It has been several months since I ran into this issue, but I heard a colleague was having a similar issue so I figured I should write it up.
What happened in my case is that I set up Federation between an OCS 2007 R2 environment at CompanyA and a Lync Server 2010 environment at CompanyB. I configured Federation from the CompanyA side and tested it with the engineers that configured Federation from the CompanyB side.
I went into Communicator and added the other people using their SIP address. For example, test.user@companyb.com. I immediately saw their presence and was able to IM them, join A/V conferences with them, and share desktops. It worked perfectly.
Later in the day, I received reports from others in CompanyA that they were not able to add users from CompanyB to their Communicator clients. Quick investigation showed that they had the proper permissions and they were putting in valid SIP addresses. When Communicator resolved the address, it showed the person’s name, but it didn’t show a presence bubble (jelly bean, skittle, whatever you want to call it) next to the name. Instead, Communicator showed the name and an icon that looks like an Active Directory contact icon next to the name.
After lots of testing and troubleshooting, we found that since I was working with the individuals at CompanyB, I had created contacts in Outlook for them. The other users in CompanyB did not have Outlook contacts, but somebody had created contacts for all of the users in CompanyB in AD and Exchange.
So, here is what I found:
1. If somebody had the person’s information in the Outlook contacts, it was possible to add them to the Communicator client without any issues by using their SIP address. For example, “test.user@companyb.com” would work fine.
2. If somebody had the person’s information in the suggested contacts in Outlook, it was possible to add them to the Communicator client without any issues. For example, “test.user@companyb.com” would work fine.
3. If the person’s information was not in the Outlook contacts (or suggested contacts), and there was a contact in AD/Exchange, it would resolve to the contact and not resolve properly over federation. In these cases, if the user prefixed the SIP address with “SIP:” when entering their address, it worked fine. For example, they would need to put in “SIP:test.user@companyb.com” and it worked perfectly.
This was an unusual situation, but it seems that it happens every now and then. I hope others get some use from this post.
