Replay 4

Important Release Notes

Build 4.6.28539 and above

This document outlines a several important notices that you should be aware of as you install, configure and begin using Replay 4.6. For important information regarding how to prepare your system before installing Replay, we encouraged you to download and review the installation guide located at http://kb.appassure.com.

New Features

• Reporting – Replay Core will aggregate Replay related activities and produce a report at a specified intervals. Six types of reports can be generated as outline below:
  • Summary Report contains:
    • Protected Machine Status
    • Backup summary
    • Exchange and SQL Mount check summary
    • Replication summary
  • Backup
    • Snapshot details
    • Exchange mount and checksum check details
    • SQL Attachability details
  • Core
    • Summary of Core activities
  • Replication
  • Repository
    • Summary of Repository usage
  • Rollup
  • Virtual Standby
• Hyper-V Cluster Shared Volume (CSV) Support (Beta) – Replay supports protecting Hyper-V hosts in Hyper-V Cluster Shared Volume environment. Protected Hyper-V hosts with CSV will not be able to create virtual standby environments. Hyper-V environments are not supported under VMware or other virtualization technologies.

4.6 Upgrade Instructions

Prior to upgrading the Replay Core, pause snapshot transfers for all Replay Agents. Please make sure that there are no transfers occurring during the upgrade process. A snapshot transfer during an upgrade process may cause a Base Image or Resync to be taken after the upgrade.

Note: If the Replay Agent is uninstalled and re-installed, a Base Image will occur after the upgrade. Uninstalling and re-installing the Replay Core will also cause a Base Image to occur after the upgrade.

Follow the steps below:

1. Upgrade the Replay Core by performing an in-place upgrade. Choose “Modify Replay Core” in the installation setup menu. Step through the Installation Wizard to complete the upgrade process.
2. Upgrade the Replay Agent by performing an in-place upgrade. Choose “Modify Replay Agent” in the installation setup menu or use the Push Install feature to upgrade the Replay Agents.
3. When all Replay Agents and the Replay Core are upgraded, resume snapshot transfers for the Agents. The upgrade process is now complete.

Installation Considerations

• Virus Scanners: When installing the Replay Core on a machine with a Virus Scanner, the “C:\Replay Recovery Points” directory and the Replay repository directories should be excluded from the scan. An example Replay repository name is “E:\TevoRepository”.
• SQL Permission for SQL Attachability Check: The SQL attachability check requires that a local instance of SQL is installed on the Replay Core. Please see this KB4130108 for details.
• Single Mailbox Level Restores: Single mailbox level restores require Outlook to be installed on the Replay Core.

Issues Resolved in this Release

• Admin Console was slow to update protected machine list or to switch between machines.
• Admin Console may not update status when run for a long time.
• Admin Console memory consumption may become high.
• Replay Core memory and CPU consumption may become high.
• Event Id added to Events tabs in Admin Console.
• Nested Groups are now supported for Authentication.

Known Issues

• Reporting feature will not be able to Report on activities prior to the 4.6 upgrade.
• Customers with large number of machines protected by a Replay Core should use SQL Server Database to collect reporting data. Using the default SQLCE database may result in slow queries.
• Replication may show errors on the first Replication attempt after the upgrade. Replication will resume normally after the error.
• Installer package may show ‘Program Compatibility Assistant’ dialog with ‘Unknown Program’ and ‘Unknown Publisher’. The message does not affect the installation.
• MailRetriever restores appointments without ‘Start time’ and ‘End time’ on Exchange 2010.
• Hyper-V exports to a Windows Share may timeout. WORKAROUND: Perform Hyper-V exports to a local volume.
• Recovery points are not correctly shared between nodes in a single-copy cluster if one or both nodes are identified by their fully-qualified domain name (FQDN) or IP address. WORKAROUND:
  when protecting single-copy cluster nodes, add the nodes to Replay using their NETBIOS names exclusively.
• Replay cannot restore mount point information. This will be resolved in a future release.
• Mail store and volume rollbacks to Exchange 2007 CCR clusters require some manual steps to complete successfully. See the section Exchange 2007 CCR Issues for details.
• Rollbacks performed with the Restore button don’t display recovery points if protected server is offline. WORKAROUND: Select the recovery point to roll back from the Recovery Points list, right-click it, and choose Restore.
• Mount points are not preserved on doing an ESX export from 64bit windows 2008 and 2003.
• In rare cases, Snapshots fail with “Unable to transfer snapshot of volume ‘C:’ due to a timeout or a conflict with a transfer from another agent. WORKAROUND: Force a snapshot on one of the agents. This will be resolved in the next release.
• Replay may generate unmountable recovery points when protecting the following volume types:
  1. Windows Server 2003 basic disk converted to simple dynamic.
  2. Basic disks created under Windows Server 2003 and mounted on Windows Server 2008.
• Delete Snapshots operation runs even if replication is in progress. This will be resolved in a future release.
• Replay.log filled with DEBUG messages if replication target changes to later build but replication source stays at old build. This will be resolved in the next release.
• If a VM export can’t be performed due to being in use, the registry is still updated with a new last-exported time. This will be resolved in the next release.
• In Rescue Image restore, initializing a destination disk while other disks are mapped to volumes causes other disks lose mapping. This will be resolved in a future release.
• Newly replicated RPs don’t always appear in console immediately. WORKAROUND: Wait for the recovery points to be updated, make take several minutes.
• AdHoc VM or RP Export automatically aborts if protected server settings are changed. This will be resolved in a future release.

Known Limitations

• Do NOT protect SCC nodes by IP address or FQDN. Replay logs an error “Failed to canonicalize source ‘hostname’ from target path” and replication will fail. Use the NETBIOS name to protect the machine.
• Replay does not support Hyper-V Cluster Shared Volumes in this release. Support for CSV clusters will be offered in a future release.
• Replay will not snap volumes located on an attached VHD.
• BMR of Win2k8 R2 or Win7 machines with SRP will fail to boot without perform several post-processing steps manually. Refer to article: http://www.appassure.com/support/KB/4130306/
• “Add Boot Entry for RRC” option doesn’t work for Win7/2k8r2 boxes with a SRP
• Replay can’t export disks bigger than 2TB to VMware VMDKs. This is a limitation of VMware.
• “Failed to load disk (VDS) information” error appears, when you start BootCDBuilder on Win XP.
• All volumes except “C:” are Offline when booting a VM created from export on 2008.
• Exported VMs may be unbootable on systems with mismatched boot and system volumes
• Base image is taken after restoring to new machine from Rescue Image.
• SQL tab missing on server properties page when protecting a SQL2000 machine.

Push Install Security Considerations

The push install feature is used to install Replay Agents remotely from the Replay Core to centralize the deployment of agents.

If both computers are in the same domain

Push Agent installation from computer A (Replay Core) to computer B (Replay Agent) when both computers are in the same domain.

If one machine is in workgroup other machine in a domain

Push Agent installation from computer A (Replay Core) to computer B (Replay Agent) when computer A is in a domain and computer B is in a workgroup.

How to enable “Remote Administration” rule in firewall on Windows 2008/Vista

Go to control panel. Open Windows Firewall. Click change settings. Go to Exceptions tab. Check Remote Administration.

How to enable “Remote Administration” rule in firewall on Windows 2008 R2/Windows 7

Local Policy

1. Click Start, click Run, type gpedit.msc, and then click OK.
2. Under Console Root, expand Computer Configuration, expand Administrative Templates, expand Network, expand Network Connections, expand Windows Firewall, and then click Domain Profile.
3. Right-click Windows Firewall: Allow remote administration exception, and then click “Properties”.
4. Click Enabled, and then click OK.

Domain Policy

1. Create new GPO in active directory or use current linked GPO, and edit it.
2. Under Computer Configuration, expand Administrative Templates, expand Network, expand Network Connections, expand Windows Firewall, and then click Domain Profile.
3. Right-click Windows Firewall: Allow remote administration exception, and then click Properties.
4. Click Enabled, and then click OK.

Replay Agent/Core Authentication

Unique credentials can be specified for each Replay Agent that is not in the same domain or workgroup as the Replay Core. Replay requires authentication for the following components:

1. Replay Admin Console when connecting to a remote Replay Core for management
2. Replay Core communicating with Replay Agents.
3. Replay Agents communicating with Replay Cores
4. Replication between Cores
5. Replay Agent and Replay Core services

All credentials are validated to ensure the user is in the local “Administrators” group or in the “ReplayAdministrators” group (domain or local). If the credential is not in either of the groups, authentication will fail. If you use the ReplayAdministrators group, these credentials will also ensure that the Administrator level credentials are not required for authorization purposes.

Optionally, this approach allows the security administrator to set up different credentials for different Replay Agents. For single domain or multi-domain implementation with trusts, the default service credentials are sufficient but for multiple domain environments specific Replay Agent and Replay Core credentials are required.

Example 1

There are machines in the network located on multiple domains and workgroups. The security administrator may want to create 1 account on the Replay Core in the ReplayAdministrators group and 1 account each on the agent machines. To configure authentication using the ReplayAdministrators group:

• WORKGROUPA will have WORKGROUPA\ragent1 for agent credentials and COREDOMAIN\radmin for core credentials.
• DOMAINB will have DOMAINB\ragent2 for agent credentials and COREDOMAIN\radmin for core credentials.
• DOMAINC will have DOMAINC\ragent3 for agent credentials and COREDOMAIN\radmin for core credentials.

Example 2

There are machines at multiple customer sites. The security administrator may want to create 3 accounts on the Replay Core in the ReplayAdministrators group and 1 account each on the Agent machines. To configure authentication using the ReplayAdministrators group:

CUSTOMER A will have CUSTOMER-A\ragent for agent credentials and MSPDOMAIN\CUSTOMER-A for core credentials. Customer B will have CUSTOMER-B\ragent for agent credentials and MSPDOMAIN\CUSTOMER-B for core credentials. Customer C will have CUSTOMER-C\ragent for agent credentials and MSPDOMAIN\CUSTOMER-C for core credentials.

Exchange 2010 Support

Replay is an Exchange-aware application that supports the VSS writer for Exchange 2010. For single server implementations, Replay protects the active databases. For DAG implementations, passive mailbox database copies can be protected using Replay reducing the performance impact on active databases.

After performing a restore of a volume containing Exchange 2010 databases in a DAG configuration, you may have to activate a copy of a database (if the database was previously active on this node) or perform a synchronization (if the database was a copy).

Using Replay on Exchange Mailbox Role Servers

If a server is not a member of a DAG, the active databases are protected. Replay will protect all of the volumes including the system volume, the database volumes and log volumes. Full system recoveries, volume and database recoveries are supported. Mailbox database and volume rollbacks to Exchange 2010 DAG clusters require some manual steps to complete successfully. See the rollback and restore sections below for more details.

Using Replay on Database Availability Group Members

If a server hosting the data being backed up is a member of a database availability group (DAG) and hosts both active and passive database copies, the best practice is to protect the volumes that contain passive copies of the databases. This means that passive copies should be placed on volumes that don’t contain active copies. You need to configure Replay to protect the volumes that contain the passive copies only. In the example below, protect the D volume on DAG member 1, F volume on DAG member 2 and the E volume on DAG member 3. Of course, the system volume should be protected along will all volumes on the CAS servers. Full member node recoveries and passive volumes and database restores are supported.

Rolling Back Non-System Volumes Containing Exchange 2010 Mailbox Databases

To perform a roll back on a volume containing Exchange 2010 data on a DAG failover cluster node, you must take the following steps:

• Ensure that whichever volumes you are rolling back to currently have only active mailbox databases or replicated mailbox database that are in the suspended state.
• Ensure the active mailbox databases corresponding replicated mailbox databases are in the suspended state.
• Roll back the volumes using the Replay Admin Console
• Wait for successful completion of the rollback.
• In EMC mount the restored mailbox database.
• In EMC, on the mailbox database with the Suspended status, perform Update Database Copy operation on the suspended copy. NB: when asked about clearing existing logs or checkpoints always answer yes.

