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.
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.
SQL Server 2014