How do I successfully create FSLogix profiles given the following:

Question

How do I successfully create FSLogix profiles given the following:

Ashley Tym 0

For simplicity's sake, here's the CoPilot summary of my problem, it concerns an Azure Virtual Desktop setup with Azure Files running a share for my FSLogix profiles. I can map to the FSLogix drive (it shows up in "net use" but not in File Explorer) and FSLogix will not create a profile container. RBAC is fine and all recommended registry settings are in place.

Here’s a concise, end‑to‑end summary of your troubleshooting so far and where things stand now.

1) What you started with

Azure Files storage account hwgsfslogix for FSLogix profile containers.
Initially, Default share‑level permissions were disabled and you couldn’t access the share; FSLogix could not attach, no logs were produced, and user profiles stayed local (non‑persistent).

2) Issues uncovered and fixed along the way

Storage networking / firewall: A 403 in the Files blade pointed to the storage account network restrictions. You changed Public network access → Enabled (from all networks) and confirmed reachability on port 445.
Name/DNS/endpoint clarity: We verified DNS now resolves hwgsfslogix.file.core.windows.net to a public Azure Files IP and that port 445 is open from the host.
Share existence & path: After some name checks, you settled on the share FSLOGIXSMBTEST and confirmed it is reachable.
Identity & auth (Entra‑only):
- You enabled Microsoft Entra Kerberos for Azure Files (identity‑based access).
  - You assigned the correct Azure RBAC data‑plane roles (e.g., Storage File Data SMB Share Contributor/Elevated) to the users/groups.
    - Result: mapping the share now works without storage account keys and without credential prompts.
    - Transport/security posture:
      - With Secure transfer required ON, your client negotiates SMB 3.1.1 + encryption to Azure Files.
        
        You verified this with Get‑SmbConnection → Dialect = 3.1.1, Encrypted = True.
        
        Server reachability proof:
        
        You successfully mapped the share: New‑PSDrive X: \hwgsfslogix.file.core.windows.net\FSLOGIXSMBTEST -Persist

Bottom line: Networking, DNS, storage firewall, identity (Entra Kerberos), and data‑plane RBAC are now all correct and working.

3) What still isn’t working

FSLogix itself is not attaching the profile container at logon. Evidence:
- fsutil reparsepoint query C:\Users<user> → Error 4390 (not a reparse point).
  - No FSLogix Profile logs in C:\ProgramData\FSLogix\Logs\Profile.
    - frxstatus.exe not found in C:\Program Files\FSLogix\Apps.

This means the FSLogix agent installation is missing/incomplete on the AVD host. The storage side is fine; the profile engine simply isn’t running/installed, so nothing is attempting to attach or write logs.

Here’s a concise, end‑to‑end summary of your troubleshooting so far and where things stand now.

1) What you started with

Azure Files storage account hwgsfslogix for FSLogix profile containers.
Initially, Default share‑level permissions were disabled and you couldn’t access the share; FSLogix could not attach, no logs were produced, and user profiles stayed local (non‑persistent).

2) Issues uncovered and fixed along the way

Storage networking / firewall: A 403 in the Files blade pointed to the storage account network restrictions. You changed Public network access → Enabled (from all networks) and confirmed reachability on port 445.
Name/DNS/endpoint clarity: We verified DNS now resolves hwgsfslogix.file.core.windows.net to a public Azure Files IP and that port 445 is open from the host.
Share existence & path: After some name checks, you settled on the share FSLOGIXSMBTEST and confirmed it is reachable.
Identity & auth (Entra‑only):
- You enabled Microsoft Entra Kerberos for Azure Files (identity‑based access).
  - You assigned the correct Azure RBAC data‑plane roles (e.g., Storage File Data SMB Share Contributor/Elevated) to the users/groups.
    - Result: mapping the share now works without storage account keys and without credential prompts.
    - Transport/security posture:
      - With Secure transfer required ON, your client negotiates SMB 3.1.1 + encryption to Azure Files.
        
        You verified this with Get‑SmbConnection → Dialect = 3.1.1, Encrypted = True.
        
        Server reachability proof:
        
        You successfully mapped the share:
        New‑PSDrive X: \hwgsfslogix.file.core.windows.net\FSLOGIXSMBTEST -Persist

Bottom line: Networking, DNS, storage firewall, identity (Entra Kerberos), and data‑plane RBAC are now all correct and working.

3) What still isn’t working

