move DC/GC from production to test environment

[Malichi]

Greetings.

I am trying to take a current DC which is also a GC and move it into an
isolated test environment. So far here are the steps I think I need to
take:

Unplug DC from domain
Boot into system restore mode
Seize FSMO roles
Move to isolated test environment

For the record I don't need to worry about event log errors with
replication, etc. I just need a copy of the AD (OUs, security info) in
order to test parsing software. I do need to add computers accounts
and user accounts to the new test environment.



Questions:

I cannot currently logon with cached credentials with network unplugged
(have not yet seized FSMO roles)

How will I log onto the DC in the test environment if I cannot logon
now using cached credentials with the network unplugged?

Would I be better off building a new DC in a test environment and
export OU info using LDIF utility?

Can someone help me with some pointers on the best way to go about
meeting these objectives?
Thank you

 

[Herb Martin]

Greetings.

I am trying to take a current DC which is also a GC and move it into an
isolated test environment. So far here are the steps I think I need to
take:

Unplug DC from domain
Boot into system restore mode
Seize FSMO roles

You are basicly deciding to never return this DC to the
production network. Be aware of that.

(Never mixed seized Role Holders with former Role Holders.)

Move to isolated test environment

For the record I don't need to worry about event log errors with
replication, etc. I just need a copy of the AD (OUs, security info) in
order to test parsing software. I do need to add computers accounts
and user accounts to the new test environment.

Why? They are all in AD.

Of course, if you have new (test) users or (test) computers you will
and may add those.

Questions:

I cannot currently logon with cached credentials with network unplugged
(have not yet seized FSMO roles)

It might be as simple as DNS...

You should be able to logon with cached credentials when unplugged since
that is what cached credentials do. My guess is you don't mean the station
where you are trying to logon is itself unplugged.

How will I log onto the DC in the test environment if I cannot logon
now using cached credentials with the network unplugged?

Logon where?

Check your DNS. Client is probably not able to find the "only DC"
now.

Would I be better off building a new DC in a test environment and
export OU info using LDIF utility?

Better off? That's a judgement call, but it would be very easy to
just build a new domain.

Can someone help me with some pointers on the best way to go about
meeting these objectives?

What objectives? You gave us your plan, not the objectives.

The closest you came to 'objectives' was a mention in passing about
testing some software parsing software.

Truth is, were it PURE "parsing" you could have do it online.

One must assume it parses and then makes some kind of change (or

 

[Malichi]

You are basicly deciding to never return this DC to the
production network. Be aware of that.

Yes, that is not a problem. Server is never to be returned to
production.

(Never mixed seized Role Holders with former Role Holders.)


Why? They are all in AD.

Of course, if you have new (test) users or (test) computers you will
and may add those.

Yes, will be adding new servers and users to this test environment.

It might be as simple as DNS...

You should be able to logon with cached credentials when unplugged since
that is what cached credentials do. My guess is you don't mean the station
where you are trying to logon is itself unplugged.

I am trying to logon to the DC itself with cached credentials. Have
not tried client login (doh!)

Logon where? To the DC

Check your DNS. Client is probably not able to find the "only DC"
now.

Thanks, have not checked that.

Better off? That's a judgement call, but it would be very easy to
just build a new domain.


What objectives? You gave us your plan, not the objectives.

The closest you came to 'objectives' was a mention in passing about
testing some software parsing software.

Objective is to recreated Ad structure in sterile environment to test a
specific software product (done by another consultant)

Truth is, were it PURE "parsing" you could have do it online.

What they are parsing for is irrelevant as far as my work goes to get a
DC and a few servers into testing.

One must assume it parses and then makes some kind of change (or
you are exceptionally cautious. <grin>)

Oh Yeah! Fortunately, that is not my bone to chew on.

Thanks for the help.

Thank you

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

 

[Herb Martin]

Yes, that is not a problem. Server is never to be returned to
production.

As a DC that is. You may demote it, even bring it online VERY
briefly for that demotion if you wish to avoid the NTDSUtil cleanup,
but do NOT leave it online if you follow that procedure unless it
is demoted to non-DC.

Also, if you intend to never return it at all, or your are planning a LONG
separation you may wish to do the NTDSUtil cleanup now so that the
other DCs will not be throwing log errors etc. (See below...)

Yes, will be adding new servers and users to this test environment.

Just do it.

I am trying to logon to the DC itself with cached credentials. Have
not tried client login (doh!)

Oh, cached credentials to a DC should never be in effect unless there is
a DNS problem or dead network (IP fails to load).

Make sure the DC is a DNS server and has itself registered (unless for
some strange reason you are using a separate DNS server in the lab.)

Check the DCs NIC to make sure it is using only itself as DNS server.

With that, NIC working, IP initialized, and DNS resolvable the DC
should be able to authenticate on itself.

To the DC

Yes, you should never need cached credentials "AT the DC".

Thanks, have not checked that.

Almost certainly the main issue.

Objective is to recreated Ad structure in sterile environment to test a
specific software product (done by another consultant)

Then since an objective is 'sterile environment', only new domain would
technically meet that requirement the way I read the wording.

Also, there was no requirement for access to current domain data, so
removing a DC from a working domain is an unnecessary complication.

If the particular hardware was needed, I would have DCPromo'd it to
non-DC while online -> gone offline -> DCPromo'd it to new DC
in new forest.

What they are parsing for is irrelevant as far as my work goes to get a
DC and a few servers into testing.

Oh Yeah! Fortunately, that is not my bone to chew on.

Let me know if I can help.

How about turning on logging of some sort? Testing might be easier
if you had Account Management or DS Objects [AND setup ACLs
for Auditing ] enabled.