Recently I faced an issue while building a complete Windows Azure Pack solution to provide Infrastructure as a Service (IaaS), initially everything was working properly while I was doing testing after each step of WAP deployment, so I able to create three subscriptions, created some virtual machines using the created subscriptions, and able to access these virtual machines, then after I finish the whole deployment and configure all post deployment activities found an issue when try to create any new subscription that shows subscription status as “ACTIVE (OUT OF SYNC)” with detailed error as below:

image

“One or more errors occurred while contacting the underlying resource providers. The operation may be partially completed. Details: Failed to create subscription. Reason: Message : An error occurred while processing this request., Innermessage: <!DOCTYPE HTML PUBLIC ”-//W3C//DTD HTML 4.01//EN””https://www.w3.org/TR/html4/strict.dtd”> <HTML><HEAD><TITLE>Bad Request</TITLE> <META HTTP-EQUIV=”Connect-Type” Content=”text/html;charset=us-ascii”></HEAD> <BODY><h2>Bad Request – Invalid Hostname</h2> <hr><p>HTTP Error 400. The request hostname is invalid.</p> </BODY></HTML>

So I start troubleshooting with below steps:

  1. First I check in VMM Console, under “Settings/Security/User Roles” and found that the new subscription administrator that should be created while creating the new subscription is not there (except admin users for the 3 subscriptions I created in the initial testing without issues), which means for me that the request did not reach to SCVMM, so the issue is almost in Service Provider Foundation (SPF).
  2. Follow the troubleshooting steps document her in very good way http://blogs.technet.com/b/privatecloud/archive/2013/11/08/troubleshooting-windows-azure-pack-spf-amp-vmm.aspx however issue was not solved and still get the same error.
  3. I start looking at each WAP component to be sure that same level of accumulative update is applied on each WAP role (Internal WAP Tier, External WAP Tier, SCVMM, SPF), but found all are the same.
  4. Start taking more deeper step and start enable debugging in both SCVMM and SPF follow steps documented here http://support.microsoft.com/kb/2850280 & here http://support.microsoft.com/kb/2913445/en-us , and the results from this debugging that I become 100% that the issue is in SPF not in SCVMM, simply because the error is logged in SPF only, part of log file on SPF after enable debugging showing the same error is below:

[1]0AB8.0ACC::‎2015‎-‎01‎-‎08 15:39:33.118 [Microsoft-ServiceProviderFoundation]Component: Provider     Activity [WebAuthentication Call, id {f13f5bc4-d696-4beb-be36-60fc99d01c82}]  Parent activity [none, id {00000000-0000-0000-0000-000000000000}]    Elapsed: 0ms  Context: {9a298a09-5e36-4e1f-b163-6e91f54a8b14}    Message : An error occurred while processing this request., InnerMessage: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">  <HTML><HEAD><TITLE>Bad Request</TITLE>  <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>  <BODY><h2>Bad Request - Invalid Hostname</h2>  <hr><p>HTTP Error 400. The request hostname is invalid.</p>  </BODY></HTML>

  • Then I followed some recommendations from communities to try to change the Service Provider registration to be done using SPF Local user, this local user should be created with the same name & password on all SPF servers, however after I did this change I found same issue still there.

  • Lately I start tracking all changes done in the environment after the first test that was succeeded before to create new subscriptions, and start rollback one of these changes which is replacing the self-signed certificate for SPF web site with a new certificate issued from internal enterprise CA, so after roll-back and return SPF website to use self-signed certificate found the issue is no more there, and I can create new subscription in addition I able to sync all the subscriptions created while troubleshooting the issue.

So it was Service Provide Foundation issue, because of replacing the self-sign certificate with new certificate from enterprise CA, although all WAP components are member in the same Active Directory AD Domain with the CA in the same AD, the most important thing is that I went through all troubleshooting techniques related to Windows Azure Pack to solve the issue and this will save me time in future Windows Azure Pack deployments.

Good luck in your WAP deployment, and hope that this post will help a lot of consultants while deploying Windows Azure Pack and Service Provider Foundation.

More Windows Azure Pack solved implementation issues can be found below: