For anything above the simplest GALSync deployment, and particularly if you have the FIM Portal, you must have development and test environments.
There are always a number of different ways you can approach each problem, and you need a suitably representative Dev environment to try them all out.
Meanwhile Test should be as close to production as you can get it so you can properly test any changes. Once changes are applied in production and have impacted production data they can be hard to roll back. Good testing is key!
Requirements for Development
- All FIM components on the same versions as Prod.
- Each production system represented: at least a text file MA with a data dump if you can’t have a full Development version of the connected system.
- A representative sample of production identity data.
Requirements for Test
- All FIM components on the same versions as Prod.
- A Test version of each production system, same versions and config as prod.
- A full set of production identity data.
- A similar spec to Prod as you are likely to run more Full Syncs in Test and bad performance can seriously curtail testing.
Migrating Configuration from Dev to Test to Prod
There are good resources on the Microsoft website for configuration migration: http://technet.microsoft.com/en-us/library/ee534906(v=ws.10).aspx
It is worth thinking of the need to migrate configuration changes when designing your system components. Some tips:
- Always use a constants lookup file with any custom code so you can have an environment-specific lookup file and use the same code.
- The Portal migration scripts work better if you have the same people in all environments – particularly if they are members of manual groups or sets.
- Small changes are often simpler to apply by hand rather than configuration migration.
Refreshing Dev and Test Environments
Inevitably Dev and Test environments will diverge from the Prod environment, so it can sometimes be very useful to do a refresh from Prod.
The best way to ensure you get everything is by transferring the databases. If you’re transferring to a different domain you need to do a couple of other steps:
- Reinstall the Sync Service using the prod DB and specifying new service accounts and groups.
- Reinstall the Portal using the prod DB and specifying new service accounts. Then use this script to change the Built-In Administrator account.
Carol,
Would making small changes by hand for the sake of simplicity cause problems for a later configuration migration? For the portal configuration I believe the changes are moved by doing comparisons with PowerShell, and depending on the manual change the objects might not match up correctly. I’m just curious about your view on that, as I’ve only done that kind of configuration deployment in a lab in the context of a training course.
Chris
Hi Chris. The Portal migration scripts match on object display name, so as long as you make sure that is correct the migration scripts will be fine. The Sync Service config migration works by updating the whole MA – however this can cause unexpected changes with precedence rules, so you either have to update the entire server config (may not be practical due to inevitable differences between test and prod) or make the changes by hand. If I’m just modifying a flow rule or two I’ll do it by hand.
I’m using the following setup with some success. The names don’t make as much sense as they could because several of them existed prior to our FIM implementation.
-Lab: A single VM that doesn’t resemble production at all, I can just use it to test what-ifs
-Sandbox: This is where real FIM development happens. Only has about a dozen users in the HR database, so sync runs are very fast.
-Dev: This is where other (non-FIM) administrators and developers are first exposed to FIM changes. Contains a copy of production HR data, so all users are represented. You could consider this an integration test environment.
-Test: This is where end users will get a chance to interact with it, as most of our test/pre-prod applications are installed in this environment. I usually leave a new FIM deploy here a week to “bake” before releasing to prod.
-Prod: The real deal.
I’m very happy to have the sandbox environment, FIM development is painfully slow with a full user load. It also gives me two chances to practice deploying a particular configuration update before going production.
The downside: The domain names are different for each environment, which means my FIM config doesn’t migrate very cleanly. I have a script that fixes many LDAP DNs in the policy.xml, and then I manually update the inbound short domain name flows on a half dozen sync rules. Novell IDM has the notion of a global variable that can be set at the server or driver (management agent) level, and they are great for things that change between environments. Really wish the FIM Service has something similar for sync rules.
Rant: I hate the FIM metaverse+service config migration process. It takes way too long, and is too brittle. With Novell IDM I could deploy a single driver (MA) in a couple minutes, and I seldom needed to do more than that. With FIM, I’m usually in it for at least a couple hours, plus however many hours it takes for update all the objects in the portal if my config changes cause that to happen.