Hey all, some folks on the XP Embedded team have recorded some video demonstrations of various features of XP Embedded, including walkthroughs of some of the new XPE SP2 features.  Click here to check them out today!  I did the Device Update Agent (DUA) video, so please forgive me for being a little nervous.  I also had a really bad cold the day I recorded it and had to stop for some coughing fits, but the folks in the MSDN recording studio did a great job of editing it out  :-)  Here's a complete list of the videos that are available (not all of them are new):

• Accelerated Operating System Configuration
• Automated Dependency Checking and Build Process
• Building a Windows XP Embedded Device
• Device Update Agent for Windows XP Embedded
• Windows Embedded Application Development
• Windows XP Embedded - Basic Lab
• Windows XP Embedded Product Overview
• Windows XP Embedded with Service Pack 2 - Basic
• Windows XP Embedded with Service Pack 2 Technical Training: Embedded Enabling Features
• Windows XP Embedded with SP2 Security Feature Enhancements
• Assisted Component Authoring
• Automated Device Analysis
• Systems Management Server (SMS) and Windows XP Embedded
• Windows XP Embedded - Advanced

Hey all, I have had a couple folks ask me if it is possible to create a package that will install the .NET Framework 1.1 and SP1 at the same time (or 1.0 and SP3 at the same time).  Here are a set of steps you can follow to use Windows Installer command line parameters to create an installable layout that includes the .NET Framework and a service pack:

1. Download the .NET Framework 1.0 or the .NET Framework 1.1
2. Extract the contents of the .NET Framework to a folder - you can do this by running dotnetfx.exe /t:c:\temp /c (where c:\temp is any folder of your choosing)
3. Download the .NET Framework 1.0 SP3 or the .NET Framework 1.1 SP1
4. Extract the service pack MSP package to a folder by running <name_of_SP_EXE>.exe /Xp:c:\temp\ndpsp.msp
5. Run msiexec.exe /a c:\temp\netfx.msi TARGETDIR=c:\temp\new_netfx
6. Run msiexec.exe /a c:\temp\new_netfx\netfx.msi /p c:\temp\ndpsp.msp

Following these steps will create an MSI and a set of files in the folder c:\temp that can be used to install the .NET Framework and a service pack.  Now you can share out the folder or install directly from there in order to install the .NET Framework and the service pack at the same time.

XP Embedded SP1 includes components for the .NET Framework 1.0 with SP2 and ASP.NET 1.0 with SP2.  Currently there is not an XP Embedded component for the .NET Framework 1.0 with SP3.  The following instructions will allow you to unofficially update your 1.0 SP2 component to 1.0 SP3.  Note that these are manual steps and are not officially supported.

Identify setup differences in 1.0 SP3

The first step is to figure out what is different between 1.0 SP2 and 1.0 SP3.  The XP Embedded components for .NET Framework 1.0 use the same OCM package that originally shipped as part of Windows XP Tablet PC and Media Center editions.  The delivery mechanism for Tablet PC and Media Center to get 1.0 SP3 is to install the overall Windows XP SP2.  As a result, you can go to any machine that has the desktop XP Pro with SP2 and find the .NET Framework 1.0 OCM INF file in the folder %windir%\inf (even if the machine is not Tablet PC or Media Center).  Now we can take this netfxocm.inf and compare it to the one in our XP Embedded SP1 database repository in the folder \Windows Embedded Data\repositories\{022716D8-0CF0-4779-B94C-8E52EB36709C} using your favorite diff utility.  Doing this shows us the differences in setup for 1.0 SP2 and SP3.  You will see a few updated registry keys that track what service pack level is installed, and also 5 new files that are delivered by 1.0 SP3:

• smartnav.htm
• uninstallpersistsqlstate.sql
• uninstallsqlstatetemplate.sql
• installpersistsqlstate.sql
• installsqlstatetemplate.sql

Apply any necessary registry changes

Now, let's take a look at the composition of the .NET Framework 1.0 SP2 components in the XP Embedded SP1 database.  There is a huge list of files that make up the .NET Framework, no registry keys, and an OC Manager Request resource.  The OC Manager Request calls into the netfxocm.inf in order to write all of the .NET Framework registry keys and run custom actions during first boot agent (FBA), such as installing files to the global assembly cache (GAC).  That means that if we update netfxocm.inf in our pre-FBA image, we will get all of the registry changes applied to our system "for free".

Apply any necessary file changes

