Enabling and Disabling

Enabling users in the SBSCP is relatively straightforward.

1. Open the SBSCP as a user with CSAdministrator or CSUserAdministrator rights and click the Users tab. In the main pane, click Enable Users, which will open the main page to select and enable users, as shown in Figure 12.4.

2. Click Add and locate the user or users you want to enable through the searching methods that were described earlier in the chapter. Once you have located and selected the relevant users, click OK.

   Note that multiple users can be selected either in one block using the Shift+click method or individually using the Ctrl+click method, which should be familiar from Windows Explorer.

3. You should be back in the main configuration page shown in Figure 12.4, this time with users listed in the Users section. You must assign the users to a Registrar pool. In Figure 12.4, this will be se01.rlscomms.net, which is the only pool available in the drop-down; however, your organization may have pools in different locations around the world. You must also select a method to generate a SIP uniform resource identifier (URI). We will cover these choices in more depth later when discussing how to enable the user from PowerShell. At this point, you will simply select Use User’s Email Address because you know the email address field is populated with an address that fits the naming scheme of the SIP domain, @rlscomms.net.

   You could now simply accept the defaults and click Enable to finish setting up the users; however, you should be aware of a few other settings.

4. The Telephony section allows you to configure the way in which the user can use Skype for Business features to make telephone calls. The default is PC-To-PC Only, which is what you should leave set for the user. This setting allows voice and video calls to be made only within the Skype for Business system between machines with the relevant client installed. Other options are to enable coexistence with a third-party PBX, to configure the user to use Skype for Business as a PBX, or to disable audio and video entirely. These settings will be covered in more detail in Chapter 16, “Getting Started with Voice.”
5. The rest of the settings you can configure on this page enable you to assign immediately the various policies Skype for Business provides to enable control of the user environment. For now, leave them at the default settings. We will discuss many of the policies in much more depth later in this chapter; at that point, you can come back and change those policies assigned to users if you like.
6. After you’ve looked through all the settings available, click Enable to make the users selected live on Skype for Business.

Although the SBSCP is fine for enabling a single user, and even acceptable for doing them in bulk, some people just love to do things from the shell. For those people, here’s how you enable a user from PowerShell. As discussed earlier, you need to locate the relevant user or users. When working in PowerShell, that means using the Get-CsAdUser cmdlet, unless you know the display name of the user, in which case you can simply start with the Enable-CsUser cmdlet. In this case, you know the display name is Test User1, so you can move right on; but if you didn’t know the name, you could use the Get-CsAdUser cmdlet to bring back the relevant user or users and pipe the output of Get-CsAdUser into the Enable-CsUser command, discussed next.

As you saw in the SBSCP, certain fields are mandatory. First, of course, you must identify the user or users, using the AD display name, SIP address, user principal name (UPN), or domainSamAccountName. Again, in this case, you can stick with AD display name. Next, you need to specify the Registrar pool and the SIP address. In this simple example setup, this is pretty straightforward because there is only one Registrar pool (se01.rlscomms.net). The choice of SIP address is possibly more complex. As a rule of thumb, the SIP address should match the email address of the user if at all possible. However, unless Exchange is installed, the email address field might not be populated. Make sure it is for the user account you will be creating so you can use it later. In this example, Test User1 is set up with the email address [email protected].

To enable the user, use the following command:

Enable-CsUser -Identity "Test User1" -RegistrarPool ↵
se01.rlscomms.net SipAddressType EmailAddress

This command will enable the user Test User1 for Lync on the se01.rlscomms.net pool with a SIP address matching the email address [email protected]. The one parameter here that may not be immediately obvious is SipAddressType. It could have been very specific, used the SipAddress parameter, and manually specified the SIP address testuser1@rlscomms .net; however, the SipAddressType parameter is potentially more useful because it allows various options to form the SIP address. One thing you will note is that when you use certain SipAddressType settings, you will need another parameter, SipDomain. In this environment, things are simple with only the one SIP domain. However, large organizations commonly need to support multiple domains, perhaps to represent different brands or company units.

The options for SipAddressType are as follows:

• EmailAddress: As shown previously, this uses the email address from the user in AD and doesn’t require the SipDomain parameter.
• SamAccountName: This uses the SamAccountName from AD and does require the SipDomain parameter to specify the suffix of the name after the @ sign.
• UserPrincipalName: This uses the UPN of the user in AD and, because the UPN is in the same form as an email address, doesn’t require the use of the SipDomain parameter.
• FirstLastName: This takes the first and last name of the user and puts a period between them—in our example, test.user1. It requires the use of the SipDomain parameter.

You now know how to find and enable users for Skype for Business. As you have seen, the SIP address is key. This forms the unique ID and is what makes users show up in searches carried out for Skype for Business–enabled users. On occasion this can cause unintended results, as you might ask yourself what happens if a user already has a SIP address populated in their msRTCSIP-PrimaryUserAddress attribute. This could have happened as part of a previous deployment when the user maybe became orphaned. Thankfully, there is a PowerShell command that can help identify these users and get them all set up for Skype for Business.

