Tuesday, January 28, 2014

Troubleshooting Windows Azure Pack - Re-register a Resource Provider

 As I highlighted in a blog post last week, we have gone under the hood of Windows Azure in order to understand this business critical solution.
This includes:

·         Architecture
·         Dependencies
·         Performance bottlenecks
·         Configuration

As a result of all this investigation, we had to “rebuild” the WAP solution several times.
When I say rebuild, I do not necessarily mean a complete rebuild, installing SPF, VMM and WAP all over again, but remove the connected dependencies and so on.
This has indeed been an interesting and valuable learning.

The situation:

You have a WAP environment that you want to restart, by flushing the configuration in the portal.
For some reason, you have lost the connection to your resource provider, so that the VM Cloud show 0, empty, nada.

You are unable to register the VMM server(s) again, and by looking at the Odata Management logs on the SPF server (where all the magic is really happening), will find out that something is complaining about an item with the same key has already been added. So to summarize, we know it's there, but it is not showing.

Before you proceed – verify the following:

Your VMM service is running, available and actually working. Make sure that VMM is not complaining about anything critical, as this is key for SPF/WAP to work correctly in this context.
Also, you must ensure that no one has touched any of the dedicated user accounts for the setup, as well as DNS is working as expected. We have seen odd behavior in conjunction with a bad DNS server.

Removing the VM Cloud resource provider in WAP with MgmtSvC-cmdlets

The portal will not let you remove the Service Provider Foundation  endpoint – but only update the settings. So, if you are not pointing to another SPF connection string, this one is currently locked at the current resource provider.

We must use powershell on the Admin WAP server to proceed:

$Credential = Get-Credential
$Token = Get-MgmtSvcToken –Type Windows –AuthenticationSite https://yourauthenticationsite:30072 – ClientRealm http://azureservices/AdminSite -User $Credential -DisableCertificateValidation

Get-MgmtSvcResourceProvider -AdminUri "https://localhost:30004" -Token $Token -DisableCertificateValidation -name "systemcenter"
Remove-MgmtSvcResourceProvider -AdminUri "https://localhost:30004" -Token $Token -DisableCertificateValidation -Name "systemcenter" -InstanceId "the instance ID you got from Get-MgmtSvcResourceProvider"

Removing the mapping in SPF

Service Provider Foundation contains the configuration for the VMM cloud towards the WAP environment, and is responsible for exposing this to the service management API.

If we run the following powershell cmdlet on the SPF server, we will see information about the resource provider:


We want to clean this up, so we will run the the following cmdlet in order to remove our resource provider:

Get-SCSPFServer –Name “nameoftheVMMserverFQDN” | Remove-SCSPFServer

Once this is done, we are able to register the resource provider for our VM Cloud in WAP again.

This will require that the Plans created in WAP must undergo a re-sync process before continuing to service the tenants.



Anonymous said...

Thank you. You save me after days troubleshooting.

Anonymous said...

While re-registering SPF endpoint. Just check you have matching cloud exist in VMM else plan sync will fail.