DS 8.x image information regarding Storage, Replication and Removal

Sections in this KB

1. Where can we find our captured Images?
2. How are they replicated to Site Servers & what role do we need to play in this?
3. How are images replicated in a Hierarchy?
4. How do we remove images we are no longer using?  What about images that are partly removed already?
5. What are other helpful considerations?

Where can we find our captured images?
There are actually a number of factors that affect the answer to this, including a version of Deployment Solution.

In DS 8.x, the process is very similar, except that the image will be captured to the nearest Package Server in the default Package Delivery folder.

If you are capturing a default image type (not a backup image) the image will then appear as a package within the Deployment and Migration settings under Settings | All Settings in the Images subfolder.  This image will include the path specified above by server\share.  NOTE:  The server to which the image is captured is considered the package "source."  This is very important later.

If you capture a Backup image, the image will not appear as a package in the console in the same location.

Both scenarios/types will create a new image resource which can be found under All Resources.

How are images replicated to Site Servers & what role do we need to play in this?
By default, all Capture Images are configured to be replicated to all package servers.  Normal Package Replication takes care of replicating and there should be no manual input required under normal circumstances.  Every site server that uses DS is configured with a Deployment Share, and the image will be placed in the same location on all site servers.

There are some caveats to this:

• If the image was captured on a Site Server and NOT the SMP, by default the image will not be replicated to the SMP, because the SMP is not (should not) be a Package Server.
• If the image captured is a Backup Image, it will not be replicated at all.  This is by design since the assumption is that a backup image is destined only for the computer from which it was captured, and thus need not be present in all locations.
• If the image was captured on the SMP, it will in fact replicate out to all Package Servers as well.
• If you want to reduce the number of package servers the image is replicated to, this must be done manually by editing the image in the console under Settings | All Settings \ Deployment and Migration\Disk Images.
• Imported images using the resource import tool are always copied to the SMP as if captured locally on the SMP.
• If the image was captured on a Site Server and you would like it to be "re-homed" to the SMP as the package source, there is no automatic way to do this - the image must be imported as a new image and the original then deleted. (see above - where an image is captured is the package "source")

Possible Workaround(s) for an image that is NOT on the NS (captured on a Site Server)

• Import the image to the NS. The DS Import utility (ResouImportTool.exe) can be used to import any image we support, either from the current release (e.g. another server) or from a previous release (e.g. GSS 3.3), and will create a new resource for it. If you were to do this for an already created resource, the image would be essentially duplicated, though you could give it a new name. Once imported though, the image now resides on the NS. And the old one should be removed.
• Copy the image to the NS (Recommended). If you simply copy the GUID folder with the image into the Task handler\Images folder, the image will then be on the NS. Problem solved.
• Copy and re-home the image to NS (Recommended for perfectionists). This is the same as copying the image to the NS but includes another step - re-homing the image. To do this, you go to the console, find the image under Settings | All Settings \ Deployment and Migration\Disk Images, and modify the source location to point to the NS instead of the Site Server. Only the server name needs to be changed to do this. Save changes, and wait for the daily tasks to run (overnight by default) and it is now re-homed.

How are images replicated in a Hierarchy?
The short answer is "not well" but some things work:

• Images are only supported when replicated DOWN in a hierarchy.
  • They also replicate up, but not correctly.  A closer look will reveal that the images are considered Software Resources in the Hierarchy at this time, and therefore follow Replication rules for all software packages.  Thus, you'll actually see the image resources appearing up the tree.  When the images are replicated though, they are not added to all the appropriate tables in DS and are not usable on top.
  • Though they do replicate down, they attempt to check into the parent, because that's where they were captured.
• Scripted OS Install (OSI) packages are the same as images.
• As with all packages, replicated packages travel from package servers to package servers. Images captured on a parent NS will not go to the child NS itself, only to the Package Servers reporting to the child NS.

In 8.x, we will recommend that you do everything in a single-server "mode" of thought, and no longer "support" images replicated in a hierarchy.

RECOMMENDATION:  Don't try to use images in a hierarchy.  Jobs and tasks possibly, but the best way to have successful imaging is one server at a time.

How do we remove images we are no longer using?

First, a few comments:

• Images have, essentially, four components, as follows:
  • Image Resource (what you should delete, NOT the others)
  • Image Package Resource
  • Image Package
  • Image files
• The most common problem in removing images is removing parts, but not all of the components, most commonly the Image Package.
  • If one piece is missing, finding the others can be tricky.
  • Direct SQL access may be necessary in some instances to correctly remove images.
• There is, currently, no automated method of deleting an image completely.

Recommended: To remove an image in the simplest way possible:

1. First gather some information (very important, as this will not be available after step 2)
   1. What is the image name?
   2. What is the image location (including source server name, and path (with GUID)? This is found in Settings | All Settings \ Deployment and Migration \ Disk Images
   3. What is the image GUID?
2. Then, delete the Image Resource. From the Symantec Management Console, open up the 'Default Organizational View', look under the sub-tree of 'Software Component', and then 'Image Resource'. Here you will find a list of images, and should delete the resource for the image you are attempting to remove.
   1. If there is more than one with the same name you may need to use SQL to find which is which, but often the Date of the resource can tell you. Double-click the image and the Image Resource to see Resource Explorer and compare the date of creation to find a match. If they're too close, SQL can be used to better align the two.
   2. Note! This will take it out of the Deploy Image list. If removed only via the next step, it will still show up in this list, even if the image appears gone.
3. Finally, remove the actual image files by browsing to the source computer\deployment\task handler\images\ and remove the GUID folder noted in 1b above (will also remove the image). You should probably verify it has the right image in it.
4. At this point, package replication should take care of the rest and wipe out the images, but it may not. If not, you will have to remove the same GUID folder from all package servers. This could be done with a script.

What are other helpful considerations?
Probably the most important thing to know is how to maintain your images, which has two important aspects:

1. Space considerations.  Remember that all images are stored under the Altiris Agent folders, and at this time you can't control where they are replicated.  The only way to control this is with HTTP imaging (which only stores in one location with no replication) or a custom script task (where you call Ghost 'manually') which you can send to anywhere but you then lose all automated control via the console for replication.  Be sure your agents on your Task Servers have ample room for all of your images.
2. Source Locations.  For this issue, you need to understand the basic concept of a "package" in NS.  A Package has a source location upon which all destination locations are based.  As the source is updated, all destinations are updated as well, thus keeping everything in sync.  Updates include additions to files, modifications to files, and deletion of files.  The latter is the problem.  If you decide to "save space" on a Site Server by deleting an image, and it's where you captured it from, you run the high risk of removing the image from all locations in the very near future as package replication does what you told it to do and updates all the destinations with an empty package.
   
   Thus, as a good "rule of thumb," you may want to consider moving the source location of images to the NS or a "stable" environment soon after capturing them.  The process to do this might be something similar to this:
   1. Capture the image on a Site Server
   2. Using the Import tool for DS, import the image to the NS from the Site Server.  This will create, essentially, a duplicate package, but will copy the file to the NS.
      • Alternatively, you could copy the image to a storage location, either on or off of the NS, and import it from there.
   3. Remove the original package and then the original files (once you are sure of the file copy.
   4. Allow package replication to send out the new image from a more stable source out to all Site Servers.