Forest Root PC Stolen + No other DC in Domain + No SSD Backup

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I work at a college, and recently set up a lab of W2K servers for a class where the students were going to build their own Active Directory, purely for the use of one class.

After building the first DC (called INSTRUCTOR), and creating the domain Room.College, I set up a seperate SYSPREP image for standalone servers, which the tutor applied to each student machine.

The room was then handed over to the tutor, and I was no longer involved in the setup. The students created their own subdomains (for example, the server STUDENT1 became a DC in the domain Student1.Room.College).

It all sounded OK till the INSTRUCTOR machine was stolen in a break-in some time last week

I was able to rebuild it by applying a GHOST image I created after creating the Room.College domain to an identical machine. This machine is not connected to the network yet. Then I went to do a restore from backup, or failing that use DS Restore Mode.

Only then, did I find out that

1. No other DCs were created in the Room.College domain
2. Ditto the subdomains. Each one has only one DC
3. INSTRUCTOR hasn't been backed up at all since I created the GHOST image.
4. The System State Data has NEVER been backed up on any of the servers (not even Instructor)
5. All machines were left in the same site (Default-first-site-name)
6. The DNS, and all master roles, were left on INSTRUCTOR. Although, one of the students' machines is a Global Catalog

As a consequence the rebuilt server on my desk has absolutely no knowledge whatsoever of the subdomains that existed in the classroom before the break-in.
So I've left it off the LAN for the time being

However, keeping the INSTRUCTOR machine off the network for the remainder of a course where the students are invariably going to want to be manipulating the forest, is not really an option.

If anyone has suggestions on how to progress, I'd be most interested
 
Perhaps I should make something a little clearer: I have discovered that the students have worked almost exclusively in their own subdomains

Under this circumstance, would it matter if I never brought INSTRUCTOR back up as the forest root

Could we (for instance) delete the replication links from the student servers to INSTRUCTOR, and just let them carry on in total isolation

Finally, if I forced an uninstall of AD on INSTRUCTOR, and let it serve as a standalone server, would it function correctly as regards providing the DNS service to the lab? The machines are using static IP addresses

The only reason I'm asking, is because if the students can work on their own domains without needing to update INSTRUCTOR, it doesn't matter too much if they can't fooll around with the top level

As I'm wearing my MCSA hat, I can tell you that I'm perfectly okay with the "you've lost the forest" answer

But I am burdened with another hat - the "if Joe Student can muck about with his own subdomain, who cares?" hat. It's not my hat, but I have to wear it
 
You forest is screwed up permanently --if it still functions as you desire
(apparently
you are getting by) then continue on this way but recognize that if they are
using this
as a "Learning environment" there may be unpredictable problems or
unexplained
inconsistencies and perhaps the BEST learning experience would be for
everyone
to re-install....

--
Herb Martin
Tim Staddon said:
Perhaps I should make something a little clearer: I have discovered that
the students have worked almost exclusively in their own subdomains.
Under this circumstance, would it matter if I never brought INSTRUCTOR back up as the forest root?

Could we (for instance) delete the replication links from the student
servers to INSTRUCTOR, and just let them carry on in total isolation?
Finally, if I forced an uninstall of AD on INSTRUCTOR, and let it serve as
a standalone server, would it function correctly as regards providing the
DNS service to the lab? The machines are using static IP addresses.
The only reason I'm asking, is because if the students can work on their
own domains without needing to update INSTRUCTOR, it doesn't matter too much
if they can't fooll around with the top level.
As I'm wearing my MCSA hat, I can tell you that I'm perfectly okay with
the "you've lost the forest" answer.
But I am burdened with another hat - the "if Joe Student can muck about
with his own subdomain, who cares?" hat. It's not my hat, but I have to wear
it.
 
Thanks for that, Herb

I totally understand that the AD is (to all intents and purposes) beyond retrieval.

I think it still merits a discussion, though

