How to migrate Windows 2000 NTFS permissions to new Windows 2003 server

The easiest thing to do is add the 2003 server as a SECOND domain controller in your existing network - this will essentially upgrade Active Directory to 2003's version.

Then you can use ROBOCOPY, XCOPY, or the old NT 4 utility, SCOPY to copy the files and security information to the new server via command line.

Thanks for the reply...

Currently I have no domain controller on the network. The 2000 Windows server is a simple member server. Are you saying that  I should upgrade it to a domain controller, then put the new 2003 server on the network as a second domain controller? I will consider that, but in all honesty I would prefer to keep the 2000 Windows server exactly as is to avoid the possibility of downtime.  If I do upgrade the Windows 2000 server to a domain controller would I need to reconfigure the workstations? If so, then it will probably not be an option.

We are definitely planning on going to a domain controller with the new server. But the main thing here is continuity to avoid downtime.  That is why I was planning to leave the 2000 server as is while the 2003 server is getting configured and the files copied over.  

One simple question in this... If I name the user and group accounts exactly the same on the new server, can I copy the directories over to the new server using xcopy and keep the NTFS permissions?

Thanks in advance!

bizcrown101,
> Currently I have no domain controller on the network. The 2000 Windows
> server is a simple member server.

This is a problem then.  I thought you had an existing domain with the existing server.  But since you don't you're pretty much out of luck.  Local accounts cannot be easily converted into domain accounts (and they cannot be easily migrated to another system either.
A quick search of google returned this:
http://www.winzero.ca/MSVR-Migrator.htm - before you dismiss it - if it would take you 40 man-hours to move and reset everyone's account and you get paid $25 per hour, then this software may be able to significantly reduce that time and in turn, even though you're spending $550 on it, you will save money by doing the task faster.  Before buying EVALUATE it first - they have a trial.

> Are you saying that  I should upgrade
> it to a domain controller, then put the new 2003 server on the network
> as a second domain controller?

No, as I mentioned above, I expected you already had a domain.

> We are definitely planning on going to a domain controller with the
> new server. But the main thing here is continuity to avoid downtime.  
> That is why I was planning to leave the 2000 server as is while the
> 2003 server is getting configured and the files copied over.
> 
> One simple question in this... If I name the user and group accounts
> exactly the same on the new server, can I copy the directories over to
> the new server using xcopy and keep the NTFS permissions?

NO.  Windows security is based on unique security IDs which are generated randomly during the creation of the machine/domain.  user names are then mapped to these IDs.  Thus you can change a user name and still have complete access to the resources the previous name did.  BUT, delete the account and recreate it (or create an account by the same name on a different machine) and it will have a DIFFERENT Security ID which will not correspond to the ones on the resources.  (This is why in a domain, you should NEVER be too quick to delete an account of a user - disable the account and wait a month at least).

Thanks again for your help...

So I guess my plan now is to make a good record of all the user accounts, groups, shares, and printer setups on the 2000 server. Copy all the data I need over to a temporary holding area. Setup the new Windows 2003 server with the exact same computer name and enter the user accounts, groups, and printer configurations. Copy all the data to the new server from the temporary holding area. Finally, go through and assign all the security permissions and setup the shares.  

Then after everything is running smooth for a few weeks I plan to upgrade the new server to a domain controller.  My primary reason for waiting on the domain controller upgrade is continuity and to avoid having to modify the setups on 60+ workstations on the same weekend as doing the server upgrade.

Thanks for the help and advice.

Bad idea.  You'll have to setup the accounts AGAIN if you do that plan, a total of 3 times.

Setup the domain on the new server first and setup the users as domain users.  You will then avoid having to do that a 3rd time.

Ahh, I see what you mean.

The rub though is that I won't be able to access the 60 workstations to change their setup on the same weekend I'm setting up the new server.  So I need a solution where I can replace out this server and I can be 100% sure people can be in working first thing Monday morning without any access problems.  Some of the reason for this is our network reliability and problems we've had in the past with some workstations accessing different servers.  If i get in a bind Monday morning and key people cannot access, I have to be able to swap the old server back in a few minutes notice. This would not be possible if I have modified workstations to look for a domain.  

 I figured if I move to a domain model that is going to require some configuration on each and every workstation for everything to get up and going.  I suppose the solution will have to be to just not plan to go to a domain model at all and just stay with the same old workgroup configuration.  

What would happen if I setup as a domain  model with the same server and users names? Would all the workstations still access by server name even though there would be no domain setup in their network configuration?  I assumed that the workstations would not authenticate properly without modification because you would need to go to each one and fill in the 'Domain' name inside the network credentials.  

Thanks again for all your help!  The most important thing I need is a fallback to the old server Monday morning if there are problems. Changing workstation setups could leave us in a huge bind on Monday morning if critical operations are having trouble.

I'm increasing points because the scope of this question keeps creeping up!

Do you have a couple of old machines? If so, I strongly encourage you to setup a small test network and experiment.

Do you have any experience with domains?  Or, to put it another way:

Do you know what the FSMO masters are?
Do you know what the Global Catalog is?
Do you know how DNS should be setup on the clients and server?

If you answered anything other than an emphatic YES to the above questions, you need to put the domain plan on hold a little bit, until you learn these things.  Failing to understand these items and how they work in a domain CAN be problematic and in some cases cause serious network issues if not correctly set.

To be clear - I STRONGLY recommend you go to a domain environment, especially with 50 users, but doing so blindly is DANGEROUS!

I would tend to suggest the best time to do this is during a week when business is relatively slow and many people are on vacation, gives you time to work out the bugs.  That said, in most environments, that's the week before thanksgiving and christmas week - not exactly upcoming dates.

The thing that complicates this is if you insist on keeping the server names identical.  It would be MUCH easier if they could be different.  Can the server name change?  (more to come, but that's a key question right now).

I've setup a few domains before but with Windows 2000 small business server not 2003.  That was a few years ago and it was a very small network.  I think I have the workstation configuration part down (because I have done it more); the server stuff I feel like I was just lucky in that I didn't have much troubleshooting to do.   I'm definitely wanting to take it slow which is why I want to have my old server as a fallback in case I'm stuck here Sunday night and not able to get everything ironed out.

Luckily we have downtime in July for about a week while the factory is being retooled. Unfortuantely I can't wait to get the new server online until then because of complications regarding adding new fiber and a new switch to the network. It's sort of a long story there.  On top of that, we need to bring on an Exchange Server to take over email in early June. This I know would work much better if the domain model was already in place but it looks like for the short term we are just going to have to run it as a standard POP3/SMTP style email server. More complications and I can feel there is going to be a lot of double work simply because we can't do all this in one step.

Changing server names is a bit complicated because of how our engineering department setup many of their Excel documents. They embedded links to files and pictures inside their engineering documents that specifically refer to the server name inside the document path.  Change the server names and all their design documents break.  We are talking 15k are more documents. Perhaps I could write a macro or something to change this but right now the easiest thing is to keep the server name the same.

Thanks again for your help.  It's really given me some things to think about and do some research on.

Ok - you know Exchange REQUIRES Active Directory - so you can't just use it as a POP/SMTP mail server without AD.

Needing to preserve the server name is what may make this FAR more of a headache.

In theory, you can change the name of the domain controller - reference:
http://www.petri.co.il/windows_2003_domain_controller_rename.htm

So assuming you do that, then my previous comment stands (note: I've never changed the name of a domain controller and I'm not sure if there are any/many short term or long term negative effects).

As for migrating the data, one way to make this move easier, use a backup.  Take a full backup of your data from the server and restore it (Data only) to the new server.  Then, the day of the migration, shut down the server service so no one can connect to the system and make changes to files on it and do a differential (differentials only get changed data so it should be a MUCH smaller backup than a full and should run pretty quickly).  Then restore the differential to the new machine.  Done.  Most of the data can be migrated midweek and ther changes done at the last minute to save you some time.

Huge help!  

I think that maybe the ticket! Even with the issues of linked documents in Excel, I maybe able to overcome that with a simple VB script.  Who knows, I maybe able to dig up a script somewhere or get some help on here regarding that issue.  

Luckily, 90% of our applications and documents use the mapped drive letters instead of the server name.  I suppose if worse comes to worse the apps and docs that are hardcoded with the server name can just stay on the old server indefinitely.  That would not be the end of the world.  

Unless you can think of anything else to add I'll your last answer so you can get credit for the points.

Thanks a ton!

One other suggestion - don't get rid of the old server (not sure - you may have hinted you won't).  Setup the domain, then join the old server to the domain.  All files can remain there.  Or you can move some files off onto the new server.  File Serving is generally not a taxing service and low end machines can often handle it quite well.

And by the way, the backup could be great, but it might preserve the permissions - which won't actually do you any good with them being associated with local accounts.  The build in NTBackup I THINK will provide the option of NOT restoring permissions - if that's the case, you're probably better off doing that and reapplying them later.

Also, I don't do much vbscripting - I tend to prefer batch scripting.  You could map out the folders and directories and create a batch script using CACLS to reset permissions on everything (again, test first on a non-production machine with a small sample set of data).  Note, there's a trick to using CACLS - it likes to prompt you and to avoid that prompt you need to feed it the contents of a small text file with a single "y" character and enter in it.  For example:

cacls filename /t /e /c /g everyone:f < y.txt

Where y.txt is just:
--------8<-------
y

--------8<-------

Come to think of it, if you did that, then you COULD do your plan that I original said was a bad idea... because you'd just have to run the script again with a few minor modifications.