FSLogix itself is not attaching the profile container at logon.
Evidence:
- fsutil reparsepoint query C:\Users<user> → Error 4390 (not a reparse point).
  - No FSLogix Profile logs in C:\ProgramData\FSLogix\Logs\Profile.
    - frxstatus.exe not found in C:\Program Files\FSLogix\Apps.

This means the FSLogix agent installation is missing/incomplete on the AVD host. The storage side is fine; the profile engine simply isn’t running/installed, so nothing is attempting to attach or write logs.

However: The FSLogix install is standard in my Azure Virtual Desktop deployment, and given the disk is currently ephemeral, installing/reinstalling it will do nothing.

Ankit Yadav 12,205 Reputation points Microsoft External Staff Moderator

2026-02-23T10:57:56.8166667+00:00
Hello @Ashley Tym ,

based on the analysis shared, your Azure Files configuration seems to be working as expected. Networking, DNS resolution, SMB over port 445, encryption, Microsoft Entra Kerberos authentication, and Azure RBAC permissions have all been validated and are not preventing FSLogix from working.

The next step should be to confirm whether FSLogix is actually installed and running on the session host.

If FSLogix is not present, no profile attach attempt is made, no logs are written, and profiles remain local, this observation is expected.

To verify, kindly log in to any session host and run the following checks:

Check if the FSLogix service exists

Open PowerShell and run:

Get-Service frxsvc

If the service is not found, it indicates that FSLogix is not installed.

If the service is present but stopped, profiles will not attach.

Check if the FSLogix binaries are present

Run the following command:

Test-Path "C:\Program Files\FSLogix\Apps\frxstatus.exe"

If this returns False, FSLogix is not installed on the machine.
Ankit Yadav 12,205 Reputation points Microsoft External Staff Moderator

2026-02-24T10:55:28.1066667+00:00

Hello @Ashley Tym

Checking in to see if you're still experiencing the issue. If yes, could you review the previous response and confirm whether FsLogix is installed on the AVD session hosts?
Ashley Tym 0 Reputation points

2026-02-25T00:02:09.31+00:00
To add to the above, I have uninstalled and re-installed FSLogix successfully but the problem persists. Furthermore, I have done the following (used Copilot to list the steps):

1) Initial FSLogix intent & base configuration

Goal set: Use FSLogix Profile Containers on Azure Files with Microsoft Entra (Azure AD) Kerberos, no AD DS domain controllers.

FSLogix install/verify (where applicable):

Confirmed FSLogix service present: frxsvc (Auto / Running).

Noted that FSLogix creates no config values by default—saw an empty HKLM\SOFTWARE\FSLogix\Profiles hive at first.

FSLogix standard registry configuration (target state) discussed/applied:

HKLM\SOFTWARE\FSLogix\Profiles\Enabled=1 (DWORD)

HKLM\SOFTWARE\FSLogix\Profiles\VHDLocations="\\<storage>.file.core.windows.net\<profiles-share>" (REG_SZ)

Recommended values applied/queued:
- `VolumeType="VHDX" (REG_SZ)` - `IsDynamic=1`, `DeleteLocalProfileWhenVHDShouldApply=1` (DWORD) - Usability/HA timings: `LockedRetryCount=3`, `LockedRetryInterval=15`, `ReAttachRetryCount=3`, `ReAttachIntervalSeconds=15` (DWORD) - Optional: `FlipFlopProfileDirectoryName=1` (DWORD), `RoamSearch=2` if needed.

2) Entra‑only authentication prerequisites (client side)

Entra join confirmed: Ran dsregcmd /status and saw:

AzureAdJoined : YES

(DomainJoined : NO)

Client switches for cloud Kerberos retrieval added (multiple times to ensure persistence):

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\CloudKerberosTicketRetrievalEnabled=1 (DWORD)

HKLM\SOFTWARE\Policies\Microsoft\AzureADAccount\LoadCredKeyFromProfile=1 (DWORD)

3) Storage-side identity checks (Azure Files)

Target: Enable Microsoft Entra Kerberos on the storage account (File shares → Identity-based access).

RBAC plan/assignment clarified: On the file share scope (not only at storage account):

Storage File Data SMB Share Contributor → FSLogix users.

Storage File Data SMB Share Elevated Contributor → admins.

Understanding: Without these, Azure Files won’t issue/authorize Kerberos tickets and the client will fall back to AD DS—leading to the “cannot contact domain controller” errors during FSLogix attach.

4) First attach failures & diagnostic errors from FSLogix

FSLogix error dialog (multiple times):

“The user profile failed to attach. Cannot retrieve virtual disk location.”

Error code 0x000004F1: “The system cannot contact a domain controller…”

Interpreted as: the host is falling back to AD auth (because Entra Kerberos ticket wasn’t obtained), but no DC exists, so attach fails.

ODFC parallel failures mirrored the same “cannot retrieve VHD” with DC messages.

5) Turning off FSLogix’s “block login on failure” (to keep working)

Removed (or planned to remove) the two enforcement keys so users can sign in even if FSLogix fails:

HKLM\SOFTWARE\FSLogix\Profiles\PreventLoginWithFailure (delete)

HKLM\SOFTWARE\FSLogix\Profiles\PreventLoginWithTempProfile (delete)

This restored logon during troubleshooting, while focusing on identity & storage fixes.

6) Testing Kerberos & SMB from the host (first rounds)

Kerberos ticket requests attempted:

klist purge

klist get cifs/<storage>.file.core.windows.net

Observed failures:

0x5aa / 0xc000009a (Insufficient resources / substatus 0x5aa) when storage wasn’t issuing tickets yet (early stage).

0x8009030e (No credentials are available in the security package) when running as local admin (no Entra PRT in that session).

SMB test:

net use * "\\<storage>.file.core.windows.net\<share>"

Mapped only when credentials were prompted (or failed), indicating Entra Kerberos wasn’t active; should map without prompting when Kerberos is working.

7) Serial Console (SAC) route to attempt a “local” interactive logon

Enabled/checked Boot Diagnostics to expose Serial Console.

Entered SAC>; created a CMD channel (cmd then ch -si <n>).

Attempted authentication in SAC with local accounts using .\username:

Saw repeated “Unable to authenticate” messages even with known-good passwords.

Noted SAC quirks (no backspace, channel closes on failed auth).

Tried tsdiscon to flip to console logon UI:

No visible effect from SAC (expected behavior if not running in a fully authenticated CMD session).

Conclusion: SAC can be finicky for Windows interactive flows; also, even a successful local account sign-in wouldn’t yield an Entra PRT, so no CIFS ticket anyway.

8) Bastion deployment & connection attempts

Deployed Azure Bastion (Standard SKU) into AzureBastionSubnet (/26); enabled Native client support.

First try of “Bastion native client” (CLI) from a non‑Windows machine:

Got Python ctypes WinDLL import error, confirming the native RDP client command must run on Windows (it launches mstsc.exe).

Switched to Bastion in the portal (browser RDP):

Encountered “remote server exception” and timeouts; suspected NSG/SKU prerequisites.

NSG fix (VM NIC / VM subnet): Added Inbound Allow TCP 3389 from VirtualNetwork (or Bastion subnet CIDR) so Bastion → VM RDP is allowed over private IP.

Validated Bastion connection again:

Success—connected and logged in as local admin (first) to complete host-side settings and gather data.

9) VM sign‑in method clarification (the critical distinction)

Recognized the difference between:

Local account sign‑in (no Entra PRT → can’t request cloud Kerberos/CIFS tickets).

Microsoft Entra (UPN) sign‑in to the VM (yields AzureAdPrt : YES in dsregcmd /status if prerequisites satisfied).

VM Entra sign‑in prerequisites validated/queued:

AADLoginForWindows extension status = Provisioning succeeded.

RBAC role on VM: Virtual Machine User Login (or Virtual Machine Administrator Login) assigned to your user (or to a group you belong to).

Use UPN (******@hartwigs.com.au) at Bastion prompt; not AzureAD\user.

10) Re-running dsregcmd & understanding NGC / cloud Kerberos state

After local admin sign‑in: dsregcmd /status showed:

SessionIsNotRemote : NO

DeviceEligible : NO

PreReqResult : WillNotProvision

Meaning: That session will not provision cloud Kerberos. It has no Entra PRT and/or the “allow cloud Kerberos retrieval during logon” policy is not applied to the Entra session.

Target state (when signed in with Entra user):

AzureAdPrt : YES (under SSO State)

SessionIsNotRemote : YES (or at least policy applied)

DeviceEligible : YES

PreReqResult : Success

11) Re-affirmed the two client switches & sign-in policy

Re-applied registry keys (idempotent):

CloudKerberosTicketRetrievalEnabled=1

LoadCredKeyFromProfile=1

