FSLogix Profile Container technology is an evolution of the previous User Profile Disk (UPD) model offered by Microsoft Remote Desktop Services. As the name implies, Profile Containers "containerize" a user's profile into a single file (VHD virtual disk), which can then be mounted on any host computer that a user logs on to. The technology behind Profiles Containers is faster, more reliable, and works outside of Remote Desktop Services, eliminating some restrictions imposed by UPD. There are times, however, when troubleshooting has to be done.

By default, every User Session Server stores FSLogix logs at C:\ProgramData\FSLogix\Logs. The logs can be viewed in order to gain insight into the error that a user is currently experiencing. The next section shows you how we used the FSLogix Logs to troubleshoot an issue that a user was experiencing.

In the screenshot below, we ran into a situation where an FSLogix Profile Container was not being created for a specific user. Instead of an FSLogix Profile Container, the users profile was being created on the individual User Session Server. This meant that they would get a different profile depending on which User Session Server they were logged into. To begin troubleshooting this, we checked the FSLogix Logs, specifically the Profile Logs, located at C:\ProgramData\FsLogix\Logs\Profile.

In the Profile Logs, we saw the below entry relating to the user who was not getting an FSLogix Profile Container.

===== Begin Session: LoadProfile: jpeters

…

Reason set to 2: User is a member of the exclude group

User is a member of the exclude group

Not a session we care about

Based on the log entry above, we see that the user belongs to a group that is excluding them from FSLogix Profile Container creation. The next course of action is to check Active Directory and see which groups the user belongs to.

As per the below screenshot, we see that the user belongs to the ‘FSLogix-ProfileExcludeList’ group, which is why they are not getting an FSLogix Profile Container created for them. To resolve this, you’d have to remove the user from that group. The group may not always be named as explicitly as shown in the screenshot below, but this is the general idea behind using the FSLogix logs to troubleshoot.

This is just one example of an error that you may encounter when viewing the FsLogix Logs. Different errors require different methods of troubleshooting, but the FsLogix Logs provide you with a place to start. If you’re unsure of what to do from what is shown in the logs, please proceed to the following sections, where we have provided a few basic troubleshooting steps.

The first step that should be taken is to bypass the Broker Server and log directly into a User Session Server. If we can login successfully using this method, then this means the Broker server is the issue, and should be rebooted and further investigated if necessary. To bypass the Broker Server, right click on your RDP file, and click Edit

By default, the Computer field is populated with the name of your deployments Broker server. Erase the broker server and input any of the User Session Servers that is associated with the Collection Pool that the user belong to.

As an example, the t1@redchair.rchr user in the screenshot below belongs to the Web Browsers Collection Pool.

Knowing this, we can go back to the CAS portal and navigate to Cloud Manager → VM Instances. In the description for all User Session Servers, you can find which Collection Pool is associated with each User Session Server. In the screenshot below, we see that rchruss003 is associated with the Web Browsers collection pool. This means that if the t1@redchair.rchr was having issues logging into the deployment, then rchruss003 is one of the servers that they can login to. Take note of this

server

In the Edit window of your RDP file, in the Computer field, input the name of the User Session Server. In this example, we’ll be inputting rchruss003. Click Connect when complete.

If you can login successfully when doing this, then that means the Broker Server is the issue. Reboot the Broker Server and when it is back online, try logging in again.

If your login is still unsuccessful, please proceed to the next section.

Login to the user session server that the user was last logged into. If you are unsure which user session server that is, you may have to login to each individual user session server that corresponds to the Collection Pool that the user belongs to. Once you have found the correct user session server, right click on the Windows Icon located at the bottom right of the screen and click on Disk Management

In Disk Management, if your Collection Pool is using FsLogix Profile Containers, the disk’s name will be the name of the user who the profile disk belongs to.

Once you have identified the disk that you would like to detach, right click it, and click Detach VHD.

Now, once the VHD has been detached, double check that it isn’t being used anywhere else.

To do this, login to your deployments File Server and right click on the Windows logo located on the bottom left of the screen and click on Computer Management

In Computer Management, navigate to Computer Management → Systems Tools → Shared Folders → Open Files

In the Open Files section, you want to search for the users .vhdx file, to see if its being used by a specific process within Windows

If you see the .vhdx file of the user in the Open Files section, right click it, and click on Close Open File

Next, click on the Refresh button and check if the .vhdx file for the user is showing up again. It shouldn’t, but if it does, keep on repeating this process until it is no longer showing up after clicking Refresh

Next, navigate to Computer Management → Systems Tools → Shared Folders → Sessions

Check in the Sessions window to see if the user who is experiencing FsLogix Profile Container issues is listed. If they are, right click on the user, and click Close Session

If the user isn’t listed in the Sessions & Open Files sections, try logging in as the user and see if they get a working FsLogix Profile Container. If they don’t, proceed to the next section.

Login to your deployments File Server.

Go to the Profile folder, typically located at D:\Profile

Locate the profile folder of the user who is having the issue. In this example, we’ll be

troubleshooting the t1 user. If you’re using FSLogix Profile Containers, as displayed in the screenshot below, then the username will be located at the end of the folder.

Right-click on the users profile folder, and click on Properties.

Go to the Security tab and click on Advanced.

If you are unable to display the current owner of the folder, then click Change.

In the ‘Enter the object name to select’ box, type in

Deployment - File-Server-Name\Administrators

Click Check Names and then OK

If you’re unsure what your File Server name is, you can find it at the top of your RDP session, as per the screenshot below,

In the event that it is not there, you can also login to https://cas.itopia.com, navigate to Cloud Manager → VM Instances and check the name of your File Server, as per the below screenshot,

Once you have added the Deployment - File-Server-Name\Administrators group as the owner of the User’s Profile Folder, check the box for Replace owner on subcontainers and objects.

Click on Apply and then OK

Click OK in the window that follows

Open the Properties

The first thing you should do is Disable inheritance

The only 3 permissions that should be there are

1. 'The user who is having the profile issue' with full control, and

2. CREATOR OWNER with full control.

3. Insert-server-name-here\Administrators with modify permissions

Remove everything else. Below is a screenshot from my personal deployment, showing how it should look.

There may be an issue with the multiple permissions that exist in the users folder. It should be boiled down to just those three.

Now, try logging into the deployment once more. If you’re still unable to login, please proceed to the next section.

Login to https://cas.itopia.com/

Navigate to Cloud Manager → VM Instances

The goal here is to take note of all User Session Servers that belong to the Collection Pool that the user is having issues logging into. In this example, the t1@redchair.rchr user belongs to the Web Browsers Collection Pool, and rchruss003 ( pictured in the screenshot below) is the only User Session Server that belongs to the Web Browsers Collection Pool.

Knowing that, log into your File Server and navigate to your Profile folder (Typically D:\Profile, unless it has been changed otherwise)

Right-click on a blank space within the Profile folder and click on Properties.

Click on the Security tab and click Advanced

Click on Change permissions

Click Add

Click on Select a principal

Click on Object Types…

In the Object Types… windows, check the Computers box and click OK.

Type in the server(s) that you took note of in the beginning of this section. In this example, we’ll be adding rchruss003 because it belongs to the Web Browsers Collection Pool, which the t1@redchair.rchr user, who is having issues logging in, belongs to. If you have multiple servers that are part of a single Collection Pool, then you will have to add all servers, not just one.

Once you have typed in the server(s), click on Check Names and then click OK.

Grant the server(s) you just added Full Control permissions and click OK.

Try logging in as the user who was experiencing the issue

Lastly, if that fails, you can get all the data (desktop, documents, downloads, etc) on his current FSLogix Profile container, and then migrate it over to a new profile. To create a new profile, login to the File Server, navigate to D:\Profile, and locate the profile folder for the user that you want to create a new profile for.

Rename the folder and put '.old' at the end

Before

After

After, renaming the profile, have the user login and a new profile will automatically be created as per the screenshot below,

From here, the new profile will be used whenever the user logs in.

If you wish to migrate data from the old profile, you will have to navigate to the path containing the users .vhdx file. In the screenshot below, we’re navigating to the old profile of the t1 user.

Once you have located the .vhdx that contains the data you would like to access, right click it, and select Mount.

You may get the below error message. Click OK

Navigate to Disk Management. You can do so by right-clicking on the Windows Icon in the bottom left corner, and selecting Disk Management.

Locate the drive that you just mounted. In this example, we’re looking for the Profile-t1 disk. When you have located it, right click it, and select Change Drive Letter and Paths...

Click Add...

You have the option of either mounting the user profile with an assigned letter, or you can mount it to a folder. Either option is fine, but in this example, we’re going to mount the user profile with the letter E. You can choose any letter that you like.

Once you have selected your drive letter, click OK.

Now, when you open File Explorer, and click on This PC m you will see the user profile mounted with the letter that you chose in the previous step.

From there, you can open the drive and copy and paste the desired files as you see fit. Whenever a user is logged into a User Session Server, their profile will appear at C:\Users but only while they are logged into the server. When the users logs off, their profile will disappear from C:\Users, because the .vhdx file is unmounted. The goal here is to mount the new profile so that you can migrate data from their old profile. You can repeat the previous steps on the new profile in order to accomplish this.

FSLogix Profile Container Support