There is a trend, nowadays, to have a hybrid setup in a customers Lync setup.  So they will have an on-premise Lync server and then expand into the LYO world, whilst keeping the Lync server operational (I'd thought I'd provide a video from our Lync conference in Las Vega describing this :) - https://channel9.msdn.com/Events/Lync-Conference/Lync-Conference-2014/ONLI302).

This is happening for loads of organisations now. It did happen for huge customers with loads of cash, but as the cloud gets cheaper we are seeing "ordinary customers" doing this.

Which isn't that bad.  What I did see, however, was a lot more issues with displaying free/busy information on the Lync client when used with Outlook / Exchange account.  The key issue here was that the SIP address was different from the SMTP address.  Not good when using the PC Lync add in for Outlook.  The SIP address is used by the plugin to see what meetings that user has, and if they are in one, will update the status of Lync.

Sometimes that won't happen. So if I have a user called myuser@contoso.com as an SMTP address but the SIP address is myuser@outside.contoso.com.  The presence information in the Lync client won't update from the Outlook client meetings.  Trouble there then! 

Easy to fix however!!! Change the SMTP address to equal the SIP address.....

Err ok, if you want something different then, just change the registry to tell Outlook not to be too harsh when looking to match the SIP and the SMTP address.  This registry change should help out:

1. Click Start, click Run, type regedit, and then press ENTER.
2. Locate, and then right-click the following registry subkey:
1. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator
   or
2. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Lync
3. Point to New, and then click DWORD Value. 
4. Type DisableEmailComparisonCheck as the name of new registry entry, and then press ENTER. 
5. Double-click DisableEmailComparisonCheck, type 1 in the Value data box, and then click OK. 
6. Close Registry Editor.
7. Restart Lync and Outlook.  

So that should fix the issue, but you can also try re-registering the SMTP address with O365:

1. In Office 365 admin portal, change the domain name of the user account from a custom domain such as domain.com to the default domain xxx.onmicrosoft.com.
2. Wait for half an hour, check the SMTP address and SIP address using Windows Powershell.
3. If the SMTP address and SIP address are shown as user@xxx.onmicrosoft.com, change the domain for this user back to domain.com.
4. Check the results

 Please use a demo account, and don't hold me liable! This is your doing :)

I myself have converted my Skype for Business (SfB) client BACK into a Lync 2013 client - just the look and feel aspect...  Why you may ask?

Well there are still some people who are Hybrid or actually on premise with Lync and can't / won't change their clients.  And having one of my machines running the Lync 2013 client or "pseudo" Lync 2013 client, is a good thing.  I can help out and I know that the customer is talking about.

So how do I change my SfB client to look "old school" as Lync 2013 was?  There are two methods which I have found, and there may be others (just let me know via a message below).

Change the look of the SfB client via PowerShell (0365 & on-premise)

Its easy really, just need to fire up a Remote PowerShell session and then fire off this command, to enable the SfB UI:

Grant-CsClientPolicy –PolicyName ClientPolicyEnableSkypeUI -Identity <username>

Then to disable the look and feel:

Grant-CsClientPolicy –PolicyName ClientPolicyDisableSkypeUI -Identity <username>

You can drop the -Identity parameter if you want to do it for a load of people, or just use the other parameters in the Grant-CsClientPolicy cmdlet (https://technet.microsoft.com/en-us/library/gg412942.aspx).

Also, the guys at Microsoft have released a website describing all of this, and honestly, I knew about this before they released the page... honestly :) - https://support.office.com/en-gb/article/Switching-between-the-Skype-for-Business-and-the-Lync-client-user-interfaces-a2394a4c-7522-484c-a047-7b3289742be0.

Change the look of the SfB client via a MS-DOS batch file and mucking around with the local registry

Ok, so I did this first and continue to do it.  This is because I am on-premise and can't access my logon script...  This also applies if you can't use the cmdlet above.

Right, so I:

