How bad of a idea is upgrading the "OS" partition of the file server and leaving the "data"?

Posted by ADynes@reddit | sysadmin | View on Reddit | 38 comments

Recently upgraded our host HyperV servers from 2019 to 2025 . Just moved all the existing 2019 virtual servers over as is with the intent of upgrading them over time. Our file server is one 50Gb vhdx for the OS and a 1.3Tb vhdx for the data, a single sub folder called Shares with all the different sub folders mapped to different network drives. It's a single file server and no DFS or anything fancy. So last time I did this, 3 or so years ago, I setup a new server with two new vhdx's and ran a pretty standard robocopy to copy everything over exactly as it was: robocopy D:\Shares \\CLEFS1\C$\Shares /COPYALL /E /LOG:C:\Shares\CopyLog.txt /XD "RECYCLER" "Recycled" "System Volume Information" "DfsrPrivate" "AI_RecycleBin" /XF "desktop.ini" "thumbs.db" "~*.*" /TEE Worked fine, I have two 10Gb connections for the virtuals and made sure the old file server was on one and the new on the other. Still took a while moving 2 million files that after de-dupe runs 1.1Tb. But I had a possibly stupid thought. Why can't I create a new server with just the OS then shut down the old server, disconnect the drive, and connect it to the new server? Will the dedupe mess things up? If so couldn't I just turn it off, wait until it's done, then do the switcharoo, and turn it back on the new server? I have a extra 2Tb of free space for expansion if needed. Or should I just go with the copy?

Reply to Post

38 Comments

[-]

_TheKnightMan_@reddit

No issues with that, you can even copy the 'shares' from the registry pretty easily so you don't have to recreate them by hand.

[-]

ADynes@reddit (OP)

What about the deduplication or should I turn it off, wait, and then back on the new server? I wasn't sure where it stored the index/meta data/etc.

[-]

_TheKnightMan_@reddit

[As far back as 2012](https://techcommunity.microsoft.com/blog/filecab/introduction-to-data-deduplication-in-windows-server-2012/424257) "A volume that is under deduplication control is an atomic unit. You can back up the volume and restore it to another server. You can rip it out of one Windows 2012 server and move it to another. Everything that is required to access your data is located on the drive. All of the deduplication settings are maintained on the volume and will be picked up by the deduplication filter when the volume is mounted. The only thing that is not retained on the volume are the schedule settings that are part of the task-scheduler engine. If you move the volume to a server that is not running the Data Deduplication feature, you will only be able to access the files that have not been deduplicated." So as long as you enable dedupe feature on your new server, you shouldn't need to touch the actual settings

[-]

ADynes@reddit (OP)

Thank-you. So I should just make sure I enable "Data Deduplication" under the file and storage services role BEFORE I attach the drive and I should be ok.

[-]

_TheKnightMan_@reddit

That's right!

[-]

_TheKnightMan_@reddit

Alternatively, you can 'clone' the OS disk, and do an in-place upgrade of the clone to ensure it works, then just reattach the data to that. If it's a simple server there's likely no risk to that.

[-]

_TheKnightMan_@reddit

Or if you have the space and maintenace window/downtime (would take the server 'offline / console' during the upgrade), clone the entire thing, then do the upgrade, then bring the clone online. Then you have a 'pre-upgrade' copy and a 'post-upgrade' copy, and once you're sure all is good you can delete your pre-upgrade.

[-]

ADynes@reddit (OP)

Luckily for me we're are a standard 8 - 5 shop and as long as finance isn't running end of month I can take things down for a couple hours on a Saturday or Sunday. Our file server double as a print server so I want to upgrade all the drives and rename some things anyway so I'll install fresh.

[-]

New-Seaworthiness742@reddit

This.

[-]

GhoastTypist@reddit

Virtual drives, makes migrating data so much easier.

[-]

Adam_Kearn@reddit

Yeah I’ve done this before without any issues. Moving the data VHD to a new VM works perfectly. All you need to do is republish the shares with the same name as before. The NTFS permissions will carry over. The one thing to note is keeping the IP address and name as the old server. Before you shutdown the old one I would rename it so you can create the new server with the previous name. If you want to use an alternative name you can create an alias to allow the old server name to continue to work.

[-]

ADynes@reddit (OP)

What about the deduplication? Will that mess with anything? And yea, I kinda want to keep the same name so I was going to rename the old one to "xxxFS1-Old" and change it to be 1 number off it's current IP address (which is open) then shut it down, install a new one using the original name and IP address, attach the drive, then either export out the registry from the old one for the shares or just recreate them.

[-]

Bogus1989@reddit

before you do any booting of the new server go change the DHCP reservations MAC Address to the new servers.

[-]

Adam_Kearn@reddit

One thing to remember to check is if you have a DHCP reservation somewhere as the MAC might need updating too. Personally I would just enable the shares manually but if you have quite a few then it might be best to export them and import again. I’ve done it this way at least 4-5 times now without any issues so far. I always recommend doing clean installs instead of in place upgrades.

[-]

maggotses@reddit

Why not just in-place upgrade and call this a day?

[-]

KB3080351@reddit

To me, a simple/standalone 2016+ windows file server with no other features or applications running on it is the perfect scenario for an n-place upgrade. I'm surprised more people are not advocating for it. Backup/snapshot the VM, do the upgrade, verify your file shares are accessible, and your done. In the extremely unlikely event something goes wrong, roll back the snapshot and it was like nothing happened.

[-]

Bogus1989@reddit

server 2016 was such a piece of garbage....that once they released 2019, i wasnt having any of that bullshit migrate over with it.

[-]

picklednull@reddit

True, but at the same time it's such a simple scenario for just doing a fresh install and re-attaching the data disk(s) as-is.

[-]

mnvoronin@reddit

"The solution must minimise the administrative effort" is present in almost all Microsoft exam questions. And I totally agree with them.

[-]

KB3080351@reddit

My view point is that if you are trying to choose between two methods to complete a task, and both methods provide the same result, generally I would consider the method which takes the least amount of time and/or work to be the best solution. If it is faster for you to do a swing migration, by all means have at it. But for the situation described by the OP, an in-place upgrade would appear to be both the safest and fastest method to accomplish the upgrade.

[-]

TargetFree3831@reddit

Yup. If it's a clean OS you're happy with, snapshot it, in-place upgrade it, and be done. No need to create extra work. Done tons of them and it all falls intonplace like butter. If not, revert your snapshot and do it the slow way.

[-]

maggotses@reddit

Yeah, I upgraded in-place tens of all kind of servers from 2012 R2... SQL servers, web servers, remote desktop session servers, etc, all without hiccups or problems, up to 2022...

[-]

Vivid_Mongoose_8964@reddit

same here, snap it,. run the upgrade, roll back if it blows up

[-]

SynapticStatic@reddit

It’s perfectly fine. Why would you robocopy a whole vhd instead of just moving it to the new vms folder instead?

[-]

Zaphod1620@reddit

It will absolutely work just fine. If you want to future proof later at your leisure, move that shared folder to a DFS link. Yo can keep both the original share and the new DFS link live while you migrate everyone over via DFS replication. In the future, you can swap out file servers all you want, and your shares won't be dependent on the <servername/share$> path. You just change the target of the DFS link and you are done.

[-]

Fenton296@reddit

If you are robocopying shares for a file server, include the /b switch. This is backup mode and it copies NTFS permissions, even if your account doesn't have access. [https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/preseed-dfsr-with-robocopy](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/preseed-dfsr-with-robocopy)

[-]

LebronBackinCLE@reddit

That’s why they’re separate

[-]

Vivid_Mongoose_8964@reddit

snapshot the vm and upgrade the os, easy peasy. ive been doing it that way for over 10 years now. if it blows up, you have the snap, but windows os upgrade are really smooth now. i did a ton of 2016/19 to 2022's a few months ago (all virtual) and they all went smooth, some ran veeam, sql, DC's, etc, etc. just do the upgrade.

[-]

Rivereye@reddit

I have yet to move a VHD from one VM to another personally, but I do know another engineer where I work does that quite frequently when creating new file servers. The big thing though I would look at with a 1.3TB disk is to make sure it is formatted GPT and not MBR. If you are MBR, a new file server using robocopy is a great time to get that over to GPT to allow for future growth of the drive.

[-]

ADynes@reddit (OP)

It is in fact GPT already.

[-]

Mr_ToDo@reddit

I don't really deal with them either but it might be, um, fun if you have checkpoints. I recall trying to move a drive with checkpoints being weird

[-]

ultraspacedad@reddit

as long as they are virtual drives you should be fine to update

[-]

sadmep@reddit

Unless I'm missing something, that's part of the reason people separate the data out to begin with.

[-]

Jellovator@reddit

I recently did this exact same thing with our fileservers. The OS is installed on a separate vhdx and the 2 or 3 data drives are all separate vhdx, so I installed a fresh OS on a new server, then copied the data vhdx files and attached them to the new server. Had to remap shares and ensure permissions were right, but it was relatively painless.

[-]

alpha417@reddit

....so that old HD is going to keep on going for how long?

[-]

ADynes@reddit (OP)

Sorry, I didn't make it clear we replaced the physical servers, not just upgraded the OS. Not worried about HD failure.....8 brand new 1.6Tb data center NVMe's in a RAID10.

[-]

alpha417@reddit

Oh, phew. Modern day SneakerNet.

[-]

Tech4dayz@reddit

That's the whole point of virtual drives. Just pick it up and move it to the new VM. No file transfer needed.