I was installing Windows Azure Pack to a different lab environment (having not had a problem on previous occasions) and everything was fine until connecting to Virtual Machine Manager. Every time I tried, I got the error “Failed to register virtual machine cloud provider”:
Clicking on ‘Details’ only gave “An error occurred while processing this request.” I did some troubleshooting, including following the great blog article from Microsoft Troubleshooting Windows Azure Pack, SPF & VMM, all of which didn’t point to the problem.
I went to the Event Viewer on the server running Windows Azure Pack (only an express installation in this lab) and navigated to ‘Applications and Services Logs > Microsoft > WindowAzurePack > MgmtSvc-AdminAPI > Operational‘ and there were several long errors in there. They were all slightly different in content, but all started the same way:
- Resource provider unexpected exception for proxy request with verb ‘GET’, operation name ‘Outgoing admin proxy call’
Sounds like a PowerShell issue…
Reading further into each error, I spotted the following:
- Invoking method GetSupportedQueryOptions of type Microsoft.SystemCenter.Foundation.Psws.Spf.SpfOperationManager failed. Cause of the problem: Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of Unrestricted.
Having a look at the Execution Policy, it was indeed set to Unrestricted. I found in Group Policy that the setting ‘Turn on Script Execution’ was enabled. I removed this, ran a gpupdate and checked the Execution Policy again, which had now reverted to Restricted. I also ran update on the Service Provider Foundation server and check it was now set to Restricted.
Connecting to Virtual Machine Manager now worked as expected.
Today is GA (General Availability) day for Microsoft Windows 8.1, Windows Server 2012 R2 and System Center 2012 R2, bringing a whole host of eagerly awaited updates. It’s available on the Volume Licensing Center (as well as MSDN and TechNet for testing), so download them and start testing and deployments!
Windows 8.1 info: http://windows.microsoft.com/en-gb/windows-8/meet
Windows Server 2012 R2 info: http://www.microsoft.com/en-us/server-cloud/windows-server/windows-server-2012-r2.aspx
System Center 2012 R2 info: http://www.microsoft.com/en-us/server-cloud/system-center/system-center-2012-r2.aspx
I came across an interesting problem the other day when installing SCCM 2012 SP1 for a client. A brand new Windows Server 2012 domain had been created and SCCM was being installed on Windows Server 2008 R2 SP1. All was going fine until I got to the SMS Provider Settings screen in the wizard, where you type the FQDN of the SMS Provider.
I filled this in and got the following error ‘You must have local administrator privileges to install SMS Provider on machine <FQDN>’:
Wait, what? I went and checked the local admins group and it was all correct as per the prerequisites, so I rebooted the box and the same thing happened. I then checked the ConfigMgrSetupWizard.log file that automatically gets created on the root of the system drive and it had an error:
Failed to open SCM on machine <FQDN>. Error code: 5
Not very helpful either. I was beginning to run out of ideas, when I decided to check the server’s SPNs. Running ‘setspn -L <HOSTNAME>’ returned entries that were missing the FQDN values! How odd.
I created the FQDN equivalent of each entry manually (you can either do this in AD Users and Computers console or by command line), rebooted the SCCM site server, ran through the installation wizard again and it then got past that stage in the wizard.
Not convinced about why this happened, I did some more digging and when looking in Control Panel > System, I saw that the entry for ‘Full computer name’ was missing the domain name, even though it had the correct domain listed further down. This is a similar picture to what I saw:
…where it should have been (notice the difference in the ‘Full computer name’ value):
It turns out the servers had been provisioned from an old template and, while I don’t know the exact reason, something was stopping these joining the domain correctly. Deploying the servers from a new vanilla ISO worked as expected.
Not a local administrators issue after all and several ‘red herrings’ from SCCM.