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

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:



This post was contributed by Daniel Oxley, a Consultant with Microsoft Services Spain 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .