November 2010 - Posts
REALLY great post by Richard Smith over on The Deployment Guys Blog.
Read the full post here and view the videos. I would highly recommend you watch some of these videos as they are excellent, really great content and very easy to follow walk-through’s.
Thanks you all for your patience waiting for the full set of deployment walkthrough videos to be posted on TechNet Edge. As per my previous post, over the past few months I have been updating the deployment walkthrough videos and I am pleased to announce that the whole video series has now been posted. In all there are seven videos (around 10 hours of content) - you can see the full list of videos here or you can link to the individual videos below:
DEPLOYMENT PLANNING:
OFFICE DEPLOYMENT: IMAGE ENGINEERING AND SERVICING: IMAGE DEPLOYMENT: Remember that you can download the video file (instead of streaming it) directly from the TechNet Edge web page for each video – look for the “Downloads” section at the bottom of the page to download the .WMV/MP4/PSP file
Great post over on The Deployment Guys by Richard Smith.
Read the full post and download the scripts here.
A request that I have had from a number of customers lately goes like this:
“we would like to have MDT 2010 download and apply all critical and security updates during image engineering from the Internet, but the device we are using as a reference machine is in the lab network which doesn't get Group Policy applied and which therefore doesn't get the proxy server settings required to connect to the Internet” I covered this scenario in a previous post where I discussed using the inbuilt MDT 2010 tasks for applying Windows Updates and how this can streamline the image engineering process.
To enable the reference device to connect to the Internet during Image Engineering, I have a pair of scripts that are added to the task sequence which configure the proxy settings (first script) and then remove the proxy settings (second script) prior to image capture.
The script examples attached to this post should be extracted from the zip file and dropped into the scripts folder in your MDT 2010 Deployment Share
You should then add a Run Command task around where the Tatoo task is in the State Restore phase of your task sequence to execute the first script as cscript CFG-ProxySetting.wsf /Proxy:<Proxyname.company.com or IP Address>:<Port> /Exceptions:local – replacing the command line options with your own proxy server details
for example - cscript CFG-ProxySetting.wsf /Proxy:PROXYSRV01.CONTOSO.COM:8080 /Exceptions:local (you must use both the /Proxy: and /Exceptions: command line options)

To remove the setting place a Run Command just before the Prepare to Capture Image group to execute cscript CFG-ClearProxySetting.wsf

You could combine these two scripts into a single script with a little re-writing to use command line arguments to add the proxy (/AddProxy) and clear the proxy (/ClearProxy) if you wanted to be efficient in your custom script use.
Great post over on The Deployment Guys blog by Daniel Oxley.
Read the full post and download here.
When working on a client site, the laboratory where I have the MDT server(s) set up along with the test machines is not always in the same place as where I am. This could be for a variety of reasons, but usually it is that the lab area is either too cold to stay in (aggressive AC being used!) or just too cramped to spend a lot of time in. This can be a bit of a pain where running successive MDT deployment tests as it requires lots of back-and-forth between my location and the lab area; I can usually use RDP to control the MDT server, but not for the computers being deployed because they are usually either in a WinPE phase, or don't yet have RDP enabled on them.
Because necessity is the mother of invention, I wrote a simple HTA program that I use to keep an eye on the progress of computers being deployed. This solves the problem of going to the laboratory to check on a computer, only to find that it is still being deployed! Basically, the HTA works by keeping an eye on an "eventshare" configured from within MDT and reports the progress back to the HTA window. Whilst this could never be a replacement for a proper monitoring system such as Systems Centre Operations Manager (SCOM) due to scalability and features, it works great for me when working in laboratory conditions; as such, I thought I'd share it here!

The HTA makes use of the little used EventShare property of MDT which allows you to specify a UNC path for the storage of task sequence events. This property is typically used when implementing the Microsoft Deployment Toolkit Management Pack for SCOM 2007, but you can use it for other purposes when SCOM isn't available :-) - see the MDT documentation if you want to find out more about this property.
I was recently troubleshooting an issue at a client where we had about 2,000 error messages for the Distribution Manager about a package that it couldn’t process.

According to this error message I was looking for a package named “.NET Framework”. I dug through every package we had, but couldn’t find one called that exactly, all I could find for anything .NET related were the following packages.

