|Publication number||US7523122 B2|
|Application number||US 11/534,930|
|Publication date||Apr 21, 2009|
|Filing date||Sep 25, 2006|
|Priority date||Sep 25, 2006|
|Also published as||US20080077605|
|Publication number||11534930, 534930, US 7523122 B2, US 7523122B2, US-B2-7523122, US7523122 B2, US7523122B2|
|Inventors||Vijayendra G. Vasu|
|Original Assignee||Microsoft Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (20), Non-Patent Citations (7), Referenced by (2), Classifications (10), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
A computer user often needs to change the computer that she works on due to hardware failure, upgrades to newer hardware or software, etc. In particular, in a business setting, management typically deploys upgrades to hardware or software for all employees in response to business needs. During these upgrades, information technology administrators sometimes need to replace the computer workstations on which the users operate. In upgrading hardware, the administrators typically provide the users with standard or default configured workstations, and the users are left to re-configure personal preferences or settings that were found on their previous workstations. These preferences or settings, collectively referred to as user state data, include documents that users have created and the changes they have made to operating system and application settings (such as display or usability customizations). In a software-only upgrade, the administrators typically provide an image of the upgrade software package or system and replace the existing software package or system on the users' existing workstations with the image.
To reduce a loss of productivity, some administrators may extract user state data before performing the hardware or software upgrade. In some practices, administrators may ask users to perform a backup operation by saving the user state data in another memory space that is not affected by the upgrade. Alternatively, the administrators may perform a migration operation to transfer the user state data for the users from previous workstations to the upgraded workstations. Both instances are cumbersome and time-consuming.
In the migration operation, the administrators currently employ a migration application tool that first asks administrators to identify the locations of files and/or registry keys in a data repository of the previous workstations where the user state data is stored. The administrators next provide these storage locations of the user state data as input to the migration tool by writing scripts to be processed by the migration tool. The migration tool next processes the scripts and gathers the contents of the specified files and registry keys.
Existing migration tools typically are able to gather customization or user state data by searching standard or known locations in the data repository (e.g., file system) of a workstation in a known execution environment (e.g., Microsoft® Windows®-based or Mac® OS-based). However, current migration tools falter in discovering the locations (e.g., whether in the registry data repository or other data repositories) other than the standard or known locations. Current migration tools also are unable to distinguish user state data from other information belonging to the applications. In addition, the migration tools also fail to facilitate codifying the user state data in executable scripts.
Embodiments of the invention overcome the deficiencies of existing migration applications by providing administrators with a tool to automatically discover the storage locations of user state data associated with an application. Embodiments of the invention also automatically generate an executable migration script based on the discovered storage locations to migrate user state data.
Aspects of the invention also permit administrators to modify the discovered storage locations of user state data. Alternative embodiments of the invention discover user state data associated with the application installed in one or more execution environments and aggregate the discovered user state data across the execution environments.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Other features will be in part apparent and in part pointed out hereinafter.
Appendix A illustrates an exemplary script in XML format generated according to an embodiment of the invention.
Appendix B illustrates a portion of an exemplary implementation of executable codes that intercepts API interactions with application programs according to an embodiment of the invention.
Corresponding reference characters indicate corresponding parts throughout the drawings.
Referring first to
In one example, the data repository 106 may be classified into a file system 108, a registry 110, and a data storage 124. The file system 108 typically includes common memory storage areas, such as folders, directories, and files that a user can access. For those skilled in the art, the file system 108 may include the part of the data repository 106 that is readily available to the user in saving data or file in the data repository 106 (e.g., C:\ drive, My computer, or “My documents” folder). The registry 110, which may also be a part of the data repository 106, includes configuration data and the like for applications and/or the operating system installed in the computing device 102. For example, the registry 110 includes a data store having parameter values, configuration settings, registry entries (e.g., registry keys), or the like. The data storage 124 may include data memory areas, such as an external memory area, a remote data storage area, or the like. The data store may describe and/or define how an application or operating system should be operated or executed.
The computing device 102 also includes one or more applications installed and stored in the data repository 106. For example, an application 112 is installed in the data repository 106 for performing one or more tasks. The application 112 may include computer-executable instructions, codes, routines or other computer-executable components for producing a technical outcome (e.g., assisting the user to compose a text document, an interactive/multimedia presentation, a musical composition, or the like). The application 112 typically includes user state data 114, such as customizations, configurations, or the like. For example, the user may configure the application 112 in the computing device 102 by setting a particular color for the font text, a particular width for the scroll bars, or the like. The user state data may include one or more of the following: (1) data associated with personal applications (e.g., user installed); (2) changes or modifications to the operating system; (3) changes or modifications to the application 112; (4) changes or configurations to toolbox or menus; (5) files or data saved to the computing device 102 by the user; (6) registry keys, and registry values accessed by the application; and (7) registry keys, and registry values associated with the application.
As mentioned previously, users may change the computing device 102 over time due to hardware or software upgrades. In the situation of a portable device such as a cellular phone or a PDA, the users may change the computing device 102 every one or two years when service providers offer discounted upgrades. In this situation, a user may wish to be able to transfer their address book entries (e.g., phone numbers), calendar events and appointments, alarm settings, photographs, ring-tones, and other data from their existing devices to the upgraded devices. Similarly, for general computers (e.g., workstations, desktops, laptops, tablet PCs, or the like), the users may wish to transfer customizations, settings, files, and other user state data from the old computer to the new computer. To properly account for all user state data 114 (e.g., changes, modifications, or personalization), embodiments of the invention facilitate the transfer or migration process by deploying an interceptor application 116 to record the locations of the user state data 114 that is associated with the application 112.
Still referring to
For example, suppose an administrator 122 wishes to gather the user state data 114 associated with the application 112. In one embodiment, the administrator 122 causes the interceptor application 116 to be launched before the application 112 is launched in the computing device 102. The interceptor application 116 monitors the interactions between the application 112 and the data repository 106. For example, the interactions may include function calls or requests to the file system 108, requests to the registry 110, etc. In another embodiment, the interceptor application 116 also records the types of calls or requests between the application 112 and the data repository 106. For example, the application 112 may wish to read data from the file system 108, while the application 112 may wish to write data to the registry 110 after the user configures the display options of the application 112.
The interceptor application 116 intercepts or records the interactions (e.g., function calls or requests to the file system 108 or the registry 110) and lists the recorded interactions. In one embodiment, the list of the recorded interactions is presented or provided to the administrator 122 visually or audibly via a user interface (UI) 120. For example, the administrator 122 may enter commands and information into computing device 102 through input devices or user interface selection devices such as a keyboard and a pointing device (e.g., a mouse, trackball, pen, or touch pad). Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. In one embodiment, these and other input devices are connected to processor 104 through the UI 120 that is coupled to a system bus or other known system bus architecture, but may be connected by other interface and bus structures, such as a parallel port, game port, or a Universal Serial Bus (USB). A monitor or other type of display device may also be connected to system bus via the UI 120, such as a video interface. In addition to the monitor, the computing device 102 often includes other peripheral output devices such as a printer and speakers, which may be connected through an output peripheral interface.
The administrator 122 may select all the user state data 114 by choosing all locations discovered and recorded by the interceptor application 116. Alternatively, the administrator 122 may also filter the recorded locations based on at least one of the following factors: type of access, location of the user state data (e.g., in the file system 108 or the registry 110), file size, or the like. Once the administrator 122 completes its selection, a script generator 118 generates computer-executable scripts based on the list. In one embodiment, the generated computer-executable scripts are computer-executable instructions or codes written in eXtensible Markup Language (XML). As such, embodiments of the invention eliminate the need to require the administrator 122 to personally identify the locations where the user state data 114 may be stored and accessed. The generated scripts may be executed on the computing device 102 or one of the execution environments 202 in
By deploying the interceptor application 116 across execution environments, such as workstations within an enterprise, embodiments of the invention further enhance the completeness in gathering where user state data 114 is stored in the data repository 106 for a given application (e.g., application 112). For example, the application 112 may store user state data in various locations as a function of the user's access rights, data repository configuration, etc. By aggregating the locations of user state data 114 associated with the application 112, embodiments of the invention increase the accuracy of collecting and discovering all user state data 114 associated with the application 112, as the application 112 may store the user state data in an obscure location in response to an event, (e.g., crashing, etc.). This approach increases the probability of gathering all the user state data 114 of the application 112 and may also be less time-consuming for the administrator 122. The script generator 118 may generate XML scripts 210 from the aggregated reports from the interceptor application 116. Appendix B illustrates a portion of an exemplary implementation of executable codes that intercepts API interactions with application programs according to an embodiment of the invention.
In an alternative embodiment, the administrator 122 may transfer from an execution environment (e.g., 202-1) to another execution environment (e.g., 202-2) the user state data 114 corresponding to the recorded locations discovered by the interceptor application 116. The administrator 122 implements the generated XML scripts 210 in the other execution environment 202-2 such that the user state data 114 in the execution environment 202-1 is transferred to the another execution environment 202-2.
In another embodiment, the interceptor application 116 is deployed over an extended or predetermined period time in the execution environments 202. At the end of the interception period, the interceptor application 116 gathers the lists of locations where user state data 114 of the application 112 are stored, from the different participating desktops or execution environments. The reports including the lists of locations are merged at the computing device 102, and the resultant list of user state data storage locations encompasses the changes made by all the users on all the participating execution environments over the entire interception period.
In another embodiment, the computing device 102 may operate in a networked environment using logical connections to one or more remote computers or computing devices, such as the execution environments 202. The execution environments 202 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computing device 202. The logical connections depicted in
When used in a local area networking environment, the computing device 102 is connected to the LAN through a network interface or adapter (not shown). When used in a wide area networking environment, the computing device 102 typically includes a modem (not shown) or other means for establishing communications over the WAN, such as the Internet. The modem, which may be internal or external, is connected to system bus via the UI, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computing device 102, or portions thereof, may be stored in a remote memory storage device (not shown). The network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
Generally, the processor 104 of the computing device 102 is programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer's primary electronic memory. Aspects of the invention described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the steps described below in conjunction with a microprocessor or other data processor. Further, aspects of the invention include the computer itself when programmed according to the methods and techniques described herein.
Referring now to
At 512, it is determined whether the identified locations are filtered based on various criteria (e.g., locations of the user state data or the types of interactions) using a filter component 416. If the identified locations are to be filtered, the user 504 is permitted to select the desirable locations from the identified locations at 514. If the determination is negative, the identified locations are selected at 516. A script component 408 generates computer-executable scripts based on the identified locations or selected locations at 518. In an alternative embodiment, a migration component 410 migrates or transfers the user state data associated with the application from a first execution environment to a second execution environment by executing the generated scripts in both the first (for gathering the user state data) and the second execution environment (for applying the user state data) at 520. In another example, when the migration component 410 migrates or transfers the user state data associated with the application from the first execution environment to one or more second execution environments, the migration component 410 executes the generated scripts in the first execution environment and then one or more second execution environments. In one embodiment, an execution component 414 executes the generated script in the second execution environment. For example, the execution component 414 may be a component adapted to executing executable code, such as the generated script.
For purposes of illustration, programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks. It is recognized, however, that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer.
Although described in connection with an exemplary computing system environment, including computing device 102, embodiments of the invention are operational with numerous other general purpose or special purpose computing system environments or configurations. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of any aspect of the invention. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The order of execution or performance of the operations in embodiments of the invention illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and embodiments of the invention may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the invention.
Embodiments of the invention may be implemented with computer-executable instructions. The computer-executable instructions may be organized into one or more computer-executable components or modules. Aspects of the invention may be implemented with any number and organization of such components or modules. For example, aspects of the invention are not limited to the specific computer-executable instructions or the specific components or modules illustrated in the figures and described herein. Other embodiments of the invention may include different computer-executable instructions or components having more or less functionality than illustrated and described herein.
When introducing elements of aspects of the invention or the embodiments thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
Having described aspects of the invention in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the invention as defined in the appended claims. As various changes could be made in the above constructions, products, and methods without departing from the scope of aspects of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
<?xml version=“1.0” encoding=“UTF-8” ?22
- <migration urlid=“http://www.microsoft.com/migration/1.0/migxmlext/
- <component context=“UserAndSystem” type=“Application”>
<displayName _locID=“migapp.msnmessenger”>MSN Messenger</
<environment name=“GlobalEnv” />
<environment name=“GlobalEnvX64” />
- <variable name=“MSNMessengerInstPath”>
- <role role=“Settings”>
- <rules context=“User”>
<pattern type=“Registry”22 HKCU\Software\Microsoft\MSNMessenger\
<pattern type=“File”>% CSIDL_APPDATA%\Microsoft\MSN
- <merge script=“MigXmlHelper.SourcePriority( )”>
<pattern type=“File”>% CSIDL_APPDATA%\Microsoft\MSN
- <rules context=“System”>
void Log(ResourceType rt, AccessType at, LPCWSTR fullPath)
static LONG logCount = 0;
if (at == AccessTypeNone)
if ((at & AccessTypeWrite) == 0)
// In this prototype, we use optimistic locking for performance
if ((logCount % LogLinesPerFile) == 0)
LONG initialValue = InterlockedCompareExchange(&logCount,
logCount + 1, logCount);
if ((initialValue % LogLinesPerFile) == 0)
// Create a log file every LogLinesPerFile messages.
// There is a chance that this thread writes using the file handle that
// has been closed. We can live with this loss of log message.
// Note, we may be off by 1 due to simultaneous increments by
// multiple threads, but we don't care as this is only approximate.
FILE *logFile = g_logFile;
if (logFile == NULL)
// We may not be able to prevent multi-threaded calls, at least
// prevent recursive writes.
g_writingLog = true;
fwprintf(logFile, L“%s %s%s %s\n”,
(at & AccessTypeRead) != 0 ? AccessTypeReadString: L“ ”,
(at & AccessTypeWrite) != 0 ? AccessTypeWriteString: L“ ”,
fullPath != NULL ? fullPath : L“”);
g_writingLog = false;
void LogRegistryAccess(bool isRegistryKey, AccessType at, LPCWSTR
Log(isRegistryKey ? ResourceTypeRegistryKey :
ResourceTypeRegistryValue, at, fullPath);
_out PHANDLE KeyHandle,
_in ACCESS_MASK DesiredAccess,
_in POBJECT_ATTRIBUTES ObjectAttributes,
_reserved ULONG TitleIndex,
_in_opt PUNICODE_STRING Class,
_in ULONG CreateOptions,
_out_opt PULONG Disposition
_out PHANDLE KeyHandle,
_in ACCESS_MASK DesiredAccess,
_in POBJECT_ATTRIBUTES ObjectAttributes,
_reserved ULONG TitleIndex,
_in_opt PUNICODE_STRING Class,
_in ULONG CreateOptions,
_out_opt PULONG Disposition
status = ORIGINAL API(NtCreateKey)(KeyHandle,
DesiredAccess | KEY_QUERY_VALUE, ObjectAttributes, TitleIndex,
Class, CreateOptions, &disp);
if (Disposition != NULL)
*Disposition = disp;
// If we are logging writes only, don't log key opens.
if(disp != REG_CREATED_NEW_KEY)
AccessType at = AccessTypewrite;
if ((DesiredAccess & (KEY_EXECUTE | KEY_READ)) != 0)
at =(AccessType) (at AccessTypeRead);
LogRegistryAccess(true, at, fullKeyName);
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6161176||Nov 20, 1998||Dec 12, 2000||Microsoft Corporation||System and method for storing configuration settings for transfer from a first system to a second system|
|US6182212||Dec 14, 1998||Jan 30, 2001||International Business Machine Corporation||Method and system for automated migration of user settings to a replacement computer system|
|US6370646||Feb 16, 2000||Apr 9, 2002||Miramar Systems||Method and apparatus for multiplatform migration|
|US6687897 *||Dec 1, 2000||Feb 3, 2004||Microsoft Corporation||XML based script automation|
|US6795835||Jan 29, 2001||Sep 21, 2004||Centerbeam, Inc.||Migration of computer personalization information|
|US6823460||Apr 28, 2000||Nov 23, 2004||Networks Associates Technology, Inc.||Method and system for intercepting an application program interface|
|US6920555 *||Mar 17, 2001||Jul 19, 2005||Powerquest Corporation||Method for deploying an image into other partition on a computer system by using an imaging tool and coordinating migration of user profile to the imaged computer system|
|US6959441||May 3, 2001||Oct 25, 2005||International Business Machines Corporation||Intercepting system API calls|
|US7032011||May 10, 2001||Apr 18, 2006||Symantec Corporation||Server based extraction, transfer, storage and processing of remote settings, files and data|
|US7107589 *||Sep 28, 2001||Sep 12, 2006||Siebel Systems, Inc.||Infrastructure for the automation of the assembly of schema maintenance scripts|
|US20030074386||Oct 1, 2001||Apr 17, 2003||Microsoft Corporation||Method and system for migrating computer state|
|US20050149582 *||Dec 29, 2003||Jul 7, 2005||Wissmann Joseph T.||Method and system for synchronization of copies of a database|
|US20060085679||Aug 26, 2005||Apr 20, 2006||Neary Michael O||Method and system for providing transparent incremental and multiprocess checkpointing to computer applications|
|US20060129769 *||Dec 9, 2004||Jun 15, 2006||Shaofei Chen||System and method for migration to manufactured information handling systems|
|US20060136471 *||Dec 17, 2004||Jun 22, 2006||International Business Machines Corporation||Differential management of database schema changes|
|US20060235899 *||Mar 27, 2006||Oct 19, 2006||Frontline Systems, Inc.||Method of migrating legacy database systems|
|US20070079140 *||Sep 26, 2005||Apr 5, 2007||Brian Metzger||Data migration|
|US20070294577 *||Jun 22, 2006||Dec 20, 2007||Bea Systems, Inc.||Automatic Migratable Services|
|US20070294703 *||Jun 19, 2006||Dec 20, 2007||Ozan Talu||System and Method for Migration of Information From a Legacy to a Replacement Information Handling System|
|GB2420198A||Title not available|
|1||Author Unknown, "Windows User State Migration Tool (USMT) version 2.6.2," Microsoft Download Center, http://www.microsoft.com/downloads/details.aspx? familyid=0CAA294C-29D9-4449-81D5-4B69B97DF7AE&displaylang=en, 3 pages, Jul. 22, 2006, Microsoft Corporation, USA.|
|2||Chen, Hao et al., "Back to the Future: A Framework for Automatic Malware Removal and System Repair," http://www.cs.ucdavis.edu/research/tech-reports/2005/CSE-2005-6.pdf, last modified Jun. 9, 2005, 16 pages, University of California, Davis, USA.|
|3||*||Grolaux et al. "Migratable user interfaces: beyond migratory interfaces", Aug. 22-26, 2004 pp. 422-430.|
|4||*||Jonathan M. Smith "A survey of process migration mechanisms", vol. 22, Issue 3 (Jul. 1988), pp. 28-40, Publication: 1988.|
|5||Li, Wei et al., Automatic Application-Specific Sandboxing for Win32/X86 Binaries, in Proceedings of Program Analysis for Security and Safety Workshop (Password) co-located with ECOOP 2006, Nantes, France, Jul. 2006, 10 pages, Computer Science Department, Stony Brook University, USA.|
|6||Lorch, Jacob R. et al., "Building VTrace, a Tracer for Windows NT and Windows 2000," http://www.eecs.berdeley.edu/Pubs/TechRpts/2000/CSD-00-1093.pdf, Feb. 2000, 17 pages, Computer Science Division (EECS), University of California, Berkeley, California, USA.|
|7||Tulloch, Mitch, "Migrating to Vista Using Windows Easy Transfer," http://www.windowsnetworking.com/articles-tutorials/Migrating-Vista-using-Windows-Easy-Transfer.html, Jul. 26, 2006, 21 pages, WindowsNetworking.com, USA.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8893118 *||Jan 30, 2006||Nov 18, 2014||International Business Machines Corporation||Migratable unit based application migration|
|US20070240143 *||Jan 30, 2006||Oct 11, 2007||International Business Machines Corporation||Migratable unit based application migration|
|U.S. Classification||1/1, 707/999.101, 707/999.2, 707/999.202|
|Cooperative Classification||G06F8/60, Y10S707/99953, G06F9/44505, Y10S707/99942|
|Oct 20, 2006||AS||Assignment|
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VASU, VIJAYENDRA G.;REEL/FRAME:018417/0778
Effective date: 20060920
|May 3, 2011||CC||Certificate of correction|
|Dec 3, 2012||REMI||Maintenance fee reminder mailed|
|Apr 21, 2013||LAPS||Lapse for failure to pay maintenance fees|
|Jun 11, 2013||FP||Expired due to failure to pay maintenance fee|
Effective date: 20130421
|Jan 15, 2015||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0509
Effective date: 20141014