Lync and Mavericks Integration

[Jpcorzo]

I know this might not be the best place to find a solution to this but I wanted to see if any of you had experienced the same problem.

Lync 14.0.x is not creating/updating the GALContacts.db file so existing users won't update the address book automatically or new user won't even get an address book. Have any of you dealt with this yet? we have a case open with MSFT but haven't heard anything yet.

[bentoms]

@seabash & @mm2270, are we creating this will be a Lync 2011 fix & not something in Lync 2014?

Just curious as to the March date.

Also.. we have WebSearchAndFileDownload set, any ideas what differences we'll see client side if we implement There are three types of policies for reading address book: WebSearchOnly?

The macs are only 10% of the overall estate.. so i might have a hard time getting the change put through.. BUT Lync is becoming a key tool for us.

[seabash]

[ Sorry this is turning into a Microsoft support forum. I won't post about this for a whole week; my gift to you ;) ].

@bentoms][/url][/url][/url The support rep only stated this bug will be fixed in the v14.0.8 update, and mentioned March (when I pressed him about it). Not surprising he wouldn't comment on as-yet-unannounced rumors of Office 2014).

Re: WebSearchAndFileDownload, this is the default Lync profile setting, and per @AlgirdasR][/url][/url][/url only the "WebSearchOnly" option appears to work.

Last thing: Communicator 2011 on Mavericks is unaffected; caches the GAL within minutes and returns search results thereafter. Communicator uses OCS and Group Policy to determine AddressBook settings though, while Lync Server 2010+ uses it's own "client policies" mechanism.

[perrycj]

@bentoms I'm in the same boat as you. We are mostly a windows house and 90-95% of our clients are using Lync on windows and since they all come from the same Lync server, I can't even ask for the workaround because it would affect all the windows clients as well.

So hopefully that 14.0.8 client comes sooner than later. I work for one of the bigger corporations in the world and we are putting all the pressure we can on microsoft to get it sooner but probably won't do much. But we'll see.

[bentoms]

@seabash.. thanks for that..

FWIW, i just updated my rMBP 13" to 10.9.1 & now Lync 14.0.7 crashes when trying to login.. FUN!

[bentoms]

oh ffs.. now enabling kerberos has it in a crash loop.. fun!

[bentoms]

3 restarts later & i'm working + even happier to have the next week off... 1 hour left!

[Widner]

@nkalister, we are seeing the same issue on our Retina MacBook Pros with 2 Thunderbolt displays.

When the Macs are plugged in to both displays Lync 14.0.7 crashes at startup.

[axnessj]

We are seeing this issue as well. Hope the 14.0.8 comes soon and actually fixes it.

Also, first time login to Lync on Mavericks takes roughly 8-10 minutes. After that it loads pretty speedily. Anyone else seeing that too?

[mm2270]

@axnessj - Login time on Mavericks for us under either version 14.0.6 or 14.0.7 is fairly quick. Only ~5 seconds, not minutes. Do you have Kerberos enabled in the settings? I've seen that drag the login time down considerably, sometimes even causing login to fail altogether.

For us, we're going forward I think with turning on the server side setting outlined above. In testing, the speed difference between searching against a local file or web based address book was so negligible there isn't much reason not to do it.
Also, the 14.0.8 (or whatever version it will be) that will supposedly fix this is coming in March according to Microsoft.

[mvest20]

We are encountering this issue with a few clients that we work with. My question: does anyone know if there are any negative impacts on Windows systems or Lync clients by making this change to the Lync server infrastructure? As has been mentioned before, most of the systems that we are supporting are Windows systems, so it's a hard sell to make a change to improve the Mac client experience if it causes any changes in behavior for Windows.

Thanks in advance.

[mks007]

Create a new lync policy that allows web search only, apply to AD gourp with your mac users in.

This will not then affect your windows users.

[mvest20]

Thanks for the response, but that's not the most straightforward thing in the world to do. Lync policies are only defined by user, site, or global levels. I found a workaround, but it's not quite as black-and-white as your response would suggest.

[zmerzyn]

All that did not work for me.. however, if you have a backup (lion) and your lync worked.. all you need to do is access last backup ...copy sip_xxxx folder.. and paste it into /users/xxx/microsoft user data/microsoft lync data/ - that does the trick.. lync works again... magic...

cheers

[nkalister]

copy sip_xxxx folder.. and paste it into /users/xxx/microsoft user data/microsoft lync data/ - that does the trick.. lync works again... magic...

that'll resolve any addresses in that cache, but you're going to miss out on any new employees added after that cache was created!

[sickboi78]

@AlgirdasR https://jamfnation.jamfsoftware.com/discussion.html?id=8899#responseChild50219

Posted 06/12/13 at 06:20 by AlgirdasR Until the update arrives, there is a workaround. There are three types of policies for reading address book: 1. WebSearchOnly (when cache is not built locally on client) 2. FileDownloadOnly (when cache is built on client - in this case something in Mavericks prevents Lync to do it) 3. WebSearchAndFileDownload (if client does not support caching, e.g. mobile app, it will be using websearch in other way - filedownload) In our case it was the 3rd one in our settings and it was not possible to find contacts, unless we used full email address. Setting this policy to 1st fixed the issue. You can set this policy with this command: Set-CsClientPolicy -Identity Global -AddressBookAvailability WebSearchOnly If you are creating a new policy, you also need to run grant command. More information about commands: http://technet.microsoft.com/en-us/library/gg398300(v=ocs.14).aspx After this is done, client needs to quit Lync and launch it again - it works instantly.

I found the following article helped with understanding the possible work-around of using WebSearchOnly:

http://blog.schertz.name/2010/11/forcing-lync-address-book-web-query/

I'm discussing this with our Infrastructure team, with a view to implementing the change.

Has anyone done this yet, and if so - have you found any issues with doing so? Any network utilisation or IO issues on the Comms server?

[barber]

Hi,

Yes i ran this from the server (Set-CsClientPolicy -Identity Global -AddressBookAvailability WebSearchOnly)

Took about 30seconds and it worked

Thanks
Guys

[easyedc]

We are doing workstation pickup/drop off for our 10.9 migration. Luckily we are able to grab the files usually and so I have had success with just copying over the 2 missing files:

/Users/XXXX/Documents/Microsoft User Data/Microsoft Lync Data/GalContacts.db
/Users/XXXX/Documents/Microsoft User Data/Microsoft Lync Data/GalContacts.db.idx

From a known good directory (10.8). Our MSFT TAM promises the update to fix this is coming this month. Sure.

[sickboi78]

Posted Yesterday at 15:02 by easyedc We are doing workstation pickup/drop off for our 10.9 migration. Luckily we are able to grab the files usually and so I have had success with just copying over the 2 missing files: /Users/XXXX/Documents/Microsoft User Data/Microsoft Lync Data/GalContacts.db /Users/XXXX/Documents/Microsoft User Data/Microsoft Lync Data/GalContacts.db.idx From a known good directory (10.8). Our MSFT TAM promises the update to fix this is coming this month. Sure.

This will only allow you to see a copy of the GalContacts.db that was up-to-date at that point in time, so won't update...

I've just had a thought on how you might be able to get round this... I've not tried this, but what you could try is test the .db and .db.idx files from another user's 10.8 build and see if they update/ work on a different users 10.9 build... IF that works, you could create a login hook/ script to copy the GalContacts files from a 10.8 Mac at login (or set a logout script on a 10.8 mac to upload to a server/ file share and reference that location for the login hook), so you can get updated contacts on the 10.9 Macs... worth a go?

[bentoms]

For those of you having made the change to the global policy, is there a noticeable lag in looking up contacts? Any noticeable increase in server lag?

[seabash]

@bentoms][/url

No perceived lag from any 10.9 clients whose Lync policy profiles our server team has flipped to "WebSearchOnly" (approx 80 so far).
Users may see a "Searching..." status (at bottom-left of Lync window), but results are milliseconds thereafter.

Notes:
If Lync is left running overnight, GAL searches fail, stalling at "Searching..." and return no results. To avoid or resolve this issue quit and relaunch Lync and GAL searches are functional.

Kerberos blocks GAL search in our environment--regardless of Lync search policy, so we configure clients for username/password. Given the sordid Kerberos history in Lync, I'm not in a hurry to address this; un/pw is fine.

Windows note: same users logging onto Windows (7/8/8.1) report slow GAL searches. So make sure these are primarily Mac users that you "flip" on Lync server.

I'll confirm Lync 14.0.8 fixes the OS X 10.9 issue IF/WHEN it's released.

[jcavallino]

Still need help with this? I have been working with my server guy on our Lync deployment and had the same issue. I have noticed if you don't add DNS entries on Mavericks to all the network adapters it won't SYNC with AD to pull the global address book information. Also on the Lync server there are different polices for windows clients and mac clients. You may want your server guys to look into that. My company end up calling PS from microsoft to come in and fix all the issues including this one. Our server guy never did this before and created a cluster F**k. But good old MSFT fixed the issues. Are you using outlook on mac? I noticed that on our outlook clients on 10.9.2 osx if you don't specify a domain controller to do searches or gal pull it won't work. You may want to look at that as well.

[bentoms]

@seabash, thanks for the confirmation.

Even if it's not what I wanted to hear.

We've 200 Macs to 1,200 PC's. Almost all the PC's are on Win7.

I'll guess we'll wait. Hopefully not long now.

But the Office 2014 rumours of a April launch has me worried that this update will be bundled with that.

Oh & shame about Kerberos auth post SearchPolicy change not being able to search. Would've been nice.

[bentoms]

@jcavallino, does Lync identify the clients used & then apply the policy?

That may work.

Any hints on where that setting is or a technet document on it?

[jcavallino]

@bentoms- My server guy always ask me who the user is so he can set policy. Also ask me are they windows or osx. We also use Lync for mobile and ipads as well. I haven't gotten access yet to the Lync server because he won't give me access maybe because i will pick it up in a hour and make him look like a moron. LOL But what i do know is there are 2 seperate policies being applied. 1. For the windows 7 clients i had to create a GPO policy to hide the first time run options when you first install Lync. I packaged the windows client via office customization tool then pushed it via SCCM 2007. The lync client for mac was very easy, only thing i don't like is i wish that they had a full service pack update for lync on osx side instead of installing 4 updates seperatly. Also back to the policy's 90% is control via server side, there is a technet article on this. http://technet.microsoft.com/en-us/library/gg398867.aspx

if you have any other questions i have built both deployments for both windows and mac. email me jcavallino@equinix.com

[nessts]

i think if you download this http://www.microsoft.com/en-us/download/details.aspx?id=36517 its a full installer.

[bentoms]

Thanks @jcavallino.

I'm not involved with new starters, so ad-hoc is a no-go.

We have Lync running @ login with the plist populated by an AppleScript app that launches Lync.

All is ok except for this 10.9 issue.

[jcavallino]

No problem I know for a fact its a policy related issue via server side. We had that problem in the first part of the deployment, but once the research was done that there are polices to control this it was lifted off my plate :)

