MOC 2007 R1 or R2 client throws the error: “Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book. If the problem persists, contact your system administrator.”

Problem

You have OCS 2007 R1 deployed in your environment and began noticing MOC (Microsoft Office Communicator) clients display a notification:

… labeled:

Cannot Synchronize Address Book

… with the error message:

Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book. If the problem persists, contact your system administrator.

Solution

After verifying that I was able to:

1. Browse the https://poolFQDN/ URL without being issued a certificate warning
2. Download a .lsabs file from the URL https://poolFQDN/abs/int/handler
3. View the Invalid_AD_Phone_Numbers.txt from the URL https://poolFQDN/abs/int/handler/Invalid_AD_Phone_Numbers.txt

… I realized that I was informed of the internal Certificate Authority being upgraded.  Although the keys from the decommissioned CA were restored onto the new CA, I had a feeling that perhaps the MOC client was still trying to contact the old CA because the pool was still using a certificate issued from the old CA.

After reviewing the pool’s certificate attributes, I had a thought that perhaps the MOC client (through Internet Explorer’s engine) was trying to contact the decommissioned CA to retrieve the certificate revocation list.  I remember coming across an article a year ago that showed how to modify the registry to skip a CRL check so after a bit of searching, I managed to find the instructions.

Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

Key: CertificateRevocation

Type: REG_DWORD

Options: 1 (turn on) or 0 (turn off)

Note how the registry key’s value is 1 (turned on):

So I proceeded to turn it off:

Signing out and back in did not remove the notification but closing and re-launching the MOC client did: 

 

So what part of the certificate tipped me off?  Here are the details to the CRL Distribution Points field:

[1]CRL Distribution Point

     Distribution Point Name:

          Full Name:

               URL=ldap:///CN=Contoso%20Ltd,CN=CERT01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=internal?certificateRevocationList?base?objectClass=cRLDistributionPoint

               URL=http://cert01.Contoso.internal/CertEnroll/Contoso%20Ltd.crl

 

The server named cert01 no longer existed because the new certificate authority is now named cert02.  Hope this post helps anyone out there who may encounter the same problem as I did.

You notice the notification “Limited External Calling” displayed on your MOC client when setting up Avaya RCC integration with Lync Server 2010 while in coexistence with OCS 2007

Problem

You noticed that after you’ve configured your Avaya AES server in the Trusted application servers node in your Lync Server 2010 topology:

… you notice that legacy OCS 2007 MOC clients being having the notification: Limited External Calling with the message:

Some calls to and from people outside of your corporate network may not connect due to server connectivity problems. Try signing out and signing back in. If this problem continues, contact your system administrator with this information.

You log into the Front End Properties of the OCS 2007 pool:

… and notice that the settings for your Host Authorization tab are missing:

So you proceed and fill the AES server settings back in and perform a Front End Server validation on your OCS 2007 front-end server:

… and notice the following failures / errors thrown:

Failure
[0xC3FC200D] One or more errors were detected

Error: Multiple server roles (TrustedUnknownService,AuthorizedHost) are configured at the same address aes.contoso.local but they have different trust options.

You also notice that if you stop the Office Communications Server front-end service, you are no longer able to start it back up.  It is not until you remove the Host Authorization entries that you are able to start your OCS 2007 front-end server service. 

Reviewing the event logs in OCS 2007 administration tools show the following errors and warnings logged:

The server configuration validation mechanism detected some potential problems. The server might not behave as expected.

The server [aesdr.contoso.local] is configured as the next hop for the static route [aesdr.contoso.local] but it is not a known configured server. Check the 'Host Authorization' pane in MMC.

Error code is:0xC3E93C47 (SIPPROXY_E_BAD_SERVER_CONFIGURATION).
Cause: Check the previous entries in the event log for the failure reason.
Resolution:
Try restarting the server after resolving the failures listed in the previous event log entries.

Error: 0x0xC3E93C47 (SIPPROXY_E_BAD_SERVER_CONFIGURATION).

