So, if I understand correctly you want to migrate the users along with sid-history so that you can also take along a bunch of file servers with it's permissions that are already set for one of the domains in your forest A? When the divestiture occurs, you'll push the user information over.

"- Configure DNS conditional forwarding in forest A to find forest B's pocket network DCs and vice versa.
  Would I have to set up forwarding on every DNS server in forestA? They have a lot of DCs."

That'll likely be problematic.  You'll want to narrow that down more to use specific DC's vs. using any DC.  If you use conditional forwarders, the clients of that DNS host (likely itself, but not necessarily) would be able to find B, and the reverse might also be true. The key is to be sure that the dc in A at the particular site and the dc in B at the same site, can see each other. See those links on Microsoft's site that relate to creating a trust over a firewall (but I have to wonder if it's worth it to have a firewall there at all for this).


 
Your biggest risk is that you run into something like sidfiltering or some issue that prevents you from being able to create the trust on schedule and be able to migrate.  I suggest you test this scenario and see what shakes out to mitigate the risk that you'll not get it to work on D-Day.  As I understand divestitures, they won't be very undrestanding if it's delayed due to an inability to set this up and pull off the migration. Lot's of raw nerves during the MAD process. :)

Al




On 10/9/06, Harvey Kamangwitz <[EMAIL PROTECTED] > wrote:
Yes, there are several terabytes of server-related resources going with the divestiture and it would be an enormous job to rebuild all the access control from scratch. Sorry, I should have mentioned that.


On 10/9/06, Al Mulnick <[EMAIL PROTECTED]> wrote:
I don't think I see what you really want to accomplish? 

Why, if you're going to firewall the networks off anyway, do you need to migrate vs. Microsoft shuffle (create new on target, delete legacy) ?

Are other resources coming with that rely on these? Or are those being migrated as well? Is it just the workstations you're concerned about?

If they're part of the same domain, what's the point?


Al


On 10/9/06, Harvey Kamangwitz < [EMAIL PROTECTED] > wrote:
Hi all,
 
I'm consulting on a divestiture, and naturally the companies want their respective AD forests to have the minimum amount of contact necessary to migrate the security principals in the divestiture from company A to company B. I wanted to sanity check with this brain trust that we can do a one-way forest trust in this firewalled situation. (They're going to use Quest Migration Manager for AD, and though technically it doesn't REQUIRE a one-way trust, the Quest SE says it's an order of magnitude easier. A one-way outgoing trust has been approved by the various security players so it can be done.)
 
- ForestA (multiple domains) and ForestB (single domain). In the beginning, no communication between them.
 
- ForestB DCs are physically landed at various Company A locations in pocket networks that can talk back
  to Company B, so they're healthy. Though they're at Company A, they are firewalled from A until D-day.
  All forest B pocket network DCs can talk to each other as well as back home.
 
D-Day:
- Transfer PDC and RID FSMOs to one of company B's pocket network DCs. (see next step for why.)
 
- Firewall off communication to company B's network, and open up comm to company A's network.
  This will make for a temporarily unhappy company B forest, but it will be okay for the duration of the migration. More importantly,
  it'll make the PDC available on the company A network for the forest trust setup and the RID master also available
  to hand out more RIDs during the migration.
  There should now be a functional company B forest on company A's network (though it'll be complaining about missing DCs).
 
- Configure DNS conditional forwarding in forest A to find forest B's pocket network DCs and vice versa.
  Would I have to set up forwarding on every DNS server in forestA? They have a lot of DCs.
 
- Establish the forest trust from A to B.
  Would selective authentication on the trust protect the visibility of A's security principals? It's mainly designed to protect B's
  resources from A's users, isn't it?
 
- Do the migration.
 
- Remove the trust
 
- Flip the pocket network firewalls back to block network A and allow network B.
 
- Let replication settle down, then transfer FSMOs back to their original locations.
 
- misc cleanup, like removing conditional forwarding
 
 
Appreciate any fine-tuning of this scenario, thanks!
 



Reply via email to