Package Server reports packages as ready but Notification Server shows them as invalid
search cancel

Package Server reports packages as ready but Notification Server shows them as invalid

book

Article ID: 179719

calendar_today

Updated On:

Products

IT Management Suite Software Management Solution

Issue/Introduction

The SMP Server (Symantec Management Platform) console shows one or more Package Server's packages as invalid, but the Package Server Console on the Package Server itself shows those same packages as ready. When you create a new test package and confirm the Package Server downloads it and marks it as available, the NS initially shows it as pending, then changes it to invalid once it receives the status report from the Package Server.

Symptoms

One or more of the following are present:

  • The SMP console shows packages as invalid for a specific Package Server while the Package Server agent shows them as ready.
  • The agent.log on the Package Server contains the following errors:

    <event date='May 16 11:51:05' severity='2' hostName='xx100' source='CreateDirectoryPath' module='AeXNSAgent.exe' process='AeXNSAgent.exe' pid='724' thread='1740' tickCount='495844828' >
      <![CDATA[Cannot create directory: 0x80070005 [Access is denied] d:]]></event>
    <event date='May 16 11:51:05' severity='2' hostName='xx100' source='EventTransport' module='AeXNSAgent.exe' process='AeXNSAgent.exe' pid='724' thread='1740' tickCount='495844843' >
      <![CDATA[Error while copying event to capture directory: Access is denied (-2147024891)]]></event>

  • Every package shows the following error when Send Package Status is run, recorded in the Package Status NSE file and in the SWDPackageServer table:

    The trust relationship between this workstation and the primary domain failed(1789).

  • Inspecting NTFS permissions on .\Package Delivery\<GUID> directories on the affected Package Servers shows only the Administrator and SYSTEM accounts — the configured credential account is absent.

Environment

ITMS 8.x
Package Servers

Cause

The Package Server agent failed to apply the credentials configured in the SMP Console under:

Settings > Notification Server > Site Server Settings > Site Server Settings tree > Package Services > Package Service Settings > Security Settings

This prevents the Package Server from authenticating correctly when reporting package status back to the SMP Server, causing the SMP Server to mark those packages as invalid. A secondary cause is the configured credential account missing NTFS permissions on the Package Delivery directories, which prevents the agent from writing status files even if the credential is applied.

Resolution

How it works

Understanding the credential flow helps identify where this failure occurs.

The NS stores the Package Service credential configuration centrally under: Settings > Notification Server > Site Server Settings > Package Services > Package Service Settings > Security Settings

Three credential options are available:

  • Anonymous access — default; no credential required for package delivery
  • Application credentials (AppId) — uses the SMP application identity account
  • Agent Connectivity Credentials (ACC) — a dedicated local account created and managed by the SMA on each site server

When a credential option is configured, the NS distributes it to Package Servers via the Client Settings Policy. The Package Server agent receives this policy, applies the credentials to its package delivery service, and then reports its package status back to the NS using an NSE file. The NS processes this NSE and updates the SWDPackageServer table. The console reads from this table to display package status.

Common failure points in this flow:

  • The Package Server agent did not receive or apply the updated Client Settings Policy, so it is still operating with stale or absent credentials.
  • The configured credential account is missing NTFS Full Control permissions on the Package Delivery directories, so the agent cannot write or report status.

The NSE containing the status update fails to reach or be processed by the NS, leaving the SWDPackageServer table with stale invalid status even after the credential is corrected.

In order to address this issue:

Run Procedure 1 first. If the NS still shows packages as invalid after completing Procedure 1, continue to Procedure 2 to clear stale snapshot and status files.

Procedure 1 — Reset credentials and resynchronize status

