How to simplify SCDPM servers maintenance

Every DPM administrator, ever tried to perform a regular maintenance onto a set of SCDPM servers (monthly updates, for example), knows that the only one way to do it correctly, i.e. without interruption of backup jobs, is to gracefully shutdown the server. To achieve this, you need to disable active SCDPM agents, connected to this server, and wait till every running job will be completed.

The only problem is — there is no quick way to get a list of every computer with an active agent connected to a SCDPM server. One may say, I’m wrong here and there IS a quick way — just use Get-DPMProductionServer cmdlet with “ServerProtectionState -eq ‘HasDatasourcesProtected'” filter. But you forgot about cluster nodes: If we protect clustered resource, but not cluster nodes themselves, we will not see them in an output of Get-DPMProductionServer (with abovementioned filter applied, of course). In addition, the output will contain clustered resources, which are useless in our task to stop every active protection agent.

That’s why I want to present you with a solution to quickly get a list of only real computers with an active SCDPM-agent installed. Just pass names of your SCDPM-servers to it (or don’t pass anything for localhost) and you’ll receive a collection of ProtectedServers in response. You may then pass that collection directly to Enable/Disable-DPMProductionServer cmdlets.

“setspn -x” is case-insensitive now

As you probably know, duplicate SPNs cause Kerberos authentication errors in AD DS domains. You may notice it by looking for KRB_AP_ERR_MODIFIED errors and Event ID 11 in system logs. With Windows Server 2008, Microsoft released a largely improved version of setspn, which includes “-x” switch to help you proactively monitor your infrastructure for duplicate SPNs. Combined with “-f” switch, setspn output contains duplicate SPNs not only from a single domain, but from a whole AD DS forest. Many companies rely on a result of “setspn -x -f” command as a data source for monitoring systems.

Today I found, that all these years almost nobody noticed that “setspn -x” command compares SPNs case-sensitively, i.e. following SPNs will be considered different and will not be shown in the output:

  • HOST/ServerName

Starting from Windows 10, Microsoft changed behavior of setspn to case-insensitive, and, from now on, every duplicated SPN will be displayed in setspn output, disregarding its case.

While Microsoft asserts, that Windows is case-insensitive to SPNs, not every Microsoft product agrees: for example, Shane Young found that you must pay attention to SPNs used by SharePoint accounts.

As a conclusion, I suggest every AD DS administrator to check their infrastructure with the setspn tool shipped with Windows 10, at least once. It allows you to find TRULY EVERY duplicate SPN (I did found a couple, myself ;).