How to prepare a workstation for imaging that includes the SMP/NS Agent

Products

Management Platform (Formerly known as Notification Server) Deployment Solution Ghost Solution Suite

Issue/Introduction

Note:
With recent versions of Ghost Solution Suite and Deployment Solution, the need of manually cleaning up the Symantec Management Agent when it is installed is no longer needed. Please refer to the following KBs:

KB 161011 "Preparing Windows 10 to run a 'Prepare for Image Capture' (sysprep) task using Deployment Solution 7.x/8.x"
KB 171149 "Preparing Windows 10 to run Sysprep through Ghost Solution Suite Capture Image Task"

Environment

DS 7.x, 8.x

Resolution

Problem

How can I image a computer with the Altiris Agent on it? What is needed to prepare the NS Agent when distributed as part of an image?

The Altiris Agent has a unique GUID for each workstation. If done incorrectly, when a new workstation is started with the same GUID as another, Notification Server will begin to manage it as if it is the same system as the other. Inventory from the multiple computers keeps over-writing each other, so systems "seem" to disappear from the NS/SMP console. MANY solutions are impacted by this.

Additionally, Microsoft OS's include a SID or Security Identifier which is unique, and is how Microsoft keeps systems separate in Active Directory. Like the GUID, if this is duplicated on the network, it causes significant problems in AD and we frequently have to refer customers to Microsoft for multiple days of cleaning up AD.

Prior to 8.0:

Resolution

Depending on the version or product you're using, there are several potential options.

Using GSS

Ghost Solution Suite has no built-in mechanism for removing the GUID's from NS. That said, if you have NS7, you most likely have DS7 and should follow the steps for imaging using DS7.

However, if you do not have DS7 (or do not intend on using it) then you can either remove the Altiris Agent prior to capturing the image (recommended) or manually remove the GUID from the Agent. The GUID is in 3 locations in the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\eXpress\MachineGUID
HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\eXpress\NS Client\MachineGUID
HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\MachineGUID

It should be noted however that the agent must be stopped for this to work. As soon as the agent re-starts, those registry keys will be repopulated! So, to do this, you should stop the agent service (leave it set to automatic), remove these registry keys, and immediately follow standard procedures in GSS to capture the image without restarting the system in production OR restarting the service.

Using DS 6.5/6.8/6.9

Any of the supported versions of DS 6.x will remove the GUID from the NS/SMP agent if capturing using the supported methods. The capture image task takes care of this for you by first removing the GUID from the agent and then running Microsoft's Sysprep tool, and then rebooting and capturing the image while in this state.

Using DS 7.x

DS 7.x takes care of this when you run the Prepare for Image Capture task (which is run prior to capturing the image itself). This is the only supported method of capturing a disk image (as apposed to a backup image). The Prepare for Image Capture task takes care of this for you by first removing the GUID from the agent and then running Microsoft's Sysprep tool Unlike DS 6.9, you then need to run the Capture Image task separately (before a reboot to production), but the net effect is the same.

Doing things manually (Unsupported)

There are those who insist on running Sysprep manually and only using our engine/tools (Ghost and RDeploy) to capture and deploy the images.

At least one reason for this is that there is a Microsoft Technet article that indicates that the "appropriate" way to modify the default profile is to run Sysprep in Audit mode and then modify the default profile prior to image capture. Our built-in processes do not support this. The default profile can be modified in several other ways that are supported by our processes, but we acknowledge that those methods are not "as complete" as the one indicated by Microsoft. 99% of our customers have been satisfied with the other methods of modifying the default profile and we highly recommend trying our method first. If you are then still not satisfied and insist on doing things this way, you should consider a few things:

IF the agent is included then the 3 registry keys indicated under the GSS method must be removed.
The Unattend.xml MUST be correctly managed by yourself. We continually see problems with this method in the XML files where there are issues with architecture and custom commands. Custom Unattend.XML files are not supported by Symantec, though support offers a best-effort level to help you find / identify problems with it.

NOTE: If you are using DS 7.x and attempting this method, the Agent should be included and the keys removed manually. This is a very awkward and again unsupported way of doing things, but in order to synchronize with post-imaging processes, we recognize the need to have the agent installed. You could actually install the agent post imaging, or follow the KB on including the installer into the Unattend file, both of which would work, but both of which will delay any post-image processes / tasks you may have included in the job. We recognize this as a viable process, but do not recommend it or support it, other than in a best-effort mode.

Not using Sysprep (Very Bad & Unsupported)

This is both not supported by us and not supported by Microsoft. Some have found a single article published once-upon-a-time by a Microsoft employee who claims that Sysprep is not needed. This is incorrect! Every customer we have found who has done this has required several DAYS of support from Microsoft to clean up their directory. We will send you to Microsoft when you run into problems and we will not be able to help you with your Active Directory (we can help with duplicate GUIDS, but be warned, it can be messy). For imaging to work in ANY of our environments, Sysprep MUST be run in some method or manner.

The only exception to this is if you are taking a backup image of a single system and restoring ONLY to that system. As soon as an image is deployed to more than one system without Sysprep having been run first, it is in an unsupported state.