Highlighted

NMM and Exch2010 SP3 RU5 failures

Jump to solution

I have 3 DAG's backing up. All using "APPLICATIONS:\Microsoft Exchange 2010" for saveset (individual DB's generate whole different set of errors). We upgraded to SP3 a few weeks ago and installed RU5 (previously RU4) on Saturday. Since then failed.

Interestingly, some of the output such as "Unknown Application Information parameter: CIRCULAR_PROMOTION_POLICY, may not be supported" is for options that the client wizard inserted. As you can see, I removed that from DAG2 and it still fails.

DAG1 - Exch 2010 SP1 RU8 - NW 8.1SP1/NMM 3.0SP1 - Success

Variables:

NSR_SNAP_TYPE=vss

CIRCULAR_PROMOTION_POLICY=Skip

NSR_ALT_PATH=r:\Snaps

NSR_EXCH2010_BACKUP=active

NSR_EXCH2010_DAG=DAG1.ai.com

NSR_EXCH_CHECK=no

NSR_CHECK_JET_ERRORS=none

DAG2 - Exch 2010 SP3 RU5 - NW 8.1.0.5/NMM 3 - Fail

Variables:

NSR_SNAP_TYPE=vss

NSR_ALT_PATH=C:\Snaps

NSR_EXCH2010_BACKUP=passive

NSR_EXCH2010_DAG=DAG2.aero.local

NSR_EXCH_CHECK=no

NSR_CHECK_JET_ERRORS=none

DAG3 - Exch 2010 SP3 RU5 - NW 8.1SP1/NMM 3.0SP1 - Fail

Variables:

NSR_SNAP_TYPE=vss

CIRCULAR_PROMOTION_POLICY=Skip

NSR_ALT_PATH=c:\Snaps

NSR_EXCH2010_BACKUP=active

NSR_EXCH2010_DAG=DAG3.aero.local

NSR_EXCH_CHECK=no

NSR_CHECK_JET_ERRORS=none

Errors with DAG2

0 2014 -a "device interface=data domain" -l full -q -W 78  -A snap_sessionid=1395069377 "03/17/14 11:16:17.862850 [nsr/save/nsrsnap.c 1730] Calling start_savecmd..

APPLICATIONS:\Microsoft Exchange 2010

03/17/14 11:16:17.878450 [nsr/save/nsrsnap.c 1743] Calling snap_wait..

03/17/14 11:16:22.886082 [nsr/save/nsrsnap.c 1764] Calling parse_fs_logs_and_prefix..

86745:nsrsnap_vss_save:Version information for C:\Program Files\Legato\nsr\bin\nsrsnap_vss_save.exe:

    Original file name: nsrsnap_vss_save.exe

    Version: 3.0.0.282

    Comments: NetWorker Module for Microsoft (x64)

50423:nsrsnap_vss_save:nsrsnap_vss_save: Unknown Application Information parameter: NSR_SAVE_FROM_SAVEGRP_NSRSNAP, may not be supported

50411:nsrsnap_vss_save:nsrsnap_vss_save: Data mover host name not specified. Assuming local host: mail02.aero.local

50412:nsrsnap_vss_save:nsrsnap_vss_save: Invalid argument: -g is specified without snap_sessionID

50338:nsrsnap_vss_save:

usage: nsrsnap_vss_save [<options>]

50420:nsrsnap_vss_save: options: [-mvWL] [-c client-name] [-f dirfile]

50421:nsrsnap_vss_save:          [-g group]

43597:nsrsnap_vss_save:          [-s server]

50422:nsrsnap_vss_save:          [-A key=value]

67780:nsrsnap_vss_save:          [-G dumps VSS Writer metadata to XML files, one per writer.]

67781:nsrsnap_vss_save:          [-? displays valid application data save set entries.]

62872:nsrsnap_vss_save:nsrsnap_vss_save: snapvss_validateAparams()failed to validate one or more Application Information parameters

68151:nsrsnap_vss_save:nsrsnap_vss_save: Exiting with failure.

Errors with DAG3

92347:nsrsnap:***************** Snapshot Management operation has started, logging to "C:\Program Files\EMC NetWorker\nsr\logs\nwsnap.raw" *****************03/17/14 11:16:53.850688 [nsr/save/nsrsnap.c 611] Calling nsrrm_host

03/17/14 11:16:53.913188 [nsr/save/nsrsnap.c 886] Calling get_pool_name..

52051:nsrsnap:Printing savecmd=nsrsnap_vss_save after parsing

03/17/14 11:16:54.350689 [nsr/save/nsrsnap.c 1693] Calling snap_wait..

APPLICATIONS:\Microsoft Exchange 2010

03/17/14 11:17:14.413235 [nsr/save/nsrsnap.c 1714] Calling parse_fs_logs_and_prefix..

86745:nsrsnap_vss_save:Version information for C:\Program Files\EMC NetWorker\nsr\bin\nsrsnap_vss_save.exe:

    Original file name: nsrsnap_vss_save.exe

    Version: 3.0.1.2.280

    Comments: Supporting Microsoft Volume Shadow Copy Service

102357:nsrsnap_vss_save:Unknown Application Information parameter: NSR_SAVE_FROM_SAVEGRP_NSRSNAP, may not be supported

102357:nsrsnap_vss_save:Unknown Application Information parameter: CIRCULAR_PROMOTION_POLICY, may not be supported

102345:nsrsnap_vss_save:Data mover host name not specified. Assuming local host: mail03.aero.local

102347:nsrsnap_vss_save:Invalid argument: -g is specified without snap_sessionID

50338:nsrsnap_vss_save:

usage: nsrsnap_vss_save [<options>]

50420:nsrsnap_vss_save: options: [-mvWL] [-c client-name] [-f dirfile]

50421:nsrsnap_vss_save:          [-g group]

43597:nsrsnap_vss_save:          [-s server]

50422:nsrsnap_vss_save:          [-A key=value]

67780:nsrsnap_vss_save:          [-G dumps VSS Writer metadata to XML files, one per writer.]

67781:nsrsnap_vss_save:          [-? displays valid application data save set entries.]

102321:nsrsnap_vss_save:snapvss_validateAparams()failed to validate one or more Application Information parameters

102333:nsrsnap_vss_save:Exiting with failure.

Tags (1)
0 Kudos
1 Solution

Accepted Solutions

Re: NMM and Exch2010 SP3 RU5 failures

Jump to solution

This was resolved by deleting the client resources and re-adding via the New Client Wizard and specifiying DAG2 as the client resource and it was added (w/ cluster nodes also) as a Federated DAG (automatically) At first this failed backups with the same error because I added it to the existing Savegroup. However, when I did DAG3 the same way, except creating a new savegroup (w/ same snapshot policy, same pool, everything), backups went fine. Something must have been corrupted in that original group.

Interesting note as well, with federated DAG, the DAG client has all the Application Information variables, not the actual server nodes like before. Also interesting, when I tried to reconfigure the SP1 boxes in DAG1 the same way, it doesn't work. But all good now.

0 Kudos
1 Reply

Re: NMM and Exch2010 SP3 RU5 failures

Jump to solution

This was resolved by deleting the client resources and re-adding via the New Client Wizard and specifiying DAG2 as the client resource and it was added (w/ cluster nodes also) as a Federated DAG (automatically) At first this failed backups with the same error because I added it to the existing Savegroup. However, when I did DAG3 the same way, except creating a new savegroup (w/ same snapshot policy, same pool, everything), backups went fine. Something must have been corrupted in that original group.

Interesting note as well, with federated DAG, the DAG client has all the Application Information variables, not the actual server nodes like before. Also interesting, when I tried to reconfigure the SP1 boxes in DAG1 the same way, it doesn't work. But all good now.

0 Kudos