(2006-12-01) Disentanglements And Migration Scenarios
Posted by Jorge on 2006-12-01
A major company is disentangling a part of its business and that part is continuing on its own. It will not be integrated into another company.
Last week I was asked to review and advise several migration scenarios setup by a company’s representative.
Current setup/requirements:
- W2K3 based AD, upgraded from W2K
- Empty Forest Root Domain and 1x Child Domain
- All resources and objects are in the child domain
- Business part to be disentangled is only in the child domain. It has locations where it exists by its own and it has locations shared with other business parts
- As always: time is an issue! 😉
- Business continuity is very important
- It was not clear if the businesses should be connected or not again in the future. Lets assume it may be needed in the future
Possible migration scenarios I had to review:
- Clone the Empty Forest Root Domain and the child domain, where only those resource are cloned or separated that belong to that business part. Network will be disconnected.
- Create a NEW AD forest/domain and migrate all the objects and resources from that business part into the new AD forest/domain
- Clone the child domain and reposition it on a separate network and rename it to be the new forest root domain
- Clone the Empty Forest Root Domain and the child domain, rename both to another name, connects networks and and migrate (?) resources from source to target
As you can imagine the first (1), the third (3) and fourth (4) scenario made me think if these were really migration scenarios to be considered for a company that size. Besides that, should they be considered at all?
Well, whatever…I’m going to try to explain ALL the scenarios and you will see what I think of all.
Ad.1
In this scenario an AD forest/domain (at least its contents) is cloned and resources are also cloned or separated. Resources are cloned if they are shared by both parties or are left behind or are moved into the cloned part, depending on who owns/uses it.
It is a "big-bang" scenario, because suddendy the AD forest is broken into two exactly the same parts. The forest and domain names are the same and the domain SIDs are the same.
With this scenario I only see disadvantages. Examples are:
- On both sides cleaning must be done and AD roles must be repositioned/established
- Both environments can NEVER be reconnected again to each other
- Both companies may experience serious security issues as both ADs have the same "ID"
IMHO, this is not an option!
Ad.2
In this scenario the sold business part designs, creates and deploys its own AD forest/domain. After that a migration plan is created, tested and executed to migrate ALL related objects and resources from the source AD to the new AD.
Activities include (very very very high-level):
- Inventory current environment and decide what needs to be migrated or not
- Decide if migration can be done with ADMTv3 and other MS tooling or if third-party tooling should be bought, licensed and used
- Build, deploy and configure new AD forest
- Connecting both ADs through name resolution and trusts
- Migrate groups, user accounts (service accounts) with passwords and group memberships (with sidhistory)
- Migrate clients from the source domain to the target domain, translate security on the client, and translate profiles (at this moment users start logging on with their new AD account on the migrated clients that have been migrated previously to the w2k3 domain)
- Migrate mailboxes if needed
- Migrate servers to the new domain or migrate data to new servers
- Translate security (Re-ACL) of the data/resources/applications from source security principals to target security principals (replace the security descriptors from the old domain with the security descriptors from the new domain ) (sID-based and name based)
- Cleanup temporary configurations
- Cleanup sidhistory (recommended!). sIDHistory is used to access resources while those resources still have security descriptors from the old domain. As soon as all data (file, folders, mailboxes, etc.) have been re-ACL-ed sIDHistory can be cleaned. Sidhistory should only be used temporary for migration purposes
- Remove trusts
- Cleanup what is not needed in the source AD that was migrated
Advantages:
- Best known, supported and safest approach/scenario
- Phased approach
- Fallback is possible
IMHO, this is THE option to choose from!
Ad.3
In this scenario only the child AD forest/domain (at least its contents) is cloned. Resources remain in the source environment until the cloned child domain has been renamed AND repositioned as the new forest root domain.
The idea behind this scenario was to create a new AD forest (cloned from the previous and renamed) that has exactly the same domain SID to prevent re-ACL-ing resources/data/applications. Although that may be true for sID- based ACEs but you would still need to re-ACL name based resources (e.g. SQL –> <DOMAIN><USER or GROUP>)
Although renamed, as the domain is cloned you would still may have serious security issues as mentioned in scenario 1. However because it has been renamed I assume it would be possible to connect both networks. I wonder if it would be possible to create a trust? I guess not! You can read more about this in the next scenario.
Besides this all, there is one thing here that is technically IMPOSSIBLE at this moment. Although you can rename ALL the domains in a forest you can NOT transfer the forest root domain role to another domain in the forest. Other non-forest root domains can be repositioned. A forest cannot exist or function correctly without a forest root domain
IMHO, this is not an option! 😉
Ad.4
This scenario is similar with scenario with the difference that both the forest root domain and the child are cloned and renamed. This scenario was born instantly are I explained what I described in scenario 3.
So the questions here are:
- Is a trust possible between cloned domains where the clone has been renamed?
- –> NO!
- Is access possible from IDs in the cloned domains without re-ACL?
- Yes, if it is sID based
- No, if it name based
- What is the impact of having two exact the same forest/domains on the network while the clone has been renamed?
- Security issues (same domain SID)
- Probably too complicated
- Probably too error prone
- Too many unknowns
- Probably not even supported by MS
IMHO, this is not an option! 😉
Summarized:
So lets compare scenario 2 and 4….
- OK, users, passwords, groups and memberships are available in both ADs, How are you going to keep up with new people that need access to resources and/or new objects. How to keep stuff in sync? As soon as the migration starts the company does not freeze until the migration is finished.
- sID based re-ACL is not needed, however name based ACLs STILL need to be re-ACL-ed
- Clients and servers STILL need to be migrated
As you can see, with scenario 4 you might save time during a certain step, but it will take more time and probably be more complex in some other way.
Stick to proven scenarios that everyone uses, like in-place upgrades or migrations to other AD forests/domains. Do not take unnecessary known risks and unknown risks just to save a few dollars/euros and time. Those kinds of measure/solution will probably hunt you down at a later moment.
Ye
s, it is true upgrades and migration also have an impact on the environment. Remember that it has been done many times by all kinds of people.
So the correct option here is option 2: "Create a NEW AD forest/domain and migrate all the objects and resources from that business part into the new AD forest/domain". This scenario has less risks and does not impact business continuity like the other scenarios probably would.
BUT…..what do YOU think?
Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————
Jorge's Quest For Knowledge! 
lordoftheping said
I would do the same.
One question : shouldn’ it be the time to clean up ?
If it was a part of another thing, it may contains bad things (like custom AD attributes from different softwares like rte fax for exchange).
Since they go for another life, why not start a new AD ?
Keeping everything seems much easier, but it’s now or never!!
I like the way you challenge solutions 🙂
LikeLike
tomek said
I was reading few discussions on this topic and in most cases conclusion was the same – if You want to share AD forest go with creating new one and resources migration.
First approach, with just splitting environment IMO is more error prone, harder to perform and amount of work connected with re-ACLing etc is almost the same (You have to get rid of entries connected with users from other part). This also introduces some security risk (remember about kbrtgt accounts).
Starting new forest let’s You start everything from the scratch, sometimes let’s You correct mistakes from previous environment so You are not born with original sin.
On the other hand – I’m the guy who is always building machines from the scratch instead of upgrading and who is cleaning AD from upgraded DCs after domain upgrade :).
Anyway – good post.
LikeLike
carlos said
I agree with your option change, the cloning part is the easy part. The difficult part is determining what other services rely on that part of the business as LOTP said, what are the custom Schema Extensions that they have, what impact does it have on something like Exchange.
Do they have something like MIIS running, how would it affect MIIS and other services (the list could just go on and on).
The nice thing about the clone forest is that you can do some “testing” there. Remove things and see how it behaves before you actually go and remove it from the live production forest.
I would use the P2V tools that we have to take some of the machines (DC, Exchange servers) and virtualizes them. That way you have a backup and you can “test ” to your hearts content.
C
LikeLike
PlaceHolder_After_Migration said
About the cloning scenario: ask Microsoft if they will support a cloned and cleaned forest. Hint: I know the answer. That alone should be sufficient argument not ever to clone a forest.
LikeLike
Jorge said
I got a hint from someone. Thank you “someone”! 😉
That hint was: “is a cloned forest supported by Microsoft”
Yes, although I did not mention it here I did tell the customer to contact Microsoft about cloning a forest and if it was supported by Microsoft. I do not know the official answer, but I assume it is: “NOT SUPPORTED”
cheers,
Jorge
LikeLike