Skip to Content

Disaster recovery in Afaria 6.6

1 Introduction

1.1 Executive Summary

This purpose of this document is to provide to the system administrator guidelines for disaster recovery of an Afaria 6.x Server or an Afaria 6.6 Server Farm.


This document is intended to provide the reader with information on how to properly configure the backing up of the core Afaria components: the Afaria Server, the Afaria Administrator, and the Afaria Database Server that houses the Afaria database.

The Afaria system can be extremely complex and thus a well thought out plan is required to perform successful backups of the system. First, however, one must understand how the Afaria components work together.

1.2 Common Terms

The following is a list of common terms used when discussing an Afaria environment:

Afaria Server:

The Afaria Server is the machine where the Afaria program files are installed. It is also the machine on which the administrator creates the Client installation kits. This machine communicates with both the database server and the Afaria Administrator system(s). Each communication Session is initiated by Client into the Afaria Server.

Afaria Administrator:

The Afaria Administrator is the browser-based, Server-side interface for Afaria. Through the Administrator, the Afaria administrator can define the parameters of the Server; create and respond to alerts on the system; set security on the system; create channels to send data to or retrieve data from Clients; view and manage Server and Client data, and communicate with other Servers. Afaria Administrator consoles reside on IIS.

Database:

Database Refers to the Database Server platform that is supporting the Afaria database. (MS SQL, Oracle, or SQL Anywhere)

Remote Afaria Administrator:

The user runs Internet Explorer on a remote machine to access the Afaria Administrator Web Console. User connects to the virtual directory served by IIS on the Afaria Administrator system. Internet Explorer must be properly configured for .NET Framework runtime security using the securityconfig.exe utility provided by Afaria.

1.3 Assumptions

The following assumptions are made for this document:

  1. This section assumes the reader is familiar with Afaria, IIS, and the Database Server platform that supports the Afaria database (MS SQL Server, Oracle, or SQL Anywhere).
  2. The account being used to install and move accounts is an Administrator account and all rights are assigned.
  3. The passwords for all relevant accounts must be known.
  4. The default install directory is being used. This is C:\Program Files\Afaria. If a custom installation directory is being used, that path should replace any instances of the default path in this document.

2 Backup up a Stand-Alone Server/Administrator Environment

A successful disaster recovery policy requires a well-planned and tested backup procedure. This

procedure should include the following: what to backup, directions for performing backups, when to

perform backups, testing the backups, and directions for restoring the backup.

The following outlines proper procedures for backing up each element within an Afaria environment. It is recommended to back up channels and the database at the same time. If this plan is followed successfully the Server ID (Transmitter ID), Internal Channel IDs and Client GUID integrity will be maintained.

2.1 Afaria Server

  1. Stop the Afaria Server service.
    1. This can be accomplished by executing net stop “Afaria Server” /y from the command line.
  2. Export all Afaria Channels, Profiles and Monitors. Ensure that the option to include the content and assignments for each channel are selected.
    1. Afaria Channels - This process can be accomplished by executing the following command through a Session Manager channel or by using a simple batch file: C:\Program Files\Afaria\Bin\xaexport.exe \ c:\backup.cmx /r

      C:\Program Files\Afaria\Bin\xaexport.exe is the command line version of the export command, “\” refers to the root server, “c:\backup.cmx” is the file that contains the backed up channels, “/r” states to include all channels below the server name.
    2. Afaria Profiles and Monitors - This process can be accomplished by executing the following command via a Session Manager channel or by using a simple batch file: C:\Program Files\Afaria\Bin\profileimportexport.exe /export /file c:\backup.pmx
    3. Example of a Session Manager channel worklist
        1. Optional – Automating the Export of the Channels, Profiles and Monitors Alternatively, the administrator can create a Windows Task Scheduler task that executes the Channel Export on a daily basis.
  3. Export HKEY_LOCAL_MACHINE\Software\Afaria to a registry file (.reg)
    1. This must be done in order to preserve the unique Server ID (Transmitter ID) and server settings that stored in the registry
  4. Backup the C:\Program Files\Afaria\ directory
    1. The default Afaria Server installation directory to preserve all Channel IDs, Channel worklists, any worklist assignments within Channels, worklist priorities, etc.
    2. Backup the C:\ABD directory if using Backup Manager
      1. This directory contains all of the Client backups if using Backup Manager Channels.
  5. Start the Afaria Server service
    1. This can be accomplished by executing net start “Afaria Server” /y from the command line.

2.2 Afaria Administrator

Using a backup program of the customer's choice backup the entire \<virtualdirectoryname>\*.* specified during the Afaria Administrator install. This is necessary in order to backup the roles any customized reports.

2.3 Database

Refer to Microsoft SQL, Oracle, or SQL Anywhere documentation for backing up the Afaria database. It is recommended the administrator creates a maintenance plan to run this backup on a scheduled basis. It is necessary to stop the Afaria Server service when performing a database backup in order to get a complete backup.

2.4 Remote Afaria Administrator

It is not necessary to backup a Remote Afaria Administrator since it is only used to administer the Afaria Server via Internet Explorer

