Small Business Server 2003 to 2012 R2 Migration and Virtualized Domain Controller Questions
-
I told you about using the CNAME process at the beginning of this process
-
My RoboCopy tests have proven to be good so far. I see the domain level permissions!
-
@scottalanmiller said:
I told you about using the CNAME process at the beginning of this process
My memory is fading when I spend 2 hours trying to explain to our office manager why scanning in a 500 page project in our copier make it run out of memory and I cannot change that fact...
-
You can only use the CNAME after you turn off the old server.
-
Don't forget, before you turn off the old server you should DCPromo it to remove it from the Active Directory. Then you can turn it off and delete the records from the DNS server.
-
These are the steps I have left in the list I've collated over the past few months:
§ Transfer FSMO Roles to new Server 2012 R2 Domain Controller □ Transfer all 5 or one at a time and start demoting your old Server 2003 DC's in the next step. But the key to remember is to NOT demote any of the current domain controllers that have any of your FSMO roles on them. Be sure to transfer them off first before proceeding to DC demotion. □ http://blogs.technet.com/b/canitpro/archive/2013/05/27/step-by-step-active-directory-migration-from-windows-server-2003-to-windows-server-2012.aspx § Demote old Server 2003 Domain Controllers □ Run dcpromo and follow steps. ® Remember: Do NOT demote any domain controller that does not have FSMO roles on them. □ http://technet.microsoft.com/en-us/library/cc740017%28v=ws.10%29.aspx § Raise Domain Functional Level □ Raise the functional level by opening Active Directory Domains and Trusts. Then right click on domain and trusts and select "Raise Forest Functional Level" □ http://technet.microsoft.com/en-us/library/cc730985.aspx § Migration Complete! :) -
Looks good.
An FYI for you. If you demote a server that has a FSMO role on it - DCPromo will push the roll to another server (at least it did for me once). But do as the documentation says, move them yourself first.
Heck, just to make sure everything is working well, I'd move all services (files/printers/av console, etc) off the old server, then after a few days to make sure that all works, I'd move the FSMO rolls then turn off the old server for a day or two. If your network continues with the old server turned off before you remove it from the domain, then you know everything has moved as needed. If when you turn the old server off, something breaks, you know you forgot something.
-
@Dashrender said:
Looks good.
An FYI for you. If you demote a server that has a FSMO role on it - DCPromo will push the roll to another server (at least it did for me once). But do as the documentation says, move them yourself first.
Heck, just to make sure everything is working well, I'd move all services (files/printers/av console, etc) off the old server, then after a few days to make sure that all works, I'd move the FSMO rolls then turn off the old server for a day or two. If your network continues with the old server turned off before you remove it from the domain, then you know everything has moved as needed. If when you turn the old server off, something breaks, you know you forgot something.
I may look at doing this. Moving the files over will coincide with login scripts to map the drives to the new file server. Since I cannot use the suggested CNAME option above until the old server is turned off, I'll for sure need to make sure our software code points to the new file server on selected sheets that have code that references the current file server.
-
@Dashrender said:
You can only use the CNAME after you turn off the old server.
That's only because a CNAME wasn't used before. If you used service names rather than host names from the beginning, as you will now, this becomes transparent and you no longer need to turn off the old system.
-
So what are some of the BPA's I can run to check to see if this last step is working? I did create a new user on the new server and it replicated back to the old one.
-
@scottalanmiller said:
@Dashrender said:
You can only use the CNAME after you turn off the old server.
That's only because a CNAME wasn't used before. If you used service names rather than host names from the beginning, as you will now, this becomes transparent and you no longer need to turn off the old system.
This is a great point. garak - listen to this. Create a CNAME NOW, right now for that new server. Then use that new name for all of your new logon scripts. This will save you a ton of pain the next time this needs to happen.
Also, now is a good time to look at creating DFS shares instead of normal shares (OK not really instead of, but in addition to).
-
Yes. Just like you can't skip virtualization now, don't skip proper DNS management too.
-
@NetworkNerd said:
@garak0410 said:
Most people have said just ROBOCOPY the files from the old file server (in this case, SBS 2003) to the new one (2012 R2 Virtual Machine) and it will keep the permissions intact and echo the different server name...correct?
Something like this should suffice: robocopy /mir /sec /secfix "source" "destination"
Question...I want to just copy everything over from d$ on oldserver and copy to e$ on newserver. What's the best syntax for that? I am getting
ERROR : Invalid Parameter #3 : "/secfix"
Currently when trying this...
-
@garak0410 /secfix needs more info. Add /copyall
-
@scottalanmiller said:
@garak0410 /secfix needs more info. Add /copyall
I added it and it still doesn't like secfix...maybe my syntax is still bad:
robocopy /mir /sec /secfix /copyall "\oldserver\d$" "\newserver\e$"
and the double \ is in there, just now showing up in the post...
-
Use three backslashes for it to show up.
-
Why are using /sec and /secfix ? One or the other.
-
And I don't believe that you can mix /mir with /copyall
-
@scottalanmiller said:
Why are using /sec and /secfix ? One or the other.
Because it was suggested earlier in this thread...LOL
-
/sec applies security, /secfix attempts to fix it. Pretty sure that they cannot be mixed.
