I was particularly interested in the features of Azure Connect – up until now called “Project Sydney”. A way of getting your corporate network joined up to the instances you have running in the cloud.
One particular feature I think will interest enterprises (outside of the fact you can connect the network up in the first place), is Domain-Join
In the diagram above you can see how this is achieved. You’d typically install the connect agent on to a domain controller and that DC will be responsible for communicating with the instances in the cloud. It’s recommended you create an AD site to achieve this.
It’s then down to how you wire up the serviceconfiguration.cscfg file which will suport new sections:
- The domain credentials used to perform the domain-join itself
- THe OU you wish to place the server object in which represents your instance. In this case you can see the Target OU in the .cscfg file is “sales” and if you look in the local AD, in the sales OU, you can see the server object CN=Web1, OU=sales, DC=plankytronixx, DC=com.
Putting all this in the .cscfg file has meant it will work with Web or Worker role. For VM roles you need to install a plugin.
Of course, now that you have a “connection” between your local network and the instances you have running in the cloud, it’s as if your corporate network extends out in to the bits of Windows Azure that are hosting your instances. To the rest of the corporate network, they now look like normal Windows servers on your network.
The Windows Azure instances will have a default local Administrators group. In the .cscfg file, you can specify which users or groups from the AD are members of that group – meaning selected individuals and groups can administer the machine (within the limits of the service model).
One feature that has been added with PDC announcements is support for RDP – meaning somebody from your local AD could use a terminal server session to perform the admin functions on the machine.