Inside OCS » DNS

The Remote UC Troubleshooting Tool (RUCT)

Curtis Johnstone — Mon, 14 Nov 2011 21:37:08 +0000

I haven’t done a blog entry for awhile on InsideOCS because I have spent a lot of my extra time developing a small free tool called: The Remote UC Troubleshooting Tool (RUCT).

The tool was born out of my former MOCLogin troubleshooting tool, but I decided to rename it because of the expanded features and all the great things it can do besides just troubleshoot DNS entries with Communicator and Lync client automatic sign-in.

I’ll go on record as saying that I think this is one of the best tools available for troubleshooting Lync and Communicator certificate issues!

A full description of RUCT is available here, and the tool can be downloaded here.

Here is a summary of what the tool can do:

1. Easily Query Important DNS Records used by Microsoft Lync Server and OCS.

DNS queries for the following Lync and OCS records are issued with one-click:

All Lync and Communicator internal and external records used for automatic sign-in.
Lync sign-in records used for Lync Online (in Office 365).
Lync simple URL records used for Dial-In, Meetings, and Administration.
Home registrar location records used by Lync devices.
The automatic partner discovery record used in an Open Federation configuration.

2. Test Network Availability.

Easily test the network connectivity to the hostname and port belonging to any matching DNS SRV record, or IP address belonging to an A record.
A TCP connection is attempted for hostnames and ports, and a ping is attempted for IP addresses.

3. Certificate Retrieval, Installation, and Export.

The tool can remotely retrieve X509 Certificate information on any Lync or OCS port that is secured using TLS (or SSL). Certificate information returned includes the Common Name (CN), Subject Name, Issuer, Certificate Authority, Expiry Date, Creation Date, and Subject Alternative Names (SANs), and the complete certificate chain.
The remote certificate can also be installed locally or exported to a file. This makes client access to labs and self-signed certificates much easier to setup.

4. Easily Retrieve Important Client-Side Troubleshooting Information.

Important client-side environment settings such as O/S version, 32-bit or 64-bit, current domain credentials, and Lync/Communicator sign-on settings are automatically retrieved and consolidated in one place.
Recent Lync and Communicator specific event log errors and warnings can be retrieved with one-click.

Screenshots

DNS Information

Certificate Functionality

Client Troubleshooting

I hope this tool is a big help to people troubleshooting Lync Server and OCS issues. Feel free to provide any feedback.

Communicator & Lync Sign-In Troubleshooting Tool (Version 3)

Curtis Johnstone — Tue, 19 Jul 2011 15:30:52 +0000

A major upgrade is now available to my popular OCS and Lync Sign-In Troubleshooting Tool. This is a small free tool to help troubleshoot client-side Communicator, and now Lync, sign-in issues (see The OCS 2007 Automatic Sign-In Troubleshooting Tool V2.0 for more information on previous releases).

A major upgrade is now available to my popular OCS and Lync Sign-In Troubleshooting Tool. This is a small free tool to help troubleshoot client-side Communicator and Lync sign-in issues (see The OCS 2007 Automatic Sign-In Troubleshooting Tool V2.0 for more information on previous releases).

In addition to several bug fixes, Version 3 of the tool now supports remotely retrieving certificate information from the TLS port on the OCS or Lync server where the client will connect (based on the matching returned DNS records). This will be a major help when trying to debug sign-in issues.

You can read more about the tool and download it here: http://www.insideocs.com/tools/MOCLogin.htm

Here is a screenshot of the main screen:

Here is a screen shot of the certificate information that is retrieved remotely, including the Common Name (CN), Subject Name, Issuer, Certificate Authority, Expiry Date, Creation Date, and Subject Alternative Names (SANs):

Thanks to all the users who have reported bugs. Retrieving the installed version of Lync or Communicator now works on x64 along with a few other issues.

Microsoft Office Communications Server Remote Connectivity Analyzer

Curtis Johnstone — Tue, 25 Aug 2009 15:20:50 +0000

Microsoft has recently made available a Beta version of a web tool that can be used to test the external connectivty of your OCS Edge deployment: https://www.testocsconnectivity.com/.

You can choose to manually enter your Edge Access hostname and port (normally 443), or by using auto-discovery (via DNS records). The auto-discovery option is good because it inherently tests that the correct external DNS entries exists which allow remote clients to automatically logon.

You need to provide a valid SIP user and password to the test the external SIP login through the Edge. Testing the complete login process is beneficial because the SSL Certificate configuration is validated.

Here is the results of a sample test run (domains and user details ommitted):

