GotSpeechGuy

Recently I had a problem with some of my PowerShell functions that call Enable-CsComputer in that things didn’t get enabled as we expected them to. I’m not sure if it was a timing issue or a replication problem but it showed up when a client tried to add a custom domain. My PowerShell script run on the Lync SQL Server so the network administrator decided that since he could manually fix the problem by running Enable-CsComputer on the Front End server that my scripts needed to do the same thing.

So I set about figuring out how to remotely execute something on the FE. As it turns out there are a few ways of doing this but I quickly ran into problems. First I tried using New-PSSession and Get-PSSession to open up a remote session on the FE but that ran into some credential issues – it would popup a login window. That approach wouldn’t work as you can’t have login windows when the function is called from a web service like I need to do. It also had a problems in that when you import the Lync module for the remote session not all of the Lync cmdlets are exposed. In fact it turned out to be a very small subset and Enable-CsComputer wasn’t one of the cmdlets.

I was told that that was to be expected as Enable-CsComputer isn’t supposed to be run remotely. It is a local command only. Ok, what does that mean to me? It meant that I somehow had to find a way to run it as a local command on the FE. So it was back to the drawing board. I ended up solving my problem using Invoke-Command though even that had a few hurdles that I had to get over. I still had the credentials issue but that was easily fixed (or so I thought) as shown in the code below. I’ll get back the the credentials stuff in a moment but first this is the code I ended up with.

# Remoting variables
$remoteUserName = “GotSpeechGuy\Administrator”
$remotePassword = “P@ssw0rd”
$remoteFE = “GotSpeechGuyFE01″

$pass = ConvertTo-SecureString $remotePassword -AsPlainText -Force
$cred = new-object System.Management.Automation.PSCredential($remoteUserName, $pass)

Invoke-Command -ComputerName $remoteFE -Authentication CredSSP -Credential $cred -ScriptBlock { C:\hosting\EnableComputer.ps1 }

All the EnableComputer.ps1 did was load the Lync module then call Enable-CsComputer. Loading the Lync module is easy done like this -

Import-Module ‘C:\Program Files\Common Files\Microsoft Lync Server 2010\Modules\Lync\Lync.psd1′

During testing I put a Get-CsSipDomain in the script and that worked fine returning a list of the Sip domains. I thought “Cool this is going to work”. But when I put the Enable-CsComputerin the script and tried to invoke it I got this error:

WARNING: Enable-CsComputer failed.

WARNING: Detailed results can be found at

“C:\Users\Administrator.UBERUSEE\AppData\Local\Temp\Enable-CsComputer-8d3bf7e0-9b09-4989-a656-334a9485543c.html”.

Command execution failed: An error occurred when add “RTCUniversalServerAdmins” to “RTC Local Administrators”.    + CategoryInfo          : InvalidOperation: (:) [Enable-CsComputer], DeploymentException    + FullyQualifiedErrorId : ProcessingFailed,Microsoft.Rtc.Management.Deployment.ActivateMachineCmdlet

Checking the .html error page showed me this:

Error: Active Directory error “-2147016672″ occurred while searching for domain controllers in domain “GotSpeechGuy.com”: “An operations error occurred. “

More research showed that when running the cmdlets remotely you only get the local admin context on the remote computer. A lot of the Lync cmdlets access AD or another computer and when that happens you get the dreaded 2-hop authentication problem.

Luckily for me Invoke-Commandhas an –Authentication  parameter which I set to CredSSP but that left a few more steps to complete the process as I still needed to enable CredSSP on the servers. That was pretty straight forward as all it took was to delegate the users credentials from the client to the server.

On the FE I ran these commands:

Enable-WsManCredSSP –Role Server

Enable-WsManCredSSP –Role Server

Enable-WsManCredSSP –DelegateComputer * -Role Client

Then on the SQL Server where the PowerShell scripts reside I ran this:

Enable-WsManCredSSP –Role Client –DelegateComputer *

After going through the steps to enable CredSSP everything started working as it should and we haven’t encountered the problems with Enable-CsComputersince.

I would like to publicly think the guys at Microsoft and my fellow Lync MVPs who helped me sort al this out. It was a long difficult process bringing all of the pieces together but with their help I got it working.

If you have any questions please feel free to ping me.