Haiku #83

Cutting edge. On the

Edge. The edge of night. Edgewise.

CS AccessEdge.

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.

Note. Of course, that was because he was the only one who actually showed up for the meeting; he later found out that this was an April's Fool joke and the two-person Lync Server PowerShell blog team doesn’t actually hold documentation meetings. But that's beside the point.

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!

Note. Ha. Get it? "Edge of your seat," because we're talking about Edge servers? OK, never mind. Forget we even mentioned it.

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.

Note. We should probably clarify that the CsAccessEdgeConfiguration cmdlets are used to manage your Access Edge servers, the servers you use to extend the capabilities of Microsoft Lync Server 2010 to people who are not logged on to your internal network. That's different from A/V Edge Servers (managed by using the CsAVEdgeConfiguration cmdlets). That kind of Edge server is used to do things like allow internal users to share audio and video with external users. A/V Edge servers can be configured at the site and service scope as well as the global scope. Access Edge servers (the kind we're talking about today) can be configured only at the global scope.

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:

Get-CsAccessEdgeConfiguration

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)
DefaultRouteFqdn VerificationLevel	EnablePartnerDiscovery

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.

Note. Just kidding. But don't use those parameters unless some official Microsoft support person tells you to use them.

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 ….