We help IT Professionals succeed at work.

Migrate 2012 remote desktop server to another domain

I have a 2012 remote desktop server that is a member and old windows 2003 small business server domain which is being retired.  I need some help with the proper migration steps to migrate the server over to the new domain which is already in place.  I need to make sure that I do not lose my licenses, etc. I would also like to preserve the existing user profiles if possible.
Watch Question

Will SzymkowskiSenior Solution Architect
Most Valuable Expert 2015
Top Expert 2015

If you are planning on migrating this server to a new domain you will need to use ADMT (AD Migration Tool). You had also stated that you want to also move the users as well, you are going to have to either have a 2 way forest trust or migrate the users as well to the new domain.

ADMT Download - https://connect.microsoft.com/site1164/program8540

ADMT Step by Step - http://social.technet.microsoft.com/wiki/contents/articles/11996.interforest-migration-with-admt-3-2-part-1.aspx

Duke KahanamokuIT Support Professional


The user accounts already exist on the new domain controller.  I would like to migrate each user's profile to the new domain profile - I have done this before with a 3rd party tool, but I thought there might be an easier way.  The bigger issue is that I think that the Remote Desktop Gateway and licensing may get broken using this method.
Site Reliability Engineer
Most Valuable Expert 2011
ADMT is for migrating from another domain or forest to a new one; it is not necessary if you can stand a new box up in the same domain, because standard AD replication will suffice for shifting that data to the new domain controller.

Firstly, I can highly recommend the swing migration kits available from http://swingmigration.itproexperts.com/. (I am in no way affiliated with that site, I just know they are good). Unfortunately, they don't seem to have kits for Server 2012; I shouldn't imagine it varies much from the 2008 case, but there will be some differences.

If you want to do this manually, then you will first need to consider what roles you are going to keep. Will you be keeping Exchange? Sharepoint? If the answer is "no" then it is fairly simple, otherwise it is going to be more complex.

You will first need to promote the new server as a DC, if you have not already, then follow the standard process for migrating from one DC to another, for which plenty of guidance is available online. Note that SBS will allow you to promote additional Domain Controllers, but you should not migrate the Operations (FSMO) roles away from the SBS server until the very end of the process, as doing so will cause you to enter the grace period after which SBS will no longer behave (the licensing requirements stipulate that it MUST hold the FSMO roles in the domain; refer this blog post for more details).

You must transfer all the data, and update the respective Group Policy objects regarding folder redirection, drive mapping, and so forth. Shares must be re-created on the new machine and ensure all users are switched over to using them, rather than the shares out of the old box. I'd recommend disabling sharing on shared folders once this is completed, so you are positive nobody is committing updates to the old file repository and getting out of sync.

You will lose Remote Web Workplace functionality, as this does not come by default with standard installs of Server 2012 (perhaps Essentials excluded?). If you need to allow remote access to workstations, you can deploy the Remote Desktop Services (RDS) Gateway role on the new machine, configure an SSL certificate, open port 443 and use this as a replacement; the gateway is configured in the "Advanced" tab of the mstsc.exe Remote Desktop Connection client utility on the client workstations which wish to connect to the server. There are plenty of third-party solutions which might also fit the bill, which would help avoid the need to run RDS Gateway on a Domain Controller.

If you are keeping Exchange, I would strongly recommend deploying this on a separate, member server at this time. Consider using virtualization (which I would recommend regardless) to host DCs and member server on the same hardware, if possible. Migrating Exchange is not too difficult; plenty of guidance exists online (link one; link two) for moving from Exchange 2003 to 2013, which I would strongly recommend you read and digest fully in advance before tackling the process. Note that 2003 -> 2013 is not a single jump; you have to move via an intermediate version such as 2010 to rid 2003 from the domain before you can complete the move to 2013. The articles cover this in detail. Don't forget to switch inbound mail delivery from the old server to the new, by updating the IP address(es) in your MX records and making the relevant changes to your firewall.

If you need to move Sharepoint, again, this involves standing up Sharepoint and dragging the data across; I'm not experienced enough to know the detail of this (none of my customers have ever used it) but there are again plenty of guides available.

One of the final steps will be to consider any other roles the SBS holds, such as a web server or DHCP server, and ensure those are provided elsewhere on the network.

Finally, decommissioning the SBS server means transferring off the Operations (FSMO) roles, ensuring the new box was promoted as a Global Catalog, then uninstalling Exchange followed by demoting (in that order) the SBS from DC to member server. At this point, the version of Windows Server on the SBS will become useless as you do not satisfy the licensing requirements. It will periodically log error messages to this effect and trigger spontaneous reboots to remind you of this fact, so be sure the SBS is surplus to requirements BEFORE you complete these last decommissioning steps.
Duke KahanamokuIT Support Professional


I had Microsoft support assist me with this - they had a pretty straight-forward way of doing it using some tools I had not seen before.

Thank you.
Duke KahanamokuIT Support Professional


Good info here - thank you for taking the time to write this!