DAG name entered for Client not in a DAG

Question

80873:nsrsnap_vss_save:NMM ..DAG name entered for client not in a DAG. Cannot continue.

*******

This sounds like an error that would easily be resolved. However, after spending the better part of 6 hours, trying to solve it, I would disagree.

Background.

Have been sucessfully backing up Exch2010 databases in standalone environment for more than 6 months, without issue.

Moving to DAG setup, attempted to configure DAG backups.

I have followed all of the suggestions/guidelines/configurations in this document:

https://solutions.emc.com/emcsolutionview.asp?id=esg124052

I've also checked all of the documents that point to the same issue, without resolution.

I've tried every version of caps/not caps/with domain, without domain, etc.. I've tried active/pasive and "all".

any ideas?

Symptoms

NMM 2.3 fails to backup Exchange 2010 with "DAG name entered for the client not on a DAG, cannot continue"

Customer configured all DAG members (two DAG mailbox servers] as well as the DAG client resources in the same backup group. The application parameter was set to NSR_EXCH2010_BACKUP=all. What happens is both clients start backing up at the same time for the same mailbox databases; Both active and passive copies. NMM 2.3 does not support multiple backups for same mailbox database. Therefore, the backup failed.

Cause

Resolution

Resolve any DNS issue with the DAG for servers.

Remove DAG client resource from backup group.

Provide application information NSR_EXCH2010_BACKUP=passive for both DAG member server client resources.

Start single DAG member server backup, which was failing earlier. Observed backup completed successfully for single database.

Avoid using NSR_EXCH2010_BACKUP=all on two or more clients that are part of the same Exchange DAG and are being backed up at the same time.

Avoid using a mix of NSR_EXCH2010_BACKUP=active and NSR_EXCH2010_BACKUP=passive on clients that are part of the same Exchange DAG and are being backed up at the same time. Set all clients to active or all clients to passive but not a mix.

CarlosRojas · Answer

Hi David,

Based on the initial configuration you mentioned the issue is basically that you are attempting to backup the same DB's through more than one node, and this leads to a backup failure.

The reason behind that is that Exchange 2010 DAG set a flag in the DB like "Backup in progress" when a backup is triggered, so if you start to backup passive DB1 from node1, and start to backup active DB1 on node2 then you will get failures.

I appreciate that the error message is bit confusing (DAG name entered for client not in DAG), however if you check nmm.raw you should see the failure related to a DB being backed up twice.

I think this is well documented, also in the KB you mentioned (esg124052) the different scenarios show the correct configuration.

The client entry for the DAG itself has to be created but not assigned to any group, and of course never scheduled for backup, as the DAG is created only for indexing purposes, to avoid issues when recovering data.

Thank you.

Carlos.

noladave · Answer

Carlos, thanks for the information, but I believe I have all of my bases covered, as far as the obvious items.  I could be wrong. I have the dag configured, but not in a group, and not scheduled for backup.  To prevent any confusion, I ran a backup with just one of the nodes in a backup group, and I tried it with 'all', on one run, and 'active' on the other run, as there are only active databases on this node right now.   I don't see anything in the NMM about a backup being active, just the wrong name being used. here are some things, with names changed.   NMM.raw (rendered) 68150 7/4/2012 2:06:16 PM  2 0 0 6228 7080 0 clientname.lsuhsc.edu nsrsnap_vss_save nsrsnap_vss_save: Exiting with success. 52701 7/4/2012 2:07:25 PM  1 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save Command line:
  C:\Program Files\Legato
