How to opt in to Microsoft Update with PowerShell

For Windows to retreive updates from Microsoft Update, as opposed to Windows Update (which is the default), you have to opt in. This is usually done through the Windows Update GUI by selecting “Get updates for other Microsoft Products”:

This becomes tedious very quickly so here’s how you can do it with PowerShell:

https://gist.github.com/morgansimonsen/8039966

To see if this was successful you can query the Services property of the $MU object:

$mu.Services

You should see something like this:

Name                  : Microsoft Update
ContentValidationCert : {}
ExpirationDate        : 11/18/2014 1:27:43 AM
IsManaged             : False
IsRegisteredWithAU    : True
IssueDate             : 11/18/2011 1:27:43 AM
OffersWindowsUpdates : True
RedirectUrls          : System.__ComObject
ServiceID             : 7971f918-a847-4430-9279-4a52d1efe18d
IsScanPackageService : False
CanRegisterWithAU     : True
ServiceUrl            : https://fe1.update.microsoft.com/v6/
SetupPrefix           : mu
IsDefaultAUService    : True

Name                  : Windows Update
ContentValidationCert : {}
ExpirationDate        : 6/18/5254 9:21:00 PM
IsManaged             : False
IsRegisteredWithAU    : False
IssueDate             : 1/1/2003 12:00:00 AM
OffersWindowsUpdates : True
RedirectUrls          : System.__ComObject
ServiceID             : 9482f4b4-e343-43b6-b170-9a65bc822c77
IsScanPackageService : False
CanRegisterWithAU     : True
ServiceUrl            :
SetupPrefix           :
IsDefaultAUService    : False

If you only have the Windows Update entry something went wrong.

One of the major benefits of this is that you can do it remotely. I have yet to find another way to do this. If you know, leave a comment.

Windows Azure compute cores and you

By default, every Windows Azure subscription has a limit of 20 compute cores. This applies to both VMs (IaaS) and worker roles (PaaS). Fortunately this is a soft limit and you can increase it by submitting a support ticket to the Windows Azure team through the management portal here. The following table lists the number of cores for each available Windows Azure instance:

Compute instance size	CPU Cores
Extra Small	1/6 (Shared)
Small	1
Medium	2
Large	4
Extra Large	8

To see how many cores each of your cloud services are using just look in the management portal. You will se something like this:

Unfortunately you need to manually add all the cores for each cloud service to get the total number. To work around this limitation you can use PowerShell:

https://gist.github.com/morgansimonsen/8039470

Save the above as a PowerShell script and run it from a prompt with the Windows Azure PowerShell module added. It will return all your VMs, sorted by name, their instance sizes, the number of cores they each use and the total number of cores in use in your subscription.

If you are paying for your Windows Azure subscription with a credit card your credit limit is $15000 by default. This will let you increase to a total of 175 cores in your subscription. If you want more cores and still pay with a credit card you will have to go through a credit check process to increase your credit limit. If you move to an Enterprise Agreement there will be no need for any credit checks to increase your core count beyond 175.

For large deployments the Windows Azure Capacity Planning team will want information from you so that they can allocate the required resources in the regions you specify. Typical questions they will ask you is where (region) you want to deploy, if you can deploy in several regions, if you are creating a new deployment or growing an existing one, which VM sizes you require and other services, like CDN, SQL etc) that you may require.

How to upload an image VHD to Windows Azure using CSUpload

Introduction

One of the exciting new possibilites in Windows Azure Infrastructure as a Service (IaaS) is the ability to create Virtual Machine images (VHD files) locally and upload them to your own image store in Windows Azure, and use them as the basis for new VMs. In this article I will demonstrate the process of uploading such an image and creating a virtual machine from it in Windows Azure.

CSUpload

There are many Cloud Storage explorers out there that can connect to Windows Azure blog storage to upload files. In this case I will use CSUpload.exe from Microsoft which is part of the Windows Azure SDK. It looks to have the best security and is specifically designed to upload images to Windows Azure. After you have installed the Windows Azure SDK the easiest way to locate CSUpload is to start the Windows Azure Command Prompt and change to the bin directory.

Disks

You can have three types of VHD files, or disks, in Windows Azure:

