Mino – The UC Guy

Microsoft Unified Communications Blog

Archive for the ‘Common Errors’ Category

How to allow domain users to connect to Lync 2010 or OCS 2007 from Clients running on non-domain computers

Posted by Mino on September 15, 2010

I had a situation in our company where we have exceptional few users who got Domain credentials but they are working on Computers that are not joined to the domain.

However these computers run over the LAN or WAN, can communicate with the internal DNS and got the certificate chain of the CA imported to them and they use DOMAIN\UID and password credentials to login to mail , MOSS and everything is working fine.

When I installed the OCS 2007 R2 client on their machines and tried to login with the same behavior as mail using DOMAIN\UID , I was not able to log in and I received the below event log warning:

"Communicator was unable to authenticate because an authenticating authority was not reachable.”
Resolution:
The server may be asking for Kerberos authentication and Communicator is not able to find the Kerberos Domain Controller in order to generate credentials and authenticate.  The network administrator will need to change the configuration on the server to utilize only NTLM authentication before Communicator can login from this location properly, or connectivity will need to be made available to an authenticating authority"

 

also as for testing I removed the OCS 2007 R2 client and installed the new Lync RC client on the same machine , I know it is not supported scenario but I was just testing it. Now the user was able to login but it disconnects after 10 seconds then reconnects again , it keep in this loop. I also found the same warning in the event log.

I know why this is happening and I know it would have been solved from the beginning if i forced the OCS to use NTLM only rather than Kerberos but this was not something i can force.

So in the end the Solution was this problem was simple :

Ensure that the users when singing in to communicator 2007 or Lync 2010 to include the ".local" in the domain.local\username part of the authentication and not DOMAIN\username.

Posted in Common Errors, communicator client, Lync 2010 Client | Tagged: , , , | 3 Comments »

You may encounter problems when you use the Absconfig.exe tool

Posted by Mino on February 2, 2010

When you install OCS 2007 RTM resource kit and you try to run the ABSconfig.exe, you get the below error

ABS Configuration Tool -Error
Exception: System.ArgumentOutofRangeException: Value of ‘6/17/2008 6:30 AM’ is not valid for Value.  Value should be between ‘MinDate’ and ‘MaxDate’.  
Parameter name: Value

at System.Windows.Forms.DateTimePicker.set_Value(DateTimeValue)

at ABSConfig.MainForm.WMIConfigInit().

and then also you get the error  :ABS is not enabled or activated on this server (to enable set the WMI outputlocation to null)

The problem is explained in the KB Article 954749  and Hotfix for the ABSConfig.exe is available for download.

Posted in Common Errors, OCS Tools Kit, Uncategorized | Tagged: , , , , | Leave a Comment »

OCS Response Group Service failed to start with Error event ID 31193

Posted by Mino on October 14, 2009

We have OCS 2007 R2 Pool with 2 front end servers enterprise edition, let us say that the FQDN of the servers are OCSFE01.contoso.com, OCSFE02.contoso.com and the Pool name is OCSPOOL.contoso.com.

I created the certificate request for the front end servers using the OCS wizard where I added the Pool name in the CN and in the SAN also , then I clicked the check box of add local machine name to the SAN certificate.

Then I try to enable the OCS Services and I found that the OCS Response Group Service failed to start with the below error:

Log Name:      Office Communications Server
Source:        OCS Response Group Service
Event ID:      31193
Task Category: (2001)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      OCSFE01.contoso.com
Description:
The provided certificate is not valid.

There was a problem validating certificate: Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was ‘OCSPOOL.contoso.com’ but the remote endpoint provided DNS claim ‘OCSFE01.contoso.com’. If this is a legitimate remote endpoint, you can fix the problem by explicitly specifying DNS identity ‘OCSFE01.contoso.com’ as the Identity property of EndpointAddress when creating channel proxy.

 

How to Resolve:

The problem is in SAN certificate for the frontend servers you need to make sure that the last DNS entry in the SAN list matches the certificate subject name, which should be your pool name.

And since I clicked the checkbox of add local machine name to the SAN , so it added the FQDN of the machine as the last entry in the SAN and this was the problem.