Attempting to Resolve the host name lcs.example.com in DNS.
Host successfully Resolved
Additional Details: IP(s) returned: xxx.xxx.xxx.xx

Testing TCP Port 443 on host lcs.example.com to ensure it is listening/open.
The port was opened successfully.

Testing SSLCertificate for validity.
The certificate passed all validation requirements.validation checks.
Additional Details: Subject: CN=lcs.example.com, OU=example, O=”Example, Inc.”, L=Example City, S=Example State, C=Example country, Issuer CN=, OU=, O=, C=

Testing OCS remote sign in through Access Edge Server: Port Number (lcs.example.com:443), for SignInAddress (exampe_user@example.com).
The specified user successfully signed in remotely through the Access Edge Server.
Additional Details: Registration is successfully completed.

The OCS 2007 Automatic Sign-In Troubleshooting Tool V2.0

Curtis Johnstone — Wed, 29 Jul 2009 20:02:51 +0000

I released a small free troubleshooting tool back in October 2008 to help diagnose Communicator automatic sign-in issues. It queries all the possible DNS records that Communicator could use to connect to the OCS server, and displays all the associated matches on the client computer.

I have made some significant improvements based on feedback and rolled it up into Version 2.0. Here are the improvements:

The preferred DNS match (that Communicator will first attempt to use) is highlighted in the results.
The type of DNS record that matched (e.g. SRV or A record) is displayed in the results.
The availability of the Port associated with any DNS match can be tested with a single-click.
Provides a warning if the record being used is TLS and the SIP domain does not match the FQDN of the OCS server/pool.
The installed version of the Office Communicator client is shown (if one is installed).

Free Download & Additional Details: http://www.insideocs.com/tools/MOCLogin.htm

Here is a screenshot of version 2.0

For more information about the Communicator Automatic Sign-In process, see my other blog postings:

Troubleshooting Microsoft Office Communicator Issues 101

Curtis Johnstone — Fri, 05 Jun 2009 16:03:06 +0000

Much has been written about troubleshooting Microsoft Office Communicator issues. In this blog entry I wanted to highlight and simplify two steps that will help you catch most problems without having to do more time consuming troubleshooting.

1) Know Which DNS Records are Being Used by Communicator

Communicator relies heavily on DNS to figure out which OCS server to connect to. Knowing how Communicator uses DNS, and what DNS records are being returned with the client DNS settings, is the key to debugging most issues.

My previous post, DNS Records and Office Communicator Automatic Client Sign-In, summarizes how Communicator uses DNS to connect to the server.

My Automatic Sign-In Troubleshooting Tool will query the local client DNS for all the DNS records Communicator might use, and display which ones match.

Knowing what DNS records are being used and which server Communicator is connecting to will help you understand the logging files in the next step.

2) Turn on and Use Communicator Logging

a) Turn on Communicator Event Logging (Options | General | Turn on Windows Event logging for Communicator)

This will produce explicit Application event log entries for any issues Communicator is experiencing. For example: “Communicator could not connect securely to server sip.example.com because the certificate presented by the server did not match the expected hostname (sip.example.com)”. There may be additional Informational or Warning log entries that provide additional context.

b) Turn on regular Communicator Logging (Options | General | Turn on logging in Communicator)

This generates a debugging log file in %userprofile%/Tracing (e.g. the filename will look something like “Communicator-uccapi-0.iccapilog”). This log file will give specific details about what Communicator is doing internally. For example, we can clearly see in this log file there is a DNS hostname lookup failure:

06/05/2009|10:26:45.553 700:EE8 INFO :: QueryDNSSrv – DNS Name[_sipinternaltls._tcp.example.com]
06/05/2009|10:26:45.563 700:FAC INFO :: domainName:quest.com: serviceName:sip: transportName:tls:
06/05/2009|10:26:45.563 700:EE8 ERROR :: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.example.com failed 9
06/05/2009|10:26:45.563 700:EE8 ERROR :: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b

(Note this file can be opened in Notepad even though it does not have a .txt file extension).

Taking these first steps will go a long way in understanding how Communicator is behaving.

The Microsoft TechNet Library has a more good information on troubleshooting specific Communicator R2 Features: http://technet.microsoft.com/en-us/library/bb963945.aspx.

Finally, if you are troubleshooting an issue with Communicator R2, take advantage of the built-in diagnostic information. See the previous post regarding the ”Great New Office Communicator R2 Troubleshooting Feature” for more information.

Update to the OCS 2007 Automatic Sign-In Troubleshooting Tool

Curtis Johnstone — Tue, 27 Jan 2009 17:21:53 +0000

