Adventures in identity management
I’ve been working a lot on config migrations lately – specifically migrating FIM configuration from dev to test to prod. I wanted to be able to easily compare two Sync Service configurations: before a migration to see what the differences are; after a migration to confirm that the servers are now the same; as a…
Run History should be regularly cleared to keep your database file sizes under control. There’s also not a lot of point keeping weeks (let alone months or years) worth of run history in the Sync Service. It shows when profiles ran and whether there were any errors, but click on a CS object and you…
Both in the Sync Service and the Portal there may be regular error messages that we just live with. We’ve figured out they’re “low priority” or perhaps they’re false alerts, where FIM thinks there’s an error but the end result is fine. However, as much as possible, we should aim for a system that runs…
The company I work for, Unify Solutions, has a product called Event Broker which I’ve blogged about before. However I was still pretty new to it then and treating it as a straight replacement for scheduling scripts. Now I’m starting to use it properly I can see there’s a lot more to it.
The Sync Service is good at maintaining connections between objects, and synchronising data between them. What it has never been so good at is constructing data from complex rules and lookups, so as much as possible, do the complex processing outside the Sync Service and present the data in a way that it can use…
There’s a box you can tick on the Deprovisioning Options page in your MA configurations – it says “Do not recall attributes on disconnection”. My advice: don’t tick this box.
When creating an MA that is a projection source or a provisioning target it is easy to overlook the join rules, as the objects are effectively already joined. But you should still have them. The other part to this is about complex join rules. While joining a new directory for the first time you may…
Our Metaverse should be the defining store of digital identities along with the best quality data we can gather about them. And ideally each person in our environment should only be represented once in the Metaverse.
It is almost always a bad idea to create extra objects types for the same basic “thing”. An object type should encompass all the possible states an identity can transition to. A person can never become a group, but they can definitely be staff, contractor or student (sometimes all at the same time) so a…
Following on from my recent post about Upgrading MIIS/ILM to FIMÂ I’ve now posted the helper scripts mentioned in that post (and demo’d in my TEC session) on the brand new FIM Team Community site. We’ll be putting various goodies on this site that we want to make publicly available and the other thing you’ll find…