Step 6: Migrate Systems
Before you can successfully migrate on a large scale, you need to know what is in front of you. Gathering real information about your hardware, applications, and security helps you determine when to make the move and what resources are required. Now you've done all the planning, you're ready to test and adjust your processes for deployment. In this step, you will:
- Position any servers purchased as part of the deployment plan in Step 1
- Make any required network adjustments, such as enabling multicasting
- Identify test candidates
- Document test cases
- Create a phased pilot
- Perform Migration
Position Any Servers Purchased as Part of the Deployment Plan in Step 1
Deployment Server can utilize network shares to provide local file sources to client computers. These shares should be hosted on a Windows server. The share content will need to be synchronized between all these servers so that the required files are always available to all clients. You will need to have the same share name on all servers, including the Deployment Server. You may name this share anything you like, but we will refer to it having the name "Deployment".
On all servers, including Deployment Server, determine a location with free space to hold all your images, personality packages, software packages, etc and plenty of room to grow. Create a directory named "Deployment" and share this directory as "Deployment". Once you have done this, you will need to move these files into the "Deployment" share of your Deployment Server.
Security access needs to be opened where endpoint clients can access the file shares to either download or upload files. If a client is capturing an image it needs to also have upload and perhaps overwrite access to the share. Having a security user that has access to the Deployment Server's main "eXpress" share, as well each package server's share is recommended. This user can be a domain user account (not necessarily a domain administrator) or a local Windows system account. If this is a local account make sure that all remote systems have the same login credentials with this account.
Now you need to replicate these files to your other servers. Deployment Server does not automatically replicate files between servers; you will need to manage this replication yourself. File replication with Deployment Server will involve large files (such as images), and a large number of smaller files (such as drivers and software installers). Designing a good method to replicate these files across a WAN in an automated method can be complex and challenging. Two suggested methods to replicate these files are to use Altiris Package Servers or Microsoft RichCopy.
Replicate files using Altiris Package Servers - The recommended method of replicating files between various file shares across a WAN environment is using Altiris Notification Server with package servers. When a package on the central Notification Server is updated it will automatically update all remote package server files with any updated files. One other advantage with Notification Server's package servers is that they can use network throttling so that WAN network links will not be overloaded with large amounts of traffic. For more details on Package Replication with Notification Server see Altiris KB Article 31779.
Replicate files using Microsoft RichCopy - Another option to replicate files between various file shares is to use
Microsoft's RichCopy utility. Because it is more complex to configure and maintain than Package Servers, it is not recommended for large environments. See Appendix B for more information about Microsoft RichCopy.
After the files have been replicated to the appropriate network locations, you will need to modify the Deployment Solution configuration to allow jobs to pull files from their nearest server. You can use the %SITE% token to allow jobs to reference files from the nearest server in Automation and Production. This process is explained in Altiris KB Article 17101. If you only need to access these files from Automation for imaging, you can use PXE Environment Variables. The use of PXE Environment Variables is explained in Altiris KB Article 45890.
Make Any Required Network Adjustments, Such As Enabling Multicasting
Implement the network changes identified during assessment and evaluation. This is required to support the Deployment Solution software that will be used to automate the migration process. Consult hardware vendors for details on how to make these configuration changes to your routers, switches, etc.
Identify Test Candidates
There are several different migration approaches that you can take to identify the pilot or test candidates. These different approaches can also be used to determine the pilot phases and subsequent migration rollout. These migration approaches are the following:
- Mass Migration
- Move everyone to common standard.
- Highly manageable but allows no customization based on departments or configurations.
- Can be expensive for the company in time and resources.
- Very few companies take this type of approach to migrations.
- Batch Migration
- Maintain small set of standard configurations.
- Batch can be based on department or similar job functions.
- Combination of hardware refresh and re-imaging.
- Good cost/manageability compromise.
- About half of the companies take this approach.
- Gradual Migration
- Migrate on hardware refresh schedule.
- Lower up-front cost.
- Can be challenging to manage.
Identify test candidates that satisfy the migration approach you will be using.
Document Test Cases
Identify the expected outcome of the migration job. A few things you will want to consider are:
- Which applications should be installed?
- Which personality files and settings should be migrated?
- Which Operating Systems should be able to migrate using this process?
- Which Computer Models should be able to migrate using this process?
Based on these objectives, create and document test cases that will verify the success of all migration scenarios. Organize these into a test matrix to use for project approval and tracking.
Create a Phased Pilot
After you have thoroughly tested the entire migration process on a single computer, you should conduct a pilot migration with a small group of users. Select the target group carefully, we recommend that you run the first pilot on a small IT group that has been involved with the overall migration project. Picking the IT users allows you to have a group of users that are able to understand if there is problem and rapidly provide feedback to the project team.
After Phase 1 migration is performed, verify that all data and settings have migrated as expected to the target group. A pilot migration also gives you an opportunity to test your overall processes. Once you have determined that the pilot migration is successful, you are ready to move to the next phase of the pilot.
Phase 2 involves migration of the larger IT department. There may be specific systems that may need to be removed from the target list of computers because those systems support critical applications or systems.
Phase 3 will be to select a department that can be migrated and moved to Windows 7. If the department is successfully migrated the pilot phase ends and the migration rollout begins.
Perform Migration
When a successful pilot has been completed it is now time to roll out the full migration. Depending on the number of total clients being managed, as well as the complexity of the environment this will need to be done in phases. There are various methods of phasing a large scale deployment, use the techniques that best fit your environment.
The Deployment process takes multiple steps, and at each step complications can arise. Often with an increase of systems being simultaneously provisioned the chance of failure or exposing a fault is magnified. When scaling the project it is important to find these issues and resolve them before you have impacted too many systems. A common approach is to start first with a migration of a small number of systems such as five to ten that are all local in a single subnet or network and complete the entire migration process on those systems. If a problem occurs at some point you might need to break apart the tasks that are contained in your migration job and run them separately on the systems being currently phased. This will allow you to analyze and identify the exact cause to the migration failure. When a smaller group has successfully migrated then it is time to select groups at remote locations and slowly ramp up the size of computers being simultaneously migrated.
In a typical case most clients will successfully run through the migration process and complete, but some clients in the batch might fail. Depending on where the client system failed it might be possible to reassign the migration job. Clients that fail to run through the entire migration process need to be gathered together logically (not necessarily physically gathered) and then analyzed for similarities that could have caused failures. In a well planned and tested migration process the total number of failed clients should be fairly small. With proper investigation and analysis even these should be mitigated.
Return to: Windows 7 Migration: Introduction