EP1866754A1 - Systeme et procede de migration d'un systeme d'exploitation, des donnees d'utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur - Google Patents

Systeme et procede de migration d'un systeme d'exploitation, des donnees d'utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur

Info

Publication number
EP1866754A1
EP1866754A1 EP06726204A EP06726204A EP1866754A1 EP 1866754 A1 EP1866754 A1 EP 1866754A1 EP 06726204 A EP06726204 A EP 06726204A EP 06726204 A EP06726204 A EP 06726204A EP 1866754 A1 EP1866754 A1 EP 1866754A1
Authority
EP
European Patent Office
Prior art keywords
computer
migration
server
synchronization server
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06726204A
Other languages
German (de)
English (en)
Inventor
Serge Soulet
Jean-Marc Vuillaume
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Refresh IT Solutions
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1866754A1 publication Critical patent/EP1866754A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files

Definitions

  • a system and method for migrating an operating system, user data, and applications from at least one server to at least one computer is a system and method for migrating an operating system, user data, and applications from at least one server to at least one computer.
  • the invention relates to the field of the migration of workstations of companies with a large number of computers, and more particularly in the field of the migration of an operating system, user data, and applications from at least one server to at least one computer.
  • the object of the invention is to remedy these drawbacks by centralizing and automating the migration of workstations.
  • a method for migrating an operating system, user data, and applications from at least one server to at least one computer connected to said server through an information network the migration is performed by an automatic sequence of a set of steps organized according to initial data and / or interactivity between said computer and said server, said steps comprising the following steps: - initialization of said computer, - analysis of said computer to check if it is able to support the migration, and
  • the method according to the invention allows a centralized and fully automated migration of a plurality of workstations then reducing the time of implementation of this migration.
  • said preceding step comprises a last command for starting an automatic start of the next step.
  • the automaticity of the migration is carried out in a simple manner and makes it possible to follow the successive triggering of the steps and to resume in case of error.
  • the initial data is recorded by a requestor of the migration operation in a database.
  • data of a synchronization server and include a migration type, execution dates of the steps, and the names of said computer and / or its / its users.
  • the different steps are planned in advance to allow a successful and rapid migration.
  • the initialization is performed by an automatic sequence of a first set of elementary steps comprising;
  • the computer to be migrated is well prepared to undergo the different stages of the migration.
  • the analysis of said computer comprises an automatic concatenation of a second set of elementary steps comprising:
  • said computer and recording said inventory in the database of the synchronization server, said inventory comprising lists of installed applications, and / or profile or profiles of the user or users, and technical parameters and location of said computer, and
  • the analysis of said computer further comprises an automatic sequence of a third set of elementary steps comprising: analysis of the capacity of said computer to support the migration, information sent to the synchronization server to interrupt the automatic process, in case said computer does not have the capacity necessary for the migration until a modification of said computer allows it to support the migration, -relancement of the automatic process when said computer has the capacity to supporting said operating system, and triggering by the synchronization server in a next step depending on the type of migration.
  • the loading of said operating system into said computer comprises an automatic sequence of a fourth set of elementary steps comprising:
  • the computer is prepared in a secure and efficient manner to allow it to receive an image in advance.
  • the deposition of said image of said operating system in said storage disk of said computer is carried out by the cable television server by communicating to said computer the name of a computer holding said image belonging to the same local network of said computer and having previously downloaded said image, or by communicating to said computer the address of a central storage location including said image if said local network does not include another computer having previously downloaded said image.
  • the method further comprises a step of preparing a data backup of the one or more users comprising an automatic sequence of a fifth set of elementary steps comprising: -choice by said requestor of the migration of profiles to be saved among profiles found on said computer, -choice by said requester of the migration operation of the applications useful to reinstall after the migration, among applications found on said computer and / or from a list of available applications, -determination of the storage volume needed to save data corresponding to the selected profile (s) and application (s). -reservation by the synchronization server of said storage volume on a backup server, and
  • the method further comprises a step of saving the data of the user or users comprising an automatic sequence of a sixth set of elementary steps comprising:
  • the loading of said operating system into said computer further comprises an automatic sequence of a seventh set of elementary steps comprising:
  • the method further comprises a step of restoring the saved data comprising an automatic sequence of an eighth set of elementary steps comprising:
  • the method further comprises a step of installing said useful applications chosen by said migration requestor before and / or after the restoration of said saved data comprising an automatic sequence of a ninth set of steps elementary comprising: -demand by the server of synchronization to the cable television server of the installation of a first application on said computer, -check by the synchronization server of the correct installation of said application, and realization of a determined number of attempts in case the installation failed,
  • the invention also relates to a computer program designed to implement the method according to the above characteristics when executed by a computer system.
  • the invention also relates to a system for migrating an operating system and applications from at least one server to at least one computer connected to said server via an information network, including a synchronization server. connection with cable television, inventory and backup servers intended to perform the migration by automatic linking of a set of steps organized according to initial data and / or interactivity between said computer and said servers and comprising an initialization of said computer, an analysis of said computer to check whether it is able to support the migration, and a loading of said operating system and said applications in said computer.
  • a synchronization server connection with cable television, inventory and backup servers intended to perform the migration by automatic linking of a set of steps organized according to initial data and / or interactivity between said computer and said servers and comprising an initialization of said computer, an analysis of said computer to check whether it is able to support the migration, and a loading of said operating system and said applications in said computer.
  • FIG. 1 illustrates a system for migrating workstations performing the migration of an operating system and applications from at least one server to at least one computer connected to said server via an information network according to the invention
  • FIGS. 2 and 3 illustrate examples describing the descriptions of a scenario and a migration operation in a database of a synchronization server, according to the invention
  • FIGS. 4 to 15 diagrammatically illustrate flowcharts of the various steps that can be implemented in several types of migration operations, according to the invention.
  • FIG. 1 illustrates an example of a workstation migration system performing the migration of an operating system and applications from at least one server to at least one computer connected to said server by intermediary of an information network.
  • this example comprises a synchronization server 1 comprising a database 3, a cable television server 5, an inventory server 7, a backup server 9 and possibly a central storage location 11.
  • a synchronization server 1 comprising a database 3, a cable television server 5, an inventory server 7, a backup server 9 and possibly a central storage location 11.
  • These servers are connected through an information network 13 with a plurality of workstations or computers 15a-15c, and 17a-17c that may be distributed over a set of separate local information networks 15 and 17 respectively.
  • the migration of a workstation associated with a determined computer 15a is performed by an automatic sequence of a set of steps (also called scenarios) organized according to data. initials and / or interactivity between the determined computer 15a and the servers 1, 5, 7, 9.
  • the initial data can be stored in the database 3 of the synchronization server 1 by a requestor 19 of the operation and may include the type of migration, the execution dates of the steps, and the names of the determined computer 15a and / or its user (s) 21.
  • a migration operation may be a migration for a user on the same computer machine, or a migration for a user on a new computer machine, or the mastering of a workstation to be rebuilt, or the mastering a workstation for a new user.
  • a migration operation is a set of steps or scenarios intended to answer all the problems that may be encountered during the migration process.
  • the steps or scenarios of a migration operation comprise an initialization of the computer 15a, an analysis of the computer 15a to check whether it is able to withstand the migration, and a loading of the operating system and applications in this computer 15a.
  • a scenario is a succession of tasks (also called elementary steps), each task being a job to be performed on an actor or computer system (for example, the servers 1, 5, 7, 9, the database 3, the computer 15a ) involved in the migration process to produce some action.
  • an action is a status resulting from an elementary stage.
  • a post-action is a program executed from the synchronization server 1 following the occurrence of an action (example: send an e-mail).
  • a post-action can have the task of performing a basic step advancing the status (the action).
  • a scenario can be defined on one or more actors (for example 1, 3, 5, 9, 11, 15a) and a migration operation is then a succession of scenarios that follow one another automatically thanks to the synchronization server 1.
  • the synchronization server 1 includes a first program capable of performing the programs called by the postactions. It also comprises a second program (for example API SetAction) callable from any point of the information network 13 capable of taking into account the status advancements issued by the actors (computer systems) in order to update the database 3 included in the synchronization server 1.
  • the synchronization server 1 also comprises a third program callable from any point of the information network 13 and able to determine the next action to be communicated during a solicitation by an actor (eg API GetNextAction).
  • I 1 GetNextAction API when for example I 1 GetNextAction API is called, it controls that the action is not the last of the scenario. Otherwise, it executes a SetAction on the first action described in the following scenario.
  • the synchronization server 1 comprises a fourth program callable from any point of the information network 13 and capable of stopping the migration process in case of error (eg API SetLastError).
  • the database 3 of the synchronization server 1 includes the description of the scenarios (ie the elementary actions or steps and their sequences), the description of the migration operations (that is to say the scenarios and sequence of these scenarios according to the migration operation), and the description of a particular operation requested by the requestor 19 of the migration operation. It is also necessary to have other programs that run on the actors (computer systems) and which must be able to perform the basic steps and to notify the synchronization server 1 of the success or failure of the program. a task by systematically informing the program of the synchronization server 1 (for example API SetAction).
  • API SetAction for example API SetAction
  • Figure 2 shows the description of a scenario in the database 3 of the synchronization server 1.
  • the box C1 represents a description of a first scenario
  • the box C2 is the name of the scenario
  • the box C3 is the description of the actions with the numbers of the execution order
  • the box C4 is the name of the action
  • if the first action is named as the scenario then box C5 expresses the naming of a post-action.
  • the C6 box indicates that the number of the previous action is non-existent if it is the first action of the scenario.
  • the C7 box indicates that the number of the following action is non-existent if it is the last action of the scenario.
  • Box C8 is a naming of the next action
  • box C9 is the number of the previous action
  • the box ClO indicates that the number of the following action is non-existent if it is the last action of the scenario.
  • FIG. 1 shows the description of a migration operation in the database 3 of the synchronization server 1.
  • Box C21 represents a description of the operation and box C22 indicates an addition of a first scenario.
  • Box C23 is a test to check whether to add another scenario. If yes, add a next scenario to box C24 before returning to test C23. On the other hand, if there is no other scenarios to add, so box C25 indicates the end of the migration operation.
  • the synchronization server 1 and its database 3 make it possible to plan the elementary steps, to follow the execution of these elementary steps, to trigger the following elementary step and to resume in case of error.
  • a first scenario is an "initialization" scenario for preparing the computer 15a to undergo the actions to be performed by depositing by the cable server 5 the initialization programs necessary for the migration.
  • the initialization scenario is achieved by an automatic sequence of a first set of elementary steps.
  • a first basic step is the request made by the synchronization server 1 to the cable television server 5 to install on the determined computer 15a a program necessary for the type of migration indicated in the initial data.
  • a second basic step is the installation of this program on the determined computer 15a by the cable television server 5.
  • a third basic step concerns the execution of this program by the cable television server 5, before the synchronization server 1 triggers a next elementary step depending on the type of migration requested.
  • the analysis of the determined computer 15a can be performed by two scenarios called “source audit” and “target audit”.
  • the source audit scenario consists of analyzing the computer 15a to verify that it is able to support the migration tools and that there is at least one user profile 21 on the computer 15a.
  • This source audit scenario includes an automatic sequence of a second set of basic steps.
  • the determined computer In a first basic step, the determined computer
  • This inventory may include lists of installed applications or software, and / or the profile or profiles of the user or users 21, and technical parameters and geographical location of the determined computer 15a.
  • a second basic step concerns the triggering by the synchronization server 1 of a next step depending on the type of migration.
  • the target audit scenario also involves analyzing the computer 15a or the workstation to verify that it is able to support the migration tools. In addition, we also check that the type of computer really corresponds to the one that was requested.
  • This target auditing scenario includes an automatic sequence of a third set of basic steps.
  • the computer 15a analyzes its ability to support the migration. Then, in a second basic step, the computer 15a sends information to the synchronization server 1 to interrupt the automatic process, in case the computer 15a does not have the capacity necessary for migration. The process is interrupted until a modification of the computer 15a allows it to support the migration.
  • the synchronization server 1 regularly queries its database 3 which contains the inventory. Thus, in a third basic step, the synchronization server 1 restarts the automatic process when the computer 15a has the capacity to support the operating system. Then, the synchronization server 1 triggers a next step depending on the type of migration.
  • the loading of the operating system into the computer 15a includes a first scenario of depositing an image of the operating system on the computer 15a and a second mastering scenario. It should be noted that the user's data and parameters must be saved before the mastering scenario.
  • the scenario of depositing the image makes it possible to deposit on the computer 15a a "ghost" image in advance knowing that the result of the distribution does not matter because it will be redistributed if necessary at the last moment.
  • This image deposition scenario comprises an automatic sequence of a fourth set of elementary steps.
  • the computer 15a proceeds to a cleaning of its storage disk by deleting useless files (for example .bak, .tmp, and ⁇ * ) known in the database 3 synchronization system 1. This in order to make a place to file the image of the operating system thus giving the scenario a maximum chance of succeeding. Then, the image of the operating system is filed in peer-to-peer by the cable television server 1 in the storage disk of the computer 15a before the triggering by the synchronization server 1 of a next step based the type of migration.
  • useless files for example .bak, .tmp, and ⁇ *
  • the filing of the image of the operating system in the storage disk of the determined computer 15a is performed by the cable television server 5 by communicating to this determined computer 15a the name of a computer storing the image. (eg 15b) belonging to the same local area network 15 as the determined computer 15a and having previously downloaded this image.
  • the cable television server 5 communicates to the determined computer 15a the address of the central storage location 11 comprising this image.
  • the method includes a "validation" scenario.
  • This scenario allows the manager or requestor 19 of the migration operation to validate that the volume of data to be backed up is not too important and to choose the applications or software to be reinstalled from those available. There is no recovery possible for this scenario. If the requestor 19 of the migration operation considers that the volume is too large, it will negotiate with the user 21 the deletion of some large or old files and then validate.
  • This validation scenario then consists in preparing the data backup of the user or users 21 and includes an automatic sequence of a fifth set of elementary steps.
  • the requestor 19 of the migration operation chooses the profiles to be saved from the profiles found on the computer 15a. Then, he chooses the applications that are useful to reinstall after the migration, among applications found on the computer and / or from a catalog or list of available applications.
  • a following basic step consists of the determination by the computer 15a of the storage volume necessary to save data corresponding to the profile (s) and application (s) chosen and informs the database 3 of the server of synchronization 1.
  • the synchronization server 1 reserves this storage volume on the backup server 9, before triggering a next basic step depending on the type of migration.
  • the method comprises a scenario of "backup of data and user parameters" by copying, if necessary, the mail data to a remote server (not shown). This backup scenario of the data of the user or users
  • 21 comprises an automatic sequence of a sixth set of elementary steps.
  • the computer 15a informs the user 21 of the beginning of the backup step in order to invite him to close his applications and close his session. Then, the computer 15a verifies that it contains no bootable external storage element (CDRom, floppy disk). In the opposite case, the computer 15a emits an alert inviting the user 21 to remove the bootable external storage element from the computer 15a.
  • the following basic steps concern a restart of the computer 15a and the backup by the computer 15a, data of the user or users 21 on the backup server 9. Then, the synchronization server 1 triggers a next elementary step depending on the type of migration.
  • the mastering scenario makes it possible to master the computer 15a, that is to say to deposit the new operating system in place of the one already present. .
  • This mastering scenario includes an automatic sequence of a seventh set of elementary steps.
  • the computer 15a loads the operating system into its storage disk.
  • the computer 15a performs a determined parameterization (more precisely a post-parameterization) of the computer 15a.
  • the synchronization server 1 triggers a next basic step depending on the type of migration.
  • the method includes a "data recovery” scenario that consists in restoring all the data of the user or users.
  • This scenario of restoring the saved data comprises an automatic sequence of an eighth set of elementary steps.
  • the computer 15a stores the saved data and then checks the quality of the data saved. Then, the synchronization server 1 triggers a next step depending on the type of migration.
  • the method includes a scenario for reinstalling useful or software applications chosen by the migration requestor 19 after or before the restoration of the saved data of the users 21.
  • This scenario includes an automatic sequence of a ninth set of elementary steps.
  • the synchronization server 1 requests the cable television server 5 to install a first application on the computer 15a.
  • a second basic step the synchronization server 1 checks the correct installation of the application. In case the installation failed, the synchronization server 1 makes other attempts (for example two other attempts).
  • the synchronization server 1 requests the cable television server 5 to install a next application on the computer 15a. The second and third basic steps are repeated until the reinstallation of all the applications chosen by the requestor 19 of the migration operation. Then, the synchronization server 1 triggers a next basic step depending on the type of migration.
  • the migration method according to the invention can be implemented by a plurality of computer programs (also called computer program) executed by the various actors or computer systems (synchronization server 1, database 3, cable television server 5, inventory server 7, backup server 9, computers 15a to 17c, etc.).
  • synchronization server 1, database 3, cable television server 5, inventory server 7, backup server 9, computers 15a to 17c, etc. synchronization server 1, database 3, cable television server 5, inventory server 7, backup server 9, computers 15a to 17c, etc.
  • the migration operation of a computer park can be of several types.
  • a first example is a migration operation for a user on the same computer, for example a migration from a Windows 2000 (registered trademark) station to Windows XP (registered trademark).
  • This operation concerns the migration of a station for a user. In this operation, neither computer 15a nor users 21 are changed, all user data is retrieved 21 and the reinstallation of all the software initially available and of which the installation package is held is allowed.
  • This first operation may include, in order, the following scenarios (steps): entering the necessary information, initialization (source), audit (source), pre-validation (source), validation (source), image repository (source) " ghost with CleanUp light ", signaling operation (source), backup of user data (source), mastering (target), initialization (target), software installation (target), restore user (target), audit (target), and recipe / survey data.
  • steps entering the necessary information, initialization (source), audit (source), pre-validation (source), validation (source), image repository (source) " ghost with CleanUp light ", signaling operation (source), backup of user data (source), mastering (target), initialization (target), software installation (target), restore user (target), audit (target), and recipe / survey data.
  • a second example is a migration operation for a user on a new computer. This operation is for migrating a workstation for a user. In this operation, a computer is changed during the migration. Users of a first computer are migrated to a second one. All user data is retrieved and transferred, and all software initially available and owned by the installation package is reinstalled.
  • This second operation can include the following scenarios in order: input of necessary information, initialization (source), audit (source), initialization (target), audit (target), pre-validation (source), validation (source), filing 'image (source)' ghost with CleanUp light ', report operation (source), backup of user data (source), mastering (target), initialization (target), software installation (target), restore of user data (target), audit (target), and recipe / survey.
  • a third example is a mastering operation of a workstation to rebuild.
  • This operation is for mastering a workstation for a user. In this operation, we do not know the computer or initial machine of the user (he may not have been).
  • This third operation can include the following scenarios in order: entering the necessary information, initialization (target), audit (target), validation (source), mastering (target), initialization (target), software installation (target), audit (target), and poll.
  • a fourth example is a mastering operation of a workstation.
  • This operation concerns the mastering of a workstation without immediate objective of use. In this operation, we only prepare the workstation for future use. The goal of this mastering is to have a workstation ready to be put into service when a new user arrives.
  • This fourth operation may comprise in the following order the following scenarios; entering necessary information, initialization (target), audit (target), mastering (target), initialization (target), and audit (target).
  • each migration operation is a set of scenarios intended to respond to all the problems stated by the process or deployment of the migration.
  • Figures 4 to 15 schematically illustrate flowcharts of the different feasible scenarios in the different types of migration operations.
  • Each scenario is a succession of basic steps or tasks necessary to achieve the goal set by the deployment of the migration operation. Note that a scenario only executes for a specific computer and each scenario is realized so as to be reusable in several types of migration operations.
  • FIG. 4 schematizes the initialization scenario for preparing the computer 15a to undergo the actions of the migration operation, by depositing the cable television customer "peer to peer” by cable television;
  • the EO basic step is manual and runs at least the day before the migration, preferably or by default ten days (J-IO) before the migration.
  • the deployer or requester 19 of the migration operation contacts the main user of the station station 15a to be migrated, retrieves his connection identifier, his station name, the type of station and the desired migration date (day D), he saves them in the base station.
  • II checks with the user 21 that the user does not use software that is not supported by the new version (eg Windows XP). The registration of the request is made through the website of the synchronization server 1. This step ends with a SetAction (POSTE_CREE) which itself generates a request for cable television with the cable server 5.
  • POSTE_CREE SetAction
  • the distributed package consists of the deposit / installation of the client of the cable television server 5 and the filing of the specific MMSetaction program. . exe ⁇
  • the installation runs the command MMSetAction.exe -DISTRIBUTORJNSTALLE. This command is followed by a post-action that executes the next elementary step E2.
  • the basic step E2 is automatically performed at the end of the installation of the client of the cable television server 5. It concerns the filing by the distribution server 5 of the packages necessary for the following actions: filing of the inventory scanner; storing and installing the synchronization server 1 client; repository of analysis and migration tools (MMCIone.exe: image installation tool ghost, MMProfiles.exe: analysis tool for profiles found on the computer, MMCIeanUP.exe: tool for cleaning the disk to be mastered , MMSigMigrXP.exe: signaling tool of the operation to the end user, MMInstl.exe: software reinstallation software, MMFileList.exe: tool for saving user data).
  • MMCIone.exe image installation tool ghost
  • MMProfiles.exe analysis tool for profiles found on the computer
  • MMCIeanUP.exe tool for cleaning the disk to be mastered
  • MMSigMigrXP.exe signaling tool of the operation to the end user
  • MMInstl.exe software reinstallation software
  • Step E3a indicates that the "Initialization" scenario is finished and step E3b is the last action of the scenario which consists in following the following scenario, depending on the requested operation.
  • FIG. 5 schematizes the "source audit” scenario which consists of analyzing the workstation 15a to verify that it is able to support the migration tools and that there is at least one user profile 21 on the workstation 15a. .
  • the step E4a is triggered by the previous scenario and allows the launch of an inventory on the workstation 15a.
  • the inventory is specific to the synchronization server because the files generated by the scanner are deposited on a specific resource so that the data is taken into account almost immediately by the inventory server 7.
  • the list of software installed the list of user profiles 21 present on the workstation 15a, the exact type of the station 15a (which will deduce the image package (Ghost XP) to be deposited), the technical parameters of the workstation 15a (Ram, disk, etc.), and the geographical location of this station 15a.
  • Step E4a is triggered by the synchronization server.
  • step E5a PostAction at 26EOK
  • the necessary data is imported into the database 3 of the synchronization server 1.
  • the action 26EOK executes three Post-Actions whose last analysis the capacity of the workstation 15a to migrate.
  • Step E5b is a test to check whether the workstation 15a supports the tested pre-requisites (for example the capacity of this latter to support the software for saving the data and parameters of the users). If yes, then we go to step E6a which simply informs the synchronization server 1 via a SetAction (AUDIT_OK).
  • step E6b the operation stops because an error is set on the scenario.
  • step E6c the source audit scenario is complete and the last action of the scenario is to chain the following scenario, depending on the requested operation.
  • Figure 6 schematizes the "target audit" scenario that begins with the ElO step that is triggered by a previous scenario. This step allows the launch of an inventory on the workstation 15a.
  • the inventory is specific to the migration because there is in addition to usual information, the list of users 21 of the workstation
  • step EI1 it is found that the inventory in the inventory server 7 is completed, so, we position the action 26EOK.
  • step E12a PostAction at 26EOK
  • the necessary data is imported into the database 3 of the synchronization server 1.
  • the 26EOK action executes a Post-Action whose last analysis analyzes the capacity of the station to be migrated.
  • Step E12b is a test to check if workstation 15a supports the tested prerequisites.
  • Step E14 is performed on the web site of the synchronization server by the requester 19 of the migration operation enabling him to unblock the situation when the technical operations of the preceding step are completed. This allows you to reset the prerequisite error message and specify that the extension has been updated by a SetAction (POST_MIS_AJOUR).
  • Step E15 is a new check of the technical prerequisites that returns to the step ElO.
  • step E16 which simply informs the synchronization server 1 via a SetAction (AUDIT_OK).
  • step E17 the target audit scenario is completed and the last action of the scenario consists in following the following scenario, depending on the requested operation.
  • FIG. 7 schematizes the "pre-validation" scenario which consists in choosing the users 21 to migrate, and among them choosing a principal, entering the user's login / pwd 21, specifying the list of extensions to be backed up, and determining the volume potentially generated by the backup of data and parameters.
  • Step E20 is a transmission of a message to the requestor 19 of the migration operation asking it to establish the user list 21 of the stations 15a to 17c in a state to migrate, to define the main user 21, and to choose the Extension profile.
  • the step E21 is performed by the requestor 19 of the migration operation on the website of the synchronization server 1, triggered by an opening of the message by the requestor 19 and a click on the proposed URL.
  • Each requestor 19 performs the following actions: selects the profiles to be migrated from the list of profiles found by the inventory, selects the main profile among the profiles to be migrated, validate the list of extensions to save, and specify the data backup path. This validation ends with a SetAction (CHOIXJJSER) that performs a PostAction.
  • CHOIXJJSER SetAction
  • Step E22 is a PostAction of step E21. This step consists in generating a message to the main user of the station 15a chosen by the requestor 19. This electronic message will contain information on the current migration process.
  • the step E23 is performed by the user 21, who using the URL contained in the message generated in the previous step enters his login / password of the station 15a.
  • This entry is stored in the database 3 of the synchronization server 1 in encrypted form. It ends with a SetAction (PWD_REGISTER).
  • PWD_REGISTER a SetAction
  • PostAction sends a message to the requester 19 allowing him to add new directories or extensions to the default ones.
  • the user 21 finds information on his profile (telephone, office number, floor, etc.). It can of course supplement or modify some of them. In addition, further information on the migration process may be provided to the user 21.
  • the step E24 concerns the determination or calculation of the size potentially generated by the backup of the data and parameters and the setting of the result in the database 3 of the synchronization server.
  • the client of the synchronization server MMBSSvc.exe generates the configuration file according to a model deposited on the workstation 15a of the user 21 and modifies the command line to take into account all the data of the users 21 (profile, parameters) and a data analysis command to save Pre-scan.cmd command is executed.
  • the pre-validation scenario is completed and the last action of the scenario consists in following the following scenario, depending on the requested operation.
  • FIG. 8 schematizes the validation scenario that enables the requestor 19 of the migration operation to validate that the volume of the data to be backed up is not too great and to choose the software to be reinstalled from those available. There is no recovery for this scenario. If the requestor 19 considers that the volume is too large, he will negotiate with the user 21 the deletion of some large or old files and then validate.
  • Step E30 is a SetAction (Validation) triggered by a previous scenario.
  • the step E31 is a preparation for the validation by the requestor 19 of the migration operation, triggered by a periodic script (for example every night at 08:00).
  • a script runs on the synchronization server 1. It provides a report by email to the requestor 19 which includes a URL allowing the requestor 19 to validate the data entered or automatically recorded in the database 3 of the synchronization server 1.
  • the requestor 19 of the migration operation goes to the site to perform the validation using the URL provided in the message generated in step E31. It can validate individually or globally each request for data backup and specify the software to be restored for each workstation 15a to 17c.
  • step E33 the validation scenario is completed and the last action of the scenario consists in following the following scenario, depending on the requested operation.
  • Figure 9 schematizes the scenario of depositing an image "Ghost with light household” (Ghost Clean Up Light). This scenario allows the filing of an image in advance.
  • Step E40 SetAction (GHOST_CUL) is triggered by a previous scenario.
  • Step E41 prepares the deposition of the image (ghost) corresponding to the station 15a to be migrated.
  • the client program of the synchronization server 1 receives, in return for the GetNextAction command, the MMCLEANUP.exe LIGHT command. It runs it to make room on the storage drive.
  • MMCIeanUP.exe with a LIGHT parameter removes unnecessary files on workstation 15a (for example
  • Step E42 is the ghost deposition on the workstation 15a.
  • the cable television server 5 is asked to deposit the ghost corresponding to the workstation 15a.
  • the result of this deposit is not analyzed because this deposit simply saves time at the time of the mastering.
  • step E43 the image filing scenario is completed and the last action of the scenario consists in following the following scenario, depending on the requested operation.
  • Figure 10 shows the "start migration" scenario.
  • This scenario puts the user 21 at work during the migration of his workstation 15a. It makes it possible to communicate information about the deployment to the user 21, to ask the user 21 to remove the floppy disks, CDRom and USB peripherals from his workstation 15a. If the user 21 does not respond to the solicitation, the local correspondent 23 will have to intervene. If the local correspondent 23 does not intervene, the migration will be suspended.
  • the window will not appear.
  • the user 21 has the possibility for example up to 30 minutes before the scheduled migration time to ask to be restarted later.
  • Step E50a is triggered by a previous scenario.
  • the client of the synchronization server lpool the server to find out if the day of the migration has arrived. If the migration is not planned for this day, the customer "surrender" for a period to be specified according to technical constraints.
  • step E50b the popup is redisplayed for example every hour up to 30 minutes before the time of the migration. Then, it is the step E52 which is triggered.
  • the step E51a is executed on the station 15a of the user 21 where the client of the synchronization server 1 executes the API makes GetNextAction and in response receives the command to execute the verification script (test E51b) of presence of a floppy disk or a CDROM. If a floppy disk or a CDROM is present, we go back to step
  • step E52 the migration time is approaching, then every 5 minutes (for example) a popup asks the user 21 to do the validation requested in step E50a.
  • Step E53 is a script that runs (for example at 18h) on the synchronization server 1 for evening migrations. This script searches for stations that must migrate the same evening and are not in "STATION_PRETE" state. The list is sent by mail to the local correspondent 23 concerned who will perform the actions normally performed by the user 21 in step E50a. To make it easier for him, he will be provided with the room N 0 in which the computer 15a is located, if it is available on the directory or if the user 21 has added it during its validation. In step E54, the scenario to start the migration is complete and the last action of the scenario is to chain the following scenario, depending on the requested operation.
  • FIG 11 shows the scenario "backup of user data”.
  • This scenario saves the data and parameters of the user 21 with the MMFilList.exe tool previously deposited.
  • the mail data is copied to a remote server, in order to be transformed into Outlook (trademark) data.
  • Step E60 SetAction SAUVEDATA
  • the step E61a action returned by the GetNextAction
  • step E61b the mail data is copied to a remote server dedicated to Netscape data migration.
  • Step E62 is a looped script that queries the synchronization server 1, retrieves the identifiers whose data has been copied and migrates the data in PST format accessible by the Outlook (registered trademark) mail client.
  • step E63 the PST data is copied to a local server and will be restored later.
  • Step E64 is to save the data of the primary user and the data of the other selected profiles earlier from the found profiles. It starts with the generation of the configuration file for MMFilList.exe. During the entire backup phase, which can be long, MMFilList.exe will inform the synchronization server 1 of the station's activity (SetLog API). This step continues with a SetAction (DATASAVED).
  • step E65 the backup scenario of the data of the user 21 is finished and the last action of the scenario consists in following the following scenario, depending on the requested migration operation.
  • FIG. 12 schematizes the scenario of mastering which consists in depositing the ghost XP in place of the operating system already existing in the workstation 15a.
  • Step E71 SetAction (MASTERIZATION) is triggered by a previous scenario.
  • Step E72 is triggered by a target station. Depending on the space available in the storage disk, we run a CleanUpHeavy that will clean the disk and make a SetAction (STATIONOK).
  • Step E73 is triggered by a STATIONOK Action.
  • PostAction at SetAction STATIONOK makes a request for distribution and installation of the ghostXP to the cable TV server 5. If it has already been deposited and is still present, it is not redeposited (capacity of the package that controls CheckSum calculated on the package and on the station). Then, in step E74a, a SetAction (GHOSTOK) is performed.
  • step E74b the presence of floppy disk or CDROM is tested. If either is present in station 15a, the process is stopped in step E74c. Otherwise, the workstation 15a is remastered at step E75 with the ghost XP by MMCIone.exe previously filed.
  • Step E76 is a post-parameterization of the newly installed workstation 15a (DNS, DHCP, station name, ...) -
  • a program (MMSetAction.exe) is executed which makes contact with the synchronization server 1 .
  • step E77 the mastering scenario is completed and the last action of the scenario consists in following the following scenario, depending on the requested migration operation.
  • Figure 13 schematizes the scenario “re-installation of software", where step E80a is a SetAction (SOFTWARE REINSTALLATION).
  • Step E80b is a local administrator logon with read rights on the "Active Directory Domain.”
  • station 15a waits, but synchronization server 1 initiates the process of software reinstallation.
  • Step E82 is a "PostAction to REPLACING LICENSE" which searches the database for the next software to reinstall.
  • the synchronization server 1 requests Tivoli to distribute a distributable software by Tivoli.
  • the step E83b the synchronization server 1 requests the distribution server 5 the distribution of distributable software by the first distribution server 5
  • step E83b it is a matter of copying software from an available network disk.
  • Step E84a all software is installed, then the scenario stops at step E84b.
  • Step E85a is a test to check if there is a need for a reboot. If it is not necessary to restart, then we go to step E82 and if it is necessary to restart then we go to step E85b to prepare the restart before returning to step E80b.
  • step E86 the scenario of software re-installation is completed and the last action of the scenario consists in following the following scenario, depending on the requested operation.
  • Figure 14 schematizes the scenario of "restoring user data”. This scenario consists of restoring all user data and completing the Office and Outlook (registered trademarks) installations.
  • Step E90 is a SetAction (RESTAURATION_DATA). Then, in step E91, the restoration of the user data is executed (RestoreMMFilList.exe).
  • Step E92 is a restoration of the converted messaging data from Netscape (registered trademark) to Outlook (registered trademark). It is searched on the local server if there is converted mail data for this user 21. If yes, they are copied to the workstation 15a.
  • Step E93 restarts workstation 15a with the main user account, Restore settings software restarts to complete the tasks specific to the user 21.
  • step E94 we launch Outlook, the standard post-configuration to the company is done, the mail profile is migrated and then we close Outlook.
  • step E96 the data restoration scenario is completed and the last action of the scenario consists in following the following scenario, depending on the requested operation. Steps E93 and E94 are repeated as many times as there are users 21.
  • Figure 15 schematizes the "survey" scenario which has three objectives.
  • the first objective is to advance the tools by analyzing the feeling of the users 21, the second objective is to validate the end of the migration by the user 21 and the third objective is to delete the data saved before the migration to make the place in the storage disk.
  • Step ElOOa is a SetAction (SURVEY).
  • Step ElOOb is a SetAction (SURVEY).
  • a script running on the synchronization server generates and sends an email to the user that contains access to a URL.
  • the user 21 answers the questions asked on the URL sent in the previous mel.
  • the questions preferably simple and few, relate to the migration and not to the use of the new version of the operating system. However, the user will have a free input area to comment on, which will be routed to either the Migration Team or the Master Design Team.
  • Step E102 is a reading of Verbatim entered by the user 21.
  • the step E103 is an automatic (for example daily) collection of the results and sending a report to the person responsible or the requestor 21 of the migration operation. Proceed to step E105a where users who validate that their data has been successfully restored can delete the backups.
  • step E106 it is considered that the operation is complete.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé et un système de migration d'un système d'exploitation et des applications depuis au moins un serveur vers au moins un ordinateur connecté audit serveur par l'intermédiaire d'un réseau d'information (13), comportant un serveur de synchronisation (1) en liaison avec des serveurs de télédistribution (5), d'inventaire (7) et de sauvegarde (9) destinés à réaliser la migration par un enchaînement automatique d'un ensemble d'étapes organisées en fonction de données initiales et/ou d'une interactivité entre ledit ordinateur (15a) et lesdits serveurs et comportant une initialisation dudit ordinateur, une analyse dudit ordinateur pour vérifier s'il est apte à supporter la migration, et un chargement dudit système d'exploitation et desdites applications dans ledit ordinateur.

Description

Système et procédé de migration d'un système d'exploitation, des données d'utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur.
Domaine technique de l'invention
L'invention se rapporte au domaine de la migration de postes de travail d'entreprises disposant d'un parc important d'ordinateurs, et plus particulièrement dans le domaine de la migration d'un système d'exploitation, des données d'utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur.
Arrière-plan de l'invention
D'une manière générale, la migration des postes de travail par exemple d'un système Windows (marque déposée) à un autre est réalisé manuellement, à l'aide de CDROM contenant les masters des postes.
Avant la migration, il est nécessaire à un technicien de faire poste après poste, une analyse des caractéristiques d'un poste (données à sauvegarder, paramètres imprimantes, connexions réseau, logiciels installés, etc.), de sauvegarder ces données manuellement, de changer de système d'exploitation, puis de restaurer les données et paramètres. L'ensemble de ces tâches nécessite plusieurs heures de travail à un technicien expérimenté pour installer un poste de travail. La centralisation du suivi de l'état des migrations et des bilans n'existe que par l'alimentation de fichiers mis à jour manuellement. Cependant, certains éditeurs, par exemple Symantec (marque déposée), proposent des outils centralisés de mise à jour d'un système d'exploitation, mais ces outils ne se préoccupent absolument pas des données et paramètres des utilisateurs.
Par ailleurs, d'autres éditeurs, par exemple Microsoft (marque déposée), fournissent quelques outils se préoccupant des données et paramètres mais ces outils ne sont pas complets, sont très complexes et ne sont utilisables que manuellement.
Objet et résumé de l'invention L'invention a pour but de remédier à ces inconvénients en centralisant et en automatisant la migration de postes de travail.
Ces buts sont atteints grâce à un procédé pour faire migrer un système d'exploitation, des données utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur connecté audit serveur par l'intermédiaire d'un réseau d'information, la migration est réalisée par un enchaînement automatique d'un ensemble d'étapes organisées en fonction de données initiales et/ou d'une interactivité entre ledit ordinateur et ledit serveur, lesdites étapes comportant les étapes suivantes : -initialisation dudit ordinateur, -analyse dudit ordinateur pour vérifier s'il est apte à supporter la migration, et
-chargement dudit système d'exploitation, desdites données utilisateurs, et desdites applications dans ledit ordinateur.
Ainsi, le procédé selon l'invention permet une migration centralisée et entièrement automatisée d'une pluralité de postes de travail réduisant alors le temps de la mise en oeuvre de cette migration.
Avantageusement, lorsqu'une étape suivante doit être exécutée à la suite d'une étape précédente, ladite étape précédente comprend une dernière commande permettant d'enclencher un démarrage automatique de l'étape suivante.
Ainsi, l'automaticité de la migration est réalisée de manière simple et permet de suivre le déclenchement successif des étapes et de reprendre en cas d'erreur.
Selon une particularité de l'invention, les données initiales sont enregistrées par un demandeur de l'opération de migration dans une base de données d'un serveur de synchronisation et comprennent un type de migration, des dates d'exécutions des étapes, et les noms dudit ordinateur et/ou de son/ses utilisateurs.
Ainsi, les différentes étapes sont planifiées à l'avance pour permettre une migration réussie et rapide.
Selon un premier aspect de l'invention, l'initialisation est réalisée par un enchaînement automatique d'un premier ensemble d'étapes élémentaires comprenant ;
-demande faite par le serveur de synchronisation à un serveur de télédistribution d'installer sur ledit ordinateur un programme nécessaire audit type de migration,
-installation dudit programme sur ledit ordinateur par le serveur de télédistribution,
-exécution dudit programme par le serveur de télédistribution, et -déclenchement par le serveur de synchronisation d'une étape suivante en fonction dudit type de migration.
Ainsi, l'ordinateur à migrer est bien préparé pour subir les différentes étapes de la migration.
Selon un deuxième aspect de l'invention, l'analyse dudit ordinateur comprend un enchaînement automatique d'un deuxième ensemble d'étapes élémentaires comprenant :
-faire un inventaire dudit ordinateur et enregistrement dudit inventaire dans la base de données du serveur de synchronisation, ledit inventaire comprenant des listes d'applications installées, et/ou du ou des profils du ou des utilisateurs, et des paramètres techniques et de localisation dudit ordinateur, et
-déclenchement par le serveur de synchronisation d'une étape suivante en fonction du type de migration. Ainsi, on peut facilement vérifier si l'ordinateur est apte à supporter les outils de migration et s'il existe au moins un profil utilisateur sur l'ordinateur.
Selon un troisième aspect de l'invention, l'analyse dudit ordinateur comprend en outre un enchaînement automatique d'un troisième ensemble d'étapes élémentaires comprenant : -analyse de la capacité dudit ordinateur à supporter la migration, -information envoyée au serveur de synchronisation pour interrompre le processus automatique, au cas où ledit ordinateur ne présente pas la capacité nécessaire à la migration jusqu'à ce q'une modification dudit ordinateur lui permette de supporter la migration, -relancement du processus automatique lorsque ledit ordinateur dispose de la capacité à supporter ledit système d'exploitation, et -déclenchement par le serveur de synchronisation d'une étape suivante en fonction du type de migration.
Ainsi, on peut arrêter ou relancer de manière automatique l'opération de migration selon la variation de la capacité de l'ordinateur à supporter les outils de migration.
Selon un quatrième aspect de l'invention, le chargement dudit système d'exploitation dans ledit ordinateur comprend un enchaînement automatique d'un quatrième ensemble d'étapes élémentaires comprenant :
-nettoyage du disque de stockage dudit ordinateur pour faire une place pour déposer une image dudit système d'exploitation par une suppression de fichiers inutiles connus dans la base de données du serveur de synchronisation,
-dépôt de ladite image dudit système d'exploitation dans ledit disque de stockage dudit ordinateur, et -déclenchement par le serveur de synchronisation d'une étape suivante en fonction du type de migration. Ainsi, on prépare de manière sécurisée et efficace l'ordinateur pour lui permettre d'accueillir une image par avance.
Avantageusement, le dépôt de ladite image dudît système d'exploitation dans ledit disque de stockage dudit ordinateur est réalisé par le serveur de télédistribution en communiquant audit ordinateur le nom d'un ordinateur dépositaire de ladite image appartenant à un même réseau local dudit ordinateur et ayant précédemment téléchargé ladite image, ou en communiquant audit ordinateur l'adresse d'un lieu de stockage central comportant ladite image si ledit réseau local ne comporte pas un autre ordinateur ayant précédemment téléchargé ladite image.
Ainsi, on peut déposer de manière sécurisée et rapide un grand volume de données sur tous les ordinateurs à migrer sans saturer les réseaux d'informations.
Selon un cinquième aspect de l'invention, le procédé comprend en outre une étape de préparation d'une sauvegarde de données du ou desdits utilisateurs comprenant un enchaînement automatique d'un cinquième ensemble d'étapes élémentaires comprenant : -choix par ledit demandeur de l'opération de migration de profils à sauvegarder parmi des profils trouvés sur ledit ordinateur, -choix par ledit demandeur de l'opération de migration des applications utiles à réinstaller après la migration, parmi des applications trouvées sur ledit ordinateur et/ou parmi une liste d'applications disponibles, -détermination du volume de stockage nécessaire pour sauvegarder des données correspondant au(x) profil(s) et application(s) choisis. -réservation par le serveur de synchronisation dudit volume de stockage sur un serveur de sauvegarde, et
-déclenchement par le serveur de synchronisation d'une étape suivante en fonction du type de migration. Ainsi, on peut choisir le volume de données à sauvegarder selon la capacité de l'ordinateur de sauvegarde et selon l'importance de ces données.
Selon un sixième aspect de l'invention, le procédé comprend en outre une étape de sauvegarde des données du ou des utilisateurs comprenant un enchaînement automatique d'un sixième ensemble d'étapes élémentaires comprenant :
-information de l'utilisateur du début de l'étape de sauvegarde afin de l'inviter à fermer ses applications et clore sa session, -vérification que ledit ordinateur ne contient aucun élément de stockage externe amorçable et, dans le cas contraire, émission d'une alerte invitant l'utilisateur à retirer ledit élément de stockage externe amorçable,
-redémarrage dudit ordinateur,
-sauvegarde des données du ou des utilisateurs sur ledit serveur de sauvegarde, et
-déclenchement par le serveur de synchronisation d'une étape suivante en fonction du type de migration.
Ainsi, toutes les précautions sont prises pour permettre une migration réussie. Selon un septième aspect de l'invention, le chargement dudit système d'exploitation dans ledit ordinateur comprend en outre un enchaînement automatique d'un septième ensemble d'étapes élémentaires comprenant :
-chargement dudit système d'exploitation dans ledit disque de stockage dudit ordinateur,
-réalisation d'un paramétrage déterminé dudît ordinateur, et
-déclenchement par le serveur de synchronisation d'une étape suivante en fonction du type de migration.
Ainsi, la mastérisation de l'ordinateur est réalisée de manière rapide et efficace. Selon un huitième aspect de l'invention, le procédé comprend en outre une étape de restauration des données sauvegardées comprenant un enchaînement automatique d'un huitième ensemble d'étapes élémentaires comprenant :
-stockage des données sauvegardées sur ledit ordinateur, -vérification de la qualité des données sauvegardées, et -déclenchement par le serveur de synchronisation d'une étape suivante en fonction du type de migration. Ainsi, l'efficacité et la qualité de la restauration des données sauvegardées sont optimales.
Selon un neuvième aspect de l'invention, le procédé comprend en outre une étape d'installation desdites applications utiles choisies par ledit demandeur de migration avant et/ou après la restauration desdites données sauvegardées comprenant un enchaînement automatique d'un neuvième ensemble d'étapes élémentaires comprenant : -demande par le serveur de synchronisation au serveur de télédistribution de l'installation d'une première application sur ledit ordinateur, -vérification par le serveur de synchronisation de la bonne installation de ladite application, et réalisation d'un nombre déterminé de tentatives au cas où l'installation a échoué,
-demande par le serveur de synchronisation au serveur de télédistribution de l'installation d'une application suivante sur ledit ordinateur, -recommencer les deux dernières étapes jusqu'à la réinstallation de toutes les applications choisies par ledit demandeur de l'opération de migration, et
-déclenchement par le serveur de synchronisation d'une étape suivante de fin d'opération ou de déclaration d'anomalie.
Ainsi, toutes les applications nécessaires sont installées permettant de restituer un poste de travail à l'utilisateur, dans un bon état de fonctionnement en ayant récupéré un maximum d'informations de la version précédente.
L'invention vise aussi un programme informatique conçu pour mettre en œuvre le procédé selon les caractéristiques ci-dessus lorsqu'il est exécuté par un système informatique.
L'invention vise aussi un système de migration d'un système d'exploitation et des applications depuis au moins un serveur vers au moins un ordinateur connecté audit serveur par l'intermédiaire d'un réseau d'information, comportant un serveur de synchronisation en liaison avec des serveurs de télédistribution, d'inventaire et de sauvegarde destinés à réaliser la migration par un enchaînement automatique d'un ensemble d'étapes organisées en fonction de données initiales et/ou d'une interactivité entre ledit ordinateur et lesdits serveurs et comportant une initialisation dudit ordinateur, une analyse dudit ordinateur pour vérifier s'il est apte à supporter la migration, et un chargement dudit système d'exploitation et desdites applications dans ledit ordinateur.
Brève description des dessins
D'autres particularités et avantages de l'invention ressortiront à la lecture de la description faite, ci-après, à titre indicatif mais non limitatif, en référence aux dessins annexés, sur lesquels :
-la figure 1 illustre un système de migration de postes de travail réalisant la migration d'un système d'exploitation et des applications depuis au moins un serveur vers au moins un ordinateur connecté audit serveur par l'intermédiaire d'un réseau d'information, selon l'invention ;
-les figures 2 et 3 illustrent des exemples décrivant les descriptions d'un scénario et d'une opération de migration dans une base de donnée d'un serveur de synchronisation, selon l'invention ; et -les figures 4 à 15 illustrent schématiquement des organigrammes des différentes étapes réalisables dans plusieurs types d'opérations de migration, selon l'invention.
Description détaillée de modes de réalisation
Conformément à l'invention, la figure 1 illustre un exemple d'un système de migration de postes de travail réalisant la migration d'un système d'exploitation et des applications depuis au moins un serveur vers au moins un ordinateur connecté audit serveur par l'intermédiaire d'un réseau d'information.
Plus particulièrement, cet exemple comporte un serveur de synchronisation 1 comportant une base de données 3, un serveur de télédistribution 5, un serveur d'inventaire 7, un serveur de sauvegarde 9 et éventuellement un lieu de stockage central 11. Ces serveurs sont en liaison à travers un réseau d'informations 13 avec une pluralité de stations de travail ou d'ordinateurs 15a à 15c, et 17a à 17c qui peuvent être répartis sur un ensemble de réseaux d'informations locaux distincts 15 et 17 respectivement.
La migration d'une station de travail associé à un ordinateur déterminé 15a (c'est-à-dire un ordinateur à migrer) est réalisée par un enchaînement automatique d'un ensemble d'étapes (appelées aussi scénarios) organisées en fonction de données initiales et/ou d'une interactivité entre l'ordinateur déterminé 15a et les serveurs 1, 5, 7, 9. Les données initiales peuvent être enregistrés dans la base de données 3 du serveur de synchronisation 1 par un demandeur 19 de l'opération de migration et peuvent comprendre le type de migration, les dates d'exécutions des étapes, et les noms de l'ordinateur déterminé 15a et/ou de son ou ses utilisateurs 21.
En effet, il peut exister plusieurs types d'opérations de migration et chaque opération de migration peut comporter plusieurs étapes ou scénarios. Ainsi, une opération de migration peut être une migration pour un utilisateur sur la même machine d'ordinateur, ou une migration pour un utilisateur sur une machine d'ordinateur nouvelle, ou la mastérisation d'une station de travail à reconstruire, ou la mastérisation d'une station de travail pour un nouvel utilisateur.
D'une manière générale, l'objectif de la migration est de restituer un poste de travail à l'utilisateur, dans un bon état de fonctionnement en ayant récupéré un maximum d'informations de la version précédente. Ainsi, une opération de migration est un ensemble d'étapes ou scénarios destinés à répondre à toutes les problématiques pouvant être rencontrés durant le procédé de migration. En générale, les étapes ou scénarios d'une opération de migration comportent une initialisation de l'ordinateur 15a, une analyse de l'ordinateur 15a pour vérifier s'il est apte à supporter la migration, et un chargement du système d'exploitation et des applications dans cet ordinateur 15a.
Un scénario est une succession de tâches (appelées aussi étapes élémentaires), chaque tâche étant un travail à exécuter sur un acteur ou système informatique (par exemple les serveurs 1, 5, 7, 9, la base de données 3, l'ordinateur 15a) impliqué dans le procédé de migration pour produire une certaine action. Ainsi, une action est un statut résultant d'une étape élémentaire. Par ailleurs, une post-action est un programme exécuté depuis le serveur de synchronisation 1 suite à la survenance d'une action (exemple ; envoyer un e-mail). Une post-action peut elle avoir la charge d'exécuter une étape élémentaire faisant avancer le statut (l'action).
Ainsi, un scénario peut être défini sur un ou plusieurs acteurs (par exemple 1, 3, 5, 9, 11, 15a) et une opération de migration est alors une succession de scénarios s'enchaînant automatiquement grâce au serveur de synchronisation 1. En effet, lorsqu'un scénario suivant (étape suivante) doit être exécutée à la suite d'un scénario précédent (étape précédente), le scénario précédent comprend une dernière commande ou tâche permettant d'enclencher un démarrage automatique du scénario suivant. Ainsi, le serveur de synchronisation 1 comporte un premier programme capable de réaliser les programmes appelés par les postactions. Il comporte aussi un deuxième programme (par exemple API SetAction) appelable depuis tout point du réseau d'information 13 capable de prendre en compte les avancements de statut émis par les acteurs (systèmes informatiques) afin de mettre à jour la base de données 3 comprise dans le serveur de synchronisation 1.
Le serveur de synchronisation 1 comporte aussi un troisième programme appelable depuis tout point du réseau d'information 13 et capable de déterminer la prochaine action à communiquer lors d'une sollicitation par un acteur (par exemple API GetNextAction). Ainsi, lorsque par exemple I1API GetNextAction est appelée, elle contrôle que l'action n'est pas la dernière du scénario. Sinon, elle exécute un SetAction sur la première action décrite dans le scénario suivant.
De plus, le serveur de synchronisation 1 comporte un quatrième programme appelable depuis tout point du réseau d'information 13 et capable de stopper le procédé de migration en cas d'erreur (par exemple API SetLastError).
Par ailleurs, la base de données 3 du serveur de synchronisation 1 comporte la description des scénarios (c'est-à-dire les actions ou étapes élémentaires et leurs enchaînements), la description des opérations de migration (c'est-à-dire les scénarios et l'ordre de déroulement de ces scénarios en fonction de l'opération de migration), et la description d'une opération particulière demandée par le demandeur 19 de l'opération de migration. II est aussi nécessaire d'avoir d'autres programmes qui s'exécutent sur les acteurs (systèmes informatiques) et qui doivent être capable de réaliser les étapes élémentaires et d'avertir le serveur de synchronisation 1 de la réussite ou de l'échec d'une tâche en informant systématiquement le programme du serveur de synchronisation 1 (par exemple API SetAction).
En effet, la figure 2 montre la description d'un scénario dans la base de donnée 3 du serveur de synchronisation 1.
La case Cl représente une description d'un premier scénario, la case C2 est le nom du scénario, la case C3 est la description des actions avec les numéros de l'ordre d'exécution, la case C4 est le nom de l'action et si la première action est nommée comme le scénario alors la case C5 exprime le nommage d'une post-action. La case C6 indique que le numéro de l'action précédente est inexistant si, c'est la première action du scénario. La case C7 indique que le numéro de l'action suivante est inexistant si, c'est la dernière action du scénario. La case C8 est un nommage de l'action suivante, la case C9 est le numéro de l'action précédente, et la case ClO indique que le numéro de l'action suivante est inexistant si, c'est la dernière action du scénario. Tant qu'il existe des actions à décrire, on boucle entre les cases C8 et ClO. La case CIl est un test pour vérifier s'il y a d'autres scénarios. Si oui, la case C12 décrit la description du scénario suivant avant de boucle à la case C2. En revanche, s'il n' y a pas d'autres scénarios, alors la case C13 indique la fin du scénario. De même, la figure 3 montre la description d'une opération de migration dans la base de donnée 3 du serveur de synchronisation 1.
La case C21 représente une description de l'opération et la case C22 indique un ajout d'un premier scénario. La case C23 est un test pour vérifier s'il faut ajouter un autre scénario. Si oui, on ajoute un scénario suivant à la case C24 avant de revenir au test C23. En revanche, s'il n' y a pas d'autres scénarios à ajouter, alors la case C25 indique la fin de l'opération de migration.
Ainsi, le serveur de synchronisation 1 et sa base de données 3 permettent de planifier les étapes élémentaires, de suivre l'exécution de ces étapes élémentaires, de déclencher l'étape élémentaire suivante et de reprendre en cas d'erreur.
Dans la suite, on décrit plusieurs scénarios sachant que chaque scénario peut être utilisé dans plusieurs types d'opérations de migration. Un premier scénario est un scénario « d'initialisation » pour préparer l'ordinateur 15a à subir les actions à réaliser en lui déposant par le serveur de télédistribution 5 les programmes d'initialisation nécessaires pour la migration.
Ainsi, le scénario d'initialisation est réalisé par un enchaînement automatique d'un premier ensemble d'étapes élémentaires.
Une première étape élémentaire est la demande faite par le serveur de synchronisation 1 au serveur de télédistribution 5 d'installer sur l'ordinateur déterminé 15a un programme nécessaire au type de migration indiqué dans les données initiales. Une seconde étape élémentaire est l'installation de ce programme sur l'ordinateur déterminé 15a par le serveur de télédistribution 5.
Une troisième étape élémentaire concerne l'exécution de ce programme par le serveur de télédistribution 5, avant le déclenchement par le serveur de synchronisation 1 d'une étape élémentaire suivante en fonction du type de migration demandé.
Par ailleurs, l'analyse de l'ordinateur déterminé 15a peut être réalisée par deux scénarios appelés « audit source », et « audit cible ».
Le scénario audit source consiste à analyser l'ordinateur 15a pour vérifier que celui-ci est apte à supporter les outils de migration et qu'il existe au moins un profil utilisateur 21 sur le poste d'ordinateur 15a.
Ce scénario d'audit source comprend un enchaînement automatique d'un deuxième ensemble d'étapes élémentaires. Dans une première étape élémentaire, l'ordinateur déterminé
15a fait un inventaire qui est ensuite enregistré dans la base de donnée 3 du serveur de synchronisation 1. Cet inventaire peut comprendre des listes des applications ou logiciels installés, et/ou du ou des profils du ou des utilisateurs 21, et des paramètres techniques et de localisation géographique de l'ordinateur déterminé 15a.
Une deuxième étape élémentaire concerne le déclenchement par le serveur de synchronisation 1 d'une étape suivante en fonction du type de migration.
En outre, le scénario audit cible consiste aussi à analyser l'ordinateur 15a ou la station de travail pour vérifier que celle-ci est apte à supporter les outils de migration. De plus, on vérifie également que le type d'ordinateur correspond réellement à celui qui a été demandé.
Ce scénario d'audit cible comprend un enchaînement automatique d'un troisième ensemble d'étapes élémentaires. Dans une première étape élémentaire du scénario audit cible, l'ordinateur 15a analyse sa capacité à supporter la migration. Ensuite, dans une deuxième étape élémentaire, l'ordinateur 15a envoi une information au serveur de synchronisation 1 pour interrompre le processus automatique, au cas où l'ordinateur 15a ne présente pas la capacité nécessaire à la migration. Le processus est interrompu jusqu'à ce qu'une modification de l'ordinateur 15a lui permette de supporter la migration.
Le serveur de synchronisation 1 interroge régulièrement sa base de données 3 qui comporte l'inventaire. Ainsi, dans une troisième étape élémentaire, le serveur de synchronisation 1 relance le processus automatique lorsque l'ordinateur 15a dispose de la capacité à supporter le système d'exploitation. Ensuite, le serveur de synchronisation 1 déclenche une étape suivante en fonction du type de migration.
Par ailleurs, le chargement du système d'exploitation dans l'ordinateur 15a comprend un premier scénario consistant à déposer une image du système d'exploitation sur l'ordinateur 15a et un second scénario de mastérisation. On notera que, les données et paramètres de l'utilisateur doivent être sauvegardés avant le scénario de mastérisation.
Le scénario de dépôt de l'image permet le dépôt sur l'ordinateur 15a d'une image « ghost » par avance sachant que le résultat de la distribution importe peu car il sera redistribué si nécessaire au dernier moment.
Ce scénario de dépôt de l'image comprend un enchaînement automatique d'un quatrième ensemble d'étapes élémentaires.
Selon une première étape élémentaire et grâce au programme déposé et exécuté au scénario d'initialisation, l'ordinateur 15a procède à un nettoyage de son disque de stockage par de suppression de fichiers inutiles (par exemple les .bak, .tmp, et ~*) connus dans la base de données 3 du système de synchronisation 1. Ceci afin de faire une place pour déposer l'image du système d'exploitation donnant ainsi au scénario un maximum de chance de réussir. Ensuite, l'image du système d'exploitation est déposée en pair-à-pair par le serveur de télédistribution 1 dans le disque de stockage de l'ordinateur 15a avant le déclenchement par le serveur de synchronisation 1 d'une étape suivante en fonction du type de migration. Avantageusement, le dépôt de l'image du système d'exploitation dans le disque de stockage de l'ordinateur déterminé 15a est réalisé par le serveur de télédistribution 5 en communiquant à cet ordinateur déterminé 15a le nom d'un ordinateur dépositaire de l'image (par exemple 15b) appartenant au même réseau local 15 que l'ordinateur déterminé 15a et ayant précédemment téléchargé cette image. Cependant, au cas où le réseau local 15 ne comporte pas un autre ordinateur ayant précédemment téléchargé cette image, alors le serveur de télédistribution 5 communique à l'ordinateur déterminé 15a l'adresse du lieu de stockage central 11 comportant cette image. Ensuite, le procédé comprend un scénario de « validation ». Ce scénario permet au responsable ou demandeur 19 de l'opération de migration de valider que le volume des données à sauvegarder n'est pas trop important et de choisir les applications ou logiciels à réinstaller parmi ceux disponibles. II n'y a pas de reprise possible pour ce scénario. Si le demandeur 19 de l'opération de migration considère que le volume est trop important, il négociera avec l'utilisateur 21 la suppression de certains fichiers volumineux ou anciens et validera ensuite.
Ce scénario de validation consiste alors à préparer la sauvegarde de données du ou des utilisateurs 21 et comprend un enchaînement automatique d'un cinquième ensemble d'étapes élémentaires.
Selon une première étape élémentaire le demandeur 19 de l'opération de migration choisit les profils à sauvegarder parmi les profils trouvés sur l'ordinateur 15a. Ensuite, il choisit les applications utiles à réinstaller après la migration, parmi des applications trouvées sur l'ordinateur et/ou parmi un catalogue ou liste d'applications disponibles.
Une étape élémentaire suivante consiste en la détermination par l'ordinateur 15a, du volume de stockage nécessaire pour sauvegarder des données correspondant au(x) profil(s) et application(s) choisis et il en informe la base de données 3 du serveur de synchronisation 1.
Ensuite, le serveur de synchronisation 1 réserve ce volume de stockage sur le serveur de sauvegarde 9, avant de déclencher une étape élémentaire suivante en fonction du type de migration. Avantageusement, le procédé comprend un scénario de « sauvegarde des données et paramètres de l'utilisateur » en copiant si nécessaire les données de messagerie sur un serveur distant (non représenté). Ce scénario de sauvegarde des données du ou des utilisateurs
21 comprend un enchaînement automatique d'un sixième ensemble d'étapes élémentaires.
Selon une première étape élémentaire, l'ordinateur 15a informe l'utilisateur 21 du début de l'étape de sauvegarde afin de l'inviter à fermer ses applications et clore sa session. Ensuite, l'ordinateur 15a vérifie qu'il ne contient aucun élément de stockage externe amorçable (CDRom, disquette). Dans le cas contraire, l'ordinateur 15a émet une alerte invitant l'utilisateur 21 à retirer de l'ordinateur 15a l'élément de stockage externe amorçable. Les étapes élémentaires suivantes concernent un redémarrage de l'ordinateur 15a et la sauvegarde par l'ordinateur 15a, des données du ou des utilisateurs 21 sur le serveur de sauvegarde 9. Ensuite, le serveur de synchronisation 1 déclenche une étape élémentaire suivante en fonction du type de migration.
Ainsi, après que les données et paramètres de l'utilisateur soient sauvegardés, le scénario de mastérisation permet de mastériser l'ordinateur 15a, c'est-à-dire de déposer le nouveau système d'exploitation en lieu et place de celui déjà présent.
Ce scénario de mastérisation comprend un enchaînement automatique d'un septième ensemble d'étapes élémentaires. Selon une première étape élémentaire et grâce au programme déposé et exécuté au scénario d'initialisation, l'ordinateur 15a procède à un chargement du système d'exploitation dans son disque de stockage. De même, grâce au programme d'initialisation, l'ordinateur 15a réalise un paramétrage déterminé, (plus précisément un post-paramétrage) de l'ordinateur 15a. Ensuite, le serveur de synchronisation 1 déclenche une étape élémentaire suivante en fonction du type de migration.
En outre, le procédé comprend un scénario de « restauration des données » qui consiste à restaurer l'ensemble des données de ou des utilisateurs. Ce scénario de restauration des données sauvegardées comprend un enchaînement automatique d'un huitième ensemble d'étapes élémentaires.
Au départ, l'ordinateur 15a procède à un stockage des données sauvegardées et après il vérifie la qualité des données sauvegardées. Ensuite, le serveur de synchronisation 1 déclenche une étape suivante en fonction du type de migration.
Par ailleurs, le procédé comprend un scénario de réinstallation des applications utiles ou logiciels choisies par le demandeur 19 de migration après ou avant la restauration des données sauvegardées des utilisateurs 21.
Ce scénario comprend un enchaînement automatique d'un neuvième ensemble d'étapes élémentaires.
Selon une première étape élémentaire, le serveur de synchronisation 1 demande au serveur de télédistribution 5 d'installer une première application sur l'ordinateur 15a.
Selon une deuxième étape élémentaire le serveur de synchronisation 1 vérifie la bonne installation de l'application. Au cas où l'installation a échoué, le serveur de synchronisation 1 réalise d'autres tentatives (par exemple deux autres tentatives). A une troisième étape élémentaire le serveur de synchronisation 1 demande au serveur de télédistribution 5 d'installer une application suivante sur l'ordinateur 15a. On recommence les deuxième et troisième étapes élémentaires jusqu'à la réinstallation de toutes les applications choisies par le demandeur 19 de l'opération de migration. Ensuite, le serveur de synchronisation 1 déclenche une étape élémentaire suivante en fonction du type de migration.
On notera que le procédé de migration selon l'invention peut être mis en œuvre par une pluralité de programmes informatiques (appelée aussi programme informatique) exécutés par les différents acteurs ou système informatiques (serveur de synchronisation 1, base de données 3, serveur de télédistribution 5, serveur d'inventaire 7, serveur de sauvegarde 9, ordinateurs 15a à 17c, etc.).
La suite, est un mode particulier de réalisation de l'invention. En effet, la migration d'un parc d'ordinateurs ou de micro-ordinateurs 15a à 15c et 17a à 17c s'effectue toujours dans le cadre d'un système d'information disposant de particularités selon le contexte de l'entreprise utilisatrice du système d'information.
L'opération de migration d'un parc d'ordinateurs peut être de plusieurs types.
Un premier exemple est une opération de migration pour un utilisateur sur le même ordinateur, par exemple une migration d'une station Windows 2000 (marque déposée) à Windows XP (marque déposée). Cette opération concerne la migration d'une station pour un utilisateur. Dans cette opération, on ne change ni d'ordinateur 15a, ni d'utilisateurs 21, on récupère toutes les données des utilisateurs 21 et on permet la réinstallation de tous les logiciels disponibles initialement et dont on détient le colis d'installation. Cette première opération peut comporter dans l'ordre, les scénarios (étapes) suivants : saisie des informations nécessaires, initialisation (source), audit (source), prévalidation (source), validation (source), dépôt d'image (source) « Ghost avec CleanUp light », signaler opération (source), sauvegarde des données utilisateurs (source), mastérisatïon (cible), initialisation (cible), installation logiciels (cible), restauration des données utilisateur (cible), audit (cible), et recette/sondage.
Un deuxième exemple est une opération de migration pour un utilisateur sur un nouvel ordinateur. Cette opération concerne la migration d'une station de travail pour un utilisateur. Dans cette opération, on change d'ordinateur au cours de la migration. Les utilisateurs d'un premier ordinateur sont migres sur un second. On récupère et transfert toutes les données des utilisateurs et on permet la réinstallation de tous les logiciels disponibles initialement et dont on détient Ie colis d'installation.
Cette deuxième opération peut comporter dans l'ordre les scénarios suivants : saisie des informations nécessaires, initialisation (source), audit (source), initialisation (cible), audit (cible), prévalidation (source), validation (source), dépôt d'image (source) « Ghost avec CleanUp light », signaler opération (source), sauvegarde des données utilisateurs (source), mastérisation (cible), initialisation (cible), installation logiciels (cible), restauration des données utilisateur (cible), audit (cible), et recette/sondage.
Un troisième exemple est une opération de mastérisation d'une station de travail à reconstruire.
Cette opération concerne la mastérisation d'une station de travail pour un utilisateur. Dans cette opération, on ne connaît pas l'ordinateur ou machine initiale de l'utilisateur (il n'en avait peut être pas).
On installe, après la mastérisation de la machine, les logiciels dont il a besoin.
Cette troisième opération peut comporter dans l'ordre les scénarios suivants : saisie des informations nécessaires, initialisation (cible), audit (cible), validation (source), mastérisation (cible), initialisation (cible), installation logiciels (cible), audit (cible), et sondage. Un quatrième exemple est une opération de mastérisation d'une station de travail.
Cette opération concerne la mastérisation d'une station de travail sans objectif immédiat d'utilisation. Dans cette opération, on ne fait que préparer le poste de travail à une utilisation future. L'objectif de cette mastérisation est de disposer d'un poste de travail prêt à être mis en service lors de l'arrivée d'un nouvel utilisateur.
Cette quatrième opération peut comporter dans l'ordre les scénarios suivants ; saisie des informations nécessaires, initialisation (cible), audit (cible), mastérisation (cible), initialisation (cible), et audit (cible).
Ainsi, chaque opération de migration est un ensemble de scénarios destinés à répondre à toutes les problématiques énoncées par le processus ou déploiement de la migration. Les figures 4 à 15 illustrent schématiquement des organigrammes des différents scénarios réalisables dans les différents types d'opérations de migration.
Chaque scénario est une succession d'étapes élémentaires ou tâches nécessaires pour atteindre l'objectif fixé par le déploiement de l'opération de migration. On notera qu'un scénario ne s'exécute que pour un ordinateur déterminé et chaque scénario est réalisé de manière à être réutilisable dans plusieurs types d'opérations de migration.
La figure 4 schématise le scénario d'initialisation pour préparer l'ordinateur 15a à subir les actions de l'opération de migration, en lui déposant par télédistribution le client de télédistribution « peer to peer »
(serveur de télédistribution (5), des outils d'inventaire, le client du serveur de synchronisation 1, et des outils de clonage.
L'étape élémentaire EO est manuelle et déroule au moins la veille de la migration, de préférence ou par défaut dix jours (J-IO) avant la migration. Le déployeur ou demandeur 19 de l'opération de migration prend contact avec l'utilisateur 21 principal de la station de poste 15a à migrer, récupère son identifiant de connexion, son nom de station, le type de station et la date de migration souhaitée (jour J), il les enregistre dans la base de données 3 du serveur de synchronisation 1. II vérifie avec l'utilisateur 21 que l'utilisateur n'utilise pas de logiciels qui ne sont pas supportés par la nouvelle version (par exemple Windows XP). L'enregistrement de la demande est réalisé au travers du site Web du serveur de synchronisation 1. Cette étape se termine par un SetAction (POSTE_CREE) qui elle-même génère une demande de télédistribution auprès du serveur de télédistribution 5.
Le colis distribué est constitué du dépôt/installation du client du serveur de télédistribution 5 et du dépôt du programme spécifique MMSetaction..exeΛ A la fin de l'installation de ce client, l'installation exécute la commande MMSetAction.exe -DISTRIBUTORJNSTALLE. Cette commande est suivie d'une post-action qui exécute l'étape élémentaire suivante E2.
L'étape élémentaire E2 est automatiquement réalisée à la fin de l'installation du client du serveur de télédistribution 5. Elle concerne le dépôt par le serveur de distribution 5 des colis nécessaires pour les actions suivantes : dépôt du scanner d'inventaire ; dépôt et installation du client du serveur de synchronisation 1 ; dépôt des outils d'analyse et de migration (MMCIone.exe : outil d'installation de l'image ghost, MMProfiles.exe : outil d'analyse des profils trouvés sur le poste, MMCIeanUP.exe : outil de ménage du disque à mastériser, MMSigMigrXP.exe : outil de signalisation de l'opération à l'utilisateur final, MMInstl.exe : automate de réinstallation des logiciels, MMFileList.exe : outil de sauvegarde des données utilisateur).
A la fin de ces opérations de distribution, une commande SetAction (MMJNSTALLE) est exécutée. L'étape E3a indique que le scénario « Initialisation » est terminé et l'étape E3b est la dernière action du scénario qui consiste à enchaîner le scénario suivant, dépendant de l'opération demandée.
La figure 5 schématise le scénario « audit source » qui consiste à analyser la station de travail 15a pour vérifier que celle-ci est apte à supporter les outils de migration et qu'il existe au moins un profil utilisateur 21 sur le poste de travail 15a.
L'étape E4a est déclenchée par le scénario précédent et permet le lancement d'un inventaire sur la station de travail 15a. L'inventaire est spécifique au serveur de synchronisation car on dépose les fichiers générés par le scanner sur une ressource spécifique afin que les données soient prises en compte quasiment immédiatement par le serveur d'inventaire 7. A cette étape, on connaît la liste des logiciels installés, la liste des profils utilisateurs 21 présents sur la station de travail 15a, le type exact de la station 15a (dont on déduira le colis image (ghost XP) à déposer), les paramètres techniques de la station de travail 15a (Ram, disque, etc), et la localisation géographique de cette station 15a.
L'étape E4a est déclenchée par le serveur de synchronisation.
On constate que l'inventaire dans le serveur d'inventaire 7 est terminé et que la date d'inventaire est postérieure à la demande faite. Alors, on positionne l'action « 26EOK » (outil inventaire). Ceci garantit que l'inventaire est à jour.
A l'étape E5a (PostAction à 26EOK), on importe les données nécessaires dans la base de données 3 du serveur de synchronisation 1. L'action 26EOK exécute trois Post-Actions dont la dernière analyse la capacité de la station de travail 15a à migrer.
L'étape E5b est un test pour vérifier si la station de travail 15a supporte les pré-requis testés (par exemple la capacité de celle-ci à supporter le logiciel de sauvegarde des données et paramètres des utilisateurs). Si oui, alors on passe à l'étape E6a qui informe simplement le serveur de synchronisation 1 via un SetAction (AUDIT_OK).
Si la station de travail 15a ne supporte pas les pré-requis testés, alors on passe à l'étape E6b où l'opération s'arrête car une erreur est positionnée sur le scénario.
A l'étape E6c, le scénario audit source est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération demandée.
La figure 6 schématise le scénario « audit cible » qui commence par l'étape ElO qui est déclenchée par un scénario précédent. Cette étape permet le lancement d'un inventaire sur la station de travail 15a.
L'inventaire est spécifique à la migration car on y trouve en plus des informations habituelles, la liste des utilisateurs 21 de la station de travail
15a. A ce stade, on connaît la liste des logiciels installés, le type exact de la station de travail 15a (dont on déduira le colis ghost XP à déposer), les paramètres techniques de la station de travail 15a (RAN, disque), et la localisation géographique de la station de travail 15a (nom du sous réseau
15).
A l'étape EIl, on constate que l'inventaire dans le serveur d'inventaire 7 est terminé, alors, on positionne l'action 26EOK.
A l'étape E12a (PostAction à 26EOK), on importe les données nécessaires dans la base de données 3 du serveur de synchronisation 1. L'action 26EOK exécute un Post-Action dont la dernière analyse la capacité de la station à migrer. L'étape E12b est un test pour vérifier si la station de travail 15a supporte les pré-requis testés.
Si la station de travail 15a ne supporte pas les pré-requis testés, alors on passe à rétape E13 qui est une opération manuelle (par exemple par un déployeur local 23) consistant à rendre techniquement la station de travail 15a migrable (par exemple par ajout de mémoire) L'étape E14 est réalisée sur le site web du serveur de synchronisation par le demandeur 19 de l'opération de migration lui permettant de débloquer la situation lorsque les opérations techniques de l'étape précédente sont terminées. Ceci permet la réinitialisation du message d'erreur de pré-requis et de préciser que le poste a été mis à jour par un SetAction (POSTE__MIS_AJOUR).
L'étape E15 est une nouvelle vérification des pré-requis techniques qui retourne à l'étape ElO.
A l'issue du test E12b, si la station 15a supporte les pré-requis testés, on passe à l'étape E16 qui informe simplement le serveur de synchronisation 1 via un SetAction (AUDIT_OK).
A l'étape E17, le scénario audit cible est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération demandée. La figure 7 schématise le scénario « pré-validation » qui consiste à choisir les utilisateurs 21 à migrer, et parmi eux en choisir un principal, saisir le login/pwd de l'utilisateur 21, préciser la liste des extensions à sauvegarder, et déterminer le volume potentiellement généré par la sauvegarde des données et paramètres. L'étape E20 est une émission d'un message au demandeur 19 de l'opération de migration lui demandant d'établir la liste par utilisateurs 21 des stations 15a à 17c en état de migrer, de définir l'utilisateur 21 principal, et de choisir le profil Extension.
L'étape E21 est réalisée par le demandeur 19 de l'opération de migration sur le site web du serveur de synchronisation 1, déclenchée par une ouverture du message par le demandeur 19 et un clic sur l'Url proposée.
Chaque demandeur 19 réalise les actions suivantes : sélectionne les profils à migrer parmi la liste des profils trouvés par l'inventaire, sélectionne le profil principal parmi les profils à migrer, valider la liste des extensions à sauvegarder, et précise le chemin de sauvegarde des données. Cette validation se termine par un SetAction (CHOIXJJSER) qui réalise une PostAction.
L'étape E22 est un PostAction de l'étape E21. Cette étape consiste à générer un message à l'utilisateur 21 principal de la station 15a choisi par le demandeur 19. Ce message électronique contiendra des informations sur le processus de migration en cours.
L'étape E23 est réalisée par l'utilisateur 21, qui à l'aide de l'Url contenue dans le message généré dans l'étape précédente saisit son login/mot de passe de station 15a. Cette saisie est enregistrée dans la base de données 3 du serveur de synchronisation 1 sous forme chiffrée. Elle se termine par un SetAction (PWD_ENREGISTRE). Cette action est suivie d'une PostAction qui émet un message au demandeur 19 lui permettant d'ajouter des nouveaux répertoires ou de nouvelles extensions à ceux par défaut. Sur les pages qui suivent, l'utilisateur 21 trouve des informations sur son profil (téléphone, numéro du bureau, étage, etc). Il peut bien entendu compléter ou modifier certaines d'entre-elles. De plus, des informations complémentaires sur le processus de migration peuvent être fournies à l'utilisateur 21. L'étape E24, concerne la détermination ou le calcul de la taille potentiellement générée par la sauvegarde des données et paramètres et la mise du résultat dans la base de données 3 du serveur de synchronisation. Le client du serveur de synchronisation MMBSSvc.exe génère le fichier de configuration d'après un modèle déposé sur la station de travail 15a de l'utilisateur 21 et modifie la ligne de commande pour prendre en compte toutes les données des utilisateurs 21 (profil, paramètres) et une commande d'analyse des données à sauvegarder commande Pre-scan.cmd est exécutée. A l'étape E25, le scénario pré-validation est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération demandée.
La figure 8 schématise le scénario validation qui permet au demandeur 19 de l'opération de migration de valider que le volume des données à sauvegarder n'est pas trop important et de choisir les logiciels à réinstaller parmi ceux disponibles. Il n'y a pas de reprise possible pour ce scénario. Si le demandeur 19 considère que le volume est trop important, il négociera avec l'utilisateur 21 la suppression de certains fichiers volumineux ou anciens et validera ensuite.
L'étape E30 est une SetAction (Validation) déclenchée par un scénario précédent.
L'étape E31 est une préparation de la validation par le demandeur 19 de l'opération de migration, déclenchée par un script périodique (par exemple chaque nuit à 08h00). Ainsi, chaque nuit, un script s'exécute sur le serveur de synchronisation 1. Il fournit un état par mail au demandeur 19 qui comprend, une URL permettant au demandeur 19 de valider les données saisies ou automatiquement enregistrées dans la base de données 3 du serveur de synchronisation 1. A l'étape suivante E32, le demandeur 19 de l'opération de migration se rend sur le site pour réaliser la validation à l'aide de l'URL fournie dans le message généré à l'étape E31. Il peut valider individuellement ou globalement chaque demande de sauvegarde de données et préciser les logiciels à restaurer pour chaque station de travail 15a à 17c.
Si le volume est trop important (volume à définir individuellement, mais aussi en fonction des espaces de stockage disponibles le jour de la migration sur les serveurs locaux), il devra prendre contact avec l'utilisateur 21 principal et lui demander de faire du ménage sur son disque de stockage. Si la place disponible dans le disque de stockage n'est pas suffisante pour réaliser les migrations dans la période déterminée, il prend contact avec chaque utilisateur 21 ou changer les dates de migration afin de lisser les opérations dans le temps. A l'étape E33, le scénario validation est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération demandée.
La figure 9 schématise le scénario de dépôt d'une image « Ghost avec ménage light » ( Ghost Clean Up Light). Ce scénario permet le dépôt d'une image par avance.
L'étape E40 SetAction (GHOST_CUL) est déclenchée par un scénario précédent.
L'étape E41 prépare le dépôt de l'image (ghost) correspondent à la station 15a à migrer. Le programme client du serveur de synchronisation 1 reçoit, en retour à la commande GetNextAction, la commande MMCLEANUP.exe LIGHT. Il l'exécute pour faire de la place sur le disque de stockage. MMCIeanUP.exe avec un paramètre LIGHT supprime les fichiers non utiles sur le poste de travail 15a (par exemple
*.tmp, *.bak,...) et émet un SetAction (CLEANUPOK). La post-action de ce setAction est traitée par l'étape suivante E42.
L'étape E42 est le dépôt du ghost sur la station de travail 15a.
On demande au serveur de télédistribution 5 de déposer le ghost correspondant à la station de travail 15a. Le résultat de ce dépôt n'est pas analysé car ce dépôt permet simplement de gagner du temps au moment de la mastérisation.
A l'étape E43, le scénario de dépôt d'image est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération demandée.
La figure 10 schématise le scénario de « démarrer la migration ». Ce scénario met l'utilisateur 21 à contribution lors de la migration de son poste de travail 15a. Il permet de communiquer des informations sur le déploiement à l'utilisateur 21, de demander à l'utilisateur 21 de retirer les disquettes, CDRom et périphériques USB de son poste de travail 15a. Si l'utilisateur 21 ne répond pas à la sollicitation, c'est le correspondant local 23 qui devra intervenir. Si le correspondant local 23 n'intervient pas, la migration sera suspendue.
Elle pourra reprendre lorsque l'utilisateur 21 ou le correspondant local 23 valideront l'écran affiché sur la station de travail 15a.
Si la session Windows est fermée, la fenêtre n'apparaîtra pas. L'utilisateur 21 a la possibilité par exemple jusqu'à 30 minutes avant l'heure prévue de migration de demander à être relancé plus tard.
L'étape E50a est déclenchée par un scénario précédent. Sur le poste 15a de l'utilisateur 21, le client du serveur de synchronisation lpool le serveur pour savoir si le jour de la migration est arrivé. Si la migration n'est pas prévue pour ce jour, le client se « rendors » pour un délai à préciser selon contraintes techniques.
En revanche, si le jour de la migration est arrivé, par exemple à partir de 09h30 si la migration à lieu le matin, ou 14h00 si la migration a lieu dans la nuit, une fenêtre Popup affichée sur le bureau de l'utilisateur
21 l'informe que le jour de sa migration est arrivé. Cette Popup lui demande de retirer les disquettes, le CDROM, son PDA et tous les périphériques USB. Si l'utilisateur 21 valide (test E50b) la Popup alors on passe à l'étape suivante E51.
En revanche, s'il annule (test E50b), alors la popup est réaffichée (étape E50c) par exemple toutes les heures jusqu'à 30 minutes avant l'heure de la migration. Ensuite, c'est l'étape E52 qui est déclenchée. L'étape E51a est exécutée sur le poste 15a de l'utilisateur 21 où le client du serveur de synchronisation 1 exécute l'API fait GetNextAction et en réponse reçoit l'ordre d'exécuter le script de vérification (test E51b) de présence d'une disquette ou d'un CDROM. Si une disquette ou un CDROM est présent, on repasse à l'étape
E50a. Sinon, on réalise un SetAction (STATION_PRETE) avant de passer à l'étape E54.
A l'étape E52, l'heure de la migration approche, alors toutes les 5 minutes (à titre d'exemple) une popup demande à l'utilisateur 21 de faire la validation demandée à l'étape E50a.
L'étape E53 est un script qui s'exécute (par exemple à 18h) sur le serveur de synchronisation 1 pour les migrations du soir. Ce script recherche les stations qui doivent migrer le soir même et qui ne sont pas en état « STATION_PRETE ». La liste est envoyée par mail au correspondant local 23 concerné qui devra réaliser les actions réalisées normalement par l'utilisateur 21 à l'étape E50a. Pour lui faciliter la tâche, on lui fournira le N0 de pièce dans laquelle se trouve l'ordinateur 15a, si elle est disponible sur l'annuaire ou si l'utilisateur 21 l'a ajoutée lors de sa validation. A l'étape E54, le scénario démarrer la migration est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération demandée.
La figure 11 schématise le scénario « sauvegarde des données de l'utilisateur ». Ce scénario sauvegarde les données et paramètres de l'utilisateur 21 avec l'outil MMFilList.exe déposé précédemment. De plus, si l'utilisateur 21 est sous Netscape (marque déposée), les données de messagerie sont copiés sur un serveur distant, afin d'être transformées en données Outlook (marque déposée). L'étape E60 (SetAction SAUVEDATA) est déclenchée par un scénario précédent. L'étape E61a, (action retournée par le GetNextAction) consiste à tester si l'utilisateur 21 est sous messagerie Netscape. Si oui, (étape E61b), on copie les données de messagerie sur un serveur distant dédié à la migration des données Netscape. L'étape E62, est un script en boucle qui interroge le serveur de synchronisation 1, récupère les Identifiants dont les données ont été copiées et migre les données au format PST accessible par le client de messagerie Outlook (marque déposée).
A l'étape E63, les données PST sont copiées sur un serveur local et elles seront restaurées plus tard.
L'étape E64 consiste à sauvegarder les données de l'utilisateur 21 principal et les données des autres profils choisis plus tôt parmi les profils trouvés. Elle débute par la génération du fichier de configuration pour MMFilList.exe. Pendant toute la phase de sauvegarde, qui peut être longue, MMFilList.exe informera le serveur de synchronisation 1 de l'activité de la station (API SetLog). Cette étape se poursuit par un SetAction (DATASAVED).
A l'étape E65, le scénario de sauvegarde des données de l'utilisateur 21 est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération de migration demandée.
La figure 12 schématise le scénario de mastérisation qui consiste à déposer le ghost XP en lieu et place du système d'exploitation existant déjà dans le poste de travail 15a. L'étape E71 SetAction (MASTERISATION) est déclenchée par un scénario précédent.
L'étape E72 est déclenchée par une station cible. Selon la place disponible dans le disque de stockage, on exécute un CleanUpHeavy qui fera le ménage sur le disque et on réalise un SetAction (STATIONOK). L'étape E73 est déclenchée par une Action STATIONOK. La post-action au SetAction STATIONOK réalise une demande de distribution et d'installation du ghostXP au serveur de télédistribution 5. Si celui-ci a déjà été déposé et est toujours présent, on ne le redépose pas (capacité du colis qui fait contrôle CheckSum calculé sur le colis et sur la station). Ensuite, à l'étape E74a, on fait un SetAction (GHOSTOK).
A l'étape E74b, on teste la présence de disquette ou CDROM. Si l'un ou l'autre est présent dans la station 15a, on arrête le processus à l'étape E74c. Sinon, la station de travail 15a est remastérisée à l'étape E75 avec le ghost XP par MMCIone.exe déposé précédemment.
L'étape E76 est un post-paramétrage de la station de travail 15a nouvellement installée (DNS, DHCP, nom station,...)- On exécute en plus un programme (MMSetAction.exe) qui reprend contact avec le serveur de synchronisation 1.
A l'étape E77, le scénario de mastérisation est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération de migration demandée.
La figure 13 schématise le scénario « ré-installation de logiciels », où l'étape E80a est une SetAction (REINSTALLATION LOGICIELS).
L'étape E80b est une ouverture de session administrateur local ayant les droits de lecture sur le « Domaine Active Directory (Marque déposée». L'étape E81 (GetNexAction), la station 15a attend, mais le serveur de synchronisation 1 enclenche le processus de réinstallation logiciel.
L'étape E82 est une « PostAction à RE- INSTALLATIONLOGICIELS qui recherche dans la base de donnée, le prochain logiciel à réinstaller. A l'étape E83a, le serveur de synchronisation 1 demande à Tivoli la distribution d'un logiciel distribuable par Tivoli.
L'étape E83b le serveur de synchronisation 1 demande au serveur de distribution 5 la distribution d'un logiciel distribuable par 1er serveur de distribution 5
A l'étape E83b, il s'agit de copier un logiciel depuis un disque réseau disponible.
A l'étape E84a tous les logiciels sont installés, alors le scénario s'arrête à l'étape E84b. L'étape E85a est un test pour vérifier si il y a une nécessité de redémarrage. Si il n'est pas nécessaire de redémarrer, alors on passe à l'étape E82 et si il faut redémarrer alors on passe à l'étape E85b pour préparer le redémarrage avant de revenir à l'étape E80b.
A l'étape E86, le scénario de ré-installation de logiciels est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération demandée.
La figure 14 schématise le scénario de « restauration des données des utilisateurs ». Ce scénario consiste à restaurer l'ensemble des données utilisateurs et à terminer les installations Office et Outlook (marques déposées).
L'étape E90 est une SetAction(RESTAURATION_DATA). Ensuite, à l'étape E91, la restauration des données utilisateur est exécutée (RestaurationMMFilList.exe).
L'étape E92 est une restauration des données de messagerie converties de Netscape (marque déposée) vers Outlook (marque déposée). On recherche sur le serveur local si il existe des données converties de messagerie pour cet utilisateur 21. Si oui, on les recopie sur le poste de travail 15a.
L'étape E93 redémarre la station de travail 15a avec le compte utilisateur principal, Le logiciel de restauration des paramètres se relance pour terminer les tâches particulières à l'utilisateur 21.
A l'étape E94, on lance Outlook, le post-paramétrage standard à l'entreprise est réalisé, le profil de messagerie est migré et ensuite on ferme Outlook. A l'étape E96, le scénario de restauration des données est terminé et la dernière action du scénario consiste à enchaîner le scénario suivant, dépendant de l'opération demandée. Les étapes E93 et E94 sont répétées autant de fois que l'on a des utilisateurs 21.
La figure 15 schématise le scénario de « sondage » qui a trois objectifs. Le premier objectif est de faire progresser les outils en analysant le ressenti des utilisateurs 21, le deuxième objectif est de faire valider la fin de migration par l'utilisateur 21 et le troisième objectif est de supprimer les données sauvegardées avant la migration pour rendre de la place dans le disque de stockage. L'étape ElOOa est une SetAction (SONDAGE). A l'étape ElOOb
(par exemple exécutée à J+3), un script exécuté sur le serveur de synchronisation génère et envoie un mel à l'utilisateur qui contient l'accès à une URL.
A l'étape ElOl, l'utilisateur 21 répond aux questions posées sur l'URL envoyée dans le mel précédent. Les questions, de préférence simples et peu nombreuses portent sur la migration et non sur l'utilisation de la nouvelle version du système d'exploitation. L'utilisateur disposera toutefois d'une zone de saisie libre pour faire des commentaires, qui seront routés soit sur l'équipe Migration, soit sur l'équipe chargée de la conception des masters.
L'étape E102 est une lecture des Verbatim saisis par l'utilisateur 21.
L'étape E103 est une collecte automatique (par exemple journalière) des résultats et envoi d'un rapport au responsable ou demandeur 21 de l'opération de migration. On passe à l'étape E105a où les utilisateurs qui valident que leurs données ont été correctement restaurées peuvent supprimer les sauvegardes.
Sinon, on passe à l'étape ElOSb, qui est un appel de soutien post-migration pour les utilisateurs à qui il manque des données. Le soutien analyse et extrait des données sauvegardées avant migration et les réinstalle.
A l'étape E106, on considère que l'opération est terminée.

Claims

REVENDICATIONS
1. Procédé pour faire migrer un système d'exploitation, des données utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur connecté audit serveur par l'intermédiaire d'un réseau d'information, caractérisé en ce que la migration est réalisée par un enchaînement automatique d'un ensemble d'étapes organisées en fonction de données initiales et/ou d'une interactivité entre ledit ordinateur (15a) et ledit serveur, lesdites étapes comportant les étapes suivantes : -initialisation dudit ordinateur,
-analyse dudit ordinateur pour vérifier s'il est apte à supporter la migration, et
-chargement dudit système d'exploitation, desdites données utilisateurs et desdites applications dans ledit ordinateur, ledit chargement comportant le dépôt d'une image dudit système d'exploitation dans un disque de stockage dudit ordinateur (15a), ledit dépôt étant réalisé par un serveur de télédistribution (5) en communiquant audit ordinateur (15a) le nom d'un ordinateur dépositaire de ladite image appartenant à un réseau local (15) auquel est relié ledit ordinateur (15a) et ayant précédemment téléchargé ladite image, ou en communiquant audit ordinateur (15a) l'adresse d'un lieu de stockage central (11) comportant ladite image si ledit réseau local (15) ne comporte pas un autre ordinateur ayant précédemment téléchargé ladite image.
2. Procédé selon la revendication 1, caractérisé en ce que lorsqu'une étape suivante doit être exécutée à la suite d'une étape précédente, ladite étape précédente comprend une dernière commande permettant d'enclencher un démarrage automatique de l'étape suivante.
3. Procédé selon Ia revendication 1, caractérisé en ce que lesdites données initiales sont enregistrées par un demandeur (19) de l'opération de migration dans une base de données (3) d'un serveur de synchronisation (1) et comprennent un type de migration, des dates d'exécutions des étapes, et les noms dudit ordinateur et/ou de son/ses utilisateurs.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'initialisation est réalisée par un enchaînement automatique d'un premier ensemble d'étapes élémentaires comprenant : -demande faite par le serveur de synchronisation (1) au serveur de télédistribution (5) d'installer sur ledit ordinateur (15a) un programme nécessaire audit type de migration,
-installation dudit programme sur ledit ordinateur (15a) par le serveur de télédistribution (5), -exécution dudit programme par le serveur de télédistribution (5), et
-déclenchement par le serveur de synchronisation (1) d'une étape suivante en fonction dudit type de migration.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'analyse dudit ordinateur comprend un enchaînement automatique d'un deuxième ensemble d'étapes élémentaires comprenant : -faire un inventaire dudit ordinateur (15a) et enregistrement dudit inventaire dans la base de données (3) du serveur de synchronisation (1), ledit inventaire comprenant des listes d'applications installées, et/ou du ou des profils du ou des utilisateurs (21), et des paramètres techniques et de localisation dudit ordinateur (15a), et
-déclenchement par le serveur de synchronisation (1) d'une étape suivante en fonction du type de migration.
6. Procédé selon la revendication 5, caractérisé en ce que l'analyse dudit ordinateur comprend en outre un enchaînement automatique d'un troisième ensemble d'étapes élémentaires comprenant : -analyse de la capacité dudit ordinateur (15a) à supporter la migration, -information envoyée au serveur de synchronisation (1) pour interrompre le processus automatique, au cas où ledit ordinateur (15a) ne présente pas la capacité nécessaire à la migration jusqu'à ce q'une modification dudit ordinateur lui permette de supporter la migration, -relancement du processus automatique lorsque ledit ordinateur dispose de la capacité à supporter ledit système d'exploitation, et
-déclenchement par le serveur de synchronisation (1) d'une étape suivante en fonction du type de migration.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le chargement dudit système d'exploitation dans ledit ordinateur comprend un enchaînement automatique d'un quatrième ensemble d'étapes élémentaires comprenant :
-nettoyage du disque de stockage dudit ordinateur (15a) pour faire une place pour déposer une image dudit système d'exploitation par une suppression de fichiers inutiles connus dans la base de données (3) du serveur de synchronisation (1),
-dépôt de ladite image dudit système d'exploitation dans ledit disque de stockage dudit ordinateur (15a), et
-déclenchement par le serveur de synchronisation (1) d'une étape suivante en fonction du type de migration.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comprend en outre une étape de préparation d'une sauvegarde de données du ou desdits utilisateurs comprenant un enchaînement automatique d'un cinquième ensemble d'étapes élémentaires comprenant :
-choix par ledit demandeur (19) de l'opération de migration de profils à sauvegarder parmi des profils trouvés sur ledit ordinateur, -choix par ledit demandeur de l'opération de migration des applications utiles à réinstaller après la migration, parmi des applications trouvées sur ledit ordinateur et/ou parmi une liste d'applications disponibles, -détermination du volume de stockage nécessaire pour sauvegarder des données correspondant au(x) profil(s) et application(s) choisis. -réservation par le serveur de synchronisation (1) dudit volume de stockage sur un serveur de sauvegarde, et
-déclenchement par le serveur de synchronisation d'une étape suivante en fonction du type de migration.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend en outre une étape de sauvegarde des données du ou des utilisateurs comprenant un enchaînement automatique d'un sixième ensemble d'étapes élémentaires comprenant : -information de l'utilisateur (21) du début de l'étape de sauvegarde afin de l'inviter à fermer ses applications et clore sa session,
-vérification que ledit ordinateur (15a) ne contient aucun élément de stockage externe amorçable et, dans le cas contraire, émission d'une alerte invitant l'utilisateur à retirer ledit élément de stockage externe amorçable, -redémarrage dudit ordinateur,
-sauvegarde des données du ou des utilisateurs sur ledit serveur de sauvegarde, et
-déclenchement par le serveur de synchronisation (1) d'une étape suivante en fonction du type de migration.
10. Procédé selon l'une quelconque des revendications 7 et 9, caractérisé en ce que Ie chargement dudit système d'exploitation dans ledit ordinateur comprend en outre un enchaînement automatique d'un septième ensemble d'étapes élémentaires comprenant ; -chargement dudît système d'exploitation dans ledit disque de stockage dudit ordinateur (15a),
-réalisation d'un paramétrage déterminé dudit ordinateur, et -déclenchement par le serveur de synchronisation (1) d'une étape suivante en fonction du type de migration.
11. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend en outre une étape de restauration des données sauvegardées comprenant un enchaînement automatique d'un huitième ensemble d'étapes élémentaires comprenant : -stockage des données sauvegardées sur ledit ordinateur (15a), -vérification de la qualité des données sauvegardées, et -déclenchement par le serveur de synchronisation (1) d'une étape suivante en fonction du type de migration.
12. Procédé selon l'une quelconque des revendications 8 à 11, caractérisé en ce qu'il comprend en outre une étape d'installation desdites applications utiles choisies par ledit demandeur de migration avant et/ou après la restauration desdites données sauvegardées comprenant un enchaînement automatique d'un neuvième ensemble d'étapes élémentaires comprenant ;
-demande par le serveur de synchronisation (1) au serveur de télédistribution (5) de l'installation d'une première application sur ledit ordinateur, -vérification par Ie serveur de synchronisation de la bonne installation de ladite application, et réalisation d'un nombre déterminé de tentatives au cas où l'installation a échoué,
-demande par le serveur de synchronisation (1) au serveur de télédistribution (5) de l'installation d'une application suivante sur ledit ordinateur,
-recommencer les deux dernières étapes jusqu'à la réinstallation de toutes les applications choisies par ledit demandeur de l'opération de migration, et -déclenchement par le serveur de synchronisation d'une étape suivante de fin d'opération ou de déclaration d'anomalie.
13. Programme informatique caractérisé en ce qu'il est conçu pour mettre en œuvre le procédé selon l'une quelconque des revendications 1 à 12 lorsqu'il est exécuté par un système informatique (1, 3, 5, 7, 9, 15a).
14.Système de migration d'un système d'exploitation et des applications depuis au moins un serveur vers au moins un ordinateur connecté audit serveur par l'intermédiaire d'un réseau d'information (13), caractérisé en ce qu'il comporte un serveur de synchronisation (1) en liaison avec des serveurs de télédistribution (5), d'inventaire (7) et de sauvegarde (9) destinés à réaliser la migration par un enchaînement automatique d'un ensemble d'étapes organisées en fonction de données initiales et/ou d'une interactivité entre ledit ordinateur (15a) et lesdits serveurs et comportant une initialisation dudit ordinateur, une analyse dudit ordinateur pour vérifier s'il est apte à supporter la migration, et un chargement dudit système d'exploitation et desdites applications dans ledit ordinateur, ledit chargement comportant le dépôt d'une image dudit système d'exploitation dans un disque de stockage dudit ordinateur (15a), ledit dépôt étant réalisé par un serveur de télédistribution (5) en communiquant audit ordinateur (15a) le nom d'un ordinateur dépositaire de ladite image appartenant à un réseau local (15) auquel est relié ledit ordinateur (15a) et ayant précédemment téléchargé ladite image, ou en communiquant audit ordinateur (15a) l'adresse d'un lieu de stockage central (11) comportant ladite image si ledit réseau local (15) ne comporte pas un autre ordinateur ayant précédemment téléchargé ladite image.
EP06726204A 2005-03-01 2006-03-01 Systeme et procede de migration d'un systeme d'exploitation, des donnees d'utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur Withdrawn EP1866754A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0502045 2005-03-01
PCT/FR2006/050180 WO2006092533A1 (fr) 2005-03-01 2006-03-01 Systeme et procede de migration d'un systeme d'exploitation, des donnees d'utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur

Publications (1)

Publication Number Publication Date
EP1866754A1 true EP1866754A1 (fr) 2007-12-19

Family

ID=35149007

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06726204A Withdrawn EP1866754A1 (fr) 2005-03-01 2006-03-01 Systeme et procede de migration d'un systeme d'exploitation, des donnees d'utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur

Country Status (3)

Country Link
US (1) US20080162604A1 (fr)
EP (1) EP1866754A1 (fr)
WO (1) WO2006092533A1 (fr)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7617501B2 (en) 2004-07-09 2009-11-10 Quest Software, Inc. Apparatus, system, and method for managing policies on a computer having a foreign operating system
US7904949B2 (en) 2005-12-19 2011-03-08 Quest Software, Inc. Apparatus, systems and methods to provide authentication services to a legacy application
US8087075B2 (en) 2006-02-13 2011-12-27 Quest Software, Inc. Disconnected credential validation using pre-fetched service tickets
US20070244996A1 (en) * 2006-04-14 2007-10-18 Sonasoft Corp., A California Corporation Web enabled exchange server standby solution using mailbox level replication
US8429712B2 (en) 2006-06-08 2013-04-23 Quest Software, Inc. Centralized user authentication system apparatus and method
US8387038B2 (en) * 2006-08-14 2013-02-26 Caterpillar Inc. Method and system for automatic computer and user migration
US7895332B2 (en) 2006-10-30 2011-02-22 Quest Software, Inc. Identity migration system apparatus and method
US8086710B2 (en) * 2006-10-30 2011-12-27 Quest Software, Inc. Identity migration apparatus and method
US20090083441A1 (en) * 2007-09-24 2009-03-26 Microsoft Corporation Synchronization of web service endpoints in a multi-master synchronization environment
US9241002B2 (en) * 2008-11-10 2016-01-19 Red Hat, Inc. Trusted relationships in multiple organization support in a networked system
US8255984B1 (en) 2009-07-01 2012-08-28 Quest Software, Inc. Single sign-on system for shared resource environments
DE102009053643A1 (de) * 2009-11-17 2011-05-19 Sinitec Vertriebsgesellschaft Mbh Verfahren zur Migration von Daten sowie Computerprogramm zur Durchführung eines entsprechenden Verfahrens
US20120137278A1 (en) * 2010-11-30 2012-05-31 International Business Machines Corporation Generating a customized set of tasks for migration of a deployed software solution
US20130067451A1 (en) * 2011-09-12 2013-03-14 Microsoft Corporation Application deployment and registration in a multi-user system
US20130159528A1 (en) * 2011-12-15 2013-06-20 Microsoft Corporation Failover based application resource acquisition
CN102571778A (zh) * 2011-12-28 2012-07-11 奇智软件（北京）有限公司 一种提供数据的方法及装置
CN104239083A (zh) * 2013-06-21 2014-12-24 中兴通讯股份有限公司 移动终端的应用的迁移方法、装置以及系统
CN105808612B (zh) * 2014-12-31 2019-08-27 北京嘀嘀无限科技发展有限公司 用于迁移数据库的数据的方法及设备
US10133593B1 (en) 2016-03-31 2018-11-20 Amazon Technologies, Inc. Virtual machine migration
US10127066B1 (en) 2016-03-31 2018-11-13 Amazon Technologies, Inc. Server synchronization using continuous block migration in provider network environments
US11443067B2 (en) 2018-01-31 2022-09-13 Salesforce.Com, Inc. Restricting access and edit permissions of metadata
US10620935B2 (en) * 2018-01-31 2020-04-14 Salesforce.Com, Inc. Version management automation and consistent application builds for different target systems
CN115080505B (zh) * 2021-09-08 2023-07-14 荣耀终端有限公司 数据迁移方法、终端、存储介质和程序产品

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6049671A (en) * 1996-04-18 2000-04-11 Microsoft Corporation Method for identifying and obtaining computer software from a network computer
EP1212676A2 (fr) * 1999-08-27 2002-06-12 Glaxo Group Limited Installation a distance de systemes d'exploitation informatiques
US6920555B1 (en) * 2001-03-10 2005-07-19 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
WO2004059509A1 (fr) * 2002-12-16 2004-07-15 Columbia Data Products, Inc. Sequences de lancement permettant d'executer des operations informatiques protegees
US7379982B2 (en) * 2002-04-15 2008-05-27 Bassam Tabbara System and method for custom installation of an operating system on a remote client
US20040187104A1 (en) * 2003-03-18 2004-09-23 Shantanu Sardesai Operating system deployment methods and systems
US20050086457A1 (en) * 2003-10-21 2005-04-21 Hohman Jennifer L. System and method for providing user controlled migration of a client computer

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006092533A1 *

Also Published As

Publication number Publication date
US20080162604A1 (en) 2008-07-03
WO2006092533A1 (fr) 2006-09-08

Similar Documents

Publication Publication Date Title
EP1866754A1 (fr) Systeme et procede de migration d'un systeme d'exploitation, des donnees d'utilisateurs, et des applications depuis au moins un serveur vers au moins un ordinateur
US9471441B1 (en) Systems and methods for backup of virtual machines
US8463758B2 (en) Network registry and file cleaner
CN107066296B (zh) 一种集群节点中镜像的清理方法及装置
FR2756070A1 (fr) Systeme de gestion et de traitement de transactions distribuees d'objets et procede mis en oeuvre par ledit systeme
EP1683008A2 (fr) Procede dans un reseau de distribution de fichiers
JP2009508190A (ja) 顧客関係管理システム及び方法
KR20040082339A (ko) 운영 시스템 배포 방법 및 시스템
US20200236167A1 (en) Synchronization of components in heterogeneous systems
WO2004109515A2 (fr) Systeme et procede de gestion et de signalisation de systemes eloignes
FR3089325A1 (fr) Procédé et dispositif de gestion de configurations logicielles d’équipements d’un aéronef
US20140324789A1 (en) Cleaner with computer monitoring
WO2009053356A1 (fr) Procede de gestion d'operations d'administration, de maintenance et de maintien en condition operationnelle, entite de gestion, et produit programme d'ordinateur correspondant
WO2022180323A1 (fr) Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants
EP3475847B1 (fr) Serveur de statistiques pour optimisation de requêtes client-serveur
EP3080968A1 (fr) Procédé de synchronisation de données entre un ensemble de terminaux
FR3118815A1 (fr) Estimation de la progression de l'exécution d'une tâche logicielle
EP2791794B1 (fr) Procede de gestion d'une application referencee par un dispositif
WO2010052441A1 (fr) Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs
Fulmer et al. AutoInstall for NT: Complete NT Installation Over the Network.
WO2010039993A2 (fr) Automatisation pour environnements informatiques virtualisés
US11093239B1 (en) Application driven configuration of service management tools
EP3144812A1 (fr) Architecture client/serveur pour l administration d'un supercalculateur
EP3032410A1 (fr) Procédé de fourniture d'un service informatique et système informatique pour la mise en oeuvre du procédé
WO2003052596A1 (fr) Systeme et procede permettant d'installer un logiciel sur une pluralite d'ordinateurs personnels de façon automatique et simultanee

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070925

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE ES FR GB IT

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE ES FR GB IT

17Q First examination report despatched

Effective date: 20080730

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: REFRESH IT SOLUTIONS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20161001