A quick look at Windows Azure IaaS

I played around a bit with Windows Azure IaaS to see how it stacks up against Amazon EC2. We use Amazon EC2 internally for some test and demo setups that don’t always have to be running.

As a practical test, I wanted to install a Windows Server 2012 domain controller in a subnet of my choice. It turns out that getting started is pretty simple. The rest of this post presumes that you have a Windows Azure account with the Virtual Machines Preview activated (go to http://www.windowsazure.com to get started).

You can manage virtual machines from the new management interface at https://manage.windowsazure.com or with Windows Azure PowerShell (https://www.windowsazure.com/en-us/manage/downloads/). This post will not use Powershell. Sorry! Smile

The first thing I did was to create a new virtual network which also lets you create an affinity group. Affinity groups allow you to have some control over the location of components like storage in order to reduce latency for instance. To learn more about affinity groups, take a look at http://social.technet.microsoft.com/wiki/contents/articles/7916.importance-of-windows-azure-affinity-groups.aspx. Note that there are other ways to create affinity groups, but it’s easy to do when you create your virtual networks. I will not bother you with the details of creating the virtual network and just show the end result. I created a virtual network with two subnets: prod and dev.

image

The details for the subnets can be seen when clicking Configure:

image

Note that there is more you can configure here. You can specify DNS servers that will then be handed out to your VMs using DHCP. In addition, you can configure a connection to your on-premises network using a site-to-site VPN solution.

After the networks are configured (including the affinity group), it’s time to create a storage account. Storage accounts are not new in Azure and are traditionally used to store BLOBs, tables and queues. The virtual machine disks you create (or that will be created automatically as an OS disk) will actually be stored in BLOB storage. I created the following storage account:

image

During the creation of the account, you will be asked for the affinity group. You see that reflected above in the location property. Note that you can actually take a look inside the storage account with a tool like Azure Storage Explorer (http://azurestorageexplorer.codeplex.com/). After adding your storage account using the name and the key (you can get that from the old portal), you will see:

image

Above, you see the boot disk of a virtual machine of 30GB. Files in BLOB storage have a maximum size of 1TB so VHDs are also limited to 1TB. Depending on the VM size, you can add additional disks of 1TB to a VM. The maximum amount of disks you can add today is 16 and you can stripe these inside the VM to a 16TB volume if required.

Now we have our network and storage defined, we can create a virtual machine. It’s important to note that you should create the virtual machine with the From Gallery option to be able to specify all the necessary settings such as the network:

image

When you click From Gallery, you will get a wizard with the following questions:

  • OS selection: Windows Server 2008 R2, Windows Server 2012, CentOS, Ubuntu, …
  • VM config: name, administrator password, size (from Extra Small to Extra Large)
  • VM mode: here’s where you select the storage account and the network
  • VM options: here you can select the virtual network subnets that this virtual machine should belong to

The virtual machine will then be provisioned and shown in the list:

image

Connecting to the virtual machine is easy with Remote Desktop and the Connect option at the bottom of the screen (with the virtual machine highlighted). The connection will not be made to the standard RDP port. Behind the scenes, every VM (or multiple VMs) live in a cloud service and each cloud service has an associated public IPv4 address. Each VM in the cloud service has an external port mapped to its RDP port. The external port is generated randomly but you can change it in the configuration of the virtual machine:

image

The cloud service’s IP address is automatically mapped to servicename.cloudapp.net so in the above example you would connect to servicename.cloudapp.net:50248 to connect to the virtual machine.

When you create your first virtual machine, you will not see the associated cloud service in the user interface. When you create another virtual machine and select to connect to an existing virtual machine in the VM options page, the cloud service will be shown in the UI:

image

The cloud service provides a view on the group of servers in the service. You can see the total amount of cores in the service, aggregated CPU utilization and more.

Now we have a virtual machine running, what about its IP address? Virtual machines are automatically assigned an IP from the range that was specified in the virtual network assigned to the virtual machine. If you specified your own DNS servers, these will be supplied as well. If not, Azure DNS servers will be assigned. It’s important to know that IPs should only be assigned through DHCP. Do not configure static IP addresses, not even one that matches the IP that was assigned. You should be aware that if your virtual machine were to fail (e.g. because of host failure), the same IP will be assigned although the MAC address will change.

Now that this is all sorted out, is there something we have to think of regarding the deployment of a domain controller? The answer is: absolutely! In short:

  • Although you have always learnt to assign a static IP to a DC, forget about that now. Use the DHCP assigned address as stated earlier.
  • Do not place the Active Directory DIT, logs and SYSVOL on the operating system disk but on an attached data disk. Data disks do not use “write-behind” caching it seems.
  • Windows Azure today does not use Hyper-V 3 so the new VMgenerationID stuff in Windows Server 2012 is not supported.

Now how does Windows Azure IaaS stack up against EC2? I have not played around with it enough to know all the details and differences but this is what I found so far:

  • Connecting to virtual machines using RDP and the concept of the cloud service and port mapping makes it easier to connect to virtual machines in a private virtual network. In EC2 you have to set this up yourself or use a Terminal Services gateway.
  • Virtual machines seem to have the ability to connect to the Internet by default. In EC2 you need to assign an elastic IP or use some gateway solution inside the virtual private container.
  • It is relatively easy to get started. The EC2 learning curve is a bit higher but there are more options as well so that evens it out.

Enabling and disabling DirSync in BPOS and Office 365

If you have some experience with BPOS or the Office 365 Beta, you know there’s a tool called DirSync that allows you to synchronize your Active Directory with Microsoft’s Online Services. During a course last week, I was asked if you can use DirSync temporarily to sync users, contacts and groups and, after migration, turn it off.

In BPOS, you can certainly do the above and essentially use DirSync as just a migration tool. It is in fact the easiest way to load users, contacts and groups into BPOS if you don’t mind setting up the software. When you turn off DirSync in the BPOS Administration website, all synchronized users become normal users which means their properties become editable. Turning off DirSync is done from the Migration / Directory Synchronization tab:

image

In Office 365, it’s a totally different story because DirSync is intended as a tool for permanent coexistence. As a result, you will not find a Disable button in the UI and there’s also no PowerShell cmdlet to turn it off. If you just want to migrate your users, contacts and distribution groups to Office 365 you should use other means such as CSV, PowerShell, etc…

Office 365 and Identity

imageMicrosoft has provided more details about Office 365 and the different identity options in a service description document (link at the bottom of this post).

There are two types of identities:

  • Cloud Identity: credentials are separate from your corporate credentials
  • Federated Identity: users can sign in with their corporate Active Directory credentials

With BPOS, there was only one type: cloud identity. Users had to logon using a Sign-In Assistant that stored the cloud credentials (name and password) and used those credentials to sign in in the background. For larger organizations, the Sign-In Assistant was a pain to install and manage so it’s a good thing it is going away.

With the new identity solution, as stated above, the Sign-In Assistant goes away and the logon experience is determined by the type of identity and how you access the service. The table below summarizes the sign-in experience:

image

1 The password can be saved to avoid continuous prompting
2 During the beta, with Federated IDs, you will be prompted when first accessing the services
3 Outlook 2007 will be updated to give the same experience as Outlook 2010

Note that it is required to install some components and updates on user’s workstations if rich clients are used to access Office 365. Although you can manually install these updates, the Office 365 Desktop Setup package does all that is needed. Office 365 Desktop Setup was formerly called the Microsoft Online Services Connector. Office 365 Desktop Setup supports Windows XP (SP2) and higher.

A couple of other things that are good to know:

  • Office 365 supports two-factor authentication if you implement SSO with Active Directory Federation Services 2.0. There are two options to enforce two-factor auth: on the ADFS 2.0 proxy logon page or at the ForeFront UAG SP1 level.
  • Active Directory synchronization is supported with the Microsoft Online Services Directory Synchronization tool. The tool is basically the same as with BPOS although there are some changes to support new features: security group replication, write back (which also enables some extra features), etc…
  • Note that the synchronization tool still does not support multiple forests.
  • The synchronization tool is required in migration scenarios like rich coexistence, simple coexistence and staged migration with simple coexistence.

The full details can be downloaded from the Microsoft website. If you are involved in Office 365 projects, this is considered required reading!

Office 365 SharePoint Online Storage

imageMicrosoft has recently published updated Office 365 Service Descriptions at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6c6ecc6c-64f5-490a-bca3-8835c9a4a2ea.

The SharePoint Online service description contains some interesting information, some of which I did not know yet. We typically receive a lot of questions about SharePoint online and storage. The list below summarizes the storage related features:

  • The storage pool starts at 10GB with 500MB of extra storage per user account (talking about enterprise user accounts here).
  • Maximum amount of storage is 5TB.
  • File upload limit is 250MB.
  • Storage can be allocated to a maximum of 300 site collections. The maximum amount of storage for a site collection is 100GB.
  • My Sites are available and each My Site is set at 500MB (this is not the 500MB noted above, in essence this is extra storage for each user’s personal data).
  • A My Site is not counted as a site collection. In other words, you can have 300 normal site collections and many more My Sites.
  • Extra storage can be purchased (as before) at $2,5USD/GB per month.

When it comes to external users (for extranet scenarios), the document states that final cost information is not available yet. It is the intention of Microsoft to sell these licenses in packs.

Check out the SharePoint Online service description for full details.

How to check that a RemoteFX session was created

When working with RemoteFX, it is not directly obvious in the UI that a RemoteFX session was established. The easiest way to check it is via the Event Viewer on the RDS host. Look for the following event:

image

You will find the above in the Applications and Services logs.

RemoteFX with Remote Desktop Session Host

After reading the Can you connect to a Terminal Server via RemoteFX post on brianmadden.com, I decided to quickly try it out in Xylos’s lab environment. The installation, as expected, is very simple. On a Windows Server 2008 R2 SP1 system, install the Remote Desktop Services role and the Remote Desktop Session Host role service. There is no need to install the RemoteFX role service because it is only required for RemoteFX in combination with the Remote Desktop Virtualization Host role service and Hyper-V (VDI scenario). Note that a GPU is not required in the RDS scenario. It is required in the VDI scenario.

After installing the role services and the reboot, you need to enable RemoteFX with a policy (for full configuration steps, see http://technet.microsoft.com/en-us/library/ff817595(WS.10).aspx):

image

Note that the policy setting below it can be used to optimize the visual experience (see http://technet.microsoft.com/en-us/library/gg288964(WS.10).aspx).

Now, what about the user experience? Well, I must say the difference is definitely noticeable especially when playing videos or heavy Flash and Silverlight. The performance improvement does come at a cost of extra CPU cycles as the RemoteFX encoding is done by the CPU. I actually had to give my RDS host two CPUs to get a good result.

Note that I did my tests over the LAN using a wireless connection. From home, RemoteFX also performed very well but that’s a 35Mbit down connection over a 10Mbit up connection at work.

The question then becomes if RemoteFX is worth enabling in an RDS scenario for the incremental benefits it brings to performance and user experience. That’s something only real-world testing and benchmarking will tell. In the meantime, take RemoteFX for RDS into account when designing a remote desktop solution and keep in mind that it will work with any virtualization solution.

Also see:

Windows Intune available on March 23rd

Windows Intune, Microsoft’s cloud-based pc management service will be available for trial and purchase on March 23rd. It will become available in several countries, including Belgium.

The service can be acquired for around 11$ per computer per month. This includes a Windows 7 Enterprise license. For 1$ extra, you can acquire MDOP as well which includes App-V.

For more technical content, see http://technet.microsoft.com/en-us/windows/ff472080.aspx?ITPID=mscomgl. The FAQ is here: http://www.microsoft.com/windows/windowsintune/windowsintune-faq.aspx.

Windows Intune