2

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.

Improve this question
0

4 Answers 4

Reset to default
3

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!

Improve this answer
2

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.

Improve this answer
6
  • Unfortunately I lack the $$$ (EDIT: and time to tender a purchase procedure) to purchase another 2019 server (as it is I've got two, to replace the two 2k3 servers). I'll go to 2019 gradually, but using a 2012R2 trial as an intermediate step. My bottomline is that unfortunately I'll have to actually attach a file server role to one of my DCs. Now, I do not know if 2012R2 offers a similar share migration. Considering my constraints, would you believe that migrating from the 2k3 file server to a 2012 file server is viable and possibly recommended?
    – carmik
    Commented Jun 28, 2021 at 13:33
  • Furthermore, would your last sentence indicate that it would be feasible to somehow magically modify my install GPOs to point to the new UNC without causing a re-install/redeploy storm?
    – carmik
    Commented Jun 28, 2021 at 13:34
  • You could certainly use a 2012R2 trial as an intermediate step--but for that matter, you could also use a 2019 trial as an even better intermediate step! You'll get more file server features, better security, and potentially a better running server. Any reason to use 2012R2 in particular? (I can't think of one.)
    – Sam Erde
    Commented Jun 28, 2021 at 14:18
  • Your second question is an insightful one, and something that you'd want to test and/or check documentation about. Worth testing with one (or a few) for sure.
    – Sam Erde
    Commented Jun 28, 2021 at 14:20
  • 1
    Since my domain is at a 2003 functional level, I can think of two: the minimum functional level for a Server 2019 is the server 2008 functional level which, alone, would prohibit joining a 2019 server to this domain. Hence one has to join a 2008/2012/2016 server and after moving roles and demoting the 2k3 servers he would raise the functional level and only afterwards he would introduce 2019 servers. The other reason is that 2019 uses DFS-R link
    – carmik
    Commented Jun 29, 2021 at 4:51
1

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!

Improve this answer
0

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.

Improve this answer
5
  • First, a clarification: as I've noted in the OP I'll be using Server 2012R2 as an interim step, since a direct migration of my 2003-based AD to 2019 is not possible for a variety of reasons. I believe I have tried adding a CNAME pointing to the actual A address record of my current 2k3 server, but connection to the CNAME fails. I believe the SMB internals do not like connecting to a well known ip address with another name.
    – carmik
    Commented Jun 28, 2021 at 13:25
  • You would need to demote the FSMO roles from srv2003, take it out of the domain and then add the CNAME.
    – Manu
    Commented Jun 28, 2021 at 13:32
  • 1
    OP is likely to have unexpected future results if changing an old domain controller's A record to be a CNAME for a file server.
    – Sam Erde
    Commented Jun 29, 2021 at 17:50
  • 1
    @carmik fyi; to make that work you need to play with the registry DisableStrictNameChecking for the LanmanService
    – yagmoth555 ♦
    Commented Jul 2, 2021 at 1:48
  • @yagmoth555 I didn't know about that. And a quick search brought up this technet article. Will test and report back.
    – carmik
    Commented Jul 2, 2021 at 5:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .