KNOWN ISSUE: complete replication takes longer and longer to run over time due to ever increasing createPXEimage Items

Article:TECH180093  |  Created: 2012-01-27  |  Updated: 2012-09-20  |  Article URL http://www.symantec.com/docs/TECH180093
NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.
Article Type
Technical Solution


Environment

Issue



There are a number of possible symptoms including:

  • Complete replication taks a very long time to run. In one case, the doubled in the past month.
  • Odd behavior of replicated PXE items, specifically deleted ones
  • Several remaining entries in the item and itemclass tables with no names.

Environment



ITMS 7.1 SP2


Cause



The deployment server clientprebootpolicychecker creates a CreatePXEImage item with each agent configuration request on the NS. This is based on the Targeted Agent Settings - "Download new configuration every:" schedule for "All Site Servers" schedule on the Notification Server.  ALL of these cumulatively, get replicated, and are never removed.  Thus, on a server that checks for a new policy every hour (default) there should be 24 of these created daily.  Over time, this adds up significantly, and if there are several child servers, the impact can be very real.

To Determine if you have this issue, you can run this very simple query against the database for the NS:

select Name, CreatedDate
from Item i
join ItemClass ic
on i.Guid = ic.Guid
where ic.ClassGuid = '7376ab64-1fa2-4781-b3ee-e04aea19fbc3'
order by i.CreatedDate desc


Solution



A fix for this issue will be included in ITMS 7.1 SP2 MP1) due early October 2012.

Point Fix and manual Workaround:

Attached to this KB is a ZIP file you should download and extract.  There are several files there that need to be installed into the GAC (manually - instructions are included here), then the old entries need to be removed, and all the services restarted (restart the computer).  All of these steps occur on the NS and/or SQL server, so be sure to plan carefully.  As usual, it's generally a good idea to have a backup before making changes to the server.

NOTE: UAC may completely block this process. You should disable this prior to beginning and re-enable later if need be.

Instructions:

  1. Run the query in the CAUSE section to be sure this fix applies to you.
  2. Download the attached ZIP file, and extract all files to a folder on the desktop (or a folder on the root of C if you prefer adding files to the GAC via Command Prompt).
    password = altiris
  3. On the NS, stop all the Altiris Services and stop IIS services (iisreset /stop)
  4. Remove the old DLL's as follows:
    1. Open a CMD window "as Administrator".
    2. Change directories to C:\Windows\assembly\GAC_MSIL\.  There's a subfolder here you need to change to called Altiris.Deployment\
    3. You need to remove the entire 7.1.2316.0__d3604070d7fd3e08 folder, though you should back up the files in that folder first in case you need to back out these changes.
      NOTE:  If the version is different, this fix may not work, so please check with support first!!
    4. Repeat steps 6 and 7 for the Altiris.Deployment.Utility and Altiris.Deployment.Common folders.
  5. Exit the Command Prompt and copy the new files into the GAC using Drag-and-drop in order to properly create the new folders and versions in the GAC.
    1. Open Windows Explorer to 'c:\windows\assembly'. Check to be sure there are NOT 3 deployment DLL's listed of the folder names you just removed. If they are still listed, this process will not work.
    2. Open a second instance of Windows Explorer to where you extracted the files in #3 (eg 'c:\dataloaded')
    3. Drag all the files from where you extracted them to 'c:\windows\assembly'. NOTE: The config files will show an error when copied. Ignore the error.
    4. Verify the files were installed correctly by browsing C:\windows\assembly for the 3 DLL versions to match the folders you removed. They should exist again with the proper version (2317)
  6. Restart the server to adopt the new DLL's and restart all services.
  7. Run the following query against the symantec_cmdb database to clear out all the old entries:
    --Send to ItemtoDelete
    Insert into ItemToDelete
    select i.Guid, GETDATE()
    from Item i
    join ItemClass ic
    on i.Guid = ic.Guid
    where ic.ClassGuid = '7376ab64-1fa2-4781-b3ee-e04aea19fbc3'
  8. From Task Manager, run the NS.Daily Schedule to process the entries you just placed in the ItemToDelete table.  You should be able to run the same query (starting at the Select instead of Insert) over and over and watch the entries disappear.
  9. To verify, you may then need to either wait for a full replication or force one to see if any problems persist.  For instance, you should see a faster replication process, and possibly other symptoms disappear.


NOTE: The files that are attached to this KB also resolve the issue documented in KB article TECH168065. 


Attachments

Contains files need to resolve the issue. See 'Solution' section below.
dataloaded.zip (346 kBytes)

Supplemental Materials

SourceETrack
Value2655086
Description

  CreatePXEImage items are being created whenever a new policy is requested, then orphaned in the database.



Article URL http://www.symantec.com/docs/TECH180093


Terms of use for this information are found in Legal Notices