Hi all,
I've started exploring PowerShell workflows for our remote administration needs and I've hit what I think might be a bug in the Restart-Computer workflow activity. Here's the walkthrough of our steps. PS functions and workflows are run from an "admin"
machine, targeting remote servers (from step 2):
1. Spin up a new Windows 2012R2 VM.
2. Install a server SSL certificate.
3. Enable SSL PS remoting (enable a WinRM HTTPS listener, add a firewall rule, remove the HTTP listener and disable WinRM HTTP firewall rules).
4. Register a client SSL certificate on the server, so that we can use PSUseSsl and PSCertificateThumbprint instead of PSCredential for running remote workflows.
5. Run a workflow that will download and install WMF 5.0, reboot the machine, wait for it and install some additional prerequisites.
Now, I've hit the problem with step #5: it looks like Restart-Computer workflow activity does not pick up the PSCertificateThumbprint workflow parameter and throws an "access denied" error when run and there is an audit failure logged in the Windows Security event log.
If I don't use the PSCertificateThumbprint and pass in a PSCredential to the workflow, the computer reboots. However, Restart-Computer seems to be using the WinRM HTTP endpoint to check if the target machine is back up when using the -Force parameter, since the command hangs there until I RDP into the target machine and re-enable the HTTP listener (by simply running winrm qc).As a side note, PSCertificateThumbprint parameter works perfectly well for authentication with our workflows, as well as CertificateThumbprint parameter when using Invoke-Command.
Am I doing something wrong here, or is this indeed a bug?
Thank you,
Marko