So I came up with a quick and easy low impact way to suspend a Lync user so that I can lock a user out of Enterprise Voice without changing any dial plans or DIDs on the user. $UPN is the userPrincipalName (i.e. mharrison@nextuc.com) of the user.

Set-CsUser -DomainController $fqdDomainController -Identity $UPN -AudioVideoDisabled $True -EnterpriseVoiceEnabled $False

Then to re-enable the user we just do the opposite

Set-CsUser -DomainController $fqdDomainController -Identity $UPN -AudioVideoDisabled $False -EnterpriseVoiceEnabled $True

If you need to suspend a whole company (i.e. OU) so that the users can’t login to Lync you can use this command where $distinguisedName is the full LDAP path to the OU:

Get-AdUser -Server $fqdDomainController -Filter * -SearchBase $distinguishedName -SearchScope OneLevel | Disable-ADAccount

To turn a company back on you use:

Get-AdUser -Server $fqdDomainController -Filter * -SearchBase $distinguishedName -SearchScope OneLevel | Enable-ADAccount

These two commands basically get all the users (-Filter *) in an OU and pipes it to Enable-ADAccount or Disable-ADAccount.

I hope these tips help and let me know if you have questions or any tips of your own to share.

I work for a company that hosts Lync. We have a web based portal that allows clients to setup their Lync accounts (creates OU and users, enables for conferencing and enterprise voice etc.). The portal calls a web service which then calls a PowerShell script that has functions for dealing with the AD and with Lync.

The Problem:

The portal sometimes kicks off simultaneous calls to the web service that end up running the same backend PowerShell scripts. I make extensive use of logging in the web service for debugging purposes. From the log fragment below you can see that two simultaneous calls were made on separate threads ( [5] & [6] ). The lines in bold are the command lines sent to the PowerShell script and are written out in the line of code that immediately precedes the line to execute the PowerShell script. If you follow the threads you can see that thread [6] returned nothing meaning that the user didn’t exist (problem occurs regardless of if the users exist or not). But thread [5] fails with the “invalid enumeration context” message. If you try to rerun the command line that failed it will work. The problem only occurs with simultaneous calls to the Get-CTUser function. Basically Get-CTUser is a wrapper for the AD PowerShell Get-ADUSer cmdlet.

2012-03-23 13:11:55,404 [5] DEBUG – Begin GetCTUser
2012-03-23 13:11:55,404 [6] DEBUG – Begin GetCTUser
2012-03-23 13:11:55,435 [5] INFO  – Getting user willy@uc.com
2012-03-23 13:11:55,435 [6] INFO  – Getting user admin@uc.com
2012-03-23 13:11:55,451 [5] DEBUG – Begin RunScript
2012-03-23 13:11:55,451 [6] DEBUG – Begin RunScript
2012-03-23 13:12:08,338 [5] DEBUG – Get-CTUser -container ‘geeks’ -UPN ‘willy@uc.com’
2012-03-23 13:12:08,354 [6] DEBUG – Get-CTUser -container ‘geeks’ -UPN ‘admins@uc.com’
2012-03-23 13:12:08,479 [6] DEBUG -
2012-03-23 13:12:08,479 [6] DEBUG – End RunScript
2012-03-23 13:12:08,479 [6] DEBUG – End GetCTUser
2012-03-23 13:12:08,588 [5] ERROR – GetCTUser The server has returned the following error: invalid enumeration context.

Some searching of the Internet for “invalid enumeration context” showed up several references to the problem. Most of the references I found were from people that were doing things like porting users so they were dealing with large results sets with hundreds or thousands of users and most of the solutions involved setting a page size but that didn’t always work. In my case I’m only after one user but still the problem seems the same. I can’t verify that it is a bug or not but either way I can’t have my PowerShell scripts sending errors back to the portal.

So after some research I decided to use DirectorySearcher to get the user and this approach seems to be working fine in my testing. The DirectorySearcher is really quite easy to use. Basically all you need to do is setup the LDAP path, tell it how deep to search, add which properties to return then tell it what to search for.

