Azure Site Recovery is now available as Preview

Azure Site Recovery is now available as Preview. This service formerly known as Azure Hyper-V Recovery Manager is able to orchestrate failover between two customer owned sites.

It is also able to replicate Hyper-V virtual machine to Microsoft Azure datacenters saving customers on costs of a secondary datacenter.

Besides replication to Azure the service also allows an orchestrated recovery of virtual machines in case of failover to an Azure datacenter.

Customers must be using System Center Virtual Machine Manager 2012 R and virtual machines running on Hyper-V. At the moment only Generation 1 VMs are supported. VHD & VHDX virtual disk files are supported.

A getting started with Azure Site Recovery  for on-premises to Azure is available here.

More information on Site Recovery here.

During Preview customers ger a 50% discount on pricing. The costs of protecting on-premises virtual machines to Microsoft Azure are $ 27,- per month per virtual machine *during Preview* . Customers receive 100GB of replication and storage per VM. Charging is based on an average usage per month. Suppose a customer protects 20 virtual machines for the first half of the month and none for the second half, the average daily number of protected virtual machines being charged by Microsoft would be 10.

Costs for using Azure Site Recovery as an orchestration tool for replication to another customer managed site is $ 16,- per month per virtual machine.

I will cover Azure Site Recovery in my new book on Microsoft hybrid cloud.

Microsoft DirSync to be replaced by Azure Active Directory Sync Services

Microsoft is actively working on enhancements to connect on-premises Active Directory to Azure Active Directory.

DirSync and Active Directory Federation Services are two options to connect both. DirSync can now be used as a backup for ADFS. See my post here.

Microsoft is working on a replacement for DirSync. DirSync is a software tool used to synchronize objects located in an  on-premises, single forest Active Directory  to Azure Active Directory. Azure Active Directory is the Microsoft multi-tenent cloud version of Active Directory used for identity management for services like Office 365.

DirSync is basically an implementation of Forefront Identity Manage but with limited features. For example it is not able to sync objects of multiple on-premises AD forests nor is it able to handle multiple Exchange organizations.

To support these scenarios enterprises are at the moment required to use Forefront Identity Manager. However, configuring FIM can be challenging and can take considerable time.

The new tool which replaces DirSync will be named Azure Active Directory Sync Services or AADSync.  AADSync significantly simplifies the configuration and makes it more predictive.

Microsoft Azure Active Directory Sync Services (AADSync) is used to onboard an on-prem environment to Windows Azure Active Directory and Office 365 and continue to synchronize changes. It is used for more advanced scenarios where DirSync does not provide support, for example multiple on-prem AD forests. At the moment AADSync does not support multiple Azure subscriptions.

AADSync will also be able to synchronize Exchange Global Address Lists. Support for PowerShell is also available, it has about 58 commands.

Microsoft Azure Active Directory Sync Services is currently available in customer technology preview (CTP).  This is a first beta release.

You can join the Azure Active Directory Sync Services preview here. The AADSync preview will then be added to your Microsoft Connect account. Through this you will be able to download the most recent version, get information on known issues and updates, as well as provide feedback.

Currently AADSync is in beta. You may not use this release in a production environment unless agreed to by Microsoft. For customers participating in the TAP program, the beta can be used in production.
To be considered for the TAP program, please contact the feedback alias

Mind AADSync does not have these features at the moment:

    • Exchange hybrid co-existence is not available.
    • Compared to DirSync, the following features are not available:
      • Password synchronization
      • Self-service password reset write-bac

More information on AADSync here.

Documentation on AADSync can be found here 


Synchronized identity (Dirsync) can now be used as backup for Federated identity in Office 365 and Azure

In May 2014 Microsoft made available an important update for federated authentication to Office 365 and Microsoft Azure. This update is not very known so far so I hope this blog helps to understand the benefit of this update!

Lets start with some basics about authentication for Microsoft cloud based services.

Authentication for Microsoft online cloud based services like Office 365 and Microsoft Azure can be performed using three models:

  • Cloud Identity (also known as Standard authentication) using cloud based username and password stored in Windows Azure Active Directory. Usernames are typically useraccount@<organization>
  • Synchronized Identity (also known as Managed Authentication) allowing synced usernames and passwords with on-premises Active Directory as source
  • Federated identity (Federated Authentication) allowing Single Sign-On to Microsoft Office 365 & Azure because of a federation with an on-premisis Active Directory

A very good post by Microsoft on identify is titled  Choosing a sign-in model for Office 365.