Cause: There are serious problems with the server configuration that prevented it from starting up.
Resolution:
Review the previous event log entries to identify failures. Alter the server configuration as required. If problems persist, contact product support.

ERRORS:
Two server roles at FQDN [aes.contoso.local] have different server version numbers. First server has GUID {2D42A164-43D3-462A-98D5-FB583A8573C7} and role 'Authorized Host' (version 0). Second server has GUID {D377357E-721A-5594-9107-F3EBD1A68BF5} and role 'Application Server' (version 5).
WARNINGS:
The server [aesdr.contoso.local] is configured as the next hop for the static route [aesdr.contoso.local] but it is not a known configured server. Check the 'Host Authorization' pane in MMC.
Cause: The configuration is invalid and the server might not behave as expected.
Resolution:
Review and correct the errors listed above, then restart the service. You also wish to review any warnings present.

Reviewing the application logs in the event logs show the following:

Event ID: 14518

The server configuration validation mechanism detected some potential problems. The server might not behave as expected.

1 warnings were detected:

The server [aesdr.contoso.local] is configured as the next hop for the static route [aesdr.contoso.loca] but it is not a known configured server. Check the 'Host Authorization' pane in MMC.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event ID: 14496

Failed to remove a server from the known servers table.

Server=[aes.contoso.local]. InstanceID={2D42A164-43D3-462A-98D5-FB583A8573C7}. Error=0xC3E93C4E (SIPPROXY_E_UNKNOWN_SERVER).

Cause: This may be due to a previous failure.

Resolution:

Check the previous event log entries for failures. Restart the server. If the problem persists, contact Product Support Services.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event ID: 12326

Failed starting the protocol stack. The service has to stop

Error code is:0xC3E93C47 (SIPPROXY_E_BAD_SERVER_CONFIGURATION).

Cause: Check the previous entries in the event log for the failure reason.

Resolution:

Try restarting the server after resolving the failures listed in the previous event log entries.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event ID: 14352

Unable to start the stack.

Error: 0x0xC3E93C47 (SIPPROXY_E_BAD_SERVER_CONFIGURATION).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp

Event ID: 14497

One or more configuration errors were detected at startup that cannot be mitigated.

Cause: There are serious problems with the server configuration that prevented it from starting up.

Resolution:

Review the previous event log entries to identify failures. Alter the server configuration as required. If problems persist, contact product support.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event ID: 14517

The server configuration validation mechanism detected some serious problems.

1 errors and 0 warnings were detected.

ERRORS:

Two server roles at FQDN [aes.contoso.local] have different server version numbers. First server has GUID {46F7B75D-1FB4-4388-B186-6E38E3211540} and role 'Authorized Host' (version 0). Second server has GUID {D377357E-721A-5594-9107-F3EBD1A68BF5} and role 'Application Server' (version 5).

WARNINGS:

No warnings

Cause: The configuration is invalid and the server might not behave as expected.

Resolution:

Review and correct the errors listed above, then restart the service. You also wish to review any warnings present.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Solution

This problem actually took me quite some time to figure out as I searched long and hard for the GUIDs referenced in the event logs but wasn’t able to find an exact match.  As I started running out of ideas, I figured I had nothing to lose by just opening up the objects in ADSIedit to see if something may catch my eye and as I browsed through the attributes of objects, I noticed the following:

The msRTCSIP-TrustedS… attribute avaya-bda-rcc is the logical name I used to created the Trusted Application Servers in the Lync Server 2010 topology builder.  Seeing how I had nothing else on my mind that I could try, I went ahead to remove that setting, published the Lync topology and long behold the OCS 2007 front-end server service began starting up.

I’m not exactly sure what the reason is but my guess is that the 2 objects somehow conflicted with each other and because I didn’t have time to further look into the problem, I just went ahead and left it as is until I have some spare cycles to figure this out.  For those who may be wondering why this isn’t a priority for me, it’s because we’re not going to be able to integrate Lync with the current AES server which is 2 versions behind the supported one.

I’ll update this post when the AES gets upgraded and the integration continues again.

OCS 2007 MOC shows the error: “Cannot Synchronize Address Book”

