Cutting edge. On the
Edge. The edge of night. Edgewise.
A couple of years ago, when the author of today's haiku joined the Lync Server documentation team, he attended his first-ever team meeting. At that meeting, his manager said, "We need to do some more documentation on Edge servers. Would anyone like to volunteer to do that?" Silence filled the room, and no one moved a muscle lest that one involuntary movement be considered a sign that you were volunteering to try and explain the ins and outs of Edge servers to a waiting world.
Two years later, the author of today's haiku was sitting in a meeting of the Lync Server PowerShell blog team when he said, "We need a haiku on the CsAccessEdgeConfiguration cmdlets. Would anyone like to volunteer to do that?" Once again, silence filled the room.
Documenting Edge servers is one of those things that everyone agrees needs to be done – just as long as someone else does it. Edge servers can definitely be … interesting … to work with, and even more … interesting … to try to explain. Fortunately, though, there's one man in this world brave enough to tackle the CsAccessEdgeConfiguration cmdlets.
But then he phoned in sick this morning, which left it up to the author of today's haiku.
Now, at first glance, you might not think that discussing of the CsAccessEdgeConfiguration cmdlets would be all that difficult; after all, there are only two CsAccessEdgeConfiguration cmdlets: Get-CsAccessEdgeConfiguration and Set-CsAccessEdgeConfiguration . But as we're about to see, there's an unexpected plot twist involving Edge server configuration settings that will keep you on the "edge" of your seat!
To begin with, we should note that you can have only one global set of Edge server configuration settings: you don't see a New-CsAccessEdgeConfiguration cmdlet because you're not allowed to create any new Edge server configuration settings. Instead, you get one collection of global settings, and all your Edge servers must abide by those settings.
One nice thing about being limited to a single collection of Edge server configuration settings is this: it makes it really easy to run the Get-CsAccessEdgeConfiguration cmdlet. Need information about all your Edge server configuration settings? We can help you with that:
That's not only all you need to do with the Get-CsAccessEdgeConfiguration cmdlet, that's pretty much all you can do with the Get-CsAccessEdgeConfiguration cmdlet.
Things get a little trickier when it comes to the Set-CsAccessEdgeConfiguration cmdlet. Why is that? Well, as it turns out, there are two different ways to configure your Edge servers, with both of the ways based on the routing method you use:
· DNS server routing , in which Edge servers rely on DNS records when handling sending and receiving federation requests.
· Default routing , in which you must specify the fully qualified domain name (FQDN) of the server used for federation requests.
Neither of those options are particularly hard; the tricky part is recognizing that the parameters and the settings that are available to you will vary depending on which routing method you choose. For example, if you decide to switch to default routing, you absolutely must include the DefaultRouteFqdn parameter, which specifies the FQDN of the server that handles your federation requests. For example:
Set-CsAccessEdgeConfiguration -UseDefaultRouting -DefaultRouteFqdn "atl-edge-001.litwareinc.com"
Likewise, if you decide to use DNS server routing you are required to use the EnablePartnerDiscovery parameter, a parameter that specifies whether Lync Server will use DNS records to try to discover partner domains not listed in the AllowedDomains list. (If you set this parameter to False then you will only be only be able to federate with domains included on your Allowed Domains list .) In other words:
Set-CsAccessEdgeConfiguration -UseDnsSrvRouting -EnablePartnerDiscovery $True
Again, not too terribly difficult; you just need to keep track of which parameters are required with which routing method. Fortunately, there aren't too many of these parameters too worry about:
Default routing (UseDefaultRouting)
DNS Server routing (UseDnsSrvRouting)
What happens if you mix and match these parameters? For example, what happens if you run a command like this one that uses the VerificationLevel parameter along with the UseDnsSrvRouting parameter:
Set-CsAccessEdgeConfiguration -UseDnsSrvRouting -EnablePartnerDiscovery $True –VerificationLevel AlwaysVerifiable
Here's what's going to happen: the command will fail, and you'll get the following error message:
Set-CsAccessEdgeConfiguration : Parameter cannot be resolved using the specified named parameters.
Oh, and just to make things even more interesting, there are also two parameters that you should never use (unless someone from Microsoft, and we mean someone who knows what they're doing, not someone from the Lync Server PowerShell blog tells you to use them): BeClearinghouse and OutgoingTlsCountForFederatedPartner. What happens if you do use them? Well, to tell you the truth, we don't know. The last tester who tried using them was never heard from again.
Incidentally, Set-CsAccessEdgeConfiguration does have a number of other parameters that can be used with either routing method. Those parameters include the following:
· AllowAnonymousUsers. Indicates whether or not anonymous users are allowed to join meetings and conferences.
· AllowFederatedUsers. Indicates whether internal users are allowed to communicate with users from federated domains, and whether internal users can communicate with users in a split domain scenario.
· AllowOutsideUsers. Indicates whether users can access Lync Server from outside the firewall and across the Internet.
So, see, it's not all doom-and-gloom; in fact, the CsAccessEdgeConfiguration cmdlets are actually incredibly useful, especially for anyone who wants to extend the range of Lync Server 2010 beyond their internal corporate network.
So was writing this article about Edge servers really the bravest, most daring and death-defying thing the author of today's haiku has ever done? You know, now that we think about it, it is. Hmmm ….
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.