OS Images: These are generalized, read-only, base disks used for creating new virtual machines. They are either provided by Microsoft, third parties or you.
OS Disks: These are specialized, dedicated, writable disks that serve as the OS disk for a specific machine. If you have migrated a VM from your local virtualiztion platform to run it unmodified in Windows Azure you will use this kind of disk. Max size for an OS disk is 127 GB.
Data Disks: Writable disks that do not contain an operating system. They can either be migrated from your local network or created from Windows Azure. Max size for a data disk is 1 TB. The VM size determines how many data disks you can attach.

CSUpload can upload virtual disks with either the VHD or AVHD extension, meaning you can upload both parent (VHD) and child (AVHD) disks.

Setting up

The first thing we need to do is create a connection string for CSUpload to user for connecting to your Windows Azure subscription. You do this with the CSUpload Set-Connection command. (As you can see CSUpload borrows from the page of PowerShell with its verb-noun command structure. Hopefully this means that it will be replaced by native PowerShell cmdlets in the near future.) CSUpload Set-Connection takes exactly one argument which is a string in quotes consisting of your Windows Azure Subscription ID, Certificate Thumbprint and Service Management Endpoint. These are most easily obtained by running the Get-AzureSubscription cmdlet from a PowerShell prompt where the Windows Azure module is loaded. Here is an example.The strings marked in red are the ones you need to use in CSUpload:

Here’s how the CSUpload command would look (wrapped for readability):

csupload.exe set-connection
“SubscriptionId=3cf46281-f639-44bc-a338-11697697bb2a
;CertificateThumbprint=C525C2AA4B587506F851A7EF5456068270ECC969
;ServiceManagementEndpoint=https://management.core.windows.net”

Windows(R) Azure(TM) Upload Tool version 1.7.0.0
for Microsoft(R) .NET Framework 3.5
Copyright (c) Microsoft Corporation. All rights reserved.

Updated the default connection string.

Once you have configured this, CSUpload will remember it until you do something to change your subscription, say delete your management certificate etc. You could also specify these parameters each time you run one of the other CSUpload commands, but that gets old real quick. Better to define them once.

The upload

To upload a disk CSUpload requires four mandatory parameters;

Destination: the storage account and path where the disk will be stored in Windows Azure. This is consists of two parts; the URL of the storage account, which you can get either from the portal or the cmdlet Get-AzureStorageAccount, the path where you want to put the VHD in that storage account, and the name of the VHD, including the .vhd extension.
Label: The disk’s label, which is displayed when you create new VMs in Windows Azure.
LiteralPath: The location of the VHD/AVHD file to upload, this is on your local disk.
OS: If the disk contains an operating system, specify either Windows or Linux.

Here is an example (wrapped for readability):

csupload.exe Add-PersistentVMImage
-Destination http://mdsstgacc01.blob.core.windows.net/myimages/base_win7sp1x64.vhd
-Label “Windows 7 SP1”
-OS Windows
-LiteralPath “d:Hyper-VVirtual Hard Disksbase_win7sp1x64.vhd” –Name basewin7sp1x64.vhd

The command above produces the following output:

Windows(R) Azure(TM) Upload Tool version 1.7.0.0
for Microsoft(R) .NET Framework 3.5
Copyright (c) Microsoft Corporation. All rights reserved.

Using the saved connection string…
MD5 hash is being calculated for the file ‘d:Hyper-VVirtual Hard Disksbase_win7sp1x64.vhd’.
MD5 hash calculation is completed.ning Time: 00:00:00; Throughput: 2694,3Mbps
Elapsed time for the operation: 00:00:15
Creating new page blob of size 5368709632…
Elapsed time for upload: 00:00:00
Registering the image ‘basewin7sp1x64.vhd’ with repository.
Image ‘basewin7sp1x64.vhd’ is registered successfully.

Let’s look at what happens…

1. MD5 Hash

CSUpload starts by generating an MD5 hash of your file to gurantee that it has been transferred correctly.CSUpload will report its progress as a percentage and display the speed at which it reads data from you local disk. This number is given in Mbps. No actual transfer of data has started yet.

MD5 hash is being calculated for the file ‘d:Hyper-VVirtual Hard Disksbase_win7sp1x64.vhd’.
MD5 hash calculation is completed.ning Time: 00:00:00; Throughput: 2694,3Mbps
Elapsed time for the operation: 00:00:15

