EnableSessionTicket from Powershell

To get support for Lync and Skype for Business on Windows Server 2012 R2, you need to add a registry key that changes TLS session caching on 2012 R2 Server. This is described here https://support.microsoft.com/en-us/kb/2901554

To create this key, use the following powershell oneliner:

Skype for Business meeting join not starting in Google Chrome

Today I got to troubleshoot this little curiosity. A customer that uses Google Chrome as their standard browser reported that a few of their users wasn’t able to join meetings when clicking the meeting join link, nothing happens and they are displayed a page looking like this.

2015-10-15_14-15-46

When a user joins a Skype for Business or Lync meeting for the first time in Chrome, they are presented with this message:

2015-10-15_14-14-31

What probably had happened to those users is that they have checked “Remember my choice for all links of this type.” and then clicked “Do Nothing”.

2015-10-15_14-14-52

What this will do is that Chrome will block URLs trying to launch the Skype for Business or Lync client using the lync15: protocol, rendering the browser unable to launch the client and forcing the user to use the web app.

Removing this block isn’t very hard, but as far as I know it is not accessible from any part of the Chrome GUI. Here’s what you need to do:

  1. Open %userprofile%\AppData\Local\Google\Chrome\User Data on the users computer
  2. Locate the file “Local State” and open it in notepad
  3. Locate the “protocol_handler” directive in the file and find “lync15:” under it
    2015-10-15_14-24-02
  4. If “Lync15:” is followed by “true”, it means that the protocol is blocked, and the client won’t be launched.
  5. To resolve the issue, either
    1. remove the whole “”lync15:”:true,” (including the last comma). This will reset the configuration, and the user will be presented with the above dialogue again the next time they try to join a meeting, giving them another opportunity to block the protocol
    2. replace “true” with “false”, which will unblock the protocol.

Managing Acano Server in Powershell

v0.2 has been released! Post here

I love it when stuff is possible to manage through PowerShell.

I’ve been working quite a bit with Acano lately and because of that I have started looking in to the management API that they provide on their Server. This API is exposed as XML through HTTPS, so I thought that it should be quite possible to write some PowerShell functions that accessed parts of the API. These have evolved in to what I now release as version 0.1 of the PsAcano PowerShell implementation of the Acano API.

Currently only the GET commands are implemented, so it is only possible to view information at the moment – not edit or create anything. The functionality provided by the POST, PUT and DELETE commands will  be implemented in the coming days and weeks.

Last weekend Knowledge Factory had our kick off in beautiful Vaxholm outside of Stockholm. There we were treated to an extremely inspiring session by Simon Wåhlin (http://blog.simonw.se/) about PowerShell and GIT. A big thank you to Simon for finally kicking me into doing source control on my scripts 😀

I’ve set up an account on Github, and from now on my scripts will be available there, and this of course also applies to PsAcano.

If you don’t want to visit the repository page on github, you can download the module here. Installation instructions can be found in the Readme.md file. Feedback is welcome as issues on github or comments on this blogpost.

Automating FIM Run Profiles for Lync

When deploying Lync in a Central Forest Topology it is recommended to use a directory synchronization product of some sort to synchronize user accounts from user forests to the central resource forest as contact objects. Nowadays this is normally handled by Forefront Identity Manager, and this deployment is discussed in detail in the Technet white paper.

When FIM is deployed, you have to execute Run Profiles on the management agents in the correct order, both import and metaverse synchronization needs to be done on the central forest management agent before any user forest management agents for the data to be exported correctly in the last step. This means that in general the Run Profiles needs to be run in this order: (This applies to both Full and Delta executions)

  • Import  Central Forest Management Agent
  • Import User Forest 1 Management Agent
  • Import User Forest 2 Management Agent
  • Sync Central Forest Management Agent
  • Sync User Forest 1 Management Agent
  • Sync User Forest 2 Management Agent
  • Export Central Forest Management Agent

Also it is a good idea to wait until the last operation is completed before starting the next.

This gets quite tedious rather quickly when you have to right-click the management agent -> run, select the correct profile, then click OK for every operation. In addition you will need to think about automation at some point as well.

So I’ve created this powershell function that will take a sorted array of Management Agent names and run all the Run Profiles in the correct order for you.

Simply load the functions in your current powershell session and run

CsFimMaRun -ManagementAgents @("ResourceForest","UserForest1","UserForest2") -Type Full

or

CsFimMaRun -ManagementAgents @("ResourceForest","UserForest1","UserForest2") -Type Delta

and the run profiles should be executed in order. For automation just add one of the above to the end of the script and run that in a windows task scheduler. One delta update a day is often enough, but if the environment is very dynamic you might want to run it more often.

If you set $debugpreference=”Continue” it’ll display the status after each operation as well.

Download here

Lync, Skype and Cisco Telepresence clients in the same video conference!

Late afternoon last Friday (In europe at least :)), Microsoft released video calling between Lync and Skype. This has been something that a lot of us has been waiting for for quite some time! You can read more about this release here.

To be able to video call a Lync contact from Skype, and vice versa, the following needs to be set up:

  • The Lync environment needs to be federated wilyncoptionsth Skype – see the Provisioning Guide
  • The Lync user needs to use the Lync 2013 client.
  • The Lync user has to be enabled for Public Access, and will have to set “Contacts not using Lync” to “Allow invites but block all other communications” or “Allow anyone to contact me” under “Alerts” in the Lync options menu.
  • If set to “Allow invites but block all other communications” both the Lync user and the Skype user must add each other to their contact lists
  • Currently it will only work from Skype on a Windows desktop running at least version 7.0.x.100. More Skype clients will be supported in the coming months.

This also brings cool opportunities when using Lync together with for instance Acano or Pexip MCU software. This screenshot is from a video conference using the Acano brigde, and here is a Skype Client, a Lync Client and a Lync mobile Client brought together with a Cisco Telepresence room! Pretty awesome! The screenshot is taken from the Skype Client.lyncskypeciscotp

 

Lync Meetings and Transport Neutral Encapsulation Format

One of the small things that make Lync Meetings so simple to join is that Outlook will recognize the meeting and wil give you a small button on the Outlook reminder that lets you join the meeting without even opening the calendar. This is also the same functionality that clickable from the calendar interface on the mobile and desktop clients and makes the meeting joinable from a Lync Room System.

Some might have noticed though that when the Lync meeting invites come from an external organization, none of the clients will actually recognize the meeting as a Lync meeting. For most of the clients this is not a big problem, because the link in the invite will still be clickable, but for the Lync Room System this will actually render the meeting unjoinable.

The method that is beeing used in the meeting invites to identify a calendar object as a Lync meeting is called Transport Neutral Encapsulation Format, or TNEF. TNEF is basically an attachment format that is used by Outlook and Exchange in different situations additional formatting is needed, like voting and meeting invites.

The global settings for sending TNEF to remote domains is default set to false. This means that when sending Lync Meeting invites out of the organization, the TNEF attachment is stripped off and the recieving party does not get the extra data which in turn makes the Lync clients at the recieving party not recognize the meeting as a Lync meeting.

To resolve this, the sending party needs to enable sending of TNEF attachments to the recieving party. This is done via the RemoteDomain settings, and can be turned on for i.e contoso.com like this:

New-RemoteDomain -DomainName contoso.com -Name Contoso
Set-RemoteDomain -Identity Contoso -TNEFEnabled $true

It is also possible to set TNEF on for all remote domains, but be careful with this as TNEF can cause issues if the recieving end does not use Exchange.