Problem

You notice a notification at the top right hand corner of your MOC client and when you click on it, you see the error: Cannot Synchronize Address Book

You proceed to click on it and you get the following detailed message:

Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book. If the problem persists, contact your system administrator.

You make an attempt to browse to the IIS directory where you the address (https://yourOCSpool.domain.com/abs) is downloaded and you get an Internet Explorer cannot display the webpage or an error that suggests the website not being up::

You then try navigating to the regular http (no SSL) root page and you see that the page is working fine:

Solution

Keep in mind that this error can be caused by many reasons and the following is just one of them.

Although the regular http page served by IIS is accessible, it’s still a good idea to check the World Wide Web Publishing service to be sure that it’s up:

Once you’ve verified that the service is up, open up Internet Information Services (IIS) Manager to verify that the site is up:

If everything looks fine, what’s most likely the cause is the certificate that is assigned to the default web site so open up the properties of it, navigate to Directory Security and then try clicking on the View Certificate button:

If continuous clicks on it doesn’t give you a response, it may be because the certificate has been deleted from the computer store.  Something like this can happen if you’ve recently renewed your certificate and after assigning it from within the OCS administrative console, you removed the old certificate.  In such a situation, the majority of your OCS services will continue to work but your address book download which relies on your IIS will cease to operate.

What you want to do at this point is to continue by clicking on the Server Certificate button to assign the new certificate to the default web site:

Once you’ve reassigned the certificate, the View Certificate button should now response when you click on it:

Now when you browse to the root of the https directory on the server, you should see this default page:

Sign out of your MOC client then back in and you should see the error message go away.

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
http://terenceluk.blogspot.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:\Windows\system32>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 Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS
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                        : EXCHANGE\EWS (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.

Can Microsoft Lync Server 2010 handle line URI extensions with the format “1234567890;ext=xxxx” that start with a “0”?

For those who have come across one of my previous posts about Microsoft Lync Server 2010 handling extensions that start with a “0”: http://terenceluk.blogspot.com/2011/02/can-microsoft-lync-server-2010-handle.html

Can Microsoft Lync Server 2010 handle extensions that start with a “0”?

… the project with the client who initially asked me this questions finally kicked off this week and while I was onsite today, I was told that I had interpreted the question incorrectly.  What they were asking was not whether Lync Server 2010 supported line URIs with an extension that starts with a “0” such as “+0123” which I had tested to work but rather whether the format “1234567890;ext=0xxx” was supported.  They have indicated that if such a line URI was processed by OCS 2007 R2, the 0 would get dropped.  Having been intrigued with this question since I was asked a while ago, I went ahead and said we should test it right now.  Here’s what the normalization rule looked like:

Pattern to match: ^(0\d{3})$

Translation rule:  +1xxx123xxxx;ext=$1

Once the normalization rule kicked in, we tried entering an extension into the MOC client and long behold, this is what we saw:

… doesn’t look good does it?  The translated extension appears to suggest that the 0 has indeed been dropped but I didn’t want to take this visual representation as a fact so I started a trace on the Lync front-end server as well as the NET UX2000 gateway we were working with and this is what I saw in the trace logs:

TL_INFO(TF_PROTOCOL) [10]3E40.3144::03/16/2011-14:53:10.312.004f2093 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(660))[825729205]
<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_C22FF>], 132.216.75.61:5070<-132.216.75.61:50730
INVITE sip:+15145555555;ext=0123@NET-SBC1.domain.ca:5070;user=phone;maddr=lync.domain.ca SIP/2.0
FROM: "Lync Test1"<sip:lync.test1@domain.ca>;tag=f1cc7c7bc1;epid=ddc9a3667c
TO: <sip:+15143984400;ext=0123@domain.ca;user=phone>
CSEQ: 1 INVITE
CALL-ID: a5d5102f296141f29986a8bfd6c041ee
MAX-FORWARDS: 69
VIA: SIP/2.0/TLS 132.216.75.61:50730;branch=z9hG4bK193ABD3D.DBA09024B7D96C76;branched=FALSE
VIA: SIP/2.0/TLS 132.206.35.97:62270;ms-received-port=62270;ms-received-cid=487500
RECORD-ROUTE: <sip:lync.domain.ca:5061;transport=tls;ms-fe=LYNCFE01.domain.CA;opaque=state:T;lr>;tag=3504A5D80AECAB1E3E86A40C5049003A
CONTACT: <sip:lync.test1@domain.ca;opaque=user:epid:RNQyjfkeulKdtEdAgsJTPwAA;gruu>
CONTENT-LENGTH: 4229
SUPPORTED: ms-dialog-route-set-update
SUPPORTED: timer
SUPPORTED: histinfo
SUPPORTED: ms-safe-transfer
SUPPORTED: ms-sender
SUPPORTED: ms-early-media
SUPPORTED: 100rel
SUPPORTED: replaces
SUPPORTED: ms-conf-invite
USER-AGENT: UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync 2010)
CONTENT-TYPE: multipart/alternative;boundary="----=_NextPart_000_0856_01CBE3C8.56A55030"
ACCEPT-LANGUAGE: en-US
ALLOW: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS
P-ASSERTED-IDENTITY: "Lync Test1"<sip:lync.test1@domain.ca>,<tel:+15143999584>
ms-application-via: SIP;ms-urc-rs-from;ms-server=LYNCFE01.domain.CA;ms-pool=lync.domain.ca;ms-application=ad894dc3-55e0-44bf-a07e-3c073aaa4a57
ms-application-via: sql1vs5_vs5;ms-server=LYNCFE01.domain.CA;ms-pool=lync.domain.ca;ms-application=51FB453D-5B9F-45df-83B4-ADD1F7E604A8
Ms-Conversation-ID: Acvj6d2DHE7BRe5PQQC19ELJkcEewA==
ms-keep-alive: UAC;hop-hop=yes
ms-subnet: 132.206.35.0
ms-endpoint-location-data: NetworkScope;ms-media-location-type=Intranet
ms-user-data: ms-publiccloud=TRUE;ms-federation=TRUE
------=_NextPart_000_0856_01CBE3C8.56A55030

