During the past few months I’ve had a number of calls to troubleshoot Live Meeting connectivity issues, then earlier this week I worked with someone on the MSDN forums on the same topic. In most cases lately the issues have actually been DNS related, but I’ve also seen firewall and configuration issues cause this. The one common thing I see is most folks don’t know where to begin in troubleshooting their issues. Since this is a common issue, and something I’ve seen a number of search queries lead people to my site on, I thought it would be appropriate to share a few things I do when troubleshooting Live Meeting. Please keep in mind, the things I’m sharing are things that have helped me correct issues, there may be better ways to troubleshoot out there, if you know of one I’d encourage you to share.
Now on to the fun, to troubleshoot Live Meeting, I typically start out by turning on logging in the registry on my machine, you can do that here:
HKEY_Current_User\Software\Microsoft\Tracing\uccp\LiveMeeting
You’ll want to change the Reg_Dword to 1 as below
Now you attempt to join the meeting, after it fails you’ll go to %userprofile%\tracing on your local machine. There will be a file named “LiveMeeting-uccp-0.uccplog”, you can open this file with notepad, or snooper. I prefer to read these with notepad, but to each his own J.
There will be a lot of information in the log, so typically I start by searching for the word “fail”. That typically gets me to a good starting point, here’s what I saw in my most recent case:
10/05/2009|12:55:07.435 66C:E30 ERROR :: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.ocsguy.com failed 0
10/05/2009|12:55:07.435 66C:E30 ERROR :: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
10/05/2009|12:55:07.435 66C:E30 INFO :: QueryDNSSrv – DNS Name[_sip._tls.ocsguy.com]
10/05/2009|12:55:07.435 66C:1240 INFO :: CUccDnsQuery::UpdateLookup – error code=80ee0066, index=0
10/05/2009|12:55:07.435 66C:1240 INFO :: CUccDnsQuery::CompleteLookup – index=0
10/05/2009|12:55:07.515 66C:E30 ERROR :: QueryDNSSrv GetDnsResults query: _sip._tls.ocsguy.com failed 0
10/05/2009|12:55:07.515 66C:E30 ERROR :: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
10/05/2009|12:55:07.515 66C:E30 INFO :: QueryDNSSrv – DNS Name[_sipinternal._tcp.ocsguy.com]
10/05/2009|12:55:07.515 66C:1240 INFO :: CUccDnsQuery::UpdateLookup – error code=80ee0066, index=1
10/05/2009|12:55:07.515 66C:1240 INFO :: CUccDnsQuery::CompleteLookup – index=1
10/05/2009|12:55:07.595 66C:E30 ERROR :: QueryDNSSrv GetDnsResults query: _sipinternal._tcp.ocsguy.com failed 0
10/05/2009|12:55:07.595 66C:E30 ERROR :: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
10/05/2009|12:55:07.595 66C:E30 INFO :: QueryDNSSrv – DNS Name[_sip._tcp.ocsguy.com]
10/05/2009|12:55:07.595 66C:1240 INFO :: CUccDnsQuery::UpdateLookup – error code=80ee0066, index=2
10/05/2009|12:55:07.595 66C:1240 INFO :: CUccDnsQuery::CompleteLookup – index=2
10/05/2009|12:55:07.665 66C:E30 ERROR :: QueryDNSSrv GetDnsResults query: _sip._tcp.ocsguy.com failed 0
10/05/2009|12:55:07.665 66C:E30 ERROR :: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
10/05/2009|12:55:07.675 66C:1240 INFO :: CUccDnsQuery::UpdateLookup – error code=80ee0066, index=3
10/05/2009|12:55:07.675 66C:1240 INFO :: CUccDnsQuery::CompleteLookup – index=3
10/05/2009|12:55:07.675 66C:1240 INFO :: Function: CUccServerEndpoint::OnDnsQueryCompleted
10/05/2009|12:55:07.675 66C:1240 ERROR :: HRESULT API failed: 80ee0066 = hrStatus. CUccDnsQuery::GetResults
10/05/2009|12:55:07.675 66C:1240 INFO :: CUccServerEndpoint::GetSipProviderProfile – Found no http proxy creds
10/05/2009|12:55:07.675 66C:1240 TRACE :: CUccServerEndpoint::UpdateEndpointState – Update state from 1 to 2. Status 0. Status text (null).
10/05/2009|12:55:07.675 66C:1240 TRACE :: New mpss created: 00266848, stack=002C77F8, 0
10/05/2009|12:55:07.675 66C:1240 INFO :: MSP.SetMultipartySsnRole[00266848] 0->0
10/05/2009|12:55:07.675 66C:1240 TRACE :: MULTIPARTY_SESSION::SetConnectParams[00266848] n=Kevin P – OCSGuy, uri=sip:FA09EF31-17B1-4BBD-9106-E58DB95ECD9E@anonymous.invalid
10/05/2009|12:55:07.685 66C:1240 TRACE :: MULTIPARTY_SESSION::AddParty – Enter participant: sip:richl@ocsguy.com;gruu;opaque=app:conf:focus:id:81338d3f5f1447aca1082e4cb5347678, this=sip:FA09EF31-17B1-4BBD-9106-E58DB95ECD9E@anonymous.invalid, RM=(null)
Although it looks like a lot of information (and it is), the important thing we see in this case is:
ResolveHostName failed
Keep in mind it is ok to see a few of these, the live meeting client is looking up a number of different SRV records at once to see what is out there, and if it finds one it will use it. It’s when all of them fail that there is a problem.
Now that we see a DNS problem I want to share a common saying around our office (and maybe elsewhere) is: “If your car won’t start its DNS”. It’s a funny saying, but it’s something that has stuck with me since I first heard it around 4 years ago. Troubleshooting anything really just needs to begin with the question of can I connect to it, and can I resolve its name. As I know I can’t resolve it from my DNS servers, I’ll start by checking the authoritative servers for that domain.
Here are the commands I used to do this starting from a command prompt:
NSLookup
Server 4.2.2.1
Set Type=NS
Ocsguy.com
This brings back a list of authoritative name servers for the domain, should look like this:
Now we can set our name servers as one of the authoritative servers for the domain, that way we know we’re getting the correct answer when we query:
After querying I found that none of the expected SRV records actually existed for the domain, once the records were created everything worked like a charm.
They certainly aren’t all that easy, but I think this is a good starting point.
Now for some useful links:
http://support.microsoft.com/kb/200525 – article on how to use NSLookup
http://www.microsoft.com/downloads/details.aspx?FamilyID=149e5dd5-eaae-46b6-afba-01c31e88a275 – Edge Server Planning Tool
http://www.microsoft.com/downloads/details.aspx?FamilyID=06793661-CD69-4490-BB4B-E97DD271209D&displaylang=en – OCS Planning Tool
Hope this helps, feel free to comment back with links to other blogs you find useful or tips on how you do it.
Pingback: One way messages with federated partner and ID 504 in Communicator « The OCS Guy's Blog