Domains, Migrating them, and the stuff between

S

Sanfam

Limp Gawd
Joined
Jan 20, 2003
Messages
174
So domains aren't usually my territory, but I believe I have a functional understanding of this manner of system. Anyway, the problems I'm encountering (seemingly) simple ones offset by the fact that I am, for all intents and purposes, completely green when it comes to domains.

The local network is mediated by a single Server 2000 system acting as the sole domain controller for an office of 17 systems. Users log in, do their work, log out. The problem, however, is that the old domain controller needs to be retired due to a number of complications developing within its domain infrastructure (stemming from physical data corruption). A new server was constructed to take its place, running Server 2003 Standard R2.

I am now at a fork where I need to decide which course of action to take. Do I attempt to migrate the old domain over to the new system? And if so, then how would I go about doing such a thing reliably? Or do I simply create a new domain on the new server and port the existing machines over to said infrastructure, moving account data and user profiles with the aid of the user hive migration tools?

(Pardon the wordy nature of this, but I feel I should explain my state before explaining the problem itself) The second genuine problem stems from an experiment with the latter, namely in attempting to completely reconstruct the user rights assignments on the domain. Right now, they really do not exist. Corruption has claimed a few user accounts and people without the slightest understanding of user rights have come in and made a complete mess. On top of this, I was looking to configuring the server in such a way as to offer four tiers of regular user rights (Editor < Designer < Developer < Management < Domain), so I felt it would be worth attempting to model this on an isolated test network connected to the new domain controller instead of doing so on the primary server.

I've managed to hit a brick wall from this point on. I somehow cannot seem to create a user group that allows an account to have local administrative privileges on whatever system it is logged in to without making it a domain administrator (I wish for this user level to have full system access, but no domain controller access). I have a feeling that perhaps I should investigate finding a means of denying the Domain Administrator direct access to the server and instead promoting those with server access to Enterprise Admins and/or Schema Admins, but this seems like it might have some unintended side-effects. This has been a consistent stumbling point, as I want both Designers and Developers to have access to the system, but do not want editors (typically short-term employees) to have the same. (I'm also tempted to deny the dangerously curious management access of any sort, instead loading up a pretty picture/movie or other distraction to keep them from touching anything while making them feel productive ;) But I suspect that wouldn't go so well once they tried to actually do anything... :p)

My thoughts remain that I am torn between the two possibilities. While the porting of the systems to the entirely new domain would be chaotic, I would be able to start from scratch and abandon the nearly nine years of packed-in crap. But the easiest, most transparent solution would be to do it the proper way...transfer the domain controller as intended by design through the built-in management system. But I have no clue where to even start when it comes to this, and the vast majority of the online guides seem to approach it from the perspective of someone with a great deal of knowledge and experience. I lack either in this territory. The last thing I want to do is leave the office with no domain whatsoever, which would be an absolute nightmare. The decision would best be made by tonight or early tomorrow as the weekend allows me a two day zone to get this done and smoothly running.

So everyone chime in on this. I'll be poking my head in occasionally.
 
With a small network like this I would happily start from scratch, especially if you're talking about corruption and previous incompetent admins messing with this.

So I'd suggest evaluating everything that needs to be done on the new domain controller, and document everything very carefully and make a good backup strategy so this mess can't come around again.

As for setting up local admin settings, I always thought this was done locally on the client machine. But i'm not too sure!
 
If it was me, Id build the new domain controller, then add it to the current domain, then promote it to a domain controller and let it replicate for a day or two.
Make sure DNS is working correctly and check the event logs for errors.
You can move the DHCP to the new server, or add a different IP range (scope) on the new server
You can move all the FSMO roles over to the new controller (google for this, I cant type out all the steps, its fairly easy though), if you have corruption problems, I would try to manually copy the data from one server to the new one when you are creating file shares.
- organize the server shares, dont assign individual permissions on shares, use domain groups
- create a domain group "Local_PC_Admins" and then in each of the workstations, you have to add this group into the administrators group (by default only the domain admins are in the local admin group, ...probably why your noticing only adding to domain admins works) there is an app on petri.co.il that can add these groups for you, and I think you can do it with GPO as well.
Use group policies to make your life easier
- redirect users "my documents" to the server
- set the IE cache size accordingly (I hate users that call with slow response, only to find out there IE cache size is at 1.7gb, I set it to 21mb)
- create a logon script to map drives based on domain groups (youll only have 1 logon script to update then, rather than multiple, you just have to add a new section if you make a new share/group)

For the PC's, what I have done for some small shops that were scared to move from workgroup to domain, or ones where I wasnt sure how bad there old domain was, I put a new hard drive into the PC, then built that up and added it to the domain (if I ran out of time, or didnt like the results, I could pop in the old HDD and they would be back at where they started, HDD's are pretty cheap, and youll always find a use for them)

Dont forget to document all your changes
 
Keiichi said:
This can be done by seizing FSMO roles as described here:
http://support.microsoft.com/kb/255504 and go here for taking the old DC out http://support.microsoft.com/kb/555846/en-us
And yes it would be worth the $259 to have MS support walk you through the entire process.
Click to expand...

Well, my preference would be to avoid seizing and instead do a proper transition, removing the corrupt users and any damaged data before the attempt, but I'm not opposed to it. Would this allow the original domain controller to remain (technically) active a drop-in backup if the need arises?

The bigger question is this: What would need to be done on the target/destination system? What roles need to be configured and to what extent do they need to be managed? My worries are that the DNS (biggish worry) and DHCP (trivial worry) data wouldn't be ported over, but if this isn't the case just let me know. Again, I'm pretty damned green in this area.

(And I may just call in and do the walkthrough as suggested, but I doubt I could get the funds alotted do so. To explain here how to obtain funds from the boss would be like describing how to create a stable room-temperature fusion reaction using only four paper clips, a lemon meringue pie, and a cat. It's a difficult, convoluted task from a penny-wise, pound-foolish management.)


dbwillis said:
<snip>
- organize the server shares, dont assign individual permissions on shares, use domain groups
- create a domain group "Local_PC_Admins" and then in each of the workstations, you have to add this group into the administrators group (by default only the domain admins are in the local admin group, ...probably why your noticing only adding to domain admins works) there is an app on petri.co.il that can add these groups for you, and I think you can do it with GPO as well.
Use group policies to make your life easier
- redirect users "my documents" to the server
- set the IE cache size accordingly (I hate users that call with slow response, only to find out there IE cache size is at 1.7gb, I set it to 21mb)
- create a logon script to map drives based on domain groups (youll only have 1 logon script to update then, rather than multiple, you just have to add a new section if you make a new share/group)

For the PC's, what I have done for some small shops that were scared to move from workgroup to domain, or ones where I wasnt sure how bad there old domain was, I put a new hard drive into the PC, then built that up and added it to the domain (if I ran out of time, or didnt like the results, I could pop in the old HDD and they would be back at where they started, HDD's are pretty cheap, and youll always find a use for them)

Dont forget to document all your changes
Click to expand...

I've got a bit of a humorous addition to the top-most remark. When I came back here from my months away, I found that the drive mappings had gone up by eight. There were now eight more <10MB shares...each an individual partition...all because an admin at the time didn't want to create a single share with subdirectories.

Regarding local administration, I'll check into the app and see what I can dig up. And I'm positive that there is a way to enable it through GPOs, but I just lack the knowledge in my present state to make this work. Must...learn...

And as part of the new server, users are all gaining roaming profiles within the next month (another thing I must learn more about successfully implementing), so these profile slimming changes will need to be made across the board. Our past policy was "New employee? build a new system for them," which made very poor business. This was followed by "just share user accounts," which made it difficult to actually manage user rights. Ugh!

Re: last item, I tend to do dual-boots when users are afraid of change. Quite often, they see the light and stick with their newer install and simply forget about the old. Works like a joy and the results don't need to impact their productivity cycle.
 
As dbwillis pointed out the ideal way is to transfer fsmo roles with his method. Seizing is a last resort method. The seizing article I linked also lists how to transfer FSMO roles as well.