Get-CsUser –UnassignedUser | Select-Object DisplayName

When run, this command will identify any users who have a SIP address but are not assigned to a Registrar pool. It will then output their display name. You could, of course, simply pipe the output to the Enable-CsUser cmdlet and get them set up directly for Skype for Business.

Making Changes to Users

Now that you’ve enabled some users for Skype for Business, you no doubt feel suitably pleased. However, it won’t be long before the changes start rolling in. For example, someone might move to a different office or even a different country and be served from a different pool. Another typical occurrence is when a name changes because of marriage, and of course, people will leave your organization temporarily or permanently and their accounts will need to be disabled and then deleted. As with all the other user administration tasks, the first requirement is to make sure you target the relevant user or users; that is where the search skills you’ve learned come in handy.

The SBSCP is well laid out, so by now you should be pretty familiar with it. On the Users tab, search for the user you need to alter. Once you’ve selected it, you can explore the available options and find the Edit and Action drop-downs.

The Edit drop-down is straightforward. It gives you an easy option to select all the users returned by a search, after which you can move to the options on the Action menu, which we’ll discuss shortly. Other than that, the only option is Show Details, which takes you to the configuration page for that particular user. This will look familiar from the steps taken to enable the user in the SBSCP described earlier. The Action drop-down gives many more options, as shown in Figure 12.5.

MOVING USERS

As you can see, moving users to another pool is simple. You select the relevant user or users and then, on the Action menu, click the Move Selected Users To Pool entry. This opens a dialog box where you can choose the pool in the drop-down shown in Figure 12.6. There is also a Force check box that should be used if the standard process for moving fails. The standard process of moving users between pools will take across their conferences and buddy lists. If for some reason the source pool is unavailable, you would have to use the Force check box to move the user without this data from the source pool. Be careful, though, because there is a risk of data loss any time the Force parameter is used. This is discussed in more detail in Chapter 15, “Troubleshooting.”

Selecting the Move All Users To Pool option will bring up a dialog that allows you to select both a source pool and a destination pool and enables moving all users from the source to the destination, as shown in Figure 12.7. Again, the Force check box allows scenarios where the source pool isn’t available.

To perform these moves from PowerShell, you would use the Move-CsUser cmdlet, a simple cmdlet. The required parameters are -Identity to target a specific user and -Target to specify the pool to which you want to move the user. There is also the -Force parameter, which provides the same functionality to move users in failure scenarios without taking user data across to the new pool. For example, this command moves Test User1 to the SE02 pool:

Move-CsUser -Identity "Test User1" -Target "se02.rlscomms.net"

Instead of having a separate cmdlet to allow all users to be moved from one pool to another, this time the PowerShell pipe is used for functionality.

Get-CsUser | Where-Object {[String]$_.Registrarpool -eq ↵
"se01.rlscomms.net"} | ↵
Move-CsUser -Target "se02.rlscomms.net"

This command first runs the Get-CsUser command you are familiar with, and using a filter it selects all users on the Se01.rlscomms.net pool. These are then piped to the Move-CsUser cmdlet, which moves them to the se02.rlscomms.net pool.

Set-CsUser -Identity "Test User1" -SipAddress [email protected]

Set-CsUser -Identity "Test User1" -Enabled:$False

Set-CsUser -Identity "Test User1" -Enabled:$True

Disable-CsUser -Identity "Test User1"

In-Band Provisioning

In-band provisioning describes the application of policy to the client through information contained in SIP messages and passed to the client during usage so that settings apply immediately. For a really detailed description of how this works, see the following TechNet article. Note that it describes the process in Lync 2010, which is just as valid for Skype for Business Server 2015.

https://technet.microsoft.com/en-us/magazine/hh219341.aspx

Because of the way policy is applied, different types of clients apply the relevant policy settings to the functionality they offer. Whatever the client, the user will have the same experience because this method of applying policy is as relevant to the browser client as it is to the PC that’s not domain joined and even to the domain-joined PC. Another benefit is that administrators are not constrained to fit Skype for Business policies around another policy engine, such as Group Policy in OCS. Almost all Skype for Business policies can be created and applied either through the SBSCP or through PowerShell (see “What About Group Policy?” later in the chapter for the exceptions). Not using group policies provides greater flexibility because policies can be applied at global, site, service, and user levels, and these policies take effect immediately rather than having to wait for a Group Policy refresh cycle.

Understanding Where Policies Apply

One of the principal benefits of moving to the in-band provisioning model is that Skype for Business policy can closely follow Skype for Business architecture and users, allowing a high degree of granularity. As discussed in Chapter 7, “Planning Your Deployment,” Skype for Business has added to the architectural concepts of OCS 2007 R2 (the organization and the pool) and includes the concept of sites, which generally map to data centers. It is now possible to apply policy at all these levels. Default policies are applied at the Global level, but administrators can create certain types of policies at other levels, such as the site, service, or tag level. Tag-level policies are what allow policy to be assigned to an individual user or selection of users. (As you will see, the search skills you learned earlier can be used to locate users to apply policy to, thereby giving you the ability to specifically target users.)

