So, you may be thinking that first of all we need to build a cloud-based Windows file server in Azure, then stand up a federated Active Directory domain controller in there to support authentication, then set permissions and…but no, we don’t need any of that. And to be honest, that sounds like a bunch of work (and potential charges for the server instance). But that’s not what we need, there is a simpler way. So before we start we’ve set up:-

Windows 10 image (CBB, fully patched) with the latest FSLogix Apps agent installed and joined to the domain, deployed to required number of test endpoints

An Azure account

A working Active Directory (can be on-premises, no need for Azure DCs)

Firewall rules configured to allow traffic to your Azure Storage Account share (the crucial one being outbound port 445, as far as I can tell)

And that’s it!

Azure storage accounts

Azure Storage Accounts provide an SMB-enabled file share in Azure intended for application access. We are going to leverage these to hold our user profiles.

Log on to the Azure Portal

Click on Storage Accounts

Click on Add

Set up the options as required, paying particular attention to those options highlighted

The Performance option can be set to Standard or Premium. You may need to test between these two, but I found Standard to be OK in my testing.

Encryption is obviously a big desirable, in my testing I left it turned off but you may very well want to activate this option.

Location is very important because it deals with where your user data is being stored.

It’s also important to note at this stage you should always configure Folder Redirection for data storage folders like Documents, Pictures, Music and the like, otherwise all of that data will end up getting written into the Azure file share which is possibly not the best place to be sending such files. Other folders should be considered for redirection also, such as Downloads and Favorites. One folder not to redirect, though, is the AppData folder – leave that within the profile itself.

Once this is set up the way you want it click the Add button and the storage account will be deployed.

Next you need to set up a file share within your storage account by going to the Files section within the storage account overview screen and clicking File share. At this stage you also need to put a quota on the file share up to a maximum of 5120 GB.

The name of the “server” you will connect to is usually To get the command for access, you need to view the file share you have just created and click on the Connect button, which will provide a net use (yes, old school!) command for connecting to the file share using a dedicated access key.

Whatever you do, DON’T share the access key with anyone you shouldn’t.

Take a copy of this net use command because you will need it later.

FSLogix setup

Now, to get FSLogix to be able to write the FSLogix profile to the Azure file share we need to make a few changes.

Firstly, you should set up a Group Policy Preference that populates the FSLogix Profile Include List local group with the users you want to deploy this to. You also need to make sure these users don’t have roaming profiles defined in AD or any other profile management tool associated with them.

Next, because FSLogix is going to attach to an Azure file share, we need to make a few changes.

Firstly, create a subfolder in your Azure file share to hold the profiles. I’ve made one called Profiles (simply use the Add Folder button as below)

Next, set the Registry value via GPO that tells the FSLogix software where to try and store the profiles for the users.


Value – VHDLocations



Now, the next part is key. In order to be able to access this share, we need to set up a few extra things.

Remember that net use command we saved earlier? You need to copy this into Notepad, replacing [drive letter] with the one you’ve chosen (I used X:). Then save it with a .cmd or .bat extension and place it on the network somewhere it can be accessed by all machines. Here’s the command we used

net use X: \\\profilestore /u:profilestore IfYouThinkIAmPostingTheRealKeyHereYouAreOffYourRockerMate

Next, set up a Group Policy Object Startup Script to run the .bat or .cmd command as your target endpoints boot up. This will authenticate to the file share as drive X: for the SYSTEM context.

Finally (and this is the kicker to make it work), set the following Registry value so that FSLogix connects to the file share in the machine context rather than the user context.


Value – AccessNetworkAsComputerObject


Data – 1

Once these settings are deployed along with the software and your Azure file storage account, you should be ready to test.


Log on to the machine with FSLogix installed as a user configured to use it. Make sure the user doesn’t have a pre-existing profile. A new Windows 10 profile should be created. All being well, you should see a folder with the user’s SID and username created within the folder in the Azure share.

Make a bunch of changes to your desktop – anything you like, Pinned Items, Start Tiles, desktop background, whatever takes your fancy. Log out and the user profile should not be saved onto the local machine.

Now log on to another Windows 10 image. You should see your profile replicated exactly onto the second machine! Any changes you make are saved up automatically into your Azure file share and can be accessed whenever this user logs onto a domain-joined Windows 10 system!

Caveats and considerations

Obviously the machines need network connectivity to access the profile. Laptop users may need to have the FSLogix Registry value of KeepLocalDir set to a DWORD of 1 to mitigate against situations where a network connection needs to be specifically connected to (like hotel wireless).

From a security perspective the user doesn’t have access to the parent folder of their user profile so they should be unable to access other profiles. The X: drive mapped for SYSTEM is visible in the filesystem but is inaccessible without the access key. To remove this, I configured a Group Policy Preference to hide the X: drive for all users.

From a security perspective encryption is desirable as well, and you absolutely need to keep the access key away from intruders! You can request a new key for the share via the Azure portal if you feel it has been compromised, and then you simply need to update the script that maps the drive for the SYSTEM account.

Cost-wise Azure Storage Accounts are much better than standing up VM infrastructure to host it, and a lot less effort is involved. If someone suddenly uploads 30,000 user profiles to one of these Microsoft may reconsider their usage, but right at the moment, they’re a great option.

FSLogix Profile Containers also support multiple concurrent sessions if you use the ConcurrentUserSessions Registry value (see here for all the Registry keys). They basically use a differencing disk to overcome this.

Obviously this tech only supports profiles of the same version (v6 as used here works for Windows 10 AU and Server 2016). If you needed multiple profile versions, I’d recommend creating subfolders under the main Profiles folder. So redirect Windows 7 machines to \\AZURE\SHARENAME\Profiles.v2, Windows 8.1 to \\AZURE\SHARENAME\Profiles.v4, Windows 10 to \\AZURE\SHARENAME\Profiles.v6, and so on, to keep everything neat. You could use Group Policy Preferences to set the Registry value based around the client operating system version with no trouble at all.

I think this is a great way of using Profile Containers to make your profiles truly “cloud-native”. I haven’t tested this at scale or with complicated applications, and you will need to measure the performance before sending it live, but I didn’t notice any appreciable difference here. Domain-joined machines can now log on from anywhere and get their profiles from a highly-available, low-cost Azure-based SMB file share. Give it a try and let me know what you think!

Read the ful larticle @