LCS/OCS PIC: Provider details and troubleshooting
For those of you that have deployed LCS/OCS and are now working on your PIC (Public Internet Connectivity) setup, you may want to know what we will be asking you to provide for a reported problem. We are still working on this information so you might see it change based on input from us and the 3 clouds. Do keep in mind that our troubleshooting of these issues is never real time, meaning we don't get an AOL/MSN/Yahoo! engineer on the phone with us when you call. This will be a fact gathering situation for which we will ensure your LCS setup is configured correctly and confirm that the issue appears to be with the cloud itself.
Addition February 4, 2008
- Yahoo! does not support PIC for global domains, for example: yahoo.cn, yahoo.au
- GoDaddy - This issue has been resolved, https://blogs.technet.com/toml/archive/2007/03/26/pic-godaddy-certs.aspx
This is not specific to GoDaddy but simply the first provider we experienced this with. The GoDaddy Trusted CA has become very popular since Windows Server 2003 released and as such it was not in the default trusted providers list for the released operating system. It has since been included in the latest list of approved/trusted authorities however none of the clouds had this provider
Addition January 15, 2007
- AOL requires Client and Server Authentication in the Enhanced Key Usage Field
- PIC partners do not support trial certificates
- Certificate must be 128bit
Please forgive the odd numbering but this site supports very limited formatting. Likely some custom html might solve it but I admit to being a novice.
- Description of problem. Please be specific with the description and, if applicable, list a step by step repro of the problem
- Has it ever worked?
- If it was working, when did it stop working?
- Was there any network, DNS, certificate, or other server configuration change made on the customer's side?
- Customer's Business name:
- Customer's federated domain(s) (eg. sample.com):
- FQDN of customer's Access Proxy (eg. Access Proxy.sample.com):
- Date when federation was enabled for customer:
- A contact from customer (name and contact info):
- A customer's LCS user email address that we can add to the AOL/MSN/Yahoo! client, for troubleshooting purposes:
- If customer's Access Proxy servers are behind firewall:
- Verify that the Firewall's outbound rules allow tcp/5061 traffic from customer's Access Proxy (tracert) servers to
- federation.messenger.msn.com 65.54.227.249
- sip.oscar.aol.com (205.188.153.55)
- lcsap.msg.yahoo.com (216.155.207.212)
- Verify that the Firewall’s inbound rules allow tcp/5061 traffic from
- both federation.messenger.msn.com (65.54.227.249) and MSN Access Proxy servers (IP range 65.54.227.13 through 65.54.227.30) to the IP address of customer's Access Proxy (determined from step 7 above).
- sip.oscar.aol.com (205.188.153.55)
- lcsap.msg.yahoo.com (216.155.207.[196-249]
- Does federation work with any of the PIC providers (AOL/MSN/Yahoo!)?
- Results of LCSDiag (TCP/TLS Connectivity test) or LCSPing (lcsping /s:<fqdn>) from customer's Access Proxy servers [Success or Fail]:
- federation.messenger.msn.com
- sip.oscar.aol.com
- lcsap.msg.yahoo.com
Lcssiplog (Logging tab on server properties level 4) for the reproduced problem from customer's Access Proxy servers. (Remember to force rollover on Logging tab to flush log to disk.
What else has been done to troubleshoot this issue?
I do hope that this helps you with narrowing the scope of your problem down and possibly identifying the cause of the problem without requiring a call to us.
TOML LCSKid