Share via

Packages unable to replicate on Secondary Site

  • Article

Replicating the package on all primary/secondary sites is a very tiresome job. We face lots of challenges for getting the package copied to a hierarchy. Most of the time, we come across a package status -  “Install Pending”.

After looking into the log file, we find the following errors on secondary sites:

**Distmgr.log
**The compressed files for package SE100113 hasn't arrived from site SE1 yet, will retry later. The compressed files for package SE100011 hasn't arrived from site SE1 yet, will retry later. The compressed files for package SE10011B hasn't arrived from site SE1 yet, will retry later. The compressed files for package SE100114 hasn't arrived from site SE1 yet, will retry later.
 
Error in despool.log
Created retry instruction for job 0002DF38Despooler failed to execute the instruction, error code = 8 

To get the issue resolved, tried these steps.

1- Tried removing the package, and adding it again but it did not resolve the issue.
2- Found few package.try files in despool\receive on secondary site. Took backup of package.try from despool\receive(cut and paste to despool\receive\backup).
3- Also found that c:\smspkg did not show any compressed file for the above-mentioned package. It seemed that compressed package had not arrived on the secondary site.

But if the compressed package has not arrived on secondary, then why central site is not able to send it again? 
To get our answer, we accessed SQL Server Management Studio.

Specifically focused on package: Name: Dell XT3, ID: SE100113

First, we removed the package from secondary site (through console).

Ran the  following query: select * from pkgstatus where ID='SE100113' AND SITECODE='DE3'

It returned 1 row, with package status showing as 1. The meaning of status=1 means compressed package has already been sent. However, this is not true, we had already removed the package from console, there is no compressed package on secondary site either, so this value was preventing the compressed package to be sent again. 
There could be two resolutions to get rid of the issue:
1. Change the status=0 (which means none), so that if the package is added again through console, it will replicate successfully.
2. Simply delete the row with status=1, and clean up all the existence of package information from secondary site.

Proceeded with step 2 as we were sure this will give 100% because we are going to remove each and every traces of the package on secondary site.

These were the steps to clean the package info completely:

  1. Ran the query delete from pkgstatus where ID='SE100113' AND SITECODE='DE3'.
  2. Deleted SE100113.pkg & pkn from distmgr.box
  3. Deleted SE10113.ICO, SE10113.PKG, SE10113.NAL from pkginfo.box
  4. Delete SE10113.PCK from c:\smspkg (in my case it did not exist)

Added the package again through Console.
After waiting for some time, package got replicated successfully. Hence, the issue was resolved. In pkgstatus table, you will see a column name “status”. Here are the possible status codes and their meaning for pkgstatus table: PKG_STATUS_NONE 0
PKG_STATUS_SENT 1
PKG_STATUS_RECEIVED 2
PKG_STATUS_INSTALLED 3
PKG_STATUS_RETRY 4
PKG_STATUS_FAILED 5
PKG_STATUS_REMOVED 6
PKG_STATUS_PENDING_REMOVE 7 // Not used.
PKG_STATUS_REMOVE_FAILED 8
PKG_STATUS_RETRY_REMOVE 9 
So, if a package is copied to DP, you will see 2 entries:

  1. With column “Type: 1”= This will show you the status of the compressed file (.pck), it will show you column status=2 (which means that compress package has received in  c:\smspkg\packageid.pck or d:\smspkg\packageid.pck)
  2. With column “type:2”= This will show you the information package copied on DP, it will show you column status=3 (which means package got installed on this site, and the package has successfully able to uncompress and copied it to c:\smspkgc$\packageid or d:\smspkgd$\packageid)   http://c.statcounter.com/9828593/0/1552348f/0/