Hi, FIM documents talk about a warm standby for the sync service - but how do we actually go about setting that up? Is there a step-by-step guide somewhere? do we need to regularly backup some config? do we need to copy anything across to the other server regularly? how does the warm standby take over and become the active role, something about a scripted failover, etc etc.... how does someone who has never done this, setup and ensure that this warm standby is ready and tested? thanks

You can copy the FIM Sync database and the keyset to another server and activate it there. All config, including extension dlls, are in the database and will be restored to the new server. You may have to manually copy any other scripts you use for running tasks or preparing data for the MAs You have two choices with the activation: 1. Run miisactivate.exe which you will find in the Bin folder. This is very quick and simple to use, but will only work if you replaced the default local groups with domain groups during the original setup of the Sync service. 2. Install (or re-install) the Sync Service on the second server, telling it to use the existing DB. Option 1 is quicker and I would recommend it. With Option 2 you may run into trouble with versioning. If you used the default local groups in the first instance you will have to reinstall the sync service on your primary groups and this time replace the local groups with names of existing domain groups.http://www.wapshere.com/missmiis

Hi, Carol explained how to enable the warm stand-by, If you had clustering in mind check Brad's response here . I'm planning to run a "hot" stand-by in my environment, with two separate sync servers running deltas in parallel - but only one doing actual exports, the other one playing catch-up. The main goal was to minimize downtime when updating configuration (the updated one would do full syncs, catch up on deltas and take over with exports when ready), but of course it will also be a backup. Of course everything needs to be properly designed to support this up front. I'll definitely share my experience once I get everything working. Piotr

Yes, we have a clustered SQL backend (all FIM databases will be here). FIM Portal will be running in NLB on 2 machines. FIM Service will be running on 2 other machines. So how do we actually setup the warm-standby in the above setup? MS recommends it, but I cannot find how we are meant to implement it.

Yes, we have a clustered SQL backend (all FIM databases will be here). FIM Portal will be running in NLB on 2 machines. FIM Service will be running on 2 other machines. So how do we setup the warm-standby in the above setup?

A warm-standby server is simply a second server that has the FIM Sync components installed on it but are not actually in operation. You technically don't have to have anything installed but it will save you time. You will need to ensure that the same patches are deployed on the warm-standby server and that the FIM Sync service is set to Manual start. As Carol pointed out, once you run miisactivate.exe the Service is started and the database is updated to work with the new instance of the FIM Sync service (keyed from your server name). You will need an up to date MIIS Encryption key ring to complete the process. Miisactivate will extract the extension directory from the SQL DB and rebuild that for you, but again, as Carol points out, this does not get you anything in your MAData folder, or any run profile/automation scripts. I did a session at TEC last year on this scenario, and I highly recommend that if you're going to pursue the warm-standby scenario that you combine it with DFS and Group Policy preferences. DFS will help replicate all of the "other" stuff the db doesn't backup for you between the two servers while GPO preferences will allow you to preserve any localized scheduled tasks (assuming you're not using something like SQL Agent instead). The warm-standby scenario only addresses HA for the Sync Service, and assumes you are resucing the database through some other means either a direct restore, through clustering, or even mirrored. With respect to mirrored databases, automatic failover is not supported yet, so while you can do this on the SQL side, you need to manually failover the mirror to the secondary and then run miisactivate. I'll post my TEC presentation to the blog here in just a bit: http://www.identitychaos.comBrad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

Ok, picture is becoming clearer - the next concern is around the 'other' stuff you mentioned...how do I get a complete list of these extra items we need to cater for that are not in the SQL databases? thank you

Al those "extra items" are things you will have created yourself (scripts, scheduled tasks) so you should know.http://www.wapshere.com/missmiis