Commenting Fixed
I realized this morning I broke the comment feature sometime awhile back. Oops. I think I’ve fixed the error so if you’ve been dying to post something you actually can do so now.
I realized this morning I broke the comment feature sometime awhile back. Oops. I think I’ve fixed the error so if you’ve been dying to post something you actually can do so now.
Clever post by Geoff Clark on a workaround for OCS when split-brain DNS isn’t an option: http://blogs.technet.com/gclark/archive/2009/05/02/ocs-dns-automatic-configuration-when-split-dns-is-not-an-option.aspx
This could be useful for other applications as well, but I would still push to get split-brain DNS configured if at all possible before falling back to this option as a last resort. While it’s attractive consider the overhead of maintaining and documenting additional DNS zones. Probably not an issue for the admin doing this, but for someone else taking a look at your environment you’ll probably raise some “WTF?” eyebrows.
Doug Lawty expands on Geoff’s idea a bit and uses Dnscmd.exe to work around a GUI limitation to create the exact zone you need: http://blogs.technet.com/dougl/archive/2009/06/12/communicator-automatic-configuration-and-split-brain-dns.aspx
The Agent Communications Panel (ACP) is a link between OCS 2007 R2 and Dynamics CRM 4.0 that Microsoft released awhile back. I’ve seen plenty of posts and mentions of the product, but not so much yet that shows how to install it and what it actually does.
First, some notes that I feel have been a little overlooked, or not made terribly clear in the documentation thus far.
To get started, download all the material found here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0d689f13-4953-40ea-995e-49469dae559e
I used an x86 Server 2003 CRM machine, but read the install guide for some notes regarding installation on Server 2008 and UAC.
The installation is very easy. On your CRM server, launch the AgentCommunicationsPanelServer<Architecture Type>.msi setup, accept the license agreement and press Next.
The install should be fairly quick. Press Finish once it completes.
Now, make sure you have a client machine with Internet Explorer 7 and the .NET 3.5 SP1 framework installed.
On your client, add your “https://<CRM Server Name>” site to the Intranet Zone in Internet Explorer to allow automatic logon.
Also, take the contents of MicrosoftCodeSigningPCA.zip and MicrosoftCorporation.zip files and install both certificates to the Trusted Root Certification Authorities and Trusted Publishers stores.
Now if you visit https://<CRM Server Name>/AgentCommunications/Microsoft.AgentCommunicationsPanel.xbap and you’ll see the application begin to download. It’s about 60 MB in size.
If you forgot to install the two certificates to both the Trusted Root Certification Authorities and Trusted Publishers store you’ll probably see this error: “Trust Not Granted. The application cannot be deployed because it is not trusted and possibly unsafe.”
If you followed everything correctly you’ll be presented with the ACP. Your presence and note can be set at the top of the screen. You can also now click on Set up A/V to configure your audio device for VoIP.
The screenshot below shows an incoming call from Roger Daltrey to an Enterprise Voice enabled user, Mick Jagger. You can see that Roger’s information was immediately pulled up in front of the agent when the call came in to provide easy access to the contact.
This second screenshot shows the ability for the agent to consult with another agent or contact while in a call.
I hope this was helpful to those wondering what the ACP actually looks like and what the installation process entails. There is obviously some great potential using the Response Group Service here to accommodate a small call center. Supported or not, it’s a great way to show off how you can build UC voice into applications.
Last night we moved our production OCS settings from the root domain system partition in AD to the Configuration partition as per the new guidance for R2 with widely distributed AD forests. It went fairly smoothly with only a few users hanging on the MigrateUserDnReferences step (after repeated tries) with a home server attribute it didn’t recognize. After I adjusted those users to match everyone else the tool finished up just fine.
The issue we had was that after the tool completed we started up the OCS services and everyone signed in just fine, but as I looked through the event logs I noticed lots of Conferencing MCU errors showing up. I restarted IIS and the Front-End services again and everything went back to to normal. Moral of the story: Don’t forget to bounce IIS since the Web Components piece of OCS runs through there.
Ran the schema/forest/domain prep steps last night as well so now on to getting R2 installed.
Ran into this bug today while trying to deploy Communicator Web Access 2007 R2 on Windows Server 2008. Apparently the SPN isn’t registered properly during the installation process which causes integrated authentication to fail. After you try to sign in you’ll see this error:
Cannot sign in because your computer clock is not set correctly or your account is invalid.(Error code: 0-1-492)
Jason Shave ran across this same issue a few weeks ago and has a nice explanation on how to add the SPN to your CWAService account.
I had to restart the CWA virtual server before the SPN change took effect, but after that CWA logged in just fine:

