Advice needed on migrating shares from a 2003 DC to a new 2012: how can I avoid breaking my software install GPOs?

I've finally virtualized our entire server infrastructure and I'm ready to start migrating to our bought Windows server 2019. Since our current setup is based on Windows Server 2003 we obviously have to do the migration step via an interim installation of say 2012 R2 (AFAIK 2016 would be ok too).

My problem is the following. Our 2003 DC hosts a number of file shares. Some of them are very easy to copy over to the 2019 installation and simply change my existing GPOs to refer to the 2019 server name, instead of the 2003.

My problem resides with certain software install GPOs, for which the relevant MSI install packages do not reside on the SYSVOL, but on a share accessible as \\srv2003\installers. Obviously this will end up as \\srv2019\installers\ but how does one go from one to another? If I "modify" our GPO installation tasks to refer to the new installation paths I'll produce an installation storm over all our clients...

Can you offer any advice on how I can accomplish this task? And possibly a better way to have our GPO msi's ready for installation (in SYSVOL perhaps instead of a different share)?

EDIT: Since my question was closed and to avoid cluttering the OP with the why it should be re-opened, do check my explanation as to why this should stay around.

The first important thing to note: it is highly recommended to not use any server roles on domain controllers except for "DNS Server" and "Active Directory Domain Services".

If you were migrating from a 2003 File Server to a 2019 File Server, I would recommend using the storage migration wizard that is included with Windows Server 2019. It helps with migrating the shares and can also redirect users to the new server after the cutover from the original file server. In this case, I don't think that approach can be recommended (migrating from a domain controller).

My first inclination was to put both of these as comments instead of an answer, but at this time, it would really be the "right" solution to build a file server, copy the installation files to a new share on it (you can even use the same share name), and then edit the GPOs to replace the DC name with the new file server name in the UNC of the installer.

Since this upgrade involves an interim installation of Windows Server 2012R2 I've thought of a possible path. The caveat is that there are no margins of error whatsoever, since the entire procedure should be performed in one step. Therefore, planning should be taken to, for example, accomodate the change to DFS-R. And this entire procedure should be performed during off-hours.

Assume the current AD servers are srv1 and srv2 (Windows Server 2003R2) and that the former provides a share with the purpose of GPO-based software installation.

First backup the shares somewhere. Then introduce two (and not one, since if things go sideways we're doomed) Windows 2012R2 servers into the domain. Avoid using Server 2016 for this step, I believe it has stopped supporting FRS.

Move roles and do whatever is needed to promote one of the two new servers, transfer roles etc and then demote srv1 and srv2. Remove both 2k3 servers from the domain. Raise functional level to 2008 R2 (for example), replace FRS with DFS. Finally make two new 2019 server installations, taking care to:

• name the first with the name of the first old 2k3 server, that is srv1, and the second server as srv2
• configure the ip addresses of these two new servers to correspond to the old ones (optional step, but I'd do it just in case)

Redo the migrate path, this time from the temp servers to the new srv1 and srv2 and finally demote/remove the interim servers. Re-create shares on srv1 and populate them.

Not a super clean solution, but it will allow me to keep my install GPOs without any name-changing/re-installations.

EDIT: I've just finished this procedure. It worked flawlessly, with new client systems downloading GPO install packages. Everyone's happy!

I don't know a clean solution to your current problem. But I can offer you a hint for the future:

Use a specific name for this purpose like install.your.domain and set a DNS record to srv2019 with this name. Next time you move your install share just change this DNS record.

For your current problem something like this might be considerable:

• Make sure srv2003 is only used for this share anymore.
• Mirror the share to srv2019
• Change the DNS record for srv2003 to the IP of srv2019.
• Decommission srv2003
• Make new GPOs for fresh installed Clients and new software, use the specific name mentioned above here

As old clients get replaced or completely set up new, the usage of your old GPO reduces until it can be deleted at some point.

I agree with SturdyErde that you should avoid having file shares on your DC, but I migrated my company off SBS08 a couple of years ago, and do understand that sometimes it is what it is. A high level description of my suggested upgrade path is:

• Add the 2012 R2 server to the domain as a domain controller
• Mirror your shares
• Decommission srv2003
• Add your 2019 server to the domain
• Create a DNS alias of srv2003 that points at srv2019
• Promote 2019

There will be raising the functional domain level steps in there, but the main point is to make a DNS alias of srv2003 to point at the new shares as soon as you decommission the old server.

I also agree with SturdyErde that you should look at the storage migration wizard. I believe there's an option that renames the new server with the old server's name, but am a little nervous at the idea of doing that with a DC.

Good luck!