MS Deployment Notes

It's been a while...

2009-09-18T12:07:00.000-07:00

It's been a long time since I've posted on here. We have our deployment working and it's been stable for about a year and a half now I guess. The new MDT 2010 is out now. I never looked at any of the betas for it because I did not want to disturb my current deployment point. I recently downloaded the 2010 (RTM?) and looked at it and it is going to take me a little bit to digest it.

The first thing that I can say about it is that I cannot wait to play with it. The MS folks have added quite a bit of nice features it looks like to me. I wasn't bright enough to understand how to setup one deployment point and have it be a master for some other ones (for lack of a better term). It appears that is easy in 2010 (and was supposedly in earlier ones, but not easy). Following that same way of doing things having a dev and prod deployment looks to be tons easier now too.

There are lots of improvements so if you haven't looked at MDT 2010 you really should take a peek. As I get to start working with it over the next little bit I will get back to updating this blog with the things that I figure out.

Production Deployment

2008-05-28T06:48:00.000-07:00

We started our production deployment here on May 12, and all in all I am pretty happy. There have been a couple "gotchas", but after about a year of working on this thing I have to say it has went very smoothly. One of our biggest issues here is bandwidth. Going from XP to Vista our deployment has, in most instances, trippled in size. With XP we were about 10G in size, and with Vista we are at about 30G. The problem with that is that our network infrastructure is inconsistent at best. There is nothing I can do about that and so that's the limitation that I have to deal with.