Microsoft posted some videos on YouTube recently showing off some of the new R2 capabilities. I can’t say I’m too wild about the whole superhero approach of “The Interventionists”. It’s tough to fit a worthwhile demo into a minute or two so don’t expect to see too much you haven’t seen before.
Videos: http://www.youtube.com/profile?user=OCSR2Launch&view=videos
Ever tried to prepend the subject of every email message with [SPAM] if it meets a certain SCL value? I figured it would be easy enough with a transport rule. Walked through the wizard and set up a basic rule set that I thought seemed reasonable.
Apply rule to messages
With a spam confidence level (SCL) rating that is greater than or equal to 4
And from users outside the organization
Prepend the subject with [SPAM]
Now that should work, right? Wrong. Messages kept flowing through without the subject modified at all. I took a look at the mail headers and I could see the SCL value being set to 4 or 5, so why wasn’t the subject being modified?
Turns out the Content Filtering Agent fires after the Edge Filtering Agent. So messages would flow through my custom rule with an SCL of 0, continue on because they didn’t meet my criteria of 4 or higher, then get passed to the Content Filtering Agent which would set the SCL 4, and then end up in my mailbox. In order to fix this you need to flip the agents around so the Content Filtering Agent is processed before Edge Transport Agent. By default The Edge Rule Agent is 3rd and the Content Filtering Agent is 4th. This Powershell line should flip them around:
Set-TransportAgent ‘Edge Rule Agent’ –Priority 4
Or, if you prefer to actually read documentation before banging your head against the wall wondering why it doesn’t word you could be smarter than me and just read this article in advance: How To Make the SCL Value Available to Edge Transport Rules
Recently I did a global deployment of OCS which required Communicator to be used in a few different languages. A great start for information on languages and localization for OCS components can found at the Modality Systems blog, but one piece of information I had a hell of time finding was deploying the multilingual user interface (MUI) pack for Communicator. Plenty of “go here to download” information available, but nothing on mass deployment.
The end goal was to deploy a single package to client machines consisting of Microsoft Office Communicator, the Microsoft Office Communicator MUI, Microsoft Office Live Meeting and the Conferencing Add-In for Microsoft Outlook. So we needed a silent installer for the MUI, but the.exe download would not respond to any kind of switches I used, no matter what.
Turns out I was just over-thinking the installer. It behaves the same way as the Live Meeting or Conferencing Add-In executables you download so you can extract the .MSI by using the –out:[File path] parameter. So, to snag the MSI which will work with any of the regular MSI switches such as /qb or /qn do the following:
CommunicatorMUI.exe –out:C:\CommunicatorMUI
Inside of the folder you specify you’ll find CommunicatorMUI.msi, which you can use as you need.
In the end, having Communicator install in the same language as Office wasn’t a strict requirement, but if you do need that done Steven Westwell has a great post on automating the registry key for language settings. He keys off a custom task sequence variable for their builds, but I’m sure you could modify that script to read the Office installation language ID.
I don’t get the hype – it’s ugly and clunky just like the old Palm phones and OS. I think they’re still screwed.

Aaron Tiensivu pointed out that the OCS Update group has been renamed in WSUS in anticipation of R2. The nice thing this time around is that Communicator client updates are going to finally be included. The current update approach is brutal: applying .msp patches which are only available as hotfixes. It made tracking and finding updates for Communicator much more difficult than it should have ever been, but this change should hopefully make that process a bit easier.