Mar 132018
 

——–UPDATE 3/28/2018 ———-

Starting with FSLogix 2.8.12 you no longer need to do this.  Great work FSLogix!

From their release notes:

“• An issue with first time OneDrive installation has been resolved. The issue occurred when OneDrive was installed for the first time, and OneDrive syncing began. The FSLogix agent would not redirect the OneDrive files to the VHD/X container until the user logged off and then back on again. The FSLogix agent has been enhanced to detect that OneDrive is being installed, and now immediately begins redirecting the OneDrive files to the VHD/X.”

I have tested this multiple times and it works perfectly.

However, I DO still recommend you make the symlink to C:\OneDriveTemp as stated below.

Old post below

———————————————————————————————————————————————————————————

We have started to use FSLogix Apps to deliver OneDrive into our Hosted XenApp Desktops that we offer to our customers. This is a great tool that allows users to use the native OneDrive utility in their XenApp sessions. Why would you need this, you may ask? The reason is that OneDrive forces your OneDrive data to be saved in %LOCALAPPDATA%. If you’re using Citrix Profile Manager (UPM) or really any other profile tool, you would be stuck trying to sync that data during logon/logout, which isn’t really feasible. You could also just use local profiles, but then you would be saving all of the data across all of your XenApp servers. I have not figured out a way to trick OneDrive to save to a network location. It was even too smart for a Windows symlink.

This is where FSLogix Apps come in. FSlogix Apps can mount a VHD for each user, and with it’s file system filter driver it’s able to determine what data is destined for OneDrive and move that data into the VHD. At this point there is only one copy of the OneDrive data, and you can roam it across all XenApp servers in your environment. It works very well and we like it a lot, however there are a couple of important shortcoming I need to discuss. I will also show you how I worked around these issues with my own testing and scripting.

Note: THIS IS NOT SUPPORTED BY FSLOGIX. IT WORKS, BUT USE AT YOUR OWN RISK!

First: FSLogix Apps can not pre-mount junction points. If you look at a user who has logged in before configuring OneDrive, you will see the following information:

One, the VHD is mounted fine.

However, look at the redirects:

You can see here that only the Outlook and Lync redirects are in place. I don’t see anything for OneDrive. Let’s see what happens when we configure OneDrive right now. Let’s look at the space on C:

So, look at OneDrive and how much space it thinks is free. The VHD configured for all users is 100GB.

I’m going to select 5.5 GB of “crap” and start a sync. Let’s see what happens.

So, it has taken up space on the C:. Well this isn’t good! With a couple users and a small amount of data you can fill up the C: on your XenApp server. Bad! Also, in this type of configuration where you are only using FSLogix Apps for OneDrive and NOT for profiles, you would be syncing this information back with your profile management solution.

So… What can we do? A couple of things to help this out. I wrote a script to pre-mount the junction points. Let’s take a look.

function Register-Redirect {
param(
[string] $TenantName = "VC3, Inc" # Enter your Tenant ID here
)
try {
# Ensure frx.exe is present in the PATH
if (!([System.Environment]::GetEnvironmentVariable('PATH').Split(';') -contains "$($env:ProgramFiles)\fslogix\apps")) {
Write-Verbose "frx.exe is not found in 'PATH'...Adding frx.exe to 'PATH'";
$env:PATH = "$($env:PATH);$($env:ProgramFiles)\fslogix\apps";
}
# If the junction point is not mapped parse out the number from the results returned from 'frx list-redirects file'
[string] $frxOutput = & 'frx' 'list-redirects' | Where-Object { $_ -match "\\$($env:USERNAME)\\" } | Out-String;
if ($frxOutput -match '\\Microsoft\\OneDrive') {
return;
} else {
$Matches = $null; # Reset the hashtable.
$frxOutput -match '\\Device\\HarddiskVolume([1-9]{1,3})\\Skype4B\\User';
$volume = $Matches[1];
# Map the junction points matching the above regex.
Write-Verbose -Message "Adding redirect => Source: \Device\HarddiskVolume2\Users\$($env:USERNAME)\OneDrive - $($TenantName) Target: \Device\HarddiskVolume$($volume)\OneDrive\User";
frx add-redirect -src "\Device\HarddiskVolume2\Users\$($env:USERNAME)\OneDrive - $($TenantName)" -dest "\Device\HarddiskVolume$($volume)\OneDrive\User";
Write-Verbose -Message "Adding redirect => Source: \Device\HarddiskVolume2\Users\$($env:USERNAME)\AppData\Local\Microsoft\OneDrive Target: \Device\HarddiskVolume$($volume)\OneDrive\UserMeta";
frx add-redirect -src "\Device\HarddiskVolume2\Users\$($env:USERNAME)\AppData\Local\Microsoft\OneDrive" -dest "\Device\HarddiskVolume$($volume)\OneDrive\UserMeta";
}
} catch {
throw "Unable to add redirect";
}
};
Register-Redirect

