Weird but true: Permissions required to use Edit Primary Users / Devices in ConfigMgr 2012

Tweet_UseEditPrimaryUsers_DevicesThe idea of this blog post is identical to my blog post about the permissions required to use Resultant Client Settings that I did a couple of weeks ago. I’m also thinking about making this something recurring, as I noticed that the role based administration model sometimes reacts a bit different then, at least, I would expect. For those following me on Twitter, this blog post will be an extended version of a tweet I posted last week. This blog post will explain a bit more about the situation, as that was a  bit hard in a tweet of 140 characters. Also, this blog is a lot easier to find for future references.

Introduction

In this blog post I’ll explain what permissions are required to use the Edit Primary Users option and the Edit Primary Devices option. This option allows the administrator to configure the primary user of a device and to configure the primary device of a user. Keep in mind that providing the administrator with the minimum rights required to use these options, it does not mean that the administrator can add every user, or every device. In the form, that allows the administrator to add a primary user (or a primary device), it is also possible to search ALL users (or ALL devices), but this search is limited to the collections that the administrator is scoped to.  

Permissions

UseEditPrimaryUsers_DevicesNow the key thing of this blog post, the minimal permissions required to use the Edit Primary Users option and the Edit Primary Devices option. There will be a small surprise between the required permissions. To provide an administrator with the minimal rights required for using these options, use the following list:

  • Collection – Read, Read Resource;
    • Without the read permissions the collections node will not show. The read resource permissions are only required to also show the members of a collection.
  • User Device Affinities – Read, Modify, Delete and Create.
    • Without the combination of the read, modify, delete and create permissions the Edit Primary Users option and the Edit Primary Devices option will not show.

Feedback

The surprise in the required permissions is the fact that the read, modify, delete and create permission are required. It’s difficult to explain that all these permission are required to allow the usage of the Edit Primary Users option and the Edit Primary Devices option. Basically, there is the ability to differentiate the permissions on configuring and modifying the user device affinity, but it’s all or nothing at the moment, at least via the console. This is not always the ideal situation. That’s why I filed a DCR on the connect site. If you would like to see this addressed in a future release, or in a hotfix, or just want to give it a small spotlight, this is the link where you can vote: https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/994950

Different methods to set the User Device Affinity for usage during and after a task sequence in ConfigMgr 2012

Last week I’ve got a question about setting the User Device Affinity (UDA) during the task sequence. Well, actually the question was more about the easiest way to do this. I didn’t have a direct answer, as it’s of course also a relative question. The easiest way can be different depending on the current configuration. In this post I will go through three methods that can be used to set the UDA, so it can be used during and after the task sequence. For usage during the task sequence, think about something like installing user-targeted applications during the task sequence and for usage after the task sequence, think about the pre-deploy software to the user’s primary device option.

Before using the first, or the second method, there are a couple of prerequisites that need to be in place, like setting the task sequence variable SMSTSAssignUsersMode to Auto and configuring Allow user device affinity with automatic approval in the PXE configuration. For all the prerequisites for configuring UDA during a task sequence, see: http://technet.microsoft.com/en-us/library/hh846243.aspx

Method 1: Create an empty task sequence variable

Setting_SMSTSUdaUser_CollectionThe first method is probably the easiest method in the most situations. Also, it might remind everyone of an often used method to simply provide an input for a computer name, when using unknown computers. The nice thing is that this exact same method can be used to provide the UDA information.

Simply create a collection variable named SMSTSUdaUsers and leave the value blank. This will cause the task sequence to request input for that specific variable. Set the value to <domain>\<user> and the task sequence will configure the specified user as the primary user for the device.

Method 2: Enable prestart command

Setting_SMSTSUdaUser_PrestartThe second method is pretty similar to the first method, in a way that it will also generate an input request. This method requires some custom scripting to create an input form that request for an user name. That input form can be started as a prestart command on the boot image. To configure a prestart command, simply go to the Customization –tab of the boot image and select Enable prestart command. In case of a PowerShell script, use a command like PowerShell.exe -ExecutionPolicy ByPass .\<script>.ps1 and select Include file for the prestart command to add the script to the boot image.

