+BudMan MVC Posted March 3, 2014 MVC Share Posted March 3, 2014 not MDHN.. you need a tld. Link to comment Share on other sites More sharing options...
riahc3 Posted March 13, 2014 Author Share Posted March 13, 2014 Hello, not MDHN.. you need a tld.MDHN is the NetBIOS name I think. Link to comment Share on other sites More sharing options...
+BudMan MVC Posted March 13, 2014 MVC Share Posted March 13, 2014 Well that is fine, but you know the pre-2000 domain name or netbios name doesn't have to fall in line. You could use I believe anything up to 15 characters so it could be Mcdonalds for example. But yeah makes more sense to match it up to what your fqdn is. Link to comment Share on other sites More sharing options...
ziph Posted April 3, 2014 Share Posted April 3, 2014 If you could get the new domain up alongside the old, you could get the sid's from the old domain to the new users on the new domain. sid-history can be real nice when the old UID shows up on the new server, so the ressources the UID had before will stil be available. Then again, maybe in your situation it is a little overdoing it, if the only ressources you need to migrate is fileaccess. We migrated around 40K users on my university in the last year or two, all with sid history (admt), but actually we just decided to wipe them all, since they are creating some annoying issues for certain applications (nilex/vcenter) etc. And in the end, having sid history, is really also tying one in the old environment, which we should really just migrate to our new domain anyway. So, build your new domain, make all your file permission groups. If you could make a trust to the old domain, you could allow users from there (or groups) acces through the new domain aswell. Untill you have everything settled and you can disconnect the trust, and do away the old domain. There are more than one way to your goal, the question is how much you want to disturb your users. With a trust, you could migrate everyone slowly but without much fuss for the users, and take one at a time. Also there is the nifty tool in windows 7 if you are running that, "windows user migration tool", you can save ppl's profile,to a share, and import it after you joined the new domain, to keep all settings and make them use the new domain. Just go to advanced when you import, and match your user with the new domain. I used that alot over the years with great success. Link to comment Share on other sites More sharing options...
PGHammer Posted April 19, 2014 Share Posted April 19, 2014 I'd say scratch as well. Just make sure that the new server's Domain isn't the same name as the old one and you could use the profile transfer wizard: https://www.forensit.com/move-computer.html No worrying about users losing settings then ;). I agree - start from scratch, and especially if there are going to be hierarchical changes in the directory structure in the new AD forest. Despite my AD in my virtualization lab being based on a single controller, I have left space for all the things I don't have (backup DCs, Exchange or other mail servers, etc.) in the structure. Even better, you can dry-map out the entire domain in your application of choice (it can be a text-file, for that matter) and then input it into System Center 2012R2 as a template for trees in your existing forests, or even whole new forests. (With minimal tweakage - which you can do right in SC 2012R2, or even SC 2012, you can do either or both, depending on your needs.) I can only hope that the forthcoming System Center Essentials offers enough of the same capabilities that SMBs and even home users can leverage without it getting too expensive. Link to comment Share on other sites More sharing options...
Recommended Posts