For all those using my OCS 2007 Automatic Sign-In Troubleshooting Tool, I’ve made a couple of minor improvements. The latest version can be downloaded here: http://www.insideocs.com/tools/MOCLogin.htm There are some usability improvements including the ability to copy the results to the clipboard.

Thanks to all those providing feedback.

Automatic Office Communicator Sign-In (Part 2 – ensuring the correct Subject Name on the Certificate)

Curtis Johnstone — Sun, 14 Sep 2008 04:00:24 +0000

A crucial setting to make automatic Office Communicator sign-in work is ensuring that the correct Subject Name (and possibly Subject Alternative Name) is specified on the certificate which resides on the OCS server where the Communicator client connects (e.g. on the Front-End or Director role). When you look at the Certificate details, the Subject Name is listed as the “Subject” property.

The basic requirement for the Subject Name on the certificate is that it match the DNS FQDN of the hostname that the client is connecting to. For example, if Office Communicator determines that it needs to connect to the FQDN host1.example.com, the Subject Name on the certificate should be host1.example.com.

Note: the actual requirement is that the Common Name (CN) portion of the Subject Name matches the DNS FQDN, but many documents use Subject Name and Common Name interchangably (the Common Name is just the CN portion of the SN).

Certificates also have one or more Subject Alternative Names (SANs) which specify alternate hostname(s) that the host can be known as. Generally speaking, if the correct FQDN does not match the SN, but is listed as one of the SANs, the certificate naming requirement will be satisfied. For OCS clients connecting to an Enterprise pool, the pool name must be the Subject Name.

The primary use for this certificate check is for security purposes. It allows the client to be sure that the server it wants to connect to is indeed that server. Think of a server certificate as a passport for that server – it validates its identity to all the clients that use it.

Two factors can make setting the proper SN confusing:

Using OCS 2007 Standard Edition vs. Enterprise.
Use of a Director (between the client and OCS 2007 server).

As a general rule, the Subject Name of the certificate should match the fully qualified hostname of the first OCS server the client connects to. If it is an enterprise edition deployment, the Subject Name should be the FQDN of the enterprise pool.

FYI – Hardware Load Balancers (HLBs) do not affect the SN on the certificate. HLBs just pass the connection through to the OCS server.

The following table summarizes the Subject Name requirement on the certificate for different OCS deployments:

Situation	With Director	With HLB	Certificate Subject Name (SN/CN)
Standard Edition Server			Front-End FQDN
Standard Edition Server	Yes		Director FQDN
Consolidated Enterprise Pool			Pool FQDN
	Yes		Director FQDN
		Yes	Pool FQDN
Expanded Enterprise Pool		Yes	Pool FQDN
	Yes		Director FQDN
	Yes	Yes	Director FQDN

Note: For an Enterprise Pool, the Subject Alternative Name (SAN) should include a entry for each supported SIP domain in the format sip. if you selected either of these options when creating the pool with the Configure Pool Wizard: 1) Configure Clients for Automatic Sign-In, or 2) Configure this pool to redirect sign-in requests. If you have multiple SIP domains and use the OCS certificate wizard, it will automatically add “sip.domain.com” to the SAN for all supported SIP domains.

In August 2009, Microsoft released an excellent white paper clearly describing the certificate requirements for OCS: Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2 (the link refers to a collection of OCS documentation – scroll down to find the ”OCS 2007 R2 Deploying Certificates.doc“).

InsideOCS has a free download tool (the Automatic Sign-In Troubleshooting Tool) that will query for all of the automatic sign-in DNS records and show which ones exist, and which one will be used.

For more details all the automatic sign-in process and it’s requirements, see:

Automatic Office Communicator Sign-In (Part 1 – The Correct DNS Service Location (SRV) Record)

Curtis Johnstone — Thu, 28 Aug 2008 03:46:33 +0000

Three items are key for automatic Office Communicator sign-in to work in an OCS 2007 environment:

Specifying the correct FQDN in DNS for the SRV record used for automatic sign-in.
Ensuring the correct Subject Name (and possibly Subject Alternative Names) are specified on the OCS certificate where the client connects (e.g. the certificate on the Front-End or Director role).
Ensuring that the Certificate Authority that issued the certificate is trusted by the client.

In my experience, Office Communicator sign-in issues are usually caused by one of these settings not being correct.

I’ll explore each of these requirements in seperate blog posts. I’ll start now with the first: specifying the correct FQDN in DNS for the SRV record.

At a high-level, when an Office Communicator client is configured for automatic sign-in, it goes through the following steps to obtain an IP address to connect to:

