In my post on May 23rd, I described using this process with MDT 2008. Since that post, another Microsoft Consultant (Barry Hartmann of MCS Federal, thanks Barry!) encountered an issue with this process if you have the .NET Framework installed in your Windows XP Professional image. The XP Pro to Tablet PC Edition conversion uses a rather unintelligent, brute force installation process to install .NET Framework 1.0 (which is required by some Tablet PC Edition components). If a newer version of the .NET Framework is installed in your image, this process will downgrade shared files and registry values. This essentially breaks the newer version of the .NET Framework.
Barry encountered this problem when he tried to install Project 2003 on a machine deployed with the "single image" process that had the .NET Framework 3.5 installed in the original XP Pro image. The Project installation fails with the .NET Framework in this state.
The one obvious solution (the one my customer has chosen) is to not include the .NET Framework in the XP Pro image. My customer will be installing .NET Framework 3.5 as an operating system specific post deployment item in the SCCM Task Sequence. The other thing that seems to correct this if the .NET Framework is in the image, according to Barry's testing, is to initiate a repair on the highest version of the core Framework installed (1.1 or 2.0) after the deployment/conversion process.
These blog posts referenced below contain the command lines you should be able to use to repair the .NET Framework 2.0 RTM and 2.0 SP1:
- For 2.0 RTM - http://blogs.msdn.com/astebner/archive/2006/02/07/527219.aspx (the commands there are for uninstall, but if you leave off /u it will do a repair instead)
- For 2.0 SP1 - http://blogs.msdn.com/astebner/archive/2008/02/19/7805444.aspx
Finally, a few fixes were made to one of the scripts from the May 23rd post. Barry discovered incorrect paths were written to files in certain SCCM deployment scenarios. The attachment with that post has been updated with the newer version.
This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.