A Closer Look at an OCS 2007 R2 Enterprise Pool Deployment
Recently I built a new OCS 2007 R2 Enterprise Edition pool for a customer, consisting of 4 Front End servers deployed behind a F5 BIG-IP hardware load balancer to provide IM and Presence and Web Conferencing to a few thousand users. You’d think “no worries right, follow the Deployment Wizard, she’ll be apples”.
Not quite in this case. From this, I learnt a lot more about what it takes to get things off the ground in a large, highly regulated and distributed Active Directory and LCS/OCS environment.
So the objective of this post is to share a few tips with you to help mitigate delays in your deployments in the future.
Back End SQL Database
Make sure you have necessary permissions on the SQL Server (cluster) for the account you are using to create databases in the instance you’re going to use. Note that a SQL Server instance that currently hosts LCS databases cannot be used to deploy the databases for OCS 2007 R2.
Also check with your DBA to see if any minimum database size requirements are in place as part of an existing new database template.
Forest Level Universal Group Memberships
As well as having Domain Admins group membership in the domain you’re deploying the pool in, to create the Enterprise Edition Pool you’ll need either membership of the RTCUniversalServerAdmins group at forest level (the parent domain – created during Forest Prep) or be a member of a group that has had these effective permissions delegated to it (see John’s post for more details).
Service Accounts
Once you’ve created the Enterprise Pool and entered all the necessary FQDNs, specified the back end server and the file shares to use, you’ll want to started installing OCS 2007 R2 on your Front End Servers and adding them to the pool. A few things to watch for here service account wise that you may require change control/approval on.
- The RTCService you create (or utilise from an existing deployment – same name or not) during Front End Server activation must be a member of the RTCHSUniversalServices universal group in forest root.
- The RTCComponentService account must be a member of the RTCComponentsUniversalServices universal group in forest root.
- The RTCGuestUserAccess account you create during Front End Server activation must be a member of the RTCUniversalGuestAccessGroup universal group in forest root.
These are all things that are usually taken care of during the entire deployment process, but could snag you up in a more complicated environment. So when you submit that change request to get RTCUniversalServerAdmins group (or equivalent delegated) membership, send through the names of the service accounts you intend on using also.
Issuing certificates to servers when using the Certificate Wizard isn’t an option
Generally once each Front End Server is installed, added to the pool and activated, we kick on with assigning certificates to these servers. We do this using the Certificate Wizard included with the OCS 2007 R2 Admin Tools.
If you don’t have the necessary rights to wanton request certificates from the CA (e.g. you might only have rights to issue certificates from one particular template) or you can’t request using the Web Server template that the OCS Certificate Wizard uses, you’ll need to either submit CSR files or get your certs from the CA’s web enrolment page. During this deployment, I opted for the later.
Because we generally need to specify a SAN (Subject Alternative Name) or two for things like pool FQDN, machine FQDN and External Web Farm FQDN, we need to make sure these get on the cert. This works a bit differently than in the OCS 2007 R2 Certificate Wizard.
Navigate to the Web Enrolment page of your CA (generally https://serverhostname/certsrv) and click through (in order) the Request a Certificate, Advanced certificate request and Create and submit a request to this CA pages.
Specify the certificate template (Web Server ideally, but if you can only use a certificate template that grants the equivalent or greater specs than this, select that). Fill in all the usual details like you would in the OCS 2007 R2 Certificate Wizard.
Now, here’s the cool part. In the Attributes box at the bottom of the page, you can specify the additional SANs you need. Your string should take the following format:
(san:dns=SN FQDN&dns=SAN FQDN) e.g. san:dns=hostname.domain.com&dns=poolname.domain.com&dns=abs.domain.com
Note that each SAN FQDN is separated by a & (ampersand) sign.
Once you’ve specified your SANs, click Submit.
If the CA is not configured to issue certificates automatically; a Certificate Pending page appears and requests that you wait for the CA administrator to issue the certificate that you requested.
Otherwise, the Certificate Issued Web page appears and you can click Install this Certificate to install the certificate.
This step installs the certificate to the User container in the Certificates MMC snap-in, so make sure to properly move it to the Machine container so you can assign it to your Front End servers.
Conclusion
You won’t come across a lot of these issues in every Enterprise Edition pool deployment you do, but it’s worth being aware of them for those peskier, more locked down environments.
If anyone has any questions regarding anything I’ve mentioned, feel free to post it in the comments section.
- Justin Morris, Modality Systems
![[owa+error.png]](http://2.bp.blogspot.com/_2HSNh5NAP4Q/SkG9K_ArM2I/AAAAAAAAAJ8/qDuQRgMu9WU/s1600/owa%2Berror.png)