my personal blog about systemcenter

Windows Azure Pack Publishing using SNI

Windows Azure Pack uses port 30071 and 30081 for its public facing authentication and portal pr default , in our demo enviroment we wanted to pushlish these but on defalt SSL port to avoid issues with customer firewalls that could be blocking high ports.

To using a single ip for Windows Azure Pack we use Service Name Indication a feature in IIS8-> that enables “hostheader” for SSL

http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability

This is a demo enviroment so we can pushlish directly from WAN to LAN without a proxy please dont do this in production

The steps here are for single server install again not prodution reference post for chaning ports

http://blogs.technet.com/b/privatecloud/archive/2013/12/10/windows-azure-pack-reconfigure-portal-names-ports-and-use-trusted-certificates.aspx

The steps needed for us (thank you to Marc van Eijk for asking why we just didnt do that) was the following

Create a dns records in the public and for

cloud.systemcenter365.com for tennant portal and cloudauth.systemcenter365.com for authentication

these point in out case to 77.233.248.6 and we have created a WAN-LAN NAT on port 80 and 443 for access

image

On our internal DNS server we created 2 zones to about going through the firewall and back when testing internally , out internal domain name is internal.systemcenter365.com , for now we used a zone for the FQDN as we only want to “regulate” the names used for Windows Azure Pack and nothing else , but we could just have created the systemcenter365.com zone internally and then created the records needed.

But for now we created a zone cloud.systemcenter365.com and cloudauth.systemcenter365.com that points to the local server hosting the endpoints , this is a requirement when using the powershell commands to install this.

We then used https://www.digicert.com/util/ digicert certification utility to order and install a public certificate so we dont remind people just to accept a certificate error.

image

We used a wildcard certificate from digicert (disclaimer :they provide for free for MVP’s)

image

On the webserver hosting the WAP endpoints

image

Change the TenantSite from 30081 to 443 and enable “Require Server Name Indication” and set the hostname to in our example cloud.systemcenter365.com

image

image

Change the Authsite from 30071 to 443 and enable “Require Server Name Indication” and set the hostname to in our example cloudauth.systemcenter365.com

After we have set the ports in IIS and enabled the SNI we need to configure Windows Azure to respond to the ports

Set-MgmtSvcFqdn -Namespace “TenantSite” -FullyQualifiedDomainName “cloud.systemcenter365.com” -Port 443 -Server sqlwap

Set-MgmtSvcFqdn -Namespace “AuthSite” -FullyQualifiedDomainName “cloudauth.systemcenter365.com” -Port 443 -Server sqlwap

Set-MgmtSvcRelyingPartySettings –Target Tenant –MetadataEndpoint ‘https://cloudauth.systemcenter365.com/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=sqlwap.internal.systemcenter365.com;User ID=sa;Password=”

Set-MgmtSvcIdentityProviderSettings –Target Membership –MetadataEndpoint ‘https://cloud.systemcenter365.com/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=sqlwap.internal.systemcenter365.com;User ID=sa;Password=”

And after chaning the fqdn and the endpoints our site now responds and works with http://cloud.systemcenter365.com

image

and a root redirect is always nice to have