Many challenges come with managing and maintaining System Center Configuration Manager in large environment. In previous posts, we covered how to limit Pull DP bandwidth and How to manage Pull DP with collections to ease management in large environment. Probably the biggest challenge with large environment, is to keep SCCM up to date.
In this post, we will provide in depth details, considerations and useful tips on Pull DP upgrade for large SCCM environment. The goal is to provide ways to prevent upgrades of SCCM to become a nightmare by taking more time than planned and/or heavy hit on the network. We will cover theses subjects :
Note that all details and considerations are regarding major upgrade like service pack upgrades and major upgrades.
[su_note note_color=”#cbcbcb” radius=”8″]Warning : this post assume that you already have excellent SCCM knowledge. In Microsoft term, this could be target audience : level 300 :)[/su_note]
After an upgrade, some packages will be automatically updated and distributed to all of your Distribution Point and Pull DP to provide the latest bits to be used by clients.
Here’s the list of what will be updated :
With the nature of packages automatically updated and distributed, it is possible to work around it prior to the upgrade of the site server.
Boot images, unlike SCCM client, can’t be pre-distributed on distribution point because of their unique nature.
To prevent a hit on the network, we removed the boot images from DP, Pull DP and DP groups.
This mean that OSD will NOT be available while the upgrade is being processed.
Once all DP/Pull DP are upgraded and system is heatlhy, redistribute boot image on all your DP/PullDP. This will give you total control on when to distribute instead of leaving the upgrade handle it.
As describe above, the update of the SCCM client package will send around 200 Mb to each DP/ Pull DP. To prevent a massive hit on the network, we created a standard package, before the upgrade, that has the content of the new SCCM client.
We got the source from another hierarchy (like a lab) that was already to the desired upgrade level.
Path to the client : SCCMInstallationDirectory\Client
The Content Library will only host a single instance of files, this will ease the distribution of the client after the upgrade as it will only validate and not distribute.
When the prerequisite checker runs, it will communicate with all DP and PullDP.
It takes approximately 5-10 seconds per PullDP… with 1000 PullDP, this could mean hours of waiting for the prerequisite checker to complete. Let it go, and follow the log for details.
You can follow the prerequisite checker in this log : C:\ConfigMgrPrereq.log
Upgrading a primary server will take time. Be patient.
As an example, upgrading a primary site server with 1000 Pull DP, 5000 clients, took more than 1 hour to complete the wizard.
Monitoring Compmon.log after the upgrade wizard added another hour to the process. This log shows the various Site component status.
Compmon.log must show Waiting until the next polling cycle in 300 secondes from now to consider the upgrade completed.
This log can be find in : SCCMInstallationDirectory\Logs\compmon.log
When upgrading a primary site, all child sites will be upgraded. In a large environment, DP and Pull DP are the biggest challenge of the upgrade.
We found this process not to be well documented and with many grey areas.
By default, when upgrading a primary site, all Distribution and Pull DP will be upgraded.
As documented in this KB for DPUpgradeThreadLimit, the default limit is 5 concurrent Distribution Point or Pull DP Upgrade.
With 1000 Pull DP, this will take extremely long time. With a large SCCM environment, most probably the server and the network can handle more than 5 concurrent upgrade.
This setting can be changed for a higher rate of concurrent upgrade. We did it at 50 concurrent upgrade. Server and network did handle it quite well.
Here’s how to check if your DP settings :
Get the setting using a script querying the WMI of the primary server.
[pastacode lang=”javascript” message=”Check DP limit setting” highlight=”” provider=”manual”]
param(
[string] $siteServerName="."
)
$providerLocation = gcim -ComputerName $siteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"
$providerMachine = $providerLocation.Machine
$sitecode = $providerLocation.SiteCode
$providerNamespace = "root\sms\site_" + $sitecode
$siteFilter = "SiteCode='" + $sitecode + "‘"
write-host $providerLocation
$distmgrConfig = gcim -ComputerName $providerMachine -Namespace $providerNamespace SMS_SCI_Component | ? {$_.ComponentName -eq "SMS_DISTRIBUTION_MANAGER"}
ForEach ($distMgrObject in $distmgrConfig) {
$properties = $distMgrObject | select -ExpandProperty Props
$threadLimitProperty = $properties | ? {$_.PropertyName -eq "DPUpgradeThreadLimit"}
if($threadLimitProperty -eq $null)
{
write-host "Actual setting for DPUpgradeThreadLimit is using default (5)"
}
else
{
write-host "Actual setting for $($DistMgrObject.SiteCode) DPUpgradeThreadLimit is $($threadLimitProperty.Value)"
}
}[/pastacode]
Here’s the script to change the setting in the WMI of the primary server.
[pastacode lang=”javascript” message=”Change DP/PullDP concurrent upgrade ratio” highlight=”” provider=”manual”]
param(
[string] $siteServerName=".",
#define the new number of DP/PullDP concurrent upgrade limit
[int] $newValue=50
)
$providerLocation = gcim -ComputerName $siteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"
$providerMachine = $providerLocation.Machine
$sitecode = $providerLocation.SiteCode
$providerNamespace = "root\sms\site_" + $sitecode
$siteFilter = "SiteCode='" + $sitecode + "‘"
write-host $providerLocation
$distmgrConfig = gcim -ComputerName $providerMachine -Namespace $providerNamespace SMS_SCI_Component | ? {$_.ComponentName -eq "SMS_DISTRIBUTION_MANAGER"}
ForEach ($distMgrObject in $distmgrConfig) {
$properties = $distMgrObject | select -ExpandProperty Props
$threadLimitProperty = $properties | ? {$_.PropertyName -eq "DPUpgradeThreadLimit"}
if($threadLimitProperty -eq $null)
{
write-host "Previous setting for DPUpgradeThreadLimit was using default, updating to $newValue"
$newProperty = New-CimInstance -ComputerName $providerMachine -Namespace $providerNamespace -ClassName SMS_EmbeddedProperty
$newProperty.PropertyName = "DPUpgradeThreadLimit"
$newProperty.Value = $newValue#
$newPropertyList = @()
$properties | % { $newPropertyList += $_}
$newPropertyList += $newProperty
$distMgrObject.Props = $newPropertyList
scim $distMgrObject
}
else
{
write-host "Previous setting for $($DistMgrObject.SiteCode) DPUpgradeThreadLimit was $($threadLimitProperty.Value), updating to $newValue"
$newProperty.PropertyName = "DPUpgradeThreadLimit"
$newProperty.Value = $newValue
$newPropertyList = @()
$properties | % {
if($_.PropertyName -eq "DPUpgradeThreadLimit")
{
$_.Value = $newValue
$newPropertyList += $_
}
else
{
$newPropertyList += $_
}
}
$distMgrObject.Props = $newPropertyList
scim $distMgrObject
}
}
[/pastacode]
Script credit : Matt Shadbolt
Here the result after modifying the WMI on our server.
Once modified in the WMI, restart the SMS_Executive so it takes effect.
Pull DP need the same upgrade as the primary server.
The high-level steps are the following :
All those steps and observation occurs after the upgrade of the server. No action are required for the following to occur.
[su_note note_color=”#cbcbcb” radius=”8″]select * from v_DistributionPointMessages where MessageID=’2399′ order by LastStatusTime[/su_note]
Hope this post will help you plan your next upgrade 🙂
Please fill out the form, and one of our representatives will contact you in Less Than 24 Hours. We are open from Monday to Friday.
Thank you for subscribing to our newsletter or requesting a quote. You will receive our next month's newsletter. If you have requested a quote, we will get in touch with you as soon as possible.
Something went wrong!
Thank for your reply!