MS Lync - Package with Advanced Configuration

[chutiya]

We're trying to deploy MS Lync across the Office, and we have to follow a manual configuration for the server settings for Lync. I've packaged up using composer, but small problem. It adds "paste" at the beginning of my server name in the advanced settings once deployed. The server should read sipdir.online.lync.com:443, but read paste sipdir.online.lync.com:443

checked the machine I packaged it on to make sure I hadn't typed paste in, I haven't. Seems to add it on deployment, or upon packaging.

any ideas?

thanks in advance.

[geoffreykobrien]

Have you checked this out:
https://github.com/talkingmoose/LyncSetup

[chutiya]

thanks @geoffreykobrien - yes, read that. But its not relevant to what we need. We need something that amends the advanced configuration/server settings. Packaging using composer is fine apart from it adding "paste" before the server address for some strange reason.

[talkingmoose]

Have you verified this is a Composer issue and not an issue with Lync itself? The Advanced settings are configured using the MicrosoftLyncRegistrationDB.plist file in the /Library/Preferences folder. What do you see in that file after deploying it?

If you're not seeing "paste" as part of the file there then the issue is more than likely Lync itself.

Also, what version of Lync are you using? I believe the latest is 14.0.9.

[chutiya]

hi @talkingmoose - yes its the latest version. Sent to another user and worked fine (once FUT/FEU were ticked), the initial user tested on had just removed the app and looks like some files didnt go with it - but strange as I would assume the packaged file would have over-written any existing files anyway. We're now using your script for other bits -thanks you for that - its very helpful.

[chutiya]

hi @talkingmoose - we've tried running this script and we have confusing results. When we push out using Casper (so just using Casper remote to send script to a machine) we get no result. Looks like nothing happens at all. But if we run script locally we get desired results. Any ideas where we could be going wrong please?

thanks,

[talkingmoose]

The script should write a log to the current user's home at ~/Library/Logs.

If you're not seeing that log file when running under a new user then the launchd item isn't working. The most common problem with that is permissions. Be sure your launch agent's permissions are similar to the others in the folder.

[chutiya]

thanks @talkingmoose - we're trying to run through Casper remote, so launchd shouldnt even come into the equation i dont think. Just sending directly for testing purposes.

[chutiya]

hi @talkingmoose - any ideas on this please? hitting desperations points here. :(

[talkingmoose]

@chutiya

Just re-read your messages and realized you're using Casper Remote. The script is designed to work under the currently logged in user. Casper Remote will run under the root account. Therefore, you're configuring the setup for "root", which probably doesn't have an account.

You'll really need to get the "/Library/LaunchAgent/net.talkingmoose.LyncSetup.plist" launchd agent running to make this work. Double-check the insructions in the README file. I'm hoping it gives enough detail to help. If not, post back and we'll take it step by step.

[chutiya]

thanks @talkingmoose - have tried some bits and we have it working apart from its not disabling the first run license agreement. Any idea how we'd work around this?

[talkingmoose]

@chutiya

Hmm... This line in the script should take care of the EULA:

defaults write $HOME/Library/Preferences/com.microsoft.Lync acceptedSLT140 -bool true

It's in the original script and I've tested here that it still works. Possibly something in this line was changed slightly.

[chutiya]

hey @talkingmoose its exactly the same. But we downloaded a version of lync from our O365 portal which is 14.0.1 - would this make a difference?

[ImAMacGuy]

@talkingmoose I know it's been about 2yrs since you updated the script, but any ideas how one might go about automating the acceptance of the certificate? I tried per-loading the cert, but still when I connect the first time it tries to install a cert. I think it's a user specific one that goes into the login keychain. It doesn't seem to require admin credentials since the login keychain is unlocked typically, but it's a stopping point for users that don't really understand what it's doing.

[talkingmoose]

@chutiya

I don't see a reason why a minor version difference would make a difference. Troubleshoot by logging in as a new user. Before launching Lync, verify the plist file contains the correct key (acceptedSLT140) and correct value (true). If that's not in the plist file first then the script is not running properly.

[talkingmoose]

@jwojda

You're right that it's been a couple of years. Unfortunately, it's also been a couple of years since I've been in an environment to troubleshoot. I'm not sure what certificate you're seeing to accept. Is this possibly a self-signed certificate that you have to acknowledge?

Certificates would need to be distributed along with the script and then you'd need to use the "security" command to add it to the user's keychain. Since I'm not familiar with this issue I'm not sure what more you'd need to do.

[donmontalvo]

Oy, looks like we have to update our suppression again for the Lync 14.4.1 update released on patch Tues.

$ defaults read com.microsoft.Lync | grep accepted
acceptedSLT140 = 1;
acceptedSLT141 = 1;
acceptedSLT142 = 1;
acceptedSLT143 = 1;
acceptedSLT144 = 1;

Thanks to @jhbush1973 for the heads up.