Introducing SMART AD Migrator from Binary Tree

by Twan van Beers, 19th June, 2015

We’ve just had two days of training using the revamped SMART AD Migrator software from Binary Tree. They’ve had an AD migration tool for some time, but it used to have various issues. These resulted in a total overhaul of the product, and this current release looks to be in a good stable state.

The AD Migrator Components

The SMART AD Migrator software consists of the following components

Directory Synchronization

Keeping the source and target objects in sync is critical to the success of an AD migration and the Directory Synchronization tool does a great job. It was already in use at Binary Tree for mail migrations, including Domino to Exchange/O365 and Exchange to Exchange/O365, so it is a mature and solid product.

REST based web service

The AD Migrator REST based web service is the key to the security and scalability of the product. Agents poll the web service and report back status to the web service, meaning all communication is initiated by the workstation and all on port 80 or preferable port 443. The web service can be installed on multiple servers, centralised or distributed and can be easily load balanced.

When distributing the web service then the agents either need to be explicitly told which URL to connect back to or a geo based DNS resolution needs to be added to the design. The URL can be specified at install time via an mst, custom wrapped MSI, command line or manually when running the agent exe.

When there is only one URL then there is the option of using autodiscover via an SRV record (based on the machine’s domain membership) The SRV is called _btadm._https.<domain> or _btadm._http.<domain> with the agent favouring https.

Management Interface

The management interface is a client installed on a server to manage the overall migration. It has rich features for grouping and filtering users/groups/devices, and displays the overall progress of the migration project

Lightweight Agent for Servers and Workstations

The agent is installed on servers and workstations to be migrated, or that need to be accessed once a user has been migrated. The agent takes care of registration, discover, reACL, Cutover and Cleanup by default but is highly customizable and can easily be made to run any task on the workstation during any of those high level phases, or additional phases as you need.

There is a polling interval defaulting to 4 hours, which can be changed up or down as needed. Just be aware that the agents poll and so a change in the interval require one additional poll for the agent to pick up the change.

The agent runs as local system, so no special credentials are needed on the workstation. The agent will be able to do whatever it needs without any UAC or Execution Policy issues. One area of trouble is Anti Virus and other protectionware, which often see the AD Migrator actions as a threat and block the activity in part. So during pilots and testing be sure to determine which exceptions you need in place, either on the AD Migrator side or on the protectionware side.

SQL Server Database

At the heart of any good system is a database, and AD Migrator is so good it has two. One is the logging database, this can grow quickly if we’re on high/debug logging and we have a large number of users/groups/devices. It can be cleaned out as regularly as you like depending on auditing requirements of the migration project. The other is the main database containing all of the information from the source and target directories as well as progress on the migration.

The good, the bad and the ugly

The big plus points of the product as I’ve seen it so far include

Security

The product was built with security in mind. All communication is from workstation to server and all over web ports and protocols means no firewall exceptions needed and no issues with IDS/IPS picking up the traffic. The agent uses Local System for almost all of its work and being given credentials over the REST interface when a specific jobs needs it, such as cutover domain join. The agent and the server exchange individual keys which are then used in future communication for rudimentary authentication. Additional authentication can be added using standard IIS methods, including Kerberos and client certificates.

Scalability

The web service is able to be scaled out, and the database can be scaled up (or out by moving the log database onto a different machine than the main database). The product is useful in small migrations with only hundreds of devices/users/groups through to large and complex migrations with many hundreds of thousands of devices/users/groups.

Ease of use

The software is pretty easy to use and has a modern interface.

Extensibility

This to me is where the product really excels, it is easy to amend the jobs and add your own to make the agent do whatever you need it to. Also the SQL database can be polled or triggered to do any additional jobs server side, for things like application credential cutover after a user/workstation have been cutover.

Now the bad and the ugly. I need to do both together since there really isn’t that much to complain about.

The reACL pulls down a file containing all of the source sids mapped to target sids and while transmitted securely is not stored securely on the machine during the reACL. We talked about perhaps at least encrypting that file at rest, or doing selective pulls of the data in a future release of the product.

Reporting is not yet included in the product, so while the data is all in SQL to create pretty reports you’d have to use something like SQL Reporting Services and create reports yourself.

Bugs… All software has bugs of course, don’t let anyone try to fool you otherwise. The AD migrator tool does have some issues. Some are mitigated using best practice, e.g. always have one profile on a domain to domain basis, don’t create forest to forest profiles. Some may need multiple instances of the AD migrator tool, e.g. multiple simultaneous divestitures require an instance per divestiture to make the process efficient.

Some of the new features coming up in the next couple of versions:

Sync from source to a single target OU without creating the OU structure beneath that target OU
Pre-staging of workstation records (and hopefully with syncing of group memberships, etc too)
Migration straight to Azure AD
Keeping track of objects even if they’re moved during the Sync
OU remapping for complex source to target OU manipulation
Option to not recreate target object if it is manually deleted
Propagation of source object deletions

Overall though this is a great product and Binary Tree are working hard to improve it, and are always receptive to feedback. You can find out more on the Binary Tree website

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.