Federated identity enables users which are authenticated to on-premises Active Directory to access Office 365 and Azure without additional authentication (Single Sign-On). To enable such a scenario several servers are required to be installed in the on-premises environment. In many cases redundancy of roles like Active Directory Federation Services (AFDS) is required. The reason for this is that if ADFS is not available users will not be able to authenticate to Office 365 and Azure. Active Directory is the single source for authentication in this scenario.

This has changed now! Since May 2014 Synchronized Identity can be used as a backup in case Federated identity is not available because of a failure (server crash, internet connection to on-premises failed, power failure etc).

Introducing Synchronized Identity

Synchronized Identity enables users to use their AD username and password to sign in to Office 365, Azure etc.
Synchronized Identity  is enabled by installing a free Microsoft tool called Dirsync. Dirsync will synchronize useraccounts plus passwords from AD to Windows Azure Active Directory (WAAD). WAAD is a multi-tenant implementation of Active Directory. It is used for authentication services by Office 365 and Microsoft Azure. Dirsync hashes the password. Dirsync is very easy to install and straightforward to use. There are hardly any issues reported.

Dirsync however does not allow Single Sign on.

To make life easier for users Federated Identity can be used. Configuration for this model is not as easy as using Dirsync. Several servers are required to be installed on-premises.You need dedicated IPs, proxies, certificates, load balancers which are not free, and set quite a few security policies.
Before Microsoft added the Password sync option in Dirsyc the only userfriendly way tp authenticate to Office 365 was using ADFS.

Dirsyc is required for Federated Identity. At sign in a check is performed if a valid useracount is used for authentication. Federated Identity does not check the password to WAAD. WAAD trusts the on-premises ADFS as a ‘password’ provider.

You now understand  availability of ADFS is critical! If it does not work your users will not be able to authenticate as there is no way to check the password. Even when the hashed password of the user is stored in WAAD, it would  not be used if the domain was configured for Federated Identity.

