The path to hundreds of packages in the library was changed but packages still point to the old path.

Products

• IT Management Suite

Issue/Introduction

Problem Scenario:

• The Software Library configuration was originally set up to point to the UNC path. Hundreds of Software Releases etc. were created and pointed to sub folders that were under the following UNC path:

\\servername\Software Library

Example:  \\servername\Software Library\85d2b26b-c68f-40b5-bb26-09d8712d1ef8\

• Due to a pending hardware failure—it became necessary to relocate the Software Library to another server/location. 

• The entire sub folder structure of the current library and their contents were copied to the following share path, and the Software Library was reconfigured in the console to point to the same path:      \\Servername\Software Library\

• After copying the library files to the new server the old server was taken down.

• When the SMP attempted to run the NS.Package Refresh schedule, or the NS.Package Distribution Point Update Schedule a warning and error similar to the following (excerpt) was seen in the SMP logs.

Unable to manage the distribution points for package: 'WireShark 1.4.0 Package'  WireShark 1.4.0 Package (85d2b26b-c68f-40b5-bb26-09d8712d1ef8~) An unknown error has occured while accessing path '\\SMPServername\Software Library\ WireShark 1.4.0 Package (85d2b26b-c68f-40b5-bb26-09d8712d1ef8~) .

Unable to refresh the codebase information for package: 'WireShark 1.4.0 Package'  WireShark 1.4.0 Package

(85d2b26b-c68f-40b5-bb26-09d8712d1ef8~) An unknown error has occured while accessing path '\\SMPServername\Software Library\ WireShark 1.4.0 Package (85d2b26b-c68f-40b5-bb26-09d8712d1ef8~) .

The errors identify the path that can no longer be accessed.

Now, it would be easy enough to edit an individual package and change the path to the correct location; but it became very difficult when having to do this for hundreds or even thousands of packages.

Environment

Management Platform 7.6x, 8.x

Cause

Existing packages retain their original properties and path references after the Software Library has been changed.

Resolution

With recent releases, we have added ways to minimize this type of issues about moving package locations:

1. About Software Library UNC location

If there is the same UNC path specified (if you needed to move this shared folder from drive C: to another drive) then the SMP Server will access it and will see same folders structure and expected folders with GUIDs of previously uploaded Software packages in library.

Example when Software Library UNC path is \\servername\foldername

In case if you are using UNC path as ServerName\DriveLetter$\SharedFolderName (\\Imagexserv\S$\SW Library test), then on attempt to change it, we offer different options to perform this change with existing packages. 
Example when you had Software Library path with shared folder on C drive but now going to change it to S drive for same shared folder name (Shared Software Library folder is already uploaded to S:\ drive then you will need to use option "Change existing packages").

2. For Patch Management solution, there is a similar way when you copy existing "Updates" main folder from "C:\Program Files\Altiris\Patch Management\Packages\Updates\" and upload this folder on another drive.

After this, set another location for patch updates on "Core Services" console page.

NOTE: Workaround in case you need to clean up / adjust the path for some other type of packages: 

Attached to this article is a SQL script (Script to change path to packages.sql) that can be run against the database. 

Usage:

• As with any script that externally modifies the database it is IMPORTANT to have a recent backup of the database before proceeding.

• Open SQL Management Studio on the database server (or wherever it is installed) then copy and paste the content of the script into a window pointing to the SMP’s database.
• If you wish to modifiy a specific package change the variable "@packageId " from  '00000000-0000-0000-0000-000000000000'   to the Guid of the desired package. If you do not then the script will assum you want to search for the old path and change it to the new path in all packages.

• Modify the @oldPath and @newPath variables in lines 3 & 4 to reflect what the script is looking for, and what it will be changing.

Example:          

If you are uncertain what to put in, run the following script first. It will return all packages with a XML link in the far right “State” column.

If you click on the XML link it will show the current properties of the package. Look for what is set in the “location=”node of the XML.

select Guid, Name,CAST(state as xml) State

from vRM_Package_Item

order by Name

• Once the correct old name or path pattern is identified and the new path is set then execute the script.

Note: If you want to do a controlled test to see if it is doing it correctly uncomment the last line and put in a valid GUID (returned by the query above) and it will only change the one package.

After executing against the one package, run the above query again, click on the XML link for that package and verify if the path is correct. If so then remove the last line or comment it out again and run the script. It will change every package object in the database where if fines an exact match for the @oldPath variable and change it to the value of @newPath.

Suggestion 2:

The following suggestion applies to only one package that needs to be updated with a new server name as its primary location.

1. Identify the GUID for the package:

select * from RM_ResourcePackage_Item
where name like '%mypackagename%' 

2. Using the GUID found with the query above, verify the current path by opening the link generated by this query: 

select Guid, Name,CAST(state as xml) State
from RM_ResourcePackage
where guid = '6C9A1F51-90DD-40F6-BAFB-759AA2E0A110' --Example GUID. 

3. Run the following query to update the server name:

--begin tran
declare @oldRootPath nvarchar(50) = 'OLDPS1-Altiris'
declare @newRootPath nvarchar(50) = 'NEWPS2-Altiris'
declare @packageId uniqueidentifier = '6C9A1F51-90DD-40F6-BAFB-759AA2E0A110' --current package GUID

UPDATE RM_ResourcePackage

SET [State] = replace(cast([State] as nvarchar(max)), 
                @oldRootPath, 
                @newRootPath), 
                
                ModifiedDate = getdate()

WHERE Guid = @packageId

UPDATE RM_ResourceSoftware_Package

SET [State] = replace(cast([State] as nvarchar(max)), 
                @oldRootPath, 
                @newRootPath), 
                
                ModifiedDate = getdate()

WHERE Guid = @packageId

--commit tran

4. Run NS.Package Refresh from Task Scheduler on your SMP Server

5. Verify that the new server name is used on the package source by following step 2 above on this section.