ConfigMgr 2007 CI replication issue

The following is a guidline to resolving CI replication issues – If you are unsure then don’t change things without asking for advice!
Summary of steps:

• Backup the site and the DB.
• Uninstall the SUP
• Delete data from CI_configurationitems and CI_sdmpackage tables so you have 0 rows in the first table and 12 schema rows in the CI_Sdmpackages table.
• Clean the of old files.
• Rename the objreplmgr.dll to objreplmgr.dll_old (stop and start services to do this).
• Wait for the files to replicate from the Central site (the .SHA file will disappear when this has finished).
• Rename the objreplmgr.dll and wait for the replicated files to be processed.

Detailed steps:

1. Backup the SCCM database! If anything goes wrong with the actions below then we can roll back to the latest backup.

2. Uninstall SUP on the primary site. This would trigger all the updates to get marked as expired in the SCCM DB. The following queries can be checked to see when that’s been done and to track the progress, however this may take some time:

SELECT COUNT (*) AS TotalCIs FROM CI_ConfigurationItems
SELECT COUNT (*) AS Expired FROM CI_ConfigurationItems WHERE IsExpired = 1
SELECT COUNT (*) AS Deleted FROM CI_SDMPackages WHERE IsDeleted = 1

3. After all the CI items have been marked as isexpired then modify the following property in Site Control file, and change the value to 0 instead of 7 days. You will need to stop the smsexec service to do this:

PROPERTY Updates Cleanup Age 0

4. Restart SMS Executive Service. WSUS_SYNC_MANAGER will now start deleting the Expired updates, and log entries similar to below in WSyncMgr.log:

Deleting old expired updates… SMS_WSUS_SYNC_MANAGER 4/23/2010 4:18:52 PM 4104 (0x1008)
Deleted 100 expired updates SMS_WSUS_SYNC_MANAGER 4/23/2010 4:19:22 PM 4104 (0x1008)

Deleted 2995 expired updates total SMS_WSUS_SYNC_MANAGER 4/23/2010 4:28:48 PM 4104 (0x1008)

5. After all the Expired updates have been deleted, check that the vast majority of the CI_SDMPackages are marked as “isdeleted” using the select count (*) queries above. There are 12 rows at the top of this table which must never be deleted. These are usually marked as NULL in the source site column. To delete the “isdeleted” SDM packages run the following Stored Procedure to remove them:

exec sp_DeleteOldSDMPackageData 0

6. After these procedures have been run we should now have two clean tables. Perform a select * from CI_ConfigurationItems / CI_SDMPackages to check the contents and confirm that these tables are clean. There should now only be about 0 rows in the Ci_configurationitems table and 12 in the sdmpackages table.

** You may have to deal with constraints on the tables by disabling and enabling if you cant clean the tables out and get the error about constraints**!-(part-2)/#.UsKiJ2ZFBEY

7. The next step is to clean out the existing files in the Probably the best thing to do is to archive all the current data to an alternate location and clear out any files from the and the subfolders to make sure there is no old data lurking here.

8. Once we have cleaned the rename the objreplmgr.dll file in Program Files (x86)\Microsoft Configuration Manager\bin\i386 to objreplmgr.dll_old (you will have to stop and start the smsexec to do this).

This will prevent the processing of the files sent from the central site until the replication has completed. This is necessary so that we ensure that some of the files retry period does not go “bad” before the files have had time to arrive.

9. Reinstall the SUP role on the primary site. This should trigger the replication of the CI objects automatically. If this doesn’t replicate immediately then create a .sha file in the on the central site.

10. Wait for the replication process to stop transferring files from the central site. This can sometimes take days and sometimes hours depending on the number of CI objects and WAN link speed. Once you have confirmed that this has stopped then stop the smsexec process on the primary site and rename the objreplmgr.dll_old to objreplmgr.dll. Restart the smsexec service.

11. This processing of the files in the\INCOMING folder should now begin. Hopefully this should complete successfully without any further insertion errors.

12. Change the following property in Site Control file back , from 7 instead of 0 days. You will need to stop/start the smsexec service to do this:


If whist replicating all the CI objects do not replicate the most likely they have an issue with transaction numbers being out of sync

Some queries which i used

select COUNT (*) as totalcis from CI_ConfigurationItems where IsExpired= 0

select COUNT (*) from CI_ConfigurationItems

select COUNT (*) as expired from CI_ConfigurationItems where IsExpired= 1

select * from CI_ConfigurationItems where IsExpired= 0

select COUNT (*) from CI_SDMPackages where IsDeleted= 1

exec sp_DeleteOldSDMPackageData 0

select * from CI_ConfigurationItems

select * from CI_SDMPackages

delete from CI_SDMPackages where SDMPackage_ID > 17906




SMS: Replication Manager Cannot Process Transactions If Transaction ID Is Not Synchronized

Understanding Site to Site Communication in SMS/SCCM

Troubleshooting “Failed to Insert Object” error message


Problem SCCM Records DDR

Problem SCCM Records-

So I was having a discussion with a colleague today about records in SCCM and the different problems we have (or I have previously had) with them!

There is quite a bit of information on the net regarding records but a lot seem to be a bit misleading, probably due to the small amount of official Microsoft information, as well as the wording being a inaccurate.

If you’re reading this, then chances are you’ve read this – – and although this is good info (I’ve copied some of it in to this post) I actually believe it is only part correct. Specifically, I think the “conflicting records” section is incorrect.

This post is an attempt to clarify the problems and I have classified them into 3 categories, based on my own experiences. I thought it important to seperate the different types of records due to the different behaviour that occurs with each one. If you think you have something to add or think I have something wrong here, please feel free to comment and I will try and integrate it into the article.

Conflicting Records
Defined as: Records that have either the same or different name, different GUID and the same hardware ID.

This is normally caused by rebuilding the exact same machine, that already has a record in SCCM, with the same name. In this instance a second record appears in SCCM, with the same name and the same hardware ID.

You can configure SCCM to deal with these types of records automatically ( but that brings its own set a challenges! In this case the old record is marked as obsolete and deleted according to the Delete Obsolete Client Discovery Data Maintenance Task (Default= 7 days). If the site is not configured to handle conflicting records (Site Properties/ Advanced), both records are shown under the conflicting records node in the ConfigMgr console and the Administrator has to manually choose the method for managing these records. It can also be scripted, check out this excellent post for more info –

Duplicate Records
Defined as: Records that have the same name, different GUID and different hardware ID.

This is normally caused by a machine, after already having a record in SCCM, having its hardware ID changed and so getting a new GUID. Circumstances that trigger generation of a new hardware ID:
1.Some aspects accountable for the Hardware ID have changed.There‘s 10 criteria monitored for Desktops, if 3 of them change, the ID also changes. For Notebooks 2 of 7 criteria have to change.
2.The SMBios serial number has changed
3.The Computer SID has changed

So for example, if you image a machine, then remove the HDD and place into another machine, even of the same type, the machine ID will change, a new GUID will be generated and you will see a duplicate record in SCCM.

There are also other scenarios where you will see duplicate records, for example:

How to deal with these? Well you can either delete them or script it to merge them. I’m afraid I dont have a script you can use but I do know the script used to deal with conflicting records WON’T WORK!

Duplicate GUIDs
Defined as: All records with the same GUID

In this case multiple machines use the same record in the ConfigMgr database. Duplicate GUIDs occur when:
1.Harddisks are duplicated with installed SCCM Client
2.Computers are renamed with installed SCCM
3.Client Computers are configured to dualboot, using the same PC name and having the SCCM Client installed in both configurations.

Clients, that share one database record cannot be managed correctly. A collection will always show the client with the most recent discovery record and that means the machine corresponding to the collection member continiously changes. This means software (or even OSs) meant for one computer could potentially be advertised to a completely different one. Not good!

SCCM offers a report to show the conflicts, but does not offer any means of remediation, the admin is forced to use other methods. There is a whitepaper from Microsoft for handling duplicate GUIDs with SMS 2003 which is still valid:


Branch DP’s and Hash Values

How can I find the package hash value in WMI on a BDP:

1. Open Webemtest and connect to root\ccm

2. Select Enum Classes, click the recursive radio button press OK

3. Scroll down to ccm_peerdpagent and double click

4. select ccm_peerdp_job and click instances.

5. click a package packageID listed.

6. Scroll Down to the hash value.

Compare this value in WMI to the Hash value that you find on the Distribution Point for the same package. To get the hash value for the distribution point content use a tool called hashdir.exe. (This is an internal tool so you would need to contact your PFE DSE for it). Compare the two hashes above with the 40 character Sha1 hash that is listed in the “NewHash” column of the SMSPackages Table of the database. Obviously these should all be the same.

What is the BDPTmpWrkFldr?

There are three folders that come into play here, they are listed below in this order:

Needs Folder

Assemble Folder

Content Folder

The flow from one folder to the next is like this:

Flow—–>Needs Folder—–>Assemble Folder—->Content Folder

1. BDPTmpWrkFldr\PDP5DB1.tmp – AKA “Needs” folder used by the Content Transfer Manager where deltas and needs files are downloaded and saved to, before being compiled and sent to the Assemble folder, this folder is deleted after it has been utilized.

2. BDPTmpWrkFldr\PDP5D91.tmp – AKA “Assemble” folder, Delta and needs files are brought in to the Assemble folder once downloaded to the Needs folder and then merged (or assembled). Once we have hash successes here we then copy to SMSPKG$.

3. SMSPKG$ – AKA “Content” folder, this is where the content is actually stored for client retrieval after the deltas have been merged and hash has been verified from content in the Assemble folder.

In this Short example from CTM log we will find the Needs folder is referenced first then the Assemble folder. The merge delta operation occurs in the next log entry in the Assemble folder. Both folders are created with a naming convention of PDP****.tmp

CCMRDC] GenerateTargetFile() called with OldFile as “F:\SMSPKGF$\UP10004A\Patches\WINDOWS_VISTA\Windows6.0-KB960225-x86.msu”,

NeedsFile as “F:\BDPTmpWrkFldr\PDP5DB1.tmp\work\Patches\WINDOWS_VISTA\Windows6.0-KB960225-x86.msu .needs”,

0 Deltafiles and AssembledFile as “F:\BDPTmpWrkFldr\PDP5D91.tmp\Patches\WINDOWS_VISTA\Windows6.0-KB960225-x86.msu”

CMergeDeltaOperation::_ProcessFile – Created merged file F:\BDPTmpWrkFldr\PDP5D91.tmp\Patches\WINDOWS_VISTA\Windows6.0-KB960225-x86.msu. ContentTransferManager 7/28/2009 5:18:16 PM 7380 (0x1CD4)

What’s the difference between “Hash failed for package” and a “PDPHashMismatchEvent”?

“Hash failed for package” is shown when the current version of the ALREADY LOCALLY stored package does not match the stored package hash. If we get this message it indicates for the BDP to NOT download a delta but instead download the full current needed version of the package. Redownloading content is not so much as a “retry” but instead an indicator that we need the full content and not just the deltas.

Example of Hash Failed for Package:

Checking provisioning status for package = UP10004A, version = 3. PeerDPAgent 2/7/2009 1:20:46 PM 7660 (0x1DEC

Hash failed for package UP10004A. Redownloading content. PeerDPAgent 2/11/2009 5:43:33 PM 6312 (0x18A8)

Package UP10004A in state ‘UpdatingPackage’. PeerDPAgent 2/11/2009 5:43:33 PM 6312 (0x18A8)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPDownloadStartedEvent


ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090211234333.305000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP10004A”;

ProcessID = 2212;

SiteCode = “UP1”;

SourceVersion = 4;

ThreadID = 6836;


PeerDPAgent 2/11/2009 5:43:33 PM 6836 (0x1AB4)

Package UP10004A in state ‘Downloading’. PeerDPAgent 2/11/2009 5:43:33 PM 6836 (0x1AB4)

Download complete for CTM job {C2D4DFC8-670F-44A6-8332-88A0F1D3710B}, downloaded KB 8291 PeerDPAgent 2/11/2009 5:44:36 PM 7396 (0x1CE4)

Package UP10004A in state ‘DownloadComplete’. PeerDPAgent 2/11/2009 5:44:41 PM 7396 (0x1CE4)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPDownloadSuccessEvent


ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090211234450.011000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP10004A”;

ProcessID = 2212;

SiteCode = “UP1”;

SourceVersion = 4;

ThreadID = 6028;


PeerDPAgent 2/11/2009 5:44:50 PM 6028 (0x178C)

Package UP10004A in state ‘HashContentSuccess’. PeerDPAgent 2/11/2009 5:44:50 PM 6028 (0x178C)

Package UP10004A in state ‘HostingComplete’. PeerDPAgent 2/11/2009 5:44:58 PM 7396 (0x1CE4)

Package UP10004A in state ‘Succeeded’. PeerDPAgent 2/11/2009 5:44:58 PM 1800 (0x0708)

Note the version number above is “3” Before we update the package above from 3 to 4 we rehash the content. The Hash failed for content so instead of grabbing a Delta update we download the full 4 content.

A “PDPHashMismatchEvent” is shown when the content that we downloaded from the DP fails the hash match immediately after the content was downloaded. In the example below we did in fact attempt to redownload the package however the hash once again failed.

Here is an example of “PDPHashMismatchEvent”:

Package UP100035 in state ‘Downloading’. PeerDPAgent 4/27/2009 7:30:28 PM 6028 (0x178C)

Download complete for CTM job {772B7EAF-D420-4D6B-B421-45B7226A2D0B}, downloaded KB 4961 PeerDPAgent 4/27/2009 7:30:50 PM 1908 (0x0774)

Package UP100035 in state ‘DownloadComplete’. PeerDPAgent 4/27/2009 7:30:50 PM 1908 (0x0774)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPHashMismatchEvent


ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090428003051.129000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP100035”;

ProcessID = 672;

SiteCode = “UP1”;

SourceVersion = 5;

ThreadID = 5792;


PeerDPAgent 4/27/2009 7:30:51 PM 5792 (0x16A0)

Package UP100035 in state ‘HostingIncomplete’. PeerDPAgent 4/27/2009 7:30:51 PM 5792 (0x16A0)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPPkgDeleteEvent


ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090428013514.996000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP100035”;

ProcessID = 672;

Share = “”;

SiteCode = “UP1”;

SourceVersion = 5;

ThreadID = 4724;


PeerDPAgent 4/27/2009 8:35:14 PM 4724 (0x1274)

We did in fact retry again and failed the hash again at 10:40:51

Package UP100035 in state ‘DownloadComplete’. PeerDPAgent 4/27/2009 10:40:51 PM 5244 (0x147C)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPHashMismatchEvent


ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090428034051.189000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP100035”;

ProcessID = 672;

SiteCode = “UP1”;

SourceVersion = 5;

ThreadID = 4168;


PeerDPAgent 4/27/2009 10:40:51 PM 4168 (0x1048)

Package UP100035 in state ‘HostingIncomplete’. PeerDPAgent 4/27/2009 10:40:51 PM 4168 (0x1048)

Why we still do MD5 hash in Config Manager as the SHA1 hash has not been used for content security since SMS 2003 RTM?

We use this value as a quick integrity check as it’s very fast. Something to note is that the older MD5 Hashes are always 32 characters in length and corresponds to the “Hash” column in the SQL Database. Newer (as of SMS 2003 SP1 and Config Mgr) and more secure SHA1 hashes are always 40 characters in length and correspond to the “New Hash” column in the SQL DB.

Remove and install a Configuration Manager 2007 Primary site in hierarchy

Some documentation for detaching and installing a new primary site

How to uninstall a Primary Site.
Before you uninstall a primary site, review all the conditions on the link below

Check “Hman.log” at Primary site and Parent site for verification
Detaching site PR3 from site PR2 Sent the actual site control image to site PR2 Processing site control file: Site PR3 File E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\\WMNUDEUJ.CT2 Update the Sites table: Site=PR3 Parent= There is no parent site, no need to forward any site control images.

Remove the system accounts from respective local groups (“Administrators” and “SMS_SiteToSiteConnection”)

New installation
Before beginning setup, you should ensure that the computer operating system and the additional installed software components that Configuration Manager Setup relies on have been updated with all relevant software updates.

Prerequisites for Installing Configuration Manager
Review the prerequisites for the servers and features you will be using in the site and install the required parts.

What do you want to do?

Add the new Primary Site machines account to the AD System Management container.

Register SPN if using a service account or if using local system account to run ConfigMgr then setup will automatically register.

Run setup and install ConfigMgr

Configuration Manager Upgrade and Installation Checklists for installing the latest service packs

Post-Setup Configuration Tasks

After Setup has run, there are still a few tasks you must perform to have a functioning Configuration Manager 2007 site. For example, you might need to assign new site system roles and install clients. For more information, see Checklist for Required Post Setup Configuration Tasks.

Configuration Manager 2007 flow diagrams

Configuration Manager Troubleshooting Flowcharts

For troubleshooting , we require to understand the flow of data is to how it flows . Here are the list of flowcharts which could be helpful in understand the flow of SCCM and good for troubleshooting.
•Configuration Manager Client Deployment Data Flow:

CCMSetup Installation Process

•Management Point Location Data Flow: Mixed Mode

•Management Point Location Data Flow: Native Mode

•Site Assignment Data Flow

•Collection Evaluator: Site Assignment Change Flowchart

•Active Directory Security Group Discovery

•Active Directory System Discovery

•Active Directory System Group Discovery

•Active Directory User Discovery

•Discovery Data Manager: Parent Site Change

•Discovery Data Manager: Site Boundary Change

•Discovery Data Processing Through Discovery Data Manager

•Configuration Manager Network Access Protection SoH Generation

•Network Access Protection Enforced Compliance

•Administrator Workflow: Create and Configure Task Sequence for Operating System Deployment

•Administrator Workflow: Create and Distribute Image for Operating System Deployment

•Administrator Workflow: Image Deployments Using Media for Operating System Deployment

•Administrator Workflow: Top Level Administrator Processes for Operating System Deployment

•Administrator Workflow: Side-By-Side Upgrade

•Administrator Workflow: Upgrading Sites

•Installing a ConfigMgr Console

•Installing a ConfigMgr Site

•Upgrade a Primary Site

•Upgrade a Secondary Site

•Upgrade an Administrator Console

•Client Program Download Request Flowchart

•Content Location Flowchart for Distribution Point Selection

•Package Access Flowchart for Internet-Based Clients

•Package Access Flowchart When Downloading from an Intranet Distribution Point

•Package Access Flowchart When Running from Distribution Point

•Package Replication with File Delta Replication Flowchart

•Service Location Flowchart for Distribution Point Selection

•Software Distribution Advertisement Flowchart

•Software Distribution Package Creation and Distribution Flowchart

•Deployment Package Process

•Software Update Deployment Process Flowchart

•Software Updates Synchronization Process Flowchart

How does SCUP work with ConfigMgr and SP1

SCUP can retrieve all available catalogs that are free -> downloads the meta data for the catalogs you imported and saves it in WSUS -> SCUP admin publishes one or more updates (automatic, full content or metadata only) -> updates are stored in WSUS (depending on the settings from the last step). Updates (metadata) will be imported into ConfigMgr on the next SUP sync. ConfigMgr admin adds updates to an update list and “downloads” the binaries from WSUS. They will be stored in an updates packages that has to be distributed to DP(s). Clients locate content on DP (depending on the boundary/group settings etc)

With ConfigMgr 2012 SP1 there is the ability to have multiple SUP’s in a site. FOr high availability, you will need to publish the SCUP update to both SUP’s as SCUP will only by default connect to one SUP and publish updates. You will have to manually connect to the additional SUPs and publish the update content.