Hi,

When attempting to upgrade DPM2012 SP1 to DPM2012 R2 (or install from scratch for that matter) the installation fails with error 4323, a member could not be added to or removed from the local group because the member does not exist. This relates, trawling the installation log, to an attempt to add the local machine account as a member of Distributed COM Users.

The account is in fact already there of course, but because the NETBIOS name of the domain does not match the DNS name (this is due to a restiction on NETBIOS characters in a very old MS product used when the domain was created) the setup program is fails to see it, and also fails to add the user as it has derived the NETBIOS name from the DNS name.

I notice that "disjoint namespaces" are no longer supported in the sys requirements for R2 - does this apply to this scenario? It will be disappointing if so. A domain rename on the NETBIOS name of the domain is not possible as Exchange Server is deployed. Is there a workaround?

Thanks

Rob

DNS name: my-domain.co.uk

NETBIOS name: MY

(From the logs:

[10/18/2013 10:58:33 AM] Information : Create a registry containing sql agent account information
[10/18/2013 10:58:33 AM] Information : Querying WMI Namespace: \\MNEMOSYNE\root\cimv2 for query: SELECT * FROM Win32_Service WHERE Name='SQLAgent$MSDPM2012'
[10/18/2013 10:58:33 AM] Information : Sql Agent account name = my-domain\MNEMOSYNE$
[10/18/2013 10:58:33 AM] Information : Create a registry containing the trigger job path information
[10/18/2013 10:58:33 AM] Data : TriggerJobPath = C:\Program Files\Microsoft System Center 2012\DPM\DPM\bin\
[10/18/2013 10:58:33 AM] Information : Add user: my-domain\MNEMOSYNE$ to local group: Distributed COM Users on server: MNEMOSYNE)

• Edited by Rob Hardman Friday, October 18, 2013 11:58 AM title edit

What I did was to create a domain account called MICROSOFT$DPM$Acct.  Next I changed the MSSQL$MSDPM2012 and SQLAgent$MSDPM2012 services to use this domain account as the Log On As account instead of the Local System account.  After making these changes, the install completed successfully.

• Edited by Jamie T. Voss Friday, October 18, 2013 7:58 PM
• Proposed as answer by Jamie T. Voss Friday, October 18, 2013 7:58 PM
• Marked as answer by Rob Hardman Friday, October 18, 2013 8:58 PM

Im also i limbo right now after trying to upgrade to R2. I hope i can reinstall the previus version otherwise it will not be that funny.

Ill upgraded the Secondary DPM first just i case there would be a problems wich was lucky.

But even if the upgrades works with the domain account i dont dare upgrade the primary DPM.

How is it possible to release a R2 update that crashes the installation?

• Edited by MrAdde Monday, October 21, 2013 2:00 PM

i ran into the same issue.

after change the "SQL Server" and "SQL Server Agent" account from "local System" to a domain-account (dom\svc_sql_dpm), the Setup ran sucessful.

Mario

• Edited by MarioMu Friday, October 25, 2013 2:33 PM
• Proposed as answer by Brrrrrt Wednesday, November 27, 2013 8:36 AM

i ran into the same issue.

after change the "SQL Server" and "SQL Server Agent" account from "local System" to a domain-account (dom\svc_sql_dpm), the Setup ran sucessful.

Mario

I was doing fresh install of DPM2012R2 with SQL2008R2 SP2, and ran into the same 4323 error

First tried Mario's solution, as it seemed easier to try....

...and this solution worked for me, thanks a lot !

• Edited by Brrrrrt Wednesday, November 27, 2013 8:37 AM

I have something to add to this.  Since the last post on this thread, the contents have been posted to Microsoft KB 2912500.  It didn't work for me, but I figured out a workaround to the workaround.

I encountered this problem installing DPM to connect to stand-alone SQL Server on a different server.  The two SQL Server services had been running as LocalSystem.

I created domain user Microsoft$DPM$Acct as instructed, but on the next install attempt, DPM Setup tried to add this as a local user of the SQL Server, so I got the same error!  In other words, I had this:

NetBIOS domain:       ABCD

DNS domain:              abcd-inc.com

SQL Server name:       SQL-Server

Before implementing the workaround, of course, it was trying to add ABCD-INC\SQL-Server$.  After the workaround, it tried to add SQL-Server\Microsoft$DPM$Acct even though the SQL Server services were running as ABCD\Microsoft$DPM$Acct.

I figured maybe the DPM Setup code sees the name "Microsoft$DPM$Acct" and assumes it is the local user typically used when SQL Server is running on the same computer.  So, I simply changed the name of the domain account to "DPMWorkaround", and setup completed successfully.  It added ABCD\DPMWorkaround to the proper group on the DPM Server, and Im going to leave everything as it is.

So, I think the KB article might need to be updated to provide what appears to be a different solution when using a separate SQL Server.  Not to mention fixing the program code.

Im also curious to get more information Christoph Stadlmann, or anyone else with enough lab time on this to know the answer:  How would DPM running a backup job as a local user cause problems that are fixed by changing the SQL Server services to use LocalSystem?  Do you have a standalone or separate SQL Server?

Jeffrey Fox

• Proposed as answer by DavidMannen Thursday, January 09, 2014 2:03 PM

So, I simply changed the name of the domain account to "DPMWorkaround", and setup completed successfully.  

After hours of testing, this finally worked for me. How strange!

SQL Server running as DOM\DMPWorkaround ("DOM" = NETBIOS-name)

SQL Server Agent running as DOM\DMPWorkaround

SQL Reporting Services running as NT Authority\NetworkService

Thanks Jeffery!

David H

• Edited by DavidMannen Thursday, January 09, 2014 2:03 PM

Does anyone know what's the best solution for this? If the problem is caused by a DNS and a NETBIOS name beeing not identically I know a lot of networks where this would happen.

I just run into this on a domain where the domain name is longer then the maximum allowed length for NETBIOS...

I fear that there will be more problems in the future with other microsoft products...

I'm also wondering if this is expected / intended behaviour. The KB article talks about disjoint namespace. I didn't read about this for a long time, but as far as I remember it hasn't anything to do with the NETBIOS name...

EDIT: Seems a different NETBIOS name counts as disjoint namespace... I know so many domains with a longer DNS domain name then NETBIOS supports...
Explanation from MS:

Disjoint namespaces

In most domain topologies, the primary DNS suffix of the computers in the domain is the same as the DNS domain name.

In some cases, you may require these namespaces to be different. This is called a disjoint namespace. For example, a merger or acquisition may cause you to have a topology with a disjoint namespace. In addition, if DNS management in your company is split between administrators who manage Active Directory and administrators who manage networks, you may need to have a topology with a disjoint namespace.

A disjoint namespace scenario is one in which the primary DNS suffix of a computer doesnt match the DNS domain name where that computer resides. The computer with the primary DNS suffix that doesn't match is said to be disjoint. Another disjoint namespace scenario occurs if the NetBIOS domain name of a domain controller doesn't match the DNS domain name.

• Primary DNS suffix and DNS domain name are different   The primary DNS suffix of the domain controller isn't the same as the DNS domain name. Computers that are members of the domain can be either disjoint or not disjoint.
• Member computer is disjoint   A member computer in an Active Directory domain is disjoint, even though the domain controller is not disjoint.
• NetBIOS name of domain controller differs from subdomain of its DNS domain name   The NetBIOS domain name of the domain controller isn't the same as the subdomain of the DNS domain name of that domain controller. 

• Edited by Deatheye Tuesday, March 11, 2014 1:21 PM