FSLogix has been challenging for many people, especially now in the early days of WVD. This article walks you through a brief overview of FSLogix, what it is and how it works, a few things that will commonly go wrong, and finally how to troubleshoot those issues.
How it works
The understanding of the orchestration of FSlogix with profiles will make logical sense when you look at the pieces and parts that FSLogix puts together.
- FSLogix apps is an installer that is loaded on WVDSH00 and is part of every deployment done with WVDSH00
- Registry entry is configured on WVDSH00 to enable FSLogix and point the profile storage to \\FS01\Profiles\%username%
- There is another registry entry that excludes DESKTOP, DOCUMENTS and FAVORITES folders from FSLogix profile because those are redirected to \\FS01\USERS\%username% folder. This registry entry points at an XML file that tells FSLogix to exclude those folders. This file is stored in \\FS01\Profiles.
What can go wrong?
We’ve seen a number of situations that can cause FSLogix profile redirection to not work. Here is a list of the most common ones. (And you can find their fixes in the section below: "Fixes for each issue" )
- \\FS01\Profiles cannot be accessed by the user who is logging in because of permissions issues.
- \\FS01\Profiles cannot be accessed because of DNS issues as a result of Hybrid AD being enabled and users not being able to resolve FS01 (needing to resolve FS01.nerdio.int instead)
- An existing local profile prevents FSLogix from creating a new FS01 based profile and the user continues logging in with the local profile
- Profile VHD file is locked on FS01 by another user session. This can often happen when a user has a disconnected session on another session host that keeps the profile file locked but WVD connection broker places the user on another host and is unable to map the profile.
- Profile redirection is disabled for Domain Admins by default on the template, by including Domain Admins security group in the local security group on WVDSH00 that excludes users from mapping FSLogix.
How To Troubleshoot?
- There is no “local_%username%” folder in C:\users while the user is logged in. This means FSLogix isn’t working.
- The date/time on the VHD file in \\FS01\Profiles\%Username% is not current. This means FSLogix isn’t mapping properly and changes aren’t being saved.
- Event Viewier FSLogix Operations log is showing errors. Each error has a code, if you search FSLogix codes you’ll be able to easily identify what the root cause is.
- Login to FS01 and check permissions on the user's VHD file in \\FS01\Profiles\%Username%\Profile_%Username%.vhd and right click to check security permissions
Fixes For Each Issue
- This is a permissions issue and the permissions should be set back to the default.
- Update the registry entries on the pool template to point at \\FS01.nerdio.int (or whatever the Nerdio AD FQDN is). There are two registry entries to change. Set template as image and update existing hosts.
- Remove the local profiles from the session host and/or template VM. Alternatively, implement the “delete local profile when it exists” registry entry on the template so FSLogix does that automatically.
- Find the other session on another host, log it off. It’s important to do this rather than just killing the file handle since there may be a RW VHD file that needs to be merged with the main profile. If the file handle is closed without logging off, then the RW file will be discarded and some changes that user made may be lost.
- Change the configuration on the global WVDSH00 template to not exclude Domain Admins from mapping FSLogix.
From time to time, the FSLogix application on the Pool hosts or Personal desktops will need to be updated/upgraded. The context of the application in WVD and it's download of the FSLogix applications can be found at: