I'm looking for guidance and/or warnings about migrating an existing Active Roles (managing 3 forests) to a greenfield in AWS but not AWS Managed AD.

I see plentiful documentation on moving to AWS Managed AD, but I'm not finding clear guidance on moving to AWS for the ARS Servers, SQL, Connectors, Domain Controllers, WITHOUT that "AWS Managed" portion.

My client plans to keep a full footprint in both Azure and AWS.

Anyone care to share some war stories or tales of success!

Frank

Parents
  • Hi, Frank.

    It happens that I just finished assisting a customer going through this precise type of scenario: migrating away from an old and established instance of the product to a new one in a new forest. Like with your customer, they had some issues with the old one that they wanted to leave behind, so opted to migrate to a new instance & new forest.

    There was a lot involved in that project, including updating and migrating dozens of scripts that referenced the legacy environment name & OU structure, but one of the bigger pieces was probably the migrating of dynamic groups. All of the queries for the dynamic groups (and there were many) were based on an OU structure that didn't exist in the new environment, so the queries all had to be updated to reflect attributes (virtual or otherwise) instead of OU. To this end I created some fairly intensive scripts to translate and reconstruct the LDAP queries for all of the dynamic groups.

    This was a fairly labour-intensive project; it's possible, but the customer needs to understand the scale of what such a project entails.

    If your new environment uses the same OU hierarchy, obviously things will be considerably easier. The Configuration Transfer Wizard should help, but bear in mind that it does not transfer Workflow (or at least it did not the last time I looked at it, which was a while ago). If you use that, also be careful to import in the correct order. E.g., you need to import virtual attribute definitions before Policy or Access Templates, since the Policy/Templates can reference the virtual attributes.

    Best of luck!

Reply
  • Hi, Frank.

    It happens that I just finished assisting a customer going through this precise type of scenario: migrating away from an old and established instance of the product to a new one in a new forest. Like with your customer, they had some issues with the old one that they wanted to leave behind, so opted to migrate to a new instance & new forest.

    There was a lot involved in that project, including updating and migrating dozens of scripts that referenced the legacy environment name & OU structure, but one of the bigger pieces was probably the migrating of dynamic groups. All of the queries for the dynamic groups (and there were many) were based on an OU structure that didn't exist in the new environment, so the queries all had to be updated to reflect attributes (virtual or otherwise) instead of OU. To this end I created some fairly intensive scripts to translate and reconstruct the LDAP queries for all of the dynamic groups.

    This was a fairly labour-intensive project; it's possible, but the customer needs to understand the scale of what such a project entails.

    If your new environment uses the same OU hierarchy, obviously things will be considerably easier. The Configuration Transfer Wizard should help, but bear in mind that it does not transfer Workflow (or at least it did not the last time I looked at it, which was a while ago). If you use that, also be careful to import in the correct order. E.g., you need to import virtual attribute definitions before Policy or Access Templates, since the Policy/Templates can reference the virtual attributes.

    Best of luck!

Children
No Data