OCS 2007 R1 or R2 MOC client indicates the following error: “Communicator could not retrieve calendar Out of Office information from Exchange Web Services…”

It’s been a while since I’ve come across an OCS 2007 R1 environment but as I start off a new project at a client’s office today, I realized that they were still on R1.  As I took the time to familiarize the RCC configuration they have in place with their Avaya PBX, we noticed that some users who have recently been migrated from Exchange 2007 to 2010 experience the following when they log into their MOC client:

When I click on the error to bring up the details, I would get the following message:

Communicator could not retrieve calendar or Out of Office information from Exchange Web Services. Communicator will automatically continue to retry. If this problem persists, contact your system administrator.

When I saw this error, I immediately had the hunch that it had to do with a combination of their EWS URL and certificate because I’ve come across something similar in the past which I blogged about here:

OCS 2007 MOC OOF Information reliance on Exchange CAS Server
https://blog.terenceluk.com/2010/07/ocs-2007-moc-oof-information-reliance.html

The first troubleshooting step I tried was to open up Internet Explorer and navigate to the internal link of the InternalURL attribute (retrieved via the cmdlet Get-WebServicesVirtualDirectory) of their EWS directory which showed that the link which was published as https://webmail.domain.com/EWS/Exchange.asmx had a certificate that contained this URL as the common name.  What’s interesting about the information I saw was that they had a different internal and external domain name and that they had their public domain configured as a zone in their internal DNS.  What basically happens is that their internal Outlook clients will query for the IP of webmail.domain.com and would get an internal IP since the reply would be from their internal DNS.  This obviously wasn’t an unsupported setup so I continued on with the troubleshooting.

After taking a deeper look at the output from Get-WebServicesVirtualDirectory | FL, I noticed the following:

[PS] C:Windowssystem32>Get-WebServicesVirtualDirectory | fl

RunspaceId                      : b47c36a9-2464-4e39-9d6b-7988c0f5abcb
CertificateAuthentication       :
InternalNLBBypassUrl            : https://cas1.domain.local/ews/exchange.asmx
GzipLevel                       : High
Name                            : EWS (Default Web Site)
InternalAuthenticationMethods   : {Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods   : {Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication      : False
WSSecurityAuthentication        : True
LiveIdBasicAuthentication       : False
BasicAuthentication             : False
DigestAuthentication            : False
WindowsAuthentication           : True
MetabasePath                    : IIS://EXCHANGE.domain.com/W3SVC/1/ROOT/EWS
Path                            : C:Program FilesMicrosoftExchange ServerV14ClientAccessexchwebEWS
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
Server                          : EXCHANGE
InternalUrl                     : https://webmail.domain.com/EWS/Exchange.asmx
ExternalUrl                     : https://webmail.domain.com/ews/exchange.asmx
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName               : CN=EWS (Default Web Site),CN=HTTP,CN=Protocols,CN=EXCHANGE,CN=Servers,CN=Exchange Adm
                                  inistrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=SomeCompany,CN=Micros
                                  oft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local
Identity                        : EXCHANGEEWS (Default Web Site)
Guid                            : 1952de93-5772-449e-8813-70ff150973b0
ObjectCategory                  : domain.com/Configuration/Schema/ms-Exch-Web-Services-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchWebServicesVirtualDirectory}
WhenChanged                     : 8/13/2010 2:19:39 PM
WhenCreated                     : 8/13/2010 2:19:38 PM
WhenChangedUTC                  : 8/13/2010 5:19:39 PM
WhenCreatedUTC                  : 8/13/2010 5:19:38 PM
OrganizationId                  :
OriginatingServer               : dc1.domain.com
IsValid                         : True

What caught my attention was the line:

InternalNLBBypassUrl            : https://cas1.domain.local/ews/exchange.asmx

A quick search on Google shows the following:

http://technet.microsoft.com/en-us/library/aa997233.aspx

The InternalNLBBypassUrl parameter specifies the URL of the Client Access server, regardless of whether it’s behind a Network Load Balancing (NLB) array. Although the InternalUrl parameter is set to the URL of the NLB array, the InternalNLBBypassUrl parameter should always be set to the URL of the Client Access server. This is because certain Exchange Web Services calls require machine affinity, and Exchange Web Services proxy incoming calls to a more appropriate Client Access server whenever possible.

The explanation from the TechNet site pretty much states we shouldn’t be changing this URL to the public URL as we did with the other attributes.  Since the certificate they were using was from a public CA, what I ended up doing just as a test was issue a certificate from their internal CA that included the internal URL of their CAS server, reassigned it within IIS for the virtual directory, rebooted the server and the error on the MOC client went away.  Note that I also tried restarting IIS and the CAS RPC service but it did not correct the problem but a reboot did.

Not that I think I’ll be dealing with many more OCS 2007 R1 or R2 deployments but this was a good refresher.  Hope this helps anyone out there that may experience this problem.