DSA Recovery

When recovering a lost DSA server, all top-level BigFix relays (and therefore the entire deployment) should already be pointing to the remaining DSA server. It is recommended to leave all relays and clients reporting up to the working DSA server during this recovery procedure. If your existing relay settings do not allow this, isolate the server being restored on the network such that only the working DSA server can connect to it.

If the master DSA server fails, run the following procedure on the BFEnterprise SQL database to promote the secondary DSA server to master during restoration and replication of the failed server.
```
declare @ServerID varchar(32)
select @ServerID = convert(varchar(32),ServerID) from DBINFO
execute [BFEnterprise].[dbo].[update_adminfields] 'Z:masterDatabaseServerID',@ServerID 
```
In this way you can install a new DSA server and you can run the Administration Tool on the secondary DSA server during the restoration of the failed server.
On the existing DSA server delete the failed DSA server id from the database.
1. First see what the existing DSA server id is by executing the following SQL statement.
```
select ServerID from DBINFO 
```
2. List the IDs of the DSA servers:
```
select * from REPLICATION_SERVERS 
```
3. After identifying the failed server ID, run the following procedure:
```
execute BFEnterprise.dbo.delete_replication_server <ID> 
```
Restore the server operating system and database software in a pristine state without any BigFix server or the BigFix database remnants.
Restore the following items from backup:
- [IEM Server folder]\BESReportsServer\wwwroot\ReportFiles
- [IEM Server folder]\Encryption Keys (can be optionally restored by copying from the secondary server, or a new key generated by the Administration Tool)
- [IEM Server folder]\UploadManagerData (optional, for faster recovery of SUA data if lost server was the SUA Source)
- [IEM Server folder]\wwwrootbes\bfmirror\downloads\ActionURLs
- [IEM Server folder]\wwwrootbes\bfmirror\downloads\sha1 (optional, for faster recovery of cached files)
- cert.pem file for Web Reports, if using HTTPS
- BESReporting database in SQL Server
Install BigFix server using the installer and the existing masthead. For additional information see Installing Additional Windows Servers.
Set the following registry values:
For 32-bit Windows systems, go to [HKLM\Software\BigFix\Enterprise Server\FillDB] or for 64-bit Windows systems, go to [HKLM\Software\Wow6432Node\BigFix\Enterprise Server\FillDB] and then set the following values:
```
"PerformanceDataPath"[REG_SZ] = "[IEM Server folder]\FillDB\FillDBperf.log"
"UnInterruptibleReplicationSeconds"[DWORD] = 14400 (decimal)
ReplicationDatabase=<DBName>
ReplicationUser=<DBUser>
ReplicationPassword=<DBPassword>
```
Restart the BES FillDB service.
Install BigFix client and console.

After replication completes, run the following procedure on in the SQL database to promote this newly restored BigFix server to be the master server.

declare @ServerID varchar(32)
select @ServerID = convert(varchar(32),ServerID) from DBINFO
execute [BFEnterprise].[dbo].[update_adminfields] 'Z:masterDatabaseServerID',@ServerID

Reinstall and reconfigure the Plugins. Configuration information can be gathered from the currently operating DSA server or from installation notes and configuration details kept by the Administrator.
Set the following registry values and restart the BES FillDB service:
Go to [HKLM\Software\Wow6432Node\BigFix\Enterprise Server\FillDB] and then set the following values:
```
"PerformanceDataPath"[REG_SZ] = ""
"UnInterruptibleReplicationSeconds"[DWORD] = 120 (decimal)
```
Launch the Administration Tool and update the replication interval on this restored server to the desired level. Typically, this value should match the interval set on the other DSA Server.
Note: Depending on the size of the deployment, the replication process might take multiple days to complete. To validate its completion, look for a Replication Completed message in the FillDBperf.log file. Connecting a separate BigFix console to each DSA server and comparing contents is another way to check that the data is synchronized in both deployments.