Restoring Exchange 2010 Mailbox Databases

To perform a restore of an individual mailbox database to an Exchange 2010 DAG failover cluster, the automatic rollback feature in Replay is not available. Instead, the following manual steps must be taken:

• Stop all Replay snapshots until resumed
• In the Exchange Management Console (EMC) suspend mailbox database copy for the active mdbs you are about to restore
• In EMC, dismount the active mailbox databases you are about to restore
• In Replay Admin Console, mount as read-only the recovery point that contains the mailbox database you are about to restore
• On the active mailbox databases, move or delete ALL files that comprise the mailbox databases you are restoring from their respective directories
• Copy ALL files that comprise mailbox database that you are restoring from the mounted snapshot to their corresponding directories on the ACTIVE DAG cluster node
• In EMC mount the restored mailbox databases.
• In EMC, on the mailbox databases with the Suspended status, perform Update Database Copy operation on the suspended copy. NB: when asked about clearing existing logs or checkpoints always answer yes.

Upon correctly executing these steps the mailbox database will be restored to the active DAG node, servicing clients with a healthy copy in progress.

Preparing Windows 2003/Windows XP Agents for export to Hyper-V

In order to export Windows 2003 machines to Hyper-V, you must install the Hyper-V integration components on the Windows 2003 server before creating a Replay snapshot. You can find the integration components ISO, vmguest.iso, in the c:\windows\system 32 folder on any Windows 2008 Hyper-V host.

If you run the setup.exe in the root of this disk on a Windows 2003 server, it will not install. You will get the message

The Hyper-V integration services can only be installed inside of a virtual machine running under Hyper-V

To get around this you have to drill down to the en-us\update folder and run update.EXE. Now on the server you will then see the hyper-v guest components installed in add/remove programs.

You can now proceed with creating a Replay snapshot of the Windows Server 2003/Windows XP machine. When the snapshot is complete, create a VHD by using the “Create VM” command from the Recovery Points tab and select “Hyper-V R2″ as the export type.

Windows Server 2008 and Windows Server 2008 R2 includes the integration components so the above
steps are not required.

Attaching an Exported VHD

In order to attach an exported VHD, please perform the steps below.

1. Make sure the VHD is accessible from the Hyper-V host.
2. Open the Hyper-V console and create a new VM.

   

3. Configure the new Virtual Machine.
4. Attach the VHD from the Replay export. When selecting the VHD, select the snapshot for the volume and add them in order they exist from the protected server.
5. After creating the new virtual machine, use settings for the virtual machine and match the number of CPU’s from the source machine.
6. After the new VM is booted for the first time installed the hyper-v integration components then it will ask for a reboot, reboot.

Resync vs. Base Images

The difference between a base image and a Resync lies in how the Replay Core handles the data it receives from the Replay Agent. In the case of a base image, every block sent by the agent is stored in a new base image file, which starts a new epoch chain. In a Resync, every block sent by the agent is compared to the value of the same block as it appears in the most recent snapshot of the agent; any block that doesn’t match is written to a new epoch file, which becomes part of an existing epoch chain.

Whenever an agent transmits a base image (due to volume inconsistency after a system failure, an improper volume dismount, a dirty volume, or a missing previous epoch), the core attempts to perform a Resync if possible (the only exception to this is when the ‘Force Base Image’ option is used in the admin console). A Resync is possible if there is a valid epoch chain on the core for the volume being transferred (uniquely identified not by drive letter but by a Replay-assigned GUID), and the most recent epoch in that chain can be successfully mounted by Replay. If a Resync is not possible, the core automatically reverts to transferring a normal base image.

Scheduling Detailed Integrity Checks and Rollups

Detailed integrity checks and rollups jobs can be scheduled on a per protected server basis. This feature is useful when protecting multiple very large transactional environments from one Replay Core. For example, you can schedule rollups to run on the weekend to reduce pressure during the week when you run detailed integrity checks.

APPENDIX A

Event ID Codes and Messages