The idea of this blog post is similar to my blog posts about the permissions required to use Edit Primary Users/Devices and my blog post about the permissions required to use Resultant Client Settings that I both did a couple of months ago. The difference this time is that the permissions, for using the Retire/Wipe option, are not that weird, but it might be good to know what the results will be of providing an administrative user with the required permissions. Also, I’ve seen some questions around the web lately regarding the possibilities to differentiate in the permissions for using the Retire/Wipe option. In the results of this blog post I’ll provide some information about the impact of these required permissions.
In this blog post I’ll explain the permissions that are required to use the Retire/Wipe option and, while I’m touching the subject anyway, the permissions required to use the Cancel Retire/Wipe option. These options are only available for mobile devices enrolled via Microsoft Intune and allow the administrator to retire/wipe a mobile device and to cancel the retire/wipe of a mobile device. I’ll explain this by going through the required permissions and providing information about the impact of a specific permissions.
Now the key thing of this blog post, the minimal permissions required to use the Retire/Wipe option and the Cancel Retire/Wipe option. There is nothing really special between the required permissions, which, on itself, might make it a bit special. To provide an administrator with the minimal rights required for using these options, use the following list of permissions:
- Read – The Read permission provide access to the collections;
- Read Resource – The Read Resource permission provides access to the detailed information about the resource, like the targeted deployments and the inventory information;
- Modify Resource – The Modify Resource permission provides access to make modifications to a the resource, like installing a client and canceling a retire/wipe action;
- Delete Resource – The Delete Resource permission provides access to delete the resource and by that the Retire/Wipe action.
Note: This also really means that without the Modify Resource permission the administrative user will not have the Cancel Retire/Wipe option and without the Delete Resource permission the administrative user will not have the Retire/Wipe option
The fact that there is nothing more required than the Read, Read Resource, Modify Resource, Delete Resource permissions make it a bit special. These permissions together provides the administrative user with the following available actions on a mobile device (see screenshot).
This means that an administrative user, that has the permissions to delete a resource, also has the permission to retire/wipe a mobile device. That makes sense as both actions eventually delete a device. To add-on to that, even if the administrative user could not retire/wipe a mobile device the administrative user could still directly delete the mobile device. In case not every administrative user is allowed to retire/wipe a mobile device, simply use a collection to scope the administrative users to everything but mobile devices.
The last thing I would like to mention is that this also means that it’s currently not possible to allow an administrative user to only use the Wipe company content and retire the mobile device from Configuration Manager option. If an administrative user has the permissions to retire/wipe a mobile device, the administrative user can use the Wipe company content and retire the mobile device from Configuration Manager option AND the Wipe the mobile device and retire it from Configuration Manager option.
6 thoughts on “Permissions required to use Retire/Wipe in ConfigMgr 2012”
Do you know what permissions would be required to allow (for example) a group of helpdesk operatives be able to reset passcodes for Windows Phone 8.1 mobile devices?
Helpdesks usually have the ability to reset AD passwords and it would probably make sense to delegate responsibility for Mobile device passwords as well.
It should be the same permissions. When they need to see the primary devices of user, they would also need the User Device Affinities > Read permissions.
Would this still be applicable to CB1703? I’ve set the permissions above but I don’t get any of the Remote device actions??. I can only actually see ‘Bypass Activation Lock’ and View Activation Lock Bypass Code’ but they are greyed out.
It’s a like i’m not able to see the options to make the changes needed.
Permissions don’t differ per version of Windows 10, if you have the capabilities for one version of Windows 10, you should have it with all. Unless the platform is not yet supported.