When you click to change to a new site the first thing bounSky does is pop the Lync / SfB client to the foreground and then send it a “sign out” command.
The client then shows on-screen with the SIP address and account details of the site you’ve just signed out of, not the one you have chosen to sign in as.
In the background bounSky pushes a sign-in request against the new site, but this isn’t visible to you on-screen.
I’ve tried but have not been able to push the new site’s details so they’ll show to you when this process kicks off. I appreciate this is often confusing for new users as it appears bounSky isn’t actually doing anything. It is – you just need to wait for the sign-in process to complete.
This is a non-uncommon error, rendering bounSky (and other applications based upon the Client-side API) effectively useless.
There can be a number of causes:
- some co-resident installations of both Office 2013 and Office 2016 versions of the Lync / SfB client
- installing the LyncAttendant application
The fix is usually to perform a “Repair” of Office 2013. (Launch Control Panel and navigate to Programs and Features. Select your version of Microsoft Office, then click “Change” and “Repair”).
If this doesn’t work for you, try completely uninstalling the LyncAttendant & repeat the repair process. (LandisComputer have encountered and blogged the process here for their Attendant Pro app).
Ouch! That’s not meant to happen (and I realise that’s cold comfort for you at this moment).
The settings might not be lost. If you still have the .msi from the previous version, uninstall the version you’ve just installed, then re-install the old one. With the settings now visible, back them up (File / Export) and repeat the upgrade. If they’re not there after this second upgrade you can restore the backup from File / Import.
If you no longer have the old .msi, you might be able to locate and hand-edit the original settings back into a CSV file to import. Check if the old config is still here:
If it’s not here, try the \AppData\Roaming\ folder tree.
(You might need to go to Explorer and enable View / Hidden Items before you can see the “AppData” folder).
If you’re using the Office 2013-based version of the Lync / Skype for Business client, patch version 15.0.4711.1000 (April 2015) introduced the ability for it to show either the Lync 2013 UI (skin) to the user, or the Skype for Business one. The csClientPolicy setting “EnableSkypeUI” dictates which UI will be presented, and this is passed in-band to the client when the user signs-in.
The client only tests this value on launch – not when the user signs in – so for the client to show the correct UI it will need to be restarted each time you switch users/sites. You can have bounSky do this for you automatically by checking the box “upon successful sign-in … restart the client” under Setup / Options.
Note that the Office 2016-based version of the client no longer includes the Lync 2013 UI, and will always display the SfB UI regardless of the user’s csClientPolicy “EnableSkypeUI” setting. Checking “upon successful sign-in … restart the client” serves no purpose for users of the Office 2016 client.
The Import from Registry process is far from perfect, purely because there’s not enough human-readable (or obviously decodable) information presented there to generate a workable set of ‘sites’.
Think of it as more of a template to work from if you’re installing bounSky on an existing machine that you’ve already used to sign in to multiple sites or user accounts.
Essentially, all I can reliably pull from the registry is the user’s SIP address. I can usually also retrieve any Manual Configuration values – but not the value of the Automatic/Manual radio button.
Note that an Import (whether from File or Registry) will over-write any previous configuration without prompting.
Security-conscious corporate environments often use Group Policy to lock the Manual Configuration and hard-code their own Internal and External values. This is typically a data-leak prevention exercise to stop anyone signing in to another organisation’s instance of Lync or Skype for Business. It’s known to really annoy on-site contract staff as it prevents them from accessing their employer’s system.
The radio buttons disabled & the text greyed is an indication that this lock has been set:
You will typically encounter this error when trying to bounce to a site where you’ve set manual that site with server settings that differ from the ones already hard-coded in the Registry.
The same error message will also display if the user doesn’t have permissions to set or clear the “Automatically Start When I log on to Windows” value in the Registry. Strictly speaking this isn’t necessarily a GPO issue, I realise.
When bounSky encounters either of these issues it will report it to the user the first time, but raise no further complaint if encountered again during that session.