Supported Operating Systems in an AD Migration

When it comes to migrating an Active Directory (AD) and the elements within it, the topic of Microsoft Operating Systems (OS) is a strategic element to develop.  In most scenarios, an Active Directory migration will have an IT Security stakeholder that will require all migration activity be compliant with their minimum IT Security requirements.  Those minimum requirements typically will not allow Microsoft operating systems that are no longer supported by Microsoft.  That is even with extended support Microsoft will no longer provide patches that would address new and evolving security vulnerabilities for the dated operating system.

Quest Software complements that best practice strategy in our AD migration products by including in our support labs all the operating systems that are presently supported by Microsoft.  When an OS is no longer supported by Microsoft, Quest will also drop the OS from the list of “supported” operating systems.  Whatever version of AD migration product was current at the time the OS was dropped would be the last archived version that had extensive compatibility testing with those operating systems.  And in all but extreme cases, future versions of the AD migration product continue to function with the no-longer-supported operating system.  Following IT Security best practices, as a guiding principle Quest Software will not provision operating systems in their support labs that Microsoft no longer supports.

What this means is if there is a migration problem with an old operating system that Microsoft no longer supports, the Quest Software support desk will provide “best effort” support with all the historical knowledge base content and lessons learned; but will not be able to prove out in a Quest support lab whatever condition is causing issues.

As the AD migration product is evaluated, consider there are four Windows Server operating system topics about supportability:

  1. On what Microsoft Windows OS can the AD migration product (or its agent) install? Current installation requirements are found in the product documentation.  When Microsoft releases a new server OS, it sometimes takes a few months for Quest to perform all the necessary testing with that new OS.
  2. Which Microsoft Windows OS can the AD migration product migrate from a Source environment to a Target environment? This typically is all the present-day operating systems that Microsoft supports – even with extended support.  Once Microsoft drops support for any OS, Quest software will also drop it from our support labs.
  3. What OS’s can be used for AD Domain Controllers? This is the same strategy as #2 above.  But is listed here to further qualify the next point.
  4. What Functional Level of AD will the AD migration product work? Even if all of the Domain Controllers in an AD are running a supported Microsoft operating system, the functional level of AD may be something that predates those operating systems.  Microsoft maintains supportability of the AD schemas even beyond the OS of the domain controllers.  Quest also follows this strategy.

This information was provided to help develop a strategy for your AD migration.  So what are some options for considering no-longer-supported Microsoft operating systems?

AD schema versions back to 2003 functional level are still encountered and successfully processed now and then.  (And will be Quest-supported until Windows Server 2016 is end of life extended support.)  If there is a 2003 Forest Functional Level with only 2003 Domain Controllers, consider standing up a new 2016 Domain Controller and use that DC for the Quest migration solution to interface.

If you don’t have the time or budget to consider upgrading unsupported operating systems on application servers to comply with your IT Security’s requirements, consider standing up a new forest that is intended for those older operating systems.  At least that way you can segment the risks associated with those older machines.  Older GPOs, older vulnerabilities, and extra protections to include AD trust strategies can be employed to put a boundary around those risky operating systems.  And it would organize that scope in a way that doesn’t get lost in the supported production domain.

If your AD migration program causes you to have the budget and motivation to perform necessary server OS upgrades, consider that it would almost never be a good idea to include an OS upgrade and AD migration action in a single event.  Upgrade the OS before or after the AD migration – not during the AD migration.

And if there is unpalatable risk associated with the upgrade of your AD schema, consider use of Quest Software’s Recovery Manager for AD that can backup and restore the entire AD as it exists – before attempting the functional level upgrade.