Retiring package server that was originally hosting image captured packages
search cancel

Retiring package server that was originally hosting image captured packages

book

Article ID: 227791

calendar_today

Updated On:

Products

Deployment Solution

Issue/Introduction

Scenario:

  1. The customer has a package server (PS), PS008, that is old and he is replacing it with a new server. New server, new hostname.
  2. The new package server, PS010, is up and running. He adds the same Sites that the original PS had. So, the customer turned off the old PS.
  3. Now, client machines can't receive the image packages because the image references still point to PS008, the original PS.
  4. When he goes to the SMP Console under Settings>Deployment>Image Management, all the "package Location" for all his images refers to "\\PS008\....." path. 
  5. When he looks at the same image packages on the new PS, all of them say "Ready" but there is no "Cache" folder created under the Package Delivery folder.
  6. When he checks the image package "Download History" tab on the new PS, it shows PS008 as the "Source Location".
  7. Another package server, PS009, has the image packages Ready and a Cache folder with the files. However, this server is going to be retired too. So, PS009 is the only package server that still has a copy of their image packages.

 

We would like to know the appropriate way to get PS010 (the new package server) ready with every image package and have them downloaded so PS008 and PS009 can be gone completely and be still able to image using the new package server.

Environment

ITMS 8.5 RU4, 8.6, 8.7.x

Resolution

Scenario 1: When the Package Server owning the image package is still available

If the image is owned by a Package Server then this Package Server is the source of that image and all other Package Servers are downloading this image from this owner.

If the customer wants to dismiss the Package Server which owns some images, then he/she should transfer image ownership to some other Package Server:

  1. Go to owner PS and find the package with a blue icon. This means the package is a "Locally managed" package.


  2. Go to "some other" PS which will be the new owner. Find the very same package, it should be with yellow icon "Externally managed".
  3. Ensure it has a package downloaded and has proper size, status, etc.  
  4. Expand the "Package Tasks" section and choose the "Take ownership" link.
    |Note: Before making "Take ownership" you must be sure all the files in the package are OK. If the package becomes "Locally managed" then there is nowhere to download from, since now it is where this package originates. If you delete files from the "Locally managed" package and run refresh, a new snapshot will be created based on the current package content on the disk. So if you convert an empty package to "Locally managed" now, it will be empty. To fix You could copy the files "by hand" from somewhere and put those in the package directory, and then run refresh. This should help. Check the snapshot.xml after the refresh, it should be generated with the files.

    The action is done silently, so do not be afraid of no immediate UI feedback. You could search for "CreateExternalPackage" in the logs for more details.
  5. Update delta membership on NS and refresh policies on both Package Servers.
  6. The package should change status on PS1 from blue to yellow, on PS2 from yellow to blue. Now the image is owned by the second PS.
  7. After all ownerships of all images are transferred to new Package Servers, the legacy PS could be dismissed.



    Note:
    One more step to consider during migration of the External Images Packages – make sure that according to the Image Management page (under the SMP Console, Settings>Deployment>Image Management  -OR-  Settings>All Settings>Deployment>Image Management)

    there are no more packages owned by the old Package server (by typing the name of the old PS into the Search box):

     

  8. ‘Legacy images’ are not shown in the Package Server UI. They need to be converted to the managed format and then migrated to the new Package Server.


    The following is provided just as reference of what to do in order to re-import your images if you also are moving the SMP Server to a new server.
    More details about the image conversion are provided in the ‘How To Re-Import Image Files After Migrating To A New SMP Server’ online documentation:

    ------------------------------------------

    Deploying affected images and PCT (PC Transplant) packages:

    Deployment Solution (DS 8.5 RU4 introduced “Image Management” (https://techdocs.broadcom.com/us/en/symantec-security-software/endpoint-security-and-management/it-management-suite/ITMS/Related-Solutions/Deployment-Solution/Removing-Unwanted-Packages-and-Resources/Managing-Images.html), so using ‘Resource Import Tool’ is not needed.

    1. Copy the affected Ghost images and PCT packages from "\\localhost\NSCap\bin\Deployment\Packages\Images" and "\\localhost\NSCap\bin\Deployment\Packages\PCT" from the old ITMS server and copy them to the same location on the new ITMS server.
    2. Open “Image Management” on the new ITMS server.
    3. Find the affected image, select it, then click ‘Package Details’ button:


    If the button is disabled, then the image is not associated with any package yet (legacy image). In this case, click the icon ‘Convert the selected legacy image to a manageable format’


    If the conversion fails, check NS logs to see if the image refers to some not existing location, and create an empty one if needed.

    1. In the ‘Package Details’, update the path by updating ‘Package location’ to point the same package but on the new ITMS server (from ‘step 1’), then click Save changes.




    2. Repeat the steps 3-4 for all the affected images.

     

    Now the affected images can be used in the tasks. 

    Alternatively, the images can be re-imported using Resource Import Tool:

    1. Open “Image Management” on the new ITMS server
    2. Find the affected Ghost image, select it, then click the ‘Convert the selected legacy image to a manageable format’ icon.

    If the icon is disabled, then proceed with the next step.

    If the conversion fails, check NS logs to see if the image refers to some not existing location, and create an empty one if needed.

    1. Select the affected image, then click the ‘Delete’ icon.
    2. Repeat steps 2-3 for all the affected Ghost images. Do not delete PCT packages as they cannot be imported via Resource Import Tool.
    3. Go to Package Server, then launch <install_path> \Altiris Agent\Agents\Deployment\Tools\ResourceImportTool.exe (available after installation of ‘Deployment Package Server Components’).

    If there are no Package Servers, or if Ghost images need to be stored on NS, then launch <install_path> \Deployment\Tools\ResourceImportTool.exe on NS.

    1. Re-import all the required Ghost images.

      “Affected Ghost images and PCT packages” are the ones that are stored directly on NS.

    By default, all Ghost images and PCT packages are stored on PS.

    Since the Package Servers don’t change in the described scenario, the remaining images don’t require additional post-migration steps.

     

    There is also one additional DS-specific step that needs to be performed after migration to the new hardware:


    NS Connection profile in Preboot Configurations page might need to be changed (and then Preboots would need to be rebuilt) after the migration if it points to the old SMP server.



 

Question:
Would be then necessary to "Take ownership" of the image packages on PS009 (wait for the process to finish) and then "Take ownership" of those packages on PS010 since also PS009 will be decommissioned?

Yes. There should be an owner for other Package Servers to be able to download it.

Question:
on PS009 (still one of the remaining old PSes), we choose an image package and did "Take Ownership". After a bit, this package changed to "Locally Managed".
One thing that we are not sure if it was set that way but on PS010 (new PS with no Cache files for image packages) that same package was marked for Deletion after PS009 took ownership. We checked on 'SMP Console>Settings>Deployment>Image Management>Select the testing image>open the image settings' and we saw that under the "package servers" tab, just the PS009 showed as the assigned package server instead of "All Package Servers" 

"Take ownership" does not change any assignment on NS, it just changes the owner of the package. The fact that this setting exists, means this was done before by someone, and this explains why files were deleted from PS010. It could have received this policy earlier and deleted the package files.


Now you need to put the assignment back, so PS010 will be able to download the package and then "take ownership" of it.


Scenario 2: When the original package server is no longer present

Question:
Can we use ResourceImportTool if we don't want to follow this process described above or when the original package server is no longer available?

Images can also be imported via ResourceImportTool.exe, however it creates new image resources, and cannot replace existing ones. Default location of ResourceImportTool on PS is "C:\Program Files\Altiris\Altiris Agent\Agents\Deployment\Tools\ResourceImportTool.exe" if Deployment Solution Package Server is installed. If the original package server is no longer available but there is another package server that still have a downloaded copy of the image package(s) file(s), you can use the ResourceImportTool.exe to grab the files from that existing location.

Note: Running the ResourceImportTool.exe tool on the new package server flags the package as Locally managed . The ResourceImportTool.exe tool adds the image-captured package as a new image to the existing list of images, and will not reference existing GUIDs, as there is no option in the ResourceImportTool.exe tool for GUID selection. 

 

Question:
If I run the ResourceImportTool on the new package server, by doing that also makes the package to be flagged as "Locally managed"? 
Adds the files and uses the same GUID as previously referenced for that same set of files for the package that is missing the files under the Cache folder?
Or creates a new whole image package reference on the SMP that will be listed as a new image reference under Image Management in the SMP Console?

It will add it as a new image to the existing list of images and will not reference existing GUIDs as there is no option in ResourceImportTool for GUID selection.
Running the ResourceImportTool.exe tool on the new package server flags the package as Locally managed . The ResourceImportTool.exe tool adds the image-captured package as a new image to the existing list of images, and will not reference existing GUIDs, as there is no option in the ResourceImportTool.exe tool for GUID selection

Powered by Wolken Software