2. Allocate blob

Once the MD5 calculation is finished CSUpload will allocate a blob of the same size as the disk in your storage account.

Creating new page blob of size 5368709632…
Elapsed time for upload: 00:00:00

3. Transfer data

Now CSUpload will transfer the contents of the disk to Windows Azure. Note that only blocks in the VHD that actually contain data will be transferred, empty blocks are skipped. If you have a large disk you will see CSUpload use some time maping which blocks contain data.

Uploading: 2,2% complete; Remaining Time: 00:10:29; Throughput: 18,9Mbps
Elapsed time for upload: 00:04:22

4. Register in repository

We are using the CSUpload command Add-PersistentVMImage, which means we are uploading something that can be the basis of new VMs in Windows Azure IaaS. We need to tell Widnows Azure that it is dealing with an image so CSUpload will register the image in your subscriptions image repository. This means it will be visible both under Images in the Virtual Machine node and in your blob storage account.

Registering the image ‘basewin7sp1x64.vhd’ with repository.
Image ‘basewin7sp1x64.vhd’ is registered successfully.

Image in the image repository.

Image in the storage account.

Notes

I have a 50 Mbps fiber optic connection at home, and I was able to max it out while uploading the VHD to Windows Azure. It seems there is no upload limit into the datacenter when performing this kind of operation. VM sizes set a cap on bandwidth, but since the VHD is not yet associated with any VM it seems there is no limit. Further investigation required…
The VHD file must have a size that is a mutiple of 1024 bytes. Or else you will get this error:
The VHD https://mdsstgacc01.blob.core.windows.net/myimages/base_win7sp1x64.vhd has an unsupported virtual size of 500000
0000 bytes. The size must be a whole number (in MBs).
For you so successfully connect to a new VM based on your image, any image you upload must have Remote Desktop enabled and allowed through the host based firewall.
The local Administrator account must be enabled and must have a password set. Later versions of Windows do not allow logon through Remote Desktop with a blank password.
You should use HTTPS when specifying you blob storage. HTTP could leak data during transfer, which CSUpload will warn you about:Use of http is insecure, can leak data to untrusted viewers and make your content vulnerable to data tampering by a malicious third party.

UPDATE: As of December 2012 a new cmdlet has been included in the Windows Azure PowerShell module; Add-AzureVHD. It performs the same functions as CSUpload with regards to uploading images and disks. Get the latest PS module here:

https://github.com/WindowsAzure/azure-sdk-tools/downloads

Windows Azure Architecture Guides released!

This just in: “Microsoft releases Windows Azure Architecture Guides! ITPros go wild!” Read all about it here:

http://www.microsoft.com/en-us/download/details.aspx?id=35764

A 9 MB Word-document; you gotta love it!

Morgan

Which accounts can I assign as Windows Azure co-administrators?

Recently the ability to add co-administrators to you Windows Azure portal was migrated from the old Silverlight portal to the new HTML 5 portal. Happy times!

You can only add valid Microsoft Accounts or accounts from Windows Azure Active Directory as co-administrators. Office 365 uses Windows Azure Active Directory to if you have an account there it can be assigned as a co-administrators. If you enter an invald account the portal will inform you:

Decoding some certificate enrollment client events

The Events

Windows clients can request certificates on their own (autoenrollment) or with the help of a user. When enrolling for a certificate you may find this pair of events in your Application log:

Source: Microsoft-Windows-CertificateServicesClient-CertEnroll
Event ID: 64
Level: Information
User: S-1-5-18
User Name: NT AUTHORITYSYSTEM
Computer: <servername>
Description: Certificate enrollment for Local system successfully load policy from policy server

Source: Microsoft-Windows-CertificateServicesClient-CertEnroll
Event ID: 65
Level: Information
User: S-1-5-18
User Name: NT AUTHORITYSYSTEM
Computer: <servername>
Description: Certificate enrollment for Local system is successfully authenticated by policy server {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}

Obviously the local system successfully enrolled for a certificate, but what do these actually tell us?

Decoding