That leaves us with one remaining step - how to get the new and updated 1.0 SP3 files that we need to get into our image.  There are a couple of different ways to do this.  The easiest would be to install .NET Framework 1.0 on a desktop XP machine and then apply SP3 to it.  Then you can use netfxocm.inf to retrieve a list of files in the .NET Framework 1.0 SP3, or look in the file lists in the XP Embedded components for .NET Framework 1.0 SP2 and ASP.NET 1.0 SP2.  Now, find all of those files on the desktop machine where you installed 1.0 SP3 and copy them into the repository folder at \Windows Embedded Data\repositories\{022716D8-0CF0-4779-B94C-8E52EB36709C} on the machine you have the XP Embedded database installed on.

Summary

Here is a high level set of steps you will need to perform based on the detailed explanations listed above:

1. Add the 5 new files listed above to the .NET Framework component (or simply add them as additional file resources in your configuration in Target Designer) by copying them from the folder %windir%\Microsoft.NET\Framework\v1.0.3705 on a desktop computer that has .NET Framework 1.0 and .NET Framework 1.0 SP3 installed.
2. Replace netfxocm.inf in \Windows Embedded Data\repositories\{022716D8-0CF0-4779-B94C-8E52EB36709C} with a copy from %windir%\inf on a machine running the desktop version of Windows XP with Windows XP SP2
3. Update the .NET Framework files that were changed for 1.0 SP3 in your database repository folder
4. Rebuild your embedded image in Target Designer and redeploy

I hope you find this useful.  Please let me know if you have any questions about any of the above

Hey all, there is now a web page available that provides direct links to the pieces of the Windows XP Embedded evaluation kit web download.  You can get to it by clicking on this link.  I would still recommend using the web download tool if possible because it provides for background downloading and will extract the files into an installable setup layout after it is done downloading.  But I know there are some scenarios where the downloader will not work correctly (certain proxy settings, domain policy that restricts the use of BITS, etc), and hopefully this will help fill that gap and unblock anyone currently having trouble downloading XPE SP1, XPE SP2 and/or XPE MUI packs.

Hey all, the Windows XP Embedded web download tool (xpeffi.exe) has been refreshed and it will now allow you to download all 23 language versions of the XPE MUI language packs (previously only 6 languages were available).  You can get the updated xpeffi.exe at the same download location - http://go.microsoft.com/fwlink/?linkid=38214

Hey all, if you are having issues downloading Windows XP Embedded SP2 using the web download tool released this week, you may need to update your proxy server configuration.  The download tool uses the BITS service to manage the transfer of files (the same service used by Windows Update and Auto Update, etc).  The BITS docs state that it will use Internet Explorer proxy settings by default.  So in some cases you may need to do the following to update proxy settings so the downloader will work correctly.  You can access Internet Explorer proxy settings by doing the following:

• Launch Internet Explorer
• Go to the Tools menu and choose Internet Options... (the last item in the menu)
• From Internet Options, choose the Connections tab and then click the LAN Settings... button at the bottom right of the Connections tab pane

It may be possible to temporarily disable the proxy server to unblock the downloader from functioning properly.  It might also help to turn on automatic settings detection.  If these suggestions do not work, please double-check to see if Windows Update will correctly download files.

I hope these suggestions help, and in the meantime I am also investigating other possible causes and solutions.

I just received word that the version of the Windows XP Embedded SP2 web download tool (xpeffi.exe) specifically for licensed embedded OEMs is now available on the OEM secure site.  I apologize for the delays encountered in getting this posted.  If you are a Windows XP Embedded OEM, click here to sign into the OEM secure website and access the download tool.

Hey all, last night the final build of XP Embedded SP2 was posted for download.  I received a comment in response to my blog post regarding problems using the web download tool on a network behind a firewall and with a proxy server.  I have tried to reproduce the issue internally behind the Microsoft firewall and haven't had any luck yet.  I asked some of my colleagues who are working on the web download tool for the Visual Studio 2005 express editions for advice and as a result have added some code specifically designed to fix proxy server authentication issues that are sometimes seen when using BITS.  However, since I haven't been able to reproduce the problem, I cannot verify whether or not this code I added fixes the problem or not.  So, I have a small request for you - if you have tried to use the XP Embedded web download tool (xpeffi.exe) and have had any download errors related to proxy servers or firewalls, could you please contact me via a comment in my blog or by emailing me directly at aaronste (at) microsoft (dot) com?  I will provide you with a private build of the download tool to see if my code change will fix this issue or not.  If it does work, we can refresh the web download tool when the remaining XPE SP2 MUI language packs are ready to release in the near future.  Thank you in advance!

I wanted to take a minute to spotlight one of the big new embedded enabling features that is new to Windows XP Embedded SP2.  It is called hibernate once, resume many.  We have taken to abbreviating this to HORM internally, so if you see this new acronym floating around in documents or newsgroups about XP Embedded that is likely what it means.

