8:33 AM : Picking Up Where We Left Off
As you may recall, I ran into an issue last night just before I left because I didn’t have the SQL client tools necessary (specifically the SQL 2005 Backwards Compatibility Pack and the SQL Native Client) installed on my front end server ocsfe1. I did try installing the tools this morning to no avail – unfortunately I wasn’t even getting a good quality error message, just “Pool backend discovery failed” – the same message I posted yesterday.
I’m pursuing a workaround at this point for two reasons:
- I need to keep the ball rolling. I have to get the internal deployment completed today.
- I’m planning to move the database to an official cluster anyway, per the directions in the Admin guide for moving the backend database for an Enterprise pool.
Primarily because of reason two, I don’t feel bad about installing SQL locally for a short time period (<1 month) until our cluster is ready to support the Enterprise pool. As with other cautions I’ve offered, this isn’t recommended. For me, it’s just real life. To achieve the goal I want, I’ve created a CNAME (alias) in DNS to tell my computer that dbcluster1 is currently the same as ocsfe1. I’ve also installed SQL Server 2005 Standard Edition SP2 32-bit locally.
8:39 AM : Creating the Enterprise Pool
Two notes here:
- We specified a different internal web farm FQDN because we may eventually move to an expanded configuration, and having a different FQDN may facilitate that transition.
- The planning documentation states that if you don’t specify an external web farm FQDN at this point, you’ll need to use the command line utility later. Usefulness of command line utilities notwithstanding, I’d rather specify it now since I know what it is.
Another note: our database files will be going onto a SAN with the transition to the database cluster. If you aren’t storing your database files on a SAN, you’ll want to make sure the database and log files are on different spindles (different physical volumes). This is basic database optimization, not an OCS thing.
I didn’t enable meeting archiving yet as it probably requires the Archiving and CDR role, which doesn’t exist yet in my infrastructure. I’m quite certain you can enable this later, so I’ll skip it for now. I have put the path in, however, so that you can see what I would be using if I were to enable it right now.
Archiving is not enabled for the same reason listed above.
Ugh. I made a mistake early on in the wizard – my pool is named ocspool.extendhealth.com, not pool.extendhealth.com. I think I can probably fix this later, so I’ll keep going for now. There were no other warnings in the log.
8:59 AM : Configuring Enterprise Pool
There’s the wrong pool name I mentioned above.
| Pros | Cons | |
| DNAT | > 65,000 users | Increased difficulty of configuration |
| SNAT | Easy configuration | < 65,000 users |
Note: Only one pool or server can authenticate automatic logon requests.
I’ll definitely be configuring external user access, but two things are stopping me from doing it right now:
- I want the edge deployment to be distinct from the pool deployment for my own sanity and anyone’s sanity following along with this thread.
- I think the only way you can configure your edge topology right now is if you’re migrating from LCS 2005 R2? and already have an edge topology deployed. I’m not certain on that, I just think that’s what I recall.
9:10 AM : Adding Ocsfe1 to Pool
So far so good this morning – everything seems to be turning out okay aside from my dumb mistake with the pool name and the issues with the pool backend. I’m now ready to add ocsfe1 to the pool as the first front-end server.
(Takes a while. Lots of time for screen captures.)
Apparently Microsoft thinks it’s funny to continually remind me of my mistakes.
Yes, the password really is that long. As a reminder (I think for the third time), I use WinGuides Password Generator to generate passwords for service accounts.
Same warnings as before:
Aside from that error being in the logs about 20 times, there were no other errors. I think I’m still okay.
9:30 AM : Fixing the Pool FQDN
Before I proceed any further, I want to correct the pool FQDN. I’ve been warned sufficiently. As part of installing the Front End role, the administrative tools for OCS were installed. I’m opening them from Start > All Programs > Administrative Tools > Office Communications Server 2007.
9:36 AM : ???
Wow … http://forums.microsoft.com/unifiedcommunications/ShowPost.aspx?PostID=2931495&SiteID=57
Apparently I’ll be removing the pool and creating it all over again. Hope that goes okay.
Lesson learned: get the pool name right in the first place.
9:44 AM : Configuring Certificates
Well, at least it didn’t take too long to get back on track. For this next step, please note that there are two distinct steps. The Web Components role requires its certificate to be manually configured in IIS. The rest of the Front End roles have a wizard. I’ll deal with the wizard first, then IIS.
Because I have a PKI deployed, I can opt to send the request to an online certification authority (Active Directory will help me locate one).
In this case, we don’t care if the cert is exportable, but I left the box checked anyway. We also don’t care about client EKU – the only place that matters is for the certificate assigned to the external interface for the Access Edge role.
I chose to include the local machine name in the SAN here. If you’re configuring automatic client logon, the SAN must also contain sip.<domain>. In my case, it was automatically populated because of the choices I made in earlier wizards to enable automatic client logon.
… and … I accidentally clicked through the next screen, so I think it succeeded but I’m not 100% certain.
Well, I got that far before realizing that the prior wizard had actually failed. It has something to do with Server 2003 not recognizing the authenticity of the certificate chain. My PKI is completely implemented with Server 2008, so I guess it’s time to go research what to do.
3:22 PM : Square 1
As if there weren’t enough blocks already…
I just got off the phone with Microsoft support. The certificate issue is “by design”. In this case, I interpret “by design” to mean, “We knew about the problem but haven’t taken the initiative to fix it.” The specific issue is that Server 2003 and Windows XP don’t support certificate chains with algorithms > SHA1. Since my root CA had a SHA512 thumbprint, and my other CAs had a SHA256 thumbprint (per NIST guidelines), Server 2003 barfed.
Generally speaking I’m very happy with Microsoft. Today, I’m not. Off to rebuild the PKI from scratch…