1. Found out where my new SfB (in effect Lync) shortcut was pointing at.  It can change and will do with the new Office versions. So I would just right click and find the file until you get to the exe.  Which was lync.exe.... surprisingly.
2. Then I looked up the registry to see if the SfB client had changed anything.  It had added a key called "EnableSkypeUI" in this key [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Lync] and the value was hex:00,00,00,01.
3. Now I created a registry file.  I used a text editor, added and saved the following:
   

   Windows Registry Editor Version 5.00

   [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Lync]
   "EnableSkypeUI"=hex:00,00,00,00

4. Then I created a batch file and put this text into it (obviously change the <User Name> part):
   
   C:\Windows\regedit.exe -s "C:\Users\<User Name>\OneDrive for Business\RegChange\changeSkypeToLync.reg"
   START "LYNC" "C:\Program Files (x86)\Microsoft Office\root\Office16\lync.exe"

5. So, I put the registry and the batch file in the same directory.  I created a shortcut icon to the batch file and then I can run this, and it changes the registry to start Lync errr as Lync.

This obviously changes the registry EnableSkypeUI back to 0 and disables the new look.  This is because the domain admins always set the registry to enable the Skype UI.

Hope that helps someone!

So what is happening?

Lync 365 / Online client is now currently being moved over to Skype for Business (as of 18 May 2015), which is causing all sorts of hassle for many people.  But it shouldn't.  Honest.  Skype for Business (SfB) is just a replacement to the Lync 2013 client we have all come to know and love... But don't worry, the new SfB client is a slight change in look and feel when working with it, and has a few neat extra features when using the new client.

Sooooo Skype themselves have written an article to make sure people know the difference between the SKYPE client and the SfB client, have a look - https://support.skype.com/en/faq/FA34551/what-s-the-difference-between-skype-and-skype-for-business.  We (Microsoft) have also written an article describing the differences and the changes to Lync online when it becomes SfB (I think the word "online" is assumed here) - https://technet.microsoft.com/en-us/library/dn913785.aspx.

That last article goes through the differences in the two types of clients and features new interfaces and features.

Don't get me wrong though, you can still use your Lync 2013 clients if you want to.  If you are struggling with controlling the "click-to-run" updates which come through automatically for each PC and you want to centralise the updates from a server on your network (in affect chosing when and where the updates come in), go here for more information - http://www.microsoft.com/en-gb/download/details.aspx?id=36778.

If you want some advice in controlling the Skype for Business client experience, then look here http://blogs.technet.com/b/scottstu/archive/2015/04/13/controlling-the-client-experience-with-skype-for-business.aspx.  A great article and explains most things....

Here is an example of where us in Lync escalation services have to collaborate with other teams to get the fix working for the customer.  To be frank, actually, the other team provided the solution to the customer and they should be praised highly.

So a customer raised a case with us in UK escalation services.  The long and the short of it was that the customer had previously installed the O365 Preview bits, ran Office 2010 bits side by side, then uninstalled them both when the new upgrade to Office came along for his tenant.  Running the Lync 2013 full client would result in an crash with a dialog box appearing that said:

"We're sorry, but Lync has run into an error that is preventing it from working correctly. Lync will be closed as a result.  Would you like us to repair now?"

Then a few buttons to repair now, help or close.  Interestingly the dialog title said:

"Lync (non-commercial use)(Unlicensed product)"

Which is strange since the client had apparently been downloaded from the tenant portal area.