Let’s start with the first event with if 65 (remember, the newest events are at the top of the event log). It tells us that a CA, included in a certificate enrollment policy, identified by GUID, has successfully authenticated the system’s enrollment request. In the Windows help we find this about certificate enrollment policies:

Certificate enrollment policy provides the locations of certification authorities (CAs) and the types of certificates that can be requested. Organizations that are using Active Directory Domain Services (AD DS) can use Group Policy to provide certificate enrollment policy to domain members by using the Group Policy Management Console to configure the certificate enrollment policy settings. The Certificates snap-in can be used to configure certificate enrollment policy settings for individual client computers unless the Group Policy setting is configured to disable user-configured enrollment policy.

Unless you have added some yourself, there is one default certificate enrollment policy, the Active Directory Enrollment Policy.

To display the enrollment policies you can run certutil.exe –Policy. It will give you a list of your enrollment policies:

Name: Active Directory Enrollment Policy
Id: {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}
Url: ldap:
NextUpdate: EMPTY
LastUpdate: EMPTY
Url Flags = 15 (21)
PsfLocationGroupPolicy — 1
PsfAutoEnrollmentEnabled — 10 (16)
0x4 (4)
Authentication = 2
Kerberos — 2
AllowUntrustedCA: 0
Priority: 7ffffffd (2147483645)
CertUtil: -Policy command completed successfully.

If you look back at the events at the beginning of this post you will recognize the GUID in the event with ID 65. The GUID in the event is the Enrollment Policy ID. So that event is saying that the system was successfully authenticated against the Active Directory Enrollment Policy. Here is a screenshot of the policy as well:

NOTE: If you want to see the defalt certificate enrollment policy and create new ones you need to use Group Policy. You can also create new certificate enrollment policies using the Certificates MMC. See the links below:

Now, if you want to see which CAs are in that enrollment policy you can run certutil.exe –CA (my output is concatenated):

Name: Active Directory Enrollment Policy
Id: {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}
Url: ldap:
6 CAs:

CA[0]:
CAPropCommonName = <CA Name>
CAPropDNSName = <CA Server FQDN>
CAPropCertificateTypes =
0: EFSRecovery
1: EFS
2: DomainController
3: WebServer
4: Machine
5: User
6: SubCA
7: Administrator

CAPropSecurity = <SDDL>

Without the Certificate Enrollment Policy Web Service role service installed, the only way to get certificate policy information from Active Directory is by using LDAP. This can obviously be a problem so the Certificate Enrollment Policy Web Service role service was created to allow certificate policy information to be retreived over HTTPS also. The Web Service functions as a proxy; accepting client requests for policy over HTTPS and querying Active Directory for certificate policy information over LDAP.

So now we know what the first event (ID 65) means.

The next event is much easier; it just says that the system was able to load the certificate enrollment policy successfully from the CA.

More information:

Active Directory Certificate Services and Public Key Management

Official Active Directory blogs

I though I would just remind everyone about Microsoft’s official Active Directory (and related) blogs. These are great places to get good technical info about AD directly from the source. Check them out!

Happy reading!

Enabling notify-driven replication across Active Directory sites

Introduction

Active Directory sites, site links and site link bridges exist to be able to tell the directory service about the network’s physical topology. Specifically to identiy which parts of it are well connected and where there are slow WAN links. The rule of thumb here is that all systems that are connected with at backbone of 10 Mbps or more are considered well connected. These should therefore be contained in a site. Two or more sites of well connected systems can be linked with site links that have a schedule and an associated cost. The cost can be said to represent how fast the link is. Low cost would cause the directory to prefer it while a high cost would be more prohibitive. The way we identify systems in Active Directory is by either IPv4 or IPv6 subnets. A list of IP subnets define a site. Needless to say; the exact same IP subnet cannot be associated with more than one site within the same forest.

However, this functionality also has another application. It can be used to created advanced replicaton topologies that segment your Active Directory.

Segmentation of Active Directory

Whenever you need to control the communication paths between domain controllers you need sites and site links. In these situations, network speed is not the issue, but rather where communication is allowed. The default topology of Active Directory replication within a site is a least-cost spanning tree. If there are any firwall or blocked communication paths between any DCs the directory cannot know about this without defined sites and site links. If you use only one site in such a situation you will not have a functional replication topology.