I don't need to know if Microsoft supports it because I know they don't. All I do need to know is if this will allow the students to practice tinkering *with their own domains* for the next couple of lessons.

There are bound to be similarly legitimate cases in the real world where people will want to set up a "quick and dirty" AD purely for the purposes of manipulating and trashing it with ruthless abandon.

This is one such case

From the tutor's perspective, I can see why he set the room up the way he did: he wanted to use the least amount of machines possible for the forest (for financial reasons) but at the same time give each student a seperate domain which was freely theirs to be manipulated and practiced on in such a way that they couldn't trash each other's work

So each student had his own domain, and he was only allowed to play with that. The INSTRUCTOR PC is the only DC in that domain and the only person allowed to play with it, is the instructor. The students copy whatever he does, on their own DCs

The only real mistake was not backing up INSTRUCTOR. Everything else was expendable

In any case, as long as the students can see the tutor playing with AD on any server in the forest by virtue of an electronic whiteboard, their inability to view the changes from their own machines is not as catastophic as it would be in the real world.

This is why I need to know if the subdomains will function in a "localised" capacity if they remain unable to communicate with a DC in the root domain

Let's say I install a DNS service to another machine and point the servers to it. The original DNS wasn't AD integrated. AD depends on DNS for replication, but let's say I put in a bogus record for INSTRUCTOR that is unreachable

If I understand correctly, They wouldn't be able to replicate AD, but they can still administer their own domains and talk to each other with pure IP

That's all the functionality we need till the end of the course
 
I don't need to know if Microsoft supports it because I know they don't.
All I do need to know is if this will allow the students to practice
tinkering *with their own domains* for the next couple of lessons.

My belief is yes -- AD will survive 'disconnects' and loss of replication
etc. pretty
well and your experience is that it is generally working.
There are bound to be similarly legitimate cases in the real world where
people will want to set up a "quick and dirty" AD purely for the purposes of
manipulating and trashing it with ruthless abandon.

There is no known way to replace or insert a parent domain.
You MIGHT be able to reload the backup and figure out a way to
convince it that the children are, well, child domains.

I have my doubts in the absence of someone giving a concrete suggestion
(a la "reset" the individual machine that loses connectivity to the domain.)
This is one such case.

From the tutor's perspective, I can see why he set the room up the way he
did: he wanted to use the least amount of machines possible for the forest
(for financial reasons) but at the same time give each student a separate
domain which was freely theirs to be manipulated and practiced on in such a
way that they couldn't trash each other's work.

He could have just made separate forests also. Unless there are sessions
that require the forest -- in which case you will have problems with them.
So each student had his own domain, and he was only allowed to play with
that. The INSTRUCTOR PC is the only DC in that domain and the only person
allowed to play with it, is the instructor. The students copy whatever he
does, on their own DCs.
The only real mistake was not backing up INSTRUCTOR. Everything else was
expendable.

That (or some similar claim) is a pretty much always the case when a backup
is not
available said:
This is why I need to know if the subdomains will function in a
"localized" capacity if they remain unable to communicate with a DC in the
root domain.

Almost certainly. You will get errors in the Event Logs though.
Let's say I install a DNS service to another machine and point the servers
to it. The original DNS wasn't AD integrated. AD depends on DNS for
replication, but let's say I put in a bogus record for INSTRUCTOR that is
unreachable.

DNS is completely distinct from AD -- you can easily repair the DNS.
AD on the other hand is dependent on DNS.
If I understand correctly, They wouldn't be able to replicate AD, but they
can still administer their own domains and talk to each other with pure IP.

They can likely replicate even (if they have 2 DCs) but the FOREST wide
replications will not work completely or continue indefinitely. Once these
DCs lose authentication with each other there will be no way to retrace it
through the (missing) common parent.

So Schema and Config (Sites and Services) will not replicate. But Schema
cannot be changed without the Schema Master (it was lost with the parent
domain.)
That's all the functionality we need till the end of the course.

Soldier on.
 
Back
Top