It’s a cliché, better safe than sorry…
But getting ILM/MIIS 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 ILM configuration.
1. The MicrosoftIdentityIntegrationServer database 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!)
2. MIIS encryption key
When you install ILM, a tool miiskmu.exe is installed with it, and available in the Programs > Microsoft Identity Integration Server menu.
3. 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.
4. Log files
In some opinions maybe less critical, but certainly useful.
5. Configuration files
Some extensions (like logging, GAL,…) use config files to read data.
Also the MASequencer configuration files, if applicable…
FYI: The MIIS Extensions directory is backed up into a Microsoft SQL Server table in the MIIS 2003 database, and the XML files are restored during the MIISactivate process…
6. The scripts, commands and batch file you use to automate MIIS operations.
7. Data of file based MA’s
File-based management agent import and export files that are located in MIIS 2003 installation path\MAData
8. Software setup files
And it’s always handy to make sure you have the software available you used to prepare your MIIS server.
Not only the ILM install files, but also the MIIS 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).
9. MIIS configuration export files
Using the MIIS GUI (Identity Manager) you can export
– The entire MIIS server configuration (Menu File > Export Server Configuration)
– The MA configuration (export management agent, one by one)
– the MV configuration (Metaverse Designer > Export metaverse)
And additional advantage of exporting these configurations is that you can use them to quickly document your MIIS configuration.
See my post on rapidly creating basic documentation of your MIIS setup.
When exporting the MIIS 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.
10. The configuration of the "non-MIIS" 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.ora file, ID files for Notes, …)
11. Documentation of the PCNS setup and config
Although it might be difficult to "backup" the PCNS config. Documenting the setup and the procedures used is of important value.
12. non-MIIS parts & pieces
Another part of non-MIIS backup is the OS, but I’ll suppose it’s sufficiently known how to backup Win2003…
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 MIIS data is distributed over more than one system (eg MIIS server with remote SQL).
13. Document your setup in detail and keep it up to date.
14. External data
An important piece of data that MIIS is managing, is the data residing in the external data sources.
If for some reason MIIS 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 I haven’t forgotten anything (otherwise send me the 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.
A. Fail-over to warm standby MIIS server
A warm standby server is a 2nd MIIS up and running along your production system.
But an active server means you need a MIIS license for that system…
"MIIS 2003 Help : Activating a standby server Running ILM 2007 FP1" explains this procedure in detail (using miisactivate.exe to fail over).
When you run the miisactivate utility, you’ll need the current MIIS encryption key.
B. Fail-over to a cold standby MIIS server
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 MIIS license.
The procedure for recovery is the same, except for a bit more delay to boot up the standby server.
C. Full system recovery
Snapshot restore, bare metal restore, system restore… Get the existing system up and running in one step from scratch. Easy! 😉
D. MIIS Server re-installation
The most time consuming way to recover is completely reinstall your MIIS server from scratch.
A well documented server setup you created before, will be your guide in that case…
Reinstall OS, restore MIIS DB, reinstall MIIS with existing encryption key, restore config and log files, restore MA data, … the full path.
E. Recovering the MIIS application and service with a fresh MIIS install (database intact, encryption key OK, file backup OK…)
One of the interesting features of MIIS is the fact that you can rerun the MIIS setup on top of an existing installation without loosing the configuration.
In the case that MIIS 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 ILM also serves other purposes:
– upgrading IIFP to ILM
– MIIS to ILM update/upgrade
– eval version to licensed version
– relocating the MIIS database (documented here)
Luckily, in some situations you don’t need a complete recovery or a complete reinstallation.
MIIS allows for exporting and importing the server configuration , the management agents and the metaverse, via the MIS GUI.
F. (Re)import the MIIS server configuration
This MIIS 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 MIIS config export.
You can recover the MIIS configuration quickly for example if you wish to recover with a clean MIIS 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 MIIS 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.
G. (Re)Import the MV
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: ILM 2007 FP1 Help: Export Metaverse Schema to File
H. (Re)Import the MA config
The MA export can be used for multiple purposes
– fresh creation of a new MA by importing the MA (without existing MA available)
– duplication of an existing MA (import MA function)
– updating the schema of an existing MA (update MA function)
Keep in mind that adding or creating a new MA, also impacts the MV attribute flow precedence…
I. Database recovery
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 MIIS service, restore the database and restart the MIIS service.
BTW, as the re-installation of MIIS only takes a short time, it still might be a good idea to reinstall on top of the existing MIIS.
J. Recovering the extensions
If the source files of the compiled MIIS .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.
K. Recover MA data and MA related configuration.
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.
L. Recover the external data source
Restore the data on the external data source and rerun your MIIS operations using preview, logging… before performing the export again.
When recovering your MIIS 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.
When you have prepared for disaster recovery, take your time to actually test the different scenarios, by preference on a test environment.
Again, the best experience is doing it yourself.
It’s an important step to avoid unpleasant surprises when disaster kicks in.
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 MIIS server fails, who should you warn or inform if disaster happens, what information do they need,…
When disaster strikes, keep cool and think!
– Immediately shut down/block/disable automated operations and scripts to avoid more trouble
– Check how bad it got
– Choose a recovery plan
– If possible, test the recovery.
– Perform the recovery
– Communicate !
– MIIS Best Practices (in ILM 2007 FP1 Help) provide you with some useful hints & tips.
Well, never say again you hadn’t a disaster recovery plan!
Download this post in pdf at :