Let’s say you have a network comprising of two zones with different security levels (Figure 1). Typically these two zones would be segmented by a firewall. However, to make administration and user experience easier and better you want to use the same domain across the zones. If you have 4 DCs in each zone, for a total of 8 DCs in the domain you would have to allow communication from all DCs in one zone to all DCs in the other zone and vice versa if you had only one site. With two sites, one for each security level/zone, with one or two bridgehead servers defined in each site, you would have much fewer openings in your firewall.

This is also very useful for Active Directory aware clients and services who try to use the DCs closest to them. Returning to our example of a network with two zones and a firewall separating them, clients in one zone would not be allowed to access DCs in the other. Clients from a zone with a lower security level typically cannot access resources in higher security levels. Depending on the circumstances the reverse may also be true. Clients from a higher security level cannot access resources on a lower level. With only one site spanning the two zones clients in either zone has a 50 % chance of trying to contact a DC they cannot communicate with (if there is an equal number of DCs in each zone). This is because they think that any DC in the site is available. On the other hand with a correctly defined site topology where the correct IP subnets are associated with the correct site, clients will not attempt to communicate with a DC in another site unless all the DCs in their own site are down.

But there is one challenge with this approach, and that is the speed of replication between sites. In our scenario network speed is not an issue. These configrations are typically segmented LANs with high speed backbones and firewalls. However, Active Directory regards sites as well connected and the links between sites as much slower. Therefore site links only replicate on a schedule, not by using notifications as DCs do within a site. The lowest replication interval you can set on a site link is 15 minutes, meaning that Active Directory updates are replicated across the site link every 15 minutes.

Within a site replication is notificaton-driven. A DC with an originating (a write that is done on the local DC) or replicated (a write done on the local DC but as the result of replication of an update from another DC) update will send a notification message to all its intra site replication partners that it has changes that need to be replicated. The DCs receiving these messages will in turn connect to the originating DC and pull the changes and update their own copies of the database. All Active Directory replication is pull-based meaning that a DC will never push its changes over to any other DC. It will just notify them and they initiate a pull to replicate any changes. This is also true for inter site replication, except between sites there are no notifications, but a schedule and a replication interval (Figure 2).

Each time the interval is reached the DCs will initiate pull replication with their configured parteners across the site links. This works this way because site links are thought to be slow and costly. Thus Active Directory does not want to monopolize them with a lot of singe obejct updates, but rather replicate a lot of objects in a queue at specific intervals. It is this behaviour we want to modify to make Active Directory updates as speedy between sites as they are within sites. Remember, in our scenario network speed is not an issue, we just want to segment our domain.

Configuring site links to use notification based replication

Whether to use notification or a replication interval to replicate across a site link is configured pr. site link. If all your sites are in the same site link configuration is simple, but if you have several sites links, in a hub-spoke topology e.g., you will have to configure each site link.

In this example we will configure the DEFAULTIPSITELINK site link that is created automatically in every Active Directory forest and contains all sites by default.

You can make the change using any tool able to write to Active Directory attributes. I will use Active Directory Sites and Services since that is the easiest way. The change itself requires Enterpise Admin level permissions.

Find the site link you want to change, right click and select Properties.
Select the Attributes Editor tab.
Find the options attribute (make sure that you display all attributes regardless of whether they have a value or not, since this attribute does not have a value by default).
Set the value of the options attribute to 1. Notice how you will now have an explanation behind the 1 value indicating that you have configured the link to use notifications (USE_NOTIFY).
Replicate this change to all DC manually or wait for regular scheduled Active Directory replication.

The options attribute uses a bitmap. Its possible values are:

Decimal Value	Binary Value	Explanation
1	1	USE_NOTIFY
2	10	TWOWAY_SYNC
4	100	DISABLE_COMPRESSION

You can use any combination of these. If your options attribute already has a value you need to perform a BITWISE OR operation on the existing value. If the value is 4, convert that to binary (100), perform an OR operation with binary 1, the result should be binary 101, which you convert to decimal (5) and enter as the value of the options attribute.

More information

How to connect your on-premise network to Windows Azure using Windows Server as a VPN gateway

Introduction

Together with the launch of Windows Azure Infrastructure as a Service (IaaS) this summer, Microsoft also introduced a way for customers to connect their on-premise networks with Windows Azure using site-to-site VPN.

