However, all the groups (1.600+) would continue to start their life in Active Directory based on some scripts. Therefore we wanted to bring all groups from Active Directory and in to the FIM Service just once and from there on manage all attributes including membership filters from the FIM Service.
Due to precedence, we could not use the FIM MA to create the groups in the FIM Service, so we had to come up with another solution. Again, my PowerShell MA came to the rescue.
Here is how we did it -
- We created another standard Active Directory MA scoped to the few OU's that contained the groups in question. We set that MA to only import and project a new metaverse type (dfsGroup) and import a few attributes, such as sAMAccountName, displayName, description and such.
- We then created a PowerShell MA (PSMA) for use with the FIM Service. For this we used my PowerShell MA.
- We wrote provisioning code to provision all dfsGroup metaverse objects to the FIMService PSMA.
- We wrote fairly simple scripts to read / write the new dfsGroups to the FIM Service as normal FIM Service Group objects
- The creation was merely to create a simple security group in the FIM Service. We utilized Craig's Martin's great PowerShell modules for this.
On the next import from the standard FIM MA, the new groups would be projected to the metaverse as normal group objects and the groups imported in the normal AD MA could now join - and bum, membership was now maintained using the filters applied when creating the groups using our FIMService PowerShell MA.
Sounds interesting? Get the PowerShell MA here and the scripts here - oh, and don't forget to get the latest cersion of Craig's FIM PowerShell module (although I included the version we used in the download bundle). You may have to change a few lines in the PSMA scripts for logging and such, but beyond that they should be pretty much functional out-of-the-box.
As always, I'm interested to know if you find this useful.