Re: AD Forest Split procedure

SQL can be an application where you would need to change the domain name of the groups

about the you will never know.... what I'm trying to say is that a current decision may close the door forever in the future or have a severe impact on future operations and you will never know what those will be

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"Tage S. Rasmussen" <TageSRasmussen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:3C957691-7412-4FCC-B966-27090EFB9759@xxxxxxxxxxxxxxxx
Thanks for your comments.

I will document all the Pro's and Cons of the 2 procedures and make sure
that the consequences of choosing the split procedure is well understood, so
a decision can be made on a solid foundation. Unfortunately when
organizations that need to split cannot agree on who should keep the existing
forest and in addition have time and resource constraints, then you need to
look at alternative solutions.

It is true that if the SID does not change reacling on most applications
will not be neccesary. However, some applications also rely on the naming
DOMAIN\OBJECTS when granting access and this will have to be changed in the
applications if the domain name is changed. Also any hardcoded references to
the domain name in scripts among others must be changed. Sharepoint Portal
Server is an example of this.

Ad 1+2) It is true that you can never predict the future, but this is the
case for everything. From my point of view it is just important to have the
right information to make a decision and that the consequences of this
decision is known up front. Unfortunately, you cannot have the cake and eat
it too.

Ad 3) I was thinking more of security threats due to the fact that the 2
organizations share the same root Domain SID.

Ad 8) Well, it could be stated as a prerequisite to use the procedure. This
way you could do the split quickly. Lateron when the client has sufficent
time and ressources a real migration could be done and thereby eliminate all
the interim coexistence issue.


"Jorge de Almeida Pinto [MVP - DS]" wrote:

1 migration is in my opinion preferred
2 check if microsoft supports it. A domain rename DOES NOT require Re-ACLing
because the domain SID does not change

Qs:
1 you will never know. Today people have a thought and tomorrow it may
differ. The day before you did not know that person thinks differently
because of other insights or whatever. If you choose that path, the door is
closed. No way back without tons of work
2 you will never know
3 domain sids do not change
4 The clone is probably not supported, maybe both. Check with MS
5 cloning: metadata cleanup, maybe reallocating services to other machines,
migration:
http://blogs.dirteam.com/blogs/jorge/archive/2006/12/27/Migrating-stuff-with-ADMTv3.aspx
6 do not know
7 do not know
8 you will never know

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* How to ask a question --> http://support.microsoft.com/?id=555375
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------
"Tage S. Rasmussen" <TageSRasmussen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:446C89DA-8D9C-4A7C-8502-DED38A4E6615@xxxxxxxxxxxxxxxx
> Hi Jorge
>
> Thanks for the link. I have read your scenarioes and the comments.
> However,
> the situation that I face is not quite as similar.
>
> I have the 2 following procedures to weigh against each other.
>
> 1. Traditional Interforest migration where a new pristine AD forest is
> etablished for one of the companies and their resources migrated to > this
> forest. The original forest will be owned by the other company.
>
> 2. AD split/cloning procedure as described in my thread.
> It differs from your scenarioes by not requiring domain renaming which
> will
> eliminate any reacl'ing of resources and thereby saving a substantial
> amount
> of resources and time. Also the 2 companies are located in different
> countries and are communicating via WAN links secured by FW's.
> Consequently,
> it will be easy to isolate traffic and DC's.
>
> As I mentioned I would never recommend procedure 2 from a technical
> perspective, but even though the procedure is not recommended nor
> supported
> the question is whether it in certain scenarios still would be an > option
> especially if time contraints and political/economical issues prevent > the
> supported Interforest migration.
>
> The procedure for sure is technically viable but whether the risks and
> disadvantages outweigh the benefits is another question.
>
> I do not agree that there are no benefits to procedure 2. Especially > when
> you do not have to reacl there are huge time and resource savings > compared
> to
> a traditional interforest migration especially for larger organizations
> with
> many users, servers, PC's and applications/services.
>
> From my perspective the choice very much depends on the following 8
> questions :
>
> 1. Will the 2 companies need to access ressources in the cloned forest
> after
> the split ?
>
> 2. Are there any other companies that simultaneously need access to > both
> forests through trust relationsships ?
>
> 3. Are there any other security issues to be concerned about due to the
> split ?
>
> 4. Will each company have a supported forest after the split ?
>
> 5. How many ressources will be needed for Metadata cleanup, > data/service
> replication and reacl'ing compared to a traditional interforest > migration
> ?
>
> 6. How long time will the split procedure take compared to a > traditional
> interforest migration ?
>
> 7. What are the risks for the procedure to fail ?
>
> 8. Will at least one of the companies lateron perform a real > interforest
> migration ?
>
>
> Ad 1+2) If yes to any of these then procedure 2 is not an option.
>
> Ad 3) If traffice between the the 2 organizations are isolated then I
> cannot
> see any severe security risks due to the split.
>
> Ad 4) I am awaiting a response from Microsoft here.
> Even though the procedure itself is not supported the question is > whether
> the 2 organizations will have an unsupported environment afterwards. I > do
> not
> believe so as long as the problems are not related to coexistence > issued
> among the 2 organizations.
>
> Ad 5) This is a bit difficult to answer as this depends on how easy the
> metadata cleanup will be. As mentioned the resources for the 2 > companies
> are
> very well segmented already as they each have their own domain. > However,
> the
> unknown factor is the shared Exchange 2003 environment that also need > to
> be
> split and any other shared services.
>
> Ad 6) This primarilly depends on the complexity of the metadata cleanup
> and
> I was hoping for some feedback from people that have done this in > practice
> especially in an environmment with Exchange 2003.
> For sure the split procedure will also have to be tested thouroughly in > a
> test environment which also takes time.
>
> Ad 7) Again some feedbcak for people that have done this in practice > would
> be beneficial.
> I have done it earlier for small environments without Exchange and for
> Dev/Test purposes only, but in a production environment the risks are > of
> course higher. A critical failure would result in a total forest > restore.
>
>
> Ad 8) If this is the case the disadvantages from issues 1-4 would be
> eliminated afterwards.
>
> /Tage
>
> "Jorge de Almeida Pinto [MVP - DS]" wrote:
>
>> see:
>> http://blogs.dirteam.com/blogs/jorge/archive/2006/12/01/Disentaglements-and-Migration-Scenarios.aspx
>>
>> that customer wanted to do the same. I talked them out of it. They
>> migrated
>> and are quite happy now with that choice, while time was also an >> issue,
>> as
>> always
>>
>> -- >>
>> Cheers,
>> (HOPEFULLY THIS INFORMATION HELPS YOU!)
>>
>> # Jorge de Almeida Pinto # MVP Windows Server - Directory Services
>>
>> BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
>> BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
>> ------------------------------------------------------------------------------------------
>> * How to ask a question --> http://support.microsoft.com/?id=555375
>> ------------------------------------------------------------------------------------------
>> * This posting is provided "AS IS" with no warranties and confers no
>> rights!
>> * Always test before implementing!
>> ------------------------------------------------------------------------------------------
>> #################################################
>> #################################################
>> ------------------------------------------------------------------------------------------
>> "Tage S. Rasmussen" <TageSRasmussen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote >> in
>> message news:0311D4CB-BBC0-4E39-A980-54116EDF0686@xxxxxxxxxxxxxxxx
>> > Hi Jorge
>> >
>> > Thanls for your reply.
>> >
>> > I am fully aware of the risks and issues with the procedure and will
>> > also
>> > include these in my preanalysis report so the decision makers are >> > fully
>> > aware
>> > of the consequences before they decide to move forward.
>> >
>> > From a technical perspective, I would never recommend doing this but >> > in
>> > this
>> > case political, economical and resource factors have higher >> > priority.
>> >
>> > However, when all this been said, I would very much like to hear if
>> > someone
>> > has actually done this with success in production.
>> >
>> > "Jorge de Almeida Pinto [MVP - DS]" wrote:
>> >
>> >> solutions like these can be very painful and you may end up >> >> shooting
>> >> yourself in your own foot by following the quick and dirty way
>> >>
>> >> and be aware that for whatever reason you will never be able to
>> >> connect
>> >> those forest to each suing trusts ot whatever. You may say: not
>> >> needed,
>> >> so
>> >> not an issue.Yeah, until someone at some moment suddendly changes >> >> his
>> >> mind
>> >>
>> >> be careful
>> >>
>> >> -- >> >>
>> >> Cheers,
>> >> (HOPEFULLY THIS INFORMATION HELPS YOU!)
>> >>
>> >> # Jorge de Almeida Pinto # MVP Windows Server - Directory Services
>> >>
>> >> BLOG (WEB-BASED)--> >> >> http://blogs.dirteam.com/blogs/jorge/default.aspx
>> >> BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
>> >> ------------------------------------------------------------------------------------------
>> >> * How to ask a question --> http://support.microsoft.com/?id=555375
>> >> ------------------------------------------------------------------------------------------
>> >> * This posting is provided "AS IS" with no warranties and confers >> >> no
>> >> rights!
>> >> * Always test before implementing!
>> >> ------------------------------------------------------------------------------------------
>> >> #################################################
>> >> #################################################
>> >> ------------------------------------------------------------------------------------------
>> >> "Tage S. Rasmussen" <TageSRasmussen@xxxxxxxxxxxxxxxxxxxxxxxxx> >> >> wrote
>> >> in
>> >> message news:8E91CECC-1510-463F-9CA5-A2265CD14A5A@xxxxxxxxxxxxxxxx
>> >> >I am currently investigating a procedure to quickly split an >> >> >existing
>> >> >multi
>> >> > tree 2003 AD forest with Exchange 2003 into 2 separate AD >> >> > forests.
>> >> >
>> >> > This needs to be done due to organizational changes where the
>> >> > company
>> >> > will
>> >> > be spilt into 2 separate entities (Org A and Org B).
>> >> >
>> >> > The 2 organizations will not have a need to access ressources in >> >> > the
>> >> > other
>> >> > organizations forest after the split.
>> >> >
>> >> > It is a fairly large organization (10000+ users) and due to
>> >> > political
>> >> > issues
>> >> > and time contraints it is currently not an option to pursue the
>> >> > recommended
>> >> > approach which is to create a new AD Forest and migrate >> >> > ressources
>> >> > and
>> >> > data
>> >> > to this using interforest migration tools.
>> >> >
>> >> > The current AD environment consists of 3 trees with a single >> >> > domain
>> >> > each.
>> >> > Every domain has multiple DC's.
>> >> >
>> >> > Empty root domain (X.LocalRoot)
>> >> > Tree for Org. A (A.LocalA)
>> >> > Tree for Org. B (B.LocalB)
>> >> >
>> >> > Luckily the ressources are segmented so ressources from Org A are
>> >> > located
>> >> > in
>> >> > domain A.LocalA whereas resources from Org B are located in >> >> > domain
>> >> > B.LocalB.
>> >> > Both organizations also have their own Exchange 2003 servers.
>> >> >
>> >> > We consider to split the existing AD environment by isolating >> >> > DC's
>> >> > from
>> >> > each
>> >> > other so each organiation will have one DC from the root domain, >> >> > one
>> >> > DC
>> >> > from
>> >> > the other tree and of course DC's from their own tree.
>> >> >
>> >> > When the DC's have been isolated we can perform a FSMO seizure,
>> >> > Metadata
>> >> > cleanup in both forests and DNS zone cleanup among others, just >> >> > as
>> >> > you
>> >> > would
>> >> > do to create a test/dev environment based on an existing forest.
>> >> > By having a DC from the other orgs tree, it will be easier to
>> >> > perform
>> >> > the
>> >> > metadata cleanup.
>> >> >
>> >> > After this procedure We will end up with 2 disconnected AD >> >> > forests
>> >> > with
>> >> > Exchange 2003 cloned from the initial forest with a empty root
>> >> > domain
>> >> > and
>> >> > a
>> >> > single tree each
>> >> >
>> >> > After Split procedure :