However in May 2014 Microsoft made a change in WAAD. User accounts can now be configured for BOTH Single Sign-on as well as for password synchronization (. This enables a fall back if ADFS Federated Identity is not available.



How to perform a temporary switch to  Synchronized Identity

WAAD will not automatically fall back to Synchronized Identity when Single Sign-On is not possible because of a failure in connecting to ADFS. Administrators will have to manual switch back to Synchronized Identity.

The temporary switch from Federated Identity to Synchronized Identity takes two hours plus an additional hour for each 2,000 users in the domain.

You will need to use the Windows Azure Active Directory Module for Windows PowerShell to switch a namespace from Federated (Single Sign-On) to Managed (password sync).

Use this PowerShell command for a temporary switch to Synchronized Identity
Convert-MSOLDomainToStandard –DomainName <federated domain name> -SkipUserConversion $true -PasswordFile c:\userpasswords.txt

For detailed instructions read this post


Partners will be able to resell Microsoft Azure in Open Licensing per August 1

Microsoft customers  wanting to use Microsoft Azure services currently have two options for purchasing:

1. Register for Azure and submit creditcard details. Microsoft will charge on pay-as-you go. For enterprises using a creditcard it is very difficult to manage costs and perform chargeback to internal departments.
2. Buy Azure credits as part of an Enterprise Agreement. Enterprise Agreements are sold exclusively by Microsoft Licensing Solution Providers (LSP , the new name for Large Account Reseller). The disadvantage of purchasing Azure in Enterprise Agreement is  the customer needs to buy up-front credits. Those credits last for one year. If not consumed the remaining credit is lost. 

The current model was not very attractive for system integrators (SIs) and value-added resellers (VARs). When they help customers onboarding to Microsoft Azure they get a kickback fee lasting two years while Microsoft does the billing. The registration of leads by the partner and receiving the kickback free is a rather complex and lengthy process.

Especially System Integrators selling hardware like storage would hesitate to onboard a customer to Microsoft Azure. It could turn out to a shoot in the own foot as they start to loss the revenue of selling hardware as well as the relationship with the customer.

Microsoft is now enabling selling of Azure more easily.

Starting August 1 Microsoft Azure becomes available in Open Licensing. Open License is a two year agreement with Microsoft for buying software licenses. Targeted at organizations having 5 to max 250 devices. Customers pay up-front.

Microsoft Partners will be able to purchase tokens from a distributor. The partner resells tokens to their customer. Reselling is actually adding the tokens (each worth $ 100,-) to the Azure subscription of the customer. This enables a billing relationship between the Microsoft partner and the customer consuming Azure resources. It also ensures recurring revenue for the partner.  Mind the credit is only valid for 1 year. Remaining credit does not roll over to the next year!

More information here and here.

Aidan Finn wrote a blogpost about this news here. As usual his opinions are just a little bit  biased. His quote below is incorrect.

finn-biasMicrosoft  certainly does not have a unique selling point here. VMware has a hybrid cloud offer as well. Not only VMware itself offers a public IaaS service (VMware vCloud Hybrid Service or vCHS owned by VMware) which connects seamless to on-premises vSphere infrastructures. There are also many vCloud Providers offering public IaaS with excellent connectivity to on-premises owned datacenters.

Microsoft is not the only cloud vendor with a partner-enabling model. VMware vCHS is sold the same way as on-premise VMware licenses with a standard SKU and partners can retain the billing relationship with their customers.

Amazon has a Channel Reseller Programm for quite some time now.



Microsoft adds new virtual machine sizes to Microsoft Azure

Today Microsoft announced it added two new virtual  machine sizes to Microsoft Azure. Those are available both in the Azure IaaS and PaaS offering (web and worker roles).

These two sizes name A8 and A9 provide faster processors, faster interconnect, more virtual cores for higher compute power, larger amounts of memory. These instances include an additional 40Gbit/s InfiniBand network that provides remote direct memory access (RDMA) technology for maximum efficiency of parallel MPI applications. This combination of features make these instances optimal for running compute and network intensive applications such as high performance cluster applications, applications using modeling, simulation and analysis, video encoding etc. Detailed configurations of these instances are available. 

A8 has 8 virtual cores and 56 GB of virtual memory

A9 has 16 virtual cores and 112 GB of virtual memory.

Both are available immediately. However A8 and A9 Vm’s can only be created using PowerShell at the moment. Creation using the Azure Management Portal will be available in the coming weeks.

More info here.


Microsoft announces Microsoft Azure Files

At TechEd 2014 in Houston Microsoft announced a new service named  ‘Azure Files’. The service is now in preview. The reason for this feature is to allow to migration of traditional applications requiring a SMB fileshare to Microsoft Azure. 

Azure Files allows VMs in an Azure Data Center to mount a shared file system using the SMB protocol. These VMs will then be able to access the file system using standard Windows file APIs (CreateFile, ReadFile, WriteFile, etc). Many VMs (or PaaS roles) can attach to these file systems concurrently, allowing you to share persistent data easily between various roles and instances. In addition to accessing your files through the Windows file APIs, you can access your data using the file REST API, which is similar to the familiar blob interface.

Basically blob storage can now be accessed over SMB just like being served from a Windows VM. With Azure files no requirement for a VM to serve files. Untill now files stored in Azure Storage could only be accessed using REST API over http.

It can be compared to a traditional storage array being able to present files using SMB.

Files served out by Azure files seem to be only accesible from VM’s running in Azure.

much more information here. 

Microsoft Azure introduces Zone Redundant Storage (ZRS)

Microsoft Azure introduces in the next months a new option for customers to have their data highly available. Zone Redundant Storage  is a mix of two currently available options for data redundancy: it replicates data to other datacenters but is limited to three copies.

Currently Microsoft Azure (the cloud service formerly known as Windows Azure) offers customers two choices for keeping data highly available.

1. Locally redundant storage (LRS). Data is stored as three different copies inside the same facility. A facility is a physical datacenter in a single region. Data is replicated synchronously

2. Geo redundant storage (GRS). This is the default option when creating an Azure Storage Account. Data is stored as three different copies inside the same, primary datacenter (like LRS). Additionally, three copies of the data are also stored in a secondary datacenter located in another region. So in total data is stored six times. Replication to the secondary location is performed asynchronously. Distance between the two regions is a couple of hundred miles. In some cases the replicated data is stored in a different county. (Amsterdam-Dublin,Singapore-Hong Kong, Brasil- San Antonio, Texas)

Image source.

The main purpose for replication is disaster recovery. In case a facility has a technical issue or is unavailable (fire, flooding etc), a copy of the data is available in another region. Mind that this replication is mainly an issurance for Microsoft to meet the SLA. Microsoft staff will decide to failover to the replicated data in case of issues. Customers cannot initiate a failover.

Since the first week of April 2014 Read Access Geo Redundant Storage (RA-GRS) is general available. RA-GRS allows customers to have read access to the data stored in the secondary region. Writes are not possible to this secondary region.

A new, third option for data availability named Zone Redundant Storage (ZRS) will become available in the coming months. It allows data to be replicated to a secondary datacenter/facility located in the same region or to a paired region. Instead of storing 6 copies of data like GRS does, 3 copies of data are stored. So ZRS is a mix of LRS and GRS. Three copies but stored in different datacenters/facilities. I am not sure if all Azure regions have more than one datacenter. If not, the data will replicated to another region.

ZRS will be priced 37.5% lower than GRS as it becomes available.




Windows Azure now allows to set fixed IP-addresses for virtual machines

Untill recently IP-addresses of Azure virtual machines were not static/fixed. A VM which had been shutdown (for example to reduce costs, think test/dev scenario’s) could receive a different IP-address at boot than orginally assigned at creation. This leads to all kinds of issues. A new Powershell for Azure version solves this issue.

Windows Azure once started as a Platform as a Service (Paas) offer. It is also a best effort cloud, which means the availability should be provided by the application, not by the platform. This is proven for example by the lack of a Service Level Agreement for single instance virtual machines. Customers are required to have at least two virtual machines serving the same application to get a SLA.

Since April 2013 Azure offers Virtual Machines which provides the ability for customers to have full control over the guest operating system. One of the tricky things in Azure VM’s is networking. When using traditional enterprise applications administrators want to have control over the IP-configuration of the virtual machines. However VM’s should be set to DHCP at all times. The reason for this is the Software Defined Networking architecture used in Azure.

When using Azure Virtual Networks administrators can define IP-subnets and DNS servers for their virtual machines. The first virtual machine which boots in an empty subnet will receive x.x.x.4 as IP-address, the second x.x.x.5 etc. This allows for some prediction of which IP-address a VM will receive. However, when a virtual machine is switched off, it might loose it’s IP-address when another VM in that subnet boots.

Set fixed IP
Microsoft offers a solution for this issue. Since the release of PowerShell cmdlets for Windows Azure version 0.7.3 released at February 12, 2014  it is possible to glue a IP-address to a particular virtual machine. So even if a VM is not running for a while, it will receive it’s originally assigned IP-address at boot.

More information on PowerShell for Azure here.

Four news cmdlets were added in PowerShell for Azure 0.7.3 :

  • Get-AzureStaticVNetIP
  • Set-AzureStaticVNetIP
  • Remove-AzureStaticVNetIP
  • Test-AzureStaticVNetIP

The guest operating system still have to be set to using DHCP. However there is some sort of permanent reservation made in the Azure fabric.

Some things to consider are:

  • setting a fixed IP-address to a VM can only be done using PowerShell. It is not possible using the Azure Management Portal
  • setting a fixed IP-address can only be done at creation of the VM. When the VM has already been created the PowerShell command will not work
  • it is required that the VM is part of a Azure Virtual Network

More information including some sample PowerShell scripts in the blogs below.

This information will also be described in my to be released book on Microsoft hybrid cloud. The book will provide an indepth look in Windows Azure IaaS. Also I will cover management, connecting System Center to Azure and lots more.

More info on my book will be published on this website.

MSDN blog: Allocating Static IP Addresses to your VMs
Stufox. Static IPs in Windows Azure
WindowsITPro Set Azure VM static IP address

Unable to install .NET Framework 3.5 feature in Azure Windows Server images

Windows Azure provides images of Windows Server 2008 and 2012. Using a few mouseclicks a new virtual machine can be depoyed in just minutes.

Just like when using your own Windows install, if you need .NET Framework 3.5 you will need to install this feature. It is listed in the ‘Add roles and features’ wizard.

In Windows Azure you might get the error listed below:

Installation of one or more roles, role services, or features failed. The source files could not be found.


You will get the following error if the conditions listed below are valid:

1. the virtual machine is part of an Azure Virtual Network

2. DNS server(s) are added to the Azure Virtual Network configuration

3. Those DNS server do not have a forward to an external DNS server able to resolve internet based servers.

Cause of issue

For installing .NET 3.5,  Windows Server needs to download binaries located on an internet server. Probably located at

If your Azure virtual machine is not part of a virtual network, it will be configured with a Microsoft managed DNS server by DHCP. This DNS server will be able to resolve DNS queries to internet based servers. So download and installation of .NET will be sucesfully.

If the VM is part of a virtual network, and you filled in the DNS server name/IP, you as tenant are responsible for providing DNS.

In the Azure Virtual  Network configuration tab a DNS servername and IP-address can be supplied. Make sure this DNS server is able to resolve internet based servers. If not, download of .NET and thus install will fail.

If you do not manage/have access to  a DNS server, use Google public DNS at

Make sure to reboot the VM if you make changes to the Virtual Network configuration. Ipconfig will not result in providing the VM with DNS server details.

How to create a site-to-site VPN connection using ADSL to Windows Azure

For research on my to be released book on Windows Azure I had to create a site-to-site VPN connection from my home to Windows Azure. Untill recently I was under the impression I needed a VPN device or Windows RRAS server configured with a public facing IP-address to be able to have such a site-to-site VPN.

However, that is not the case. Using a common ADSL modem, Hyper-V manager and a virtual machine running Windows Server 2012 with RRAS I was able to setup the VPN connection.

Thanks to Christopher Keyaert  who blogs at who helped me. Read his blog which describes how to update Azure networking if your ADSL connection has a dynamic IP. 

My ADSL modem is a Fritz!Box 7270. I did not have to modify the configuration of the modem. You might want to add a route in your modem pointing to your RRAS server if other servers need access to Azure VMs.

The site-to-site can be setup using a physical server with RRAS installed as well. No need for the RRAS server to have a public IP.

In my book I will publish a step by step instruction how to configure this. In this post I will provide the basic steps. There are many other posts explaining how to setup a site-to-site VPN connection. For example this one. 

1. In the Azure Management Portal create a virtual network. First create a new local network. In here you configure the public IP-address which is assigned to your ADSL modem. You also specify the IP-subnet used in your home location. Mine is

2. Enable ‘configure site-to-site VPN’.

3. Then create a gateway in the portal. Select dynamic routing. Creation of the gateway will take about 5 to 10 minutes.

4. After the creation has finished, select ‘Download VPN device script. Choose Windows Server RRAS and store the .cfg file on your RRAS server.

5. Rename the .cfg file to PS1. Start PowerShell and execute the .PS1 file. You might have to change the execute policy .

The PowerShell script adds a Network interface to the RRAS server. This connects to the IP-address of the Azure gateway. When the script has finished open Routing and Remote Access console. Select Network Interfaces-> then select the demand dial connection named as IP-address of the Azure gateway. Right click and select Connect.

If all goes well a VPN connection is enabled.

Make sure the Ethernet network interface of the RRAS server which connects to your internal (home) network does not have a gateway filled in for the IP-properties. Otherwise ip-traffic will not flow to and from Windows Azure.

Also make sure the firewall on the RRAS server does not block VPN-traffic.

In Windows Azure create a virtual machine and make sure it is added to the virtual network you created in the first step. After creation has finished, open an RDP connection. Then make sure the Windows Server firewall does not block VPN traffic.

That is it. You now should be able to ping or use any other connection from your home server (RRAS) to a virtual machine in Azure.

Please let me know if you have issues in setting up the S2S VPN (mvdb22 at gmail dot com )

How to capture an image of an Azure Windows Server virtual machine the safe way

Customers can create custom made Windows Server images in Windows Azure based on their own created baseline Windows Server image. A custom made image provides a way to deploy virtual machines which are identically configured.

Windows Azure currently has issues which can cause unwanted lost of a baseline image resulting in lost of work. This is because the server on which sysprep is exectuted is not shutdown but rebooted by Azure.

This blogpost describes a workaround.

The procedure to create an image is simple:

  1. Deploy a virtual machine using a Microsoft supplied image or your own image
  2. customize the guest operating system
  3. execute sysprep
  4. capture the guest operating system OS disk and publish it as an image

Sysprep should be performed by selecting ‘shutdown’. Because of an issue in Windows Azure in certain circumstances Azure restarts the guest when a guest initiated shutdown is selected.

This results is customers not being able to Capture the virtual machine because it is still running in a state waiting for input after the reboot.

This issue is hard to reproduce. In many cases customers will not encounter an issue. However I encountered this issue 4 times in a row on 4 different servers.

Microsoft does planned maintenance on Windows Azure for installation of bug fixes and new features. These updates are done in batches which means at any given time some hosts are running as non-patched and some are patched. When  Microsoft has patched all hosts this problem will not occur.

The workaround is simple: in Sysprep select Quit instead of Shutdown. Then do a Shutdown initiated from the Azure Management Console.When the VM has stopped a capture can be performed.

This blogpost has all the details.



Running Citrix AppController on Windows Azure (it won’t)!

Since 2013 Citrix supports running XenApp & XenDesktop on Windows Azure.  I wanted to be able to have a demo / Proof of concept  environment showing XenApp, XenMobile, AppController and ShareFile on Windows Azure to demo to customers.

My  experiment was to see if AppController can  run on Windows Azure. To make a long story short: it does not… 

If you are interested in why not, read on.

AppController is distributed by Citrix as a virtual appliance. It can run on XenServer, Hyper-V and VMware ESXi. I could not find any documentation which said which Linux distribution is used. If I had that info I could decide if AppController could be run on Azure. There is no mentioning of Azure support in Citrix documentation nor on blogs. 

As Azure runs Hyper-V 2008 and Hyper-V 2012 in datacenters and does support some Linux guest I deciced just to give it a go. In the Netherlands we say “if you do not shoot, you will always miss.. ”

So I downloaded the VHD file and created a new virtual machine on Hyper-V Manager. This allowed me to configure the appliance. It requires  an IP-address.  I set this is x.x.x.4 .  I enabled SSH to be able to do some remote management.

I also created a virtual network in Azure to have control over the subnet used by the AppController VM.

First challenge was the format of the VHD supplied by Citrix. This was in a dynamically expanding disk which Azure does not support. So I needed to convert the vhd from dynamically expanding to fixed size. I used Hyper-V Manager for that task. Mind you will need enough diskspace to host the maximum filesize of the VHD. The maximum filesize of the supplied VHD is set to 50 GB.

After that I did an upload to Azure and tried to convert the VHD to Disk. Error! Grrr.  The filesize was not a whole number. So used Vhd resizer on my laptop to convert the vhd filesize to a whole number. This finished in about 15 minutes.

Another upload. Luckily empty spaces in a VHD are not uploaded to Azure so upload is rather quick.

As an administrator you do not have much control over IP assignment in Azure. IP-addresses are assigned by a Microsoft managed DHCP server. The first VM which boots in an ’empty’ subnet will receive IP x.x.x.4 , the next x.x.x.5 and so on.

So created a VM using the just uploaded vhd. Made sure this VM was the first in the subnet. Booted the VM and the state shows running. However no response on http/https/ssh.

Windows Azure does not offer a remote console. So there is no way to monitor the boot process of this Linux based virtual machine. I guess the boot process just halts on trying to ‘find’ some hardware devices like network interface.

I hope this info was usefull.


App Controller 2012 R2 unable to deploy Linux images

System Center App Controller is a self-service portal which allows non-IT staff to deploy virtual machines to clouds on-premise, in Service Provider clouds or in Windows Azure.

Windows Azure supports both Windows Server and Linux as guest operating system in a virtual machine.

However when using App Controller 2012 R2 those Linux images are not available for deployment. Three different Linux images are shown but are greyed out.


When using the Azure Management Portal a choice of 9 different Linux images is available:  various versions of Ubuntu, CentOS (Openlogic distribution), SUSE and Oracle Linux.

This is caused by a limitation of App Controller. When preparing a deployment of a virtual machine App Controller creates a so called Configuration Set. This is an XML file which has information like the computername, user account and password or certificate. When user input has been recieved App Controller transmit this information to Azure.

At this moment App Controller 2012 R2 lacks the ability to deploy Linux images.

Guide: How to sync on-premise Active Directory to Windows Azure Active Directory

Microsoft released a Test Lab Guide which explains in detail how to synchronize an organization Active Directory with Windows Azure Active Directory.

Organizations moving to a hybrid cloud want to be able to provide identity management for services running on Windows Azure whil not depending on their on-premise Active Directory.

By using Windows Active Directory Synchronization Tool (DirSync) on-premise AD can be synchronized to Windows Azure Active Directory.

This 48-pages documents explains step by step how to sign up for a free trial of Azure, how to enable WAAD and how to setup and configure DirSync.


Since November 2013 DirSync can be installed on a server with Active Directory installed. So only a single DC is needed to be able to use this Lab Guide.

More information and download of the guide here.

Free ebook: Introducing Microsoft System Center 2012 R2

Microsoft published a new free ebook titled:  Introducing Microsoft System Center 2012 R2. The book is currently available in PDF format only. Mobi and ePub format will be available soon. The ebook has 155 pages and provides a high level overview of Microsoft Cloud OS and System Center 2012 R2 is particular. Each chapter has an overview of one of the components of System Center. Content of each chapter includes an introduction, some screenshots, a Microsoft expert writing about new features and links to more information.

This ebook provides a good insight into System Center 2012 R2 and is highly recommended for those who are looking for an easy to consume total overview.

Download here.

%d bloggers like this: