System Center Data Protection Manager 2016 Delegated Administrator

I recently had a requirement to add a delegated administrator to DPM 2016. While it’s possible to configure self-service recovery, there doesn’t appear to be any way that I can configure another user to perform the delegated admin role as there is in some other System Center products.

It is possible to configure another user to be a delegated DPM admin if you’re willing to roll up your sleeves and get a little grubby with the config however! Note that I’m fairly sure that doing this will impact support, but it’s easy to undo if required.

The problem:

  1. There’s nothing in the DPM interface that appears to allow configuration of a delegated admin.
  2. Adding a user as a local admin of the DPM server still doesn’t allow the user concerned to administer DPM. When trying to launch the DPM console, the following error is shown:
    Unable to connect to DPM server error
  3. Granting the user logon locally permissions still requires that the user elevates when launching the DPM console, so realistically they should be made a local admin on the DPM server.

The solution:

  1. Grant the user local admin rights on the DPM server. I’d strongly suggest creating a dedicated admin account for the user rather than using their day-to-day account for this purpose.
  2. On the SQL instance that DPM uses, configure the following:
    1. Create a new login for the account that will be used as a delegated admin.
    2. Right-click the new account and select ‘Properties’.
    3. Select the DPM database and in the database role membership section of the dialog, select the appropriate DPM-related permissions for the user. To give the user full admin permissions on DPM, select all of the ‘MSDPM…’ role checkboxes:
      DPM delegated admin SQL rights
    4. Click OK to close the dialog.
    5. Check that the user can a) log onto the DPM server and b) successfully launch the DPM admin console and administer the service.

Test-SPContentDatabase False Positive

I was recently performing a SharePoint 2013 to 2016 farm upgrade and noticed an interesting issue when performing tests on content databases to be migrated to the new system.

As part of the migration of a content database, it’s usual to perform a ‘Test-SPContentDatabase’ operation against each database before attaching it to the web application. On the farm that I was migrating, I got mixed responses to the operation, with some databases passing the check successfully and others giving the following error:

PS C:> Test-SPContentDatabase SharePoint_Content_Share_Site1

Category        : Configuration
Error           : False
UpgradeBlocking : False
Message         : The [Share WebSite] web application is configured with
claims authentication mode however the content database you
are trying to attach is intended to be used against a
windows classic authentication mode.
Remedy          : There is an inconsistency between the authentication mode of
target web application and the source web application.
Ensure that the authentication mode setting in upgraded web
application is the same as what you had in previous
SharePoint 2010 web application. Refer to the link
http://go.microsoft.com/fwlink/?LinkId=236865″ for more
information.
Locations       :

This was interesting as all of the databases were attached to the same content web application, and had been created on the current system (I.e. not migrated to it from an earlier version of SharePoint) and therefore should all have been in claims authentication mode. Of note also is the reference to SharePoint 2010 in the error message, I guess the cmdlet hasn’t been updated in a while…

After a bit of digging, it turned out that the databases that threw the error when tested had all been created and some initial configuration applied, but nothing more. Looking into the configuration, there were no users granted permissions to the site (except for the default admin user accounts that had been added as the primary and secondary site collection administrators when the site collection had been created), but an Active Directory group had also been given site collection administrator permissions.

A quick peek at the UserInfo table for the database concerned revealed the following (the screen shot below is from a test system used to replicate the issue):

UserInfo Table

The tp_Login entry highlighted corresponds to the Active Directory group that had been added as a site collection administrator.

Looking at Trevor Seward’s blog post ‘Test-SPContentDatabase Classic to Claims Conversion’ blog post showed what was happening. When the Test-SPContentDatabase cmdlet runs, it’s looking for the first entry in the UserInfo table that matches the following rule:

  • tp_IsActive = 1 AND
  • tp_SiteAdmin = 1 AND
  • tp_Deleted = 0 AND
  • tp_Login not LIKE ‘I:%’

In our case, having an Active Directory Group assigned as a site collection administrator matched this set of rules exactly, therefore the query returned a result and hence the message was being displayed, even though the database was indeed configured for claims authentication rather than classic mode authentication.

For the organisation concerned, having an Active Directory domain configured as the site collection administrator for some of their site collections makes sense, so they’ll likely experience the same message next time they upgrade. Obviously in this case it was a false positive and could safely be ignored, and indeed attaching the databases that threw the error to a 2016 web application didn’t generate any issues.

Steps to reproduce:

  1. Create a new content database (to keep everything we’re going to test out of the way).
  2. Create a new site collection in the new database adding site collection administrators as normal.
  3. Add a domain group to the list of site collection administrators.
  4. Run the Test-SPContentDatabase cmdlet against the new database.

DPM 2012 R2 SQL Backups Failing After November 2014 OS Updates

Following the installation of the November 2014 OS updates and the updated DPM agent (to update rollup 4) onto a number of servers, I saw failures when attempting to perform a backup of SQL Server 2012 databases hosted on Windows Server 2012. These manifested as ‘replica is inconsistent’ in the DPM console:

DB Replica Inconsistent

On the affected SQL Server, the following error was appearing in the server event log each time a consistency check was triggered:

Event 4354 - Failed to fire the RequestWriterInfo method

The COM+ Event System failed to fire the RequestWriterInfo method on event class {FAF53CC4-BD73-4E36-83F1-2B23F46E513E} for publisher  and subscriber . The display name of the subscription is “{E6057DCA-9DE3-42FC-9A6E-A057156277B4}”. The HRESULT was 80042318.

I tried a number of things to resolve the issue:

  1. Modified the protection group. Initially, the protection group wizard did not show the ‘SQL Server’ option and I could not re-add the SQL Server databases. The agent required an update (again) and following this, I could then re-add the SQL Server databases, however when synchronised, the databases were still reporting ‘replica is inconsistent’.
  2. Removed the protection from the affected server, removed the DPM agent, rebooted, then reinstalled and attached the DPM agent and re-added the SQL Server databases to the protection group. This also had no effect, with the databases still reporting as ‘replica is inconsistent’.
  3. Updated the affected server to SQL Sever 2012 SP2 CU2 as the cumulative update mentioned VSS related fixes. Again this had no effect.

I have a Microsoft support call open at the moment in an effort to determine the root cause of the issue, but have found that removing a specific update appears to resolve the issue. The update in question is KB3000853. KB3000853 is an update rollup for Windows 8, Windows RT and Windows Server 2012 and contains a number of fixes including KB2996928 which is a backup related hotfix that references VSS. My suspicion is that this update is what has caused the issue, but will update this post when I get a final resolution from Microsoft support.

Update:

I’ve had this confirmed as an issue with KB3000853 by the Microsoft engineer I’ve been working with.
The workaround for the moment is to either change the account that runs the SQL VSS Writer service to the domain admin account (I assume an account that has local admin permissions, but have not tested this so far), or remove KB3000853, at which point the backups start functioning correctly again.
There is currently no confirmed release date for an updated version of KB3000853.

Update 2:

There’s now a revised hotfix to correct the issue experienced above. The steps to correct the issue are:

  1. Install KB3000853.
  2. Install hotfix KB2996928.

This combination corrects the issues on the servers on which I have installed them.