I’ve got an older post here that talks about the same principal, but always a good thing to read and practice.

Read Johan’s post over on his new blog here. Same principal applies and the same files/commands The idea is to be able to quickly test your customsettings.ini without having to run a full deployment, this allows you to figure out the behavior and test database queries without running the full process.

Customers will also need to use XPe’s Target Designer to build their XPe image with all necessary pre-requisites to install and run ConfigMgr client. The following download contains the XPe macro component for ConfigMgr client. If the customer is not authorized by their hardware vendor to build their own images, they will need to request this be done by their hardware vendor.

It’s been a while, but I’ll now continue this series of basic tips in the hope to help avoid some deployment unpleasantness that you might rub shoulders with at some point! In this post I’ll explain 5 common errors that people make when configuring their newly deployed Windows 7, and what you should really be doing instead… if there is an "instead".

Windows 7 x64 and Office 2010 x64 – This is a great combination, all that 64 bit goodness on your computer will make all your friends and family drool with envy… (not). Trouble is, if you roll out the 64 bit version of Office 2010 and then at a later date try to use add-ins that are only available in 32 bit, then you might come a bit unstuck and have egg on your face. Why? Because all of your Office add-ins will also need to be 64 bit. As such, it is vital that you plan carefully any Office 2010 x64 roll out to ensure compatibility and all round happiness.

Recommendation: If there is nothing stopping you using Office 2010 x64, then go for it but test it carefully. Otherwise, the best combination at the moment is Windows 7 x64 and Office 2010 x86.

C:\Windows\WinSxS – A lot of people are rather dumbstruck by the size of their customised WIM image that they freshly created with MDT. For "no apparent reason", what was a fairly low-calorie Windows + Apps installation has out-of-the-blue created a 6Gb captured WIM file. Upon investigation, it is deemed that the C:\Windows\WinSxS has somehow become bloated and then begins a manual process of cleaning out the "junk". Well, if you do this then you will most definitely break something…! The WinSxS folder is the component store for Windows and where an attempt to avert "DLL Hell" is made through the use of Side-by-side assemblies. Unfortunately, this folder will very likely grow larger over time, so you should also take into account its growth when planning your partition sizes.

Cleaning Up the Default Scheduled Tasks – Since Windows Vista, Windows has come with a lot of default scheduled tasks that might, at first glance, appear to be surplus to your requirements. Do you really need those "Windows SideShow" tasks even though you don’t use the feature? The answer is YES. Although you might have decided that you really don’t need them, if you remove them you’ll be entering into unknown territory that could possible cause a conflict with something that appears to be unrelated. Given the sheer number of different combinations of scheduled tasks possible, Microsoft can’t test every single permutation. As such, the only configuration that is completely and thoroughly tested by Microsoft is the one you get once Windows has finished installing. Feel free to remove the ones you want, but you may find that you are on your own when your computer disappears into a whirling pit of death, pain and destruction (not too over-dramatic is it ?!!?)

Configuring Windows Events via the Registry – It is easy, and plenty of people do it, to change the configuration of event logging in Windows via the registry, but it is not the best way at all. There exists a little known tool that will do this for you, WEVTUTIL.exe, which you should use instead.

Disabling the Windows Firewall – Personal firewalls have become quite common now, even in the enterprise. Windows has had once since XP and also a lot of common 3rd-party security products also provide them. However, a very common configuration mistake that I see in a lot of projects is that if a 3rd-party firewall product is being used then the Windows Firewall service should be disabled via Group Policy. Don’t do that though because it is an unsupported method and also, more importantly, if the firewall service is stopped or disabled then the IPsec configuration portion of Windows 7 will also stop. Disabling the Windows Firewall also disables certain features of Windows Service Hardening which is most certainly not a good thing.

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.

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.

I recently had an issue with my hyper-v lab where my MP quit working. It’s a test lab so I’m making changes all the time. So no big surprise there. However, uninstalling the MP and even uninstalling/installing IIS didn’t resolve the issue. I kept getting a failed attempt when running the MP Troubleshooter and when trying to browse to the web page to verify the MP. Again, thanks to a colleague for pointing me in the right direction.

You can use these links to test your MP:

http://servername/SMS_MP/.SMS_AUT?MPCERT

http://servername/SMS_MP/.SMS_AUT?MPLIST

What ended up resolving the issue was running the following command and then restarting IIS.