Of course, all these different levels mean that you need to understand their precedence. The following rules apply:

• If a per-user policy is assigned to the user, then the per-user policy is used.
• If no per-user policy is assigned to the user, then the service policy is used.
• If there is no per-user or service policy, then the site policy is used.
• If there is no per-user, service, or site policy, then the global policy is used.

Simply summarized, the policy set closest to the user wins! Understanding this is important because it has a material effect on which settings are applied to users. For example, certain settings in a policy could be left blank by the administrator to allow the user discretion over how Lync works for them. For example, you could allow the user to choose whether to display a photo by leaving the DisplayPhoto section of the CsClientPolicy blank. But what would happen if you set the DisplayPhoto section of the CsClientPolicy to force the use of the AD stored photo on the global policy but then left that setting blank on a policy closer to the user (that is, site or user tag)? The user would still be able to choose. The whole policy is applied even if settings are blank, not just the settings that have an explicit value.

To understand the various levels more closely, you need to understand the difference between policy name and scope, which defines how policies are referenced using the -Identity parameter in PowerShell. The following are some examples of how different policies are referenced:

• Identity global pulls back the global policy of whichever cmdlet is used.
• Identity site:PolicyName reflects a policy that is assigned to a site.
• Identity registrar:server.domain.xyz reflects a policy that is assigned to a specific service, in this case a registrar.
• Identity Tag:PolicyName reflects a policy that is assigned to users.

You can see clearly the concept of policy name and policy scope. The element in the identity before the colon (:) is the scope; the element after the colon is the policy name. In the case of either site or service scopes, the policy name matches that of the site or service where the policy is to be assigned. In the case of the tag scope, the policy name should describe where the policy will apply. You will see how this works when you create and assign policies later in this chapter.

What About Group Policy?

We’ve mentioned that all policies could be created through SBSCP or PowerShell; however, that is not quite true. When the Skype for Business client starts up, it needs certain bootstrapping settings passed to it. For example, if you are not using autoconfiguration through DNS records, the client would need to be provided the Skype for Business server address to log on to. Another such configuration is to enable or disable the welcome screen that pops up when the client is launched for the first time. Clearly in-band provisioning won’t work in these instances because the client hasn’t logged on or been able to check settings. Therefore, the use of Group Policy is maintained for these client bootstrapping settings only.

To apply these Group Policy settings, you will need to obtain the relevant ADMX (.admx) template file. The Lync16.admx file is available as part of the pack of Office 2016 ADMX files. At this time of writing, it can be downloaded here:

www.microsoft.com/en-us/download/details.aspx?id=49030

Interestingly, although part of Office 2016 and called Skype for Business (rather than just an upgrade), the file is still called Lync16.admx!

You will see that there are 32-bit and 64-bit versions of the download. Don’t worry about this. This is important when you are going to be doing custom installs of Office, but in this case, we will just download the 32-bit version.

The file you download will be called admintemplates_x86_4286-100_en-us.exe. On running the application, you will be prompted to extract the contents to a folder. In the folder where you extract the files, you will find that you have two more folders and a spreadsheet. The spreadsheet is called office2016grouppolicyandoctsettings.xlsx and contains details of every setting that the GPO can control. Ignore the fact that neither Skype for Business nor Lync is listed on the Introduction tab! To locate the Skype for Business settings that can be manipulated, go to the ADMX tab and filter the first column, File Name, to show Lync16.admx only. You will see all the settings that can be set. If you move back to the folder where you extracted the files, you will see the folder called admx. Inside is the Lync16.admx file. There is also a folder called en-us. In here you will find the Lync16.adml file, which is a language-specific file for the Lync GPO template file.

Once you have the template file, you will need to load it into a Group Policy object (GPO), which will then be applied at the level in AD where you want to control settings. This is subject to all the usual constraints, such as delays in policy propagation as mentioned earlier.

Since with Skype for Business you are now dealing with ADMX templates rather than the older ADM templates that Lync 2010 used, the method of use has changed. Instead of manually importing the template into a specific GPO, you now have two options to load the new settings template. You can either add them locally on a single machine or load them centrally and have them replicated to any DC for multiple admins to access. Both processes are described in detail here:

www.petri.co.il/add-administrative-templates-to-gpo.htm

Given that this is Active Directory work, it is out of scope for this book, so we will stick to the simplest method, which allows you to test things by using the local store on one machine. If you are rolling this out in production, then speak with your AD specialist to understand the best method for your network.

1. To load the template into a GPO, on a domain controller (or anywhere else you have the Group Policy Management tools installed), open the %systemroot%PolicyDefinitions folder. Copy the lync16.admx file to this folder. Then open the en-US folder and copy the lync16.adml file in there.
2. Next open the Group Policy Management tool by finding the Group Policy Management app and clicking. On the left pane, drill down into the forest and domain and right-click Group Policy Objects. Select New, as shown in Figure 12.8.
3. Give the policy a name, but don’t select a starter GPO, and click OK.
4. Right-click the new GPO and click Edit. In the left pane, drill down to User Configuration ➢ Policies ➢ Administrative Templates: Policy Definitions (ADMX Files) Retrieved from the Local Machine. One of the folders you will find underneath is called Skype for Business 2016.
5. If you then drill down to the next level, you will find Microsoft Lync Feature Policies, under which all the settings will be visible in the right pane. Each setting is fairly self-explanatory and comes with a useful help article built into the GPO, as shown in Figure 12.9.
6. After you set up the policy as needed, you can apply it to the relevant group of users by using the standard method.

