Step 1: Assess Your Environment and Plan Your Deployment
Gathering real information about your hardware, software applications, and network will help determine when to migrate and what resources are required for the migration. Is your network ready for a large-scale rollout? Evaluating your organization's physical requirements and topology is the key to developing an accurate and predictable deployment plan. During this phase you will assess your environment as well as outline your deployment and migration business case by doing the following:
- Discover devices across your network
- Run an inventory scan
- Assess hardware readiness through reports
- Assess software readiness to prioritize applications to test and migrate
- Determine where and how you will utilize multicasting and local file shares
- Add costs, timeframes, and required hardware and personnel requirements to plan
- Determine dependencies unique to your organization
- Develop acceptable Service Level Agreements (SLAs)
- Create communication plans
- Identify potential issues and risks
Discover Devices Across Your Network
The first step in analyzing client systems in an environment is to actively manage endpoints with client software. Altiris Deployment Solution uses AClient and DAgent to manage client systems. AClient is installed and used on client systems with Windows XP and older Windows operating systems. DAgent is used for Windows XP and newer operating systems. Since each agent contains the same functionality it doesn't matter which is used with Windows XP. There are a variety of methods to install the agent on each end point. Depending on your network infrastructure or personal preferences choose from one of the following:
Remote Agent Installer - This is usually the preferred method to install the Deployment Solution agents. This program can be accessed from the Deployment Solution Win32 console from Tools > Remote Agent Installer, or it can be accessed from the Deployment (eXpress) share with the file rcinstall.exe. The wizard will ask you for agent settings, and a user account used to access the systems remotely.
This utility requires that each endpoint has remote file system access, remote registry, and remote services access. If this utility is failing to install the client software on an endpoint you can attempt the following three tests. Try to map a network drive to \\clientComputerName\c$. Open up regedit.exe and select File > Connect Network Registry and attempt to connects to the client system's registry. Open up Windows Services (services.msc) and from that dialog select Action > Connect to another computer and from there attempt to connect to the remote system's services.
AD group policy - If the Remote Agent Installer cannot be used for some reason, and all client end points are joined to a domain, group policies can be used to install the Deployment Server agent to end points. The installation of AClient or DAgent can be done in a batch script that can then be run from a domain group policy. More information about this process can be found in Altiris KB Article 1680.
Other endpoint management system - If endpoints are already managed by a desktop lifecycle management product, such as Altiris Client Management Suite, it can be fairly easy to create a package and push out the agent with that software. Since this is different for each type of management software you will need to reference the product documentation. Altiris KB Article 45334 explains the process with Altiris Client Management Suite.
Manual installation - A manual client installation might be preferred if no remote installation option will function or if the number of remote endpoints is very small, such as in a test environment. From the client computer, browse to the eXpress share and copy over to the client system AClient.exe or DAgent.msi (depending on the client operating system) and then run the file. Both of these contain a short installation wizard which will prompt for agent settings, such as installation directory and Deployment Server IP address.
Run an Inventory Scan
As soon as a Deployment Solution Agent is installed to a client machine, it begins sending basic inventory, such as computer name, network information, domain information, and basic hardware information. Basic inventory is sent every time the Agent connects to Deployment Server. The Agent also sends full inventory such as detailed hardware information, services, applications, etc. Full inventory is sent at a configurable interval which is every 24 hours by default. If you want to make sure that a particular report contains the latest inventory data, you can schedule a Get Inventory task to all computers to force a full inventory scan.
This information is stored in the Microsoft SQL server specified during the Deployment Solution installation. The Deployment Solution Win32 console has the ability to view detailed inventory for a single client system. It does not have a method to generate reports or view groups of inventory data in a spreadsheet. Other tools will be required to generate these types of reports.
Various tools are available to generate these reports such as Microsoft Report Builder or Crystal Reports. SQL Management Studio also has query analyzers that allow simple query results from a SQL query. All of these tools use Transact SQL (or TSQL) as the basis of building these reports. A basic understanding of the Deployment Solution database schema is required to generate reports and gather needed data to perform proper analysis. See Appendix A for information about the data stored in the eXpress database and sample queries that can be used to retrieve that information.
Assess Hardware Readiness through Reports
You will need to query your Deployment Solution database to generate a list of client computers that meet the following requirements:
You can get this list by running the following query against the Deployment Solution Database:
SELECT C.name, H.proc_speed, H.ram_total, CASE proc_type WHEN 1 THEN 'x86' WHEN 2 THEN 'x64' ELSE 'incompatible' END AS architecture, D.name AS [graphics device name], D.manuf AS [graphics device manufacturer] FROM computer C, hardware H, device D WHERE C.computer_id = H.computer_id AND C.computer_id = D.computer_id AND D.class LIKE '%4d36e968-e325-11ce-bfc1-08002be10318%'
Assess Software Readiness to Prioritize Applications to Test and Migrate
The Deployment Server database will contain all applications that are installed on client systems, provided that the application registers itself with the Windows operating system (i.e. the application is displayed in Add/Remove Programs). After the Deployment Solution Agent is installed on all client systems that will be migrated, a report can be built that will give a list of all software currently installed. Some of this software might not be supported by your IT group, but it should provide a good list to work from to build a list of applications that will be installed during or after the Windows 7 migration process.
Query your eXpress database to generate a list of all software in your environment that will be included in the Windows 7 Migration. This information can be queried from the Applications table in the eXpress database. When you have the list, check with the application vendors to determine what applications are Windows 7 compatible.
You can get this list, sorted by the count of computers having that application, by running the following query against the Deployment Solution Database:
SELECT COUNT(1) AS [count], [publisher], [description], [name], [version], [product_id] FROM [application] GROUP BY [publisher], [description], [name], [version], [product_id] ORDER BY [count] DESC, [publisher], [description], [name]
Determine Where and How You Will Utilize Multicasting and Local File Shares
Out of the box, Deployment Solution supports three imaging engines: RDeploy, Ghost, and ImageX. Before determining where and how to use multicasting and local file shares, it is important that you understand the difference between these imaging engines and how it affects you.
RDeploy - This is the native imaging engine in Deployment Solution 6.x. It is the only imaging engine that uses multicasting technology to reduce server load while deploying the same image to many clients on the same subnet. RDeploy supports most drive formats, including FAT, NTFS, and EXT3.
Ghost - This is the native imaging engine in Deployment Solution 7.x. It does not support multicasting. Ghost supports most drive formats, including FAT, NTFS, and EXT3. It supports preserving specific files and folders while deploying a new image to an existing system.
ImageX -This imaging engine was developed by Microsoft. It does not support multicasting. ImageX only supports the Windows compatible driver formats FAT and NTFS. With some customization, you can preserve specific files and folders while deploying a new image to an existing system.
| |
RDeploy |
Ghost |
ImageX |
| Multicast |
X |
|
|
| FAT |
X |
X |
X |
| NTFS |
X |
X |
X |
| EXT3 |
X |
X |
|
| File Preservation |
|
X |
X |
A powerful use of Ghost's file preservation is during personality capture and deployment during an in-place migration. When performing in-place migration (the same hardware to a new operating system), you can store the personality package on the hard drive rather than the file server. Since personality packages have the potential to become very large (sometimes in the gigabytes), the file preservation technique will speed up the migration and reduce server workload. Since no imaging engine supports both multicasting and file preservation, you need to determine which feature will benefit you the most. If you choose to take advantage of this feature, make sure to capture your images as Ghost (GHO) files.
Large and complex networks are going to require a lot of work to determine how replication and imaging will be done. If a large number of imaging tasks are going to run simultaneously, multicast research should be done. If PXE will be used then DHCP infrastructure and IP helpers need to be considered.
Image Placement and Management - In segmented networks across a WAN it is important to place image shares at each LAN location and identify what the link speeds from each image share to the endpoints. You will need to test network transfer speeds between the end clients and the file shares. It is important to test a variety of clients to identify potential weak or trouble spots that could cause problems. If necessary a single LAN site might need more than one local file share, or perhaps a single file share could be used across multiple LANs. The requirements for a file share are fairly simple, a Windows system, sufficient resources (such as disk space and network access), and high availability.
Once local file share needs have been identified, order any new server hardware that is deemed necessary and position them at their respective places in the network.
Multicast and Broadcast domains - Deployment Solution utilizes both multicasting and broadcasting for various functions. It is important to determine where broadcast and multicast boundaries exist, and if multicasting (or IGMP) is enabled on your network devices (usually at the switch level). Broadcast technology is used with both PXE (Pre-boot eXecution Environment) and WOL (Wake On Lan). These are both very useful tools used for image deployment, but are not required. Since broadcasting is often very restricted in most networks, certain accommodations need to be made to allow the use of these functions.
PXE Broadcasting - The PXE pre-boot technology allows a client machine to boot to a pre-boot environment, such as WinPE or DOS, without using any physical media at the client system, such as a boot CD. It does not utilize the hard drive while booting, so it is ideal for zero footprint provisioning. PXE utilizes the same network protocol as DHCP. Since a client's PXE boot behavior is dictated by the BIOS boot process, and by the Intel PXE boot protocol standard, it cannot be configured or modified.
PXE clients send broadcasts on UDP port 67 and receive a response on UDP port 68. Normally broadcast packets on these ports are forwarded to the DHCP server even if they are across broadcast domains. If client machines are on a separate LAN from the PXE server and the UDP broadcast packets cannot get from the client machine to the PXE server due to network design, one of the following three things will need to be done to use PXE:
- Install a secondary PXE server at each local LAN in each broadcast domain.
- Use/add IP helpers on network devices (generally routers) to forward DHCP packets to the IP address of the PXE server.
- Add DHCP scope options to the DHCP server. This is known as using PXE Forced Mode.
Adding a PXE server to each LAN is a good idea if each site is a very long distance, or has a slow link between each link. If a very large number of LAN sites exist it can cause complexity very quickly. Generally if a small number of remote sites (such as 5 or less) are being used then this method is fairly easy to implement. In very large environments where hundreds of sites exist it is not recommended to use this method.
Adding IP helpers to all network devices can be a challenging unless a replication method is in place by the network administration team. Depending on the difficulty of modifying and maintaining the network infrastructure this method can be investigated. Adding IP helpers also increases the amount of network traffic going across broadcast domains. This additional traffic needs to be monitored to determine if it will cause network congestion or other complications. If the network in general does not have very much DHCP traffic, then this change should not have very much impact over all.
If the DHCP server scope options are available for modification it is highly recommended to use scope options to redirect clients that are PXE booting from the DHCP server to the PXE server. Using this option requires an understanding of DHCP scope options. The Altiris KB Article 33999 explains how to configure these scope options on a Microsoft DHCP server.
If you are using a non Microsoft DHCP server the same DHCP options/principles can be applied with slight modifications. Instruction for certain popular DHCP devices may be found in the Altiris Knowledgebase.
Add Costs, Timeframes, Hardware, Software, And Personnel Requirements To Plan
To determine the costs, timeframes, and personnel requirements you will need to make a list of required hardware, software, and tasks to complete the migration. When you have the list, you can then add time estimates for the tasks. Then, estimate the cost for the hardware, software, and estimated task time requirements. The list of tasks will be unique to your business, but a good place to start is the tasks outlined in the table of contents of this document.
When you have determined the tasks and the time required for each task, you can then determine which tasks will need multiple staff and designate who will be working on each task.
Determine Dependencies Unique To Your Organization
Each organization has its own unique requirement and dependencies that need to be addressed before a full rollout can be accomplished. It is important to identify these requirements during the initial pilot rollout or perhaps even earlier. Some of these might include:
- Blackout times where productivity cannot be impacted by downtime.
- Total network bandwidth that is available.
- Impact on network applications and interruption of network services caused by:
- A large amount of imaging
- Transferring large files
- Personality migration
- Remote application installations
When identifying these unique conditions in your environment make a plan on how these will be dealt with as well as possible side effects of any workarounds. If these items will delay a full rollout then the estimates created in previous stages need to be updated. Some of these dependencies could add time and resources. Planning for dependencies ahead of time will reduce frustration and lost work.
Develop Acceptable Service Level Agreements (SLAs)
At this point, you know how many people will be working on each task. You can use the time required for each task divided by the number of staff working on it to determine how many work hours each task will take. You can then determine how many days each of the 7 steps will take and declare a target date to have each step completed.
Create Communication Plans
You need to create a communication plan document that describes:
- Your objectives
- How you will accomplish the objectives
- Who will be notified of status updates
- When status updates will be communicated
- Timetable
- Reports
Identify Potential Issues And Risks
Factors of a successful project are scope, time, and money. Prior to a full rollout of Windows 7 Migration, analysis needs to be done to identify potential risks that may affect these factors. These risks will fall into one of four categories. Here are some examples of possible risks (this is not an exhaustive list):
- Technical, quality and performance
- Unforeseen environmental dependencies
- Data loss
- System outages
- Project management
- Timelines are not met
- Inadequate project plan
- Organizational
- Lack of resources
- Inconsistent objectives or project scope
- Poor prioritization
- External
- Power outages
- Legal issues
- Labor issues
- Changing priorities or expectations
Build and Test
During the second phase, you can prepare for migration by building image files, identifying application compatibility issues, building application packages, and generating personality templates. You will also build and test your migration workflow job to ensure all files and templates are in place and ready to go.
Return to Windows 7 Migration: Introduction