Windows Server migration: upgrades and Storage Migration Service

Start DC01, SRV01, NODE1 and CL01. Take a snapshot of NODE1 (“Before SMS”). Work as SAATLAB\adm.rahul in PowerShell as administrator.

1Write an in-place upgrade readiness check

On SRV01, create and run this function (it works on any server you plan to upgrade):

function Test-UpgradeReady {
    $os   = Get-CimInstance Win32_OperatingSystem
    $cv   = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
    $c    = Get-CimInstance Win32_LogicalDisk -Filter "DeviceID='C:'"
    $team = @(Get-NetLbfoTeam -ErrorAction SilentlyContinue).Count
    $build = [int]$cv.CurrentBuild
    [pscustomobject]@{
        Computer      = $env:COMPUTERNAME
        Caption       = $os.Caption
        Build         = $build
        DirectTo2025  = ($build -ge 9600)
        InstallType   = $cv.InstallationType
        Evaluation    = ($os.Caption -like '*Evaluation*')
        CFreeGB       = [math]::Round($c.FreeSpace / 1GB, 1)
        EnoughSpace   = ($c.FreeSpace -gt 32GB)
        NicTeams      = $team
        IsDC          = ((Get-CimInstance Win32_ComputerSystem).DomainRole -ge 4)
    }
}
Test-UpgradeReady

You should see something like this on SRV01:

Computer     : SRV01
Caption      : Microsoft Windows Server 2025 Datacenter Evaluation
Build        : 26100
DirectTo2025 : True
InstallType  : Server
Evaluation   : True
CFreeGB      : 37.4
EnoughSpace  : True
NicTeams     : 0
IsDC         : False

Build 9600 is Server 2012 R2, the oldest version that upgrades directly to 2025. The other fields map to the rules: keep the same InstallType (Core stays Core), disable NIC teams, have space for setup, and treat DCs differently (add a new DC rather than upgrading, as most teams do). Run it with Invoke-Command across all servers to build your upgrade list.

✅ Checkpoint: Test-UpgradeReady returns a readiness object for SRV01.

2Install Storage Migration Service on NODE1

From DC01:

Invoke-Command -ComputerName NODE1 -ScriptBlock {
    Install-WindowsFeature SMS, SMS-Proxy | Select-Object Success, RestartNeeded
}

You should see something like this:

Success RestartNeeded
------- -------------
True    No

SMS is the orchestrator that runs jobs; SMS-Proxy speeds up transfers on the destination. NODE1 plays both parts here. In real projects the orchestrator is often a separate management server.

✅ Checkpoint: SMS and SMS-Proxy are installed on NODE1.

3Inventory SRV01 in Windows Admin Center

On CL01, open Windows Admin Center (https://srv01.saatlab.internal:6516), connect to NODE1 and open the Storage Migration Service tool. Choose New job, name it SRV01-Partner, source type Windows servers and clusters.

Enter SAATLAB\adm.rahul credentials, add SRV01 as the source device, and start the scan. When it finishes, SRV01’s shares appear with their sizes and paths, including Departments, Home$ and Partner.

[Add your screenshot here: SMS inventory of SRV01 shares]

✅ Checkpoint: The inventory lists SRV01’s shares with their paths and sizes.

4Transfer the Partner share to NODE1

In the job, click Next to Transfer data. Enter credentials, choose destination NODE1, and map volume D: on SRV01 to volume C: on NODE1 (SMS maps whole volumes and keeps folder paths, so the share lands in C:\Shares\Partner). Include only the Partner share, keep Retain the existing permissions on, and run Validate, then Start transfer.

When it finishes, check from DC01:

Invoke-Command -ComputerName NODE1 -ScriptBlock {
    Get-SmbShare -Name Partner | Select-Object Name, Path
    Get-ChildItem C:\Shares\Partner | Select-Object Name
    icacls C:\Shares\Partner
}

You should see something like this:

Name    Path
----    ----
Partner C:\Shares\Partner

Name
----
schedule.txt

C:\Shares\Partner NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                  BUILTIN\Administrators:(OI)(CI)(F)
                  PARTNER\GG_Partners:(OI)(CI)(M)

Successfully processed 1 files; Failed processing 0 files

The share, the file Anil wrote in Lesson 33 and its permissions, including the partner forest’s group, all arrived. In a real project you’d now run the transfer again just before the window to copy recent changes, then run the Cut over step, which renames SRV01, gives NODE1 its name and IP, and updates AD and DNS. Skip cut over in the lab, because SRV01 must keep its identity.

✅ Checkpoint: NODE1 has a Partner share with schedule.txt and the same permissions as on SRV01.

5Confirm SYSVOL uses DFS Replication

On DC01:

dfsrmig /getglobalstate
Get-SmbShare -Name SYSVOL | Select-Object Name, Path

You should see something like this:

Current DFSR global state: 'Eliminated'
Succeeded.

Name   Path
----   ----
SYSVOL C:\Windows\SYSVOL\sysvol

“Eliminated” means FRS is fully gone and SYSVOL uses DFS Replication, as expected for a domain created on Server 2025. In an old domain you’d see “Start” or no state, and you’d move through the dfsrmig states Prepared, Redirected and Eliminated before adding new DCs.

✅ Checkpoint: dfsrmig reports the global state Eliminated.