I love reading Scott’s blog. I love troubleshooting, but he takes it to a new level…
http://blogs.msdn.com/scottos/archive/2009/03/20/office-communicator-2007-hangs-on-shutdown-logoff-fixed.aspx

“Customers running Office Communicator 2007 + Office 2007:

This issue is fixed by applying the hotfix referenced in KB 961752 (http://support.microsoft.com/kb/961752), and although the KB article does not specifcally call out this issue, we are working on both creating a new KB to address this, as well posting this blog entry to increase its visibility.

Customers running Office Communicator 2007 + Office 2003:

Our Office Development Team is moving forward with creating corresponding official hotfix for Office 2003.  Although it’s a bit early to discuss timeframes in terms of when you can expect the public hotfix, we have a private copy of the fixed MSMAPI32.DLL.  If you would like to test this build, please engage Microsoft Customer Support Services via http://support.microsoft.com.  Premier customers: please leverage your Technical Account Manager to initiate the case creation process.“

I’ve recently used the MigrateOcsGlobalSettings VBS script to move the RTC Service schema entries from the System partition to the Configuration partition in preparation for an R2 installation. I wasn’t familiar with the msRTCSIP-UserDomainList attribute needing to be set. Where there are users, there needs to be an entry in this attribute. The CN=Configuration,DC=domain,DC=local and any other DNs of domains where users exist need to be populated here. On a fresh installation, I understand this to be unnecessary.

Wow! I am honored and humbled to be attending the next rotation of the Microsoft Certified Master training program. I’m sure that I will be even more humbled once I get there. It will be an intense 3 weeks away from the family. It will also be an extremely rewarding experience. I’ll be sure to blog updates during my visit toward the end of April.

I just finished troubleshooting a problem that I should have solved sooner than I did!

A very simple installation of OCS 2007: a single standard pool and a single consolidated edge server. They didn’t have a PKI structure and oddly didn’t want one, so we used GoDaddy for the internal certs and Thawte for the public certs. After the implementation, everything seemed to work fine…

…until we tested one of the internal company users trying to make a Communicator call to another company user that was connected from the Internet. The invite was sent and the other client would ring, but the call would not connect. I began to narrow the scope of the failure by running the validation on pool and edge and taking Snooper traces of both servers. There were no errors and only this message in the Snooper trace, “Call terminated on media connectivity failure“, for the reason the call was terminated. As it turns out, inside to inside calls worked, outside to outside calls worked. The part that confused me, and still does to some degree, is that Federated calls succeeded.

Knowing that peer-to-peer calls don’t use the AVMCU, I decided to test LiveMeeting to ensure the MCU was OK…and it was. I was able to get full voice and video from a LiveMeeting hosted from the pool server.

Typically, I will install a consolidated edge with three public IPs on one NIC, an internal IP on a second NIC, and have the default gateway on the external NIC. Most smaller installation don’t have internal firewalls and have the edge installed directly on the internal LAN. I had overlooked the internal NIC configuration in assuming that communication was good to the internal network. It wasn’t until a ping from a workstation failing to the edge that reminded me to check the routing table on the edge server. Sure enough, the ping response was not able to be routed back since there were different subnets between the internal IP of the edge and the internal network. Once I added the internal persistent route, everything worked fine.

In this case the internal network was 192.168.11.0/24 and the internal interface of the edge was 192.168.251.0/24. The other office locations on the MPLS are other 24 bit masks of the 192.168 networks and are all reachable through the 192.168.251.1 gateway address. The funky part of the route add statement is getting the interface ID from the top of an ipconfig command and using the 0×1xxxx number. Lastly, the –p makes the route persistent (i.e.: after a reboot).

Now, back to the Federated call working when the route statement wasn’t there…

It appears that for Federated calls, the AVMCU is utilized. I’m researching that now. Someone please enlighten me.

It might be useful in a Cisco direct SIP environment to automatically strip the + from all outgoing SIP communication from an OCS Mediation server.

To do this, create a text (XML) file called MediationServerSvc.exe.config and place it in the location of the MediationServerSvc.exe file. It should be in the ‘C:\Program Files\Microsoft Office Communications Server 2007\Mediation Server’ directory. The contents of this file should be:

Now, you are free to normalize to E.164 without having to worry about your Cisco devices getting confused!

Just a quick note for machines not a member of the domain that want to participate in URL send/receive in the Communicator 2007 client. You will need the following registry setting to enable clickable URLS…

The above text can be copied into notepad and named with a .REG extension and run on non-domain machines not getting the group policy to allow URLs.

Just a quick note to document the bizarre occurrence of an AD attribute causing OCS Forest Prep state to show not ready…

The environment had LCS 2005 running and OCS was installed in parallel.

I was ready to activate the Mediation Server, after having the pool installed for a few days,

and it said the Forest wasn’t ready. I then checked the OCS Server and it showed the following…

Running the ‘lcscmd /forest /action:CheckForestPrepState’ command showed the following attribute ‘not ready’…

CN=user-Display,CN=C04,CN=DisplaySpecifiers

…in the Configuration container.

Running ForestPrep again appears to have resolved the issue, but I’m keeping an eye on it!

I just resolved an issue where the OCS Front-End and the Exchange 2007 UM server wouldn’t talk with each other. Communicator or Phone Experience would not connect to Exchange UM.

Here is a debug from Phone Experience dialing Voice Mail…

Result-Code: 0xc3e93f30 SIPPROXY_E_INVALID_EDGE_PROXY_HEADER
…and…
SIP 480…
ms-diagnostics: 15007;reason=”UM server did not respond to request”;source=”OCS001.company.net”;dialplan=”Test.company.net”;
umserver=”ex07.company.net”;appName=”ExumRouting”

The Exchange server would produce this event, ID1088:

The IP gateway or IP-PBX “pool.company.net” did not respond to a SIP OPTIONS request from the Unified Messaging server. The error code that was returned is “400″ and the error text is “Malformed Edge Proxy header:The requested operation failed.”.

The OCS server would produce this event, ID44022:

An attempt to route to an Exchange UM server failed.
The attempt failed with response code (Timeout): ex07.company.net.
Failure occurrences: 1, since 4/17/2008 2:34:57 PM.
Resolution:
Check this server is correctly configured to point to the appropriate Exchange UM server. Also check whether the Exchange UM server is up and whether it in turn is also properly configured.

Every Internet search related to Malformed Edge Proxy pulled up certificate related issues. I checked the certificates, but everything looked fine. It wasn’t until I noticed the EventID:1112 showing which certificate the UM service was using did I correlate the issue. This event specifies the specific certificate used by UM. In this case, I compared the certificate assigned to the Default Web Site on Exchange to the certificate used by UM and found differing serial numbers:

I then deleted the certificate used by the UM service and restarted the UM Service and all was well.