We recently upgraded from SCCM 2012 SP1 CU1 running on Windows 2008 R2 to SCCM 2012 R2 running on Windows 2012 R2. We have 1 Primary Site and 4 Distribution Point Site Servers.

Now that the dust has settled, we noticed on our Distribution Point Configuration Status page the icon for our Primary Site Server still shows Warning but all of the content shows as green and is distributed to it. It shows 11 messages which I'm guessing 1 of them is why the Warning icon doesn't seem to be going away.

The message is;

11/30/2013 6:00 PM
Processing Content
Failed to retrieve the package list on the distribution point ["Display=\\dist-sccm1.xxxxx.abc\"]MSWNET:["SMS_SITE=PRI"]\\dist-sccm1.xxxxx.abc\. Or the package list in content library doesn't match the one in WMI. Review smsdpmon.log for more information about this failure.

However, here's the issue leading into this one... our log file has already turned and we cannot view anything before early December. Is there any other way to narrow down the issue or determine what is needing to be fixed? Is it possible that since everything is running fine that everything is fixed but the Warning will not clear?

Our current backup for the server only covers our Repository for Applications, Packages, and Drivers so we are unable to restore any log file from our backup solution (however, I'm now thinking we should include the logs directory with the backups on how fast they seem to overwrite themselves).

Any input, suggestions, direction is appreciated.

Thanks,

Robert (Vanyun)

Hi Robert,

We see this issue a lot in our environment.  I wrote the following script to check WMI on the remote distribution point as I believe this is where the 'check' is performed.

You can do a quick compare by looking in the ContentLib\PkgLib directory (count the number of ini files) and compare to the result of:

Get-WmiObject -ComputerName $ServerName -Namespace root\sccmdp -Query "select * from SMS_PackagesInContLib" | select PackageID

Where $ServerName is the name of your DistributionPoint.

If they don't match, then this could be the reason for the failure above.  Redistribute the missing package and you should get a healthy server back.

I do however want to know WHY the packages get removed from WMI, as I know they transferred there correctly at some point.

Thanks for the info. Upon running the query I'm finding a lot of package IDs being referenced. However, upon looking in my PkgLib folder I only find 28 ini files.

The odd thing is that I have removed this server from the Distribution Point Group and have only selected the 4 Boot Images to be distributed. At this time it shows 6 of 6 packages deployed but still shows a warning icon.

Below in the output from the WMI query;

PackageID
PRI00001 - Boot Image x86
PRI00002
PRI00003
PRI00004 - Boot Image x64
PRI00010
PRI00011
PRI00016
PRI00017
PRI00019
PRI0001B
PRI0001F
PRI00022
PRI00023
PRI00024
PRI00025
PRI00026
PRI00027
PRI00029
PRI0002A
PRI0002B
PRI0002C
PRI0002D
PRI0002E
PRI0002F
PRI00030
PRI00032
PRI00033
PRI00034
PRI00035
PRI00036
PRI0003A - Doesn't exist in SCCM
PRI0003B
PRI0003C
PRI0003D
PRI0003E
PRI0003F
PRI00040
PRI00042
PRI00044
PRI00045
PRI00047
PRI00048
PRI00049
PRI0004C
PRI0004D
PRI0004E
PRI00050
PRI00051
PRI00054
PRI00055
PRI00056
PRI00057
PRI00058
PRI00059
PRI0005A
PRI0005B
PRI0005C
PRI0005D
PRI0005E
PRI0005F
PRI00060
PRI00061
PRI00063
PRI00065
PRI00066
PRI00068
PRI00069
PRI0006A
PRI0006C - Boot Image x64 Diagnostic
PRI0006F
PRI00070
PRI00071
PRI00073
PRI00074
PRI00075
PRI00076
PRI00077
PRI00078
PRI00079
PRI0007A
PRI0007B
PRI0007C
PRI0007D
PRI00080
PRI00081
PRI00082
PRI00083
PRI00084
PRI00085
PRI00086
PRI00087
PRI00088
PRI0008A
PRI0008B
PRI0008C
PRI0008D
PRI0008E
PRI00090
PRI00091
PRI00097
PRI00098
PRI0009A
PRI0009B
PRI0009C
PRI0009E
PRI0009F
PRI000A3
PRI000A6
PRI000A7
PRI000A9
PRI000AA
PRI000B0
PRI000B2
PRI000B5
PRI000B6
PRI000B7
PRI000B8
PRI000B9
PRI000BA
PRI000BB
PRI000BC - Boot Image x86 Diagnostic
PRI000BE
PRI000BF
PRI000C2
PRI000C3
PRI000C5
PRI000C8
PRI000CA
PRI000CB
PRI000CD - Doesn't exist in SCCM
PRI000CE
PRI000CF
PRI000D2
PRI000D3
PRI000D4
PRI000D5
PRI000D6
PRI000D7
PRI000DB
PRI000DC
PRI000DD
PRI000DE
PRI000DF
PRI000E0
PRI000E5
PRI000E6
PRI000E7
PRI000E8
PRI000EA
PRI000EB
PRI000EC
PRI000ED
PRI000EE
PRI000EF
PRI000F0
PRI000F1
PRI000F3
PRI000F4
PRI000F5
PRI000F6
PRI000F7
PRI000F8
PRI000F9
PRI000FA
PRI000FB
PRI000FC
PRI00100
PRI00102
PRI00114
PRI00115
PRI00116
PRI00120
PRI00121
PRI00122
PRI00124
PRI00126
PRI00127
PRI00128
PRI00129
PRI0012A
PRI0012B
PRI0012C
PRI0012E
PRI0012F
PRI00130
PRI00131
PRI00137
PRI0013A
PRI0013B
PRI0013E
PRI00141
PRI00143
PRI00145
PRI00148
PRI00149
PRI0014A
PRI0014B
PRI0014C
PRI0014D
PRI0014E
PRI0014F
PRI00150
PRI00151
PRI00152
PRI00154
PRI00156
PRI00157
PRI00158
PRI00159
PRI0015A
PRI0015B
PRI0015E
PRI00163
PRI00164
PRI00165
PRI00166
PRI00167
PRI00168
PRI00169
PRI0016A
PRI0016B
PRI0016C
PRI0016E
PRI0016F
PRI00170
PRI00174
PRI00175
PRI00176
PRI00179
PRI0017B
PRI0017C
PRI0017F
PRI00180
PRI00181
PRI00183
PRI00184
PRI00185
PRI00186
PRI00187
PRI00188
PRI00189
PRI0018A
PRI0018C
PRI0018D

I have added notes to the 4 Boot Image packages we want on this DP (it's used for PXE) along with 2 package IDs that do not even exist in our system. Is there anyway to force the "Processing Content" to check again or to flush the WMI records?

It seems that WMI is holding on to a lot of old package data (~244 total) and our PkgLib directory still is holding onto some more data than it needs (28 ini's) where we should only want to see the 4 Boot Images information.

This post is pretty old, and you have probably sorted it by now, but just in case...

You can flush wmi of the old entries by running a script like this:

$PackagesAtWarningDP = Get-WmiObject -Namespace root\sms\site_$($SiteCode) -Class SMS_PackageStatusDistPointsSummarizer -Filter "ServerNALPath like '%$($WarningDP.Name)%'"

# Format the name of each package into a neat array.
    foreach ($Sitepackage in $PackagesAtWarningDP)
    {
        $AllPackagesAtSite += $Sitepackage.PackageID
    }

foreach ($WMIPackage in $AllPackagesInWMI)
    {
        if ($AllPackagesAtSite -notcontains $WMIPackage)
        {
            Write-Host "    $($WMIPackage) is NOT assigned to this DP but exists in WMI."
            $PackagesToRemoveFromWMI += "$($WMIPackage)"
        }
    }

if ($PackagesToRemoveFromWMI)
        {
            Write-Host "  There are $($PackagesToRemoveFromWMI.Count) to remove from WMI."
            foreach ($OldPackage in $PackagesToRemoveFromWMI)
            {
                # Remove the Missing Package from WMI.
                Get-WmiObject -ComputerName $($WarningDP.Name) -Namespace root\sccmdp -Class SMS_PackagesInContLib -Filter "PackageID = '$($OldPackage)'" | Remove-WmiObject
                Write-Host "   Removed $($OldPackage) from WMI."
            }
        }

This is an excerpt from one of the PowerShell scripts I use to remediate this issue.
It takes a list of the packages assigned to the DP (from the primary server) and compares that to what is in the local DP wmi namespace.  If they exist and shouldn't, it deletes them.  I have another IF statement that adds them if they don't exist.

After this runs, you should start another validation and watch the smsdpmon.log and the console to see how it goes.  

Doing this has cleaned up our DP's.

Note: The Content Library Explorer tool in the toolkit is also very handy for seeing issues in the content library.

Cheers,

David

• Proposed as answer by Garth JonesMVP, Moderator Saturday, March 21, 2015 3:14 PM

This post is pretty old, and you have probably sorted it by now, but just in case...

You can flush wmi of the old entries by running a script like this:

$PackagesAtWarningDP = Get-WmiObject -Namespace root\sms\site_$($SiteCode) -Class SMS_PackageStatusDistPointsSummarizer -Filter "ServerNALPath like '%$($WarningDP.Name)%'"

# Format the name of each package into a neat array.
    foreach ($Sitepackage in $PackagesAtWarningDP)
    {
        $AllPackagesAtSite += $Sitepackage.PackageID
    }

foreach ($WMIPackage in $AllPackagesInWMI)
    {
        if ($AllPackagesAtSite -notcontains $WMIPackage)
        {
            Write-Host "    $($WMIPackage) is NOT assigned to this DP but exists in WMI."
            $PackagesToRemoveFromWMI += "$($WMIPackage)"
        }
    }

if ($PackagesToRemoveFromWMI)
        {
            Write-Host "  There are $($PackagesToRemoveFromWMI.Count) to remove from WMI."
            foreach ($OldPackage in $PackagesToRemoveFromWMI)
            {
                # Remove the Missing Package from WMI.
                Get-WmiObject -ComputerName $($WarningDP.Name) -Namespace root\sccmdp -Class SMS_PackagesInContLib -Filter "PackageID = '$($OldPackage)'" | Remove-WmiObject
                Write-Host "   Removed $($OldPackage) from WMI."
            }
        }

This is an excerpt from one of the PowerShell scripts I use to remediate this issue.
It takes a list of the packages assigned to the DP (from the primary server) and compares that to what is in the local DP wmi namespace.  If they exist and shouldn't, it deletes them.  I have another IF statement that adds them if they don't exist.

After this runs, you should start another validation and watch the smsdpmon.log and the console to see how it goes.  

Doing this has cleaned up our DP's.

Note: The Content Library Explorer tool in the toolkit is also very handy for seeing issues in the content library.

Cheers,

David

• Proposed as answer by Garth JonesMVP, Moderator Saturday, March 21, 2015 3:14 PM

This post is pretty old, and you have probably sorted it by now, but just in case...

You can flush wmi of the old entries by running a script like this:

$PackagesAtWarningDP = Get-WmiObject -Namespace root\sms\site_$($SiteCode) -Class SMS_PackageStatusDistPointsSummarizer -Filter "ServerNALPath like '%$($WarningDP.Name)%'"

# Format the name of each package into a neat array.
    foreach ($Sitepackage in $PackagesAtWarningDP)
    {
        $AllPackagesAtSite += $Sitepackage.PackageID
    }

foreach ($WMIPackage in $AllPackagesInWMI)
    {
        if ($AllPackagesAtSite -notcontains $WMIPackage)
        {
            Write-Host "    $($WMIPackage) is NOT assigned to this DP but exists in WMI."
            $PackagesToRemoveFromWMI += "$($WMIPackage)"
        }
    }

if ($PackagesToRemoveFromWMI)
        {
            Write-Host "  There are $($PackagesToRemoveFromWMI.Count) to remove from WMI."
            foreach ($OldPackage in $PackagesToRemoveFromWMI)
            {
                # Remove the Missing Package from WMI.
                Get-WmiObject -ComputerName $($WarningDP.Name) -Namespace root\sccmdp -Class SMS_PackagesInContLib -Filter "PackageID = '$($OldPackage)'" | Remove-WmiObject
                Write-Host "   Removed $($OldPackage) from WMI."
            }
        }

This is an excerpt from one of the PowerShell scripts I use to remediate this issue.
It takes a list of the packages assigned to the DP (from the primary server) and compares that to what is in the local DP wmi namespace.  If they exist and shouldn't, it deletes them.  I have another IF statement that adds them if they don't exist.

After this runs, you should start another validation and watch the smsdpmon.log and the console to see how it goes.  

Doing this has cleaned up our DP's.

Note: The Content Library Explorer tool in the toolkit is also very handy for seeing issues in the content library.

Cheers,

David

• Proposed as answer by Garth JonesMVP, Moderator Saturday, March 21, 2015 3:14 PM

This post is pretty old, and you have probably sorted it by now, but just in case...

You can flush wmi of the old entries by running a script like this:

$PackagesAtWarningDP = Get-WmiObject -Namespace root\sms\site_$($SiteCode) -Class SMS_PackageStatusDistPointsSummarizer -Filter "ServerNALPath like '%$($WarningDP.Name)%'"

# Format the name of each package into a neat array.
    foreach ($Sitepackage in $PackagesAtWarningDP)
    {
        $AllPackagesAtSite += $Sitepackage.PackageID
    }

foreach ($WMIPackage in $AllPackagesInWMI)
    {
        if ($AllPackagesAtSite -notcontains $WMIPackage)
        {
            Write-Host "    $($WMIPackage) is NOT assigned to this DP but exists in WMI."
            $PackagesToRemoveFromWMI += "$($WMIPackage)"
        }
    }

if ($PackagesToRemoveFromWMI)
        {
            Write-Host "  There are $($PackagesToRemoveFromWMI.Count) to remove from WMI."
            foreach ($OldPackage in $PackagesToRemoveFromWMI)
            {
                # Remove the Missing Package from WMI.
                Get-WmiObject -ComputerName $($WarningDP.Name) -Namespace root\sccmdp -Class SMS_PackagesInContLib -Filter "PackageID = '$($OldPackage)'" | Remove-WmiObject
                Write-Host "   Removed $($OldPackage) from WMI."
            }
        }

This is an excerpt from one of the PowerShell scripts I use to remediate this issue.
It takes a list of the packages assigned to the DP (from the primary server) and compares that to what is in the local DP wmi namespace.  If they exist and shouldn't, it deletes them.  I have another IF statement that adds them if they don't exist.

After this runs, you should start another validation and watch the smsdpmon.log and the console to see how it goes.  

Doing this has cleaned up our DP's.

Note: The Content Library Explorer tool in the toolkit is also very handy for seeing issues in the content library.

Cheers,

David

• Proposed as answer by Garth JonesMVP, Moderator Saturday, March 21, 2015 3:14 PM

Hi David,

I am also facing the very same issue that was addressed, but then i am unable to run the script to flush the wmi, i am not much clued up with power-shell, it is throwing me with this error, i'm not sure on this script where should i edit. Please assist

I couldn't paste the screenshot the account still need to be verified 

Thanks

Exzeketive

Which error is it? No need to post a screenshot, the error message would be sufficient. 

Hi Exzeketive,

Here is a more complete script that should help. (Note, I haven't tested it...)

Import-Module ($Env:SMS_ADMIN_UI_PATH.Substring(0,$Env:SMS_ADMIN_UI_PATH.Length-5) + '\ConfigurationManager.psd1')
$PSD = Get-PSDrive -PSProvider CMSite

$SiteCode = "XYZ"
$Remediate = $false #change to true if you want to rememdiate, useful for reporting
$DistributionPoint = "server1"
$AllPackagesInWMI = @()
$AllPackagesAssigned = @()
$VerbosePreference = "Continue" # Set to SilentlyContinue if you want no output.

$PackagesToRemoveFromWMI = @()
$PackagesToAddToWMI = @()


#Get a list of all packages in WMI on the Distribution Point.
$AllPackagesInWMI = Get-WmiObject -ComputerName $DistributionPoint -Namespace root\sccmdp -Query "select * from SMS_PackagesInContLib" | Select-Object -ExpandProperty PackageID

#Get a list of all packages that are actually assigned to the Distribution Point.
$AllPackagesAssigned = Get-WmiObject -Namespace root\sms\site_$($SiteCode) -Class SMS_PackageStatusDistPointsSummarizer -Filter "ServerNALPath like '%$DistributionPoint%'" | Select -ExpandProperty PackageID


#Warning can occur for 2 reasons, 
#  package IS in WMI and shouldn't be. 
#  package ISN'T in WMI and should be.

#List all Packages to be added to WMI.
foreach ($AssignedPackage in $AllPackagesAssigned)
{
    if ($AllPackagesInWMI -notcontains $AssignedPackage)
    {
        Write-Verbose "  $AssignedPackage is NOT in WMI, but should be."
        $PackagesToAddToWMI += $PackageInDIR
    }
}


#List all packages to be removed from WMI.
foreach ($WMIPackage in $AllPackagesInWMI)
{
    if ($AllPackagesAssigned -notcontains $WMIPackage)
    {
        Write-Verbose "  $($WMIPackage) is not Assigned, but is in WMI."
        $PackagesToRemoveFromWMI += "$($WMIPackage)"
    }
}

if ($PackagesToAddToWMI)
{
    Write-Verbose "  There are $($PackagesToAddToWMI.Count) to add into WMI."
}

if ($PackagesToRemoveFromWMI)
{
    Write-Verbose "  There are $($PackagesToRemoveFromWMI.Count) to remove from WMI."
}


if ($Remediate)
{
    if ($PackagesToAddToWMI)
    {
        
        foreach ($FailedPackage in $PackagesToAddToWMI)
        {
            # Add the Missing Package into WMI.
            Set-WmiInstance -ComputerName $ServerFQDN -Namespace root\sccmdp -Class SMS_PackagesInContLib -Arguments @{PackageID="$FailedPackage"} -PutType CreateOnly | Out-Null
            Write-Verbose "  Added $($FailedPackage) to WMI."
        }
    }
    if ($PackagesToRemoveFromWMI)
    {
        foreach ($OldPackage in $PackagesToRemoveFromWMI)
        {
            # Remove the Missing Package from WMI.
            Get-WmiObject -ComputerName $ServerFQDN -Namespace root\sccmdp -Class SMS_PackagesInContLib -Filter "PackageID = '$($OldPackage)'" | Remove-WmiObject
            Write-Verbose "  Removed $($OldPackage) from WMI."
        }
    }
    
    #Schedule a validation to be run in the next 10 mins.
    if ($PackagesToAddToWMI -or $PackagesToRemoveFromWMI)
    {
        #  Schedule Validation for 10mins time from now.
        CD "$($PSD):"
        $TimeNow = Date
        $TimeInTen = $TimeNow.AddMinutes(10)
        $ValidationSchedule = New-CMSchedule -Start $TimeInTen -DayOfWeek $($TimeNow.DayOfWeek)
        Set-CMDistributionPoint -SiteCode $SiteCode -SiteSystemServerName $DistributionPoint -ValidateContentSchedule $ValidationSchedule
        Write-Verbose " Validation Scheduled for $($TimeInTen) on $($DistributionPoint)"
    }

}

This script should work if ran from your Primary Server, as long as the account used to run it also has permissions to access WMI on a remote system.

Cheers,

David

Hi David,

Thank you very much the script does clean the WMI packages as i ran it from my Secondary Site Server, the issue that i am facing now is that, all of my DP's in my Region rely onto this Secondary Site Server.

After the Cleaning of the WMI package, i have noted that the Package was not redistributed to the secondary server. the package in question is the  ConfigMgr Client Upgrade package ("C0100004")

Now All the DP's installed after are failing to get the package with an error: Package Transfer Manager failed to update the package "C0100004",version 5 on distribution point Server.eu.contoso.com. Review PkgXferMgr.log for more information about this failure.

Errors in PkgXferMgr.log

CContentDefinition::TotalFileSizes failed; 0x80070003

CSendFileAction::SendFiles failed; 0x80070003

CSendFileAction::SendFiles failed; 0x80070003

Please advise

Thanking you in advance for your assistance

regards

Exzeketive

Hi David,

Thank you very much the script does clean the WMI packages as i ran it from my Secondary Site Server, the issue that i am facing now is that, all of my DP's in my Region rely onto this Secondary Site Server.

After the Cleaning of the WMI package, i have noted that the Package was not redistributed to the secondary server. the package in question is the  ConfigMgr Client Upgrade package ("C0100004")

Now All the DP's installed after are failing to get the package with an error: Package Transfer Manager failed to update the package "C0100004",version 5 on distribution point Server.eu.contoso.com. Review PkgXferMgr.log for more information about this failure.

Errors in PkgXferMgr.log

CContentDefinition::TotalFileSizes failed; 0x80070003

CSendFileAction::SendFiles failed; 0x80070003

CSendFileAction::SendFiles failed; 0x80070003

Please advise

Thanking you in advance for your assistance

regards

Exzeketive

Hi David

many thanks for this it picks up the packages to be removed say i got lpo00897 .

where shall i put this value so it can be removed

Tthanks for your script i got the package which need to be removed from wmi lets say i have package name lop005644

I have changed the value as below but it does not remove that 

$PackagesToRemoveFromWMI = @()

$PackagesToRemoveFromWMI = "LOP005644"

Is there anything else need to be changed to get that removed or i am not entering it at the right place.

Hi, the script should handle this for you.

The variables:

$PackagesToAddToWMI
and
$PackagesToRemoveFromWMI

get created and populated by the first steps.

To make it remediate - as it is above, you need to set $Remediate = $true.  By default it only reports what will be done.

Cheers,
David

PS. I note that Henk Hoogendoorn tweeted about this today and posted a link to another script:

" Blog: The package list in content library doesn't match the one in WMI http://henkhoogendoorn.blogspot.com.au/2015/07/the-package-list-in-content-library.html #ConfigMgr #SCCM #SysCtr "

Many thanks it worked like charm it removes perfect but i am having issue when it needs entry to be added in wmi .