MIIS Solution: SyncProdToDev part 1

So, it seems like on every project I start I always start with the same task - creating a copy of the production AD environment in a test lab. It's surprising how few customers actually have functioning test environments if they have one at all but MIIS makes it easy to duplicate the relevant parts of a working AD environment. First let us cover what we can and cannot synchronize between environments.

Fair Game
The following objects are ok to copy between the two environments:

• user objects - pretty easy, but we can't get the password here or the SID
• contact objects - easy, we do this with GALSync
• group objects - easy, MIIS will maintain the group memberships for us but we'll want to avoid System Groups or any special builtin group.
• organizationalUnit objects - easy, but we can't delete them if our source goes away (grr)
• site objects - yes, but we can't propagate renames for some reason
• subnet objects - ditto
• siteLink objects - ditto

While the first four are relatively easy, the last three require some additional attention for the following reasons:

• These objects are containers for other objects or are themselves part of parent container that must be created beforehand.
• Once these objects are created, we won't be able to rename them using csentry.DN or csentry.RDN as they are protected system objects.

This gets us the important stuff we'll need to simulate our production environment, so what is off limits?

Off Limits
The following are either not possible to synchronize due to their nature or not worth trying:

• Group Policy Objects - you might be clever enough to get the GPO objects to synch between domains, but don't forget that the object is only half; you also need the files that go with it. Plus you'd have to edit the objects and the files to sanitize the DNs.
• Delegated Permissions - you're welcome to try, but the AD MA can't see AD Access Control Lists
• Containers - you can certainly copy these objects but they are generally reserved for special areas of the domain so you're probably better off keeping these out of scope. I try to avoid anything "CN=" at the root to play it safe.
• Application objects - don't go trying to copy Exchange objects, it is certainly easier to just install Exchange in the test forest and call it good.
• Bi-directional Sync - since we're testing, we shouldn't be expecting to sync changes in our test environment back to our production environment because that would be crazy. I had to list it because someone will ask "Brad, what about bi-directional syncs?" If bi-directional synchronization of AD domains turns you on and you want to adapt this solution to accomplish that - be my guest.

Ok, so what is the challenge here?

The Challenge
So we can copy the relevant objects between forests, but the problem we are going to run into is translating the distinguished names between the forests. If we have ForestA (DC=foresta,DC=com) and ForestB (DC=forestb,DC=test) and both are single domain forests then we pretty much need to just replace all occurrences of ForestA's DN with that of ForestB's. But, what if ForestA has multiple domains, or better yet, multiple trees? That makes the problem of a simple .Replace much harder. This is where we're going to use Regular Expressions to solve this problem.

Now, unless we're collapsing multiple domains into one domain, we don't have to worry about the typical things like sAMAccountName uniqueness because it's already unique in the source. So, except for DN, we're pretty much copying like for like - pretty easy right?

We also have an issue of stepping on the same object types - so if you project everyone from ForestA as object type person and then provision them into ForestB, what happens when you need to now project from HR and join...you've got a mess.

The Messy Part
So, after you create your ADMAs to both forests and add all of the applicable object types, mappings and so on you're ready to go. But now you have complicated your test environment with stuff you don't want to bring over into production. Your server export will either contain MAs that you don't want or they will contain object types and attribute flows that you don't care about.

In order to solve the object type problem, we will certainly want to use our own object types. In the solution we will use:

• syncPerson
• syncContact
• syncGroup
• syncOrganizationalUnit
• site
• subnet
• siteLink
• siteLinkBridge
• plus all of the dependent object types I won't list here...

So that gets us around the project/join issue, but we need to address the others. Here are a few different scenarios I can think of using:

• Discrete Install of IIFP - we could use an entirely separate installation of IIFP (since we're only doing AD to AD) with just this solution and that way we wouldn't muddle the test cases, or
• Discrete Install of MIIS - same as above, but no added value here, or
• Same Install of MIIS/Same MAs - this is the one we probably want to avoid, using the same MAs we're developing to move into production to also synch our environments, or
• Same Install of MIIS/Separate MAs - this is probably the most logical, we're just going to build two completely separate MAs that only contain our synch information. The only hitch here is unless we use MVRouter, we will at least have a function in the MVExtension to do the provisioning of these objects which means you need to allow for the condition. That means you'll need to delete the two synch MAs if you're doing full server imports or not import them if you're doing each MA individually. That just leaves the extra schema attributes which you'll have to live with or go to the IIFP scenario.

Rules Extensions
Since DN is the only thing that needs to be altered and we only care about DN during Provisioning, the only extension code we need is going to be in Provisioning, so no MA extensions or advanced attribute flow (aww shucks!).

In part two we'll look at the code, schema and provide the MA exports - stay tuned!