Agent Communications Panel for OCS 2007 R2 and CRM 4.0

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.

  • I’ve seen conflicting information around support for the add-in.  A lot of posts indicate it’s fully supported by the OCS team, but according to this post, the ACP is not supported in any way from Microsoft. It really sounds like it’s more of a proof-of-concept application to show what you can do with the UC APIs and the ability to link to other platforms. Anyone know what the official story is? I’m hesitant to mention this to clients because of the ambiguous support policy.
  • CRM natively has presence, IM, and click-to-call functionality as long as Communicator is running on the user’s PC. This is true of both the Outlook version and the web-based access to CRM.  The ACP application differs by providing the Communicator functionality through the browser without actually using Communicator.  However, there is no link or dependency on Communicator Web Access for the ACP.
  • Because this is an XAML browser application (XBAP) it provides a lot more functionality than Communicator Web Access. Specifically, audio traffic can be played through the browser, so you have the Enterprise Voice features similar to a full Communicator experience.

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.

5-6-2009 3-30-02 PM

The install should be fairly quick. Press Finish once it completes.

5-6-2009 3-32-09 PM

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.

5-6-2009 3-41-53 PM

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.”

5-6-2009 3-42-33 PM

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.

5-6-2009 4-21-21 PM

This second screenshot shows the ability for the agent to consult with another agent or contact while in a call.

5-6-2009 4-26-28 PM

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.

OCS 2007 Global Settings Migration

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.

CWA 2007 R2 Login Fails

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)

image

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:

image

OCS 2007 R2 Launch Videos

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

Edge Transport Rules & SCL Values

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

Communicator multilingual user interface

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.

Communicator Updates Coming in WSUS Soon

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.

Office Communicator and Published Phone Numbers

One of the trickiest parts of configuring OCS voice is getting all your address book normalization rules functioning properly and I noticed something recently that really threw me off so I set off on a little investigation. To set the stage, I removed all normalization rules from my Mediation Server and deleted the Company_Phone_Number_Normalization_Rules.txt file. Theoretically that leaves me with just the built in rule processing.

I have 2 users, Jim Morrison and Roger Daltrey, both enabled for Enterprise Voice capabilities. Jim's Line URI is tel:+15035461201 and Roger's is tel:+15035461101. In Active Directory I filled in the telephone numbers for Jim and Roger as the same values, sans the tel: prefix. Just so we're clear, Jim's number was +15035461201.

I fired up 2 Communicator clients, one signed in as Jim and the other as Roger. From Roger's point of view I saw this:

image

 

Not very nicely formatted, right? Jim sees the same thing for Roger's number. The key point here is the number is displayed exactly as it is formatted in AD. The thing that threw me off was that I knew I had seen Communicator format those numbers in a much nicer way. Something more like +1 (503) 546-1201, which is much easier to read. So I started fiddling and went into Jim's phone options within Communicator and added a mobile number. I used the same format I did in AD, +12345678900. I added Roger to my Team Access Level so he could see the mobile number and took another look:

image