The service responsibel for this feature is called Windows Azure Gateway. It uses IPSec to establish a site-to-site VPN tunnel between your network and your networks in Windows Azure. Effectively adding a second site to your network. Currently only Cisco and Juniper devices are officially supported as your local part of the tunnel. However since Windows Azure Gateway is using standard IPSec site-to-site tunneling you could theoretically use any device supporting the requirements. One such scenario using Windows Server 2008 R2 as our on-premise router, is the purpose of this port. (If you’re wondering why I’m not using Windows Server 2012, the answer is simply that it does not support the requirements. Specifically Windows Server 2012 does not do NAT-T like Windows Server 2008 R2 does.)

Requirements

The Windows Azure Gateway documentation lists the following requirements for the on-premise VPN device:

VPN device must have a public facing IPv4 address
VPN device must support IKEv1
Establish IPsec Security Associations in Tunnel mode
VPN device must support NAT-T
VPN device must support AES 128-bit encryption function, SHA-1 hashing function, and Diffie-Hellman Perfect Forward Secrecy in “Group 2” mode
VPN device must fragment packets before encapsulating with the VPN headers

Fortunately for us Windows Server 2008 R2 supports all of these! So let’s set it up.

Before you can configure your local device you have to perform these steps in the Windows Azure Management Portal:

Create one or more virtual networks (WAVN) in Windows Azure
These will host you Windows Azure VMs and be your LANs in Windows Azure.
Define a local netwok in Windows Azure
Configure this network with all the subnets that you run in your on-premise network, as well as the public IP address of you VPN device.
Add at least one DNS server to Windows Azure
These can be any DNS server; on-premise, in Windows Azure and public DNS. All the servers you add will be assigned with Windows Azure DHCP to your VMs.
Set aside one subnet within the networks you created in Windows Azure to be the link-network
This network represents the link between you and Windows Azure. It must be within the boundary of the networks you created in Windows Azure in the previous step.
Enter the public IP of your VPN device
The VPN device cannot be behind a NAT, not even a 1:1 NAT with public IPs.
Start the Windows Azure Gateway

These are high-level steps. The Windows Azure documentation goes into great detail about how to configure your cloud networks etc. This post focuses on using Windows Server as you local VPN device so I will not repeat the specific steps here. Instead I refer you to the documentation:

Establish a Site-to-Site VPN Connection
http://msdn.microsoft.com/en-us/library/windowsazure/jj156210.aspx
Create a Virtual Network for Cross-Premises Connectivity
http://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/

After completing the setup in Windows Azure you are ready to configure your local device.

The Windows Server 2008 R2 machine you will be using as your VPN device must have hotfix 2523881 installed. This patch enables the old Windows Server 2003 mode of NAT-Traversal (NAT-T) which is required by Windows Azure Gateway. If you do not have this hotfix installed, you will receive traffic into your network but return traffic will not work. Here is the link to the hotfix:

You cannot establish an IPsec tunnel to a computer that is running Windows 7 or Windows Server 2008 R2 through a NAT device
http://support.microsoft.com/kb/2523881

The Local Network

This is the local network topology in my test environment:

Our task here is to connect our on-premise network with our Windows Azure networks and then promote a server in Windows Azure to a domain controller for our Active Directory domain.

Routing

Your local VPN server does not need to be the default gateway for your local network, but if it is, it will make your setup easier. Suffice it to say that you need to work out the routing requirements in your environment. In this example I assume that the VPN server is also your local default gateway. Your VPN server should not have a default gateway IP set on the NIC connected to the local network (LAN). If you require custom routing use RRAS, the route command or NETSH to set up your routes.

The VPN server

Your local Windows Server machine needs at least two NICs, one connected to your local network and one to the public Internet. The server does not need to be joined to your domain. I highly recomment you keep the Windows Firewall enabled on the VPN server. Having a server directly connected to the Internet without a firewall is not a good idea.

High level setup steps

Document the public IP of your VPN server and the public IP of your Windows Azure Gateway endpoint, as well as your Windows Azure networks and local networks. You will need these during setup.
Find you IPSec encryption key from the Windows Azure portal.
Enable routing
Configue IPSec tunnel
Verify connectivity
Add VM in Windows Azure and promote to domain controller.