I was recently working with a client that had some custom scripts they wanted to use to run some processes. What they wanted was to be able to update the Task Sequence progress bar with the progress of those scripts or actions, instead of a single “custom action” being displayed with no progress. It turns out that by using the oLogging.ReportProgress you can control the progress bar and what is presented by using oLogging.CreateEntry to control the display name.

Normally the Task Sequence progress bar only shows the main action.

There is actually built-in logic to allow you to display the progress of individual tasks. The below is an example of displaying “Installing Adobe Reader” with a 5% progress bar. I used oLogging.CreateEntry to display “Installing Adobe Reader” and then oLogging.ReportProgress to show a 5% progress bar.

Using oLogging.ReportProgress I can tell it to display a 75% progress bar as well.

This can be used to show the progress of your custom scripts or actions, along with showing what is happening in that custom script using the logging functions. The script you want to run to show this progress needs to be a .wsf that uses ZTIUtility.

Here is a sample TS to run our custom script. I have 2 pause steps before and after just run something else along with our custom action. This is a good practice when testing so you can see that something before and after ran successfully.

If we run this TS on our machine, we’ll see the progress bar show up and it will through updating the progress and then continue to execute the TS.

Another example allows us to control when the progress is updated. This script waits for updates to some registry keys before it updates the progress.

When we run this Task Sequence on a client, it’ll sit at this screen until we provide it with values.

If we update the registry values, then we can control the display.

The Task Sequence progress is automatically updated as it read the values in the registry we are monitoring. So in this example you could pipe some values out to these values from your custom script (called by the .wsf) and therefore update the TS progress. When your custom script is done, you can just pipe “Done” to the registry and it will end the TS step and proceed to the next step.

MDT 2010 supports using legacy $OEM$ folders to organize and copy supplemental files to the target computers. However, when deploying Windows Vista or later operating systems, data WIM files are preferred over $OEM$ folders.

Note In an instance where multiple $OEM$ folders have been defined, the first driver that LTIApply.wsf finds is deployed to the target computer.

· An $OEM$ folder with Windows XP or Windows Server 2003, see the Microsoft Windows Corporate Deployment Tools User’s Guide (Deploy.chm) and the Microsoft Windows Preinstallation Reference (Ref.chm), both of which are in the Deploy.cab file in the Support\Tools folder on the Windows installation media.

MDT 2010 looks in the following locations within the deployment share, in the order specified, to find an $OEM$ folder:

· Control\task_sequence (where task_sequence is the name or ID of the task sequence that MDT 2010 is installing). Create $OEM$ folders in this location to create a custom folder for each build.

· Operating Systems\Name (where Name is the name of the operating system MDT 2010 is installing). Create $OEM$ folders in this location to create a custom folder for each operating system.

· Platform (where Platform is either x86 or x64). Create $OEM$ folders in this location to create a custom folder for each platform.

· $OEM$, which is at the root of the deployment share and is the default $OEM$ folder if a folder is not found in the previous locations.

An $OEM$ folder contains supplemental files. The following list describes each folder that you can create within an $OEM$ folder to organize these files:

· $$. Windows Setup copies the contents of this folder to %SystemRoot% on each destination computer. It replicates all the folders, subfolders, and files that this folder contains in the %SystemRoot% folder of each destination computer. For Windows Setup to copy a file to %SystemRoot%\System32 on each destination computer, for example, put the file in $OEM$\$$\System32.

· $1. Windows Setup copies the contents of this folder to %SystemDrive% on each destination computer. It replicates all the folders, subfolders, and files that this folder contains in the %SystemDrive% folder on each destination computer. This is typically drive C on most computers.

· Drive. Drive is a drive letter (C, D, E, and so on). Windows Setup copies the contents of this folder to the root of the corresponding drive on each destination computer. It replicates all the folders, subfolders, and files that this folder contains in the corresponding drive during the setup process. For example, Windows Setup copies any files put in $OEM$\D to the root of drive D on each destination computer.

Microsoft recommends that these folders not be used. The folders rely on a very specific disk configuration on the destination computer. Use $1 to represent %SystemDrive%, instead. In most installations, $OEM$\$1 and $OEM$\C write to the same location: the root of drive C.

· TEXTMODE. For Windows XP and Windows Server 2003, this folder contains hardware-specific files that Windows Setup and text-mode setup install on the destination computer during the text-mode phase of the installation process. These files may include OEM HALs, mass-storage device drivers, and the Txtsetup.oem file. The Txtsetup.oem file describes how to load and install these files. List these files in the [OemBootFiles] section of the answer file.