Viewing Policies

You will undoubtedly want to know what policies already exist before you create new ones. Skype for Business comes with a global policy set up for each policy type available, and the default settings are hard-coded into the software. You will see this in action later in the chapter when we discuss what happens if you try to delete a global policy.

Because we discussed some of the policies earlier in this chapter, you already know several of the policy types. In the SBSCP, they are spread out in the various tabs to which they apply. For example, to see the available ClientVersionPolicies, you would navigate to the Client tab in the SBSCP; in the main pane under Client Version Policy, you would see all available policies. This is shown in Figure 12.10.

What you can see is not only the default global policy but also some other more focused policies, which you will create shortly. If you view one of the other policy sections, under the Federation and External Access tab, you can see the External Access policy. If you double-click the global policy, you will see the settings in Figure 12.11. Interestingly, this is one of those areas in the GUI that has changed since Lync 2010 (aside from branding) because external access now includes settings to configure XMPP, more of which is covered in Chapter 21, “Reverse Proxies, Load Balancers and Gateways.”

To change any of the settings, simply check the relevant check box and then click Commit. You can see how easy it is to retrieve policy information and change settings in the SBSCP. If you look carefully enough at all the possible options, you will also notice that some of the more wide-ranging policies like the CsClientPolicy are not visible through the SBSCP.

Given that some of the settings are not available through SBSCP and in keeping with the rest of the book, let’s take a look at how you would use PowerShell to view policies.

As we have already discussed, there are various default global policies. To retrieve one of them, the CsClientPolicy type, you would use a command such as this:

Get-CsExternalAccessPolicy -Identity global

Because you want to retrieve the default global policy, notice the naming convention. Also notice the output of this command, which shows the current settings that you saw in Figure 12.11.

Identity                          : Global
Description                       :
EnableFederationAccess            : False
EnableXmppAccess                  : False
EnablePublicCloudAccess           : False
EnablePublicCloudAudioVideoAccess : False
EnableOutsideAccess               : False

To get the remaining policies, you simply need to identify the relevant cmdlets. Sadly, this is not as simple as it could be because the developers didn’t quite stick to a naming convention. Most of the cmdlets are formatted like the previous one, Get-CsXxxPolicy. However, there are a couple that stand out. First, note that although the Get-CsNetworkIntersitePolicy and Get-CsEffectivePolicy cmdlets follow the relevant naming format, the first actually works with Call Admission Control (CAC) and as such is not related directly to users, and the latter is a new cmdlet enabling administrators to see which set of policies applies to a user. We cover Get-CsEffectivePolicy later in this chapter. The other anomaly is the Get-CsDialPlan cmdlet; although it doesn’t have Policy in the name, it retrieves dial plans related to Enterprise Voice that are applied to users, and it is targeted as the other policy cmdlets are, based on global, site, and user. Dial plans are covered in Chapter 13. With this knowledge, you can run the following command to get a list of all the relevant cmdlets:

Get-Command -Module SkypeforBusiness | Where-Object {($_.Name -like "Get-Cs*Policy" ↩
-or $_.Name -eq "Get-CsDialPlan")} | Where-Object ↵
{$_.Name -notlike "*Effective*"} | Where-Object {$_.Name ↵
-notlike "*Network*"} | Select-Object Name

This command will first get all the commands in the Skype for Business module and then sort through them listing only those that fit the criteria of starting with Get-Cs and ending with Policy. It will omit the Get-CsNetworkIntersitePolicy and Get-CsEffectivePolicy cmdlets and include the Get-CsDialPlan cmdlet. When it is run, you will see the following output:

Name
----
Get-CsArchivingPolicy
Get-CsCallViaWorkPolicy
Get-CsClientPolicy
Get-CsClientVersionPolicy
Get-CsConferencingPolicy
Get-CsDialPlan
Get-CsExternalAccessPolicy
Get-CsHostedVoicemailPolicy
Get-CsLocationPolicy
Get-CsMobilityPolicy
Get-CsPersistentChatPolicy
Get-CsPinPolicy
Get-CsPresencePolicy
Get-CsThirdPartyVideoSystemPolicy
Get-CsUserServicesPolicy
Get-CsVoicePolicy
Get-CsVoiceRoutingPolicy

If you are familiar with Lync 2010 or Lync 2013, you will notice that there are a few new policies in Skype for Business Server 2015 (highlighted in bold in the previous list). First, Get-CsCallViaWorkPolicy is used to define the settings for enabling users to control non-Skype phones, such as legacy PBX devices. Second, Get-CsThirdPartyVideoSystemPolicy is similar to Get-CsVoicePolicy, except it is focused on the settings and interaction with video systems. Now you have a useful list of all the cmdlets that can be used to retrieve policy settings. They all (even Get-CsDialPlan) take the same command structure as shown earlier to get the current global policy settings.

