Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.

Disable Windows 7 Action Center

If for some reason you don’t want to use Group Policy to disable the Windows 7 Action Center, then there is a registry key you can set to disable it. 




Once the registry key is set to a value of “1”, certain items will be greyed out in the Action Center configuration, and you will no longer see the Action Center icon in the system tray.


There is a simple Group Policy setting for this as well, this is generally my preference, but I had a client who wanted to disable it in the image regardless.

User Configuration – Policies – Admin Templates – Start Menu and TaskBar – Remove the Action Center Icon



Save time (and avoid pain) – Create a MDT test environment

To quote Johan, this is an “oldie but goodie”.

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 Smile 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.


Configuration Manager–Thin Clients and Windows Embedded Discussion

Recently has some internal discussions around these two items.  I wanted to post the information for others to find so they don’t have to “dig” for it as we had to.  The specific questions at hand were:

1) For a thin client, can we push software to a Windows Embedded Standard 2009 system while leaving WPF lock in place?

2) Can we use OSD to deploy the HP Thin State Client (Linux) to a system?

Here are some key points around these topics:


Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007


Read the full post here.

Note: The section titled How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point was updated with two additional steps (19 and 20) on 1/6/2011.


This is a general guide on properly setting up and troubleshooting the System Center Configuration Manager 2007 (ConfigMgr 2007) PXE Service Point. 

Common errors that are seen at the PXE boot screen when the PXE Service Point is either not configured properly or experiencing problems are the following:

PXE-E53: No boot filename received
PXE-T01: File not found
PXE-E3B: TFTP Error – File not Found
PXE-E55 Proxy DHCP Service did not reply to request on port 4011

However the error messages can vary depending on the PXE implementation on the client PC.  Another common symptom is that the Windows Deployment Services Server (WDS) service will not start.

To resolve these issue and to prevent them from occurring in the first place, follow the guide below  This guide is broken down to the following sections:

– Setting Up IP Helpers

– How To Properly Install And Set Up A New Instance Of WDS And A PXE Service Point

– Reinstalling WDS And The PXE Service Point

– Testing The PXE Service Point

– Monitoring And Troubleshooting The PXE Boot

The guide is written in chronological order of the actions that need to be taken properly get a ConfigMgr 2007 PXE Service Point working and operational. Refer to the appropriate sections as needed.


Back to basics #4 – Things You Shouldn’t Do But Are Tempted To

Great post by Daniel Oxely over on The Deployment Guys blog.

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.

Recommendation: The only recommendation really is to do nothing at all.  A good explanation of the "what" and the "why" is available here:

  • 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 ?!!?)

Recommendation:  Don’t remove any of the default tasks.  This page details what they all do:

  • 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.

Recommendation: If you want to change a setting, such as the log retention policy for example, then use this tool rather than going editing the registry directly.  More information here:

  • 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.

Recommendation: Turn the Windows Firewall feature off via Group Policy rather disable the service.  More information:


Configuration Manager–Importance Of Properly Naming Packages With A Descriptive Name

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. 


Troubleshooting Microsoft Deployment Toolkit 2010 Lite Touch

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


Configuration Manager MPCERT and MPLIST Returning HTTP Error 500–Internal Server Error

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:



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

cscript.exe %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

Be sure to add the scripting tools in order for this command to work.  I think it’s a good idea to add both the IIS 7 and the IIS 6 tools for your lab environment.



Microsoft Deployment Toolkit–Controlling The Task Sequence Progress Bar And Individual Step Status

Huge thanks to Keith Garner for answering my questions and showing me this function. Thanks Keith!

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.


I’ve attached my sample scripts to this post.  Also, I’d recommend you read Michael Niehaus’s post on Hiding (and showing) the task seqeunce progress dialog box for further information on the topic.


Copy Content to Target Computers Using $OEM$ Folders

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.

For more information about using:

·         Data WIM files or $OEM$ folders with Windows Vista or Windows Server 2008, see the Windows Automated Installation Kit User’s Guide in the Windows AIK.

·         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 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.