Forum Discussion

PaulH_11's avatar
PaulH_11
Copper Contributor
Mar 24, 2022
Solved

New VM, old VHDs

We need to update a file server and move it to a different datacenter. The existing VM is Windows 2008 R2 and we will be moving the data it to either a 2016 or fresh 2019 server. The data is on separate VHD (not VHDX) files. As I recall, permissions are stored as NTFS metadata directly on the disk drive itself and not registry data. So it is conceivable that I could simply copy the VHD file to the new host and attach it to a new VM thus preserving the data and NTFS permissions. The only things I would need to consider would be shares and share permissions. Is this an accurate assumption? Would there be a benefit to moving this stuff to a VHDX file?

  • PaulH_11 

     

    Hi, Paul.

     

    Not far off but not quite accurate, no.

     

    You are correct in that the permissions are stored in the file system, but those are - in database language - foreign key references to either the local security database (aka SAM) or possibly the Active Directory database if it's a domain-joined machine - those being the primary keys as it were. So, there's two halves to the portability.

     

    In the VHD, you'll have one half, but without the server to which the disk was attached, it is possible to lose the second half.

     

    I say possible because it really relates specifically to the scenario where local groups have been created on that server and then in turn applied to the file system, or similarly for local accounts created on that server. If only built-in groups have been used, or only permissions from the domain (if that applies), then those permissions are "portable" and you have nothing to worry about.

     

    If locally-defined groups or accounts have been used in the file permissions, you can still port the VHD across but any access control entries (ACEs or simply permissions) referencing those groups/users would still be present on the file system but entirely unusable by the new server, as it can't look them up in the relevant SAM. They'd show up in the permissions GUI as a SID rather than the user-friendly name.

     

    Switching topics to the merit of cutting over from VHD to VHDX, I never committed all the advantages to memory but I'll speak to two:

     

    1. VHDX permits faster I/O as it's based on a SCSI implementation rather than the old and deliberately-limited IDE implementation;
    2. VHD is not a format that's catered to with respect to any new features/enhancements/what have you.

    I would recommend cutting over as it's not a complex - particularly if you're using Server 2016 or later but that's just my opinion (not only based on the two points above, but they are worth considering.)

     

    Here's some links you can have a read of. Note, I deliberately chose the Server 2016 versions of the PowerShell commandlets as that was the earliest version you mentioned.

     

    Anyhow, best of luck with whichever approach you take.

     

    Cheers,

    Lain

     

    Hyper-V Storage I/O Performance | Microsoft Docs

    Test-VHD (Hyper-V) | Microsoft Docs

    Convert-VHD (Hyper-V) | Microsoft Docs

1 Reply

  • LainRobertson's avatar
    LainRobertson
    Silver Contributor

    PaulH_11 

     

    Hi, Paul.

     

    Not far off but not quite accurate, no.

     

    You are correct in that the permissions are stored in the file system, but those are - in database language - foreign key references to either the local security database (aka SAM) or possibly the Active Directory database if it's a domain-joined machine - those being the primary keys as it were. So, there's two halves to the portability.

     

    In the VHD, you'll have one half, but without the server to which the disk was attached, it is possible to lose the second half.

     

    I say possible because it really relates specifically to the scenario where local groups have been created on that server and then in turn applied to the file system, or similarly for local accounts created on that server. If only built-in groups have been used, or only permissions from the domain (if that applies), then those permissions are "portable" and you have nothing to worry about.

     

    If locally-defined groups or accounts have been used in the file permissions, you can still port the VHD across but any access control entries (ACEs or simply permissions) referencing those groups/users would still be present on the file system but entirely unusable by the new server, as it can't look them up in the relevant SAM. They'd show up in the permissions GUI as a SID rather than the user-friendly name.

     

    Switching topics to the merit of cutting over from VHD to VHDX, I never committed all the advantages to memory but I'll speak to two:

     

    1. VHDX permits faster I/O as it's based on a SCSI implementation rather than the old and deliberately-limited IDE implementation;
    2. VHD is not a format that's catered to with respect to any new features/enhancements/what have you.

    I would recommend cutting over as it's not a complex - particularly if you're using Server 2016 or later but that's just my opinion (not only based on the two points above, but they are worth considering.)

     

    Here's some links you can have a read of. Note, I deliberately chose the Server 2016 versions of the PowerShell commandlets as that was the earliest version you mentioned.

     

    Anyhow, best of luck with whichever approach you take.

     

    Cheers,

    Lain

     

    Hyper-V Storage I/O Performance | Microsoft Docs

    Test-VHD (Hyper-V) | Microsoft Docs

    Convert-VHD (Hyper-V) | Microsoft Docs