"Up-ping" the uptime of your Lite-Touch server
I like the lite-touch installation (LTI) feature of MDT, it think it's great and is very impressive as it allows clients to easily see the benefit that they will gain by using MDT to create and deploy their images. I can go on-site with a customer to demo the product and have a basic MDT server configured to deploy Windows Vista and Office 2007 (both with the most basic of configurations) over the network in their laboratory, all in one day. Admittedly, the setup won't do much else because it lacks all the details but, as a demo, it works well. However, one thing that LTI does not offer is 'high-availability'; something that Systems Center Configuration Manager excels at.
In one of my previous posts I wrote about using DNS to create 'distribution points'-like behaviour in LTI scenarios. That post got quite a bit of feedback, so with this post I want to 'steal' another Configuration Manager feature so that it can be applied to a LTI scenario, namely, making your MDT server highly available. With this post you will be able to improve the reliability of your deployments by ensuring that your single point of failure (your MDT server) is always available, simply by clustering your MDT distribution share. As before, I once again recommend Systems Center Configuration Manager as the product of choice if you need a highly-available platform for installing your images as it really is the best option available; the content offered in this post could never replace the functionality offered by Systems Center Configuration Manager.
Windows clustering has been around for many years now, and most people understand how it works; the basic concept is shown in the image below. An active server provides services to the network with a passive server in standby waiting to take over from the active server if it ever stops responding. The change-over, or more correctly called: failover, happens very quick so most people would not even notice that a server has failed. With each version of the Windows Server operating system Microsoft has improved the cluster service, so I will try and stay as generic as possible with this post.
Figure1: a generic diagram showing a typical cluster configuration
With this in mind, an excellent way to improve the availability of your MDT server is to copy the distribution$ folder onto a cluster! All your client computers would then connect to the virtual name of the cluster and use the distribution point for the installation of your operating system image, rather than connect to the MDT server. The only change that you would need to make would be to edit the bootstrap.ini file from your MDT configuration in order to include the virtual name of the cluster rather than the hostname of the MDT server; you'll need to make this change manually because MDT will put it's own hostname there by default. Note that even if you installed MDT onto one of the nodes of the cluster, it would still place the hostname of that node into the bootstrap.ini file rather than the cluster virtual name. This is because MDT is not a cluster aware application.
Example of the bootstrap.ini file for use on a cluster:
[Settings]
Priority=Default[Default]
DeployRoot=\\MYVIRTUALCLUSTER\Distribution$
You will need to create a cluster shared folder resource that shares the folder as "distribution$", without this part it won't work! Also, you will need to manually synchronise any changes you make on the MDT server with the files on the cluster, MDT won't do this for you.
Finally, one important thing to bear in mind is that, in the event of a failover, any existing deployments *might* fail depending on where they are in the process and what they were doing at the time of failover. If a client computer is applying the WIM image when the active server fails, then the process will also fail. If however, the active server fails over during a point in the deployment process when a client computer was not actually using the deployment point then you may find that the process will continue seamlessly, although your mileage will vary with this as it really is an unknown due to various factors in play during failover.
In a follow-up post I will explain how to work with the files on the cluster directly from MDT, so that MDT can update the files onto the clusters shared storage without the need for you to copy the files over manually when you make changes. Stay tuned!
This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain