none
DPM 2012 R2 Installation / Upgrade Fails with error 4323

    Question

  • 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
    Friday, October 18, 2013 11:57 AM

Answers

  • 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
    Friday, October 18, 2013 7:57 PM

All replies

  • Having the same issue here.  To make matters worse, it doesn't seem to have rolled back to my previous version either, and I'm stuck in limbo (my shortcut to the 2012 SP1 version of the DPM console no longer works, DPM service won't start, etc.)
    Friday, October 18, 2013 7:10 PM
  • 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
    Friday, October 18, 2013 7:57 PM
  • After successful setup, I had to change back MSSQL$MSDPM2012 and SQLAgent$MSDPM2012 services back to 'Local System'. Otherwise, scheduled backup jobs failed because DPM always tries to run them as .\MICROSOFT$DPM$Acct and not the domain account used during update.

    By the way: One should mention that the domain account has to have the same permissions as the local account, otherwise setup fails due to permission errors on file system.

    Monday, October 21, 2013 7:53 AM
  • I´m 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.

    I´ll 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 don´t 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
    Monday, October 21, 2013 12:54 PM
  • This didn't work in my environment. As in Rob's case the FQDN and NETBIOS names for my domain differ and I see setup trying to create an account using a portion of the FQDN for the domain instead of the NETBIOS name.

    Another post about a similar error (or maybe the same error) is at:
    http://social.technet.microsoft.com/Forums/scriptcenter/en-US/3b113d76-d998-4716-a1c8-8b6b02770020/dpm-2012-r2-installation-error-id-812?forum=dpmsetup


    Kevin Severud CCNA Security & Wireless, MCITP:EA & EDA7, MCTS Exchange 2007, MCTS SQL 2005

    Friday, October 25, 2013 4:21 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


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

    4323 a member could not be added to or removed from the local group because the member does not exist.

    DPMSetup.log shows:

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

    I was able to repro this error and here is the solution I found.  It is pretty much what has been reported here but with a minor tweak that may be required.

    1. Create a domain user account named MICROSOFT$DPM$Acct
    2. Find the location of the DPMDB database files and be sure the account above has full permissions on that directory
    3. Change MSSQL$MSDPM2012 and SQLAgent$MSDPM2012 to start with the new user account (easiest using SQL Configuration Manager)
    4. Upgrade should run fine now
    5. Change SQL back to using the local (.\MICROSOFT$DPM$Acct)

    We are investigating this internally to determine root cause


    Thanks, Chris Butcher - MSFT This posting is provided "AS IS" with no warranties, and confers no rights

    Friday, November 01, 2013 3:51 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

    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
    Wednesday, November 27, 2013 8:36 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 I’m 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.

    I’m 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
    Tuesday, December 31, 2013 10:30 AM
  • 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
    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:

    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 doesn’t 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
    Tuesday, March 11, 2014 1:07 PM