[ptrondsen]

Thanks for the great comments, we too are having this issues with Lync 14.0.7, and Mavericks.
In reading the comments, it does appear that Lync is not creating the two GalContacts files. (GalContacts.db, GalContacts.db.idx) in the Lync Data folder for new setups.
So, I looked on my Mac, because I am connected via Kerberos, and have no issues searching for contacts.
I have the two Gal files, so I copied them to the affected client, and relaunched Lync, and now I am able to search on the client's Mac.
So, my question is, why are these not being automatically created, and secondly, is there any negative issues with using the GalContact files from my computer? They don't appear to contain any personal data.
Thanks!

[sickboi78]

@ptrondsen - there is no issues with using these files... the problem is they won't update, so any changes made to the GAL won't propagate to that client. You would need to manually copy the GAL files to the affected Mac manually - or as I stated in a previous post... use a Launchd/ startup script to copy the files from a good source from a network volume at each logon.

[ptrondsen]

@sickboi78 - Thanks for the info, that makes sense, I thought maybe the GAL files would kick in the connection to the server. Any idea, why this isn't happening automatically anymore?

[sickboi78]

@ptrondsen - There is an incompatibility/ bug with Lync on Mavericks (OS X 10.9). M$ have released a couple of patches/ updates to Lync which fix other issues, but not this one. From reading through the thread, v14.0.8 is due imminently, and should (hopefully) address this issue...