Retreive the IPSec encryption key

Log on to the Windows Azure portal and select Networks. Click the network your are connectin your on-site network to and select View Key (you will find this at the bottom of the screen):

Copy the displayed key:

Enable routing

Install the Routing and Remote Access (RRAS) Role Service which is part of the Network Policy Server and Access Services role. You will need to select both Remote Access Service and Routing, one cannot be installed without the other. You can do this either through Server Manager or PowerShell.

The PowerShell command is:

Add-WindowsFeature NPAS-RRAS-Services –IncludeAllSubFeature

Enable and configure Routing and Remote Access for LAN routing only. Right click Routing and Remote Access and select Configure and Enable Routing and Remote Access:

Select Custom Configuration and the select LAN Routing:

What this step does is turn Windows into an IPv4/IPv6 router. It simply tells it to start forwarding IP datagrams. Unless you have special routing requirements in your environment you are finished with configuring RRAS.

Configure the IPSec tunnel

In Windows Server 2008 and newer IPSec settings have been merged into the Windows Firewall.

1. Open Windows Firewall with Advanced Security and select Connection Security Rules:

2. Right click and select New Rule. On the Rule Type page, select Tunnel:

3. On the Tunnel Type screen, leave the default Custom configuration and No for IPSec exemptions selected and click Next:

4. On the Requirements screen leave the default: Require authentication for inbound and outbond connections selected and click Next:

5. Next, on the Tunnel Endpoints screen, configure the tunnel endpoints and networks. (You will have to scroll down to configure the networks for Endpoint 2):

NOTE: It is extremely important that the networks you define here match your local network configuration in Windows Azure or your traffic will not be routed.

6. On the Authentication Methods screen, select Advanced and then press the Customize button:

7. In the Customize Advanced Authentication dialogue add a Preshared key authentication for the First Authentication Methods:

8. On the Profile screen select the Firewall Profiles for which this rule will apply. Usually it will be all three:

9. At the Name screen, give the rule an appropriate name and description:

10. Windows Azure Gateway requires that you change the TCP Maximum Segment Size (MSS) to aviod fragmentation. You do this with NETSH on your external (Internet facing) interface. First list your interfaces:

netsh interface ipv4 show subinterfaces

In the Interface column you should recognize your interface names. Now change the TCP MSS value:

netsh interface ipv4 set subinterface “<name of interface>” mtu=1350 store=persistent

Run the first NETSH command again to verify the change.

11. Configure the IPSec Quick Mode key lifetimes. Windows Azure Gateway uses a Quick Mode (Phase 2) key lifetime of 1 hour (3600 seconds) or 100 GB of traffic, whichever happens first. The Phase 1 key lifetime is 8 hours, which is the default in Windows Server 2008 R2 so there is no need to change that.

Right click the Windows Firewall with Advanced Security node at the top of the Windows Firewall console, and select Properties. Then select the IPSec tab, and press the Customize button:

Next select the Advanced radio button under Data protection (Quick Mode) and press the Customize button. Under Data integrity and encryption select the entry called ESP/SHA1/AES-CBC 128 etc. and press the Edit button:

Under Key lifetimes the timeout value in minutes is already set correctly to 60 minutes (3600 seconds) so we only need to configure the KB timeout. Set it to 102 400 000 KB (100 GB).

Exit out of all the boxes by pressing OK.

NOTE: These are global settings which affect all connection security rules on the server. If you want to specify these settings only on the connection security rule that pertains to Windows Azure, use NETSH. Unfortunately you cannot configur connection security rules specific main mode or quick mode settings in the GUI. Also you cannot use NETSH to configure global quick mode settings, only main mode settings. The logic behind this escapes me…. If you do decide to configure rule specific quick mode settings with NETSH, the GUI will inform you that your rule “…contains properties that are not supported through this interface”. That said I would actually recommend using rule specific quick mode settings because that way you won’t have to change the computer defaults which could potentially cause problems for other rules. Although not needed by Windows Azure Gateway, because the default settings match the required settings, you can also configure specific main mode rules that match e.g. endpoints, using NETSH. More about the diffrences between the Advanced Firewall GUI and NETSH here. Also have a look at the scripts section at the end of the post.

