I hit a particularly funky snag this last two weeks with a client deployment.
Previously on the PABX users had speed dials for people’s cellphone numbers etc, to elleviate the pain of pin codes and such whilst dialing mobile numbers. In an effort to not have to program 3000 speed dials into the lync deployment via normalisation rules I suggested we import these to the actual user’s details on AD. The client agreed and liked the idea and put someone to task to match the 600 users deployed on lync to their employee numbers and contact details from the HR database.
9 November 2011:
With slight of hand and a quick excel/notepad CSV session 600 contacts went flying into AD without any issues
10 November 2011:
Within a day I received a rather stressed phone call from the IT manager regarding an entire list of 600 user’s mobile numbers having been imported incorrectly. Aparently there was an issue with the lookup used and the list was completely wrong, no harm done, I thought and requested a new list. As luck would have it I received a rather stressed phone call on Saterday regarding a certain executive who could no longer dial anyone from his mobile phone, since all the numbers were wrong. Finding this extremely strange I quickly investigated the details in AD and Lync and confirmed that all the information was in fact correct. I was also mildly confused as to how a AD contact update had found it’s way into a person’s personal contacts and naturally from there, their mobile phone.
14 November 2011:
Monday morning I jumped into the issue after a few calls and noticed that I had left out the ABS normalisation rules, thus lync was not translating any of the AD contact information anyhow. A quick remote session with one of the parties involved onsite and demonstrating the process I quickly managed to demonstrate how the lync client was now reflecting the AD information. Once this was achieved I sat back and relaxed thinking that another problem was resolved without any major hiccups.
I received a rather concerning call from the IT manager onsite, claiming that the MD was in a remote location and was unable to dial anyone on their mobiles, since every time she did she got to some random person whom she did not know. Naturally realising the now extreme urgency of this issue I jumped in trying to determine how exactly it was possible for personal contacts in outlook to be updated when Lync ABS itself, could not translate this information prior to the correct import being done and the translation rules being setup on Monday.
OUTLOOK SOCIAL CONNECTOR!
A fine little feature of Outlook 2010 named the outlook social connector became the apparent troublemaker. A tool to synchronise and pull contact information from MSN and Facebook, also features a sync function running once every 4 days synchronising AD contact information with more recent time/date stamps to the user’s personal contacts! Whilst a nifty little feature when all of a sudden all your personal contacts from work start showing pictures in your contact list on your phone, not such a nice feature when all their mobile numbers are wrong!
Hitting the “update” button top right of an opened contact appeared to repair some of the contacts, however I managed to determine the following:
1. Contact Information updated manually post sync is not overwritten
2. Contacts are synced via email address, wrong address = no sync.
3. I created a blank contact for testing purposes which was fully populated by 10am the following day.
4. When a number is updated, ie, mobile 1 becomes mobile 2, the mobile 2 is moved to “other”, thus leaving both entries.
5. Once the contact information is updated in AD, the connector does not allways recognise the new information in AD as legit, and does not update the contact in outlook.
This little episode turned out to be rather scary. I managed to prove to the client that the ABS for Lync was in fact correct, and that any incorrect information was coming out of their personal contacts, to date I have not found a way to repair this, globally. I myself sat repairing one of the EXEC’s contacts via RDP AD contact detail comparison.
Closing Notes / Observations
1. My only suggestion here is to be cautious, have bulk import lists double and triple checked, explaining the potential disasters.
There are GPO’s which can manipulate the outlook social connector, in the office 14 management downloads, this can be used to disable all synchronisation of the connector, perhaps worth enabling for a week or so whilst doing bulk updates.
2. Strangely enough, Job Titles and Pager Numbers appeared to be synchronising across the board with no hiccups.
3. I also noticed that numerous contacts despite having the correct email address never synchronised automatically, a click of the “update” button in the contact view in outlook quickly retrieved additional contact information and AD photos, thus rendering the feature fairly unpredictable.
4. Setting the GPO for the social connector and changing the default 4 days sync to 1 minute causes outlook to crash, where this is required I would suggest 1 – 2 hrs as a better alternative.
5. Also perhaps worth mentioning, the bulk of my 9 November updates sync’d to the outlook clients on the day. The second import only started synchronising on the 14th ( Monday and after the weekend… )