The client had been uninstalled several times PLUS the uninstall process followed, using the automated 'fix it' way and the manual way (http://support.microsoft.com/kb/2739501).

There were some issues in the past where old bits of the preview were causing problems installing the 'full' version of the office suite.

So the focus was currently on the customers previous installation of O365 which may have been causing the issue. 

Uninstalling Lync 2013 client would be cleanly done, working through the registry at this point didn't reveal anything too crazy in terms of left over details from the preview installation.

The weirdest behaviour was when I managed to get 2013 working ok on the customers machine.  We thought that this was a job done and go home for tea and biscuits.  However when the customer woke their laptop up from sleep the old error popped back.

SO it was something in the startup that was telling the Lync client that it actually was an unlicensed product.  The issue wasn't there as part of the installation.

At this point I took a process monitor trace http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx, this would take a trace of the process and how it was interacting with the local machine.  It was at this point that I had to call in the big guns.  This felt initially like a setup issue but now was one around licensing.  I sent out feelers to the Office team and got responses.  Previously, this case had been with them, but had been put to Lync online because it looked to be a Lync related issue.  Once I had nailed it down to the client reverting rather than being installed incorrectly I could then ask for help.

So the amazing chaps at the office team found this in the process monitor traces:

3:47:38.6048073 PM Explorer.EXE 4688 RegQueryValue HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\C:\Program Files\Microsoft Office 15\root\office15\lync.exe SUCCESS Type: REG_SZ, Length: 20, Data: ~ WIN7RTM

So, explorer, before firing up, was checking if I need to run Lync in Windows 7 compatibility mode.  In this case it was.  Which isn't the best thing to do if the licensing model needs to remain working with the Lync 2013 Windows 8 install of the product.

Once the office team determined the that this was the case, they advised the customer not to run in compatibility mode and the Lync client now worked as advertised.,

The lesson is that it might not only be the application that is failing or been set incorrectly.  Hope this helps!

Skype is the replacement for MSN messenger and a great replacement it is too.  In fact I would go far as to say its the best service for home use.  And that includes many fruit based alternatives, just because you can subscribe to have minutes with which to dial up phones and also have an inbound phone number.

What it isn't, is a corporate united communications system.  That's where Lync comes in.  But don't panic, they can work together.   If your tenant is set up, you can speak to (literally or via messages) another Skype user.

The process is simple but can be slightly strange for the Lync user.  In Lync, if my Lync tenant is federated to your Lync tenant, I just search for your SIP address and there you are.  I can see presence and I can talk to you immediately.  We are federated so that should be the case right?

With Skype its a different kettle of fish.  You are federated with Skype (you can change this through your tenant settings by turning off external IM communication), but the thing is, as a Lync user I could just start entering SIP addresses and then start to see people on Skype through my Lync client.  Which would make my contacts list huge AND be a bit annoying for people who you don't know who you constantly message.  So you *can* add a Skype user to your Lync contacts list, but until they accept you as a friend, you won't be able to see their presence.  The same is true the other way.  The Skype user can add your Lync SIP address but won't see your presence or be able to contact you until you have added them to your contact list.

In essence, it is protecting you from seeing people that you shouldn't see and also people not seeing you without your permissions.

However the problem comes when your tenant is enabled for external federation / PIC and you cannot add anyone from Skype and no one can add you.  In this case I would contact support.  They would be best placed to sort out your problem.

In a nutshell, the Hybrid Lync 2013 installation is where you already have an on premise installation of Lync and want to expand into the cloud and have users in the cloud or on premise.  I'm no sales person but I guess having your sales force who are out and about on a cloud platform and all the admin people in the office on the on premise makes a load of sense.

There are loads of brilliant documentation on what it means and how to do this. The best starting point is here: http://technet.microsoft.com/en-us/library/jj204805.aspx.  And there is a brilliant blog here http://imaucblog.com/archive/2013/05/10/step-by-step-guide-enabling-split-domain-within-office-365-lync-online/ which is great at summarising how to do the whole process with little bother. However I've got a couple of questions and answers which I hear frequently and may answer your question before having to dive into the documentation.

Can I just add my domain to my tenant and share the sip domain?
No, not really.  Especially if you are not on the earlier tenant (how can I tell? http://office.microsoft.com/en-gb/help/am-i-using-office-365-after-the-service-upgrade-HA103982331.aspx) and especially not if you have Lync 2010 on premise.  You cannot just add the domain to your online tenant and expect that to work.  It might work, it might not, but you will get a load of unexpected side effects as well as things getting broken and nothing but hassle from your user base.  In a word don't do it.  You need:

• A tenant running Lync Online 2013.
• Active Directory Federation Services (ADFS) running Win 2008 R2 SP1 or later.
• Lync Server 2013 on premise deployment *
• A directory synchronisation server

Ok what does the * mean in the above point?
Well ok, you don't need a pure Lync 2013 server deployment.  Just one of these:

More information is here http://technet.microsoft.com/en-us/library/gg425833.aspx.

Great, I just need to add the domain into the online tenant and I'm good to go right?
Well no, your online tenant needs to have some PowerShell scripts enabled, and you will have to run some scripts on your on premise deployment.  Raise a support ticket for the online people to have your tenant enabled for the correct commandlets and enabled for hybrid.  Then you need to run some commandlets on the tenant and the on premise.  Remembering to configure federation in your O365 tenant, with it off, you won't get far.

As I come across more questions, I will update them.  So watch this space.

There was always the question of the MSCRL traces aka the traces from Microsoft Online Services Sign in Assistant.  This is a service installed as part of the previous o365 generation.  The Lync 2010 client required this to function with the service and also give flexibility to other apps as well.  So, to troubleshoot this you needed to edit the registry and turn a flag on and specify a folder and voila! The logs appeared as if by magic.

Now though, this service is on demand since Lync 2013 is a next gen client and is cloud aware.  It also logs to a folder permanently all these low down traces.  No more editing the registry and restarting services.  It all comes as standard.

Ok so the UCCAPI and ETL logs for Lync 2013 are, by default, located here:

C:\Users\<myuser>\AppData\Local\Microsoft\Office\15.0\Lync\Tracing

These will need to be turned on as per normal via the Gear > Tools > Options > General

We have the options of OFF - LIGHT - FULL.  Me?  I prefer FULL, just because its best to have something and not need it than to need it and not have it.

Turn that on, and repro the issue.  Of course have a look at the CRL logs if you wish, and they are located:

C:\Users\<myuser>\AppData\Local\Microsoft\MSOIdentityCRL\Tracing

This is what you see when you try to install the client from the installation media:

"Microsoft Lync Basic 2013 encountered an error during setup "

Oh dear... That's not good.

Ok lets look into the MSI install log, inside it we see:

2013/05/03 16:01:14:024::[16752] Successfully
installed package: LyncEntryWW path:C:\MSOCache\All
Users\{90150000-012D-0000-1000-0000000FF1CE}-C\LyncEntryWW.msi

2013/05/03 16:01:14:025::[16752] 05/03/2013 16:01:14
Committing MSI transaction.

2013/05/03 16:01:44:089::[16752] Error:
MsiEndTransaction failed. MsiEndTransaction ErrorCode: 1603(0x643).

2013/05/03 16:01:44:089::[16752] WER element
[P4] is set to value [1603]

2013/05/03 16:01:44:089::[16752] WER element
[P7] is set to value [1603]

2013/05/03 16:01:44:089::[16752] WER element
[P6] is set to value [%s %s]

2013/05/03 16:01:44:089::[16752]  WER element [P6] is converted to [FC73469E]

2013/05/03 16:01:44:091::[14288] Showing
completion dialog.   

Hmmm a MsiEndTransaction failed... With an error 1603.

So looking further into this, it looks like the WMI repository is corrupted.  We can have a quick go in repairing and seeing if all is well with system files by trying to run this at the command prompt:

sfc /scannow

SFC is a system file checking tool which I think was included in Windows 2000 and now is in every version of windows.  You can read more about it here http://technet.microsoft.com/en-us/library/bb491008.aspx.

That might not sort out your problem, it might be that we need to do major surgery.  You can do this by running this script as a batch file:

@echo off
sc config winmgmt start= disabled
net stop winmgmt /y
%systemdrive%
cd %windir%\system32\wbem
if exist repository.old rmdir /s/q repository.old
rename repository repository.old
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
wmiprvse /regserver
winmgmt /regserver
net start winmgmt
net start SharedAccess
net start CcmExec

This should clear out the old repository and create a new one. 

Remember: This solution is presented as an solution to the issue being described and you run it on your own machines at your own risk! 

This should get things working.  I'm told that this also fixes an issue with Office 2013 not installing.  I've yet to test it, but please let me know if that is the case.