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.

 

How to Allow Support Users to Rename Domain Computers (Without Domain Admin Rights)

Renaming domain-joined computers is a routine IT support task — but granting Domain Admin rights just for this purpose is a security anti-pattern.

This guide explains the correct and Microsoft-supported way to allow IT support engineers to rename computers using PowerShell, without elevating them to Domain Admins, while maintaining proper security boundaries and auditability.

---

Common Misconception

“IT support engineers are already local admins on PCs, so they should be able to rename domain computers.”

❌ Incorrect

• Being a local administrator only allows changes on the local system.
• Renaming a domain-joined computer also modifies the computer object in Active Directory, which requires AD-level permissions.

---

Correct Approach (Best Practice)

✔ Delegate limited Active Directory permissions

Instead of broad admin access, we delegate only what is required:

• Rename computer objects
• Update DNS hostname
• Update Service Principal Names (SPNs)

Nothing more.

---

High-Level Design

Component	Purpose
AD Security Group	Controls who can rename computers
OU-level Delegation	Limits scope to specific computers
PowerShell Rename-Computer	Supported rename mechanism
Local Admin Rights	Required on the target PC

---

Step 1: Create a Dedicated AD Security Group

Example group name:

• IT-Support-ComputerRename

Add your IT Support User accounts to this group.

Tip: Do not assign permissions directly to users — always use a group.

---

Step 2: Delegate Computer Rename Permissions in Active Directory

1. Open Active Directory Users and Computers
2. Right-click the OU containing computer accounts
3. Select Delegate Control
4. Add the group:
   IT-Support-ComputerRename

5. Choose Create a custom task to delegate
6. Select:
   • ☑ Only the following objects in the folder
   • ☑ Computer objects
7. Permissions:
   • ☑ Read
   • ☑ Write
8. Select the following permissions:
   • ☑ Validated write to DNS host name
   • ☑ Validated write to service principal name
   • ☑ Write account restrictions

Finish the wizard.

✅ Delegation is now limited, secure, and auditable.

---

Step 3: Ensure Local Administrator Rights

IT support engineers must also be:

• Members of the Local Administrators group on the target computer
  (via GPO, Intune, or manual assignment)

This is required to execute the rename locally.

---

Step 4: PowerShell Command for Support Users

IT support engineers can now rename computers without supplying domain credentials, using their own login:

Rename-Computer -ComputerName "OLD-PC-NAME" -NewName "NEW-PC-NAME" -Force -Restart


Requirements

• Run PowerShell as Administrator
• Computer must be online and reachable
• Rename triggers an automatic reboot

---

Is -DomainCredential Required?

No, as long as:

• The support user is logged in with their support ID
• The support ID is in the delegated AD group
• PowerShell is run as Administrator

The command uses the current security context.

---

What This Design Prevents

Risk	Mitigation
Over-privileged support accounts	No Domain Admin rights
Credential leakage	No hardcoded credentials
OU-wide damage	Delegation limited to computers
SPN / DNS corruption	Validated writes only

---

Auditing & Logging

Computer rename events are logged in Domain Controller Security Logs:

• Event ID 4742 – Computer account was changed

This makes the activity fully traceable for audits.

---

Recommended Naming Controls

For production environments:

• Enforce naming standards via SOP
• Restrict delegation to specific OUs only
• Require ticket/reference number before rename
• Log changes in CMDB or asset inventory

---

Summary

✔ Local admin rights alone are not enough
✔ Delegated AD permissions are the correct solution
✔ IT support engineers can safely rename computers
✔ No Domain Admin exposure
✔ Fully auditable and compliant

---

Final Note

This approach aligns with least privilege, enterprise security, and Microsoft best practices — making it suitable for regulated and audit-driven environments.

Regards
Syed Jahanzaib