General Information
I just migrated a OCS 2007 R2 Edge on Windows Server 2008 last night to Lync Edge 2010 Edge on Windows 2008 R2. All I can say is, it was a less than pleasant experience if you’re doing federation. This is not a native Lync problem per se, but is more due to Windows 2008 R2; of course, this depends on your Outlook.
The migration process to migrate an OCS 2007 R1 Edge to Lync 2010 Edge is documented at the following URL:
https://technet.microsoft.com/en-us/library/gg425785.aspx
The migration process to migrate an OCS 2007 R2 Edge to Lync 2010 Edge is documented at the following URL:
https://technet.microsoft.com/en-us/library/gg398413.aspx
Note: The migration steps are in different locations. The R2 migration documentation has you migrating federation and Media at the same time as an R2 Edge can do media for a Lync Pool. The R1 migration documentation has you configuring Lync to use Lync Edge for Media while R1 Pool uses R1 Edge as an R1 Edge cannot do media for a Lync Pool. Then, at a later time after all pools have been migrated, you cut over federation.
The Issue
The general issue is that Windows 2008 R2 has much fewer root certificates installed than does a Windows 2008 or previous operating system version. In fact, Windows 2003 even has many more root certificates than Windows 2008. This doesn’t seem like a good trend going forward. Let’s take a look at a comparison between Windows 2003, Windows 2008, and Windows 2008 R2:
Windows 2003
Windows 2008
Windows 2008 R2
You can see, the amount of root certs has gone down drastically. Now the problem is that when doing federated communication from our Lync 2010 Edge Server to other partners, the communication will occur using TLS. This means the federated partner needs to contain the root certificate for our external edge certs and our Lync Edge needs to contain the root certificate for our federated partner’s external edge certs. As you can see, Windows 2008 R2 doesn’t contain many root certs so this presents more risk for federated communication failures. And… this is exactly what we saw.
What we actually saw is many of the following errors for many different federated organizations:
As we can see, we’re missing the root certs to communicate properly with our federated partners. What to do? Well… the solution is actually relatively simple.
Open up one MMC console but add 2 certificate snap-ins. One is local on the Lync 2010 Windows 2008 R2 Edge and one is remotely connected to either a Windows 2003 or a Windows 2008 Server. From the Remote 2008 or 2003 box, in the Trusted Root Certification Store, copy root certs (don’t cut as you still need them on the remotely connected machine) and paste into the Trusted Root Certificate Authorities store on your Lync 2010 Windows 2008 R2 Edge Server.
Afterwards, you will now have a Lync 2010 Windows 2008 R2 with the proper Trusted Root certificates in order to negotiated TLS with your federated partners. One thing to keep in mind, you may still be missing a root cert after doing this. You can still monitor 14428 event entries on your Lync 2010 Server 2008 R2 Edge and see what certificate vendor they are using. Then go hunt down that root certificate on either a Windows 2008, Windows 2003 Server, or via the CA vendor’s website.
So, here's how I fixed mine. THANKS TO YOUR BLOG … i was trying to federate to a customer … but I was getting this error in the event log. So, clearly, I am missing something in the chain … so, I found an SSL site that they used off of their public website … just poked around until I found one … like … "https://portal.whatever.com" … and I found that this particular customer was using ensign certs … I exported the chain individually and imported into trusted root … I didn't just copy all of them from an old 2k3 or non-r2 server …
That's generally for federating with new companies. The article is specific to migrating to Lync which means your old OCS 2007 R1/R2 Server was already working with the previous company which means the previous server already had all the proper certificates that you'd need. If you federate with a new company and you run into this, you're always going to have to go hunt for their certificate.
http://social.technet.microsoft.com/wiki/contents…
"When you open Trusted Root CAs container on Windows XP/Windows Server 2003 you will see a lot of certificates. When you open this container on Windows Vista and newer operating system — only few common trusted root CA certificates are shown. However this doesn't mean that only displayed certificates are trusted. Trusted root CA list is approximately the same (comparing with Windows XP/Windows Server 2003), but rarely usable certificates are stored in the crypt32.dll file and on Microsoft Update web site."
You can try using http://support.microsoft.com/kb/931125 I know it says that its designed for XP, but it does work on Servers… in fact, MS recommends using it in disconnected environments.
This will install the full base set of Trusted Roots.
I'm experiencing this issue as well, but I'm the party not trusted despite using a cert signed by an approved root. It's impractical to try and get my partners to load my cert when we use open federation. I even opened a ticket with MSFT and they basically said "get them to load your cert".
I've also run across this with federated partners, but another thing to watch out for is adding too many certificates back into the Windows Server store could lead to some client connection issues, specifically Lync Phone Edition clients. Mike Stacy blogged on this a while back as well for OCS: http://mikestacy.typepad.com/mike-stacys-blog/200…
Hi Elan,
Nice article. Do you know a way to actually work out which root certificate is missing? That is what I am after.
For example, I am getting a 14428 error for one of our federation partners. I assume they purchased a new certificate and it is probably issued by a root authority that my server does not trust. I would like to be able to fix this without needing to contact anybody else.
I know we don't trust their certificate (due to the 14428 errors) and I know what their server name is. What I don't know is a way to "view" their certificate so that I can work out which root certificate I need to add to my own store. Do you know a way to do this?
Thanks,
David
Can probably try https:// to their Edge FQDN. The Event Log errors should tell you what certificate vendor they are using though. That's how I resolved my issues.
Would seem appropriate for MS to provide a key list for Lync environments. I've been seeing the same issue as @ed on our OCS2007R2 on Win 2008 R1 servers. Painful to figure out which Root Cert is missing, and adding cart blance is kinda excessive, but probably donesn't hurt anything right…
This article was useful.
Thanks
I'm experiencing the same symptoms, but my Server 2008 computers have less trusted root CAs than do my 2008 R2 servers, actually. I used a Windows 7 workstation instead and was able to import a lot of additional root CAs. I'll monitor my Edge servers for more of these errors.
Thanks!