Noted Intune Settings Catalog equivalent exists for Kerberos → “Allow retrieving the cloud Kerberos ticket during the logon” (supported on Windows multi‑session) if you want to push it centrally.

12) Attempted Kerberos again (still under local admin session)

Ran:

klist purge

klist get cifs/hwgsfslogix.file.core.windows.net

Observed: 0x8009030e (No credentials are available in the security package).

Root cause: still logged in as local; need Entra UPN logon to obtain a PRT.

13) Next actions performed/queued to complete the identity flow

Plan / action to sign in via Bastion using Entra UPN once:

Confirm AADLoginForWindows shows Provisioning succeeded.

Ensure your user (or group) has VM User/Administrator Login role on the VM.

Use UPN to sign in via Bastion; verify AzureAdPrt : YES (dsregcmd /status).

Then re-run:

klist purge

klist get cifs/<storage>.file.core.windows.net → expect a successful CIFS ticket.

net use * "\\<storage>.file.core.windows.net\<profileshare>" → no prompt if Kerberos works.

14) FSLogix test points & logging

With Kerberos working, FSLogix should mount automatically at sign‑in.

Where you looked (or will look):

C:\ProgramData\FSLogix\Logs\Profile\*Profile*.log for “Loaded profile successfully”.

On the share: new \<SID>_<username> directory and VHDX file creation.

If attach still fails, you checked/understood typical log patterns:

Access denied, file locked, cannot retrieve VHD location → storage identity/RBAC or path issues.

(Optional toggle during testing) You removed the logon‑blocking keys so users can sign in even if attach fails; plan to re‑enable once stable.

15) Networking & Bastion hygiene you applied

VM-side NSG rule added:

Inbound TCP 3389 from VirtualNetwork (or from Bastion subnet CIDR) → allows Bastion to reach VM over private IP; prevents client connection timed out.

Bastion subnet best practice confirmed:

No need for 3389 inbound on AzureBastionSubnet; ensure required 443/8080/5701 control/data-plane rules if an NSG is attached to that subnet.

Bastion native client attempt from non‑Windows host diagnosed and resolved by using Windows to launch mstsc (or by using a Bastion tunnel + mstsc).

16) What blocked progress so far (root causes confirmed)

Entra Kerberos tickets were never issued because the Windows session used for testing was a local account, so:

No Entra PRT in that session → klist get cifs/... returned No credentials available.

FSLogix fell back to AD DS → “cannot contact a domain controller” → attach failed.

Storage must also be correct (identity-based access enabled & RBAC set on the share). Without it, even with an Entra session + client switches, klist get/net use will still fail or prompt.

TL;DR—your current state

You’ve put all the right pieces on the host (FSLogix config, client keys, Entra join) and you’ve enabled Bastion + NSGs so you can reach the VM reliably.

The missing link to make Kerberos/FSLogix snap into place is: perform one interactive sign‑in on the VM using your Entra UPN (with AADLoginForWindows healthy and the VM login RBAC role assigned), then re-run dsregcmd /status to confirm AzureAdPrt : YES and immediately test klist get cifs/.... After that, FSLogix will attach.
1) Initial FSLogix intent & base configuration

Goal set: Use FSLogix Profile Containers on Azure Files with Microsoft Entra (Azure AD) Kerberos, no AD DS domain controllers.

FSLogix install/verify (where applicable):

Confirmed FSLogix service present: frxsvc (Auto / Running).

Noted that FSLogix creates no config values by default—saw an empty HKLM\SOFTWARE\FSLogix\Profiles hive at first.

FSLogix standard registry configuration (target state) discussed/applied:

HKLM\SOFTWARE\FSLogix\Profiles\Enabled=1 (DWORD)

HKLM\SOFTWARE\FSLogix\Profiles\VHDLocations="\\<storage>.file.core.windows.net\<profiles-share>" (REG_SZ)

Recommended values applied/queued:

VolumeType="VHDX" (REG_SZ)

IsDynamic=1, DeleteLocalProfileWhenVHDShouldApply=1 (DWORD)

Usability/HA timings: LockedRetryCount=3, LockedRetryInterval=15, ReAttachRetryCount=3, ReAttachIntervalSeconds=15 (DWORD)

Optional: FlipFlopProfileDirectoryName=1 (DWORD), RoamSearch=2 if needed.

2) Entra‑only authentication prerequisites (client side)

Entra join confirmed: Ran dsregcmd /status and saw:

AzureAdJoined : YES

(DomainJoined : NO)

Client switches for cloud Kerberos retrieval added (multiple times to ensure persistence):

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\CloudKerberosTicketRetrievalEnabled=1 (DWORD)

HKLM\SOFTWARE\Policies\Microsoft\AzureADAccount\LoadCredKeyFromProfile=1 (DWORD)

3) Storage-side identity checks (Azure Files)

Target: Enable Microsoft Entra Kerberos on the storage account (File shares → Identity-based access).

RBAC plan/assignment clarified: On the file share scope (not only at storage account):

Storage File Data SMB Share Contributor → FSLogix users.

Storage File Data SMB Share Elevated Contributor → admins.

Understanding: Without these, Azure Files won’t issue/authorize Kerberos tickets and the client will fall back to AD DS—leading to the “cannot contact domain controller” errors during FSLogix attach.

4) First attach failures & diagnostic errors from FSLogix

FSLogix error dialog (multiple times):

“The user profile failed to attach. Cannot retrieve virtual disk location.”

Error code 0x000004F1: “The system cannot contact a domain controller…”

Interpreted as: the host is falling back to AD auth (because Entra Kerberos ticket wasn’t obtained), but no DC exists, so attach fails.

ODFC parallel failures mirrored the same “cannot retrieve VHD” with DC messages.

5) Turning off FSLogix’s “block login on failure” (to keep working)

Removed (or planned to remove) the two enforcement keys so users can sign in even if FSLogix fails:

HKLM\SOFTWARE\FSLogix\Profiles\PreventLoginWithFailure (delete)

HKLM\SOFTWARE\FSLogix\Profiles\PreventLoginWithTempProfile (delete)

This restored logon during troubleshooting, while focusing on identity & storage fixes.

6) Testing Kerberos & SMB from the host (first rounds)

Kerberos ticket requests attempted:

klist purge

klist get cifs/<storage>.file.core.windows.net

Observed failures:

0x5aa / 0xc000009a (Insufficient resources / substatus 0x5aa) when storage wasn’t issuing tickets yet (early stage).

0x8009030e (No credentials are available in the security package) when running as local admin (no Entra PRT in that session).

SMB test:

net use * "\\<storage>.file.core.windows.net\<share>"

Mapped only when credentials were prompted (or failed), indicating Entra Kerberos wasn’t active; should map without prompting when Kerberos is working.

7) Serial Console (SAC) route to attempt a “local” interactive logon

Enabled/checked Boot Diagnostics to expose Serial Console.

Entered SAC>; created a CMD channel (cmd then ch -si <n>).

Attempted authentication in SAC with local accounts using .\username:

Saw repeated “Unable to authenticate” messages even with known-good passwords.

Noted SAC quirks (no backspace, channel closes on failed auth).

Tried tsdiscon to flip to console logon UI:

No visible effect from SAC (expected behavior if not running in a fully authenticated CMD session).

Conclusion: SAC can be finicky for Windows interactive flows; also, even a successful local account sign-in wouldn’t yield an Entra PRT, so no CIFS ticket anyway.

8) Bastion deployment & connection attempts

Deployed Azure Bastion (Standard SKU) into AzureBastionSubnet (/26); enabled Native client support.

First try of “Bastion native client” (CLI) from a non‑Windows machine:

Got Python ctypes WinDLL import error, confirming the native RDP client command must run on Windows (it launches mstsc.exe).

Switched to Bastion in the portal (browser RDP):

Encountered “remote server exception” and timeouts; suspected NSG/SKU prerequisites.

NSG fix (VM NIC / VM subnet): Added Inbound Allow TCP 3389 from VirtualNetwork (or Bastion subnet CIDR) so Bastion → VM RDP is allowed over private IP.

Validated Bastion connection again:

Success—connected and logged in as local admin (first) to complete host-side settings and gather data.

9) VM sign‑in method clarification (the critical distinction)

Recognized the difference between:

Local account sign‑in (no Entra PRT → can’t request cloud Kerberos/CIFS tickets).

Microsoft Entra (UPN) sign‑in to the VM (yields AzureAdPrt : YES in dsregcmd /status if prerequisites satisfied).

VM Entra sign‑in prerequisites validated/queued:

AADLoginForWindows extension status = Provisioning succeeded.

RBAC role on VM: Virtual Machine User Login (or Virtual Machine Administrator Login) assigned to your user (or to a group you belong to).

Use UPN (******@hartwigs.com.au) at Bastion prompt; not AzureAD\user.