So make sure that the CN should be the pool name ocspool.contoso.com and the last name in the SAN should also be pool name ocspool.contoso.com

 

Update : this is a known issue that  has been fixed with Hotfix in KB 969695

Posted in Certificates, Common Errors, Front End Server, OCS 2007 R2 | Tagged: , , , , , , | Leave a Comment »

Address Book Download Issue (Vista Only)

Posted by Mino on July 6, 2009

This is a case I have faced right after the MVP award thing; it proves one thing to me.  You will always learn till the last minute of your life whether you are a Ranger or MVP or even one of the product team themselves. 

Ok here is the case; I have a Pilot on Isolated Environment where I have deployed 3 machines (AD+ CA+ Exchange, OCS Front End, OCS Mediation) And the users are on another production environment and they are planning to test the OC locally from their computers joined to the Production domain not the pilot one.

I have everything configured fine, hosts file edited correctly, Certificate Chain imported and Communicator is able to login correctly with no Problem. All of a Sudden all Vista machines are not able to download address book or to retrieve outlook free /busy information. However XP machines are working smoothly with no Problem

OK….then we think logic , what is common between Address Book and Exchange Free/ Busy?  Both are Web Services retrieved through HTTPS, so it has to be IE problem.

After some Googleing I found the solution on the UC No Evil blog as he describes details of troubleshooting steps he did and in the end it appeared to be the IE setting of Check for sever certificate revocation along with Disabling Windows Vista User Access Control

