| Cloning is a method of imaging a preconfigured operating system and applications onto similar machines and or for rapid restore purposes. Cloning is a suitable deployment method if you will be: Installing identical configurations on multiple servers. Required to install an operating system and software configuration as quickly as possible. Required to restore an operating system and software configuration as quickly as possible. Install operating systems on computers that have similar hardware and compatible hardware abstraction layer (HAL). In addition to these deployment solutions, you can customize a cloned image to accommodate different hardware and software requirements; this allows you to use one disk image to deploy several different hardware and software configurations. For future growth, ease of server deployment and disaster recovery purposes, it is desirable that you use system-imaging utilities to clone MetaFrame XP servers (Ghost, DriveImage) and Microsoft Sysprep to prepare the OS for imaging. A few manual steps are required for cloning MetaFrame XP servers. Please be very careful and make sure you complete every step and double checking your work is advisable. If you forget to change the server DSN file, you run the risk of corrupting the IMA data store and that could cause farm wide issues. Clean installation only You can only use server cloning to install a clean version of MetaFrame XP servers. You cannot use server cloning to upgrade an existing MetaFrame XP server. Limited server configuration Some server components must be installed and configured after cloning is complete. These include Certificate Services, and any software that is dependent on the Active Directory directory service. These also include any application or service that stores the computer name or the computer SID and cannot recover if the computer name or SID changes. HAL compatibility You can only clone a MetaFrame XP server if the HAL on the disk image is compatible with the hardware on the destination server. In some cases, Windows Server 2003 automatically upgrade the HAL that is on a disk image to suit the HAL requirements of a destination computer, but this can only occur if the HAL on the disk image meets several requirements.
In order to successfully clone a Microsoft Windows Server it is required to utilize Windows 2000 System Preparation Utility (sysprep) The sysprep utility can be downloaded from: http://www.microsoft.com/windows2000/downloads/tools/sysprep/license.asp Sysprep is a simple utility that prepares a Windows 2000 machine for the following: Disk duplication Sysprep allows you to copy fully installed systems when the hardware is similar. It modifies the local computer security identifier (SID) so that it is unique to each computer. Automating Mini-Setup Sysprep creates a shortened GUI-mode setup that takes 3 to 10 minutes instead of 20 to 30 minutes and prompts the end user only for required and user-specific information, such as accepting the Microsoft license agreement, computer name, domain properties and TCP/IP addresses. Conditions of Sysprep with the current version of Windows 2000 Sysprep runs only if the computer is a member of a workgroup, not a domain. You can run additional programs at the end of Mini-Setup by providing a Cmdlines.txt in your Sysprep folder. For more information on the Microsoft Sysprep utility, please refer to Microsofts Windows 2000 Deployment Planning Guide: http://www.microsoft.com/windows2000/techinfo/reskit/dpg/default.asp. Note: Sysprep has been known to take a while to finish and you system might appear to be hung but is not.
Sysprep for Windows Server 2003 is very much the same as for Windows 2000 Server minus the new enhancements added for Server 2003, as shown below. The sysprep utility can be located on the Microsoft Windows Server 2003 CDROM in the following folder: \Support\Tools\ in the Deploy.CAB file. You will want to extract the contents of the deploy.cab file to a folder and inside you will find sysprep.exe. New in Sysprep Sysprep has several new features that are useful for cloning server in corporate environments. | Feature | Description | | Cancel restart support | A Sysprep parameter that prevents a computer from restarting after you run Sysprep. This parameter is mainly used for testing, especially to check if the registry was modified correctly after you perform installation tasks. | | Countdown timer setting for product activation | A Sysprep parameter that prevents a reset of the countdown timer for product activation. By default, the countdown timer for product activation is reset when you run Sysprep. This parameter is useful if you activate a computer before you deliver it to an end user. This setting is not relevant if you have a volume license. | | Mass storage support | A Sysprep parameter (-bmsd) and an answer file entry (BuildMassStorageSection) that instructs Sysprep to build a list of drivers for mass storage controllers. This prevents you from having to enter device driver information manually in the Sysprep answer file, if an image supports more than one type of mass storage controller. | | Device driver cleanup support | A Sysprep parameter that clears unused mass storage drivers added by the [SysprepMassStorage] section of Sysprep.inf, and removes phantom devices created by Plug and Play. | | Audit support | A Sysprep parameter that lets you verify software and hardware installation without generating new SIDs or processing any items in the Factory mode answer file (Winbom.ini). You can only use audit support with the new Factory mode feature. | | Factory mode | A Sysprep parameter that restarts a computer in a network-enabled state without running Mini‑Setup. Factory mode is useful for updating drivers, running Plug and Play enumeration, installing applications, testing, configuring the computer with customer data, or making other configuration changes before you deliver a computer to an end user. The Factory mode answer file, Winbom.ini, allows you to automate many installation tasks. | | Forced shutdown support | A Sysprep parameter that forces a computer to shut down after you run Sysprep. This parameter is useful if a computer has an Advanced Configuration and Power Interface (ACPI) BIOS and it does not shut down properly when you run Sysprep. | | Reseal support | A Sysprep parameter that clears the Event Viewer logs and prepares the computer for delivery to the customer. Typically, you use the -reseal parameter after you perform installation and auditing tasks in Factory mode. | If you will be utilizing cloning for rapid deployment of MetaFrame XP Servers and for disaster recovery purposes then you will want to follow the following procedures. It is not supported to clone a MetaFrame XP server that is acting as the host server, the server housing the Microsoft Access or MSDE data store. For rapid deployment of MetaFrame XP server running in a Farm utilizing an Access or MSDE data store you will be required to clone the second server in the Farm or any server that is connected to the host server in indirect mode. The following procedures do NOT work on MetaFrame XP Servers with their drives remapped. This is just another reason why I do not recommend remapping drives. If you must use drive remapping then please refer to the following section but do note it is not supported by Citrix technical support. The following defines how to clone a Citrix MetaFrame XP Server. 1. Install and configure the MetaFrame XP server as discribed in the installation procedures in this document. 2. Install any image applications. 3. Make any tweaks and make and modifications to the users enviroment. 4. Create a new folder off the root of the boot drive called sysprep. i.e., c:\sysprep. 5. Obtain the appropriate version of Sysprep, as documented above, and copy sysprep.exe and setupcl.exe to c:\sysprep. 6. Remove the server from the domain and reboot when prompted. 7. Empty all the event logs, recycle bin and clear documents and settings. 8. Delete the Wfcname.ini file from the root drive of the server, if it exists. It will be located on the root of the drive. (C:) 9. Save the changes to the DSN file. 10. Stop the IMA service and set the startup option to Manual. 11. If you are running Resource Manager on a MetaFrame XPe server, you must delete the local database used by Resource Manager (named RMLocalDatabase) so that the cloned server does not retain information from the server you are using as the source for the cloning. The RMLocalDatabase is installed in Citrix Resource Manage\LocalDB in the MetaFrame installation directory, %Program Files%\Citrix by default. 12. Run sysprep.exe from c:\sysprep and follow on screen instructions. 13. Create an image of the server with qulified imaging software. (i.e., Symantec Ghost, PowerQuest DriveImage) 14. Deploy the image obtained in Step 13. and follow the mini setup wizzard to install the image. 15. Login as administator 16. Execute regedit.exe on each server and make or verify the following changes:
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA]
"ServerHost"="new_server_name"
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\RUNTIME]
"PSRequired"=dword:00000001
"HostName"="new_server_name"
where "new_server_name" is the current computer name of each new MetaFrame XP server. 17. Search the registry on each new server. Replace any occurrence of the old server name with the new server name.
18. Change the hostname in %SystemDrive%\Inetpub\wwwroot\Citrix\PNAgent\config.xml. Search for any occurrences of the old name and replace it with the new name. 19. Manually start the IMA service and set the service to start automatically. 20. Verify that the server was successfully added to the farm by executing qfarm at a command prompt on any server in the farm. The newly imaged server should appear in the list of servers. 21. Logon to the server as a MetaFrame XP administrator. 22. Open the Management Console for MetaFrame XP and right click on the Farm and select Properties. 23. Zone settings are not retained when cloning a server. When the Citrix IMA Service on the cloned server starts for the first time, the MetaFrame XP server joins the default zone. The name of the default zone is the ID of the subnet on which the cloned server resides. When deploying images to servers on multiple subnets, assign zone information for each server after the imaging process completes. 24. Feature Release level settings are not retained when cloning a server. The proper Feature Release level will need to be set for each cloned server that is added to the farm. This can be set on all servers using the Management Console. From the Management Console for MetaFrame XP right click on the new server and click Set Feature Release Level.
Note: The following procedures do NOT work on MetaFrame XP Servers with their drives remapped. This is just another reason why I do not recommend remapping drives. If you must use drive remapping then please refer to the following section but do note it is not supported by Citrix technical support. The following defines how to clone a Citrix MetaFrame XP Server. 1. Install and configure the MetaFrame XP server as discribed in the installation procedures in this document. 2. Install any image applications. 3. Make any tweaks and make and modifications to the users enviroment. 4. Create a new folder off the root of the boot drive called sysprep. i.e., c:\sysprep. 5. Obtain the appropriate version of Sysprep, as documented above, and copy sysprep.exe and setupcl.exe to c:\sysprep. 6. Remove the server from the domain and reboot when prompted. 7. Empty all the event logs, recycle bin and clear documents and settings. 8. Delete the Wfcname.ini file from the root drive of the server, if it exists. It will be located on the root of the drive. (C:) 9. Edit the Mf20.dsn file with Notepad or another text editor. By default, the DSN file is located in the %ProgramFiles%\Citrix\Independent Management Architecture folder. For a Microsoft SQL Server installation, the DSN file should look similar to this: [ODBC] DRIVER= SQL Server UID= SQL_USERNAME DATABASE= NAME_OF_DATABASE WSID= NAME_OF_ MF_SERVER APP= Citrix IMA SERVER= NAME_OF_SQL_SERVER Remove the following line: WSID= NAME_OF_MF_SERVER. The DSN now looks like this: [ODBC] DRIVER=SQL Server UID=SQL_USERNAME DATABASE=NAME_OF_DATABASE APP=Citrix IMA SERVER=NAME_OF_SQL_SERVER 10. Save the changes to the DSN file. 11. Stop the IMA service and set the startup option to Manual.
12. If you are running Resource Manager on a MetaFrame XPe server, you must delete the local database used by Resource Manager (named RMLocalDatabase) so that the cloned server does not retain information from the server you are using as the source for the cloning. The RMLocalDatabase is installed in Citrix Resource Manage\LocalDB in the MetaFrame installation directory, %Program Files%\Citrix by default. 13. Run sysprep.exe from c:\sysprep and follow on screen instructions. 14. Create an image of the server with qulified imaging software. (i.e., Symantec Ghost, PowerQuest DriveImage) 15. Deploy the image obtained in Step 13. and follow the mini setup wizzard to install the image. 16. Login as administator 17. Open the %ProgramFiles%\Citrix\Independent Management Architecture\MF20.dsn file and add the following line: WSID= NAME_OF_NEW_MF_SERVER to create a dsn follow similar to the following: [ODBC] DRIVER= SQL Server UID= SQL_USERNAME DATABASE= NAME_OF_DATABASE WSID= NAME_OF_ NEW_MF_SERVER APP= Citrix IMA SERVER= NAME_OF_SQL_SERVER 18. Execute regedit.exe on each server and make or verify the following changes:
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA]
"ServerHost"="new_server_name"
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\RUNTIME]
"PSRequired"=dword:00000001
"HostName"="new_server_name"
where "new_server_name" is the current computer name of each new MetaFrame XP server. 19. Search the registry on each new server. Replace any occurrence of the old server name with the new server name. 20. Change the hostname in %SystemDrive%\Inetpub\wwwroot\Citrix\PNAgent\config.xml 21. Manually start the IMA service and set the service to start automatically. 22. Verify that the server was successfully added to the farm by executing qfarm at a command prompt on any server in the farm. The newly imaged server should appear in the list of servers. 23. Logon to the server as a MetaFrame XP administrator. 24. Open the Management Console for MetaFrame XP and right click on the Farm and select Properties. 25. Zone settings are not retained when cloning a server. When the Citrix IMA Service on the cloned server starts for the first time, the MetaFrame XP server joins the default zone. The name of the default zone is the ID of the subnet on which the cloned server resides. When deploying images to servers on multiple subnets, assign zone information for each server after the imaging process completes. 26. Feature Release level settings are not retained when cloning a server. The proper Feature Release level will need to be set for each cloned server that is added to the farm. This can be set on all servers using the Management Console. From the Management Console for MetaFrame XP right click on the new server and click Set Feature Release Level.
If you will be cloning a MetaFrame XP Server and you will be using Symantecs Ghost to create an image of a server computer that is running MetaFrame on Windows 2000 then you will need to follow the following procedures. Note: Cloning MetaFrame XP servers is not supported by Citrix support and hence not a good idea. Servers with remapped drives can be duplicated using a hardware solution such as Compaq Smart Array controllers with RAID1 drive mirroring. The following article was pulled from Symantecs knowledgebase. Situation:
You want to clone a terminal server. That is, you want to use Ghost to create an image of a server computer that is running a terminal services program such as Citrix MetaFrame or Windows 2000 Terminal Services. You want to know whether Ghost can clone a terminal server.
Solution:
Ghost does not support the cloning of terminal servers. However, Symantec Ghost 7.5 does support the use of Microsoft's Terminal Server for remotely controlling the Ghost Console.
Cloning terminal servers:
Symantec does not provide technical support for cloning terminal servers. Symantec provides the following information as a suggestion only. The following suggestions have not been tested and might not work:
In some cases Ghost can successfully clone a terminal server, but the destination computer cannot restart after cloning because Windows changed the drive letters. This problem is likely to happen when you reassigned the drive letters on the source computer in the process of configuring the terminal server program.
Using Ghost's SZEE and -FDSP switches might prevent Windows from changing the drive letters after cloning; however, some terminal server services might not function.
Here is an example of a Ghost command-line that uses the SZEE and -FDSP switches:
ghost.exe -fdsp -clone,mode=load,src=g:\2prtdisk.gho,dst=1,szee
Using terminal services to run the Ghost Console:
Symantec Ghost 7.5 supports Microsoft Terminal Server. You can use Microsoft Terminal Server to remotely control the Ghost Console.
Note that you cannot use Terminal Server to remotely control the Ghost Client. Only the Ghost Console can send Tasks to the Ghost Client.
In earlier Ghost versions, using Terminal Services to log in to the Ghost Console does not work. To remotely control the Ghost Console, use a remote control program, such as Symantec pcAnywhere.
|