On the same day I published my Azure Newbie Notes post, which mentioned, among other things, the inability to set static IP address for VMs, things changed a bit. Then-new v0.7.3 of Windows Azure PowerShell added several cmdlets that allow handling of static internal IP addresses. This came without any official announcements, but was covered in several blog posts on TechNet. No doubt this is a must-have feature – many services just won’t operate correctly without constant IP address, with DNS server is probably the most notable among them. Unfortunately, configuring static IP address via web-based Azure Management Console is not available yet.
[ Here you can find brief explanation on how to install and configure Azure PowerShell, along with the some related links. ]
Several posts and articles with useful samples related to static IP addresses:
Here and in the samples below “MyVM” is the name of the virtual machine we want to update and “MyCloudService” is the name of the cloud service this VM belongs to.
Probably the most useful sample nowadays is one that shows how to take existing VM and set it to have a static IP address. Although most of the articles say you have to use an available (that is, free) IP address, you can use the same IP address that is already assigned to the specific VM. Also, pay attention that Update-AzureVM cmdlet reboots the VM. Note that in the sample run below I’m configuring MyVM to the same IP address it already has. Of course, it makes sense to run the first part of the command alone first to make sure you are going to update the right VM.
Another useful command is to check whether a VM already has a static IP address configured or not. For VMs with static IP address configured, this IP will be displayed, otherwise only the diagnostic output of the first part will be shown.
Windows Azure PowerShell is a module that provides cmdlets to manage Azure through Windows PowerShell.
Here you can find an official documentation on how to install and configure Azure PowerShell. But in a nutshell, there are two simple steps.
Step 1:
Download and run Microsoft Web Platform installer, which will guide you through the Windows Azure PowerShell installation. The process is a bit lengthy and includes some heavy Microsoft components, such as IIS Express and SQL Server Express. Note that a system restart may (will?) be required during the installation, so prepare accordingly.
Step 2:
Open Azure PowerShell and configure it to use your Azure account, as explained in the documentation.
Two methods are available – via your Azure credentials (with session available for the next 12 hours) and certificate-based. The former did not work in my case, resulting in some strange error, so I had no choice but to go with certificates option. Surprisingly, the setup went extremely easy. First, download your settings file with Get-AzurePublishSettingsFile cmdlet. Second, import the resulting file with Import-AzurePublishSettingsFile cmdlet and delete the file from the local system.
This week I dedicated some time to check what Windows Azure is about. Here are some notes I gathered during those days. I have some background in VMware and AWS, so the notes are mostly around the differences between those and Windows Azure that I spotted.
The first thing to note is that single Management Console provides access to all Windows Azure functionality pieces. Here those pieces look like the parts of a whole. In AWS each service actually is a separate service (with some of those services being integrated), and the console clearly reflects that.
Virtual Machines and Virtual Networks Those are two basic concepts that are much the same between Azure and AWS, besides maybe some terminology differences:
Amazon AWS
Windows Azure
Instance
Virtual Machine
(Instance) Type
(VM) Size
Start, Stop, Terminate
Start, Shut Down, Delete
AMI (= Amazon Machine Image)
(VM) Images
VPC (= Virtual Private Cloud)
(Virtual) Network
My feeling is that similarly named type/size on Azure is much slower than its AWS counterpart, but I cannot prove that with some test results yet.
VM Images Just like AWS, Azure provides you large set of images to start your VM from. There is no marketplace for 3rd party images yet, but you can create your own images if you need to. Two major differences here are the need to go through all sysprep burden on your own and the fact that the original VM is deleted (sic!) after it was captured as an image. Yet, this may be not that bad to avoid some confusion, considering that original instance is mostly wiped after sysprep.
IP Addresses Unlike AWS, where internal IP address of an instance within VPC will remain constant for the instance lifetime (that is – until the termination), here both external and internal IP of the VM will not survive the shutdown and will be changed after you turn it on. A possible workaround is to shut down the VM from inside the guest OS and not from the Management Console. This way the VM is considered running by Azure and all VM resources, including IP addresses, are preserved. Note that in this state the VM continues to eat your budget! [ Update (May 2014): Here is a great article on the topic. Also, setting static IP address is now possible via PowerShell. ]
Cloud Service The concept of cloud service does not exist on AWS, and is not easy to create simple explanations of what it is. The explanation from Microsoft pretends to be complete, but is mostly confusing. There are some better explanations on the net, much more suitable for newbies – for example this one, which explains the concept by giving three examples of cloud services: 1) Small HTML site. 2) Complex 2-tier web application built on ASP.NET and SQL Server. 3) Virtual network with multi-server application cluster and local AD installation. Each VM lives inside some cloud service, even if it is a cloud service with single VM inside. Each cloud service has own permanent DNS name under “cloudapp.net” domain, short and fully resolvable on the internet, and single public IP address. The IP address will be released after all VMs in the cloud service go down, but the new IP will be associated with the same DNS name after the service will be up again. Each VM in the service will get own externally available ports (so-called “endpoints”), which are mapped to some private ports on the VM itself. Those port numbers do no change, making configuration of various connection managers (like mRemoteNG) static and easy to maintain. In addition, cloud service may be configured to act as a load-balancer for containing VMs, eliminating the need to maintain separate entity for that (like, say, ELB on AWS).
Name Resolution There are significant differences related to name resolution between Azure and AWS. The build-in DNS service is intended to provide name resolution for virtual machines that reside in the same cloud service only. That is, even if you have two virtual machines that are located on the same virtual network, but belong to different cloud services, you will need to use your own DNS server solution in order for them to communicate directly by hostname. I guess this is one of the reasons for Azure-provided DNS server not being able to perform reverse lookups. Pay attention that setting own DNS server in Azure is not so straightforward given that internal IP addresses may change over time. [ Update (May 2014): Things have changed. read about it here. ]
Active Directory Windows Azure Active Directory is not a Domain Controller. You can use it to sync on-premises AD with Windows Azure AD to easily enable SSO, but you can not join computers to Windows Azure AD. In addition, it appears that you cannot delete Windows Azure Active Directory that you don’t need anymore. Well, at least they don’t charge for it. But anyway, if you do need full Active Directory (with Domain Services) in Azure – recall that it requires own DNS server…
Storage Windows Azure Blob Storage is somehow similar to S3 in AWS – but only if you need programmatic access. There is no way to upload files there via Management Console, and I was unable to find third party utils or browser extensions that can do it for you without mandatory registration to their service (and providing them your Azure credentials). [ Update (May 2014): CloudBerry Explorer for Microsoft Azure Cloud Storage seems to do that job perfectly! ]
Security There is no AWS-like separate “security groups” in Azure. Instead, the same functionality is provided by endpoints that are configured directly on VM level (see my notes on cloud services above). The major drawback of this approach is lack of single place to maintain access rules. However, it makes some sense when you recall that each VM has own public port number for the same protocol.
Opening an HTTPS URL in the environment that is not connected to the internet may take time. Fortunately, there is a way to speed up this process on the client side. It appears that Windows tries to retrieve fresh CRL (certificate revocation list) from own and third party servers. Obviously, this attempt times out when the client is not connected to the internet. There is no way to disable CRL retrieval completely, but it is possible to reduce retrieval timeout to the minimum allowed. The system will still attempt to contact CRL servers, but it will take less time to go through the whole list of servers.
In addition to SSL handshake, the settings above will speed up any process that involves certificate validation – for example, validation of code signing certificates.
So:
Open Local Group Policy Editor (for example, search for “Edit Group Policy” in the Start Menu)
Go down the tree from “Computer Configuration” => “Windows Settings” => “Security Settings” => “Public Key Policies”
On the right side, double-click on “Certificate Path Validation Settings”
Go to “Network Retrieval” tab
Select “Define these policy settings” checkbox
Change both timeout values under “Default retrieval timeout settings” to 1 second
Click “OK”
For detailed instructions for clients that are part of Active Directory Domain, visit this TechNet topic (although it speaks about increasing timeout and decreasing it).
The instructions above apply to Windows clients, but the same technique may be applicable for the other operating systems.
Some time ago we found that the Microsoft UAG installation in our lab does not allow RDP access. The server itself was fine and the RDP service inside worked as expected – it was clearly visible on the VM console, – but the RDP connections were silently ignored. It looked strange and we spent the significant amount of time looking for the reason of this behavior over the internet, until we realized that the UAG server does allow us to connect via RDP from one of the remote computers – the one it was installed from. This gave us a clue on what’s going on and finally led us to the right direction.
The solution is simple and well-documented – but only if you know what to look for, as usual. It appears that Microsoft TMG (the product that Microsoft UAG is based on) allows remote access from predefined set of computers only. In order be allowed to open RDP to UAG server, the computer should be added to the list of Forefront TMG Remote Management Computers. The detailed instructions can be found at the bottom of this TechNet article, and I’ll quote the relevant part here also for future reference:
«Open the Forefront TMG Management console from the Start menu. In the console tree, click the Firewall Policy node. On the Toolbox tab, click Network Objects. Click Add, and then click Computer. Specify the details of the computer from which you will remotely manage Forefront UAG. … After adding the computer to the set, activate the changes in the Forefront TMG Management console.»
On the same day I published my Azure Newbie Notes post, which mentioned, among other things, the inability to set static IP address for VMs, things changed a bit. Then-new v0.7.3 of Windows Azure PowerShell added several cmdlets that allow handling of static internal IP addresses. This came without any official announcements, but was covered in several blog posts on TechNet. No doubt this is a must-have feature – many services just won’t operate correctly without constant IP address, with DNS server is probably the most notable among them. Unfortunately, configuring static IP address via web-based Azure Management Console is not available yet.