10) Re-running dsregcmd & understanding NGC / cloud Kerberos state

After local admin sign‑in: dsregcmd /status showed:

SessionIsNotRemote : NO

DeviceEligible : NO

PreReqResult : WillNotProvision

Meaning: That session will not provision cloud Kerberos. It has no Entra PRT and/or the “allow cloud Kerberos retrieval during logon” policy is not applied to the Entra session.

Target state (when signed in with Entra user):

AzureAdPrt : YES (under SSO State)

SessionIsNotRemote : YES (or at least policy applied)

DeviceEligible : YES

PreReqResult : Success

11) Re-affirmed the two client switches & sign-in policy

Re-applied registry keys (idempotent):

CloudKerberosTicketRetrievalEnabled=1

LoadCredKeyFromProfile=1

Noted Intune Settings Catalog equivalent exists for Kerberos → “Allow retrieving the cloud Kerberos ticket during the logon” (supported on Windows multi‑session) if you want to push it centrally.

12) Attempted Kerberos again (still under local admin session)

Ran:

klist purge

klist get cifs/hwgsfslogix.file.core.windows.net

Observed: 0x8009030e (No credentials are available in the security package).

Root cause: still logged in as local; need Entra UPN logon to obtain a PRT.

13) Next actions performed/queued to complete the identity flow

Plan / action to sign in via Bastion using Entra UPN once:

Confirm AADLoginForWindows shows Provisioning succeeded.

Ensure your user (or group) has VM User/Administrator Login role on the VM.

Use UPN to sign in via Bastion; verify AzureAdPrt : YES (dsregcmd /status).

Then re-run:

klist purge

klist get cifs/<storage>.file.core.windows.net → expect a successful CIFS ticket.

net use * "\\<storage>.file.core.windows.net\<profileshare>" → no prompt if Kerberos works.

14) FSLogix test points & logging

With Kerberos working, FSLogix should mount automatically at sign‑in.

Where you looked (or will look):

C:\ProgramData\FSLogix\Logs\Profile\*Profile*.log for “Loaded profile successfully”.

On the share: new \<SID>_<username> directory and VHDX file creation.

If attach still fails, you checked/understood typical log patterns:

Access denied, file locked, cannot retrieve VHD location → storage identity/RBAC or path issues.

(Optional toggle during testing) You removed the logon‑blocking keys so users can sign in even if attach fails; plan to re‑enable once stable.

15) Networking & Bastion hygiene you applied

VM-side NSG rule added:

Inbound TCP 3389 from VirtualNetwork (or from Bastion subnet CIDR) → allows Bastion to reach VM over private IP; prevents client connection timed out.

Bastion subnet best practice confirmed:

No need for 3389 inbound on AzureBastionSubnet; ensure required 443/8080/5701 control/data-plane rules if an NSG is attached to that subnet.

Bastion native client attempt from non‑Windows host diagnosed and resolved by using Windows to launch mstsc (or by using a Bastion tunnel + mstsc).

16) What blocked progress so far (root causes confirmed)

Entra Kerberos tickets were never issued because the Windows session used for testing was a local account, so:

No Entra PRT in that session → klist get cifs/... returned No credentials available.

FSLogix fell back to AD DS → “cannot contact a domain controller” → attach failed.

Storage must also be correct (identity-based access enabled & RBAC set on the share). Without it, even with an Entra session + client switches, klist get/net use will still fail or prompt.

TL;DR—your current state

You’ve put all the right pieces on the host (FSLogix config, client keys, Entra join) and you’ve enabled Bastion + NSGs so you can reach the VM reliably.

The missing link to make Kerberos/FSLogix snap into place is:
perform one interactive sign‑in on the VM using your Entra UPN (with AADLoginForWindows healthy and the VM login RBAC role assigned), then re-run dsregcmd /status to confirm AzureAdPrt : YES and immediately test klist get cifs/.... After that, FSLogix will attach.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Ankit Yadav 12,205 Reputation points Microsoft External Staff Moderator

2026-02-26T10:36:27.62+00:00
Hello @Ashley Tym

Can you please confirm if you validated these steps too:

Confirm that you are signed in with your Entra UPN and that a PRT has been issued

Sign in correctly

Connect to the virtual machine using Bastion or RDP. At the Windows sign-in screen, enter your Entra UPN, for example ******@yourdomain.com {do not sign in using a local account like .\username, and do not use AzureAD\username}.

