From:	Chris Steck (Exchange)
Sent:	Wednesday, December 08, 1999 6:29 PM
To:	Alex Armanasu (Exchange); Henry Lee (Exchange); Weiru Cai (Exchange); Murthy Srinivas (Exchange); Michele Freed (Exchange); John Delo (Exchange)
Cc:	Craig Marl (Meridian Partners Ltd.) (Exchange)
Subject:	Belated minutes from 12/2  manifest mtg.
Sorry for the delay in getting these out. If you have an action below, please reply to me  with your status and I'll send an update. -Chris
=========================
Last week the To line met to discuss our course of action wrt manifests for legacy apps.

We enumerated the issues and determined a continuing course of action, reviewed latest enhancements/fixes made to tools by John and assigned action items for next steps  

Enumerated Issues and resultant action items

Tool related blocking issues/bugs
•	Sysdiff will sometimes report a sharing violation, required a private build by Henry. AI: HenryLee, please elaborate to determine when/if we need to depend on the private build or not.)
•	Leaf nodes in registry can not be duplicates 
AI: Fix by JohnDelo already code complete at time of meeting, All manifest creators should test.
•	MRU lists, cached paths of any kind can break when manifest run on target PC with different configuration. 
AI: JohnDelo to add path relocation code to tools. -Status John?
AI: All manifests creators must go back and manually mark paths in manifests for conversion according to process John will outline.

Process related issues
•	Takes minimum 1/2 to 1 day to generate a manifest using the current tools 
•	Recognizing lists in the generated manifests and converting to a generic list type is a time consuming manual process requiring situational heuristics, and is subsequently highly prone to human errors both of execution and omission.
AI:  We are just going to live with this for now, and ALL must manually munge the manifests they created to account for lists in the registry.
•	Unclear if we are all following the exact same procedures and using the same builds to create manifests.
AI: ChrisSte and Craig will generate brand new manifests using a "blessed" build of the tools. (no private builds!) 
AI: ChrisSte to facilitate manifest check in process

Coverage holes (deficiencies in the tool's feature set and/or our process)
•	How do we recognize and reflect dependencies on the order in which applications are installed in the manifests.  
Example 1: Visio hooks into the Outlook Contacts if Outlook is present. If Outlook was installed prior to Visio on the source,  those hooks will exist in its config.-But if user reinstalls Visio first via our manifest on the migration target, those hooks may also have migrated, but cause unexpected behavior in Visio since Outlook is not there.
•	If an app normally installs a sub component, but doesn't if that component already exists, how do we reflect that logic in one generic manifest?
•	If config data is stored in a proprietary format and/or outside the profile, how do we know we are only extracting the stuff that is relative to the user? (and not say, the hardware)
Example: A graphic art app stores color settings for a particular video card/monitor pair on the user's PC.  That info is stuffed in the same OLE stream in the registry as the user specific info. (like say his custom toolbar palette)  -If the user moves to new hardware, how do we put back the toolbar without taking the monitor video card settings?
AI for all of above: Craig to investigate by comparing manifests created for Word 2k installed on a clean machine, and another created for Word 2k installed after the remainder of Office is already present.

•	We have not tried to create a manifest for a VB app.
AI: Craig will create manifest for Company Store app.

•	We need beta testers to beat on the tools
In addition to the rest of us, MurthyS, Mfreed and BShah will use manifests once they have been updated for lists and marked for paths.