Post on 11/3/14 at 3:02 PM by @easyedc read:

We are doing workstation pickup/drop off for our 10.9 migration. Luckily we are able to grab the files usually and so I have had success with just copying over the 2 missing files: /Users/XXXX/Documents/Microsoft User Data/Microsoft Lync Data/GalContacts.db /Users/XXXX/Documents/Microsoft User Data/Microsoft Lync Data/GalContacts.db.idx From a known good directory (10.8). Our MSFT TAM promises the update to fix this is coming this month. Sure.

The other 'fix' listed in this thread is to change your Lync directory search behaviour for your mac users to use 'WebSearchOnly' mode...

http://technet.microsoft.com/en-us/library/gg398300(v=ocs.14).aspx

http://blog.schertz.name/2010/11/forcing-lync-address-book-web-query/

If you do this globally, Windows Lync users will notice a slow down in searching for users - I guess there are other other considerations for this too - depending on how many users you have/ what spec your infrastructure is (network & server etc.)... if you don't have many users and decent infrastructure, this may not be a massive consideration, and you may want to implement a change globally... it may be that you create a new administrative group on your Lync server just for your Mac users and implement the policy for them only... a bit more complicated to implement, but if you can't wait for the patch from M$, then this might be a better solution for you... certainly easier to implement if you don't have a managed Mac environment where you can deploy logon script updates to all Mac users...

If you do have a managed Mac environment, and can push logon scripts out to all your Macs, then settings a Mac with OS X 10.8 and Lync on to copy it's GAL files to a network volume and all other Macs to pick those files up each day may be an easier/ quicker solution (workaround) for you to implement... we don't have that many Mac users, so are happy to wait for the patch from M$.

[ptrondsen]

@sickboi78 - Thanks Again, obviously, the other fix, has to be done on the server side, and I am just a Mac Server admin, and don't have rights, so I guess I'll wait for 14.0.8. :)

[sickboi78]

@ptrondsen If you've got a Mac OS X Server and/or ARD (Apple Remote Desktop), I think you could easily push a launched bash script to your users Macs and get them to configure themselves to pick up updated files... create a new task and deploy it - simples :)

[sickboi78]

Hi Everyone... update 14.0.8 has FINALLY been released...

KB Article:
http://support.microsoft.com/kb/2952672

Download:
http://www.microsoft.com/en-us/download/details.aspx?id=36517

I've just downloaded and installed it, and it has resolved the GAL issue - for me, at least. I haven't performed a clean install yet, but it looks promising.

Please advise if you have any issues!

[rtrouton]

I ran into a few issues installing it. Post on it here:

http://derflounder.wordpress.com/2014/04/10/repackaging-the-microsoft-lync-14-0-8-installer/

[mks007]

14.0.8 Working so far, only on a few at the moment.

Lets see what happens.

[tgrose]

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/

[TuckerLM]

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!