It’s a cliché, better safe than sorry…
But getting FIM up and running again shouldn’t be that hard, at least if you have prepared for it. There are a few components which you should take into account for backing up your FIM configuration.
↑ Return to Top
Bookmark this page as: http://aka.ms/FIMDRP
Download a template document of this procedure at : http://aka.ms/fimdrpdownload or http://aka.ms/mimdrpdownload
This applies to any server on which FIM components are installed.
Lots of environments run their servers on a virtualized machines, most of these VM systems allow to snapshot the guest system.
Advantage
Disadvantage
Known issues with Snapshots
More details at: MIIS/ILM/FIM: How to Backup the Synchronization Engine
The FIMSynchronisationService database is hosted on SQL.
Make sure you have a regular backup of your database using the SQL Management tools.
It seems obvious, but also perform a restore once in a while. (Doing is the best practice!)
Recommendation
When you install FIM, a tool MIISkmu.exe is installed with it, and available in the Programs > Microsoft Identity Integration Server menu.
The following registry keys under the path [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FIMSynchronizationService]:
Safeguard the source files of the extensions you created and compiled.
This allows you to recompile the extensions if needed.
Before you start editing and recompiling the extensions, make a backup of the source.
In some opinions maybe less critical, but certainly useful.
Some extensions (like logging, GAL,…) use config files to read data.
Also the task scheduler or MASequencer configuration files, if applicable…
FYI: The FIM Sync Extensions directory is backed up into a Microsoft SQL Server table in the FIM Sync database, and the XML files are restored during the FIM Syncactivate process…
The scripts, commands and batch file you use to automate FIM Sync operations.
(Cfr. FIM Sync Design and Planning collection)
File-based management agent import and export files that are located in FIM Sync installation path\MAData
And it’s always handy to make sure you have the software available you used to prepare your FIM Sync server.
Not only the FIM install files, but also the FIM Sync Resource Took Kit files, Visual Studio, SQL server and other tools you used for configuration, troubleshooting and other operations…
In general, make sure your backups are stored safely (and better at safe distance).
Using the FIM Sync GUI (Identity Manager) you can export
Important notice:
When exporting the FIM Sync configuration,the export does NOT export the content of the connector spaces, nor the metaverse. Also the exensions associated with the MA and MV are not exported.
Independent the tool used to schedule you FIM Sync run profiles, make sure you have a backup of
Theconfiguration of the "non-FIM Sync"tools and clients
For some MA’s you need to configure a client or specific files, or specific network settings. You better make sure you’ve documented these settings or make a backup of this configuration part.
Let me explain: for example the configuration of the hosts file, the services file, system files that are customized to support clients like the Oracle or SAP client.
Other client specific configuration (names.orafile, ID files for Notes, …)
Although it might be difficult to "backup" the PCNS config. Documenting the setup and the procedures used is of important value.
Another part of non-FIM Sync backup is the OS, but I’ll suppose it’s sufficiently known how to backup Windows Server…
One way of backing up the system is a full system backup of your server.
On server system level, virtualisation also offers a way of taking a snapshot of the server image.
But still this doesn’t cover the list if the FIM Sync data is distributed over more than one system (eg FIM Sync server with remote SQL).
Remark: be aware of the Microsoft support policy for systems in a virtualized environment (here and here)
Partially taken from: FIM Service Backup and Restore
Sample script
See also: How to back up and restore the relevant SQL databases. For more information, see Backup Overview (SQL Server) (http://go.microsoft.com/fwlink/?LinkId=184023).
The FIM Service Configuration File, which is located at %programfiles%\Forefront Identity Manager\2010\Service\Microsoft.ResourceManagement.Service.exe.config.
The following registry keys under the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FIMService:
SQL Server Agent Jobs:
For detailed guidance, check TechNet FIM Service Backup and Restore
See: FIM Portal Backup and Restore
See: FIM 2010 R2 Reporting Disaster Recovery: http://technet.microsoft.com/en-us/library/jj133846(v=ws.10).aspx
See: http://technet.microsoft.com/en-us/library/jj133846(v=ws.10).aspx
It is highly recommended that you follow the procedures outlined in the System Center Service Manager 2010 SP1 Disaster Recovery Guide. These procedures describe backing up the databases and the encryption key that is created when System Center is deployed. It also provides useful SQL scripts for capturing and preserving SQL Server logon and object level permissions information.
<in progress>
See: http://technet.microsoft.com/en-us/library/fim_cm_backup_and_restore(v=ws.10).aspx
For a downloadable version of this guide, see the Microsoft Download Center FIM CM 2010 Backup and Restore (http://go.microsoft.com/fwlink/?LinkId=200498).
Document your setup in detail and keep it up to date.
Documentation should include:
An important piece of data that FIM Sync is managing, is the data residing in the external data sources.
If for some reason FIM Sync exported wrong of faulty data, it can be quite hard to roll-back the export.
Better make sure the data source administrators got their data backed up.
Now you should have secured the most important pieces of the configuration.
Let’s hope we haven’t forgotten anything (otherwise send feedback).
Having a backup is one thing, restoring is another.
Depending on how bad your server got damaged, you have some options for recovery.
It depends on the type of disaster which options to choose or to combine.
Configuration components don't change frequently (or should not). Configuration items only need to backupped before and after the change to allow recovery.
It's a best practice for the administrators to take a backup of the configuraton before and after they change configuration.
Component that change base on the FIM processes require frequent backup to allow recovery of the entire FIM content.
It's higly suggested to take regular (automated) backup of the data components. But it's not required to take full backups on a high frequency
Suggestion
A warm standby server is a 2nd FIM Sync up and running along your production system.
But an active server means you need a FIM Sync license for that system…
"FIM Sync Help : Activating a standby server Running ILM 2007 FP1" explains this procedure in detail (using FIM Syncactivate.exe to fail over).
When you run the FIM Syncactivate utility, you’ll need the current FIM Sync encryption key.
This is the same procedure, but with the secondary server NOT up and running simultaneously.
For this reason there is no need for an additional FIM Sync license.
The procedure for recovery is the same, except for a bit more delay to boot up the standby server.
Snapshot restore, bare metal restore, system restore… Get the existing system up and running in one step from scratch.
Easy! ;)
But usually a pretty lengthy job, that requires additional tasks...
The most time consuming way to recover is completely reinstall your FIM Sync server from scratch.
A well documented server setup you created before, will be your guide in that case…
Reinstall OS, restore FIM Sync DB, reinstall FIM Sync with existing encryption key, restore config and log files, restore MA data, … the full path.
Recovering the FIM Sync application and service with a fresh FIM Sync install (database intact, encryption key OK, file backup OK…)
One of the interesting features of FIM Sync is the fact that you can rerun the FIM Sync setup on top of an existing installation without loosing the configuration.
In the case that FIM Sync gets corrupted as application, just rerun the setup and reconnect to the existing database when the wizard asks for the database location.
A fresh install of FIM/ ILM also serves other purposes:
Luckily, in some situations you don’t need a complete recovery or a complete reinstallation.
FIM Sync allows for exporting and importing the server configuration , the management agents and the metaverse, via the MIS GUI.
This FIM Sync server configuration export only contains configuration data only, not the live data of objects in the CS or metaverse. The actual compiled extensions are not included in the FIM Sync config export.
You can recover the FIM Syncconfiguration quickly for example if you wish to recover with a clean FIM Sync database (and then run the full import and sync run cycles..)
This method also allows for initially uploading an existing (test)configuration in to a blank FIM Sync production server.
But also an existing setup can be restored, for example in case of a misconfiguration.
If you need more detailed info on this method, check the ILM 2007 FP1 Help: Importing and Exporting a Server.
The metaverse can be exported and imported separately from the server config.
This is a useful for a emergency recovery of the MV.
More info: FIM 2010 Help: Export Metaverse Schema to File
The MA export can be used for multiple purposes
Keep in mind that adding or creating a new MA, also impacts the MV attribute flow precedence…
In some situations it is faster to to restore the complete SQL DB with the actual data (configuration AND object data).
Supposing the encryption key is OK, stop the FIM Sync service, restore the database and restart the FIM Sync service.
BBTW, as the re-installation of FIM Sync only takes a short time, it still might be a good idea to reinstall on top of the existing FIM Sync.
If the source files of the compiled FIM Sync .NET extension have been deleted of corrupted, restore (or copy) a backup of the project files to original location. Eventually you might need to recompile (rebuild) the .NET projects.
Some MA’s need external configuration (like the ERPMA config tool for SAP).
Other MA’s (file based MA’s) need their data in the MA subfolder…
Restore the configuration and/or data files from backup to their initial location.
Restore the data on the external data source and rerun your FIM Sync operations using preview, logging… before performing the export again.
When recovering your FIM Sync server, it might be wise to temporarily turn off the provisioning in the first phase.
Then run the imports and synchronization cycles.
If that runs fine, re-enable provisioning and run the cycles again.
Install the FIM Service on a computer in the same Active Directory domain as the FIM Service was previously installed. When installing the FIM Service to a new database the SQL Server Agent Jobs are automatically restored.
Ensure that the FIM Service and SQL Server Agent are not running. If it is not possible to stop the SQL Server Agent, ensure that the FIM stored procedures are not running and disabled. Use the appropriate method for restoring the database, depending on your backup type and the data that you want to recover. See Restore and Recovery Overview (SQL Server) (http://go.microsoft.com/fwlink/?LinkId=184026) for more information.
Restore the SQL Server database. It may be necessary to close open connections on the SQL Server database. For more information, see sp_who (Transact-SQL) (http://go.microsoft.com/fwlink/?linkid=181177).
Restore and validate the .NET Application Configuration file.
Restore the registry key values.
Restore the SQL Server Agent jobs.
Start the FIM Service and SQL Server Agent.
Install the FIM Service on a computer in the same Active Directory domain as the FIM Service was previously installed. When installing the FIM Service, connect to the existing database.
Validate the registry key values. Restore if required.
Validate the SQL Server Agent jobs. Restore if required.
Restart the FIM Service and SQL Server Agent.
Review your disaster recovery planning from time to time.
Keep in mind that a good preparation and the necessary technical precautions are not the only part of disaster recovery.
Plan for crisis communication: who is impacted if the FIM Sync server fails, who should you warn or inform if disaster happens, what information do they need,…
When disaster strikes, keep cool and think!
Well, never say again you hadn’t a disaster recovery plan!