The Deployment Guys

Helping to deploy your world automagically...

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

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

  • Comments 5
  • Likes

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: http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx

 

  • 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: http://support.microsoft.com/kb/939039

 

  • 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: http://technet.microsoft.com/en-us/library/cc721981.aspx

 

  • 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: http://technet.microsoft.com/en-us/library/cc766337(WS.10).aspx

 

  

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.

  • That's a great list Daniel - any chance of a similar small list stating "The things you really should do"...?

    Not using a domain admin account as your build account for example...stuff like that?

    Thanks

  • Good idea, I'll make that the next one!

  • Office 2010 introduces native 64-bit versions of Office products to support 64-bit processors. Office 2010 also provides support for 32-bit Office 2010 applications that run on 64-bit Windows operating systems by using Windows-32-on-Windows-64 (WOW64). However, the version of Office 2010 to install should not be simply dependent on the Operating System architecture of a master image.

    Microsoft makes direct recommendations on TechNet <link> for which version of Office 2010 to install (as well as specific advantages and disadvantages):

        •   If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on previous versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2010 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems.

        •   If some users in your organization are Excel expert users who work with Excel spreadsheets that are larger than 2 gigabytes (GB), they can install the 64-bit edition of Office 2010. In addition, if you have in-house solution developers, we recommend that those developers have access to the 64-bit edition of Office 2010 so that they can test and update your in-house solutions on the 64-bit edition of Office 2010.

    Additional guidance is also given on MSDN <link>:

        When should I use the 64-bit version of Microsoft Office?

        This is more a matter of which host application (Excel, Word, and so forth) you are using. For example, Excel is able to handle much larger worksheets with the 64-bit version of Microsoft Office.

    Generally, it is recommended to install Office 2010 32-bit as part of a master image for performance advantages, unless there is a requirement for users to work with large files larger than 2GB.

  • Office 2010 introduces native 64-bit versions of Office products to support 64-bit processors. Office 2010 also provides support for 32-bit Office 2010 applications that run on 64-bit Windows operating systems by using Windows-32-on-Windows-64 (WOW64). However, the version of Office 2010 to install should not be simply dependent on the Operating System architecture of a master image.

    Microsoft makes direct recommendations on TechNet <technet.microsoft.com/.../ee681792.aspx> for which version of Office 2010 to install (as well as specific advantages and disadvantages):

        •   If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on previous versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2010 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems.

        •   If some users in your organization are Excel expert users who work with Excel spreadsheets that are larger than 2 gigabytes (GB), they can install the 64-bit edition of Office 2010. In addition, if you have in-house solution developers, we recommend that those developers have access to the 64-bit edition of Office 2010 so that they can test and update your in-house solutions on the 64-bit edition of Office 2010.

    Additional guidance is also given on MSDN <msdn.microsoft.com/.../ee691831(office.14).aspx>:

        When should I use the 64-bit version of Microsoft Office?

        This is more a matter of which host application (Excel, Word, and so forth) you are using. For example, Excel is able to handle much larger worksheets with the 64-bit version of Microsoft Office.

    Generally, it is recommended to install Office 2010 32-bit as part of a master image for performance advantages, unless there is a requirement for users to work with large files larger than 2GB.

    And ugh, dangling prepositions.

  • Yeah, saw this once, they jumped the gun and went to 64 bit office too early, it was a real nightmare having to maintain two different installs of Office, and two separate images, not fun. Avoid x64 Office if you can, besides if somebody really has a 4+ gig excel file I assume they're doing something wrong.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment