Backup-GPO Error on Windows Server Core

After migrating some scheduled tasks to a new Windows Server 2016 Core server I discovered that the Backup-GPO cmdlet was throwing an error.

Backup-GPO: The data is invalid. (Exception from HRESULT: 0x8007000D)

I used this quick PowerShell script in order to determine which GPOs in particular were having an issue.

$gpos = Get-GPO -All

foreach ($gpo in $gpos)
      Write-Host $gpo.DisplayName.ToString()
      Backup-GPO $gpo.DisplayName.ToString()

The policies all had folder redirection in common which narrowed things down but still didn’t explain the behavior. After a bit more research I found this KB article which seems to correlate with this issue even though it’s about AGPM.

The article states:

Because Windows Server Core does not have the GPMC Interfaces installed, applications that use this interface will fail.

So it appears that the cmdlet will not work on any version of Windows Server Core as I was able to reproduce the issue on Windows Server 2012 R2 Core and Windows Server 2019 Core (I also tried it with the Server Core App Compatibility Feature on Demand).

I ended up having to migrate the task to a server with the desktop experience installed in order for it to work.

Cannot Start Server Service

While scripting a report; I came across an error about being unable to connect.

I examined the server in question and found the server service was not running.

I tried to start it but it stopped immediately with the following error in the system event log:

Windows could not start the Server service on Local Computer Error: 1808: The account used is a computer account. Use your Global user account or local user account to access this server.

However, the service was configured correctly to run as the Local System account.

It’s an odd problem and the error is misleading. The actual cause was that a user had placed a share path in in the system Path variable (ie \servershare)

After removing the offending entry the server service started right away.

WinRM Not Listening

While scripting the same report as earlier, I cam across a server which I could not connect to remotely via PowerShell.

The WS-Management service was running but was not listening on port 5985 as it should be.

Running the  winrm quickconfig command resulted in another error:

WinRM already is set up to receive requests on this machine.
Message = The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”.

Error number: -2144108526 0x80338012

Restarting the winrm service resulted in a couple errors in the System event log for port 5985 and 47001 with event ID 10128:

The WinRM service is not listening for HTTP requests because there was a failure binding to the URL (http://+:47001/wsman/) in HTTP.SYS.

No remote requests will be serviced on that URL.

User Action
Please use “netsh http” to check if ACL for URL (http://+:47001/wsman/) is set to Network Service.

Additional Data
The error code received from HTTP.sys is 5: %%5

I ran netsh http show urlacl from and elevated command prompt and discovered there were no wsman entries at all.

I then ran the following commands to add the URL ACL entries and restart the WinRM service.

netsh http add urlacl url=http://+:47001/wsman/ user=”NT SERVICE\WinRM” 

netsh http add urlacl url=http://+:5985/wsman/ user=”NT SERVICE\WinRM” 

net stop winrm

net start winrm

I tried running winrm quickconfig again and this time it was successful! PowerShell remoting was working again.