sleep 5

& "C:\Program Files (x86)\Microsoft OneDrive\OneDriveSetup.exe"

All of this assumes your C: of your XenApp Server is HardDiskVolume2!!!

What does this do? Ok, first, you put your tenant ID in the top. You need this because your folder is normally in the “OneDrive – TenantID” format. Next, it sets a path to the frx .exe. Then it checks to see if the junction points are already mounted with `frx list-redirects` . (it will have no problem duplicating them, so I had to write this in). It uses logic to only pull your own username, so if you are logged into a XenApp server with a bunch of users, you only return your own information. By default it will list all users.

If the script see’s that you don’t have them mounted it will mount them for you. This is where it gets tricky. Look at the existing `frx list-redirects`

The section on the right is where it mounts the information into the VHD. Notice it is HardDiskVolume4. What I had to do was (get a bunch of help, BobFrankly/Atum – CitrixIRC) write a regex to extract the “4” from this output, so we can use it to mount the OneDrive locations in the same volume. THIS IS CRITICAL. Otherwise you wouldn’t be writing to the VHD and that would be bad. So the script extracts the volume number, then runs `frx add-redirect` to add the junction points.

This is a function, so the last thing it does is run the function, then launches the OneDriveSetup.exe

Let’s run this and see what it does. I added a pause so we could see it. You can see the two “Operation completed successfully!” messages, and the OneDrive Setup has launched.

On the server you see the junction points. Notice the addition of two OneDrive folders.

So, let’s setup OneDrive and see what happens. First, let’s look at the hard drive space again.

But wait, why does it still show the wrong amount of hard drive space? Bear with me.

Let’s sync 5GB of “crap” and see what happens. It shows the proper VHD size after the sync is complete. I’m not sure WHY it shows up incorrectly first, it just does.

Let’s check out the hard drive.

Success!

YOU SHOULD ONLY NEED TO RUN THIS SCRIPT ONCE! Once this process is done, FSLogix will handle the rest and you won’t have to do this ever again! I have this setup to launch through a shortcut in the user’s Start Menu’s as part of the “OneDrive Onboarding” process.

Second: If you have worked with OneDrive before, it’s great, but not perfect. Also, FSLogix doesn’t always perfectly clean up all of the junction points at logoff. You want to make sure they are gone at logoff, especially if something breaks during initial configuration of OneDrive. I have added a logoff script to kill the junction points. You will have to edit this for your own tenant ID!

frx del-redirect -src "\Device\HarddiskVolume2\Users\%USERNAME%\OneDrive - VC3, Inc"
frx del-redirect -src "\Device\HarddiskVolume2\Users\%USERNAME%\AppData\Local\Microsoft\OneDrive"

Lastly, if you know how the behavior of OneDrive is, you can still have a problem. By default, when you sync with OneDrive, the FIRST place it writes files to is C:\OneDriveTemp\<USERSID>. After it’s done processing it moves it into the OneDrive file location. It does this on a file by file basis, but again, if you had a bunch of users all sync’ing at the same time, you still could possibly fill up the C: on the XenApp server!

Lastly: The final uber-hack I did for this was to create a symlink on the server to point C:\OneDriveTemp to a network location. This one actually works with OneDrive. In my case I pointed it to a share I created on the same volume I was pointing the FSLogix VHDs to.

mklink /d C:\OneDriveTemp <SomePathHere>

That’s all I have. These are the step’s I had to go through to use FSLogix Apps with OneDrive in our production environment. Have fun!

Stay tuned. In a future post I will show you how to setup QOS for OneDrive so you don’t kill your datacenter’s bandwidth when you have a bunch of people uploading files at the same time.