I understand that using litetouch to create the reference image is going to be my best approach, but using a fully patched base seems to be a good place to start for creating either a thick or thin reference.

My question is about what state to leave the the patched base in depending on the whether I plan on building a thick or thin reference image and how to setup the task sequence for either. Based on my earlier experience with imagex, for at least the thick
image I would want to deploy my patched base image to a VM and have it boot into "Audit mode." Would the same be correct for creating a litetouch deploy? Or am I just missing something about how MDT works?

Answers

You could do that. Personally, I don't allow my "build" task sequences to capture an image. I deploy the "bare" OS from source files and go through the patching process (which should include any reboots required for installation of said
patches). After the machine is fully patched, I shutdown and snapshot the VM.

There are plenty of folks who go through the full process when building an image - deploy bare OS, patch, layer applications, sysprep and capture image, all within a single TS. I find that process to be too unwieldy considering some of the legacy apps I
need to install, which require a certain level of TLC.

I've never had need to boot into Audit Mode, so I can't speak to that. I have what I've always called "hybrid" images, which are about 80% thick and 20% thin, i.e. most of my apps are installed on the image itself; some of them are installed at
the time of deployment.

Keep in mind what we're talking about is a Base OS image with all applicable Windows Updates. You would typically deploy that Base OS image in order to build a custom image that will be deployed to end-use devices.

You can just as easily leave step 2 as a VM snapshot and not actually capture the image. I simply like having the WIM file in case of <insert scenario here>.

If you are concerned about leaving an end-user device with the Administrator logged on, you can add a logoff or reboot finish action to your rules file. (CustomSettings.ini.) Search the MDT documentation for "Property Definitions" to get a list of
all the thing you can set with the rules file, such as skipping Wizard panes and setting finish actions.

All replies

Create a task sequence to install an image from source files, such as an ISO provided by Microsoft. Once deployed, patch the image in whatever manner you normally do - Internet, WSUS, so on. When the image is patched fully, shut down the VM, take a snapshot.

Create a task sequence to install an image from source files, such as an ISO provided by Microsoft. Once deployed, patch the image in whatever manner you normally do - Internet, WSUS, so on. When the image is patched fully, shut down the VM, take a snapshot.

If you want to capture an image at this point, revert to snapshot and then run a sysprep & capture task sequence, described here:

-Nick O.

Hi, Nick. Thanks for the quick reply.

Do I understand you correctly that I should shutdown the VM at the MDT summary page without letting it reboot? I've already created an image similar to what you suggest. It's task sequence installs the updates AND then immediately captures the image. When
this image is deployed it boots into the Administrator account automatically. How would I get it to boot into Audit Mode without creating an administrator account when I want to use it to create a thick image?

You could do that. Personally, I don't allow my "build" task sequences to capture an image. I deploy the "bare" OS from source files and go through the patching process (which should include any reboots required for installation of said
patches). After the machine is fully patched, I shutdown and snapshot the VM.

There are plenty of folks who go through the full process when building an image - deploy bare OS, patch, layer applications, sysprep and capture image, all within a single TS. I find that process to be too unwieldy considering some of the legacy apps I
need to install, which require a certain level of TLC.

I've never had need to boot into Audit Mode, so I can't speak to that. I have what I've always called "hybrid" images, which are about 80% thick and 20% thin, i.e. most of my apps are installed on the image itself; some of them are installed at
the time of deployment.

Keep in mind what we're talking about is a Base OS image with all applicable Windows Updates. You would typically deploy that Base OS image in order to build a custom image that will be deployed to end-use devices.

You can just as easily leave step 2 as a VM snapshot and not actually capture the image. I simply like having the WIM file in case of <insert scenario here>.

If you are concerned about leaving an end-user device with the Administrator logged on, you can add a logoff or reboot finish action to your rules file. (CustomSettings.ini.) Search the MDT documentation for "Property Definitions" to get a list of
all the thing you can set with the rules file, such as skipping Wizard panes and setting finish actions.

I'm one of those Nick mentions that build the entire thing end-to-end and then capture it. I'm lucky enough to not have any applications that require that level of TLC that I haven't managed to automate the install or configuration for somehow (script,
PoSH, whatever). That said, mine is fully automated and builds images each month as a "nightly" style automated build cycle. You can see some of the details here: http://dcthegeek.blogspot.com/2013/01/automating-image-building-with-mdt.html

Fully patching your base image is a fantastic way to reduce imaging times. I've found that as an additional compromise, including Office in the base image cuts the deployment time substantially. I have essentially have four Windows 7 base images:

Windows 7 x64 - Office 2010

Windows 7 x64 - Office 2013

Windows 7 x86 - Office 2010

Windows 7 x86 - Office 2013

This allows quick deployment time while still allowing flexibility with regards to the additional apps that are deployed.

I do it a very similar way to DCtheGeek except I have a completely separate deployment share which allows me to put all of the customsettings into the [default] section and only requires sections for ~3-4 line sections for each image generating

I'm still not quite getting is Audit Mode...
Previously when I was using imagex to capture and deploy images, Audit Mode was an important step to include in building the reference. Is Audit Mode just not needed or required when using MDT? If it is still useful, when would I want to use it and what is
the best way to configure an image to boot into Audit Mode?

Sorry to be so dense. I'm slowly getting my head wrapped around it though.

I'm still not quite getting is Audit Mode...
Previously when I was using imagex to capture and deploy images, Audit Mode was an important step to include in building the reference. Is Audit Mode just not needed or required when using MDT? If it is still useful, when would I want to use it and what is
the best way to configure an image to boot into Audit Mode?

Sorry to be so dense. I'm slowly getting my head wrapped around it though.

Andy

Andy

I've used MDT on an almost daily basis for the past 4 years and I've never use Audit Mode for any of my images. So, no, it certainly isn't a requirement for MDT. Unfortunately, I can't speak to it any further because, again, never used Audit Mode.

As to audit mode, it is possible in MDT but the real point is to automate as much as possible. Just for some perspective, I generate new images once a month to roll up the new Windows update patches and the process is fully automated from
start to finish.

To give you an idea, my process is now:

1. Start VM

2. Boot to the network and select capture

(This entire process is automated, install apps, updates, scripts etc. We receive an email when the build is completed.)

3. Run a powershell script which imports the OS and creates a Task Sequence based on the fresh image.

4. Update some minor details such as description of what was updated etc.

When I first started we used to do things in a more manual way, manually creating the base image etc. Then moved to MDT but still pausing the build sequence so I could manually install certain apps and make changes.

Once I just knuckled down and spent a bit of time on it, I found I was able to automate everything.

It's literally a 1 minute job now for any of the tech's here to re-create a fresh image.

Instead of audit mode, you really want to add everything into the MDT workbench and let it automate things. If it's an app - silent install it, if its a change - script it. The time spent for us has already paid for itself!

I've used MDT on an almost daily basis for the past 4 years and I've never use Audit Mode for any of my images. So, no, it certainly isn't a requirement for MDT. Unfortunately, I can't speak to it any further
because, again, never used Audit Mode.

-Nick O.

I'm with Nick again... with the way that "Sysprep and Capture" works in WinPE, there's really no need to ever be in audit mode manually that I've ever seen.

Thanks, Nick. I'm going with your advice and am working towards an automated build. My first attempt with many of the installations automated and a few added during a "suspend" seems to be working mostly as expected. The odd issue I've noticed so far is
that after deploying the image I now have 2 Administrator accounts. One is "Administrator" and the second is "Administrator" with the computer name appended ("Administrator.E6230-FS").

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.