DP Maintenance Mode = On
Starting in SCCM 1902 we have an awesome new feature called ‘Maintenance Mode’ for Distribution Points. The Microsoft Docs do a good job of highlighting some use cases for this. I’ll also note them below.
- The site doesn’t distribute any content to it.
- Management points don’t return the location of this distribution point to clients.
- When you update the site, a distribution point in maintenance mode still updates.
- The distribution point properties are read-only. For example, you can’t change the certificate or add boundary groups.
- Any scheduled task, like content validation, still runs on the same schedule.
In particular, I appreciate the bold line above. This will provide a more consistent end user experience. If a distribution point is provided to a client it is far more likely to be an active DP when maintenance mode is leveraged. You can also expect your PkgXferMgr, and distmgr log files to look much cleaner while you perform scheduled maintenance.
For more information on automating this process with the Configuration Manager SDK, see
SetDPMaintenanceMode method in class SMS_DistributionPointInfo
below!
As of the writing of this post, enabling, and disabling maintenance mode on a distribution point is not an option with the native ConfigMgr PowerShell cmdlets. The docs do make the statement above and point you in the right direction though. There is a WMI method available for triggering a change to maintenance mode on a distribution point. The method has two parameters as you can see below.
I am sure that we will see a native cmdlet for this very soon, or a new parameter on Set-CMDistributionPoint. But until then! I have written a function that will do this for you as well. Being able to scriptomatically trigger maintenance mode is very useful. It can be built into processes that you may already have in place to reduce alerts, prevent clients from requesting content that you know will be a failed request, or simply keep some of those log files clean!
Set-CMDistributionPointMaintenanceMode
The function I’ve written can be found here. It has four input parameters.
.PARAMETER SMSProvider
Define the SMS Provider which the WMI queries will execute against.
.PARAMETER DistributionPoint
Provides the Distribution Point which you want to change the maintenance mode of. This should be provided as a FQDN,
but if you provide the shortname we will also attempt a search with a wildcard.
.PARAMETER MaintenanceMode
The desired state of of Maintenance Mode for the distribution point. This is either 'On' or 'Off'
.PARAMETER Force
Bypass confirmation prompts.Overall, there isn’t much to this function. It looks a bit longer than it really is because I tend to use splatting. It also should be pretty intuitive to use. Below is a couple examples of using it. You can see that it supports the pipeline, which I’ll discuss a bit more below.
(ValueFromPipelineByPropertyName = $true)
[parameter(Mandatory = $true, ValueFromPipelineByPropertyName = $true)]
[Alias('ComputerName', 'Name', 'NetworkOSPath')]
[string]$DistributionPoint,
That snippet above is is example of how you setup a parameter to accept pipeline input. It is what makes that magic of Get-… | Set-… work. Specifically, ValueFromPipelineByPropertyName will pass parameters through the pipeline based on a matching property name. This is why I’ve added an alias of NetworkOSPath to the DistributionPoint parameter. There are some other options as well, such as simply ValueFromPipeline which will select a parameter passed through the pipeline based on object type. Pipeline support, in my opinion, makes a function like this feel a bit more intuitive. It works as expected. If tasks are being done at scale, whether with a large number of objects, or very frequently, it is generally recommended to avoid the pipeline due to performance issues. There is always an alternative to the pipeline, but for quick one-off commands this can be ‘quick’ and clean.
[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = ‘High‘)]
Also, this function fully supports -Whatif and -Confirm. This is achieved by setting [CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = ‘High‘)] at the top of the function and also using statements such as if ($Force -or $PSCmdlet.ShouldProcess($Computer, “MaintenanceMode $MaintenanceMode“)). These are very useful options to have working in a custom function. Setting a distribution point in maintenance certainly has an impact on production. By properly supporting these parameters we are able to have a sort of ‘test run’ of the function as you can see below.
I’ve also specified ConfirmImpact = ‘High’ which will make sure that you are prompted to confirm your proposed maintenance mode for the distribution point. The -Force parameter, or -Confirm:$false would let you bypass these confirmations. With this function effectively taking a distribution point offline for clients it is good to have a bit of confirmation!
That’s All Folks
I did link it above, but you can git the script here.
Hopefully someone gets a bit of use out of this. I would suspect in the next version or two of ConfigMgr we will see this natively available. It might even be in a tech preview already… I should probably check.
Add comment