Verify the Entra authentication state:

Open Command Prompt or PowerShell. You do not need to run it as administrator.

Run: dsregcmd /status

In the output, look for the following key values: AzureAdJoined : YES
AzureAdPrt : YES

Under User State or SSO State, you should also see: PreReqResult : Success
DeviceEligible : YES

*If AzureAdPrt shows NO, it means the session is not authenticated with Microsoft Entra ID. FSLogix and Entra Kerberos will not work without a Primary Refresh Token.
*In that case, review your sign-in method and confirm the VM login RBAC assignments before moving forward. Do not continue until AzureAdPrt shows YES.

Confirm that a CIFS Kerberos ticket for Azure Files:-

Clear any existing Kerberos tickets

In PowerShell, run: klist purge

Request a CIFS ticket for Azure Files

Run: klist get cifs/.file.core.windows.net

**
Expected result**: The command completes without prompting for credentials. No errors are returned. A ticket is added to the Kerberos cache. To confirm, run: klist Look for a ticket entry similar to: Server: cifs/.file.core.windows.net If you see that entry, it confirms that the CIFS Kerberos ticket was successfully issued for Azure Files.

Note: Make sure every command below is run in the same interactive Windows session. That session must be signed in with a Microsoft Entra user principal name, such as ******@contoso.com. Do not run these steps from a local account session.
Ankit Yadav 12,205 Reputation points Microsoft External Staff Moderator

2026-02-27T06:37:51.8133333+00:00

Hello @Ashley Tym

Good day!

Just checking in if you are still blocked with the issue, if yes, can you please review my earlier shared response and test it out.

1 answer

Your answer

Ankit Yadav 12,205 Reputation points Microsoft External Staff Moderator

2026-02-23T10:57:56.8166667+00:00

Hello @Ashley Tym ,

based on the analysis shared, your Azure Files configuration seems to be working as expected. Networking, DNS resolution, SMB over port 445, encryption, Microsoft Entra Kerberos authentication, and Azure RBAC permissions have all been validated and are not preventing FSLogix from working.

The next step should be to confirm whether FSLogix is actually installed and running on the session host.

If FSLogix is not present, no profile attach attempt is made, no logs are written, and profiles remain local, this observation is expected.

To verify, kindly log in to any session host and run the following checks:

Check if the FSLogix service exists

Open PowerShell and run:

Get-Service frxsvc

If the service is not found, it indicates that FSLogix is not installed.

If the service is present but stopped, profiles will not attach.

Check if the FSLogix binaries are present

Run the following command:

Test-Path "C:\Program Files\FSLogix\Apps\frxstatus.exe"

If this returns False, FSLogix is not installed on the machine.
Ankit Yadav 12,205 Reputation points Microsoft External Staff Moderator

2026-02-24T10:55:28.1066667+00:00

Hello @Ashley Tym

Checking in to see if you're still experiencing the issue. If yes, could you review the previous response and confirm whether FsLogix is installed on the AVD session hosts?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Ankit Yadav 12,205 Reputation points Microsoft External Staff Moderator

2026-02-26T10:36:27.62+00:00

Hello @Ashley Tym

Can you please confirm if you validated these steps too:

Confirm that you are signed in with your Entra UPN and that a PRT has been issued

Sign in correctly

Connect to the virtual machine using Bastion or RDP. At the Windows sign-in screen, enter your Entra UPN, for example ******@yourdomain.com {do not sign in using a local account like .\username, and do not use AzureAD\username}.

Verify the Entra authentication state:

Open Command Prompt or PowerShell. You do not need to run it as administrator.

Run: dsregcmd /status

In the output, look for the following key values: AzureAdJoined : YES
AzureAdPrt : YES

Under User State or SSO State, you should also see: PreReqResult : Success
DeviceEligible : YES

*If AzureAdPrt shows NO, it means the session is not authenticated with Microsoft Entra ID. FSLogix and Entra Kerberos will not work without a Primary Refresh Token.
*In that case, review your sign-in method and confirm the VM login RBAC assignments before moving forward. Do not continue until AzureAdPrt shows YES.

Confirm that a CIFS Kerberos ticket for Azure Files:-

Clear any existing Kerberos tickets

In PowerShell, run: klist purge

Request a CIFS ticket for Azure Files

Run: klist get cifs/.file.core.windows.net

