Sep 15

News in TDM Exchange 7.1.1

Exchange Comments Off on News in TDM Exchange 7.1.1

New for Data Protection for Microsoft Exchange Server Version 7.1.1

Data Protection for Microsoft Exchange Server includes several new features and changes.

The required authority to perform mailbox restore operations is reduced
In previous releases, only members of the Exchange Organization Management role group had the required administrative permissions to complete mailbox restore operations. With this release, it is no longer necessary for Exchange backup and restore operators to be in the Organization Management role group and have full administrative authority. You can use Exchange Role Based Access Control (RBAC) to limit users to specific operations, for example, view-only access to a mailbox list or individual mailbox restore operations. With RBAC management role scope, you can further limit the scope of restore operations, for example, to users in a single Active Directory domain.
Capacity to keep a recovery database for mailbox restore operations
With this release, you can retain a recovery database for reuse in mailbox restore operations. Alternatively, you can ensure that the recovery database is removed after a mailbox restore operation is complete. You can use the /KEEPRDB option with the restoremailbox command on the command-line interface, or specify the option in the Microsoft Management Console (MMC).
Capacity to use or remove an existing recovery database during mailbox restore operations
You can restore mailboxes from an existing recovery database, or you can automatically remove an existing recovery database during mailbox restore operations. You can choose whether to use a recovery database for mailbox restore operations in the MMC, or by using the /USEEXISTINGRDB option with the restoremailbox command on the command-line interface.
Performance enhancements in Mailbox Restore Browser functionality
Performance is significantly improved when the Mailbox Restore Browser feature restores whole mailboxes, mailbox folders, and selected mail messages.
Usability enhancements in the Mailbox Restore Browser interface
When you use the Mailbox Restore Browser interface to restore a mailbox, you can identify which backup version to restore from a list of available backups. Right-click menus are available for mailbox restore tasks.
AES 256-bit encryption added as an available data encryption type
AES 256-bit encryption is available as a data encryption type with this Data Protection for Exchange release. AES-256 provides the most secure algorithm to encrypt data that is sent to the Tivoli Storage Manager server. AES-128 and DES-56 encryption remains as encryption types that you can use.
Options to bypass integrity checking in a Database Availability Group environment
If at least two healthy copies of a database (one active and one passive copy) exist in a Database Availability Group (DAG) environment, it might not be necessary to verify the consistency of the database and log files. To expedite backup processing, you can bypass integrity checking of database and log files. You can use the /SKIPINTEGRITYCHECK options with the backup command on the command-line interface, or in the MMC.

written by Bosse

Jun 16

ANS1353E and/or ACN5229E errors when attempting a VSS backup

Exchange Comments Off on ANS1353E and/or ACN5229E errors when attempting a VSS backup

Problem(Abstract)

RC53 failure when configuring TSM for Copy Services to perform VSS snapshot backups and the local dsmagent node may not be able to connect properly to the TSM server. These messages can be reported on any tdpexcc command.

Symptom

The errors received are:

ACN5229E Error obtaining VSS information from Local DSMAgent Node: 'NODENAME'. ANS1353E (RC53)   Session rejected: Unknown or incorrect ID entered

Cause

Either the TDP node, the local dsmagent node, or both, lack TSM server administrator ID’s of the same names and client owner authority.

 

Resolving the problem

Run the following commands:

First, if the admin IDs exist with the same names as the nodes (they should have been automatically created when the nodes were registered), then remove them with the following commands:

remove admin [TDPforExchangenodename] remove admin [localDSMAgentnodename]
Then, re-create them with the following command (this will ensure we have clean IDs to work with):
register admin [TDPforExchangenodename] register admin [localDSMAgentnodename]
Finally, run the two commands below to grant each of the admin IDs client owner authority for the nodes whose names they match:
grant authority [TDPforExchangenodename] authority=owner node=[TDPforExchangenodename]
grant authority [localDSMAgentnodename] authority=owner node=[localDSMAgentnodename]

written by Bosse