Aaron Tiensivu's Blog

To begin, follow the instructions here for the usual Server 2008 R2 workaround/fixes for Server 2008 R2 and OCS 2007 R2.

1. From an elevated PowerShell prompt: Import-Module ServerManager [Enter]
2. Install the prerequisites for Group Chat Server with: Add-WindowsFeature AS-NET-Framework,Desktop-Experience,FS-FileServer,NET-Framework-Core,MSMQ-Server,MSMQ-Directory,RSAT-ADDS,WAS-Process-Model,WAS-Config-APIs,Web-HTTP-Logging,Web-Mgmt-Compat,Web-Mgmt-Console,Web-Static-Content,Web-Windows-Auth [Enter]
3. Install KB 975858 so certificate based authentication works properly.
4. Install the OCS Group Chat Server as you normally would on any other operating system. Elan's guide is helpful for this (Part 1 / Part 2).
5. Install the OCS Core update from here and the UC API update from here. (If those links are outdated, go to KB 968802 for the latest links or use the ServerUpdateInstaller.exe)
6. Install the OCS 2007 R2 CU6 Group Server update from here. It is also a good idea to grab the Admin tools update from here and updated client from here.
7. At this point, if you try to start the OCS Group Chat Server services, they will stop without anything useful in the Event Logs. I'll save you time debugging this by pointing you to this older KB article here. You need to run %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Group Chat Server\ServerConfigTool.exe so that the tool will update the Group Chat database schema to the QFE1 level.
8. After running the ServerConfigTool.exe, you'll be able to start the update OCS 2007 R2 Group Chat services.

Celebrate, at this point you'll have a working Group Chat install on Server 2008 R2.

I've heard of numerous reports of the CU6's SQL back-end update having version mismatch problems with the front-end update.

One cause I can speculate on is that the web caches that Microsoft uses publish the updated bits are lagging behind. Unfortunately, due to the updates always having the same filename from Cumulative Update to Cumulative Update, it is hard to determine what version you have downloaded without looking at the file dates stored in each individual update.

If the front-end is updated without the proper back-end update, the front-end will complain about version mismatches in the SQL stored procedures.

Update: A tip from Tom Pacyk - install the OCS2009-DBUpgrade.msi before the other CU6 updates.

I talked a little about the .NET 4.0 issue here a few days ago but now that .NET 4.0 is on Windows/Microsoft Update as a recommended update, it is hitting more users during OCS installation.

If you install .NET 4.0 Framework before installing any OCS server role, the OCS setup program will complain that .NET 3.5x is not installed, even if you have .NET 3.5x installed (x being equal to 0 or 1, meaning .NET 3.50 or .NET 3.51).

Solution? Uninstall .NET 4.0 Framework, install OCS server roles, and then install .NET 4.0 if necessary. The OCS product team is working with the Windows product team to get a hotfix/update out for this.

Ideally, I wish there was a service pack for OCS 2007 R2 that had updated install bits for the ASN fix and the Server 2008 R2 gotchas.