12. Verify that the IPSec tunnel has been created using the Monitoring node of the Windows Firewall with Advanced Security console. Under Security Associations you should have an association under both the Main Mode and Quick Mode nodes:

If you do not see any security associations, try to ping an address in one of your Windows Azure networks. This should establish the tunnel.

13. Verify connectivity in the Windows Azure portal:

Add Windows Azure Virtual Machines

Now you can add Windows Azure VMs to your Windows Azure networks. These machines will receive IP addresses from the Windows Azure DHCP service. The addresses will be leased to the machine for its lifetime so it will be the same as having a static IP. Windows Azure DHCP will also configure the servers with the DNS servers you have defined in Windows Azure. These can be both on premise and in the cloud. The default gateways for the machines will be set to the first address on the subet that the machine is connected to.

Verify connectivity

After the first Windows Azure VM is online (and its firewall opened) you should be able to send traffic across the VPN. In my case I can now ping between my Windows Azure VM and on-premise machines:

Now I can add the make the Windows Azure VM a domain controller:

Scripts

Since network devices like routers and switches are usually configured using scripts, here are the NETSH commands to configure Windows Server as a VPN device from the CLI:

Enable IPv4 routing:
You don’t really need RRAS installed to make Windows Server route IPv4 traffic. You can configure the same functionality directly with NETSH. This removes the requirement for RRAS to be installed. To configure routing you must first find either the interface names or indices of your network interfaces. In this case mine are 12 and 14. 12 is the External interface connected to the Internet and 14 is the Internal interface connected to the LAN. Routing, or IP datagram forwarding, must be configured on both. Use NETSH:
netsh interface ipv4 set interface “12” forwarding=enable netsh interface ipv4 set interface “14” forwarding=enable
Create connection security rule with rule specific quick mode settings:
netsh advfirewall consec add rule name=”Windows Azure” endpoint1=”192.168.0.0/16″ endpoint2=”10.1.0.0/16″ action=”requireinrequireout” description=”Site-to-site VPN for Windows Azure” mode=”tunnel” profile=”any” type=”static” localtunnelendpoint=”80.212.96.194″ remotetunnelendpoint=”168.63.16.208″ protocol=”any” auth1=”computerpsk” auth1psk=”wL8fC…” qmsecmethods=”ESP:SHA1-AES128+60min+102400000kb”
Create main mode rule that matches traffic between the local network and Windows Azure. This rule will then be used by the connection security rule. This is a redundant step since the default settings of Windows Server 2008 R2 match the requirements of Windows Azure. This is just to show how it’s done…
netsh advfirewall mainmode add rule name=”Windows Azure IPSec Main Mode Settings” mmsecmethods=”dhgroup2:aes128-sha1″ mmkeylifetime=”480min,0sess” description=”Main mode settings compatible with Windows Azure Gateway” endpoint1=”192.168.0.0/16″ endpoint2=”10.1.0.0/16″
Configure the TCPMSS size:
netsh interface ipv4 set subinterface “<name of interface>” mtu=1350 store=persistent

So if you combine all the commands in a nice cmd file you have something resembling a router configuration script.

More info on NETSH syntax is available here:

Notes

IPv6 is currently not supported by Windows Azure so you will have no IPv6 native connectivity. Maybe you can make some of the transition technologies work. I have not tested that.
The VPN Server itself will not be able to communicate with virtual machines in Windows Azure. Only computers behind the VPN server will have communication.
I was able to measure a transfer speed of about 9 Mbps between my local network and a Small Instance VM running in Windows Azure. I used IPERF to test.
I have experienced some instability with this solutions but I am not sure if this has to do with Windows Server or Windows Azure. Leave a comment with your experiences.
The Windows Firewall protects your VPN Server on the Internet. make sure that it is configured correctly. May I also suggest to remove any unnecessary bindings on the Internet facing NIC. Also remember that the VPN traffic is not inspected by the firewall since it is inside the tunnel.
The configuration scripts available for supported gateway devices, currently Cisco and Juniper, are quite useful to understand the settings needed to configure your VPN server. These are available for download through the Windows Azure Managmenet Portal, under Networks.
Windows Azure PowerShell can also be used to manage and set up your networks and gateway.