It’s useful to see the current settings for each of the global policies, but sometimes you’ll want to see the default settings. There are a few ways of doing this.

• Check TechNet.
• Create a new, empty policy and retrieve it to display its settings. This method has a disadvantage that we’ll discuss next.
• Create a new policy but use the -InMemory parameter. This is rather clever.

As mentioned, creating a new policy with no parameters other than a name will create a policy using the default settings, as shown in this example:

New-CsClientPolicy -Identity TestDefaultSettings

This command would create a new client policy called TestDefaultSettings. However, you don’t really want to have to create policies every time you want to see the default settings because it would be too easy to forget one and clutter up the system. Fortunately, another option is available. One of the parameters of the New-CsXxxPolicy cmdlets is -InMemory. When appended to the command just shown, it creates a policy but holds it in memory and never writes it to the configuration store. To see this parameter in action, run the following command:

New-CsClientPolicy -Identity TestDefaultSettings -InMemory

This will output the default settings of the client policy but not actually create the policy. Of course, this functionality is not provided just to let you see the default settings of a policy. It will also allow you to create a new policy in memory and assign it to a variable. You can then manipulate the policy settings as you need and put the policy into action, thereby ensuring that the correct settings are applied immediately, as shown in the following example:

$newpolvar = New-CsClientPolicy -Identity NewPolicy1 -InMemory
$newpolvar.DisableEmoticons = $True
$newpolvar.DisablePresenceNote = $True
Set-CsClientPolicy -Instance $newpolvar
$newpolvar = $NULL

What this does is set the variable $newpolvar to the default settings of the NewCsClientPolicy cmdlet, creating in memory a policy called NewPolicy1. Next, you edit certain properties of that variable to disable emoticons, for example. Then you write back those setting with the Set-CsClientPolicy cmdlet, which actually creates the policy. Finally, you end by resetting the variable $newpolvar to Null so that it can’t accidentally be used.

You’ve looked at how to retrieve the global policies and the default settings, but what about easily viewing the other policies of a specific type? The next command will list all policies of a certain type:

Get-CsClientVersionPolicy | Select-Object Identity

This command will list all the CsClientVersionPolicies, as in the output shown here:

Identity
--------
Global
Site:EMEA
Service:Registrar:se01.rlscomms.net
Tag:TestDefaultSettings

Actually, we’ve skipped ahead a little; you’ll learnt to create policies in the next section, but it’s not very interesting to show only one line of output!

This output nicely demonstrates the naming conventions showing scope and assignment. The Tag:TestDefaultSettings entry is ready to be assigned to users.

Creating and Assigning Policies

So far we’ve covered the basics of creating a policy using the New-CsXxxPolicy cmdlets. You know that simply using the cmdlet followed by an identity will create a new policy with the default settings. We’ve also discussed the basics of what the different identities for the policy mean to where they apply, but it will be useful to recap that here. This time you will use the New-CsClientVersionPolicy because it can be created against all the various scopes available as follows:

New-CsClientVersionPolicy -Identity global
New-CsClientVersionPolicy -Identity Site:EMEA
New-CsClientVersionPolicy -Identity registrar:se01.rlscomms.net
New-CsClientVersionPolicy -Identity TestDefaultSettings

These commands will create policies with the default settings. Of course, you can also create new policies through the SBSCP. One of the benefits of this is that you get guidance in creating the policies of different scope, as shown in Figure 12.12.

Once you have selected the scope type, you will be presented with a search box to locate the relevant pool (registrar) or site, or you will be taken straight into the policy settings windows with a text box to name the policy if it is to be a user (Tag:) policy.

After policies have been created in the SBSCP or PowerShell, the next stage is the assignment of these policies. Global policies, site policies, and service policies don’t need to be assigned; they just work immediately on creation because their identity specifically references an element of Skype for Business architecture where they are to be active. That’s why the name of a policy can be edited only with user policies. Of course, this means you can’t use one site policy on another site; you must create a new one because the naming format is specific to the site, such as Site:EMEA or Site:APAC. If you do need to do this, there is no simple method. It would be worth reviewing the following article, which details a possible workaround:

http://blogs.technet.com/b/csps/archive/2011/03/21/copypolicies.aspx

The user policy (sometimes called tag level) will need to be assigned. This is where the Grant-CsXxxPolicy cmdlets come in. To assign the TestDefaultSettings client version policy to the Keith_Skype user, you need to do the following:

Grant-CsClientVersionPolicy -Identity "rlscommskeith_skype" ↵
-PolicyName "TestDefaultSettings"

This will apply the policy to Keith_Skype. But suppose you want to apply this policy to all members of a department or to those with a special custom attribute or specifically to members of an AD group.

Well, this is once again where PowerShell comes in. You can again utilize the searching skills you learned at the beginning of this chapter. You first locate the relevant group of users you need and then pipe the output to the relevant Grant-CsXxxPolicy cmdlet. Here is an example:

