Haiku #39

Cold, calculated,

Ruthless, and unstoppable.

It's The Director.

We have to admit that most Microsoft Lync Server 2010 components don't sound very intimidating; in fact, some of them (Mediation Server) sound downright cute and cuddly. But then there's this: The Director! Now there's a server role for you. The Director always reminded us of The Terminator, the evil robot sent from the future to destroy the world.

Note. Have you ever noticed that, in the future, all the robots seem to be evil? (Remember the evil duplicate robots in Bill and Ted's Bogus Journey?) Wouldn't it make sense for us to stop making robots now, so that, in the future, there won't be any evil ones that can be sent back in time to destroy us?

As far as we know, there's nothing evil about The Director; in fact, the Director actually seems like a handy little thing to have. (Maybe not as cute and cuddly as an Application Server, but still useful.) Directors are designed not to destroy the world, but to authenticate users and respond to user requests. Admittedly, that sounds a lot like a Front End server, but there is a difference: Directors do not host user accounts. Instead, Directors are typically used by organizations that allow external access to the network through Edge Servers. When used by organizations like that, Directors server two purposes: 1) they help alleviate the strain on Front End servers by handling authentication requests; and, 2) they help shield the internal network from denial-of-service attacks and other malicious traffic.

Directors are also useful any time multiple Front End servers are deployed in a central site. In that case, Directors receive all user requests and then channel those requests to the appropriate server pool. This, again, helps to ease the burden placed on the Front End servers.

But destroy the world? No. Maybe in a future release of Lync Server. But not on Lync Server 2010.

Ah, but what if there's a bug in Lync Server that will cause a Director to try and destroy the world? Well, to be honest, that's pretty unlikely. However, just to be on the safe side, Lync Server includes the Set-CsDirector cmdlet, which provides a way for you to manage Directors. For example, you can set the port number used for SIP traffic and/or Web services traffic; you can also indicate which Archiving Server, Edge Server, Monitoring Server, and Web Server the Director should be associated with. And just how do you go about doing these things? Well, like this:

Set-CsDirector –Identity Director:atl-director-001.litwareinc.com –SipPort 5072

In this example, we're changing the SIP port for the Director atl-director-001.litwareinc.com to 5072. That's about as complicated as it gets.

The only thing that's even sort of complicated is the fact that there is no Get-CsDirector cmdlet; if you want to get back information about your Directors you need to use the Get-CsService cmdlet:

Get-CsService –Director

Why do you have to use Get-CsService rather than using a Get-CsDirector cmdlet? We asked that question once ourselves, and the answer was this: you don't want to know.

Note. Actually, we did want to know; that's why we asked the question in the first place. But we decided to just go with the flow and not worry about it. After all, we didn't want someone sending an evil robot from the future after us. We have enough things to deal with as it is.

Oh, and before we go, there's one other thing about the Set-CsDirector cmdlet that's good to know: Set-CsDirector doesn't accept pipelined input. Why is that good to know? Well, suppose we wanted to change the SIP ports for all our directors to port 5072. You might think that this command would do the trick:

Get-CsService -Director | Set-CsDirector –SipPort 5072

Unfortunately, that command won't work. Instead, you get back an error message like this one:

Set-CsDirector: The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties did not match any of the parameters that take pipeline input.

Which is just our way of saying that you can’t use Get-CsService to return information about all your Directors, then pipe all that information to the Set-CsDirector cmdlet. Set-CsDirector just plain doesn't know what to do with pipelined data.

Fortunately, though, the ForEach-Object cmdlet does know what to do with pipelined input. If you want to change the SIP port for all your Directors, a command like this one will work:

Get-CsService -Director | ForEach-Object {Set-CsDirector -Identity $_.Identity -SipPort 5072}

We got that example from one of the rare good robots who have been sent back from the future, so we're pretty confident it will work. This, by the way, is the approach you'll need to use when doing bulk updating for most of the server roles (User Server, Registrar, Management Server, PSTN Gateway, etc.) that are returned by the Get-CsService cmdlet.