Nero Blanco > Blog > SMART AD Migrator Architecture

SMART AD Migrator Architecture

by Twan van Beers, 10th July, 2015

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)

Twan van Beers

Twan is a senior consultant with over 30 years of experience. He has a wide range of skills including Messaging, Active Directory, SQL, Networking and Firewalls. Twan loves to write scripts and get deep and dirty into debugging code, in order to understand and resolve the most complex of problems.