To create a form, like my example, in PowerShell that requests for input, make sure to use at least a small function, like the following, that creates a task sequence variable named SMSTSUdaUsers with the value from the input field.

function Set-SMSTSUdaUsers { param( [string]$UserName ) $TSEnv = New-Object -COMObject Microsoft.SMS.TSEnvironment $TSEnv.Value("SMSTSUdaUsers") = $UserName }

Note: To use a PowerShell script in the boot image make sure that the Optional Component of Windows PowerShell is added. This also includes Microsoft .NET.

Method 3: Import computer information and set primary user

Setting_SMSTSUdaUser_ImportThe third method is actually just a more advanced method to Import Computer Information. A bit more then a year ago, I created a small form that allows somebody to import computer information and to also directly configure a primary user. This makes sure that a computer directly has a primary user configured, which can be used during and after a task sequence. For some more information, see: https://www.petervanderwoude.nl/post/updated-import-computer-form-v0-8-directly-adding-a-user-device-affinity-in-configmgr-2012/

Conclusion

There are many methods to configure the UDA for usage during and after a task sequence. Probably, there a more methods then the three mentioned in this post, but these are the most common and easy to use. Also, I didn’t mention the methods in which a users is allowed to configure it themselves, or in which an administrator can manually configure it via the console. I like automation and as less as possible manual actions. For all the different options to configure UDA via console options, see: http://technet.microsoft.com/en-us/library/gg699365.aspx

Updated: Import Computer Form v0.8 – Directly adding a User Device Affinity in ConfigMgr 2012

A few months ago I released the first public version of my Import Computer Form. I’ve had some nice feedback about it and also some good ideas for added functionality. This update will mainly be about three things:

  • Cleaning-up old code, by merging a few lines and adjusting some queries.
  • Adding error catching, by introducing an error provider for faulty input.
  • Adding functionality, by introducing an option to add a User Device Affinity/ Primary User.

Overview

These additions mean that this version gives the user the possibility to perform the following actions, without the need of access to and/ or a locally installed ConfigMgr console:

  • ImpoCompInfov08Fill in a Computer name.
  • Fill in a MAC Address.
  • Select an OS Deployment Collection.
  • Select a Primary User.
  • Import the Computer Information.
  • Add the User Device Affinity/ Primary User.
  • Close the form.

Inside information

CreaRelaWMII thought it might be nice to give some information about how easy it actually is to add this new functionality of adding a User Device Affinity/ Primary User. First start with looking for the class and the methods that hides the functionality that is needed. This can be done by, either browsing through WMI, or searching through the online reference on MSDN. As the screenshot shows, I like to use WMI Explorer. It also show that browsing to the class SMS_UserMachineRelationship reveals the method CreateRelationship, which again reveals its four parameters. For the exact information about the parameters it’s still necessary to look at MSDN. The “fun” part is that the input, of the parameters, is required in the order as shown in WMI. The order shown at the different MSDN articles is NOT the order needed as the input! After all the input is collected, the command line is “just” adding it all together in one Invoke-WmiMetod command, like this:

Invoke-WmiMethod -Namespace root/SMS/site_$($SiteCode) -Class SMS_UserMachineRelationship -Name CreateRelationship -ArgumentList @($ResourceID, 2, 1, $UserName) -ComputerName $SiteServer

Note: I used exactly the same way to change my method, for importing a machine, into a “one-liner”. This made it to an Invoke-WmiMethod for the class SMS_Site and the method ImportMachineEntry, like this:

Invoke-WmiMethod -Namespace root/SMS/site_$($SiteCode) -Class SMS_Site -Name ImportMachineEntry -ArgumentList @($null, $null, $null, $null, $null, $null, $MACAddress, $null, $ResourceName, $True, $null, $null) -ComputerName $SiteServer

Availability

As of today this updated version of my Import Computer Form is publicly available via the TechNet Galleries. Please let me know what you think of the tool.

>> Available via download here on the TechNet Galleries! <<