sr\bin
srsnap_vss_save.exe -A optype=conventional -A NSR_SNAP_TYPE=vss -A NSR_ALT_PATH=E:\Exchange\Snapshots -A NSR_EXCH2010_BACKUP=active -A NSR_EXCH2010_DAG=(dagname).lsuhsc.edu -A NSR_PARENT_JOBID=3312260 -c clientname.lsuhsc.edu -g Groupname -LL -m clientname.lsuhsc.edu -s backupservername.lsuhsc.edu -l full -q -W 78 -A snap_sessionid=1341428845 -A NSR_STRICT_SYNC=0 -A NSR_PS_DEBUG_ID=1341428826 -A NSRSNAP_JOBID=3312262 APPLICATIONS:\Microsoft Exchange 2010  52702 7/4/2012 2:07:25 PM  1 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save System Version: 6.1 Build 7601 S 52705 7/4/2012 2:07:25 PM  1 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save Computer Name: CLIENTNTAME     User Name: NT AUTHORITY\SYSTEM (SYSTEM) 73064 7/4/2012 2:07:25 PM  1 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save Version information for C:\Program Files\Legato
sr\bin
srsnap_vss_save.exe:
 Original file name: nsrsnap_vss_save.exe
 Version: 2.3.0.107
 Comments: NetWorker Module for Microsoft Applications (x64) 52681 7/4/2012 2:07:25 PM  1 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save NetWorker Server Version: NetWorker 7.6.2.7.Build.697 Network Edition/279 50423 7/4/2012 2:07:25 PM  0 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save nsrsnap_vss_save: Unknown Application Information parameter: NSRSNAP_JOBID, may not be supported 50411 7/4/2012 2:07:25 PM  0 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save nsrsnap_vss_save: Data mover host name not specified. Assuming local host: clientname.lsuhsc.edu 50402 7/4/2012 2:07:25 PM  0 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save nsrsnap_vss_save: Inserting APPLICATIONS:\Microsoft Exchange 2010 in saveset list 80271 7/4/2012 2:07:25 PM  0 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save NMM .. Valid snapshot policy. Group: 'Groupname' Snapshot Policy: 'Serverless Backup' Snapshots Per Day: '1'  Retain: '0' Backup Snapshots: 'All' Level: 'full'. 79946 7/4/2012 2:07:25 PM  5 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save NMM .. Exchange2010 Shell  79598 7/4/2012 2:07:25 PM  5 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save NMM .. Exchange2010 Shell   80873 7/4/2012 2:07:25 PM  5 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save NMM ..DAG name entered for client not in a DAG. Cannot continue.  63335 7/4/2012 2:07:25 PM  5 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save NMM backup failed to complete successfully. 50404 7/4/2012 2:07:25 PM  0 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save nsrsnap_vss_save: createInstanceBackup() failed 0 7/4/2012 2:07:25 PM  2 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save nsrsnap_vss_save: APPLICATIONS:\Microsoft Exchange 2010: failed  63309 7/4/2012 2:07:25 PM  1 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save NMM .. bye bye. 68151 7/4/2012 2:07:25 PM  2 0 0 6488 2416 0 clientname.lsuhsc.edu nsrsnap_vss_save nsrsnap_vss_save: Exiting with failure. C:\Program Files\Legato
sr\applogs>nsrsnap_vss_save -v -?Initializing data to display...NMM ... Using client name CLIENTNAME, the version of the Exchange server is Exchange 2010.79946:nsrsnap_vss_save:NMM .. Exchange2010 Shell79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell 'APPLICATIONS:\Microsoft Exchange 2010'79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell'APPLICATIONS:\Microsoft Exchange 2010\NO-101 -- Active'79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell'APPLICATIONS:\Microsoft Exchange 2010\NO-106 -- Active'79598:nsrsnap_vss_save:NMM .. Exchange2010 Shell'APPLICATIONS:\Microsoft Exchange 2010\NO-102 -- Active' If you can think of anything else, please let me know.   I will be opening a service request this evening, for action on Thursday.  Thank you.

CarlosRojas · Answer

Hi David,

I'm bit confused now.

In your first post you mentioned that you were able to resolve the issue.

This error message usually comes from:

1.- Wrong configuration (most likely either 2 nodes running backup at the same time with NSR_EXCH2010:BACKUP=all) or even not all aliases included in the alias field of the DAG client and the physical nodes. Adding uppercase names for FQDN and short name in some cases is required, depending on how you have condigured DNS and/or hosts file.

2.- Name resolution issues with the DAG.

3.- DAG having multiple Network interfaces.

4.- NetWorker server having multiple network interfaces and not configured correctly.

The steps you described are the ones to solve the issue, in other words, removing the DAG client from the group, running the backup only for one group and solving any name resolution issue are the troubleshooting steps that support would follow at first.

So if you are going to open a case I understand that you are still facing issues. What are the issues you are facing and what is the exact configuration?

Thank you.

Carlos.

noladave · Answer

Carlos, the problem is not solved, sorry if there's confusion on that.

Everything appears to check out, as far as DNS with the DAG, and using the FQDN for configuration of the client. I went through that issue when we first went up on exchange 2010.

