Share via

The Difference Between Grant-Cs* Cmdlets and Set-Cs* Cmdlets

  • Article

What's the different between the Grant-Cs cmdlets and the Set-Cs cmdlets? Are there any Grant-Cs cmdlets that don't deal with policies?

At last: an easy question to answer! When it comes to policies, the Set-Cs cmdlets are used to make a change to an actual policy. For example, one of the properties of an external access policy is EnableFederation, which (when True) allows users to communicate with people who belong to a federated organization. By default, EnableFederation is set to False. If you wanted to take your global policy and enable federation, you'd use the Set-CsExternalAccessPolicy, like so:

Set-CsExternalAccessPolicy –Identity global –EnableFederation $True

The Set-Cs cmdlets are always used to modify existing objects.

Note. Well, OK: not always. There are some oddball cases, like the E9-11 cmdlets, in which the Set-Cs cmdlets can either modify existing objects or create new objects. But most of the time (by far most of the time) the Set-Cs cmdlets are used to modify an object that already exists. That's definitely the case with policies.

So then what are the Grant-Cs cmdlets for? Well, when it comes to policies, these cmdlets are used to assign per-user policies to people or groups of people. (And yes, this is only for per-user policies: global, site, and service policies do not have to be assigned. For more information, see the aptly-named article Assigning Policies.)

For example, suppose we used the New-CsExternalAccessPolicy cmdlet to create a new per-user policy named RedmondExternalAccess. Suppose we later used the Set-CsExternalAccessPolicy cmdlet to change some of the property values of that policy. Now we'd like to assign that policy to Ken Myer; that way, Ken will be able to do whatever that policy allows him to do (e.g., communicate with people who belong to a federated organization). To assign the policy, we need to use the Grant-CsExternalAccessPolicy cmdlet:

Grant-CsExternalAccessPolicy –Identity "Ken Myer" –PolicyName "RedmondExternalAccess"

We're the first to admit that Grant is not the most intuitive verb that could be used to describe what these cmdlets do. Originally these cmdlets used the verb Assign; for example, we had the Assign-CsExternalAccessPolicy cmdlet. For better or worse, however, Assign is not one of the officially-approved Windows PowerShell verbs, which meant we had to replace Assign with something else. Based on the available choices (Checkpoint? Unregister?), Grant seemed like the best bet.

So that's the difference between the Grant-Cs and the Set-Cs cmdlets, at least when it comes to policies. Now let's tackle question 2: are there any Grant-Cs cmdlet that don't deal with policies?

Well, yes, there are: Grant-CsOUPermission and Grant-CsSetupPermission. These two cmdlets are used to grant predefined security groups the Active Directory permissions needed to manage Lync Server. There's a good chance you'll never have to run either of these cmdlets because, by default, Setup grants those permissions for you. However, if you've locked down your domain (by doing something like disabling permission inheritance) you might need to use them. Grant-CsOUPermission and Grant-CsSetupPermission do something similar to the other Grant-Cs cmdlets (they assign permissions rather than assign policies) but there's one major difference: as we noted, these two cmdlets assign permissions to predefined security groups instead of to users or groups of users. There's no way to assign setup permissions to, say, just Ken Myer. Instead, setup permissions get assigned to the RTCUniversalServerAdmins, and there's no way to change that.

By the way, don't be fooled by the Grant-CsDialPlan cmdlet: that one works just like the other policy cmdlets, primarily because it is a policy cmdlet. In order to remain consistent with the terminology used in Microsoft Exchange we use the term dial plan instead of, say, dialing policy, but a dial plan is actually a policy. (In Office Communications Server it was known as a location profile.) Or, to be a little more specific, it can be assigned to users or groups of users the way policies can.

But that's another story for another day. For now, just consider the dial plan to be a policy (despite the name) and everything will be right with the world.