Transferring a domain to Azure (dns and billing)

NOTE: this post has been superceded! Use the Microsoft AppService API to create or update your domains.

Tip: Jack Rudlin wrote a great post on using the API for this.

—-old content from here—

Lately I’ve been playing with custom domains in Azure, Microsoft has been allowing us to directly purchase domain in Azure for a while now. This leverages GoDaddy’s API, but Microsoft bills you for the domain, consolidating your domains, management and usage nicely in Azure.

The portal only allows you to purchase new domains, so how do you transfer existing domains to Azure DNS?

First you’ll need a transfer code, which you can get from your current DNS provider. Then, execute the following script:


Register-AzureRmResourceProvider -ProviderNamespace Microsoft.DomainRegistration
$rgName = "NAME OF YOUR RESOURCE GROUP"
$ResourceLocation = "Global"
$ResourceName = "MYDOMAINNAME.NL"
$PropertiesObject = @{
'Consent' = @{
'AgreementKeys' = @("DNPA","DNTA");
'AgreedBy' = '122.13.11.20'; #ip address you're running this script from
'AgreedAt' = '2017-17-07T08:37:40'; #roughly the current time
};
'authCode' = 'DOMAIN TRANSFER CODE'; #code by current domain provider
'Privacy' = 'true';
'autoRenew' = 'true';
}

New-AzureRmResource -ResourceName $ResourceName -Location $ResourceLocation -PropertyObject $PropertiesObject -ResourceGroupName $rgName -ResourceType Microsoft.DomainRegistration/domains -ApiVersion 2015-02-01 -Verbose

It will take a long time to run, but you’ll have a custom domain in Azure that you can now connect to websites and/or manage through AzureDNS.

Note: this only works for domains OLDER than 60 days and can take 5-7 days until the domain is usable in Azure, all domain records will be copied to an Azure DNS zone.

Exchange 2010 backend with 2013 frontend proxy something has gone wrong error

At a customer site users were experiencing “:-( Something went wrong” errors in OWA (2013). The RPC endpoint was also broken, blocking a migration to Office 365.

Initial checks showed a few errors on the 2013 frontend server:


[Eas] Marking ClientAccess 2010 server NLEX01.domain.local (https://nlex01.domain.local/Microsoft-Server-ActiveSync) as unhealthy due to exception: System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.HttpProxy.ProtocolPingStrategyBase.Ping(Uri url)

[Autodiscover] Marking ClientAccess 2010 server NLEX01.domain.local (https://nlex01.domain.local/Autodiscover) as unhealthy due to exception: System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.HttpProxy.ProtocolPingStrategyBase.Ping(Uri url)

[RpcHttp] Marking ClientAccess 2010 server NLEX01.domain.local (https://nlex01.domain.local/rpc/rpcproxy.dll) as unhealthy due to exception: System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.HttpProxy.ProtocolPingStrategyBase.Ping(Uri url)

[Owa] Marking ClientAccess 2010 server NLEX01.domain.local (https://nlex01.domain.local/owa) as unhealthy due to exception: System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.HttpProxy.ProtocolPingStrategyBase.Ping(Uri url)

The issue ended up being twofold;

  1. somehow the SCCM client on the Exchange backend had replaced the local server certificate that IIS uses, this certificate wasn’t accepted by the frontend server
  2. for some reason NTLM (Windows) Authentication was switched off on the Virtual Directories on the backend machine.