Haiku #107

I'm sorry that I

Didn't call. You can blame my

Access policy.

 

In case you haven't been following the news lately, in the past couple of weeks the New York state Department of Health issued guidelines for summer camps, guidelines that include a list of activities deemed too dangerous for children to participate in. Among the activities on that list: kickball, Wiffle ball, and freeze tag.

 

Just in case you aren't familiar with freeze tag, freeze tag a variation on the good old-fashioned game of tag. In plain old tag (which apparently is not too dangerous for children to participate in) one person (known as "it," although not be to confused with Cousin It) runs around and tries to tag the other people in the game. If you get tagged, then you become it.

 

Note. Now that you mention it, while it might not be dangerous it does sound kind of stressful, doesn't it? Those poor kids.

 

In freeze tag, people who get tagged don't become it. Instead, they have to freeze; that is, they have to remain motionless at the very spot where they were tagged, at least until another player comes along and unfreezes them. To "unfreeze" someone all you have to do is touch them. Apparently something in the freezing/unfreezing process is too dangerous for most people. Unless you are a highly-trained freeze tag professional, do not try that home.

 

Note. Does the author of today's haiku agree that freeze tag is a dangerous activity? No, not really. After all, he sits motionless in the same spot at work every day, not doing anything, not even moving a muscle, and he never seems to get hurt.

 

Well, unless you count his annual performance review.

 

So if you can't play freeze tag or Wiffle ball (Wiffle ball!) in the state of New York what can you do? To be honest, we don't have a complete list of the acceptable activities, although we do know that Frisbee is considered safe. (Despite this study, which appeared in the Wisconsin Medical Journal.) Also considered safe (as far as we know, anyway) is this: running the CsExternalAccessPolicy cmdlets. Which is obviously a good thing to know: after all, later this summer, when the kids are just lying around playing video games, you can tell them, "Kids, it's a beautiful day today. Go outside and run the CsExternalAccessPolicy cmdlets." No doubt they'll complain at first. But once they've gone outside and started playing around with the CsExternalAccessPolicy cmdlets, well, then they'll be singing a different tune.

 

Note. Here at Microsoft, the CsExternalAccessPolicy cmdlets – Get-CsExternalAccessPolicy, Grant-CsExternalAccessPolicy, New-CsExternalAccessPolicy, Remove-CsExternalAccessPolicy, and Set-CsExternalAccessPolicy – are informally known as the "Freeze Tag of Microsoft Lync Server 2010."

 

So what's there to love about the CsExternalAccessPolicy cmdlets? A better question would be this: what isn't there to love about the CsExternalAccessPolicy cmdlets? As the name implies, the CsExternalAccessPolicy cmdlets provide a way for you to manage your external access policies. What are external access policies? Well, suppose you've set up your Edge Servers and you've enabled federation and set up all your allowed domains and purchased any licenses you might need to communicate with public instant messaging services and done all the other stuff that you might need to do to allow your users to communicate with the outside world (or simply to log on from the outside world; that is, from outside your organization's firewall). Does that mean that now your users can communicate with the outside world? No. That's because the ability of individual users to communicate with the outside world (or to log on from outside the internal network) is controlled by external access policies. And, by default, the global external access policy prohibits all these activities.

 

Note. No, as far as we know, the New York state Department of Health did not write the global external access policy. But it does seem like more than just a coincidence, doesn't it?

 

If you want to extend some of these capabilities to your users, you'll need to either modify the global external access policy, or create some new external access policies. (These policies can be created at either the site scope or the per-user scope.) When working with an external access policy, you have four key properties available to you:

 

· EnableFederationAccess. When set to True, this allows users to communicate with users from a federated organization.

· EnableOutsideAccess. When set to True, this allows users to log on to Lync Server over the Internet, and without having to first log on to the internal network.

· EnablePublicCloudAccess. When set to True, this allows users to exchange instant messages with people who have SIP accounts on a public Internet connectivity provider such as MSN or AOL.

· EnablePublicCloudAudioVideoAccess. When set to True, this allows users to conduct audio/video conversations with people who have accounts on a public Internet connectivity provider.

 

Pretty cool, huh? So let's say you want all your users to have all these capabilities. How can you do that? Simply by using Set-CsExternalAccessPolicy to modify the global external access policy:

 

Set-CsExternalAccessPolicy -Identity global –EnableFederationAccess $True –EnableOutsideAccess $True – EnablePublicCloudAccess $True –EnablePublicCloudAudioVideoAccess $True

 

Your kids are going to love this!

 

And because you can create new policies at the site scope or the per-user scope, you can do all sorts of other fun things with the CsExternalAccessPolicy cmdlets. For example, suppose you'd like all your users to be able to log on via the Internet, but you only want the Sales department to be able to communicate with federated users. How can you do that? Well, first, you can modify the global policy to allow outside access:

 

Set-CsExternalAccessPolicy -Identity global–EnableOutsideAccess $True

 

After you've done that, you can create a new per-user policy that allows both outside access and federation access:

 

New-CsExternalAccessPolicy -Identity SalesExternalAccessPolicy –EnableFederationAccess $True –EnableOutsideAccess $True

 

And then all you have to do is use the Grant-CsExternalAccessPolicy cmdlet to assign the new policy to the appropriate users. For example, this command assigns the new policy to every person in the Sales department:

 

Get-CsUser –LdapFilter "Department=Sales" | Grant-CsExternalAccessPolicy –PolicyName SalesExternalAccessPolicy

 

Hey, who even needs Wiffle ball, right?

 

Note. Well, OK, the author of today's haiku does: he still plays Wiffle ball any chance he gets. But most people probably can get by without it now that they now about the CsExternalAccessPolicy cmdlets.

 

While we're at it, here's a little tip that might come in handy. By default, Microsoft Lync requires encryption for all audio/video conversations. That can be a problem if you enable public cloud audio/video: some of these public Internet services don't support audio/video encryption. If you try to start an audio/video conversation with someone on one of these services, the call will fail, and an event will be recorded on the Front End Server telling you that the encryption levels don’t match.

 

So is there a way to work around this? As a matter of fact, there is. Just modify Lync Server so that encryption is supported, but isn't required:

 

Set-CsMediaConfiguration –Identity global –EncryptionLevel SupportEncryption

 

Is it a good thing or a bad thing to no longer require encryption? That's something you'll have to decide for yourselves.

 

So there you have it: the CsExternalAccessPolicy cmdlets. Twice as much fun as freeze tag, and nowhere near as dangerous! See you tomorrow.