From:	Alex Armanasu (Exchange)
Sent:	Wednesday, November 17, 1999 3:50 PM
To:	Murthy Srinivas (Exchange)
Subject:	Win9x Upgrade versus ScanState

     This email compares the win9x upgrade process to the scanstate migration process.  First, it describes what features the two tools has.  Second it describes how code is shared between the two tools.

Features

				Win9x Upgrade		ScanState
User files available after		yes			configurable
Moves system settings		almost all		15 groups
Moves application settings	a lot			10 applications
Moves user profile		yes			yes
src and dest same machine		yes			yes
src and dest different machine	no			yes
Moves irrelevent drivers		sometimes		no
Moves machine to managed env	no			some

      There are three core features that caused us to implement scanstate rather then using the win9x upgrade process.  The first is on the chart above.  Upgrade only works on one machine.  If you can't run Windows 2000 on your current machine, upgrade can't help you get your state to a Windows 2000 machine.  Scanstate can.  The second feature is more perceived then reality.  Customers perceive that an upgrade is less reliable then a wipe, reload, and reapplication of state (WRR).  Whether or not this is true remains to be seen, but customers have that perception.  They also perceive that WRR will clean up the machine.  That may mean losing unused files or losing unused registry keys.  Again, this is not a demonstrated feature of scanstate.  The third feature is managability.  In a managed environment the administrator can find a user's files and settings.  Scanstate aids in this process by giving the administrator the option of moving the users files to My Documents.

Code Sharing

     Scanstate consists of four pieces: moving system settings, move the user hive, moving application settings, and moving user files.  Each pieces uses the win9x upgrade code to a different degree.

     Moving the system settings is almost a direct port of the Win9x upgrade code.  For each setting we took the win9x upgrade code and ported it to our tool.  We examined porting the win9x upgrade tool itself but decided not to for the following reasons.  First, the win9x upgrade tool runs during setup and we do not.  A lot of APIs behave differently during setup.  Second, the win9x upgrade tool is tightly coupled to a process that creates several databases.  We could not determine a simple way to take just the pieces of the code we needed.  A quick port would require porting all of the win9x upgrade code.  The entire tool was too large to port in the time frame we had available.  Finally, the win9x upgrade code has already been through several ports.  It contains a lot of bad coding practises including extensive use of globals between modules and lack of documentation.

     The code to move the user hive is based on the design of the win9x upgrade.  We read their documentation, discussed their design with them, and took their file containing rules to process the hive.  We simply rewrote the processing code which was straightforward and only took a week.

     The application settings are moved by specifying rules to the registry processing engine used to move the user hive.  The win9x upgrade uses the same method.  However, the win9x upgrade moves both the user hive and the machine hive.  The scanstate tool does not want to move the machine hive.  Thus the win9x upgrade file containing application rules only has a subset of the information we need.  We had to determine which keys in HKLM needed to be moved for all our applications of interest.

     The win9x upgrade code does not move files.  Scanstate must move files.  We had to write this code from scratch.