Migration from Server 2003 domain to Server 2012

Hello guys,

I will be migrating a small business' Server 2003 domain to a Server 2012 domain. Its a pretty simple setup with about 10 client pcs, and just one server. But I have no experience with Server 2012 yet, so in that regard I have a few questions. The server will be running Server 2012 standard.

Which antivirus product is usually used in small business enviroments, on server 2012? System Center 2012 Endpoint Protection is probably not suited for such a small domain, where none of the other products in the System Center suite will be necessary.

I can see there are a few options, such as Eset, AVG etc.

Find more posts tagged with

Comments

ptilsen

I haven't touched 2012. However, I've migrated from 2000 to 2003, 2008, and 2008 R2, and for small business I've found that the upgrade is generally non-eventful. Follow Microsoft's steps and you should be fine, assuming we're just talking about domain. If you're talking about an SBS server or a server doing much more than domain, it can be more complicated.

Antivirus choices invariably come down to six of one or half a dozen of the other. AVG is good enough, even if it has its problems -- they all do.

Dracula28

Its more or less just a DC. But its a single domain, single DC setup. And I haven't really done that kind of migrations before. Usually its 2-3 DCS in a single domain enviroments. There you can just demote the old DC, and promote the new server with the same computer name to a DC.

I don't think any applications are dependent on the DC by name in the migration I'm going to perform, but do you have any experience with renaming DCs in production enviroments?

Perhaps I could install the new server as an additional DC, then rename the old DC, and finally rename the new DC to the old DC's name, if I have to keep the computer name of the old DC. would you recommend this approach?

ptilsen

I would not recommend that approach.