function Get-CTUser(
[Parameter(Mandatory = $true)][string]$container,
[Parameter(Mandatory = $true)][string]$upn
)
{
    try
    {
        $Domain = New-Object System.DirectoryServices.DirectoryEntry("LDAP://ou=" + $container + "," +  $defaultHostingPath)
        $Searcher = New-Object System.DirectoryServices.DirectorySearcher($Domain)
        $Searcher.PageSize = 200
        $Searcher.SearchScope = "subtree"

        # Setup the filter to only find the one user
        $Searcher.Filter = "(userPrincipalName=" + $upn + ")"
        # Setup which fields we want to return
        $Attributes = @("distinguishedName", "GivenName", "lastLogon", "mail", "Name", "SamAccountName", "sn", "telephoneNumber", "userAccountControl", "UserPrincipalName")
        # Load the fields inthe properties array
        ForEach($Attribute In $Attributes)
        {
            $Searcher.PropertiesToLoad.Add($Attribute) > $Null
        }
        # Execute the search
        $Results = $Searcher.FindAll()
        # Build the reyrn string
        ForEach ($Result in $Results)
        {
            $ret = $ret + "`nDistinguishedName`t:" + $Result.Properties.Item("distinguishedName")+ "`n"
            $ret = $ret + "GivenName`t`t:" + $Result.Properties.Item("GivenName")+ "`n"
            $ret = $ret + "lastLogon`t`t:" + $Result.Properties.Item("lastLogon")+ "`n"
            $ret = $ret + "mail`t`t`t:" + $Result.Properties.Item("mail")+ "`n"
            $ret = $ret + "Name`t`t`t:" + $Result.Properties.Item("Name")+ "`n"
            $ret = $ret + "SamAccountName`t`t:" + $Result.Properties.Item("SamAccountName")+ "`n"
            $ret = $ret + "Surname`t`t`t:" + $Result.Properties.Item("sn")+ "`n"
            $ret = $ret + "telephoneNumber`t`t:" + $Result.Properties.Item("telephoneNumber")+ "`n"
            $ret = $ret + "userAccountControl`t:" + $Result.Properties.Item("userAccountControl")+ "`n"
            $ret = $ret + "UserPrincipalName`t:" + $Result.Properties.Item("UserPrincipalName")+ "`n"
        }

        return $ret
    }
    catch
    {
        Throw (new-object Exception("Exception Get-CTUser: $_"))
    }

}

The lines of script were I’m building the $ret string is done that way so that I could mimic as close as possible the way that Get-ADUser returns its results. I didn’t want to break anything upstream that parsed the result values.

1. Deploying, Configuring and Administering Microsoft Lync Server 2010 Jump Start

2. Planning and Designing a Microsoft Lync Server 2010  Solution

Enjoy.

It’s March again and that means that it is time for the Orlando Code Camp. Every year about this time the Orlando .Net User Group hosts a code camp. Don’t know what a code camp is? Well, it’s a free one day learning event for programing professionals. The code camp focuses on .Net technologies and all of the sessions are presented by members of the development community. Real every day working developers sharing their expertise.

I’ll be there giving a presentation entitled Administering Lync Using PowerShell. So if you are in the Florida area then register at the link above and come on by.

When enabling a user for enterprise voice you need to assign a DID to the user and you don’t want to use one that is already in use. Bit how do you get a list of DIDs in use? Turns out it can be quite easy.  The following PowerShell command will give you a list of AD users and their phone numbers.

Get-AdUser -Filter * -Properties OfficePhone | FT UserPrincipalName, OfficePhone

If you want to write this to a file then you can just pipe the output to Out-File like this.

Get-AdUser -Filter * -Properties OfficePhone | FT UserPrincipalName, OfficePhone | Out-File c:\hosting\ListDIDs.txt

Since this relies on Get-AdUser you will need to make sure the cmdlet is available. You can do that by importing the AD libraries like this:

Import-Module “ActiveDirectory”

As always I hope this helps and please leave me comments if you have any tips of your own.

Jacksonville Code Camp

That’s Joe Healy in the orange shirt and he is probably the greatest Microsoft Developer Evangelist that ever lived. Joe has really grown the Florida developer community and is the main reason we have 5 or 6 code camps every year as well as several SQL Saturdays. Thanks Joe.

The Orlando .NET Code Camp is scheduled for march 31st and I have submitted a session ( Administering Lync Server 2010 using PowerShell) for that. I’ve spoken at the Orlando event several times and they always put on a great event. If you are in or going to be anywhere near to Orlando at the end of March you should add it to your calendar. I’ll provide more details later.

I’ve been using this for about 2 weeks now with no real problems. I’m finding that NextUC when integrated with Office 365 handles all of my collaboration needs. I worked on the backend for this integration which was a great learning experience for me as I got familiar with the Lync PowerShell cmdlets needed to configure the integration. The more I mess around with Lync PowerShell the more I appreciate the effort that Microsoft has put into it. I do almost as much development in PowerShell these days as I do in C# or java.

Since I now have the Lync Mobile Client on my Windows Phone I have IM and collaboration whereever I go. I love being able to stay in contact and join conferences when I am on the go. If you haven’t downloaded a client for your mobile device (I also have it on my Ipad) then what are you waiting for?

Anyway, this feature should be coming soon for all NextUC users

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 –DelgateComputer *

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.