Get-CsUser –LdapFilter "Department=Marketing" | ↵
Grant-CsClientPolicy –PolicyName "TestCsClientPolicy"

This will first use an LDAP filter to get all the members of the Marketing department who are Lync enabled and then apply TestCsClientPolicy to them. If you are using the SBSCP to assign policy, things follow much the same format. You would use the search skills covered earlier to locate the relevant Skype for Business–enabled users. Then you would select the users and, in the Action drop-down, click Assign Policies. This will open the window you see in Figure 12.13. You can assign the relevant policies to the users by using the relevant drop-down menus and clicking OK to apply.

Applying a policy to members of a specific AD group is unfortunately not quite so simple. Like many things, though, it can be achieved with a line of PowerShell.

You first need to get the members of the group. This can be done as follows:

Import-Module ActiveDirectory
Get-AdGroupMember -Identity TestGroup

Here, you are first importing the AD module so you can manipulate AD objects and then get the members of the group TestGroup. However, the output looks like this:

Get-ADGroupMember -Identity TestGroup
 
distinguishedName : CN=Keith Skype,Cn=users,dc=rlscomms,dc=net
name              : Keith Skype
objectClass       : user
objectGUID        : 43cea8f9-5d84-4007-bd4b-d2daac38986a
SamAccountName    : Keith_Skype
SID               : S-1-5-21-1801160900-2869415974-1656638013-1144

If you try to pipe that directly into the Grant-CsXxxPolicy cmdlet, you will get an error because the Grant-CsXxxPolicy cmdlet doesn’t understand the input. To work around this, you need to understand the type of input that the Grant-CsXxxPolicy cmdlet takes. You can get this from the help file, as shown here:

String value or Microsoft.Rtc.Management.ADConnect.Schema.ADUser object.
Grant-CsClientPolicy accepts pipelined input of string values
representing the Identity of a user account. The cmdlet also
accepts pipelined input of user objects.

This tells you that the cmdlet accepts pipelined user objects, as you proved when passing it output from Get-CsUser, and that it also accepts strings that represent user accounts. Therefore, what you need to pass the Grant-CsXxxPolicy cmdlet is something in the form of Keith Skype.

As you can see from the output from the Get-AdGroupMember cmdlet, this particular format is found under the .name attribute. You can, therefore, use the following PowerShell command to grant policy to the membership of a specific AD group:

Get-ADGroupMember -Identity testgroup | ForEach-Object ↵
{Grant-CsClientPolicy -PolicyName testdefaultsettings -identity $_.name}

This command first gets the members of the group and then for each member runs the Grant-CsClientPolicy cmdlet using the .name attribute for the identity.

Realistically, you probably don’t want to create all your policies with the default settings. After all, there would be little point in that because you could simply use the default global policies. So to create new policies with settings other than the default, you need to specify what settings you want in New-CsXxxPolicy. As an example, creating a custom presence policy enables you to manage two important aspects of presence subscriptions: prompted subscribers and category subscriptions.

New-CsPresencePolicy -Identity MarketingPresencePolicy ↵
-MaxPromptedSubscriber 600 -MaxCategorySubscription 900

This would create a new presence policy using the settings entered. The MaxCategorySubscription parameter lets you control the maximum number of category subscriptions allowed at any one time. A category subscription represents a request for a specific category of information—for example, an application that requests calendar data. The MaxPromptedSubscriber parameter enables you to control the maximum number of prompted subscribers a user can have at any one time. By default, anytime you are added to another user’s contacts list, a notification dialog appears onscreen informing you of this fact and giving you the chance to do such things as add the person to your own contacts list or block the person from viewing your presence. Until you take action and dismiss the dialog box, each notification counts as a prompted subscriber.

Creating a presence policy in this way is easy. However, what about a policy that has many more options you could set, like a client policy? In that case, you need to plow through them and set the ones you want. The options that you don’t explicitly set will take on the default settings for that policy.

As you’ve seen, it is also possible to create policy using the SBSCP. In this case, configuring the relevant settings is simply a case of using the GUI and then clicking Commit.

Editing Existing Policies

We have shown how to create several policies, but what about editing the existing ones? Editing policies is also a simple matter in PowerShell or the SBSCP. With PowerShell, you would use the relevant Set-CsXxxPolicy cmdlet and identify the policy using the naming conventions outlined previously (Scope:Name) and then use the relevant parameter to change the setting, as in the following example:

Set-CsPresencePolicy -Identity Tag:MarketingPresencePolicy ↵
-MaxPromptedSubscriber 200 -MaxCategorySubscription 400

There is at least one policy that works slightly differently than the others. That is the client version policy. This policy is made up of rules to allow or disallow certain versions, and it uses the CsClientVersionPolicyRule set of cmdlets to amend and create rules.

Having created and assigned all these policies, the last thing we will cover in this section is how to see which user has which policy assigned. After all, it could get rather complex with all those different levels in play.

To see the policies applied to a user, run the following command:

Get-CsUser -Identity "Keith Skype"

This will output something similar to the following:

