Getting the xSharePointAdministration module to work has a lot of gotchas. So I decided to write a separate post for it.

First of all: the xSharePointAdministration module uses the PSSnapin “Microsoft.SharePoint.PowerShell” for all its work. It therefore must be run on only one server in the farm – this would normally be the server that hosts the central administration. I will refer to this server as the deployment server. Make sure to do all the work on the deployment server.

Desired state configurations are run by the Windows Management Instrumentation (winmgmt) service. This service normally runs under the “Local System” account. So you have to grant this account all required permissions that he needs for the tasks to do.

SPShellAdmin

To interact with SharePoint from PowerShell the user needs to be granted permission to do so. You can use the Add-SPShellAdmin CmdLet to do this. Note that with only a user name the permission is only granted to the config db – an not content databases. You have to explicitly grant permissions for these databases.

Add-SPShellAdmin -UserName "nt authority\system"

Get-SPDatabase | where { $_.Type -like "Content Database" } | Add-SPShellAdmin "nt authority\system"

If you use other databases you may have to add grant permissions for them as well.

FarmAdministrators

If you want to deploy farm solutions as DSC resources you have to make the user a farm administrator. You can do this in central administration under Security à Manage farm administrators group.

Database

If your sql server is on a different machine then your deployment server you also have to add the computer account of your deployment server (<domain>\<computername>$) as a login to your sql server. You can grant premissions for each data base – but the easiest way is to make the account sysadmin.

Policies

If you want to work with content in site collections (like web or lists) you have to grant permissions therefor too. The easiest way is to create a policy in the web application and grant full access to the local system account. You can do this in central administration in “Application Management” à “Manage web applications”.

ServiceApplication Permission

If you use resources that use service applications (like xUserProfileProperty) you have to grant permission to the service application. Make the user an administrator. In some cases you might have to grant normal permissions as well.

xWeb and xList

The two resources xWeb and xList have still issues. As Ash pointed out in a comment there is an AccessDeniedException on some systems. I’m still figuring out what it is. I encourage you to use the xProvisioning module in the meantime.

Troubleshooting

Since I’m in the middle of doing it – I wanted to share some advice on troubleshooting security issues with the DSC resources.

After all changes make sure to restart the winmgmt service:

Restart-Service winmgmt -Force

If you sill get strange behavior reset the iis and restart your PowerShell console.

If you want to execute a test script as the system account you can use psexec from sysinternals:

psexec -i -s Powershell.exe

This will open a new window with a PowerShell console. Test with whoami – it really runs as local system.