You are here: Application protection > Failing over application jobs > Failing over application jobs configured for identity failover

Failing over application jobs configured for identity failover

When a failover condition has been met, failover will be triggered automatically if you configured automatic failover when establishing protection. If you configured manual intervention before failover, you must use the Failover Control Center to initiate failover for application workloads configured for identity failover. This is a legacy console that is eventually being phased into the Double-Take Console.To access the Failover Control Center, select Start, Programs, Double-Take, Availability, Double-Take Availability Failover Control Center.

On the main Failover Control Center page, click Add Target, specify your target server, and click OK.
After the target is inserted in the Target Machine list, click Login. Supply valid credentials if prompted.
Highlight the failed source and click Failover.
Select the how you want to handle the data in the target queue. You may want to check the amount of data in queue on the target by reviewing the Statistics or Performance Monitor.

Apply Data in Target Queues Then Failover— All of the data in the target queue will be applied before failover begins. The advantage to this option is that all of the data that the target has received will be applied before failover begins. The disadvantage to this option is depending on the amount of data in queue, the amount of time to apply all of the data could be lengthy.
Discard Data in Target Queues and Failover Immediately— All of the data in the target queue will be discarded and failover will begin immediately. The advantage to this option is that failover will occur immediately. The disadvantage is that any data in the target queue will be lost.
Revert to Last Good Snapshot if Target Data State is Bad— If the target data is in a bad Double-Take Availability state, Double-Take Availability will automatically revert to the last good Double-Take Availability snapshot before failover begins. If the target data is in a good state, Double-Take Availability will not revert the target data. Instead, Double-Take Availability will apply the data in the target queue and then failover. The advantage to this option is that good data on the target is guaranteed to be used. The disadvantage is that if the target data state is bad, you will lose any data between the last good snapshot and the failure.

Click OK.

After failover is complete, clients will be rerouted to the target, which is standing in for the source.

The following notes apply to Exchange protection.

Users using Outlook or Outlook Web Access to receive e-mail can connect after the changes have propagated through your environment. Users that had Outlook open during failover will need to restart the Outlook client (excluding Outlook Web Access clients on a LAN). Additionally, those users using Outlook Web Access or Outlook 2007 may see a security alert because the security certificate has the source server name but Exchange is now on the target. Click Allow or OK to dismiss the alert.

You will not be able to log in to the domain from the source Exchange server after failover because the target has assumed the source server's host Service Principal Name so that Outlook Web Access can use the source name. If you need to log in to the domain and Outlook Web Access is not needed, contact technical support for a workaround.

If you SMTP gateway is configured to send e-mail to a specific IP address that address is not failed over to the target, you will need to update the IP address after failover.

Mail stores or storage groups created after a failover will not be failed back.

The following notes apply to SQL protection.

After failover, linked databases in the SQL instance will be unavailable until the service master key is updated. You will need to run the command "alter service master key force regenerate" against the SQL target server to reset the service master key and then remove and re-add the linked servers into the target SQL instance.

After failover with a snapshot of a SQL database-only server, the SQL services on the target server are stopped and the databases are not mounted. You will need to manually start the MSSQLServer service for each instance on the target server and then manually attach the databases.

After failing over SQL 2008, Rich Internet Applications created using ADO.net 2 may not connect.

After failing over SQL 2008, you may not be able to take the SQL database offline. If this occurs, stop and restart the SQL Server Management Studio application, and then you can take the database offline.

After failing over in a SQL workgroup, you will not be able to connect to the source server instance of SQL. You can work around this issue by creating an alias on the target with the source server’s name.