HORM provides the ability to resume an EWF-protected system from a hibernation file (hiberfil.sys) each time a machine is restarted instead of performing a full OS boot.  This greatly improves the cold-boot startup time of machines.  Here are a few key points about HORM:

• You must protect all partitions on your volume with EWF in order for HORM to work correctly
• You must use EWF RAM or RAM Reg overlay types in conjunction with HORM
• Ordinarily, NTLDR will check the header/signature of hiberfil.sys when the system begins the boot process in order to protect against a stale orphaned hiberfil.sys being booted.  If a stale hiberfil.sys is detected, NTLDR will show a menu asking if you want to continue to resume or discard the hiberfil.sys and perform a full boot.  You can create a file named resmany.dat (any size, any format) on the root of the boot partition (typically c:) to suppress this check and allow your device to resume without any user interaction.
• You must make sure to use the EWF NTLDR with HORM.  EWF NTLDR is the only boot loader that has the logic to search for resmany.dat and skip the hiberfil.sys header check.
• There are useful help docs describing how to implement HORM on your device, you can check them out here.
• One thing not covered in the documentation is how to enable HORM directly from Target Designer.  You can create an additional file resource that will copy resmany.dat to the root of your image partition or simply add it to the image after you do a build inside of Target Designer.  Then, assuming you have enabled hibernation in your power management component and configured EWF to run on startup, you will be able to immediately create your hiberfil.sys after your image finishes running through first-boot agent (FBA).
• If you are using Winlogon and include the settings in the UI Core component you will be able to hibernate via the start menu.  If not, you can include the XPE Power Management tool (xpepm.exe) and run xpepm -hibernate from a cmd prompt to create your hiberfil.sys after you launch the apps that you want to run each time you resume.

I encourage you all to take a look at HORM as you start exploring XPE SP2.  Please let us know if you run into any problems or have any questions.

Hey all, I was talking to someone earlier this week about ways to detect whether or not the .NET Framework SDK is installed on a user's machine.  They had seen my blog entry about detecting the .NET Framework redist and were curious about whether or not a similar method exists for the SDK.  As I was looking into it I stumbled upon a type of detection strategy that Visual Studio and the .NET Framework SDK use internally in their MSIs that I really wanted to explain in more detail because I haven't seen other setups do this or even use this term (plus now I can write a separate post about detecting the SDK and refer to this article for more details about one of the methods).

Before I start I wanted to define a couple of terms I'm going to use later on:

• Version - I will use this to refer to a specific family of products, for example - Visual Studio .NET 2002, Visual Studio .NET 2003
• Edition - I will use this to refer to one of the "flavors" of a product within a specific version; each edition represents one distinct product available in its own box at the store or via web download; for example - Visual Studio .NET 2002 Professional English, Visual Studio .NET 2003 Enterprise Developer German;
• SKU (or stock-keeping unit) - same as edition; this is the common name for products internally at Microsoft in my experience

The various editions of Visual Studio (such as Pro, Enterprise Developer, Enterprise Architect, etc) and the .NET Framework SDK ship many common components that can be installed to directories that the user can change in setup UI.  For example - the core IDE bits are the same for all editions of Visual Studio (within the 2002 version family and 2003 version family respectively of course).  Also, you can install the .NET Framework SDK tools, samples, etc by using the standalone SDK setup.exe or by choosing the .NET Framework SDK items in the Visual Studio setup selection tree.  You are allowed to install any edition of Visual Studio and/or the .NET Framework SDK on the same machine, in any order, with uninstalls mixed in also.

In these multi-edition scenarios, Visual Studio and .NET Framework SDK setup do some internal detection to determine whether or not any of the common components are already installed on the user's machine.  If they are, setup detects what path they are installed to, and automatically changes the install path in the setup UI for the feature(s) that contain the common component(s) to match the ones that were previously installed, and also prevents the user from changing these paths by graying out the browse button or via some other means. 

We use the term vertical integration to encompass this process of performing detection, updating paths if necessary and blocking future changes to these paths in setup UI.  Side note - I don't know for sure but it appears that we may have invented this term for this functionality on the VS setup team, I did some web searches and couldn't find any setup-related uses of this term (everything that came up for me was banking or financial analysis stuff).

Behind the scenes, vertical integration is implemented using some standard MSI constructs and in some cases some custom code in the Visual Studio external UI handler.  Here is an outline of how things are implemented in the Visual Studio .NET 2003 family (which includes the .NET Framework SDK 1.1).  I'm going to use the example of how we vertically integrate the .NET Framework SDK with Visual Studio .NET and refer to the MSI data for this, but there is similar data in the MSIs for other shared components as well.  You can see all of this data by using the Orca tool in the MSI Platform SDK to open the vs_setup.msi or netfxsdk.msi and view the data:

