• No results found

Troubleshooting backups

The following topics explain issues that might occur during the backup process for an Exchange environment, as well as steps to resolve or work around the issues.

Unable to browse mailbox items from a recovered database

If you are unable to browse mailbox items from a recovered database, you must restore the original (source) mailbox to an alternate (target) mailbox by running the New-MaiboxRestoreRequest or Restore-Mailbox PowerShell cmdlet. Microsoft provides a full list of syntax and parameters for these cmdlets.

Solution:

Table 25 PowerShell cmdlets for restored mailboxes

Exchange version PowerShell cmdlet Microsoft website Exchange 2010 SP1 or The following examples show the New-MaiboxRestoreRequest and Restore-Mailbox cmdlets with sample parameters:

l Exchange Server 2010 SP1 or later and Exchange Server 2013 CU1 or later:

New-MaiboxRestoreRequest -SourceDatabase <RDBNAME> -SourceStoreMailbox

<GUID_OF_MAILBOX_YOU_WANT_TO_RESTORE> -TargetMailbox

Troubleshooting

Troubleshooting backups 131

<ORIGINAL_USER_MAILBOX> -Targetrootfolder <Folder_to_restore_into>

If the file system path specified for NSR_ALT_PATH in the Exchange client does not exist, it is automatically created in NMM. Before performing a backup, delete the specified alternate path for the NSR_ALT_PATH attribute.

Before performing a backup, empty the contents of the specified alternate path for the NSR_ALT_PATH attribute. Any data previously stored in that location will be deleted.

Unmounted or offline databases are skipped

If a database is unmounted or offline when a backup is performed, the backup process skips that database. Generally, this is not an issue because databases that are not mounted are not in production.

Event log error: Microsoft Exchange Replication service VSS Writer failed

A failed or canceled backup of a passive copy might produce an error in the Event log that the Microsoft Exchange Replication service VSS Writer failed. However, this condition might be temporary. If this backup failure and error occur, there are two solutions.:

Solution:

l If you need to perform an immediate backup, stop and then restart the Microsoft Exchange Replication Service writer.

l If you wait about 15 minutes, the Exchange server automatically corrects this condition.

NTFS softlinks are skipped by default in Windows VSS backups

NMM Windows File System backups using the NMM Windows VSS client skips NTFS softlinks (also known as symbolic links or symlinks). In addition, if an Exchange Server is configured to save either database files or log files to a softlink path, backups fail. EMC plans to fix this in a future release.

Backups might time out for large Exchange databases when using the default time out value

The default time out for how long to wait for snapshot creation, before failing the backup is 20 minutes. For large Exchange servers or databases, backups might fail because VSS snapshot creation might require more than 20minutes. To specify more time to wait for VSS snapshot creation before timing out and failing the backup, you can add the registry key CC_VSS_ASYNC_TIME_OUT in HKEY_LOCAL_MACHINE\SOFTWARE\emc\RMService

\RMAgentPS\Client. You must add this registry key in each DAG node where the DAG client is installed.

Solution:

If the firewall causes the connection to shut down:

1. Set the TCP keepalive parameter to a low value, such as 5 minutes on the following:

l NetWorker server

l NetWorker storage node

l NetWorker client (NMM host)

For example, on Microsoft Windows, create a registry key:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Tcpip\Parameters Value name: KeepAliveTime

Value Type: REG_DWORD Value Data: 300000 (Decimal)

NOTICE

Exercise caution when modifying the Windows registry. The following Microsoft article provides details: http://support.microsoft.com/kb/324270.

Your operating system documentation provides information on how to set the TCP keepalive parameter.

2. After the backup failure is resolved, you can increase the KeepAliveTime value if required based upon your backup environment.

MAPI browsing fails in Client Access Server (CAS) array or Network Load Balancing (NLB) setup

Sometimes MAPI browsing fails in Client Access Server (CAS) array or Network Load Balancing (NLB) setup where the CAS server is set to an CAS array or NLB in the NMM user interface. The failure might be due to the NLB configuration, NLB type, firewall setup, or other error.

Solution:

Set up the individual CAS servers to directly communicate with CAS server in such setups, instead of creating an CAS Array or NLB through the NMM user interface.

“New page map is wrong size” error is displayed while configuring DAG client resource on an Exchange Server 2013 DAG in Windows 2012 operating system

The following error message is displayed while configuring Exchange Server 2013 DAG client resource using the Configuration wizard for Federated backup on Windows Server 2012: “New page map is wrong size”

Solution:

Create the client resource manually by using the NetWorker Management Console.

Unhandled exception occurs during item-level recovery for Exchange Server 2010 GLR RDB

When performing item-level recovery to an alternate user mailbox for Exchange Server 2010 GLR, an unhandled exception might occur.

Solution:

Perform the following steps:

1. Close and reopen the NMM UI.

2. Perform GLR.

3. Perform item-level recovery.

Exchange Server 2010 backups are not using Data Domain Boost device and the backups are instead directed to the storage node (NW148692)

The NMM and NetWorker client do not recognize the Data Domain (DD) device and direct their backups to the storage node instead of the DD device.

Solution:

Troubleshooting

Troubleshooting backups 133

l Configure the device resource for the DD on the NetWorker server using its IP address and not its name.

l Add entries for both the name and IP address of the DDR in the host file on the NMM client.

For Exchange Server 2010, backup fails if a logs volume and a database mount point volume are the same and in the same save set

Backup fails if a logs volume and a database mount point volume are the same (for example, D:\) and are in the same save set.

Backup fails with the following message:

RM .. 026420 ERROR:An unexpected internal error occurred:

IRD:

mountRestoreState::handleFinalStatusMsg() : validateState::runState() failed.

Solution:

Don't configure the log volume and the database mount point volume to be the same location.