A query is made to DNS (against the DNS server configured on the Windows client) for an SRV record associated with the SIP domain of the SIP address for the user attempting to sign-in. The SRV record must be of a particular format. See my previous blog post on what the format of the DNS record should be. The SIP domain is the right-hand-side of the user’s SIP address (e.g. example.com for the SIP address user@example.com).
The successful DNS query returns two key pieces of information: a fully-qualified domain name (FQDN) and a Port.
The client then does a DNS A record lookup on the FQDN to get an IP address associated with the FQDN.
The Communicator client attempts a connection to the IP address and Port.

Note: if the Communicator client is not configured for automatic sign-in, it just uses the DNS A record for the FQDN (or hostname) configured directly in the client. Also, if no SRV records are found, Communicator tries several DNS host (A record) lookups (see my previous blog post for the specific formats).

What FQDN should be listed for the DNS SRV record? Depending on your environment, this could be the FQDN of an OCS Front-End, a Director, or the Virtual IP (VIP) of a load balancer. The table below answers the most common scenarios.

TABLE 1: WHAT SHOULD THE AUTOMATIC SIGN-IN DNS SRV RECORD POINT TO?

Pool Type	With Director	With HLB	DNS SRV FQDN	DNS (A) Record
Standard Edition Server			Front-End Server	IP of Front-End
“”	YES		Director	IP of Director
Consolidated Enterprise Pool			Pool	IP of Front-End in Pool
“”	YES		Director (1)	IP of Director
“”		YES	Pool	Internal VIP of HLB
Expanded Enterprise Pool		YES	Pool	Internal VIP of HLB
“”	YES		Director (1)	IP of Director
“”	YES	YES	Director (1)	IP of Director

Notes:

(1) HLB = Hardware Load Balancer

(2) If the Director is a Standard Edition, the FQDN is the FQDN of Standard Edition Server. If the Director is an Enterprise Edition, the FQDN will be the FQDN of the Pool associated with the Director.

(3) If you have multipe SIP domains in your environment, you require a DNS SRV record for each one.

InsideOCS has a free download tool (the Automatic Sign-In Troubleshooting Tool) that will query for all of the automatic sign-in DNS records and show which ones exist, and which one will be used.

For more details all the automatic sign-in process and it’s requirements, see:

Also, Page 65 of the Microsoft Office Communications Server 2007 Planning Guide details the DNS SRV requirements for automatic client sign-in.

Byron Spurlok has a good post with more details on how to create these DNS records on your DNS server.

DNS Records and Office Communicator Automatic Client Sign-In

Curtis Johnstone — Tue, 19 Aug 2008 19:12:03 +0000

Office Communicator client signs into OCS in one of two ways:

1) The OCS server hostname is manually specified in Communicator, or,
2) “Automatic Sign-In” via a DNS query on the SIP domain (the domain portion of the user’s SIP address) which returns the OCS server (or pool).

This is true for clients running both inside and outside your internal network (’outside’ meaning outside the firewall, on the Internet).

The DNS records for automatic sign-in are always front-and-centre when trouble-shooting any Communicator sign-in issues, so I’ll recap the format of the DNS SRV records most commonly needed:

_sipinternaltls._tcp. (Internal TLS)
_sipinternal._tcp. (Internal TCP)
_sip._tls. (External TLS)
_sip._tcp. (External TCP *)

From a DNS sign-in perspective, Communicator does not know or care whether it is on an internal or external network – it queries for the DNS SRV records in the order listed above, and will attempt a connection on the first match (the hostname specified by the SRV record).

* Although Communicator will search for the external TCP SRV record of the format “sip._tcp.” external connections must use TLS (on the Edge Access).

The DNS SRV record returns a hostname representing the OCS Enterprise Pool or Standard Server. A DNS A record lookup is then performed to get an IP address to connect to.

If no records DNS SRV records are found, Office Communicator performs an explicit DNS A record lookup up in the following order (until it gets a successful match):

5. sipinternal.
6. sip.
7. sipexternal.

Note: In the Communicator R2 client, it appears that the format “sip.” (#6 above) is tried before “sipinternal.”, and #7 is not attempted at all.

InsideOCS has a free downloadable tool, the Automatic Sign-In Troubleshooting Tool, that will query for all of the automatic sign-in DNS records and show which ones exist, and which one will be used.

For more details all the automatic sign-in process and it’s requirements, see:

Note: the manual configuration of Office Communicator clients can be automated through the Microsoft Office Communicator Group Policy.

For additional information, see the following links: