I recently started a new project whereby we are upgrading an OCS 2007 R1 installation to OCS 2007 R2. On our first day of planning the client was hosting a kickoff meeting using Microsoft Office Live Meeting. I was at the client site with my laptop connected to their internal network but could not join their Live Meeting. I would get the classic error:
This seemed strange to the client as they had regularly hosted external participants given they had a full blown Edge server deployment and allowed Anonymous participants.
After the meeting I did some further investigation by enabling verbose tracing in the Live Meeting client. The Application Event Log is no help in this circumstance so you need to enable verbose logging in Live Meeting as this isn’t done by default. To do this I created the following two entries:
HKEY_CURRENT_USER\Software\Microsoft\Tracing\uccp\ LiveMeeting]
"EnableFileTracing"= DWORD:00000001
"Tracing"= DWORD:00000001
After re-attempting to join the meeting and getting the error a log file is created in the %TEMP% folder. Look for the latest pwconsole-debugNN (where NN is some number)
There is a lot of info generated but after combing through it I found the following:
[MC] 18:21:17:785 GMT [PID 10700] [THREAD 9576] [E] [X-PSOM] caught std::exception: Unable to resolve host name: web.mycompany.com
Boom – It then immediately was clear that this organization had not published their OCS Edge FQDN’s within the internal DNS. A quick ping test confirmed this host was unknown. After determining what the Edge FQDN for web conferencing was, I hardcoded into my host file and we tested again. This time I was able to join the meeting!
Some may think that this scenario is obscure and likely not to affect them since their customer and vendors would connect from outside the corporate firewall. However, in larger organizations it is quite common for vendors and customers to meet together onsite. I often have vendors onsite and vice versa. In this case I was onsite and was attempting to join a Live Meeting anonymously for which I needed to be authenticated by their Web Conferencing Access Edge Server. I could not reach it hence the error I received. The server was reachable to me via IP but only once I hardcoded the hostname locally. This obviously would not affect internal users since they would authenticate directly against their OCS FE server they were signing onto.
DNS is critical to OCS deployments. Careful consideration is required when planning for publishing the required records to support all the use case scenarios in your OCS environment.
Comments