3 Restoring a “Stand-alone” Afaria Server

3.1 Database

This section is only necessary if installed on same machine as Afaria Server OR if the database is being moved to another server.

Refer to appropriate documentation for restoring a database for the Database Server platform in use for the environment. The Afaria Database must be restored prior to recovery of Server and/or Administrator. Ensure all user security accounts have been recreated and aliased properly as per the Installing Afaria Guide for the appropriate version.

3.2 Afaria Server

  1. Edit the registry file (.reg) created during the last backup to remove the section that holds the history of installed software updates on the Afaria Server
    1. Note all of the installed Hot Fixes and/or Service Packs that are installed prior to removal listed under HKEY_LOCAL_MACHINE\Software\Afaria\Server\Patch
    2. Remove everything under HKEY_LOCAL_MACHINE\Software\Afaria\Server\Patch
    3. Re-save the registry file.
  2. Import the modified registry file (.reg).
  3. Restore the entire C:\Program Files\Afaria\ directory that was backed-up previously
    1. This is the default Afaria Server installation path, path may be different
  4. Install the Afaria Server from the CD/Installation image
    1. Select the default options. This will ensure that the server is using the service account name, password, and authentication/assignments as the original Afaria Server system. If the Database server is changing, ensure that the new values for the server are being used.
  5. From a backup restore the C:\ABD directory.
    1. This will restore the Client backups for the Backup Manager component.
  6. Import the Afaria Channels from export file (.cmx).
  7. Import the Afaria Profiles and Monitors from the export file (.pmx)
  8. Re-Apply the same Afaria Hot Fixes and/or Service Packs noted in step 1.1.

3.3 Afaria Administrator

This section is only necessary if the Administrator is installed on same machine as Afaria Server
  1. Restore the entire Afaria\<virtualdirectory>\*.* that was backed-up previously.
  2. Delete HKLM\SOFTWARE\Afaria\WebUI and HKLM\SOFTWARE\Afaria\Workstation keys from the registry.
    1. Deleting these keys will allow the install to specify the virtual directory name during the installation.
  3. Install the Afaria Administrator from the CD/Installation image
    1. Select the default options. This will ensure that the server is using the service account name, password, and the domain used for policies as the original Afaria Administrator system.
    2. During the installation specify the original virtual and physical directory name.
  4. Re-Apply the same Afaria Hot Fixes and/or Service Packs noted in step 3.2 Step 1.1 above.

3.4 Remote Afaria Administrator access

The end-user may need to re-run security configuration utility (securityconfig.exe) upon connecting to the Afaria Administrator web console via Internet Explorer the first time after the any systems are recovered.

4 Backing Up/Restoring a Server Farm Environment

An Afaria Server Farm configuration is defined as an environment that has one Master Server and one or more Replication Server(s) installed. All channels are setup on the Master and then are replicated to each Replication Server that is participating in the farm. One of the benefits of a farm environment is

that if a Master system goes down, Clients can continue to connect to the Replication Server systems. Channels cannot be created on slave systems.

4.1 Master Server

Follow the same guidelines outlined above for “Backing Up and Restoring a Stand-Alone Server Environment."

4.2 Replication Server

  1. Follow normal system backup procedures for any Windows Server.
  2. Prior to reinstallation, remove the row correlating to this Replication Server system from the A_SERVER table in the Afaria database.
  3. Reinstall the Afaria software pointing to the current location of the database.
  4. By pointing to the database, the server will automatically install as the role of a Replication Server system.
  5. Once reinstalled, verify the Farm relationship from the Master server. The administrator may need to reconfigure Channels Replication Schedule and/or re-replicate Channels.

5 Multitenant Environment

A tenant is an entity defined within the Afaria environment that is associated with a subset of the client base and its related operations and assets. Assets include non-client items that support operations and profiles, such as policies and channels. Tenant features let the administrator maintain clients and assets for multiple tenants. For example, the administrator may want to operate the Afaria installation as a hosting environment to multiple customers or multiple enterprise divisions, with each customer or division assigned to a different tenant identity. Multi-tenancy is the state of an Afaria installation that has the tenant features enabled.

5.1 Backup and Restore a Multi-tenant Environment


If backing up a Multi-tenant server, follow the same guidelines outlined above for backing up and restoring a stand-alone environment, but pay close attention when exporting and importing channels. Since there is more than one tenant, channels and profiles will need to be looked at on a per tenant basis.
Do so by following these directions:

  1. Export channels using the /r command as described in the stand-alone environment guidelines.
  2. Export profiles on a per tenant basis using the following command instead of the one listed above: C:\Program Files\Afaria\Bin\profileimportexport.exe /export /file c:\backup_<tenant name>.pmx /tenant <tenant name>
  3. Import channels and profiles on a per tenant basis. Make sure that the restored channels and profiles are assigned to the correct tenant.

6 Summary


As with any Disaster Recovery Plan, it must be thoroughly tested in order to validate it. Testing will validate the steps included in this document, indicate any additional steps that must be included (possibly due to a customized or unique environment), and provide the level of comfort that the systems can actually be restored in the event of a failure.

Tags: