Hey Zlatko,

This is in fact a very generic one, as this behavior could be caused for different reasons.

My advice, as usual, is to run NMM Config Checker. This handy tool will let you know for instance if there is any permissions missing or not applied correctly, missing MS fixes, etc etc.

So first question, what authentication method do you have in server and client?

To check it out run nsradmin:

nsradmin -p nsexec

nsradmin>print type: nsrla

Both have to match and, for NW 8 I would recommend o use:

0.0.0.0/0,nsrauth/oldauth

On the other hand, check on the server that you don't have any nested indexes:

C:\Program files\Legato\nsr\index\client_name

If inside that folder you find another folder with the name of the client again then that is the reason.

Another tip. For NMM backups, ALWAYS check first Application and System event logs, as NMM relies big time on OS, and especially in VSS, so OS logs are always the first place to look into.

Thank you.

Carlos.

Authentication method on both client and server is as you wrote.

There are no nested indexes.

Apllication and System event logs show nothing unusual.

NMM Config Checker is good, and everything is green (not even a warning)

In Applications and Service Logs in MSExchange Management event log I got this error, but I don't know if it is related to my recover tryout:

Cmdlet failed. Cmdlet Get-PublicFolderDatabase, parameters {Status=True, Identity=f446826c-0610-4977-b288-eb96640f4103}.

Hi Zlatko,

This could be caused by one of the following reasons:

1.- Index issue

2.- Media DB issue

3.- Connectivity issue

For the index issue I would say run nsrck -L2 client_name on the NW server and check if there is anything wrong in the output of the command.

For he MDB issue that is a bit more complicated to troubleshoot but, for instance run the following commands:

mminfo -q client=dag_short_name -r client,clientid

Then run

mminfo -q client=dag_FQDN_name -r client,clientid

The output should be the same, same client name and same client ID.

If not I would suggest you to open a case with support, as I could tell you how to fix it but support should tell you better

Thank you.

Carlos.

There is some messages in monitor.xml, but that is old messages, when I tried to restore something yesterday. Nothing from todays attempt.

Process that is using CPU and memory is "store.exe" and its description is "Microsoft Exchange MDB Store".

Network utilization is under 5%. There are two network cards in teaming mode.

For the index issue... everything is fine. Nothing unusual.

For the MDB issue, dag short name and dag FQDN client id is the same.

Hey Zlatko,

This is getting interesting then

Ok, can you check the file called "monitor.xml" under C:\Program Files\EMC NetWorker\nsr\applogs

This is the output of the monitor tab in NMM GUI, just want to check if there is any message in there that could point us in the right direction.

Also please check in the task manager which process is using more CPU, and also check the network to see the traffic.

Thank you.

Carlos.

Good point Zlatko,

Is there any chance to disable teaming?

Can you also set debug level 7 in nsrexecd on the client?

Store will be always by default the process using more CPU and memory, what is the second one? or in fact, which nsrxxx process is the one taking more resources?

Set that one in debug 7 as well by running this command:

dbgcommand -p PID debug=7

To turn off the debug once the test is done run:

dbgcommand -p PID debug=0

Thank you.

Carlos.

It is not possible to disable teaming right now. Maybe at some time, when it is approved by a collegue that administer MS Exchange.

The most "expensive" nsrxxxx process is nsrexecd, while in idle state. I have setup debug level to 7. Now what?

Once you have set the debug level to 7 do the same operation.

Once it hangs for a while stop the debug option, then check the logs check the daemon.raw of the client.

Thank you.

Carlos

I had big problems backing up Exchange since I set this debug level. Restarting the service did not help me to resolve issue, so I opened SR.

Worked for 5 hours to try to resolve an issue, and after all we did, I had to reinstall NetWorker client and NMM, but, I had to delete old C:\Program Files\Legato folder in order to NetWorker correctly install in default location C:\Program Files\EMC Networker.

Now, I will try to recover one mailbox, and will update you with the result.

Hi Zlatko,

So the issue went away after reinstalling NMM and delete/rename C:\Program filesLegato folder?

Thank you.

Carlos.

Kind of.

The thing is... recover probably works fine... but I cannot do GLR because I am backing up to a tape device directly. I will reconfigure device selection so backups will go to some AFTD (Avamar), and then, I will try GLR.

Will update you with the result.

When I click on select a version of the save set that is GLR-compatible I got nothing. Not a single save set.

I am backing up full every day to an Avamar deduplication node. Should I open SR? I am cornered here.

Hi,

As per the NMM 2.4 Application Guide, you have to do the following steps:

In the Exchange Server Session toolbar, click Recover:

• If the backup is GLR-compatible, the recovery will proceed.

• If the backup is not GLR-compatible, you will be prompted to select a version of the save set that is GLR-compatible. To select a GLR-compatible save set:

a. Click Yes.

b. Select a backup from the list of backups.

c. Check the Use selected item backup time as new browse time checkbox and then click OK. NMM creates an RDB and performs the recovery.

Note: Only full backups are compatible with GLR.

Hope this helps you.

Ahmed Bahaa