• There is a vertical integration component in the Component table, in this case named VIntegration_dotNetSDK.  It has a directory keypath and writes a registry value named [PRODUCTRELEASE] under HKLM\SOFTWARE\Microsoft\VisualStudio\SxS\FRAMEWORKSDK.  In this case the value name evaluates to 7.1, and the value data is equal to the .NET Framework SDK folder path.
• The vertical integration component is included in the MSI for all editions of the product that share the bits that we want to vertically integrate.
• There is an entry in the AppSearch table that searches for the vertical integration component, in this case it is called FRAMEWORKSDK.3643236F_FC70_11D3_A536_0090278A1BB8_RO (note the RO on the end, which represents "read-only")
• The appsearch uses an entry in the CompLocator table to search for the component GUID of the vertical integration component in the component table.
• There is a type 35 custom action in the Custom Action table that sets the value of the install path for the component that we want to force to have the same path as the previously installed component.  It uses the property set in the AppSearch table (which uses the signature defined in the CompLocator table).  In this example, the custom actions CA_Vintegration_Init_FrameworkSDK and CA_Vintegration_Exec_FrameworkSDK change the path of the directory FRAMEWORKSDK.3643236F_FC70_11D3_A536_0090278A1BB8 to match the value data in the registry under HKLM\SOFTWARE\Microsoft\VisualStudio\SxS\FRAMEWORKSDK.  This custom action makes sure that the path of the second and subsequent editions installed that have these shared, vertically integrated components will install to the same directory by default (even if the original installation directory is a non-default path updated by the user in setup UI)
• In the case of the .NET Framework SDK, we use standard Windows Installer UI.  In this MSI there is an entry in the ControlCondition table that causes the Browse control on the InstallPoint dialog to be hidden if the appsearch finds the vertical integration component installed.  This prevents the user from changing the install point in setup UI.
• In the case of Visual Studio, we use an external UI handler so we had to write custom code to prevent the user from changing the install point in setup UI.  In a nutshell, what happens is that when Visual Studio setup is first launched, it opens vs_setup.msi and runs through the actions listed in the custom table named InitializationSequence.  This will run all of the AppSearches and the type 35 custom actions to change paths for vertically integrated components.  Then there is code that finds all directory tokens that have "_RO" on the end, and hides the browse button for the features displayed in the selection tree UI that they are associated with.

This vertical integration strategy has caused us some headaches in the past.  In Visual Studio .NET 2002 and 2003 and the .NET Framework SDK 1.0 and 1.1, it is not transparent to the user that setup changes the default install paths on its own and prevents users from changing the paths of the second and subsequent editions that are installed on the machine.  There are odd scenarios where you can install one of the MSDN Quarterly documentation sets and then if you try to install Visual Studio or the .NET Framework SDK you cannot change the path and have no idea why not.  In many of the internal scenarios that I have seen, we have had to resort to using MSI API calls to enumerate installed products and then checking against a known list to determine what other product prevents the Visual Studio path from being changed because there is not any good logging to track this type of issue down.

The worst case I saw of this was caught before we shipped Visual Studio .NET 2003 - someone had installed Visual Studio .NET 2002 and an MSDN Quarterly, and then when they installed a beta of Visual Studio .NET 2003 the path was redirected onto the VS 2002 install location and the user could not change it.  In this particular case, the user didn't even notice it and ended up destroying their copy of VS 2002 (which should ordinarily install side-by-side with VS 2003) because all shared files were upgraded to the 2003 version and VS 2002 could not launch with a mismatch of some 2002 and some 2003 files.  This issue was caused by the MSDN Quarterly picking up AppSearch entries that looked for some shared components within VS 2002's MSIs and some shared components within VS 2003's MSIs.  We did a couple of last-minute tweaks to the VS 2003 vertical integration detection logic to avoid that issue when VS 2003 shipped.

Fortunately, in Visual Studio 2005 (codename Whidbey), this has been improved greatly - there is now visual indication in the setup UI that the path is not allowed to be changed and we generate a message on the fly indicating what product(s) we detected that are causing this behavior.

I know this post is long and detailed but I wanted to give some insight into how one of the features of Visual Studio and .NET Framework SDK setup works and also help illustrate some of the complicated engineering problems that have to be solved by setup.  As Rob Mensching says in the header of his blog, setup isn't just an xcopy (in most cases....)  :-)

Hey all, I posted last night about Windows XP Embedded SP2 being available for download and listed some of the new/changed features.  Our documentation team has posted a much more in-depth paper today that describes the new features in XPE SP2.  Check it out by clicking here.  I also encourage you to use the "rate this page" feature in the top corner of the screen to send any feedback you have about the document so we can continue to improve our documentation in the future.