**
Expected result**: The command completes without prompting for credentials. No errors are returned. A ticket is added to the Kerberos cache. To confirm, run: klist Look for a ticket entry similar to: Server: cifs/.file.core.windows.net If you see that entry, it confirms that the CIFS Kerberos ticket was successfully issued for Azure Files.

Note: Make sure every command below is run in the same interactive Windows session. That session must be signed in with a Microsoft Entra user principal name, such as ******@contoso.com. Do not run these steps from a local account session.
Ankit Yadav 12,205 Reputation points Microsoft External Staff Moderator

2026-02-27T06:37:51.8133333+00:00

Hello @Ashley Tym

Good day!

Just checking in if you are still blocked with the issue, if yes, can you please review my earlier shared response and test it out.

Answer 1

To successfully create FSLogix profiles in your Azure Virtual Desktop setup with Azure Files, follow these steps based on your current troubleshooting status:

Verify FSLogix Installation: Since you mentioned that the FSLogix agent installation is missing or incomplete, ensure that FSLogix is properly installed on your Azure Virtual Desktop (AVD) host. You can do this by checking if the FSLogix installation files exist in C:\Program Files\FSLogix\Apps\. If they are missing, you will need to install or reinstall FSLogix on the AVD host.
Check Registry Settings: Ensure that the necessary registry settings for FSLogix profile containers are correctly configured. You should have the following settings in HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles:
- Enabled (DWORD) set to 1
- VHDLocations (MULTI_SZ or REG_SZ) pointing to your Azure Files share (e.g., \\hwgsfslogix.file.core.windows.net\FSLOGIXSMBTEST)
- DeleteLocalProfileWhenVHDShouldApply (DWORD) set to 1 (recommended)
Test User Sign-In: After confirming the installation and registry settings, test the user sign-in process. When a user logs in, they should see the message "Please wait for the FSLogix Apps Services". If this message does not appear, it indicates that the FSLogix service is not starting correctly.
Check Logs: If the profiles are still not being created, check the logs in C:\ProgramData\FSLogix\Logs\Profile\ for any errors that may provide insight into what is failing during the profile attachment process.
Network and Permissions: Since you've already verified network access and permissions, ensure that the user accounts have the correct Azure RBAC roles assigned to access the Azure Files share. The roles should include Storage File Data SMB Share Contributor or Elevated.
Secure Transfer: Make sure that the secure transfer is enabled for your Azure Files storage account, as this is necessary for the FSLogix service to communicate securely with Azure Files.

By ensuring that FSLogix is installed correctly, the registry settings are configured, and the user sign-in process is functioning as expected, you should be able to successfully create FSLogix profiles in your Azure Virtual Desktop environment.

References:

Share via

How do I successfully create FSLogix profiles given the following:

1) Initial FSLogix intent & base configuration

2) Entra‑only authentication prerequisites (client side)

3) Storage-side identity checks (Azure Files)

4) First attach failures & diagnostic errors from FSLogix

5) Turning off FSLogix’s “block login on failure” (to keep working)

6) Testing Kerberos & SMB from the host (first rounds)

7) Serial Console (SAC) route to attempt a “local” interactive logon

8) Bastion deployment & connection attempts

9) VM sign‑in method clarification (the critical distinction)

10) Re-running dsregcmd & understanding NGC / cloud Kerberos state

11) Re-affirmed the two client switches & sign-in policy

12) Attempted Kerberos again (still under local admin session)

13) Next actions performed/queued to complete the identity flow

14) FSLogix test points & logging

15) Networking & Bastion hygiene you applied

16) What blocked progress so far (root causes confirmed)

TL;DR—your current state

1) Initial FSLogix intent & base configuration

2) Entra‑only authentication prerequisites (client side)

3) Storage-side identity checks (Azure Files)

4) First attach failures & diagnostic errors from FSLogix

5) Turning off FSLogix’s “block login on failure” (to keep working)

6) Testing Kerberos & SMB from the host (first rounds)

7) Serial Console (SAC) route to attempt a “local” interactive logon

8) Bastion deployment & connection attempts

9) VM sign‑in method clarification (the critical distinction)

10) Re-running dsregcmd & understanding NGC / cloud Kerberos state

11) Re-affirmed the two client switches & sign-in policy

12) Attempted Kerberos again (still under local admin session)

13) Next actions performed/queued to complete the identity flow

14) FSLogix test points & logging

15) Networking & Bastion hygiene you applied

16) What blocked progress so far (root causes confirmed)

TL;DR—your current state

1 answer

Your answer