Azure Files Migration POC: End-to-End Implementation Runbook

Deployment assumption

This version is written for a new POC deployment. It does not include cleanup or reset steps for an earlier Azure File Sync environment.

Public-document redaction notice

All personal, tenant-specific, subscription-specific, domain-specific, IP-address, email-address, and uniquely identifying resource values have been replaced with generic placeholders. Replace placeholders only in a controlled working copy.

Contents

1. Purpose, scope, and success criteria
2. Reference architecture and placeholders
3. Phase 1 - Active Directory users and security group
4. Phase 2 - Source folders, test data, and NTFS ACLs
5. Phase 3 - Create the Azure storage account and file share
6. Phase 4 - Azure Files private endpoint and DNS validation
7. Phase 5 - Create the Storage Sync Service
8. Phase 6 - Storage Sync private endpoint validation
9. Phase 7 - Install the Azure File Sync agent
10. Phase 8 - Create the sync topology
11. Phase 9 - Validate synchronization
12. Phase 10 - Enable on-premises AD DS authentication
13. Phase 11 - Assign share-level RBAC
14. Phase 12 - Test Kerberos and ACL isolation
15. Troubleshooting guide
16. Validation checklist and evidence pack
17. Production cutover considerations
18. Appendix A - Complete command library
19. Appendix B - Portal configuration checklist

1. Purpose, scope, and success criteria

This runbook documents a complete Azure Files migration proof of concept. The POC validates two related but separate paths:

Critical distinction

Azure File Sync can be healthy even when end-user SMB mapping is not yet configured. Synchronization authentication and user SMB authentication are separate concerns.

The POC is successful when all of the following are demonstrated:

• Azure Files and Storage Sync Service private endpoints resolve to private IP addresses.
• TCP 443 succeeds from the file server to required Azure File Sync endpoints.
• TCP 445 succeeds from the domain-joined test client to the Azure Files private endpoint.
• The file server registers successfully and the server endpoint becomes healthy.
• Files, folders, and NTFS ACLs synchronize to the Azure file share.
• The storage account is configured for on-premises AD DS authentication.
• A synchronized security group receives the Storage File Data SMB Share Contributor role at file-share scope.
• Each test user maps only their own home folder using Kerberos, without a storage account key.
• Cross-user access is denied by NTFS ACLs.

2. Reference architecture and placeholders

On-premises file server
<SOURCE_PATH>
└── Home
    ├── User01
    ├── User02
    └── User03

Azure
<STORAGE_ACCOUNT> / <FILE_SHARE>
        ↑ Azure File Sync over TCP 443
<STORAGE_SYNC_SERVICE> / <SYNC_GROUP>

Direct user access
\\<STORAGE_ACCOUNT>.file.core.windows.net\<FILE_SHARE>\Home\User01

3. Phase 1 - Active Directory users and security group

Create or confirm multiple enabled domain users. Use one synchronized security group for Azure share-level RBAC, while using individual NTFS ACLs for each home folder.

Run location

Run all Active Directory cmdlets in this phase on <DOMAIN_CONTROLLER>, or another management server with the ActiveDirectory PowerShell module installed.

Import-Module ActiveDirectory

$Users = @("User01", "User02", "User03")
foreach ($User in $Users) {
    Get-ADUser -Filter "Name -eq '$User' -or SamAccountName -eq '$User'" `
        -Properties UserPrincipalName, Enabled |
        Select-Object Name, SamAccountName, UserPrincipalName, Enabled
}

For a full reset, remove and recreate the POC group only after confirming it is not used elsewhere:

# Optional clean reset of the POC group
Remove-ADGroup -Identity "<ACCESS_GROUP>" -Confirm:$true

New-ADGroup `
    -Name "<ACCESS_GROUP>" `
    -SamAccountName "<ACCESS_GROUP>" `
    -GroupCategory Security `
    -GroupScope Global `
    -Path "CN=Users,DC=<DOMAIN_COMPONENT_1>,DC=<DOMAIN_COMPONENT_2>" `
    -Description "POC users permitted to access the Azure Files share"

Add-ADGroupMember `
    -Identity "<ACCESS_GROUP>" `
    -Members "user01","user02","user03"

Get-ADGroupMember "<ACCESS_GROUP>" |
    Select-Object Name, SamAccountName, ObjectClass

Trigger a delta synchronization on the server hosting Microsoft Entra Connect:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

In Microsoft Entra ID, verify that the group source is Windows Server AD and that all expected members are visible before assigning Azure RBAC.

4. Phase 2 - Source folders, test data, and NTFS ACLs

Run location

Run this phase on <FILE_SERVER> in Windows PowerShell as Administrator.

$RootPath = "F:\Shares\POCData"
$HomePath = Join-Path $RootPath "Home"

New-Item -Path $HomePath -ItemType Directory -Force
New-Item -Path "$HomePath\User01" -ItemType Directory -Force
New-Item -Path "$HomePath\User02" -ItemType Directory -Force
New-Item -Path "$HomePath\User03" -ItemType Directory -Force

"Private test data for User01" | Set-Content "$HomePath\User01\User01-Test.txt"
"Private test data for User02" | Set-Content "$HomePath\User02\User02-Test.txt"
"Private test data for User03" | Set-Content "$HomePath\User03\User03-Test.txt"

PowerShell variable warning

Do not use $Home as a custom variable. $HOME is a built-in, read-only PowerShell variable that points to the current user profile.

Apply a controlled ACL boundary at the Home root, then individual permissions on each user folder:

$Domain = "<AD_NETBIOS>"
$HomePath = "F:\Shares\POCData\Home"

# Home root: administrators and SYSTEM retain full control;
# the common group receives read/traverse only.
icacls $HomePath /inheritance:r
icacls $HomePath /grant:r `
    "$Domain\Domain Admins:(OI)(CI)(F)" `
    "SYSTEM:(OI)(CI)(F)" `
    "$Domain\<ACCESS_GROUP>:(RX)"

# User01
icacls "$HomePath\User01" /inheritance:r
icacls "$HomePath\User01" /grant:r `
    "$Domain\user01:(OI)(CI)(M)" `
    "$Domain\Domain Admins:(OI)(CI)(F)" `
    "SYSTEM:(OI)(CI)(F)"

# User02
icacls "$HomePath\User02" /inheritance:r
icacls "$HomePath\User02" /grant:r `
    "$Domain\user02:(OI)(CI)(M)" `
    "$Domain\Domain Admins:(OI)(CI)(F)" `
    "SYSTEM:(OI)(CI)(F)"

# User03
icacls "$HomePath\User03" /inheritance:r
icacls "$HomePath\User03" /grant:r `
    "$Domain\user03:(OI)(CI)(M)" `
    "$Domain\Domain Admins:(OI)(CI)(F)" `
    "SYSTEM:(OI)(CI)(F)"

Verify the final ACLs and save the pre-migration baseline:

icacls $HomePath
icacls "$HomePath\User01"
icacls "$HomePath\User02"
icacls "$HomePath\User03"

New-Item C:\POCReports -ItemType Directory -Force
icacls "F:\Shares\POCData" `
    /save "C:\POCReports\PreMigrationACLs.txt" `
    /t /c

5. Phase 3 - Create the Azure storage account and file share in the portal

This phase creates the Azure Files destination. The portal is used so the facilitator can see and explain each platform setting.

6.1 Create the storage account

1. In the Azure portal, search for Storage accounts and select Create.

2. On Basics, select the approved subscription and the existing POC resource group.

3. Enter a globally unique storage account name using lowercase letters and numbers only.

4. Select the approved Azure region. Use the same region for the Storage Sync Service when practical.

5. Select Azure Files as the primary service when the portal presents that option.

6. Select Standard performance. For a small functional POC, choose locally redundant storage unless resiliency testing requires another option.

7. Choose the file-share billing model approved for the POC. Provisioned v2 is valid, but it bills for provisioned capacity, IOPS, and throughput rather than only consumed data.

6.2 Create the Azure Files private endpoint during storage-account deployment

1. On the Networking tab, select Disable public network access if private-only access is required.

2. Create a private endpoint targeting the storage account subresource file.

3. Select the VNet and private-endpoint subnet that are routable from the on-premises environment.

4. Enable private DNS integration and select or create the zone privatelink.file.core.windows.net.

5. Confirm the private DNS zone is linked to the VNet used by the private endpoint.

6. Complete Review + create and wait for deployment to finish.

What this does

The private endpoint allocates a private IP in the selected subnet. Clients continue using the normal <STORAGE_ACCOUNT>.file.core.windows.net hostname; DNS changes its resolution to the private endpoint.

6.3 Create the file share

1. Open the storage account and select Data storage > File shares.

2. Select + File share.

3. Enter <FILE_SHARE> as the SMB file-share name.

4. For provisioned v2, select only the capacity, IOPS, and throughput needed for the POC. The default 1 TiB is technically valid but may cost significantly more than a small POC allocation.

5. Keep SMB as the protocol and use the recommended performance settings unless the POC includes performance testing.

6. Enable backup when required. A simple daily policy and short POC retention period is sufficient for functional validation.

7. Create the share and verify that it is initially empty. Do not manually create the home folders in Azure; Azure File Sync will upload them.

6. Phase 4 - Azure Files private endpoint and DNS validation

Run location

Run these tests on <FILE_SERVER>. Repeat TCP 445 testing from the actual domain-joined end-user test client later.

nslookup <STORAGE_ACCOUNT>.file.core.windows.net
Resolve-DnsName <STORAGE_ACCOUNT>.file.core.windows.net

Test-NetConnection <STORAGE_ACCOUNT>.file.core.windows.net -Port 445
Test-NetConnection <STORAGE_ACCOUNT>.file.core.windows.net -Port 443

Expected DNS chain:

<STORAGE_ACCOUNT>.file.core.windows.net
  CNAME -> <STORAGE_ACCOUNT>.privatelink.file.core.windows.net
  A     -> <PRIVATE_ENDPOINT_IP>

Do not use ping

Azure Storage does not normally answer ICMP echo requests. Use nslookup or Resolve-DnsName for DNS, and Test-NetConnection for TCP 445 and 443.

7. Phase 5 - Create the Storage Sync Service in the portal

The Storage Sync Service is the top-level Azure File Sync resource. It contains registered servers and sync groups.

1. In the Azure portal, search for Storage Sync Services.

2. Select Create.

3. Choose the same subscription and POC resource group used for the storage account.

4. Enter <STORAGE_SYNC_SERVICE> as the service name.

5. Select the same Azure region as the Azure file share when practical.

6. On Networking, create a private endpoint during deployment when private-only connectivity is required.

7. For the private endpoint, select the Afs subresource, the approved VNet, and the private-endpoint subnet.

8. Enable private DNS integration and select or create privatelink.afs.azure.net.

9. Complete Review + create and open the deployed Storage Sync Service.

What this does

The Storage Sync Service coordinates server registration, sync groups, cloud endpoints, server endpoints, health, and synchronization metadata. Its private endpoint is separate from the Azure Files private endpoint.

8. Phase 6 - Storage Sync private endpoint and connectivity validation

The Storage Sync Service private endpoint publishes several service-specific FQDNs, commonly management, syncp, syncs, and monitoring names. The portal shows the exact names and assigned private IPs.

1. Open Storage Sync Service > Networking > Private endpoint connections.

2. Open the private endpoint and select DNS configuration.

3. Record the exact FQDNs shown. Do not invent the endpoint names.

4. For a quick check, test the management endpoint. For a comprehensive pre-agent check, test all FQDNs shown by the private endpoint.

5. After the agent is installed and the server is registered, use the Azure File Sync network diagnostic cmdlet for comprehensive validation.

# Quick check using the exact management FQDN shown in the portal
nslookup <MANAGEMENT_FQDN>
Test-NetConnection <MANAGEMENT_FQDN> -Port 443

# Optional pre-agent validation of every FQDN shown by the private endpoint
$AfsEndpoints = @(
    "<MANAGEMENT_FQDN>",
    "<SYNCP_FQDN>",
    "<SYNCS_FQDN>",
    "<MONITORING_FQDN>"
)
foreach ($Endpoint in $AfsEndpoints) {
    Test-NetConnection $Endpoint -Port 443 |
        Select-Object ComputerName, RemoteAddress, TcpTestSucceeded
}

9. Phase 7 - Install the Azure File Sync agent and register the server

Run location

Perform this phase on <FILE_SERVER> using a local or domain administrator account.

1. Open the Storage Sync Service in the Azure portal and select Registered servers.

2. Use the agent download link to obtain the installer that matches the Windows Server version.

3. Run the installer as Administrator.

4. Enable Microsoft Update when prompted so the agent receives supported updates.

5. Reboot if the installer requests it.

6. After restart, open the Azure File Sync Server Registration interface.

7. Sign in to Azure and select the correct subscription, resource group, and <STORAGE_SYNC_SERVICE>.

8. Complete registration and allow the wizard to perform network validation.

9. In the portal, confirm that <FILE_SERVER> appears under Registered servers and reports Online.

Authentication mode

Enabling storage account key access does not force Azure File Sync to use Shared Key. Current agents may register and synchronize using managed identity. This affects File Sync backend authentication only; end users still use AD DS/Kerberos.

# Confirm the agent service after installation
Get-Service FileSyncSvc

# After registration, comprehensive network test where supported
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Test-StorageSyncNetworkConnectivity

10. Phase 8 - Create the sync group, cloud endpoint, and server endpoint

11.1 Create the sync group and cloud endpoint

1. Open <STORAGE_SYNC_SERVICE> in the Azure portal.

2. Select Sync groups and then + Sync group.

3. Enter <SYNC_GROUP> as the sync-group name.

4. Select the subscription containing the Azure file share.

5. Select <STORAGE_ACCOUNT>.

6. Select the empty <FILE_SHARE>.

7. Create the sync group. The selected Azure file share becomes the cloud endpoint.

What this does

A sync group defines the synchronization relationship. It contains one cloud endpoint, representing the Azure file share, and one or more server endpoints on registered Windows servers.

11.2 Add the server endpoint

1. Open the newly created sync group.

2. Select Add server endpoint.

3. Select the registered server <FILE_SERVER>.

4. Enter <SOURCE_PATH> as the server endpoint path.

5. Set Cloud tiering to Disabled for the basic POC. This keeps full file content on the source server and removes tiering from the test variables.

6. Set Initial upload to Merge when the Azure file share is empty. Use an authoritative option only when a deliberately pre-seeded cloud share requires it.

7. Set Initial download to Avoid tiered files when that option is presented.

8. Create the server endpoint and wait for its status to move toward Healthy.

Important

The server endpoint path is the local NTFS folder, not the SMB UNC path. Azure File Sync synchronizes NTFS security descriptors, but it does not migrate the local SMB share definition into Azure RBAC.

11. Phase 9 - Validate synchronization and portal access

# Run on <FILE_SERVER> to create a fresh change
"Initial sync test $(Get-Date)" |
    Set-Content "F:\Shares\POCData\InitialSyncTest.txt"

# Review recent completed sync sessions
Get-WinEvent `
    -LogName "Microsoft-FileSync-Agent/Telemetry" `
    -MaxEvents 100 |
Where-Object Id -eq 9102 |
Select-Object -First 5 TimeCreated, Id, Message |
Format-List

A successful upload session normally includes HResult 0, no failed transfers, and no persistent upload errors. The portal may temporarily show Pending even when telemetry confirms successful synchronization.

1. Open Storage account > File shares > <FILE_SHARE> > Browse.

2. Use Microsoft Entra user account as the portal authentication method.

3. Confirm that Home and its user folders are present.

4. If the administrative account cannot browse, assign Storage File Data Privileged Reader at the file-share scope. Do not assign this privileged role to end users.

5. After the initial upload, run an on-demand backup when Azure Files backup is enabled to capture a known recovery point.

12. Phase 10 - Enable on-premises AD DS authentication with AzFilesHybrid

Run location

Run this phase on <DOMAIN_CONTROLLER> or a domain-joined management server using 64-bit Windows PowerShell 5.1 as Administrator.

13.1 Create a dedicated OU

Import-Module ActiveDirectory

Get-ADOrganizationalUnit -Filter "Name -eq 'AzureFilesPOC'" |
    Select-Object Name, DistinguishedName

# Create only when it does not exist
New-ADOrganizationalUnit `
    -Name "AzureFilesPOC" `
    -Path "DC=<DOMAIN_COMPONENT_1>,DC=<DOMAIN_COMPONENT_2>" `
    -ProtectedFromAccidentalDeletion $true

13.2 Verify PowerShell prerequisites and import AzFilesHybrid

$PSVersionTable.PSVersion
[Environment]::Is64BitProcess
Get-Module ActiveDirectory -ListAvailable
Get-Module Az.Accounts -ListAvailable
Get-Module Az.Storage -ListAvailable

Set-Location C:\AzFilesHybrid
.\CopyToPSPath.ps1
Import-Module AzFilesHybrid -Force
Get-Command Join-AzStorageAccount
Get-Command Debug-AzStorageAccountAuth

13.3 Connect to the correct Azure subscription

Connect-AzAccount

Get-AzSubscription |
    Select-Object Name, Id, TenantId, State

$Subscription = Get-AzSubscription |
    Where-Object Name -eq "<SUBSCRIPTION_NAME>"
$Subscription | Set-AzContext

Get-AzContext |
    Select-Object `
        @{Name="Account";Expression={$_.Account.Id}},
        @{Name="Subscription";Expression={$_.Subscription.Name}},
        @{Name="SubscriptionId";Expression={$_.Subscription.Id}},
        @{Name="TenantId";Expression={$_.Tenant.Id}}

Public-document rule

Never publish the real account email, subscription ID, tenant ID, or privileged administrator name. Store those values only in a secure working record.

13.4 Locate the storage account and define variables

Get-AzStorageAccount |
    Where-Object StorageAccountName -eq "<STORAGE_ACCOUNT>" |
    Select-Object StorageAccountName, ResourceGroupName, Location

$SubscriptionId       = "<SUBSCRIPTION_ID>"
$ResourceGroupName    = "<RESOURCE_GROUP>"
$StorageAccountName   = "<STORAGE_ACCOUNT>"
$OrganizationalUnitDN = "<AZURE_FILES_OU_DN>"
Set-AzContext -SubscriptionId $SubscriptionId

13.5 Check for stale AD objects and join the storage account

Get-ADObject `
    -LDAPFilter "(servicePrincipalName=cifs/$StorageAccountName.file.core.windows.net)" `
    -Properties servicePrincipalName |
    Select-Object Name, ObjectClass, DistinguishedName, ServicePrincipalName

Get-ADComputer `
    -Filter "Name -eq '$StorageAccountName'" `
    -Properties ServicePrincipalName |
    Select-Object Name, DistinguishedName, ServicePrincipalName

Join-AzStorageAccount `
    -ResourceGroupName $ResourceGroupName `
    -StorageAccountName $StorageAccountName `
    -SamAccountName $StorageAccountName `
    -DomainAccountType ComputerAccount `
    -OrganizationalUnitDistinguishedName $OrganizationalUnitDN

The join creates or configures an AD computer account representing the storage account and configures Azure Files to trust the on-premises AD DS domain.

13.6 Validate the AD object, SPN, and encryption

Get-ADComputer `
    -Identity $StorageAccountName `
    -Properties ServicePrincipalName,
                msDS-SupportedEncryptionTypes,
                DistinguishedName |
    Format-List Name,
                DistinguishedName,
                ServicePrincipalName,
                msDS-SupportedEncryptionTypes

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Expected SPN: cifs/<STORAGE_ACCOUNT>.file.core.windows.net. Confirm the diagnostic reports a healthy Azure Files authentication configuration and modern Kerberos encryption.

13. Phase 11 - Assign Azure Files share-level RBAC

Azure RBAC provides permission to enter the SMB share. NTFS ACLs then decide which directories and files the user may access.

1. In Microsoft Entra ID, confirm that <ACCESS_GROUP> is synchronized and contains the intended users.

2. Open Storage account > File shares > <FILE_SHARE> > Access control (IAM).

3. Select Add > Add role assignment.

4. Select Storage File Data SMB Share Contributor.

5. Assign the role to <ACCESS_GROUP>.

6. Use the file-share scope for least privilege.

7. Leave default share-level permission disabled unless a deliberate broad-access model is required.

8. Allow time for Azure RBAC propagation before testing.

14. Phase 12 - Test user mapping, Kerberos, and ACL isolation

15.1 Permit temporary RDP access for test users

Run location

Run these commands on <FILE_SERVER>, because Remote Desktop Users is a local group on each server.

net localgroup "Remote Desktop Users" "<AD_NETBIOS>\user01" /add
net localgroup "Remote Desktop Users" "<AD_NETBIOS>\user02" /add
net localgroup "Remote Desktop Users" "<AD_NETBIOS>\user03" /add
net localgroup "Remote Desktop Users"
gpupdate /force

If Get-LocalGroupMember is unavailable, use ADSI to inspect the actual account paths:

$Group = [ADSI]"WinNT://./Remote Desktop Users,group"
$Group.psbase.Invoke("Members") | ForEach-Object {
    $Member = $_
    [PSCustomObject]@{
        Name = $Member.GetType().InvokeMember("Name","GetProperty",$null,$Member,$null)
        Path = $Member.GetType().InvokeMember("ADsPath","GetProperty",$null,$Member,$null)
        Class = $Member.GetType().InvokeMember("Class","GetProperty",$null,$Member,$null)
    }
}

15.2 Reset a forgotten test-user password when necessary

Run location

Run password reset commands on <DOMAIN_CONTROLLER>.

Import-Module ActiveDirectory
Set-ADAccountPassword `
    -Identity "user01" `
    -Reset `
    -NewPassword (Read-Host "Enter new password" -AsSecureString)
Unlock-ADAccount -Identity "user01"
Enable-ADAccount -Identity "user01"
Set-ADUser -Identity "user01" -ChangePasswordAtLogon $false

15.3 Perform the user mapping test

Sign out completely, then sign in interactively as the domain user. Do not rely on Run as different user, because the SMB and Kerberos behavior must be tested using the user’s real logon token.

whoami
whoami /groups | findstr /i "<ACCESS_GROUP>"

nslookup <STORAGE_ACCOUNT>.file.core.windows.net
Test-NetConnection <STORAGE_ACCOUNT>.file.core.windows.net -Port 445

net use * /delete /y
klist purge
klist get cifs/<STORAGE_ACCOUNT>.file.core.windows.net
klist

net use H: \\<STORAGE_ACCOUNT>.file.core.windows.net\<FILE_SHARE>\Home\User01 /persistent:no
Get-ChildItem H:\

"Created through Azure Files: $(Get-Date)" |
    Set-Content H:\User01-Azure-Test.txt
Get-Content H:\User01-Azure-Test.txt

# Negative tests - these must fail with Access Denied
Get-ChildItem \\<STORAGE_ACCOUNT>.file.core.windows.net\<FILE_SHARE>\Home\User02
Get-ChildItem \\<STORAGE_ACCOUNT>.file.core.windows.net\<FILE_SHARE>\Home\User03

Do not use the key

Do not specify /user: and do not enter a storage account key during end-user tests. The test is intended to prove AD DS/Kerberos authentication and NTFS authorization.

15. Troubleshooting guide

16. Validation checklist and evidence pack

17. Production cutover considerations

A successful POC proves the pattern but does not by itself constitute a production migration plan. Before production cutover:

• Inventory data size, file count, long paths, unsupported files, reparse points, open files, and stale SIDs.
• Confirm backup and restore testing for both source and Azure file share.
• Allow initial synchronization to finish and resolve every persistent error.
• Validate application dependencies, drive mappings, login scripts, DFS namespace targets, and hard-coded UNC paths.
• Plan a change freeze or read-only period for final synchronization.
• Confirm the final sync backlog is zero or within an approved tolerance.
• Update user mappings to the Azure Files UNC path or a stable DFS namespace.
• Keep the old server intact and read-only for an approved rollback period.
• Monitor Kerberos, SMB authorization, performance, and support incidents.
• Remove temporary RDP permissions and test accounts when the POC closes.

Appendix A - Complete command library

This appendix consolidates the principal commands used throughout the runbook. Replace all placeholders before execution.

# ==================== DOMAIN CONTROLLER ====================
Import-Module ActiveDirectory
Get-ADUser -Filter "Name -eq 'User01'" -Properties UserPrincipalName,Enabled
Get-ADGroupMember "<ACCESS_GROUP>"
Start-ADSyncSyncCycle -PolicyType Delta

New-ADOrganizationalUnit -Name "AzureFilesPOC" `
  -Path "DC=<DOMAIN_COMPONENT_1>,DC=<DOMAIN_COMPONENT_2>" `
  -ProtectedFromAccidentalDeletion $true

Set-ADAccountPassword -Identity "user01" -Reset `
  -NewPassword (Read-Host "Enter new password" -AsSecureString)
Unlock-ADAccount -Identity "user01"

# AzFilesHybrid
Set-Location C:\AzFilesHybrid
.\CopyToPSPath.ps1
Import-Module AzFilesHybrid -Force
Connect-AzAccount
Get-AzSubscription | Select Name,Id,TenantId,State
$Subscription | Set-AzContext

Join-AzStorageAccount `
  -ResourceGroupName "<RESOURCE_GROUP>" `
  -StorageAccountName "<STORAGE_ACCOUNT>" `
  -SamAccountName "<STORAGE_ACCOUNT>" `
  -DomainAccountType ComputerAccount `
  -OrganizationalUnitDistinguishedName "<AZURE_FILES_OU_DN>"

Debug-AzStorageAccountAuth `
  -StorageAccountName "<STORAGE_ACCOUNT>" `
  -ResourceGroupName "<RESOURCE_GROUP>" -Verbose

# ==================== FILE SERVER ====================
$RootPath = "F:\Shares\POCData"
$HomePath = Join-Path $RootPath "Home"
New-Item "$HomePath\User01" -ItemType Directory -Force

icacls $HomePath /inheritance:r
icacls $HomePath /grant:r `
  "<AD_NETBIOS>\Domain Admins:(OI)(CI)(F)" `
  "SYSTEM:(OI)(CI)(F)" `
  "<AD_NETBIOS>\<ACCESS_GROUP>:(RX)"

icacls "$HomePath\User01" /inheritance:r
icacls "$HomePath\User01" /grant:r `
  "<AD_NETBIOS>\user01:(OI)(CI)(M)" `
  "<AD_NETBIOS>\Domain Admins:(OI)(CI)(F)" `
  "SYSTEM:(OI)(CI)(F)"

icacls "F:\Shares\POCData" /save "C:\POCReports\PreMigrationACLs.txt" /t /c

nslookup <STORAGE_ACCOUNT>.file.core.windows.net
Test-NetConnection <STORAGE_ACCOUNT>.file.core.windows.net -Port 445
Test-NetConnection <STORAGE_ACCOUNT>.file.core.windows.net -Port 443

Get-Service FileSyncSvc
Get-WinEvent -LogName "Microsoft-FileSync-Agent/Telemetry" -MaxEvents 100 |
  Where-Object Id -eq 9102 | Select-Object -First 5 TimeCreated,Message | Format-List

net localgroup "Remote Desktop Users" "<AD_NETBIOS>\user01" /add
gpupdate /force

# ==================== USER SESSION ====================
whoami
whoami /groups | findstr /i "<ACCESS_GROUP>"
net use * /delete /y
klist purge
klist get cifs/<STORAGE_ACCOUNT>.file.core.windows.net
net use H: \\<STORAGE_ACCOUNT>.file.core.windows.net\<FILE_SHARE>\Home\User01 /persistent:no
Get-ChildItem H:\

Appendix B - Portal configuration checklist

End state

The completed POC provides private synchronization from a Windows file server to Azure Files, preserves NTFS ACLs, enables on-premises AD DS/Kerberos authentication, and demonstrates per-user home-folder isolation without exposing storage account keys to end users.