Tag Archive: Windows Azure

There is a ton of online documentation about Windows Azure VMs that advise that static IP addresses are not supported and that one must rely on dynamic IP addresses since Windows Azure VMs will hold onto those IP addresses for the lifetime of the VM. Take for example this article about deploying AD on a Windows Azure Virtual Network which advises to even use dynamic IP addresses on a domain controller.

This used to be true! Well, it kind of still is….in some cases…

Recently Microsoft released a fantastic new feature which makes Windows Azure VMs that much more compelling for developers in that when a VM is shut down from the Windows Azure Portal (not from the guest operating system which still continues the previous behaviour) it now actually gets deallocated and thus you are not charged for those compute units. This is very attractive for developers with MSDN accounts (who recently had some major price discounts applied on their compute units and on many other Azure services as well) as they can now consider scaling up their development machines to higher levels and still stay within their account limits by shutting down and deallocating their machines when they are not in use.

One by-product of this change is that when a machine has been deallocated its IP address is no longer reserved for that machine and is put back into the pool of available IP addresses and will be assigned to the next machine that is allocated. Shutting down the machine via the guest operating system doesn’t deallocate the machine and thus this problem isn’t seen then. This issue can have significant impact if you have a domain controller/DNS server running on your Azure virtual network which you shut down and deallocate to save money.

You can try to start up your deallocated machines in exactly the same order every single time to ensure that they get back the same IP address, or you can consider putting the domain controller/DNS server onto an isolated subnet of your virtual network so that there is no contention for its IP address.

If preserving an IP address if of major importance to you then you can either leave the Azure VMs running or always shut then down from the guest operating system rather than via the portal in which case the machine remains allocated and thus the IP address is preserved. Remember that even if the machine is shut down you will still be getting charged compute units if it isn’t deallocated.

Continuing my foray into the world of Azure I started playing with using my Azure VM as an ADFS server with the goal of using it as an identity provider in Windows Azure ACS for the appropriate candidate azure services. I followed the instructions on this fantastic step by step walkthrough by Haishi Bai (he sure does make it easy for those who are learning their way) but I ran into a problem when I tried to get the Identity and Access extension (on a side note make sure you have the WIF runtime installed on the server, then install the WIF SDK, and only then install the Identity and Access Visual Studio extension or you will face a null object reference type error when opening Visual Studio and the extension won’t load) in Visual Studio to use my Azure ACS namespace as an identity provider.

According to the instructions on this blog post and on many others one should browse to the Access Control Services management portal, click on the Management Service link, click on ManagementClient then symmetric key and take down the key value that is listed here.

Now to have Visual Studio connect to your ACS namespace you need to open the Identities and Access menu by right clicking on the project and selecting that item, choosing to use the Windows Azure Access Control Service and then pressing the configure link to choose an ACS namespace. Now the guidance says that you should place your ACS namespace in the first textbox and your symmetric key in the second.

Unfortunately you’ll find that chances are this wont work. You will be faced with a ID1113 error (you can see it by hovering over the red exclamation mark) which states that the combination of namespace and management key are invalid. Browsing around the internet (there are many places where this suggestion is made but it is probably worded best in this blog post) suggests that this is a common problem when you have created the ACS namespace in the new Azure Management Portal and have suggested that you should instead create the ACS namespace in the old portal instead (you can access the old portal by clicking on your name on the top right hand side of the portal screen and choosing previous portal).

What I have found however is that if I instead entered the ManagementClient password instead of the symmetric key then the extension seems to accept the combination and allows me to choose from the identity providers that I have configured in the ACS management portal. I do not know why the password is accepted while the symmetric key isn’t when that is apparently what is being asked for, but for others who are also stuck at this step use the password instead.

I hit an interesting problem today while trying to RDP to my Windows Azure VM using active directory credentials where I was getting an error message stating “An authentication error has occurred. The local security authority cannot be contacted.”.

This VM was connected to a domain, my domain controller also being an Azure VM. At some point I must have set the DNS settings on my VM to obtain the DNS server address automatically rather than explicitly point at my domain controller and this was the cause of my problem. The problem didn’t present itself till I rebooted the VM in question, and since a bit of time had passed in between the two actions it wasn’t immediately obvious what the cause of the problem was.

To fix the issue I had to swap the credentials I was using to remote into my VM to a local account (when you provisioned the VM you would have created a local account, if you don’t remember these credentials or any other local account details that have RDP access then you might be in some trouble) which allowed me to successfully remote into the VM, and then had to set the DNS server address to explicitly point at the IP address of my domain controller. Props to Kevin P. Sullivan who mentioned this solution on this discussion board.

My colleague Mark Brimble has also pointed out to me that he has seen the exact same error for a newly provisioned local user on an on premise VM for which the password had to be reset upon the first login, so take note that there might be other causes for this error message.

For those of you who aren’t very familiar with network settings hopefully the below screenshots should guide you (the highlights denote what you need to click/change).