Lync and Mavericks Integration

I got it to work to things that were key for me.

Its pulling your contacts from your default mail server so if you using outlook Mac 2011 go into outlook preferences and make it your default mail server. otherwise its trying to sync with mac mail by default. Second thing I did was from advice above. which was clear out old cache info from both lync and outlook. Worked like a charm.

Quit Outlook 2011, if Open. This is supposed to rebuild those files you need.
Navigate to ~/Library/Caches/Outlook/Main Identity/#
(the "#" is a number, depending on how many identities you have created)
Move the # folder to the trash
Restart Outlook and let the new data download.
Also, quit Lync, remove:
~/Library/Caches/com.microsoft.Lync/

I am currently on Lync 2011 14.0.9. I am operating about 50 Mavericks 10.9.3 in a mostly-Windows Active Directory environment (2008), with over 35,000 Windows 7 clients that all use Lync 2013 for PC.

I ran into this crashing issue, shortly after upgrading to Maverick. Lync would load, start to populate the user list and then throw up the EXC_BAD_ACCESS error. after trying all of the above without success, I stumbled on a solution to the problem that was one of the craziest moments I've had in my 5-year make-a-mac-work-in-a-PC-world experience, let alone 15 years of Windows client and server experience. Ready?

I created a custom DMG that has two scripts utilizing cocaoDialog for receiving technician input. The first creates the system name, host name, etc (of which I lovingly used from the forums here) that uses dsconfigad (the command that joins the system to AD). The second asks for specifics on user ID and email address info specific to the targeted user, installs our corporate certificates, and installs and configures a list of various applications.

As most don't know, "dsconfigad -namspace [forest | domain]" handles how the system will create the locally stored mobile profile when logging in to the Mac. If the mobile account storage set to allow mobile profile access, set to store the profile locally, and the AD “namespace” is set to forest, it creates the locally stored profile with a folder name that contains a backslash like this: /Users/MYDOMAINNAME01FLast12. Microsoft Office is written in code from Windows, thus it pukes when it tries to access a home folder with a backslash. Since OS X is Unix based, it uses forward slashes to signify folder separations. You are supposed to signify apps to use the context /Users/MYDOMAINNAME01FLast12 to call a folder from an application (Double backslash would show a single backslash when calling it as a character within the folder's string name). This setting also facilitates whether to log into the system using the context FLast12 or MYDOMAINNAME01FLast12. Here is the blurb straight out of the dsconfigad man page:

-namespace forest | domain Sets the primary account username naming convention. By default it is set to "domain" naming which assumes no conflicting user accounts across all domains. If your Active Directory for-est forest est has conflicts setting this to "forest" will prefix all usernames with "DOMAIN" to ensure unique naming between domains (e.g., "ADDOMAINuser1"). Warning: this will change the pri-mary primary mary name of the user for all logins. Changing this setting on an existing system will cause any existing homes to be unused on the local machine.

The problem was that I had it set to forest, when I created the first of the two scripts, and it slipped through the cracks until we ran into this Lync 2011 crashing issue, and also now a rogue issue that one cannot save files in Excel due to the same reason. (Excel launches fine, but try to save anything and it won’t let you.)

I have tested and confirmed that changing "dsconfigad -namespace domain” will prevent any further issues. adjusted the first script in my custom DMG and was a very easy change. We will also have to update the documentation to not call for SAFEWAY01FLast12 as the login context after running the last script. It will now be just like logging into our Windows domain: FLast12

As for the existing, already upgraded systems: if they were upgraded directly from 10.7 or 10.8 to 10.9.3, they wouldn’t experiencing these problems, but still need to have the AD settings changed so future new AD profiles that are logged onto the system are configured properly. Also, in-place upgrades will use the existing local AD profile folder from 10.7 or 10.8 as /Users/FLast12, so no changes will be necessary since it kept the correct standard of the username as the profile's home directory.

I trust this benefit someone else out there!