Identity                : CN=Keith Skype,CN=Users,DC=rlscomms,DC=net
VoicePolicy             :
VoiceRoutingPolicy      :
ConferencingPolicy      :
PresencePolicy          :
DialPlan                :
LocationPolicy          :
ClientPolicy            : TestDefaultSettings
ClientVersionPolicy     :
ArchivingPolicy         :
ExchangeArchivingPolicy : Uninitialized
PinPolicy               :
ExternalAccessPolicy    :
MobilityPolicy          :
PersistentChatPolicy    :
UserServicesPolicy      :
HostedVoiceMail         :
HostedVoicemailPolicy   :
HostingProvider         : SRV:
RegistrarPool           : se01.rlscomms.net
Enabled                 : True
SipAddress              : sip:[email protected]
LineURI                 :
EnterpriseVoiceEnabled  : False
ExUmEnabled             : False
HomeServer              : CN=Lc  Services,CN=Microsoft,CN=1:1,CN=Pools,CN=RTC  Service,CN=Services,CN=Configuration,DC=rlscomms,DC=net
DisplayName             : Keith Skype
SamAccountName          : Keith_Skype

Note that although some of the policies applied are shown, others are not. This is because the only ones shown here are the ones assigned specifically to the user, namely, the Tag: policies.

In the past with Lync 2010, seeing all the policies that applied to a user required some fairly serious PowerShell. If you’re interested in that, then take a look at the Lync Server PowerShell blog.

http://blogs.technet.com/b/csps/archive/2010/06/07/scriptuserpolicyassignments .aspx

However, in Lync 2013 we were given a new built-in cmdlet to do exactly what we need. The Get-CsEffectivePolicy cmdlet will return all the policies applied to a user even if they are applied only at a global or site level. For example, if you run the following command, you will see the policies applied to Test User5:

Get-CsEffectivePolicy –Identity "Test User5"

The output looks like this:

Identity                       : Keith Skype
ConferencingPolicy             : Global
PresencePolicy                 : Global
LocationPolicy                 : Global
VoicePolicy                    : Global
LocationProfile                : Global
ClientVersionPolicy            : Global
ClientPolicy                   : Tag:TestDefaultSettings
ImArchivingPolicy              : Global
UserPinPolicy                  : Global
ExternalAccessPolicy           : Global
HostedVoicemailPolicy          : Global
MobilityPolicy                 : Global
PersistentChatPolicy           : Global
VoiceRoutingPolicy             : Global
UserServicesPolicy             : Global
ThirdPartyVideoSystem          : Global
CallViaWorkPolicy              : Global
GraphPolicy                    : Global
AddressBookServerPolicy       : Global
OnlineDialinConferencingPolicy :

You can see that all the policies are applied at the global level except for ClientPolicy, which is defined at the user level. There is no definition for OnlineDialinConferencingPolicy as this environment is not connected to online services.

Removing or Resetting Policies

With all the experimenting with policies you’ve done in this chapter, you have probably ended up with lots of policies you don’t want! You also may well have changed the settings of the default global policies and, for that matter, other policies as well. What can you do about that? Well, removing a policy at any of the levels other than global is simple. Use the relevant Remove-CsXxxPolicy cmdlet with the identity of the policy as follows:

Remove-CsClientVersionPolicy -Identity Site:EMEA
Remove-CsClientVersionPolicy -Identity registrar:se01.rlscomms.net
Remove-CsClientVersionPolicy -Identity TestDefaultSettings

In the SBSCP, removing policies is just as simple; you simply select the relevant policy and then, from the Edit drop-down, select Delete.

Interestingly, if you remove a policy currently assigned to a user, you will get a warning, and you are given the opportunity to continue. Assuming you select Yes, the policy will be removed, and the user will be reset to a Global policy assignment. See Figure 12.14 for the result of rerunning the Get-CsEffectivePolicy command.

However, if you run the Get-CsUser cmdlet, you will receive the following response:

WARNING: "ClientVersionPolicy" with identity "2" assigned to "sip:[email protected]" has been removed from configuration store.

This indicates that the user configuration still believes there to be a policy assigned, and it is identified with the value of 2. This is known as an anchor.

In this case, the user will be applied to the next policy defined by the scope, which is why Get-CsEffectivePolicy looked OK and, while it may be messy and unclear, there is no specific need to tidy further.

Of course, removing site and service policies automatically removes their assignment because the identity and assignment are intrinsically linked.

Interestingly, if you try to delete the default global policies, Skype for Business won’t let you! Essentially, all that happens is that any changes you have made to the global policy revert to the default settings. To try this for yourself, you would use a command like the following one:

Remove-CsClientVersionPolicy -Identity global

When you run this, you will reset the global CsClientVersionPolicy to its default settings. By way of warning, you will see the following output:

WARNING: Global configuration for "ClientVersionPolicy" cannot be removed. Instead of removing it, the Global configuration for ClientVersionPolicy" has been reset to the default value.

ClientPolicy

The client policy is manipulated using the CsClientPolicy cmdlets. It is this policy that replaces the vast majority of settings that would previously have been set using group policies in OCS 2007 R2. Client policies can be applied at the site or user scope.