Before you begin: Confirm which credential type is configured under Settings > Notification Server > Site Server Settings > Package Services > Package Service Settings > Security Settings. The steps below reset and re-apply whichever credential type is active.

  1. In the SMP Console, request a new Client Settings Policy for every Package Server. This ensures all Package Servers start from a known policy state before credentials are reset, without affecting Package Servers that are functioning correctly.
  2. Under Package Service Settings > Security Settings, configure the credential to Anonymous access. This resets the Package Server agent to its defaults and clears any stuck credential state.
  3. Request a new Client Settings Policy for every Package Server that is showing invalid packages.
  4. Under Package Service Settings > Security Settings, re-configure the Agent Connectivity Credentials (ACC) or AppId as required by your environment.
  5. Request a new Client Settings Policy for every Package Server that is showing invalid packages. This second policy request pushes the restored credential to the Package Servers after the reset in step 2.
  6. On each affected Package Server, verify that the configured credential account has Full Control NTFS permissions on:

    C:\ProgramData\Symantec\Symantec Agent\Package Delivery\
    If the account is absent, add it with Full Control before proceeding. See Setting up Agent Connectivity Credential (ACC) and Best Practices (KB 194234) for ACC-specific permission requirements (Best Practice #2).

  7. On each affected Package Server, send a Package Status to the NS:

    • Right-click the SMA tray icon > Symantec Management Agent Settings
    • Select the Package Server tab
    • Click Resend Package Status
  8. In the NS console, confirm the affected Package Servers now show packages as Ready.

Procedure 2 — Clear stale snapshot and status files

Run this procedure only if Procedure 1 did not resolve the invalid status. This procedure manually re-synchronizes the snapshot files between the NS and the affected Package Servers.

Warning: Deleting snapshots on the NS causes all clients to download new versions of those snapshots on their next configuration update, which can generate significant IIS and network traffic. Delete only the snapshots for the affected packages, not all snapshots, unless all packages are affected.

On the SMP Server:

  1. Navigate to the NS Snapshots folder:
    C:\ProgramData\Symantec\SMP\Snapshots\
  2. Delete the {GUID}.xml snapshot file for each affected package (identified by package GUID).
  3. Run the NS.Package.Refresh scheduled task:

On each affected Package Server:

  1. Navigate to the Package Delivery folder:

    C:\ProgramData\Symantec\Symantec Agent\Package Delivery\

    Delete the snapshot.xml file from each <GUID> subdirectory for the affected packages.

  2. Navigate to the Package Status folder:

    C:\ProgramData\Symantec\Symantec Agent\Package Server Agent\PackageStatus\

    Delete the PackageStatus.xml file from each <GUID> subdirectory for the affected packages.

  3. Force the Package Server to download the updated snapshots from the NS:
    • Right-click the SMA tray icon > Symantec Management Agent Settings
    • In the Configuration section, click Update
  4. Resend package status to the NS:
    • Right-click the SMA tray icon > Symantec Management Agent Settings
    • Select the Package Server tab
    • Click Resend Package Status

Verification

After completing either procedure:

  1. In the NS console, navigate to the Package Server status view and confirm that the previously affected Package Servers now show Ready for all packages.
  2. Run Send Package Status on one affected Package Server and confirm no trust relationship or access denied errors appear in the agent.log.
  3. Open Registry Editor on an affected Package Server and confirm the Package Service is running under the expected credential (or anonymous, if that is the configured mode).
  4. Optionally, run the following SQL query against the Symantec_CMDB database to confirm no packages remain in a non-Ready state for the affected Package Servers:
SELECT
     vi.[Name]          AS 'Package Server'
    ,pack.[Name]        AS 'Package Name'
    ,ps.[Status]        AS 'Status'
    ,pack.[Package Version] AS [Package Version on NS]
    ,ps.Version         AS [Version Last Reported by PS]
    ,ps.[PackageId]     AS 'Package GUID'
FROM SWDPackageServer ps
JOIN vItem vi
    ON vi.[Guid] = ps.[PkgSvrId]
JOIN SWDPackage pack
    ON pack.[PackageId] = ps.[PackageId]
    AND pack.[_Latest] = 1
WHERE ps.[Status] != 'Ready'
ORDER BY vi.[Name], ps.[Status]

A result set with no rows confirms all packages on the affected Package Servers are now reporting as Ready.

Additional Information

 

Powered by Wolken Software