What’s important to note is that the display name you see in the console is actually derived of 3 components. The Name, Version, and Manufacturer. What you see in the status messages is only the Name. Hmm, not the greatest and something that does not lead to quick and easy troubleshooting.

I typically don’t ever recommend using the Version field, I always make sure the Name is fully descriptive of the package. This also ensures what you see the the status messages helps you easily and quickly identify the package, so you don’t have to dig through several hundred or thousand packages trying to figure out which one is causing the issue.

Unfortunately, you can’t use the version in both the Name and Version field or you will end up with a funky looking Display name like this:

So, the thing to remember is that it’s important to using a standard naming convention for all your packages, and that you use a fully descriptive Name for each package, remember this is all you will see in the status messages, besides the package ID, which you can’t really search for easily in the console when your packages are under numerous folders.
Great post by Nick Moseley for troubleshooting bad MIF’s.
Read the full post here and download the script here.
“Today I was troubleshooting some client communication problems and found that one of the causes was that they were generating bad MIFs, so SCCM was rejecting the hardware inventory they were sending. Along the way, I also found that there 230 bad MIFs on my site server. Instead of manually opening each file to ‘document’ which system it was, I decided to script it. I must give credit to a blog posting by Don Hite, which gave me the original idea to do this in the first place.”
If you haven’t seen it, a new version of Client Center has been released:
http://myitforum.com/cs2/blogs/rzander/archive/2010/11/23/sccm-client-center-v2-0-3-released.aspx
I'm proud to announce Version 2.0.3 of SCCM Client Center :http://sourceforge.net/projects/smsclictr/
Changes:
- Patch Mgmt can also show only approved updates
- Edit Hardware Inventory Classes
- Show Services without WMI
- x64 improvements and fixes
- Logging improved
- Some other minor updates :-)
Readme.txt contains some additional informations arround the license types of the different components...
The below guide will cover configuring Task Sequence’s for allowing USMT data to be stored to and from a UNC path. This will utilize a folder named after the computer (utilizing the %OSDCOMPUTERNAME% variable) in the specified server share path, and by simply renaming the folder you can control if the data is restored to another machine. This behavior is very similar to how USMT functioned previously to ConfigMgr and the use of the SMP (State Migration Point), and something I’ve found a lot of people wish was still present. This will also cover modifying your “Refresh” Task Sequence to allow for the data to be stored to the UNC path and then restored to the computer after the refresh has been completed. The first 2 Task Sequences covered with be used for manually capturing and restoring USMT data onto machines, from Run Advertised Programs, or through a mandatory advertisement. These could be used to do a bulk capture and/or restore. If you are using MDT integrated Task Sequences, then the standard client TS template covers both the new computer/bare metal and refresh scenarios. If you are using a TS based upon the client template, then if you do a new computer/bare metal deployment, as long as there is a matching folder in the UNC path, USMT data will be restored to the bare metal machine without having to create an association prior to imaging that new computer.
This guide currently only covers USMT 3, several community members have reported success with USMT4, however I haven’t had time to test this configuration with USMT 4 yet.
You can download the Task Sequence templates here.
Packages needed:
USMT3 x86 or x64
MDT Scripts (Toolkit files)
Settings package (contains customsettings.ini)
![clip_image002[7]](http://myitforum.com/cs2/blogs/cnackers/clip_image0027_thumb_6B1DAEE6.jpg)
Overall view of the Task Sequence steps:
![clip_image004[4] clip_image004[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0044_thumb_2A2F7B1C.jpg)
Point the first step to your MDT scripts package:
![clip_image006[4] clip_image006[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0064_thumb_287EAF48.jpg)
Point the Gather step to your Settings package:
![clip_image008[4] clip_image008[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0084_thumb_74D642E9.jpg)
Next, we need a run command line step to create our folder:
![clip_image010[4] clip_image010[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0104_thumb_6553311A.jpg)
Next we need to set the Task Sequence variable to the path we want:
![clip_image012[4] clip_image012[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0124_thumb_03BD7204.jpg)
Select your USMT Package:
![clip_image014[4] clip_image014[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0144_thumb_501505A5.jpg)
Configure your capture options as needed:
![clip_image016[4] clip_image016[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0164_thumb_3972B75E.jpg)
Configure your additional options as needed:
![clip_image018[4] clip_image018[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0184_thumb_37C1EB8A.jpg)
Packages needed:
USMT3 x86 or x64
MDT Scripts (Toolkit files)
Settings package (contains customsettings.ini)
![clip_image002[7] clip_image002[7]](http://myitforum.com/cs2/blogs/cnackers/clip_image0027_thumb_6B1DAEE6.jpg)
Overall Task Sequence steps:
![clip_image020[4] clip_image020[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0204_thumb_74966D5C.jpg)
Set the first step to your MDT scripts package:
![clip_image022[4] clip_image022[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0224_thumb_6EDB53B6.jpg)
Point the Gather step to your Settings package:
![clip_image024[4] clip_image024[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0244_thumb_3F3D352A.jpg)
Configure the Task Sequence variable to the path you want:
![clip_image026[4] clip_image026[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0264_thumb_5DA77613.jpg)
Configure your USMT package:
![clip_image028[4] clip_image028[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0284_thumb_74F27A84.jpg)
Configure your Restore options as needed:
![clip_image030[4] clip_image030[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0304_thumb_0113F4AC.jpg)
Configure your additional Restore options as needed:
![clip_image032[4] clip_image032[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0324_thumb_5F481C1A.jpg)
Delete or disable the following steps, as they will no longer be needed:
![clip_image036[4] clip_image036[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0364_thumb_2529296E.jpg)
Be sure to catch the “Move State Store” step in the “Gather Logs and StateStore on Failure”:
![clip_image038[4] clip_image038[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0384_thumb_119BC9CD.jpg)
Add the following steps to the Stare Capture phase:
![clip_image040[4] clip_image040[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0404_thumb_76EF2DB3.jpg)
![clip_image042[4] clip_image042[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0424_thumb_0DCDFF30.jpg)
Add the following step to the State Restore phase:
![clip_image044[4] clip_image044[4]](http://myitforum.com/cs2/blogs/cnackers/clip_image0444_thumb_529A2364.jpg)
You will now be able to refresh an existing machine and USMT will be captured to the UNC path you’ve specified. If you use this Task Sequence for a new computer/bare metal build, it will restore USMT data if there is a matching folder in the server share.
Here’s a nifty property that I don’t’ think is very well known.
You can specify “FinishAction” in your customsettings.ini to tell the computer what to do after the deployment is completed. This property can also be defined in the database.
The available options are SHUTDOWN, REBOOT, RESTART, LOGOFF, and “BLANK”.
The default action is “BLANK”, which just exits the wizard without doing anything.
This property only applies to Lite Touch and does not apply to ZTI with Configuration Manager.
Join Andreas Hammarskjold and Johan Arwidmark, two of the world’s foremost deployment experts in a dazzling session that gives you the tools and processes to use when troubleshooting OS Deployments using Microsoft Deployment Toolkit (MDT) 2010 Lite Touch. Learn about common issues and their workarounds, parsing log files, driver handling, WinPE, PXE Troubleshooting, Unknown Computers, and much more. We share our notes from the field, and our tips and tricks for making OS Deployment using MDT 2010 Lite Touch even better.
Watch the video here.
Speaker(s): Johan Arwidmark
Event: Tech·Ed North America
Year: 2010
Track: Windows Client
Want a sneak peek at the future of deployment? Live Demo: Microsoft Deployment Toolkit 2010 is used to deploy Windows 7 Client and Windows Sever 2008. Get ahead of the curve and be prepared to answer your customer's questions BEFORE they ask. Walk through installation, image creation, and deployment scenarios of the future.
Watch the video here.
Speaker(s): Michael Niehaus, Tim Mintner
Event: Tech·Ed North America
Year: 2009
Track: Windows Client
Join Johan Arwidmark and Mikael Nystrom in a dazzling session on using the right tools for deploying Windows. They will navigate you through the current deployment tools that Microsoft provides and help you decide which solution is right for you. They will guide you on when to tweak, and when to stop tweaking and choose a different path. Tools and solutions like Windows AIK, WDS and MDT 2010 are covered in this session. You can expect a lot of live demos, tips and tricks.
Watch the video here.
Speaker(s): Mikael Nystrom, Johan Arwidmark
Event: Tech·Ed Europe
Year: 2010
Track: Windows Client
One of the biggest challenges when doing windows deployment is dealing with device drivers. Join Michael Niehaus and Johan Arwidmark as they share their notes from the field on handling device drivers in the deployment process, using the MDT 2010 and ConfigMgr 2007 SP2 platform as a foundation. You can expect a lot of live demos, tips and tricks in this session.
Watch the video here.
Speaker(s): Mike Niehaus, Johan Arwidmark
Event: Tech·Ed Europe
Year: 2010
Track: Windows Client
Watch this discussion with Microsoft and external IT Professional influencers as they discuss Windows operating system deployment. So you want to deploy Windows, but where do you start? What tools should you use? Learn everything you need to know about Windows deployment from the experts.
Watch the video here.
Speaker(s): Michael Niehaus, Rhonda Layfield, Stephen Rose, Mikael Nystrom,Tim Mintner, Jeremy Chapman, Johan Arwidmark
Event: Tech·Ed North America
Year: 2009
Track: Windows Client
Here is a list of the User State Migration Tool (USMT) variables I’ve put together for use with Configuration Manager (ConfigMgr). I complied information from the TechNet documentation.
Operating System Deployment Task Sequence Variables
| Variable | Capture | Restore | Description |
| OSDMigrateAdditionalCaptureOptions | x | | Specifies additional user state migration tool (USMT) command line options that are not exposed in the Configuration Manager 2007 user interface and will be used when capturing the user state. The additional options are specified in the form of a string that is appended to the automatically generated USMT command line. |
| OSDMigrateAdditionalRestoreOptions | | x | Specifies additional user state migration tool (USMT) command line options that will be used when restoring the user state. The additional options are specified in the form of a string that is appended to the automatically generated USMT command line. |
| OSDMigrateConfigFiles | x | | Specifies the configuration files used to control the capture of user profiles. This variable is used only if OSDMigrateMode is set to “Advanced”. This comma-delimited list value should be set in order to perform customized user profile migration. Example: miguser.xml,migsys.xml,migapps.xml |
| OSDMigrateContinueOnLockedFiles | x | | Allows the user state capture to proceed if some files cannot be captured. Valid values: "true" (default) "false" |
| OSDMigrateContinueOnRestore | | x | Specifies that the user state restoration should continue even if some files cannot be restored. Valid values: "true" (default) "false" |
| OSDMigrateEnableVerboseLogging | x | | Enables verbose logging for the USMT. Valid values: "true" "false" (default) |
| OSDMigrateLocalAccountPassword | | x | If “OSDMigrateLocalAccounts” is “true,” this variable must contain the password to be assigned to all local accounts that are migrated. Because the same password is assigned to all migrated local accounts, it should be considered a temporary password that will be changed later by some method other than Configuration Manager 2007 operating system deployment. |
| OSDMigrateLocalAccounts | | x | Specifies whether the local computer account should be restored. Valid values: "true" "false" (default) |
| OSDMigrateMode | x | | Allows you to customize the files that are captured by USMT. If this variable is set to “Simple,” then only the standard USMT configuration files are used. If this variable is set to “Advanced,” then the task sequence variable OSDMigrateConfigFiles specifies the configuration files that the USMT should use. Valid values: "Simple" "Advanced" |
| OSDMigrateSkipEncryptedFiles | x | | Specifies whether encrypted files should be captured. Valid values: "true" "false" (default) |
| OSDMigrateUsmtPackageID | x | | Specifies the package ID of the Configuration Manager 2007 package that will contain the USMT files. This variable is required. |
| OSDMigrateUsmtRestorePackageID | | x | Specifies the package ID of the Configuration Manager 2007 package that contains the USMT files. This variable is required. |
| OSDStateFallbackToNAA | | | Specifies whether the task sequence step should use the Network Access Account as a fallback when the computer account fails to connect to the state migration point. Valid values: "true" "false" (default) |
| OSDStateSMPRetryCount | | | Specifies the number of times that the task sequence step should try to find a state migration point before failing. |
| OSDStateSMPRetryTime | | | Specifies the number of seconds that the task sequence step should wait between retry attempts. The number of seconds can be a maximum of 30 characters. |
| OSDStateStorePath | x | x | The UNC or local path name of the folder to which the user state should be saved. No default. |
More Posts
Next page »