#3 and #4 are interesting, as Im' sure we have multiple NIC's installed.

I opened a service request yesterday afternoon, so hopefully will hear from EMC today. Since we aren't in production, with our DAG setup, i opened it as sev 3. I might have to bump it up, if this drags on too long.

Hopefully, it's something in the configuration that we aren't aware of.

Thanks.

CarlosRojas · Answer

Hi David,

If you are sure that all points described above have been already addressed or looked into then I think this could be an issue with a duplicated client ID within your Media DB.

This is difficult to identify, and should be corrected by EMC support, as there is one particular tool to be used and the use of that tool can seriously mess up your environment if not used correctly.

So all aliases (all interface names, shortname and FQDN, are added in all alias clients?

Will wait then for the feedback from support.

Thank you.

Carlos.

CarlosRojas · Answer

Hi David,

Have you tried to recreate the clients again? This can give you a hint.

If there is some issues with the MDB, and you try to recreate the client you should get an error message like "there is already a client called xxx with client ID yyyy".

If this happens then you will need to write down the client ID and the names, and then correct it.

Steps would be:

1.- Write down the client ID, client name and aliases of the DAG.

2.- Delete all client entries for physical nodes and the Exchange nodes and the DAG itself.

3.- Delete the peer information for the 2 physical nodes and the DAG on the NetWorker server.

4.- Recreate the physicalnode 1 with same client name, client ID and aliases as they were before (should be created with FQDN)

5.- Recreate node 1 with same client Id, client name and aliases as before. (Should be created with FQDN)

6.- Recreate the DAG client with same client name, client ID and aliases as before (Should be created with FQDN)

7.- Stop NW services, including the 2 Replication Manager services on the 2 physical nodes

8.- Delete /nsr/tmp and /nsr/res/nsrladb on the 2 physical nodes.

9.- Start up NW services on the 2 physical nodes, including ONLY Replication Manager AgentPS

10.- Run a new backup.

If all these steps complete successfully then there is still a chance that you have issues with the MDB, but if there is no error message similar to the one I mentioned above then let's wait for support's feedback.

I've sent you an e-mail anyway.

Thank you.

Carlos.

noladave · Answer

Carlos, I think you might have hit on something, I will discuss with Farah Monday morning.

We did an upgrade to Win2008, and new hardware, and I'm wondering if we somehow duplicted all of our clients when we upgraded.

We have just about run out of other ideas. We were going to do a webex Friday, but never found the time.

noladave · Answer

Well, this was a long and winding road. The problem was solved on July 20, by the 2nd tier EMC support technician. We worked with 1st tier for close to 2 weeks, and did not get anywhere, even after 3 hour webex. Multiple uploads of logs, EMC config checker, and EMC report grabber.

Ultimately 4 main issues (and some little ones).

Our final configuration

NSR_SNAP_TYPE=vss

NSR_EXCH_CHECK=no

NSR_CHECK_JET_ERRORS=none

NSR_ALT_PATH=E:\Snapshots

NSR_EXCH2010_BACKUP=active (passive also works)

NSR_EXCH2010_DAG=(short DAG name, not FQDN)

1 - even though the documentation insists that the FQDN name must be used in the NSR_EXCH2010_DAG= (name) Never got a reason why, but in our case, it works with the shortname, and doesn't work with the FQDN.

2 - Not sure if this was a major issue, or not. Exchange and log files were on seperate drives, (E: and G:), but there was a directory with the name of "logs" on the E:\Exchange drive. Even thought the "logs" folder wasn't be used, it seems like it was causing some issue, so we deleted that folder.

3 - The way we have a master domain name, and how it was, and was not, included in name resolution of the DAG, the nodes, and the backup server. We put entries in the hosts file, on each exchange node, of all possible combinations of the DAG, nodes, and backup server. ***THIS most likely was the cause of most of our issues, including #1 above.

4 - service account. We use a service account for backing up, and restoring Exchange servers. There was some confusion in the documentation, and even EMC, as to what service should use the service account (domain name/userid). IN the end, the only service that needed it, was the Replication Manager Exchange interface, on each of the Exchange nodes. All other services uses the local system account.

Carlos, thank you for all of your suggestions, you were right in the neighborhood with the answer, it just took a while for us & EMC to get there.

NetWorker

DAG name entered for Client not in a DAG

Was this post helpful?