SMART AD Migrator Architecture - Nero Blanco IT Migration Specialists

This week we will look more deeply into the Binary Tree SMART AD Migrator software’s architecture, and how to scale up or out. We introduced AD Migrator in an earlier blog called “Introducing SMART AD Migrator from Binary Tree”. If you’ve not heard of the product before it is worth reading the overview first.

Right, so what are the components of the AD Migrator suite

• SQL Server database
• Directory Synchronization tool
• AD Migrator Management Interface
• AD Migrator Web Service
• AD Migrator Agent

In a small/simple environment you could put the first four all on a single server, and deploy the agent to the workstations to be migrated via GPO/WSUS/SCCM or your tool of choice.

SMART AD Migrator Single Server

This would give a simple centralized architecture but of course has scale limitations. A bigger scale but still centralized would be to split the roles over more servers and add a load balancer for the web service.

SMART AD Migrator Centralized

This would still be a fairly simple centralized architecture but can be scaled out as needed at the web service layer.  The Directory Synchronization and AD Migrator Management Interface components can be combined together depending on who operates both of those.  I’ve drawn them separated since in some cases they could be managed by different teams, for example the Directory Synchronization tool may be managed by an Active Directory team, where as the AD Migrator UI may be needed by desktop support.

Now if we want to decentralize then there are two main options.  Option 1 is to distribute the web service component, and option 2 is to actually have totally separate migration software.  Now option 1 is simple to do as shown below:

SMART AD Migrator Distributed

The Agent URL can be a single namespace resolved with something like a Cisco Global Site Selector (GSS) or F5 Global Traffic Manager (GTM).  Alternatively, it could just be an agent deployed with different regional URLs depending on the region via your distribution method of choice.

Option 2 really is a multiple of the two centralized architectures we described above.  You can duplicate that as needed, as long as you ensure that there is a total separation between the objects synced/managed by each instance.

Binary Tree are working on guidance for how best to size the SMART AD Migrator suite, so that you can deploy the right architecture from the outset and be confident that it will last for your entire migration without breaking a sweat (bot you and the architecture that is)