In one of the primary environments I manage (at my training company) we have a training network for our students. Each week (or several times per week) new students arrive and expects a newly installed computer. Traditionally we have always used Symantec Ghost to distribute complete fat images (complete images of hard drives). The problems with this is the total amount of data to store the large and number of images to maintain. For instance: we had 5 different computer types and that’s is five base images since they are not hardware agnostic. Then we have some 400 courses in our schedule which gives 5*400 images total a massive numbers of images to maintain. When we were asked to change the start URL for IE, or a patch came, we had to update ALL of the images. This was not a optimal procedure and needed not only lot’s of disk space, but also lots of time. So we needed change.
That’s why we decided to go with WDS, WDS gives us multicasting of the operating system and the ability to use database for configuration and that in turn make it possible to out different programs to different computers without even needing to use a single image, just scripts and config in the MDT. MDT can be built on-top of a SQL database, which can be tied into our LOB data system. MDT was selected as the primary working tool. The big problem with this solution is when we want to deploy large VHD files to be used in the courses, the file size of these are between 20 and 100GB, and after the initial multicast of the operating system MDT would simply copy the resource (VHD) from the server using SMB, this would lead to some 15 connections to the deployment share, and sending the file to all the 15 clients using unicast in a fifteen person classroom. Basically what 15 unicast transfers does is reducing available bandwith with as much as 15 times!! This leads to not being able to complete deployment within the time frame for next course.
This was no problem in ghost since we could use multicast for the full image and even for data file copies (since those images were fat). We could achieve this with MDT also by using a fat image instead of the thin image that we now use. However that would serve almost no purpose.. the images would go down by the five models but still 400 course images.. I looked for some other ways and ended up with producing Data Images and deploying with WDS using Multicast and here is how to do it:
Step 1: Capture files into Data Image
Data Images are basically WIM files with just data, no boot information, no operating system – just plain files. They are to be deployed on a excising file system and does nothing more than amend the file system. This works perfectly for me in this scenario since I just want to “install” VHD files into a directory using multicast. So first I locate the data that I need to put in a file. Example:
IMAGEX /capture C:\Course\VirtualMachines C:\Course\VirtualMachines_MS1234.wim “VirtualMachinesForMS1234”
This will produce a WIM file in the c:\course directory with the content of whatever was in the c:\course\virtualmachines directory and label that WIM VirtualMachinesForMS1234
Step 2: Add image to WDS (Multicast namespace)
This is a bit tricky, there is no “Add data image” to WDS. This is because WDS is not designed to transfer files other than install files. The WDS buils on the transport server which have the actual functionalities for transferring files. What we need to do is to create a new multicast namespace and add that file and directory to that namespace. This is done via command line on the WDS by entering
WDSUTIL /New-Namespace /Namespace-Type:AutoCast /Server:wds01.course.local
/FriendlyName:CourseVM_ms1234 /Namespace:cwm_ms1234 /ContentProvider:WDS /ConfigString:C:\Course
/New-Namespace signals that we would like to create a new namespace
/NamespaceType:AutoCast signals that we would like to create a AutoCast namespace
/Server is on which server the namespace should be created
/FriendlyName is the name which this autocast should be listed in the console
/Namespace is the actual namespace name
/ContentProvider is the content provider, you can develop your own, in my case I will use WDS
/ConfigString is the config that should be forwarded to the ContentProvider, in this case the directory in which the wim file exists
We could actually use just one namespace for all our files if we would like to but that limits the number of simultaneous courses we can install.
Step 3: Starting multicast from the deployed client using wdsmcast.exe in the task sequence
So what I do is to create a MDT application called “Virtual Machines Installer”, the application will consist of ImageX.exe, WDSMCast.exe and batch file called setupVM.cmd which is the file to be called from the MDT install package. The setupVM.cmd get one parameter from environment which must be set prior via variables: the course name. This could be expanded to include more options etc but will be sufficient for my needs. I then repeat the comand as needed.
WDSMCAST /transfer-file /server:wds01.course.local /namespace:”cwm_%CourseID%”
/username:demo\user /password:demoaccount12! /sourcefile:VirtualMachines_%CourseID%.wim
/destinationfile:%TEMP%\VirtualMachines_%CourseID%.wim
Then we are done.. or you now need to do a task-sequence which includes a call to the “Virtual Machines Installer” which will pull over the file to the local machine and then perhaps we need a script to import the virtual machine into Hyper-V but that is out of scope for this short article. Enjoy wdsmcast if you didn’t know about it before. Also I have got the question, why pack this in a wim and not just transfer the files directly. One is compression but most important for me was the ability to have something that can be merged and manipulated using standard tools and to be able to group loads of files and security information in a single file. Happy multicasting! And don’t forget: TechNet is your premier place for more information… goto http://technet.microsoft.com/sv-se/library/cc725964(WS.10).aspx
