Migrating a Legacy Windows File Server

Migrating a Legacy Windows File Server (2012 R2) to Windows Server 2022
Without Breaking Users or Permissions

Author: Syed Jahanzaib
Environment: Enterprise / Large File Server (5+ TB, millions of files)

---

Background

In our environment, we had a legacy Windows Server 2012 R2 file server joined to an old SLD-based domain (OLDDOMAIN), hosting:

• ~ 5 TB of data
• Millions of files
• Thousands of SMB shares
• Very deep folder structures (path length > 256 characters)
• Users mapping shared folders as W: drive

We have already migrated users and groups to a new FQDN-based domain (NEW.DOMAIN), with a two-way trust in place. The objective was to migrate the file server to Windows Server 2022, without breaking access, without recreating thousands of shares manually, and with a clear rollback option.

Key Challenges

• NTFS permissions tied to old domain SIDs
• Thousands of existing SMB shares
• Long file paths that often fail with normal copy tools
• Very large dataset (Robocopy risk)
• Need to preserve:
  • NTFS permissions
  • Share names
  • Share-level permissions
  • Existing UNC paths

Migration Strategy (High-Level)

We used a hybrid approach:

• Symantec Backup Exec → for data + NTFS permissions
• Registry export/import → for SMB share definitions and permissions
• Server rename strategy → to keep the same hostname for users

This approach avoids:

• Manual share recreation
• Mass permission rework during cutover
• Long Robocopy execution windows

Environment Overview

Component	Old Server	New Server
OS	Windows Server 2012 R2	Windows Server 2022
Hostname	FILESERVER.OLD.DOMAIN	FILESERVER.NEW.DOMAIN
IP	192.168.10.1	10.0.0.10
Domain	OLDDOMAIN (legacy)	NEW.DOMAIN
Backup	Symantec Backup Exec 2014	Same

Important Domain Consideration (Very Critical)

Although the file server was joined to OLDDOMAIN, all folders already had:

• NEW.DOMAIN\Domain Users
• NEW.DOMAIN\Security Groups

added to NTFS permissions.

This ensures that even if OLDDOMAIN is decommissioned later, access will continue to work.

Rule:
As long as every folder has at least one valid NEW.DOMAIN permission entry, removing the old domain will NOT break access.

---

STEP-BY-STEP Migration Procedure …

Step 1 – Export SMB Shares from Old Server

On FILESERVER.OLDDOMAIN, run as Administrator:

reg export "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares" C:\Shares.reg /y
reg export "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security" C:\Shares_Security.reg /y

These exports include:

• All share names (including hidden $ shares)
• Share paths
• Share-level permissions (ACLs)

Note: Backup Exec does NOT back up SMB share definitions.

Step 2 – Final Backup and Downtime Window

• Notify users of downtime
• Stop user access (disable shares or stop LanmanServer)
• Take a final full backup using Backup Exec

Step 3 – Restore Data to New Server

On FILESERVER-new.NEW.DOMAIN:

• Restore all data using Backup Exec
• Ensure:
  • Same drive letters
  • Same folder paths
• Verify NTFS permissions on random folders

Step 4 – Rename Servers (Identity Preservation)

1. Rename old server:
2. FILESERVEROLD.DOMAIN → FILESERVER-old.OLDDOMAIN

Reboot.

1. Rename new server:
2. FILESERVER-new.NEW.DOMAIN → FILESERVER.NEW.DOMAIN

Reboot.

1. Verify DNS points to the new IP.

Step 5 – Restore SMB Shares on New Server

Copy the exported .reg files to the new server, then run:

reg import C:\Shares.reg
reg import C:\Shares_Security.reg

Restart the Server service:

net stop lanmanserver
net start lanmanserver

(or Simply Reboot)

Step 6 – Validation

Verify shares:

net share

Test from client machines:

• Existing mapped drives (W:)
• Old domain users (if any)
• New domain users (NEW.DOMAIN)
• Read / write / modify access

Why Backup Exec Instead of Robocopy?

In large environments:

• Millions of files
• Deep folder nesting
• Long path names

Robocopy may:

• Take days
• Fail on path length
• Require multiple retries

Backup Exec advantages:

• Better handling of long paths
• Preserves NTFS ACLs reliably
• Tape-based restore is stable for large datasets
• Proven rollback option

Robocopy can still be used only for validation, not primary migration.

What Happens When Old Domain Is Removed?

If OLDDOMAIN is removed later:

• Any OLDDOMAIN\* permissions become Unknown SIDs
• Access still works because NEW.DOMAIN permissions exist
• Cleanup can be done later (optional)

This avoids pressure during the migration window.

Rollback Plan (Always Have One)

If anything goes wrong:

1. Stop SMB on new server
2. Power off new server
3. Rename old server back to FILESERVER
4. Fix DNS
5. Users resume work immediately

---

Final Thoughts

This method provides:

• ✔ Zero reconfiguration for users
• ✔ Preserved permissions
• ✔ Safe rollback
• ✔ Scalable approach for very large file servers

It is a practical, production-tested approach for enterprises migrating from legacy domains and OS versions.

 

Windows RDP change Port / Disable Windows Default Shares

Modify Windows Remote Desktop Default Port 3389

Windows 10’s default RDP port has been the same for so long that many admins or normal end users already know about it.  (TCP 3389). Unfortunately, though, they aren’t the only ones. It’s typically the first one hackers try, meaning anyone with the default setting is more prone to a successful attack.

As a result, it can be well worth taking the time to change RDP port in Windows 10. It won’t radically increase your server’s security, but this small change can combines with other techniques to create a much safer experience on the whole.

To change port, Execute Powershell (Run as Admin)

Query the current port

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name "PortNumber"

• Change windows default RDP port

# CHANGE BELOW PORT TO YOUR DESIRED PORT NUMBER
$portvalue = 33389
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name "PortNumber" -Value $portvalue

Note: A system reboot is required to activate above settings.

---

Disable Windows Default Share

Windows administrative shared folders are used for remote access and computer management. Disabling them can increase security by minimum. While Windows administrative shares are convenient for managing computers remotely, they also present additional security risks. You can completely prevent Windows from creating these hidden admin shares. This will not disrupt the operation of the Windows computer used as the client but will limit its remote administration capabilities.

[Execute Powershell Terminal (CMD) as Admin]

Query Shares Information using Powershell commands…

Get-WmiObject Win32_Share | Format-Table -AutoSize

• Disable Shares via REGEDIT CMD (FOR WORKSTATION)

You can create this registry entry manually by using the reg add command:

reg add HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters /f /v AutoShareWks /t REG_DWORD /d 0

• Disable Shares via POWERSHELL CMD (FOR SERVERS OS)

Set-ItemProperty -Path "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name "AutoShareServer" -Value 0 -Type DWord

Explanation:

• AutoShareServer (for servers): Prevents automatic creation of administrative shares.

• AutoShareWks (for workstations): Same purpose but for client versions (e.g., Windows 10/11)

After running the command:

1. Restart the “Server” service or reboot the server:

   Restart-Service LanmanServer

Note: Or its better to restart the system to activate above settings.

---

 

Regard’s
Syed Jahanzaib