Configuration Manager Post In-place OS upgrade, CreateMedia.exe finished with error code 80004005

Another short post to highlight an issue after performing an In-place OS upgrade from Windows Server 2008 R2 to Windows Server 2012 R2 – Configuration Manager 1602

When attempting to create standalone media on a remote console, the error below was displayed in the CreateTsMedia.log 

Retrieving info for package H0100143.4

Content library is on remote system ‘SiteServer’
Cannot connect to remote registry on ‘SiteServer’ (frequent cause is remote registry service is not running) 
Trying to use WMI to read from the remote registry.
Failed to open to WMI namespace ‘SiteServer\root\default’ (80041003)
Unable to open WMI namespace ‘SiteServer\root\default’ (0x80041003)
Failed to connect to namespace ‘root\default’ needed to read remote registry values. The user who creates media has to be local administrator on remote DP on ‘SiteServer’ which contains media content.
Content library location could not be found.
Omitting package source ‘SiteServer’ because content library location or its usable drives cannot be read from registry of ‘SiteServer’
CreateMedia.exe finished with error code 80004005 

As you can see, the process is unable to read the content library location from the registry.

Content library location could not be found.
Omitting package source ‘SiteServer’ because content library location or its usable drives cannot be read from registry of ‘SiteServer’

After a while of troubleshooting, I discovered that the remote registry access had been removed from the below registry string, this entry bypasses restrictions for remote services.

remote-registry Once I restored this entry the process was able to complete on a remote console.

Further information about access to remote registry here 


Error opening remote console after Configuration Manger in place OS upgrade

Quick post about issues connecting to site with remote console after upgrading the server OS from Windows 2008 R2 to Windows Server 2012 R2

After the upgrade all remote console were unable to connect to the site


After reviewing the SMSAdminUI.log  on one of the remote devices, there were access denied errors.

\r\nSystem.Management.ManagementException\r\nAccess denied \r\n   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
:System.Management.ManagementException\r\nAccess denied \r\n   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)

I granted one user local admin rights to the SCCM server, which was hosting the SMS Provider and the console access was restored.

I reviewed the DCOM permissions which were fine, however, the WMI permissions for the SMS Admins group were missing!

I check the WMI permissions using wmimgmt.msc and added the required permissions




I removed the local admin permissions and tested again. Console access was working again

More detail

In order to access a local or remote SMS Administrator console, users must be members of the SMS Admins local group. The SMS Admins group is explicitly granted Enable Account and Remote Enable on the Root\SMS namespace. The SMS Admins group provides its members with access to the SMS Provider, through WMI. Add Users to the SMS Admins group when they need to access the SMS Administrator console, but do not have to be Local Administrators

Console access troubleshooting


Powershell script to compare DP packages with WMI

Blog on the content library

Blog on troubleshooting content 2012

$WMIPkgList = Get-WmiObject -Namespace Root\SCCMDP -Class SMS_PackagesInContLib | Select -ExpandProperty PackageID | Sort-Object

$ContentLib = (Get-ItemProperty -path HKLM:SOFTWARE\Microsoft\SMS\DP -Name ContentLibraryPath)

$PkgLibPath = ($ContentLib.ContentLibraryPath) + “\PkgLib”

$PkgLibList = (Get-ChildItem $PkgLibPath | Select -ExpandProperty Name | Sort-Object)

$PkgLibList = ($PKgLibList | ForEach-Object {$_.replace(“.INI”,””)})

$PksinWMIButNotContentLib = Compare-Object -ReferenceObject $WMIPkgList -DifferenceObject $PKgLibList -PassThru | Where-Object { $_.SideIndicator -eq “” }

Write-Host Items in WMI but not the Content Library
Write-Host ========================================

Write-Host Items in Content Library but not WMI
Write-Host ====================================

To remove the item from WMI (Using the list from the previous script):
Foreach ($Pkg in $PksinWMIButNotContentLib){
Get-WmiObject -Namespace Root\SCCMDP -Class SMS_PackagesInContLib -Filter “PackageID = ‘$Pkg'” | Remove-WmiObject -Confirm

To remove INI files using the list from the previous script:
Foreach ($Pkg in $PksinContentLibButNotWMI){
Remove-Item -Path “$PkgLibPath\$Pkg.INI” -Confirm

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:


Sending content to remote DP failing and seeing Retrying rename in smsdpprov.log

Remote DP failing and seeing Retrying rename when distributing a package to the DP

Resolution – Symantec Endpoint Protection was casing the files to be locked. Updated to latest version of SEP

[10CC][Sun 08/25/2013 19:56:35]:Retrying rename of D:\SCCMContentLib\FileLib\TCC100000A to D:\SCCMContentLib\FileLib\AB2D\AB2D1AB92B3943B66AAC8538C8C655BEC2B75093E6B59B9AEC9287A476D3384C
[10CC][Sun 08/25/2013 19:56:39]:Retrying rename of D:\SCCMContentLib\FileLib\TCC100000A to D:\SCCMContentLib\FileLib\A11E\A11E3E94237BECC1EBB3C4CEC5AB80AA9AD40728446770D478D59D04A52FB216
[10CC][Sun 08/25/2013 19:56:42]:Retrying rename of D:\SCCMContentLib\FileLib\TCC100000A to D:\SCCMContentLib\FileLib\A644\A6446BEB9786181D3C328F07A3DD20AC1DCA30BD5A750A851A70EA1EF13DCC30
[10CC][Sun 08/25/2013 19:56:46]:Retrying rename of D:\SCCMContentLib\FileLib\TCC100000A to D:\SCCMContentLib\FileLib\39F3\39F3A89C269B4FF50937BABEB664810EF4B68144532C5E52B5E4B4EB7352C282
[10CC][Sun 08/25/2013 19:56:49]:Retrying rename of D:\SCCMContentLib\FileLib\TCC100000A to D:\SCCMContentLib\FileLib\B0E4\B0E4CF7E8B30EC1197208B806C8FE8ACFFE728319BFF0D4F956D6FB91C17FCC0
[10CC][Sun 08/25/2013 19:56:52]:Retrying rename of D:\SCCMContentLib\FileLib\TCC100000A to D:\SCCMContentLib\FileLib\E393\E393BB581F000202DEF3E23635515CFBE79DDAD3EA54E995008CCA08C364BED5
[10CC][Sun 08/25/2013 19:56:56]:Content ‘FB7B41B9-08FF-40BE-9CFA-83664BF41A25’ for package ‘CAS00363’ has been added to content library successfully
[10CC][Sun 08/25/2013 19:57:14]:Failed to delete package file(s) from \\server*\SMSPKGD$\CAS00363. Error = 145
[10CC][Sun 08/25/2013 19:57:22]:CreateDirectoryW failed for \\?\D:\SMSPKGD$\CAS00363\E70CE9B3-91BE-4009-927C-F42CB7771917\amd64
[10CC][Sun 08/25/2013 19:57:22]:CreateFolder failed; 0x800700b7
[10CC][Sun 08/25/2013 19:57:22]:CContentDefinition::ExpandContentDefinitionItems failed; 0x800700b7
[10CC][Sun 08/25/2013 19:57:22]:Failed to expand content ‘FB7B41B9-08FF-40BE-9CFA-83664BF41A25’ for package ‘CAS00363’ to share ‘\\server*\SMSPKGD$\CAS00363’. Error code: 183