As shown in the snooper logs, we can see that the extension 0123 is indeed passed as the extension even though the Lync client appears to have disregarded it.  I’ve also gone ahead to have a look at the UX2000 gateway logs and confirmed that the full line URI was sent over with the extension: “0123”.

Lync Server 2010 Desktop Share issue with Windows 7 and UAC: “Share control is disabled for elevated applications.”

For those who have come across one of my earlier posts about:

OCS 2007 R2 Desktop Share issue with Windows 7 and UAC

http://terenceluk.blogspot.com/2010/10/ocs-2007-r2-desktop-share-issue-with.html

… I finally had some time over this weekend to try testing the same scenario with Microsoft Lync and the results were more or less the same with the only difference being a new warning message is displayed in the Lync client. The following screenshots demonstrates the problem:

A desktop share is initiated:

The shared desktop loads:

Control is given to the person viewing the shared desktop and he proceeds to open the registry editor:

Opening the registry triggers UAC so the person viewing the shared desktop sees the following message:

Sharing is currently paused.

The person sharing their desktop sees the following:

Once the user sharing their desktop proceeds with selecting Yes to UAC, the shared screen loads:

However, the person viewing the shared desktop can no longer move the mouse. The person sharing the desktop can reclaim control:

Then give control again:

While the person viewing the desktop can move the mouse again, they will find that they cannot move or interact with the registry editor. What’s different about Lync Server 2010 and OCS 2007 R2 with this issue is that in Lync, you will see the following warning message in the instant message window of the person sharing their desktop:

Share control is disabled for elevated applications.

Clicking on the text will show the following message:

There are applications running at an elevated privilege on your desktop. A participant in control will not be able to control these applications.

As with OCS 2007 R2, disabling UAC appears to fix this problem but it’s probably not the best solution due to security concerns so I will update this post if I ever figure out if there is a way to get around this without disabling UAC.