It is the client policy that allows the configuration of such elements as these: MaximumNumberOfContacts, whether to add a disclaimer message to an IM with the IMWarning setting, whether to force saving of IMs in Outlook with the EnableIMAutoArchiving setting, and whether to display a photo with the DisplayPhoto setting.

Of course, there are many more settings available, which are all described in detail in the Skype for Business help file. However, if the setting is not in the default scope, there is a way to make client policies even more flexible. You can use the New-CsClientPolicyEntry cmdlet to add additional areas of control to the Skype for Business ClientPolicy. This functionality has to be used in conjunction with Microsoft, which could add the relevant new element to control in a cumulative update, as detailed here:

http://technet.microsoft.com/en-us/library/gg399046.aspx

In the past, this was used to add a method for providing a link to a feedback URL to capture client requests during the beta periods of Lync.

ClientVersionPolicy

The client version policy is set to ensure control over which different clients can register to a Skype for Business pool. Client version policies are made up of rules that identify specific clients. These rules are defined using the ClientVersionPolicyRule cmdlets. Each SIP client sends identifying information in its SIP headers. This identifying information is then matched against the defined rules.

These policies are used to ensure both a consistent user experience and security by making sure that old, unpatched clients cannot connect to the service.

Client version policies can be applied at the global, site, service (registrar), and user scopes.

ClientVersionConfiguration

The ClientVersionConfiguration cmdlets allow you to control, at either the global (default) or site (new policy) level, what happens when clients attempt to connect to Skype for Business. This is where you turn on or off the facility in Lync to check client version. If this policy is enabled, the ClientVersionPolicy policies apply. The other side to ClientVersionConfiguration is what happens when Skype for Business denies access to a client. You can use the settings to set the default action if a client version is not specifically noted in a ClientVersionPolicy policy. You can also configure whether to prompt the user with a URL to get an updated client if they have a client that is not compliant with the policy.

PrivacyConfiguration

Presence is a great resource; the ability to see whether someone is available can significantly streamline communication. However, some people are not eager to present this information. Lync 2010 introduced a way of managing this situation, which Skype for Business Server 2015 continues to maintain, by applying Privacy Configuration settings. The fundamental aim of these settings is giving users control. It allows users to show their status to only those people on their contacts list.

Given that only allowing contacts to see your status is very restrictive, you can help users prepopulate their contacts list with their manager and direct reports using the AutoInitiateContacts setting. Other settings configure Skype for Business to ensure that the user must specifically opt in to sharing photo and location information with others.

Policies can be configured at the global, site, and service scope. At the service scope, the policy can be applied only to the User Services service.

PresencePolicy

The presence policy controls two settings, the MaxCategorySubscription and the MaxPromptedSubscriber. Presence as a concept is all about providing information about whether someone or something (a group, for example) is available. However, the simple process of providing that information creates network traffic and database load because all the people who are tracking an object are communicated with and logged. Skype for Business is a fairly efficient system and scales to hundreds of thousands of users; however, if all those users subscribed to a single object, then when it came online or changed status, that would generate hundreds of thousands of messages to let all those users know.

To mitigate this potential flood of network traffic, you can use the settings in the presence policy. The first setting, MaxCategorySubscription, controls the individual types of information that each user can subscribe to—for example, calendar information.

The MaxCategorySubscription property enables you to limit the number of category subscriptions a user can have.

The second setting is the MaxPromptedSubscriber setting. Each time you are added to another user’s contacts list, the default client behavior is to prompt you with a pop-up that gives you the chance to reciprocate and add the user to your contacts list. Each of these prompts counts as someone subscribed to the requesting user’s presence. It is common practice to limit the number of unacknowledged presence subscriptions; this can be done with the MaxPromptedSubscriber property. If a user were to reach the maximum number, they would not receive new contact notifications until some of the outstanding prompts have been acknowledged.

The CsPresencePolicy cmdlets can apply at the global, site, or per-user scope.

CsCallViaWorkPolicy

CsCallViaWorkPolicy only has four settings that can be controlled. They are the Identity and Enabled settings, which every policy has, and then simply AdminCallBackNumber (and associated UseAdminCallBackNumber).

Of all of these, the only setting of interest is AdminCallBackNumber, which allows the use of a generic “administration” number rather than the individual users’ number.

CsThirdPartyVideoSystemPolicy

With even less to configure, CsThirdPartyVideoSystemPolicy simply has a flag (SupportSendingLowResolution) to indicate whether the particular policy enables lower resolutions.

UserServicesConfiguration

User Services are the services that control the basic settings for maintaining presence for users and also some baseline meeting settings. The meeting settings cover the length of time an anonymous user can remain in a meeting without an authenticated user and the maximum time that any meeting can remain active. On the user side, you can set the maximum number of contacts each user can have and the maximum number of meetings that they can schedule.

The user services configuration policies are applied at site or service scope. You can also edit the global policy.

When the user services configuration settings and the client policy settings are in conflict (for example, when different maximum number of contacts per user has been set), the lower number wins.