Interesting. That mobile number sure looks better than the work one, right? Why didn't Communicator display that number the same way for both numbers? I opened up Jim's phone options again and took a closer look. Jeff Schertz has a nice post mentioning how access levels (don't) get applied when you enter a number in AD, but the key point applicable here is that a number entered in AD is automatically visible to anyone within the organization. So Jim's number was entered in that box and I was unable to edit it as a user, but what I noticed was the work number was unpublished.

image

So I checked that box and then flipped over to Roger's Communicator. Well, well, well. All the numbers look right and are nicely formatted now.

image

 

So what I discovered is that the a visible and published number are treated differently. OCS will format a published number, but not a number that is simply visible because of AD. Strange, but good to know. I think this is due to where Communicator is pulling the information from. If a number is coming from AD and is unpublished, the number is being read by MOC from the GalContacts.db file. If a number is published to OCS, MOC is reading the number from the server and OCS database. So priority-wise MOC prefers a published number over one read from the address book.

Communicator Custom Presence Tool 1.1

My little Communicator application for publishing custom presence has been non-functional for some folks. I spent some time trying to fix it and think I figured out most of the problem - it works just fine for users who have made the required registry edit manually or previous to running the application. If the user never has created the necessary registry key for enabling custom presence, the application never worked. I've been completely unsuccessful in creating a legitimate fix so I've resorted to a cheapskate approach and made the application now require UAC privileges. If you were having problems I would try this updated version, but if the old version worked for you and you are not an Administrator on your box, I'd recommend sticking with the old version for now. Another solution would be to simply run the original version in an Administrator context by right-clicking on the application and choose "Run as Administrator."

I'm hoping to get a better solution up soon, but this works as a stop-gap.

Download: Communicator Custom Presence Tool 1.1

On the note of a better solution - I'm not much of a programmer so maybe someone has an idea for me.

My problem is a normal user in Vista does not have write privileges to the HKEY_CURRENT_USER\Software\Policies\Microsoft key. It seems odd, especially considering that's within the HKCU hive. So the application fails when it tries to create the HKCU\Software\Policies\Communicator key. The .XML file gets created just fine, but Communicator will never look for it because the registry key to tell it so never got set. So how the heck can I use VB to say "Open this registry key, add the permission to create a subkey?" Is it even possible without the user having write access on that key? Every time I try programmatically I get denied access, even if I open the parent key for editing. It'd be swell to be able to do this without requiring a UAC prompt.

If I ever figure that one out I have some cool ideas for a nicer GUI and 2.0 release.

Injecting Contacts to the OCS Address Book

I had a client ask recently if there was a way to insert federated contacts into their own internal address book. This would work out well for organizations where there would maybe be a few high-profile users who are frequently added between different companies. I went about trying this today and the answer is that it kind of works.

For sake of this example let's say I'm user A in Company A with an OCS SIP domain of domainA.com and a partner I'm federated with is User B in Company B with an OCS SIP domain of domainB.com. Since the OCS Address Book Service will pick up any user or contact in Active Directory that has the msRTCSIP-PrimaryUserAddress attribute set I went about the following:

  1. Created a contact object for a User B in Company B as you would normally have for a user outside your organization.
  2. Used ADSIEdit and manually populated the attribute with the user@domainB.com value that I knew was reachable and federated through OCS already.
  3. Forced an Address Book Sync.
  4. Removed User B from my Outlook contacts so Communicator wouldn't pick it up.
  5. Deleted the GALContacts.db file.
  6. Restarted Communicator.

I can search the Search field in Communicator and I get the by-letter matching for User B as I would expect for anyone else in my organization. The only downside is I don't receive any presence or information for the user until I actually add them to my contact list. On the other hand, this is the exact same behavior seen when typing any federated contact's name into the Search field. Mission sort of accomplished?

iPhone Configuration (Web) Utility

So now that the JesusPhone iPhone has been deemed Enterprise worthy around the world with its Exchange support businesses are jumping at the opportunity to move employees on to the platform. Or should I flip that around to say employees are breathing down the neck of IT departments so they can finally get an iPhone?  Either way works.

Apple has actually provided a configuration utility named, oddly enough, the iPhone Configuration (Web - if you use the web version) Utility that you can download for free. There is a native application for OS X and a web-based one for Windows or OS X systems. As far as I can tell, they all have the same feature set. Here's a quick little tour...

The main screen resembles the iTunes interface for syncing iPods and iPhones. You can also sign your profiles with a certificate, otherwise they'll appear to be from an untrusted source to the end-user.

image

The passcode page lets you configure some lockout and pin policies.

image

Wi-Fi lets you configure wireless network profiles. It's actually extremely flexible in how much you can configure.

image

The VPN page lets you configure either PPTP, L2TP or an IPSec Cisco VPN connection.

image

The Email tab will allow configuration of an IMAP or POP account.

image

The Exchange tab lets you configure a few settings to bypass any Autodiscover lookup.

image

The credentials tab lets you import certificates on to the iPhone. You can add a self-signed certificate here (hello SBS users!) to import on the device. You could alternatively point the user at a web address with the certificate file and mobile Safari would prompt them to install the certificate.

image

Lastly, you can set up the APN address, username and password if you're really ambitious. I'd suggest leaving this setting alone.

image

Keep your Communicator.msi handy

Well that was weird. I had a flaky SATA driver cause a blue screen of death on me a few minutes ago and after the restart Communicator wouldn't launch. Instead, it was prompting me for the path to a Communicator.msi. Glad I had it on hand because apparently that crash damaged the app somehow. All was well after I pointed at the .msi and it repaired itself. Strange.

Missing PR_PF_PROXY attribute on public folders

If you're in the Exchange 2003 System Manager and try to open up the properties of a public folder you might see an error like this:

The mail proxy for this folder cannot be found. This may be due to replication delays. The mail enabled pages will not be shown. ID no: c1038a21

That will lead you to this KB article: http://support.microsoft.com/kb/328740 where the simple fix (Method #2) is to just mail-enable the public folder again. What the KB doesn't mention is that in ESM you need to use the Folders node to do this. If you were to drill down through your Information Store and Public Folder Store you'll never get this option. So in ESM make sure you do this through the folders node like in the screenshot.
image

At that point you can right-click on a folder, choose All Tasks and then Mail-Enable. You'll see a warning message about only re-stamping the PR_PR_PROXY attribute if really necessary. Just press Yes and you should be able to look at the public folder properties again.

Office 2008 SP1 fixes some Exchange 2007 Problems

Recently a few of the folks I work with that use Macs noticed Entourage 2008 was having trouble using Exchange 2007 Web Services properly (as it advertised it would). I tried it out from home and verified the same thing, that the Out of Office Assistant and Free/Busy lookups didn't go so well. I've been meaning to get around to building an OS X 10.5 virtual machine so I could hook it into my VM environment and do a packet trace to see what was going on, but it seems like I won't need to anymore. Just update your friggin' client to SP1 and EWS works properly. They've also added support for Autodiscover. I haven't had a chance to play yet, but I wonder what kind of lookups and certificate restrictions Entourage has compared to Outlook.

So, moral of the post - problems with Entourage 2008 for Mac and you've got an Exchange 2007 environment? Upgrade your clients to SP1.

The 3 Stages of Enhanced Presence

A few weeks ago Michael Wagner posted an entry on the Communicator Team Blog about the 3 different stages enhanced presence can actually be in. Prior to that I had assumed that it was either an on or off deal, but there's a nice little limbo state in the middle to confuse you further. I had the opportunity to play with these different states recently so I figured I'd share what I experienced because it differed slightly from Michael's post.

The same rules apply:

  • Stage 1 - The user account Enhanced Presence setting is unchecked. This is accomplished by enabling a user for OCS 2007 or migrating a user from LCS 2005.
  • Stage 2 - The user account Enhanced Presence setting is checked, but they have not signed in with Office Communicator 2007. This is accomplished by manually checking the box "Enhanced presence" on the user account.
  • Stage 3 - The user account Enhanced Presence settings is checked and the user has signed in with Office Communicator 2007.

Here's what I found a client was able to log in to, depending on their stage.

Stage 1

  • Communicator 2005
  • Mac Messenger 6.0.3
  • 3rd-party clients (Trillian, Miranda)

Stage 2

  • Communicator 2005
  • Communicator 2007
  • Communicator Web Access 2007
  • Mac Messenger 6.0.3
  • 3rd-party clients (Trillian, Miranda)

Stage 3

  • Communicator 2007
  • Communicator Web Access 2007

Takeaways

  • Moral of the story is that once a user signs in to Office Communicator 2007 there's no going back. The only fix is to delete their account from OCS and re-enable it, but they will lose their contact list and access level preferences.
  • If you migrate users from LCS 2005 they will not be able to sign-in to a 2007 client unless you enable their account for enhanced presence. I know it's counter-intuitive because most of the documentation states that you can't use OC 2005 if you're enabled for enhanced presence. Not true, you can continue using OC 2005 until you sign in once to OC 2007. The big gotcha here is why users couldn't log in to OC 2007 after being migrated successfully - it's because you have to manually set the enhanced presence.
  • Oddly enough, that only seems to be required for migrated users. For a new user who had never been on LCS, simply creating their OCS account allows them to log in to OC 2007 without enhanced presence being checked. This behavior really confused me, but it must be a difference in how the user creation process is handled for an OCS pool as opposed to an LCS pool.
  • Michael's post states that you can't log in to CWA 2007 unless you're at Stage 3. I found this to be false. You can't login to CWA 2007 until you reach Stage 2.