The SMP server is not building package codebase download links for itself.

Products

IT Management Suite

Issue/Introduction

When the NS.Package Refresh schedule is run it is supposed to build and or maintain package download links for the packages it owns, which the server stores in the table swdPackageCodebase

If the download codebases do not exist then neither package server or regular client agents will be able to download packages for which they are given advertisements to download. Instead they will log the following warning to the agent log when they request information about the package:

No package sources returned by server (-2147023728).

Environment

ITMS 7.6, 8.0, 8.1, 8.6

Cause

When the process to build and refresh packages is initiated the server runs the stored procedure spItemNSSourceSelect against each package being evaluated. If the package is determined to have come from a foreign source the process ignores the package and does nothing with it.

Sometimes if an NS has been through a reconfiguration, during the process it may have generated a new GUID for the server. The GUID will be stamped in the value of OwnerNSGuid contained in:

C:\ProgramData\Symantec\SMP\Settings\CoreSettings.config

The server’s new GUID is then stamped, along with a numeric ID in the table OriginNSSourceNS. This table’s primary purpose is to track the source and origination servers of objects in a Hierarchy configuration. But, standalone servers go through the same vetting process as it relates to objects, which is usually where they get tripped up if the GUID has changed since the initial installation.

In this case it is package objects that the NS is trying to resolve for the source and or origination servers, and the value it gets back for each package is not interpreted as that of the local NS.

Resolution

TROUBLESHOOTING:

1. Open the file C:\ProgramData\Symantec\SMP\Settings\CoreSettings.config and search for OwnerNSGuid and copy the GUID that is in the “value” element. To notepad or a text editor

Example: 8b53108b-f9d6-491e-86e6-6473ed5eb57e

OwnerNSGuid" type="local" value="{8b53108b-f9d6-491e-86e6-6473ed5eb57e}

Check that the value matches with the one on the database. You can run the following query:

select osns.Id as [Server ID], vtns.guid as [Server GUID]

from OriginNSSourceNS osns

join vThisNS vtns on vtns.Guid = osns.OriginNSGuid

and vtns.Guid = osns.SourceNSGuid

2. Using SQL Management Studio, run the following SQL query against the database

select distinct

p.Name,

fs.Id as [Server ID],

fs.name as [Source NS],

osns.SourceNSGuid as [Source Guid],

fs2.Name as [Origin Server],

osns.OriginNSGuid as [Origin Guid],

cb.cnt as Codebases

from swdPackage p

join ItemNSSource ns on ns.ItemGuid = p.packageid

join OriginNSSourceNS osns on osns.id = ns.OriginNSSourceNSId

join ForwardServer fs on fs.Guid = osns.SourceNSGuid

join ForwardServer fs2 on fs2.Guid = osns.OriginNSGuid

left join

(select PackageId, cnt=COUNT(*)

from swdpackagecodebase

where [Source] is null

group by PackageId

) cb on cb.packageid = p.packageid

where p._latest = 1

order by p.Name

3. The previous query will return detailed information about the known packages. The last column in the query, “Codebases”, will show either a numeric value or NULL.

As per the following graphic you may notice packages where the server is the same as all of the others (or another server’s name is displayed). Usually, if the “Codebases” column is NULL then the [Server ID] value will be different than those where the “Codebases” column has a numeric value.

You will also usually notice that the GUID in the “Source Guid” column, where the “Codebases” column has a numeric value, is the same as the OwnerNSGuid in CoreSettings.config.

(a) If there is a difference in the values of the “Server ID” between packages where Codebases are NULL and those that have a numeric value, then this means that the packages with NULL codebases need to be assigned to the server ID that is aligned with the GUID in CoreSettings.config

(b) If all packages show a NULL value in the codebase column then copy the GUID found in CoreSettings.config and plug it into the @Guid value of the following SQL query and run it.

declare @Guid uniqueidentifier

set @Guid = '8B53108B-F9D6-491E-86E6-6473ED5EB57E'

select distinct osns.Id as [Server ID], fs1.Name as [Source Server], fs1.Guid as [Source Guid], fs2.Name as [Origination Server], fs2.Guid as [Orination Guid], COUNT(*) as [Count]

from ItemNSSource ns

join OriginNSSourceNS osns on osns.Id = ns.OriginNSSourceNSId

join ForwardServer fs1 on fs1.Guid = osns.SourceNSGuid

join ForwardServer fs2 on fs2.Guid = osns.OriginNSGuid

where @Guid = osns.OriginNSGuid and @Guid = osns.SourceNSGuid

group by osns.Id, fs1.Name, fs1.Guid, fs2.Name, fs2.Guid

The value in the “Server ID” column is the ID the server is operating on and needs to be changed for packages it owns and should be maintained.

SOLUTION

1. If the NS is in a Hierarchy then make note of what ID the packages that are not getting built is (previous example was 16) and plug the value of the value the NS should be using into the following SQL script and run it against the database.

update ItemNSSource

set OriginNSSourceNSId = 1 -- The ID the server seems to be operating under

where OriginNSSourceNSId = 16 -- The ID that seems to be incorrect

2. If the NS is a standalone configuration, and is not in a hierarchy then plug the server ID the NS should be operating under into the following SQL and run it against the database to make the NS the sole custodian of all objects in the database.

update ItemNSSource

set OriginNSSourceNSId = 1 -- The ID the server seems to be operating under

where OriginNSSourceNSId <> 1

Run the “NS.Package Refresh

NOTE: As with any situation where external manipulation of the database is to be performed it is strongly suggested that a backup of the current database be captured prior to performing these changes.