Below Are the Detailed Steps as described on the Blog:

  1. Make sure this symptom is the same on all of your Vista clients.
  2. Flush DNS by using ipconfig /flushdns on the client.
  3. Verify within IE that ‘Check for server certificate revocation* is disabled.  To do this go to IE > Advanced > Security section > Check for sever certificate revocation*.   Deselect the check box.
  4. Now  close Internet Explorer, close Communicator (Completely — sign-out and close application)
  5. Start Communicator| Sign in
  6. If you’re not presented with an error or the warning stating an issue accessing the Address Book, go to the %userprofile%\Local Settings\Application data\Microsoft\Communicator and verify that a GalContacts.db file exists.  If it does exist, GREAT! You’re done.   If not then continue with the rest of the procedure.
  7. Within IE add the Address Book URL that users will download the AB files.  IE > Internet Options > Security > Trusted Sites > Add the URL to trusted sites (ex.  https://ocsfrontend.company.com)
  8. Repeat steps 4-6
  9. If you still cannot download the address book try, move to step 10.
  10. Verify that User Access Control is off and then repeat steps 4-6.

Also some good technical details for the issue are available here on Microsoft Forums

Posted in Certificates, Common Errors, communicator client, Front End Server, Good Articles take from Other Blogs, Miscellaneous, OCS 2007 R2 | Tagged: , , , , , , , , , , , | 8 Comments »

How to Fix Exchange UM Certificate errors when Integrating with OCS 2007

Posted by Mino on May 19, 2009

Typically When Exchange 2007 is installed, it generates a self-issued certificate for use with IIS, SMTP, and SIP (if you’re using UM).  This certificate generally isn’t ideal for Outlook and OWA clients because it’s not trusted by any machines except for the Exchange server, and one of the first tasks to do is replace this certificate with one that is trusted by the user’s machines.

So typically you would request to buy a Public certificate for the Exchange and usually people don’t include the internal FQDN of the servers in this request.

On the Other Hand when you deploy the OCS 2007 you will require Certificate for each OCS server and this is required for securing the communication internally between OCS to OCS servers and OCS to Client. So you will deploy internal Enterprise CA in your domain to issue the certificates for the OCS , and since this is Enterprise CA so it will be published in the Active directory and it will be trusted by default for all internal domain user computers.

However when you try to integrate the OCS 2007 with the Exchange UM by this design , the first thing you will notice that the Voice mail is not accessible from the Communicator client  and it is giving you communicator error whenever you click on voice mail ,and you will find lots of Certificate event logs and OCS Protocol stack errors on both OCS front end and Exchange UM Server.

The reason behind that is because the Exchange UM server is still using the Exchange Self Signed certificate for its internal name and it is trying to communicate with the OCS using this certificate , and since the OCS doesn’t know anything about this issuer so it drops the connection.

To solve this problem we will have to replace the Exchange UM self signed certificate with one from the same CA that the OCS 2007 is using. To accomplish this task simply run the below command on the Exchange command shell.

New-ExchangeCertificate -GenerateRequest -Path c:\UMrequest.req -SubjectName “c=US, o=Contoso, cn=umsrv.mydomain.local” -DomainName mydomain.local  -PrivateKeyExportable $true

This will generate a request on the C: drive under the name of UMrequest.req  for the UM server internal FQDN umsrv.mydomain.local , open it with notepad and copy the content and then go to the PKI auto enrolment page https:\\pkisrv.mydomain.local\certsrv   to issue the certificate and save it locally .

Then we need to import the certificate to exchange and Enable it for UM service usage , my certificate is saved on the C: drive with the name of UMCertificate.cer

Import-ExchangeCertificate -Path c:\UMCertificate.cer

The last thing we will do is to enable this certificate for UM usage, first make sure to copy the Thumbprint of the certificate that you will see in the command shell then run the below command .

Enable-ExchangeCertificate -Thumbprint 5113ae0233a72fccb75b1d0198628675333d010e –Services UM

Restart UM service and restart OCS Front End Server and now you will get the UM working fine with the OCS and you will no longer see the protocol stack errors.

Posted in Certificates, Common Errors, communicator client, Front End Server, Mediation Server, OCS & Exchange07, OCS 2007 R2, Phone Edition, Unified Messaging | Tagged: , , , , , , , , , , | 3 Comments »

The OCS 2007 R2 Edge and NAT

Posted by Mino on March 4, 2009

Any Post starting with this disclaimer means that this post was not written by me however I have liked it and added to my blog. I will also include the link to the original or Similar post to provide credit to the original author.

https://blogs.pointbridge.com/Blogs/mcgillen_matt/Pages/Post.aspx?_ID=61

The proof was came last week when I was working with a client on an R2 edge server. This was the perfect test case because we had already tried NAT with R1 and, of course, it failed…

So we were going to try it again with R2 – same firewall and everything. As we went through the R2 Edge config, there was a little check box on the AV interface that said “This address will be NAT’d”. Sweet!

We checked the box…and… it failed .

We were kinda puzzled, but the OCS error logs came to the rescue. The error log showed that the edge server was “unable to resolve ‘av.customer.com’ – using 10.x.x.x instead”.

That’s exactly what I didn’t want: the internal IP being handed out. The helpful hint, though, is that the edge was trying to resolve the name “av.customer.com”. If you ask me, this is a bit odd. It would make more sense to me if OCS just had a parameter that said “external IP address of AV edge”. But apparently not – it just does a lookup on the AV edge FQDN.

The client was using split-brain DNS and didn’t have a record for av.customer.com in the internal DNS zone. So we added an A record. But listen up here: you want to add the PUBLIC IP for av.customer.com in your DNS – even if it’s an internal DNS server.

Apparently, this is the mechanism for the edge to figure out what IP to hand out to external clients for AV sessions.

 In summary:

  • Check the “use NAT” box in the AV edge configuration properties
  • Make sure your internal and external DNS A records for the AV edge server are configured with external addresses.

Big improvement over R1

Posted in A/V Edge Server, Common Errors, Edge Server, OCS 2007 R2 | Tagged: , , , , , , , , | 1 Comment »

OCS R2 Updates about the Firewall Requirements for External User Access

Posted by Mino on February 25, 2009

One of the main topics that has been giving me hard times when communicating with a firewall System Admin would be why would the OCS AV Edge Server need a Publicely routable IP , and how secure it is to open 10,000 ports  ( 50,000 – 59,999 ) TCP/UDP ?

usually we used to get Microsoft articles and explain more about the STUN protocol and why It cant work behind NAT and then how to secure the Edge .

But now with the R2 I have good good news for the Firewall Admin team  :

1- If you are implementing a Single Consolidated Edge Server then you can work with NAT IP rather than the publicely routable real IP which was required before . Only Only if this is a Single consolidated Edge

2- the 50,000 – 59,999 UDP/TCP ports which are required to be open , are only required if you are planning to have fedration with other orginizations . if there is no fedration in your plan then no need to open these ports .

I hope you are happy now Firewall Admin team  J

Firewall Requirements for External User Access

 

 Publicly Routable IP Address

In any location with multiple Edge Servers deployed behind a load balancer, the external firewall cannot function as a network address translation (NAT). However, in a site with only a single Edge Server deployed, the external firewall can be configured as a NAT.

If you do so, configure the NAT as a destination network address translation (DNAT) for inbound traffic—in other words, configure any firewall filter used for traffic from the Internet to the Edge Server with DNAT, and configure any firewall filter for traffic going from the Edge Server to the Internet (outbound traffic) as a source network address translation (SNAT). The inbound and outbound filters must map to the same public IP address and the same private IP address, as shown in the figure below.

The A/V Edge Service requires the port range from 50,000 through 59,999 to be open only for the sharing of audio/video with federated organizations.

  • If you will be federating with organizations that run Office Communications Server 2007 and earlier, you must open this port range for both RTP/TCP and RTP/UDP, and for both inbound and outbound connections.
  • If you will be federating only with organizations that run Office Communications Server 2007 R2, you need only to open this port range for RTP/TCP, only for outbound connections.
  • Otherwise, if you will not be sharing audio/video over a federated relationship, you can close this port range.

  dd441361_6b3a5ede-4253-4874-b096-2e969bf52626en-usoffice_131

Source : http://technet.microsoft.com/en-us/library/dd441361(office.13).aspx

Posted in A/V Edge Server, Common Errors, Consolidated Edge, Edge Server, Miscellaneous, OCS 2007 R2 | Tagged: , , , , , , , , , , | 1 Comment »

Call unsuccessful – The Requested type of content encryption is not supported

Posted by Mino on November 17, 2008

You might get the above error message when you try to call your voice mail hosted on Exchange 2007 SP1 UM from your Office Communicator Phone Edition (OCPE) powered device. The likely cause of the issue is a mismatch between the VoIPSecurity setting of your SIP URI UM dial plan and the Security – Encryption level setting on the A/V Conferencing properties on your OCS 2007 pool.

The OCPE device use the Security – Encryption level setting to determine, if media should be encrypted or not. The default setting is Require encryption and OCPE will then send media using SRTP. If the UM dial plan VoIPSecurity parameter is set to SIPSecured Exchange 2007 SP1 UM will not accept the SRTP based media and you get the error message above on OCPE. Changing your UM dial plan to have the VoIPSecurity parameter set to Secured will fix the issue. This is the recommended setting, since this ensures that media is sent in a secure way.

Posted in Common Errors, OCS & Exchange07, Phone Edition | Tagged: , , , , , , , , | Leave a Comment »

Communicator error ” Cannot Synchronize Address Book “

Posted by Mino on November 17, 2008

A common issue we see is clients getting an error stating “Cannot Synchronize Address Book”.  It looks like this:

1  

 

 2

 

This is an action that the OCS installation doesn’t take care of automatically so it happens pretty regularly.  To resolve it, select the Directory Security tab and click on the Server Certificate Button

3

After you click on the Server Certificate button, follow the Wizard, select Assign an Existing Certificate and assign the certificate used by your OCS Server for client logins.  Once you’ve assigned the certificate the SSL port on the Web Site tab should be filled in with port 443. 

Sign your clients out of Communicator and then back in and the Address Book should be downloaded successfully

 

PS : if you are using Exchange 2007 Selfsigned Certificate , you should also recieve this error still and that it because the self signed certificate for exchange is not trusted by OCS 2007 . so you should either replace the exchange 2007 self signed certificate with a certificate from the same CA as the OCS 2007 or you should import the exchange self signed certificate inside the OCS 2007 servers in the Trust Certificate store  

Posted in Common Errors, communicator client, Miscellaneous, OCS & Exchange07 | Tagged: , , , | 1 Comment »