.

Relevant Pages

  • Re: AD Forest Split procedure
    ... migration is in my opinion preferred ... Traditional Interforest migration where a new pristine AD forest is ... eliminate any reacl'ing of resources and thereby saving a substantial amount ... the 2 organizations will have an unsupported environment afterwards. ...
    (microsoft.public.windows.server.active_directory)
  • Domain Migration (Preserve Resource Access)
    ... We are in the design phase of building a W2K8 forest which we will ... Due to the large number of resources we would prefer not to ... using SID history to preserve access. ... migration and it can't be removed because security was not translated on ...
    (microsoft.public.windows.server.active_directory)
  • Re: Partial AD Migration from Windows 2000 to Windows 2008
    ... to point out that is missed by many folks during the computer migration is ... existing forest), have access to resources in the old domain? ... completely separated from the old one and its resources; ... accounts, and start again, because the original accounts will remain. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Partial AD Migration from Windows 2000 to Windows 2008
    ... (and I assume a new domain in a new forest that has nothing to do with the ... once the migration is complete the new domain will be totally and ... completely separated from the old one and its resources; ... accounts, and start again, because the original accounts will remain. ...
    (microsoft.public.windows.server.active_directory)
  • Re: "Columbus Theory" was Monarchs and Monoculture in southern Michigan
    ... I don't have a firm decision on the "Columbus Theory". ... Clearing land for farms in the 18th century wiped out a lot of unspoiled forests, and the timber boom of the late 1800's and early 1900's pretty much chewed up all the old growth forest. ... By 1975 they found that the Monarch was commonly breeding along the north shore of Lake Huron from Sudbury to Sault Ste. Marie and in Thunder Bay and that in 1977 Monarchs were considerably more common at Sault Ste. Marie than they were at Toronto. ... United States would have noted a "migration" and even if they saw a group ...
    (sci.bio.entomology.lepidoptera)
Loading