This is the basic approach I would take:
Setup new DC
Join to domain
Run ADPrep or any other dependencies (again, haven't done 2012)
Run DCPromo
Setup DNS if not done as part of DCPromo (not sure how things go in 2012, but most likely you will have the option)
Setup DHCP or other services if necessary (typically in a single-server environment the server is running AD/DNS/DHCP)
Transfer FSMO roles to new DC
Modify DHCP to point services to need DC
Point old DC to new DC for primary DNS
Decom old DNS
Decom old DHCP and other services if applicable
Demote old DC
Disjoin server from domain
Decom server and delete its A record
Add Alias record of old server's hostname pointing to new servers' name
Walk through this article to get file sharing with the alias working (this isn't necessary in all cases or even most, but not knowing more about the setup I would recommend it)

Even this list misses a lot of the detail and possibly a step or three, but it should get you started. Do not monkey around with renaming the DCs as part of your process. No good will come of it and it isn't necessary.

You should also make sure what services are installed and in use on the old server. Again, I assume DHCP, DNS, and AD, but there's really no reason to assume. Check Manage Your Server, services.msc, and Add/Remove Programs to see what is going on.

Also, if this server is running SBS 2003, rather than vanilla Windows Server 2003, the process changes and you will need to read the relevant white paper, which probably doesn't exist for SBS 2003 to 2012.

Dracula28

Thanks. Thats pretty much how I was thinking of doing it, but I was keeping in mind that I might need to rename the DCs if applications/services are dependent on the old DCs name. I have to admit I totally forgot about creating an alias. The server is just running AD and DNS from what I can remember. Which is pretty straightforward to migrate.

Also its thankfully not SBS, its the plain Server 2003. I have no experience whatsoever with SBS versions of Windows Servers.

Btw, In Server 2012, you don't have to run Adprep manually when addning a 2012 DC in a 2003 32-bit domain. Its done automatically. There is also no dcpromo.

ptilsen

Nice! I've been avoiding Server 2012 for now because I know I won't get to touch it for at least three months, if not nine or more. Even what I do know about it makes me want to start implementing it.

One other thing to mention is if Server 2012 has BPAs and they're anything like 2008 R2, there will be some errors and warnings. Many are worth checking, but many will be a result of a single-server domain, which means they're obviously okay to ignore.

Dracula28

Any tips on migrating home folders? Robocopy keeps giving me access denied errors. Its just about 40GB. I was thinking of backing them up to a .bkf file and then restore the file on the new server.

But there might possibly be a better way to do this? I haven't migrated a file server before.

ptilsen

Robocopy is fine. If you're getting access denied it is for a reason, and you should work on that. Double-check share-level and NTFS permissions on each end. Assuming you are running it from 2012, an elevated Command Prompt would be necessary (and without it you would get access denied errors). By the way, be sure you're doing robocopy /copyall /e to get security ACLs and ownership passed as well as time-stamps.

If you can get drive letters to match up on destination server or don't mind doing some find and replace in notepad, you can save yourself some time in creating shares by migrating the shares themselves. If it's fewer than ten shares I would just do it manually.

There are other options but for a 1-to-1 like this I generally just do it "manually" with Robocopy.

rsutton

Regarding the server name. Once you decom the server, you can create an A record for the older server name and point the IP address to the new server. That way if someone types in \\oldserver\fileshare (or whatever) they would actually be accessing \\newserver\fileshare.

Also, I'm not a big fan of Robocopy but it works as long as you have the right syntax and permissions. The permission errors you are getting likely mean that the account you are using to run robocopy does not have access to something. If you have nested and explicit permissions, you will need to give yourself explicit access to these folders to successfully run robocopy.

ptilsen

rsutton wrote: »

Regarding the server name. Once you decom the server, you can create an A record for the older server name and point the IP address to the new server. That way if someone types in \\oldserver\fileshare (or whatever) they would actually be accessing \\newserver\fileshare.

This generally doesn't work unless you follow the steps in the article I linked. SMB file shares are hostname-aware and strict aliasing is enabled by default, at least in Server 2000 - 2008 R2.

Also, it doesn't really matter since both work, but it is more proper, if you will, to use a CNAME record since it represents an alias. For clarity, it is generally recommend to have only one A record per hostname, with any aliasing accomplished with CNAME records, not host records.

Edit: A note on Robocopy and varying nested permissions:
When encountering this, I will generally run cacls, xcacls, or icacls as needed to fix any permissions issues. For example, to grant domain admins full control over a directory recursively:
icacls [drive]:\[dir]\* /grant "[domain]\domain admins":F

In some cases, it is also necessary to perform a recursive Takeown. This is not ideal because it can take file ownership away from an intended owner, but it generally is not harmful.

One final note: When migrating between virtual systems on the same or compatible virtualization platforms, the best file migration method can actually be to attach the source systems hard disk, then perform the registry "migration" of shares. This negates any need for file permission changes or file moves since you are simply putting the original filesystem on a different machine. The same possibility applies to physical drives, but that is obviously not going to be possible in many situations and not ideal in most.

rsutton

That's some good information ptilsen. I would add that you should be careful not to take ownership of directories that are used for folder redirection as that can break folder redirection.

ptilsen

Indeed it can. In one instance, I performed this style file server migration, and actually wrote a script to automatically set ownership back to the user based on the folder name (folder redirection to home dirs set to \\server\profiles\%username%, so this was possible). Other times, I've manually had to fix the ownership issue. That being said, I've generally found Takeown is not necessary for this type of manual migration.

Dracula28

Thank you very much for the tips guys. I've managed to migrate all data, and everything is fine, except one detail,
SYSVOL and NETLOGON are not being shared from the Server 2012 DC. Everything seems to be just fine, and I can see the connection objects in AD Sites and Services. If I try to replicate them, the replication is succesful, but still sysvol and netlogon are not being shared on the new DC, and they are therefore not being replicated.

I can ping both servers from each other with their FQDN. Old Server has itself as the , and the new server as the alterante DNS server in tcp/ip properties. While its vice versa on the new server.

Any tips on this regard?

ptilsen

You will have to look in event viewer on both servers, particularly the File Replication Service, DNS Server, and Directory Service logs. The answer will almost certainly be there.

Dracula28

I had to set the BurFlags in the registry. D4 on the old DC, to set it as authoritative, and D2 on the new DC, to set it as non-authoritative. It resolved the issue. Because as soon as I started file replication service on the new DC, it shared sysvol + Netlogon, and replicated the policies and scripts just fine.