The first deployment that we did we did on an 8-port (that's what we had at the time) Gbit switch. That allowed us to do six machines at a time. Two ports were used by the net connection for windows updates and the nas for building from. Those six machines took three hours. Next we put twelve machines on a 100Mb switch. Those machines took four and a half hours. That evening we plugged the nas into the wall and started the rest of our machines (about 25). Sorry I don't have exact figures on this, but by the next morning several machines failed asking for the CD, I think 3 just failed with some deployment error, and 4-6 were still building.

So after looking at this I tried to think of different things to try to get things done faster. First off, I have to say that I am pretty happy with the loading on our nas. I don't know how well it should load, but I know that we were never able to load our old server pulling down ghost images like we are able to do on the nas (If we got more than 5 or 6 ghost sessions going some would start to fail). We are using a Qnap TS-409 Pro nas. One of the things that I thought about doing is copying the application install files down to the local machine and then have the task sequence fire them off the local hdd. Currently the installs are fired off the server/nas. I don't know if that would work in our environment because until the past year we always got the smallest hdd we could from the vendor because we did not really need any bigger drives. I also thought about other temporary network topologies, but nothing really stands out as a solution. So in the end we just opted for a 24-port Gbit switch and let em grind.

The biggest time hog for deployment/installing is Visual Studio 2008. The old version took forever to install. I think this one takes twice as long to install! This install just drives me insane. I have sat and watched the resource monitor for this install and it is just slow. First off the it looks like msiexec.exe needs to be ported over to being a multithreaded app. For most all of the VS install the processor is pegged right at 50%. (I've tried looking to see if there is any documentation on Windows Installer being either single threaded or multithreaded and I could not find anything, so I am assuming it is single threaded.) Office 2007 and CS3 take some time too, but they seem to be a fair amount better about dealing with network/cpu/hdd/memory usage for their installs. VS just seems to have a one track mind though. It is either using network or cpu or hdd, but when one spikes all the others fall off.

As for any errors that I've seen the most common one is a program give me an exit code of 13 and I cannot find a way for the deployment wizzard to accept that return code as ok. Other machines have failed up doing windows updates, which to me is not a show stopper. They will get their updates soon enough. One or two errors happened that caused us to just wipe the drive and start over. I don't remember the exact errors, but they were pretty odd ones about installing Vista and wiping the hdd did the trick.

Quick and dirty "spare" deployment point

2008-05-08T09:26:00.000-07:00

In our environment we have some "problem" labs that we have to deploy Vista into. For one reason or another the network will not really handle deploying several machines at a time. Trying to remedy this solution I got us a nas to work off of. This presents some interesting challenges.

The deployment tool isn't really setup to handle a dual server type setup very well (if at all). I might be missing something that would make this really easy, but I don't think so. Other blogs I have read talk about dns round-robbin and load balancing and the like, but none of those scenarios really address the problems that I face -- slow connections to the server room, either because of a wan-link or a flakey network. At any rate I got us a small nas so that I would have a local resource we could build from in any lab.

What I did was create shares on the nas that are named the same as the ones that are on our primary server. I use two different shares for the deployment and the applications. I then copied all the files over from each share to the corresponding one I made on the nas. After doing this I had to modify a few things to point to the nas.

One of the first things that I had to modify was the bootstrap.ini file to point to my nas -- but that was easier said than done. There might be an easier way to do it than what I put here, but this is what I did. I took the LTI iso and mounted it so I could read/write to it. I then had to open the boot.wim in the Sources folder that is in the iso (for the time being I'm going to leave it to your google-foo to figure that out -- if anyone asks I'll write that up later). I edited the bootstrap.ini in there and saved all of it back out and burned a boot cd.

From there I had to modify serveral files on the nas to point to the nas:

\Control\Applications.xml
and
\Control\*\TS.xml

* is the task sequence number of any task sequence you might use from the nas

I did all of this outside of the deployment tool because I did not want to make two deployment points and I didn't want to duplicate task sequences and have to edit both of them for each change I make (well I have to edit it anyway, but I would rather use a txt editor to do a search and replace rather than using the task sequence GUI).

That's my quick and dirty way to use another server to deploy from. Good luck.

Using Robocopy

2008-04-25T06:14:00.000-07:00

In part of my deployment I use robocopy to copy over a batch file for later use by the system. I am now to the point in my deployment where I am working on the "little" things and getting the kinks out of them. After my task sequence ran robocopy it would fail because robocopy returned an exit code of 1. After doing a bit of digging I found that means everything worked out just fine. So if you are using robocopy in any of your task sequences you will want to find that/those step(s) and go to the options tab and edit a few things. I put a check in front of "Continue on error" so that copying over one file is not going to derail my deployment. I also added in a 1 in the "Success codes:" box. I have not ever touched this box before, but I have faith that is going to solve my problem with robocopy. Be aware that you may have to put other robocopy "success" codes in to make your particular deployment not bark at you.

Booting off USB

2008-03-28T12:48:00.000-07:00

Found a little note in the MSDT help files on booting off USB. I had a couple little gotchas when doing this, and I'll let you know what they are. One of the gotchas is in their instructions so I'll give you my instructions (this wipes your flash drive, just so you know).

1 Open admin cmd prompt.
2 Run "diskpart".
3 Run diskpart command "list disk".
4 Make note of the disk number your flash drive is.
5 Run diskpart command "select disk (drive number)".
6 Run diskpart command "clean".
7 Run diskpart command "create partition primary".
8 Run diskpart command "select partition 1".
9 Run diskpart command "active".
10 Run diskpart command "format fs=fat32".
11 Run diskpart command "assign"
12 Run diskpart command "exit"

Then the instructions tell you to use xcopy to copy the contents of your boot CD to the flash drive. Xcopy would not work for me. I just copied the contents of the CD over to the flash drive and it seems to work just fine.

Remember to disconnect your flash drive before your machine needs to reboot or your sequence will fail.

Custom script move OU failing with 0x8007052E error.

2008-03-28T12:33:00.000-07:00

After upgrading and messing around with some new hardware (looking at a NAS for a mobile build server) I started getting errors with the custom OU moving scripts that I have been using for a while. I copied my deployment point over to the NAS I'm looking at and made the changes needed in the bootstrap.ini and applications.xml files. I tried my deployment off the NAS and when it got to the Z-MoveComputer_StagingOU.wsf script it failed with an error code of 0x8007052E (-2 something dec -- sorry didn't write it down). After doing a fair amount of trouble shooting I found out that off the NAS it did not like the following line in the code (probably 2/3 of the way down):

Set objContainer= openDS.OpenDSObject("LDAP://" & strDC & "/" & strStagingOU, strAccounttoJoinWith & "@" & strDomain, strAccountPassword, ADS_SECURE_AUTHENTICATION)

In particular I had to make admin@domain into doman\admin in order for the script to function. If you are seeing this error then see if swapping that helps you. The NAS is not on the domain and our other deployment server is. I don't know why this would need to change on one vs. the other, but I don't make the rules, I just play the game.

Custom script for automating app install by machine name.

2008-02-28T09:19:00.000-08:00

Phew what a title! Ok so it took me about a week to get this little script functioning. The reason that I came up with this script is that I really could not find a way to have automated application installs by machine name that fit into our "ecosystem". The old way we did application installs in XP and before was by a vbscript. I'm not opposed to the old way, but the old way that we did it had no error checking. What I really wanted to do was come up with something that would tell me what application failed to install if one or more did fail. Since this is already handled in MSDT I really wanted to leverage that.

I don't claim to be a programmer. I'm a hardware guy. I'm sure that someone could come up with more eloquent ways of putting this script together (and if you do please let me know), but what I have works for me. In our environment we have labs that need a basic set of software installed and then they have different sets depending on what lab that is. We have tried as best as we can to standardize our machine names, and that helps a lot. Thus, one of the things this script does is strip out the lab name from the machine name (ie BB100-01 is lab BB100 machine number 01).

The script then looks at a file I've called sourcetxt.txt to see what software needs to get installed where. Because of my ability with scripting everything has to be jumbled up together making it hard to read, but if the data is not in the correct format then the script dies. The data in this file takes the form of:

LabID=All:AppID=keyaccess

LabID can be either All or the name of the lab (BB100 from above). The : is the field delimiter. The AppID is the "name" of the application to be installed. I say it like that because the name is actually a file with that exact name + .txt that has the GUID in it for the application. It can have multiple GUIDs in it. I did this because we key our apps and thus I have the actual app install and then I have the keyed exe to install over it (If I ever get the time to devote to learning key server I could learn to deputize installers, but that's a whole other topic right there).

Included with the zip file are three files: \Z-CUSTOM_LabApps.wsf, \Applications\sourcetxt.txt, and \Applications\winscp.txt

I put my script in the scripts folder and I made a subdir called Applications in that folder to house the two files that references.

After the script strips the lab name out, reads the apps required in the lab and then gets the associated GUIDs of those apps it then writes those values back into the VARIABLES.DAT file. This then allows the MSDT framework to handle the app install and report back any app install errors. If you have applications specified in your CustomSettings.ini file then you will have to modify the script to start with the number that you left off with.

I created my own custom task sequence to run this script. I run it during the Preinstall\New Computer Only section after the "Copy scripts" built-in task runs.

Hope it helps!

Download the LabApps.zip here.

Sidebar crashing when installing applications

2008-02-22T16:04:00.001-08:00

For whatever reason the sidebar seems to like to crash in the middle of application installations. It does not seem to matter what applications (but CS3 seems to be the worst one) I pick to install it seems to die along the way. It's kinda scary seeing those pop-up boxes coming up asking if you want to debug. So I added the following task sequence to kill the sidebar right before installing apps.

taskkill /F /IM sidebar.exe /T

Custom automated apps script coming.

2008-02-22T15:56:00.000-08:00

I think I've came up with my own customs script for automating the application installs. I'm testing now and the script hasn't failed. I just have to now see if MS' programmers are better than I am and the VARIABLES.DAT file can handle spaces and line returns (my script chokes on spaces and line returns). If it can't then I will have to work on my script some more.

Move OU scripts

2008-01-03T12:00:00.001-08:00

Ok I am going to try to get the ball rolling on the scripts for moving your machines around in the OUs.

Fisrt off you will need to get the scripts from the following post:
BDD 2007 - How to move a computer object in Windows PE

The scripts are kinda hidden right before the comments section. Taking a look at that blog post though ought to keep you busy for a bit.

Because I am using a LTI approach I followed the link in the middle of Ben Hunter's post to Johan Arwidmark file. The following is Mr. Johan Arwidmark's complete set of instructions for getting the ADSI to work in a LTI:

Instructions

1. Download the Plugin from http://www.deployvista.com/Repository/WindowsPE20/tabid/73/Default.aspx and extract to C:\Plugins\ADSI

2. Copy the following files from a Windows Vista to C:\Plugins\ADSI

adsldp.dll
adsnt.dll
mscoree.dll
mscorier.dll
mscories.dll

3. Using ImageX, mount your WinPE image (winpe.wim)

Syntax: ImageX /mountrw winpe.wim 1 c:\mount

4. Using PEImg, add support for Windows Scripting Host (For the sample script)

Syntax: PEImg /install=*Scripting* c:\mount\windows

5. Using PEImg, inject the plugin

Syntax: PEImg /inf:C:\Plugins\ADSI\ADSI.inf c:\mount

6. Using ImageX, commit the changes

Syntax: Imagex /unmount /commit c:\mount

Note: A sample script that connects to a DC and lists the users container is provided as well... the plugin will not inject this sample script by default.

These instructions caused problems for me. At first I had problems just getting the instructions to work. Make sure you pay attention to where you installed things and where to you put all your files and plugins and all that good stuff. I ended up making a batch file so I would not have to type those commands over and over again at the command prompt. You need to search and find the imagex.exe and the peimg.exe to use them. After some tweaking to my bat file I got the above instructions to work for me.

{UPDATED since I got feedback from Mr. Ben Hunter.
I don't think I was being clear on what was happening when I responded to Mr. Hunter's blog post. As you can see below in my comments Mr, Hunter has confirmed that step 4 of Mr. Johan Arwidmark's instructions above does need to be left out for MDT to "compile" your WinPE image properly. So you can skip the next paragraph, but I will leave it in so that when you read Mr. Hunter's comment you won't wonder what he's on about.}

After getting that to work I headed back to Ben Hunter's post to march onward. Up until the point where I had to update my deployment point everything went as planned. I did an "Update" [not "Update (files only)"]. In the middle of this MDT (was BDD) would crap out and give me an error. I found the error log for MDT and found out that my install of MDT was already doing step 4 in Mr. Johan Arwidmark's instructions for me. I commented on this to Mr. Ben Hunter on his blog and he did not believe this was possible. Now I believe that Mr. Ben Hunter knows way more about MDT than I do or I ever will. I can only report though what is happening to me. My MDT is, by default, adding in the scripting support that Mr. Ben Hunter says it should not be doing. When MDT would get to the point that it was injecting scripting support into the WinPE image it would throw an error and WinPE creation would fail. If this is happening to you then I would suggest that you not use step 4 in Mr. Johan Arwidmark's instructions.

After clearing that hurdle I ran smack into the next one, which happened to be a brick wall. The next set of problems I ran into cost me about a week. I hope that I will be able to put enough troubleshooting info in this post to get anyone past the errors that I ran into.

I got my PE disc made. I started my LTI process. It pulled down my image. It did a few more thing and then died. I got the got the pink screen of your build is toast. Looking at the details I got the following error:

ZTIERROR - Unhandled error returned by Z-MoveComputer_StagingOU: Table does not exist. (-2147217865)

There are several things that you will need to do to get past this error. First off take a look at the script. You will find that the script starts off by copying global variables into local variables. The first thing that I did was hard code in the script the things that I wanted in those local variables (ie my username, my passwd, the domain controller, and so on). I then started adding in a lot of logging entries so that I could see at what point the script was barfing at. Here is an example of one of the entries that I added:

oLogging.CreateEntry "7VARS:" &strStagingOU&"_"&strComputer&"_"&strAccounttoJoinWith&"_"&"passwd"&"_"&strDomain&"_"&strDC, LogTypeInfo

This helped a lot in tracking down where something had to change to make things work. I put entries like that all over the script.

In case you need help getting started on the troubleshooting of that script, here's what you need to do. You have the pink screen of build death up. Just move that down and out of your way. In the command prompt that is open (there should be 2 -- find the one with the prompt that you can actually type thing in on) you need to open 2 notepads and then connect to your deployment share (net use z: \\SERVER\SHARE$). Go to z:\scripts. Use this command to get started troubleshooting:

cscript Z-MoveComputer_StagingOU.wsf /debug:true

{UPDATED since I got feedback from Mr. Ben Hunter.
It appears that I am having some weirdness with my TS. I had to remove them all and readd them in order for a couple issues to clear up -- one of them being the missing variables getting initialized.}

A current issue that I am dealing with on this script is that MS decided to change a global variable name from one release to the next. To figure that out open the script with one of your notepad windows. With the other notepad window you will need to open the variables.dat (c:\minint\smsosd\osdlogs\) file. I have found that the global var "DomainAdmin" has now been changed to "USERID" and "DomainAdminPassword" has now been changed to "USERPASSWORD". I had to update my script to point to this change. Of course the problem is that my old task sequence still has the old global var name and so I have to totally redo my old TS to make sure that any new TSes that I do work with the move OU scripts.

{UPDATED since I got feedback from Mr. Ben Hunter.
Thanks to Mr. Hunter again on the CN vs OU comment. I know that I was using OU=Computers not CN=Computers. Making the new OU that I called VistaTest worked for me using OU=VistaTest. I don't claim to be an AD guru, but I think I can justify to myself why OU=Computers didn't work. I don't know if I'm correct on that so I will not type out my justification. :) }

Another problem that I encountered with this script is that my domain controller would not allow the scripts to move machines into the generic "computers" OU. When I created a new OU and told the scripts to use that OU I stopped getting errors. I could move the machines into that OU using Users and Computers so I don't know why the script was not allowed. Just something to keep in mind.

A note on the scripts themselves. I was not familiar with what the scripts were actually doing so it seemed to me that they were doing things in reverse. That is by design. The scripts connect to the OU that you want the machine moved into and then it says move the computer here. That threw me off. So if you are looking at the script and thinking "why is it doing it that way, that's backward," then that's probably why.

As far as I can recall that covers the errors that I saw and what I've had to do to fix them.

Desktop resolution problems

2008-01-03T11:25:00.000-08:00

A couple posts ago I talked about the problems I had with my test deployment due to the desktop resolution. To refresh your memory Adobe CS3 requires that the desktop resolution be set to at least 1024x768 or it will not install. If getting errors deploying CS3 make sure it meets all system requirements -- the installer checks!

When our builds started they were at the resolution of 1024x768, but due to a driver update from windows update the resolution was getting reset to 800x600. I assume this is the default resolution that the driver is set to. So after doing a bit of searching I ran across Resolution Changer. This program is able to run from command line to change the resolution of your desktop.

In order to solve my problem I added a task sequence between doing the pre-applications windows updates and installing applications. I added the task as a run command line task. I put the little tool on my server and I run it from there. On the advice of one of the MSDN bloggers I named my custom task "CUSTOM - reschanger" (adding the CUSTOM to the front makes my extra steps a lot easier to find).

For the Command line:
\\SERVER\SHARE$\tools\reschange.exe -width=1024 -height=768 -depth=32 -refresh=60 -force -quiet
(All one line, no line breaks.)

For the Start in:
\\SERVER\SHARE$\tools
(I don't think this is really needed, but I put it in there just in case.)

I ran into a couple issues with this when I first started. At first I just put in the exe and the width and height switches. That gave me errors. Not really in the mood to troubleshoot the errors I added in the command line that you see above and all worked out just fine.

Just running the program by itself gives you a pop-up-box of the switches and what they do.

You can download the program from:
http://www.12noon.com/reschange.htm

Updating MS Deployment

2008-01-03T11:12:00.000-08:00

{UPDATED since I got feedback from Mr. Ben Hunter.
I was wrong on all of this. If you are seeing an issue like the one that I saw below as far as I can tell something is corrupted in your Task Sequences. I deleted all mine (I had two, one prod and one test) and readded them and everything is working just fine now.}

So I ran into another little issue when I updated MS Deployment (was BDD). So it would appear that internally MS decided to change some of the variable names. I am using a script that moves my machines to a temp OU and then back to the original OU after everything runs. Well I turned my stable test task sequence (TS) into my production run. I then branched off that and started doing some more testing of little things (I can't even remember now what). When it got to my custom scripts of the OU stuff it would fail. Since I've spent weeks messing with that script I got fairly good at trouble shooting it (yes that is still going to be put up here at some point). As it turns out MS decided that they should change a variable name from (I think) "DomainAdmin" to "UserName". It would appear that since I imported/converted my old TS it was using the old variable names and so it kept working with my scripts. However when I tried making a new TS it would fail.

Ahhh, the lovely little things that give me job security.

Test Deployment

2007-12-22T10:35:00.000-08:00

On the 17th we started our first test deployment. It went fairly well, but we did run into a few "issues." For all the testing that I have been doing I had hoped that it would have went smoother, but all-in-all I am not complaining.

Here are a few snags that I ran into:

Printer drivers -- I already knew that this was going to be a snag. We us a login script to give our computers the printers they are supposed to get. The script looks at the machine name. With Vista MS has decided that users should not be able to install printer drivers (or any for that matter, I'm certain). In XP because the domain controller said the printer driver was ok XP would let users install that driver. At any rate there is a setting that you can use in Group Policies that will allow users to install a certain set of drivers (printer, sound, video, etc.). The only problem with that is when a user logs in and the script assigns them the printers they are asked if they want to install the driver. I would like to not have to have the user click the "install driver" button. In XP that was all handled in the background. I know that I can set a policy for the printers, but I would prefer not to setup ~20 policies for printers. I guess I'll keep working on that one.

Adobe CS3. You know, I am getting to the point that I am not very happy with Adobe these days. Their installer is just a pain to use, and it does not really help you out where there is an error. On my test machine all the times that I installed CS3 it just worked. When we deployed on Monday we were getting errors from the CS3 installer. Come to find out that CS3 will not install on a machine that has the resolution set to 800x600. When Vista first started installing the resolution was set to 1024x768. During the windows update phase newer drivers would get installed and by default the resolution in those drivers are set to 800x600. So after some searching I found a little command line tool that I could use to get the resolution changed to 1024x768. Since I'm on holiday I'll have to write about that a little later will all the details.

User error. I made several stupid mistakes. I forgot a program that we needed to install. Then when I added it into the applications list I fat fingered it. WooHoo for being prepared. I also had an application that I added into the applications list and copied the command line to have the correct syntax, but then I did not change the filename. I also did not test my application keying well enough and MS Access would crater because it was keyed. WooHoo for paying attention.

Drivers. I found out that you may need to add in some drivers to your driver store in the middle of the build process. I am so thankful that we are using MDT and not our old way of sysprep/ghost/deploy. I was able to make a lot of changes and add drivers in about 30 min and keep deploying. Our old way would have taken half a day just to add in the sound drivers that windows update did not have.

The power also went out in the machine room in the middle of our deployment. That caused all sorts of frustration. Since I use scripts that move machines around to different OUs during the build process I had to go back and put them in the correct place so we could start the builds again once the server came back up.

Did things go as well as I wanted? NO. Did things go well. Yep I think they went pretty well. Just somethings to think of when you start to do your deployment testing.

MS Deployment folder structure

2007-11-12T12:42:00.000-08:00

In your local or network deployment point you will see several folders. Here's what I've learned about them since I've been messing around with either the MDT or BDD tools. This is not going to be an exhaustive list, but rather a general overview for people that may not have seen the folders yet.

My root folder is named Distribution. This is the one that gets shared to our deployment techs.

Under Distribution is 10 folders:
$OEM$
Applications
Boot
Captures
Control
Operating Systems
Out-of-Box Drivers
Packages
Scripts
Tools

$OEM$ -- I don't have a clue. My deployment point has nothing in this folder. You're on your own on this one.

Applications -- My deployment point has nothing in this folder be design. You can do what you will with this folder. If you choose to have MDT manage your applications then it will upload (and del) what it feels it should. I like managing the packages I make for application installation myself.

Boot -- This is where MDT is going to put your images for burning your WinPE CDs at. You will be coping stuff from this folder a lot.

Captures -- I don't have a clue. My deployment point has nothing in this folder. You're on your own on this one. I suspect this is where it would put an image you capture using MDT, but I have not done that.

Control -- This is where your CustomSettings.ini and Bootstrap.ini are going to end up. These folders are going to look a little different (but not much) depending on if you are looking at your local machine vs your network share. On the network share, as far as I know, CS.ini and BS,ini need to live in the root of this folder for WinPE to do what you think it is going to do. Your Task Sequence is also going to live in this folder.

Operating Systems -- Where the OS images are.

Out-of-Box Drivers -- When you import drivers into MDT this is where they go.

Packages -- I don't have a clue. My deployment point has nothing in this folder. You're on your own on this one. I am pretty sure that if you download any patches or language updates for your installs this is where MDT would put them. That's my logical guess.

Scripts -- This is where the big stuff happens in MDT. This is where the scripts are that actually get the things done that you want. If you have any custom scripts this is where they would go. I have downloaded and added in a few custom scripts to this folder. If you are getting weird errors then this is where you are going to have to go into when booted into your PE disc to try to troubleshoot the scripts.

Tools -- This is where a lot of the behind the scenes stuff from MDT is going to live. I don't know much about this folder. I have had to use some of the tools in here when I was working on my custom scripts that I downloaded. This is where the tool for opening and editing the .wim files are. Good luck.

Update vs Update (files only)

2007-11-12T12:26:00.000-08:00

I talk about updating files on here a lot and I would like to make clear what I am referring to. In MS Deployment there are two parts to the files -- there are the local copies and there are the network copies. When you are working on your machine and you edit files all of that happens on your local machine. In order for the 'world' to see your work you are doing you have to publish, or "update", your changes. Below is where you do that:

As you can see in the left pane you have to have the Deploy tree opened and Deployment Points selected. That will bring up your deployment points in your main pane. Right-click on the deployment point that you want to publish your changes to and the little right-click menu pops out that gives you the option to update or update (files only). The "update (files only)"option uploads all the changes you have done to your deployment point so long as they do not have to be incorporated into your WinPE image. If you need to update your CustomSettings.ini or Bootstrap.ini files or you need to include updated network drivers into your WinPE CD then you will need to click the "update" option.

If you are seeing weird things that you are sure you changed then go here and update and reburn your WinPE CD and try again.

Task Sequence problems after updating MS Deployment

2007-11-12T11:59:00.000-08:00

I just updated my MS Deployment tool to the latest version (4.0.383.0, I think). This is the new deployment tool that is now just out of beta. Thus far the update has went pretty smoothly. I have only had one problem. I backed up my work local and network deployment directories. I uninstalled the last MDT beta, and installed the new version. I pointed everything back to where it was supposed to be. When I got the the wizard for adding my local directory I noticed there was an upgrade option. I decided to try that so I wouldn't have to copy over the Vista source and remake my application command lines. Then I updated files and reburned my boot CD.

After booting to my WinPE CD for the first time I was getting a Task Sequencer not found error. This error was cropping up before it would ask for my username and password to connect to the share for the very first time. Because of this I knew it had something to do with the files that were on the CD. The first place I started looking was at my CustomSettings.ini and Bootstrap.ini files. Those files reside in the Control folder. I looked at my network share first and found a folder named {########...}. In that folder was a CustomSettings.ini and Bootstrap.ini file, with the modifications that I needed to have in them. In the root of the control folder there were also CustomSettings.ini and Bootstrap.ini files. These did not have the correct settings that I needed in them.

At this point I looked in my local deployment folder \Distribution\Control and in there were three sub-folders. Two that had the same naming convention as the one on the network share {########...} and another named 100 (which just so happens to be the number I gave my Task Sequence ID for my Vista build). At this point I replaced the 'upgraded' CustomSettings.ini and Bootstrap.ini files with the ones that had the information I needed. (How to explain this the least confusing way possible?) The two folders that have the same name in your network and local folders are what are going to have your old (and presumably working) ini files. The folder that does not get created on the network share is the folder that the ini files are being copied from to the root of the Control folder on your network resource.

Once you get those files copied over on your local machine then you need to update files and reburn your CD. That should then get you going again so you can go back to working on other MDT issues. :)

My CustomSettings.ini and Bootstrap.ini innards

2007-11-09T14:16:00.000-08:00

Here is what I currently have in my CustomSettings.ini and Bootstrap.ini files: I've changed a few things, but you should expect that...

CS:
[Settings]
Priority=Default
Properties=StagingOU,DomainDC
[Default]
OSInstall=YES
UserDataLocation=NONE
SkipAppsOnUpgrade=YES
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipBDDWelcome=YES
AdminPassword=THEPASSWORD
SkipDeploymentType=YES
DeploymentType=NEWCOMPUTER
SkipDomainMembership=NO
JoinDomain=DOMAIN
DomainAdminDomain=DOMAIN
SkipUserData=YES
SkipBuild=NO
BuildiD=Test1
SkipComputerName=NO
ComputerName=TEST-COMPUTER
SkipPackageDisplay=NO
SkipLocaleSelection=YES
UILanguage=en-US
UserLocale=en-US
KeyboardLocale=0409:00000409
SkipTimeZone=YES
TimeZoneName=Mountain Standard Time
SkipApplications=NO
SkipBitLocker=YES
SkipSummary=NO
CaptureGroups=NO
SLShare=\\COMPUTER\logs$
Home_page=http://my.SCHOOL.edu
StagingOU=OU=VistaTest,DC=DOMAIN,DC=ad,DC=SCHOOL,DC=edu
DomainDC=DOMAIN.ad.SCHOOL.edu

CustomSettings.ini settings

Note: The YES' and NO's have to be UPERCASE.

[Settings]
Properties=StagingOU,DomainDC
I had to add this in there because of the custom scripts I found to swap OUs. StagingOU and DomainDC get initalized further down in the [Default] section.

[Default]
OSInstall=YES

UserDataLocation=NONE
SkipAppsOnUpgrade=YES
SkipCapture=YES
The 3 above are used for upgrades -- which I don't know anything about.

SkipAdminPassword=YES
Ask the 'user' to input an admin password when they are building the machine.

SkipProductKey=YES
Has the machine talk to the KMS server.

SkipBDDWelcome=YES
Don't make me click next to get to a useful prompt.

AdminPassword=THEPASSWORD
Put what you want here for the admin password.

SkipDeploymentType=YES
DeploymentType=NEWCOMPUTER
SkipUserData=YES
This formats the HDD and does not save user data.

SkipDomainMembership=NO
JoinDomain=DOMAIN
DomainAdminDomain=DOMAIN
You can prepopulate this to save some typing when telling the setup what domain to join.

SkipBuild=NO
BuildiD=Test1
In MDT you can have several different builds -- this lets you choose which one to prompt for or automatically start building with.

SkipComputerName=NO
ComputerName=TEST-COMPUTER
Prompt for the computer name.

SkipPackageDisplay=NO
SkipApplications=NO
Show what packages get installed and allow the person running the build to check off what gets installed.

SkipLocaleSelection=YES
UILanguage=en-US
UserLocale=en-US
KeyboardLocale=0409:00000409
Lookup these values if you need them to be different.

SkipTimeZone=YES
TimeZoneName=Mountain Standard Time
Look it up if you need something different here.

SkipBitLocker=YES
We are not going to use this.

SkipSummary=NO
Shows the values you have either put into this CS.ini file or typed into the dialogs to check they are correct.

CaptureGroups=NO
Store the members of the current groups on the machine so they can be readded after the machine is built.

SLShare=\\COMPUTER\logs$
Where some logs will be saved at on a network machine if you want them to be. I had a very difficult time getting this to work, but it is very nice when you run into problems with your deployment (and you will).

Home_page=http://my.SCHOOL.edu
Sets the default IE homepage.

StagingOU=OU=VistaTest,DC=DOMAIN,DC=ad,DC=SCHOOL,DC=edu
DomainDC=DOMAIN.ad.SCHOOL.edu
These are added in so that my custom swap OU scripts will work. The DomainDC value has to be something that the WinPE 'install' can resolve. The StagingOU is where you want your machine to be housed on a temp basis so that you can get around any policies that may cause you heartburn with doing installs. For me the generic Computers OU would not work, I had to make a different one -- but more on that in another post.

Boot:
[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES
DeployRoot=\\MYSERVER\Deploy$
UserDomain=DOMAIN
UserID=admin

Bootstrap.ini settings

SkipBDDWelcome=YES
Gets rid of the 'hi welcome to the deployment click next to do anything useful' screen.

DeployRoot=\\MYSERVER\Deploy$
The server share where you have your deployment point at.

UserDomain=DOMAIN
The domain that the below UserID is a part of that let's you have access to the above DeployRoot folder.

UserID=admin
The user name you use to connect to the DeployRoot share.

CustomSettings.ini

2007-11-09T13:41:00.000-08:00

Sysprep.inf is dead! Long live sysprep.inf.

Here's the good stuff on the CustomSettings.ini and Bootstrap.ini if you don't care to read my story on them... CustomSettings.ini lives in the Control folder in your deployment point. If you can't find it in the root then it is in a sub folder. If there are more than one you will need to find out which one actually controls your booting up. I guess it is also worth pointing out that these files get copied to the boot CD if you make one so you have to "recompile" your boot disc everytime you make a change to either of those files. Skip to the bottom for more info without my life's story as it relates to CustomSettings.ini and Bootstrap.ini.

I had *ahem* a very hard time trying to figure that was was driving this Win PE thing that I was being told to use by BDD. I knew that somewhere somehow something was telling PE to do something, but at the time I was trying to figure that out it seemed like finding out what was on the state secrets list. After digging for a long time I finally figured out that the files that I really needed to mess with were Customsettings.ini and Bootstrap.ini.

When I first started my life as a tech working on our lab machines we were using DOS boot disks (and this wasn't THAT long ago -- I'm not THAT old :p ) to start our builds for our XP machines. Eventually we ran into BartPE and life was glorious! The group that I am now a part of syspreped their builds that they made and I started to become very familiar with what that little file did. I worked with that file and got things to smooth out a fair amount. So when I read that sysprep.inf was dead I just couldn't believe that there was not something waiting in the wings to drive the new install system MS had built.

I knew that there were a lot of options in sysprep.inf that would save me a lot of typing and waiting around on dialog boxes. When I first started looking and trying to figure out what was driving this new menu system of course I knew that it was all XML. I tried to wade my way through them, but the only thing that I could really come up with was "yeah the things display things, but somewhere something has to initialize that variable." I am not a programmer and so looking at the scripts folder in my deployment point I was very daunted by the task of trying to follow all those scripts to figure out what was going on. Litterally after looking for 2 weeks, buying 2 books, doing tons of googling, and complaining to anyone that would listen I stumbled across CustomSettings.ini in forum posting I believe. White papers be damned I found what I could actually edit to get that XML that you talked about so much to do things for me!

Eureka!

The base CustomSettings.ini and Bootstrap.ini are very sparse files.

CustomSettings.ini:
[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y

Bootstrap.ini:
[Settings]
Priority=Default

[Default]
DeployRoot=

In the first BDD that I installed you could get to these files, but there was no indication that they would really help you in any way. All the white papers talked about was the other thing that I can't even seem to find in Deployment now. I wasted a lot of time on that thing trying to get it to customize my setup and not understanding what CustomSettings.ini did. Well now that you've listened to my life's story here's a good listing of the things that you can put into CustomSettings.ini to get the things done that you need to get done:

http://technet.microsoft.com/en-us/library/bb490304.aspx

Other Deployment blogs.

2007-11-09T13:26:00.000-08:00

I'm sure that most people already know about these sites, as I can't believe that my blog would come up first on google, but just in case.

http://blogs.technet.com/richardsmith/default.aspx

http://blogs.technet.com/benhunter/default.aspx

And these are more specialized posts that might be very helpful too.

http://windowsconnected.com/forums/p/1871/7315.aspx#7315

http://blogs.technet.com/richardsmith/archive/2007/07/17/useful-registry-changes-during-build-creation.aspx

I will talk a fair amount more about this particular post later, as it sapped away about a week of my time...
http://blogs.technet.com/benhunter/archive/2007/09/16/bdd-2007-how-to-move-a-computer-object-in-windows-pe.aspx

New Applications

2007-11-09T12:59:00.000-08:00

In my limited experience with MS Deployment I have not seen a reason why there are two types of applications that you can add.

The first option of adding an application with source files has done nothing but cause me problems. First off every time you 'update files' it copies the application from your local deployment folder to the server deployment point. This seems like a pretty big waste of time/bandwidth to me. Also, and a lot more annoyingly, is that since it is touching your files on the server, well that means that it is touching your files on the server. If you make a small change to something, or think that you're making a small change to something you might just be erasing your application install point on the server. This has a lot of implications that I just was not happy with. I lost several small packages that I made and it took me a little while to figure out what was happening.

The second option of adding an application that is elsewhere on the network is just what the Dr. ordered for me. I don't know why the first option is there, but in the future I will not be using that. Maybe for someone there is a valid reason to use that option, but I would rather physically touch the files on the server myself rather than have the tool update stuff for me. When using this option I suggest not even using the applications folder that is part of the network deployment point. I have my own network share for applications and I copy the files over myself and I just point the new applications wizard to it.

I hate updating

2007-11-09T12:37:00.000-08:00

I have found that going from one version of BDD/MS Deployment is a pain. If you are starting out with MS Deployment then you are ahead of the game by quite a bit. Moving over from BDD to the beta for Deployment was quite a bit of a hassle for me -- it took a couple days to get my deployments "stable" again. Upgrading from MSD beta to MSD beta took about an afternoon (and most of that had to do with a custom script).

One of my biggest issues that I faced when I was upgrading the first time from BDD to MSD was that I wanted to go from hosting the deployment point on my local machine to hosting it on a server. I was just playing when I first started with BDD and thus I hosted the files off my local machine. When I upgraded I figured it was about time to put them somewhere where more people could get to it to help me test.

Something that I was not aware of -- either because I failed to read it, or it wasn't ever stated -- is that you need to have a "local" deployment point for BDD/MSD and a "network" deployment point, and those should not be the same points. I started seeing some very weird things when I was trying to have my "local" and "network" deployment points at the same point. I was mapping a drive and also "publishing" to the same point. From what I can gather that does not work. I would see things disappear for no reason.

I don't really recall what all my problems were that I was seeing but I cured most all of them when I remade a local deployment point (or file store if you will) and then published to my network deployment point.

Another issue that I had when I upgraded is that I tried to reuse the same exact folder structure and just have MSD rebuild over the top of that. MSD did not really like that and I started to get several of the same files in different places and I had to figure out what files were actually driving the process. That was a big pain.

The last time that I upgraded MSD I backed up both my local and network deployment point and then uninstalled MSD and installed the new version. I then had the new version of MSD create the new local and network deployment points. This worked out a lot better for me. I had to copy my Vista install wim and applications over again, but compared to tracking down what file is messing me up where that saved me a lot of time.

Drivers Folder

2007-11-09T12:28:00.000-08:00

If you have not started working with MS Deployment please, please, please do yourself a favor and make you a drivers folder just for the drivers that you plan to add to your Vista builds. Then when you make that folder come up with a way to know exactly what drivers you have in the folder and what they are for.

When I first started out with BDD (now MS Deployment) I did not do that. I had every intention of doing that, but I did not. I was so eager to get my hands dirty that I put a couple of the drivers that I needed for my test machine somewhere and got to work. Since then I've updated BDD a couple times and I've been asked to add these drivers and make a PE boot disc so we can do some other things and I no longer know what drivers I have and where they are. Don't do that to yourself when it will only take a few extra seconds to be organized from the start.

Just starting off

2007-11-09T11:54:00.000-08:00

I've never really done any blogging. I've made some web pages, but that is about it. I am hoping that I can turn this page into a resource for people that are trying to deploy Windows Vista. I'm not going to make any promises about how that is going to go.

I've been messing with BDD or Microsoft Deployment now for about 6 months. When I got hired on at my current job I was tasked with building the Vista deployment scheme for our general student use computer labs. I was very familiar with how we were doing the XP deployments so I didn't think it was going to be a big deal. Boy was I wrong.

Thus far I've read through some of the white papers that MS shipped with BDD. I was not pleased with the very high level that they were written at. I wanted a click here and do this to accomplish that they documentation. What I was reading was a talk to you network admin and see how much bandwidth you have so that when you deploy you will not crash your network. Handy advice to be sure, but not very useful when our test lab building was 6 to 9 months out.

At any rate, I started getting my feet wet in the Vista deployment waters with BDD. The program was very lacking and fairly buggy. I'm not the type for submitting bug reports so I didn't care to troubleshoot the problems with the program itself. I just wanted to get it fairly stable and drive on with my work. Since then I've come a very long way, I think, and pretty much all on my own. I've done a lot of googling for things. I've tried to decipher other people's blog posts and figure out what I was doing wrong that everyone else seemed to have no problems with.

Some of the things that I would like to discuss here are the problems I've solved (I think), and some of the deadends I went down that I was not smart enough to figure out the solution to.

One of the big things that I had to deal with is OUs. I'll post the problems I was having and my fixes in the future.

The BDD/Deployment tool itself and it's oddities (as far as I see them).

CustomSettings.ini and Bootstrap.ini and what they mean to me.

The structure of the deployment folder.

Some things that I don't know if I will ever get into on this blog is doing system upgrades with the Vista deployment tools. Luckily I just have to wipe the machine and move on. No data is stored locally on the machines that I deal with so I don't care.

Hopefully in the future this will help someone out with their frustrations on dealing with the Vista deployment tools.