Basically you just get your freshly installed 2003 server to join the domain as a member, log on as an enterprise admin on it, then follow the steps. By default in a Win2K domain all FSMO roles are contained in one DC, the AD controller. Just make sure you transfer that you transfer any services that system hosts to another system, DHCP, DNS, File/print etc., then once that is taken care of transfer FSMO roles. Then do the cleanup on aisle 5.

One good thing about MS support is that they document pretty much everything and will send you transcripts of the entire incident. I know it will definitely save on the man hours. If anything else those transcripts will be valuable logs for you to show to your boss that it's really really complicated and worth the $259 ^_^.
 
Theres also another method you could try, without impact, which is the same as the sbsmigration.com package (which I bought and was worth the $$)

add a DC to the current domain, let it replicate for a day or two, then disconnect it from the domain, then have it seize all the roles (now youd have 2 of the same domain running seperately)
Youd 'purge' the old domain controller from the offline domain you had just created, then you can make a new domain controller with the same name as the old domain controller (since you just puirged it)
Then you can move the new server into the old servers place.
- same name so there isnt any problems, its just a 'cleaned' up version of the domain.
The tempDC can be a PC, virtual machine or laptop since its just a temporary one, plus you can do this at your leisure, in the office, at home, wherever.
 
First off, thanks for the responses. It can sometimes be difficult to get good information from the cloud of minds that is the internet. Anyhoo, I was lassoed by the boss this evening and during the time I was expecting to be configuring the server, was forced to sit and listen to an only fractionally conscious man pick apart every single component of a 35 item PO for what amounted to nearly four hours. As such, I had to put off reconfiguring the server for the elegant FSMO transfer and now have to wait another day or so to ensure proper replication. (doh)

Any good ways out there to ensure replication, or am I best just sipping a slurpee and enjoying myself for the next day?
 
Why don't you setup another domain, setup a trust and migrate the users one by one. Once the trust is in place, you can give things on the old domain rights using the credentials of the new domain, so that you can transition and then migrate everything over.
 
Sanfam said:
Any good ways out there to ensure replication, or am I best just sipping a slurpee and enjoying myself for the next day?
Click to expand...

1. Open Active Directory Sites and Services.

2. In the console tree, click NTDS Settings for the server that you want to force replication.

3. In the details pane, right-click the connection over which you want to replicate directory information, and then click Replicate Now.

http://www.windowsitpro.com/Files/16/13396/forcereplication.gif
 
ND40oz said:
Why don't you setup another domain, setup a trust and migrate the users one by one. Once the trust is in place, you can give things on the old domain rights using the credentials of the new domain, so that you can transition and then migrate everything over.
Click to expand...

I don't particularly like this suggestion. It is tedious and you can mess things up very easily.

It is best just to run DCPROMO and use the directions posted from Microsoft above.
 
LoStMaTt said:
I don't particularly like this suggestion. It is tedious and you can mess things up very easily.

It is best just to run DCPROMO and use the directions posted from Microsoft above.
Click to expand...

If the existing domain has parts of it that are hosed, what do you think the rest of it is like. Personally, I'd rather start fresh then bring up another DC in the domain and hoping that there aren't any other series issues. Who knows what was done with permissions and other things before you got there. Trust me, I dealt with this before, it's easier with a small instance to migrate away and start over then try to "fix" what the previous administrators have done. If you know what you're doing, you won't mess things up and it's not tedious, it's actually pretty simple and AD can migrate the groups, user and computer accounts for you.
 
xtox said:
With a small network like this I would happily start from scratch, especially if you're talking about corruption and previous incompetent admins messing with this.
Click to expand...

With a network so small...(only 17x workstations..so it's really a very quick and painless thing)....and the current DC is some unknown state of ...lack of health....I agree with this....start with a clean slate. Walk away knowing it's nice, clean, 'n healthy...no need to worry about lingering issues coming back to bite you. Leave the corruption behind.
 
You must log in or register to reply here.
Back
Top