Monthly Archives: August 2014

Lync Phone edition tls handshake fail with usb tethering out of box

MSFT support engineers have identified a bug with the USB tethering on Lync Phone Edition. They compared the packet traces of the PIN authentication successful TLS handshake and compared it with the failed USB tethering TLS handshake.

They observed that during PIN authentication, the Lync phone connects to the Lync server over port 80 to download the intermediary certificate whereas during USB authentication, the phone skips that step and immediately attempts to handshake on SSL 443. The problem is the handshake fails because the phone does not yet have the intermediate certificate.

Quick conceptual background: A certificate chain is commonly composed of a Root certificate, followed by an intermediate certificate, and finally the issued certificate.

So in summary, there is a bug in the Lync Phone Edition firmware that is preventing the intermediate cert download from occurring during the USB tethering.

This is why the USB tethering works successfully following the PIN authentication, because during the PIN authentication, it successfully downloads the intermediate certificate.

MSFT is going to document this issue into a Knowledge Base Article and then inform the product engineering team. There is no guarantee that the product group will fix this behavior since there is a reasonable work-around to use PIN authentication.

Another potential fix is to find a different certificate authority that may skip the intermediate authority and issue device certs directly from the root authorities that come pre-loaded on each phone as described at the bottom of (this) MS Technet article.

This is not very practical because you would first have to purchase the certificate from Comodo, Verisign, Entrust, etc to find out whether they issue certs directly from the root and skip the intermediate. Also, it is highly unlikely that we would find a CA provider that does not have an intermediate authority because best practice is to mask/shield the root from direct contact by issuing certs from the intermediate rather than the root.

Assign lync policies based on ad group

I adapted a script I found online to run within a scheduled task to assign a Conferencing Policy based on the membership of a global group named “CSLyncRecordingUsers.” Originally the script accepted paramters, but I wanted to just force the scheduled task to run with as few paramters as possible. I commented out the lines requiring arguments.

The service account needs to have the Logon as Service right assigned, and it needs to be a member of RTCUniversalServerAdmins.

The scheduled task just needs to reference powershell.exe and then a single parameter with the location of the script.

_________BEGIN Assign-ToGroup.ps1____________________

import-module ‘C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync\Lync.psd1’

#Note: The above quotes must be single ticks and not double quotes or the task scheduler will not fire.

#Purpose: Assign the Recording Policy to all members of the global Group CSLyncRecordingUsers

#Syntax C:\Scripts\Assign-ToGroup.ps1 CSLyncRecordingUsers”RecordingAllowed”

#$strFilter = “(&(objectCategory=Group)(SamAccountName=” + $args[0] +”))”
$strFilter = “(&(objectCategory=Group)(SamAccountName=CSLyncRecordingUsers))”

$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher

$objSearcher.SearchRoot = $objDomain

$objSearcher.Filter = $strFilter

$objSearcher.SearchScope = “Subtree”

$colProplist = “member”

foreach ($i in $colPropList)

{[void] $objSearcher.PropertiesToLoad.Add($i)}

$colResults = $objSearcher.FindAll()

foreach ($objResult in $colResults)

{$objItem = $objResult.Properties; $group = $objItem.member}

foreach ($x in $group)

{

# Grant-CsConferencingPolicy $x -PolicyName $args[1]
Grant-CsConferencingPolicy $x -PolicyName “RecordingAllowed”

}

Windows Azure Automation

Windows Azure Automation allows you to automate the creation, monitoring, deployment, and maintenance of resources in your Windows Azure environment. For example, by default Azure Automation comes with a default Azure runbook containing over 350 Azure powershell commands that you can schedule for automation. You will also be able to import other runbooks to automate non-Azure assets, or create your own.

“Azure Automation provides an orchestration feature set for public cloud resources that is similar to what the Service Management Automation (SMA) engine provides for on-premises private cloud resources via the Windows Azure Pack and System Center 2012 R2 Orchestrator.” – Keith Mayer (from his excellent blog on Automation here).

I looked into this service because I wanted a solution to shut down my demo VM’s running in Azure on a nightly basis.

The first step is to logon to the Azure Account Portal and sign in with your subscription information:

https://account.windowsazure.com

Then click Preview Features and click the “Try it now” button

A pop-up will appear informing you that the feature will be added to your subscription soon.

Now logon to the Azure Management Portal. If you were previously signed in, you must sign out and back in before you’ll see the Automation option appear in the menu.

https://manage.windowsazure.com

Click ‘Create an automation account’

At the time of preview, it is only available in East US.

To get started with your first “Hello World” runbook, follow the guidance online (here).

There are currently 20 powershell commands for managing Azure Automation available (here).

There are 30 runbooks in the Technet script gallery that have been written by the community for use in Azure Automation available (here).

I found a runbook on the Technet script gallery (here) written by Peter Selch Dahl for stopping all VMs.

However, after reading the rest of Keith Mayer’s blog, I decided to just follow his article. http://blogs.technet.com/b/keithmayer/archive/2014/04/04/step-by-step-getting-started-with-windows-azure-automation.aspx