WVD with Azure Premium Files and FSLogix cannot connect

%3CLINGO-SUB%20id%3D%22lingo-sub-2212621%22%20slang%3D%22en-US%22%3EWVD%20with%20Azure%20Premium%20Files%20and%20FSLogix%20cannot%20connect%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2212621%22%20slang%3D%22en-US%22%3E%3CP%3EI%20just%20wanted%20to%20write%20this%2C%20to%20get%20it%20out%20there%2C%20possibly%20to%20channel%20frustration%20but%20most%20to%20see%20what%20other%20techs%20are%20doing%20out%20there%20for%20their%20WVD%20deployments%20that%20utilize%20FSLogix%20and%20Azure%20Premium%20Files.%26nbsp%3B%20After%20the%20stunt%20Microsoft%20pulled%20today%20hosing%20AzureAD%2C%20users%20are%20unable%20to%20sign%20into%20WVD%20hosts%20because%20their%20profiles%20are%20stored%20on%20Azure%20Premium%20Files%20which%20they%20cannot%20successfully%20authenticate%20to.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMy%20hope%20is%20that%20Microsoft%20has%20this%20fixed%20by%20the%20morning.%26nbsp%3B%20I%20know%20they%20are%20working%20on%20it....but%20I%20can't%20come%20to%20work%20tomorrow%20and%20tell%20everyone%20they%20can't%20sign%20in%20to%20work.%26nbsp%3B%20I%20need%20a%20solution%2C%20or%20an%20alternative%20in%20case%20Microsoft%20cannot%20reverse%20this%20by%20morning.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERight%20now%20I'm%20thinking%2C%20and%20this%20would%20be%20painful%2C%20is%20to%20just%20turn%20off%20FSLogix%20so%20users%20would%20be%20running%20local%20profiles.%26nbsp%3B%20I%20don't%20like%20the%20idea%20of%20this%20because%20it%20seems%20there%20will%20be%20a%20lot%20of%20aftermath%20cleanup%20to%20do%2C%20but%20I%20suppose%20it's%20better%20than%20the%20alternative%20of%20not%20being%20able%20to%20sign%20in.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnyone%20else%20facing%20the%20same%20dilemma%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2213030%22%20slang%3D%22en-US%22%3ERe%3A%20WVD%20with%20Azure%20Premium%20Files%20and%20FSLogix%20cannot%20connect%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2213030%22%20slang%3D%22en-US%22%3EIf%20you%20have%20a%20server%20in%20azure%20you%20could%20host%20it%20on%20a%20drive%20attached%20to%20that%20vm%20but%20beware%20of%20maxing%20out%20on%20iop%2Fthroughput%20as%20the%20vm%20spec%20is%20the%20bottleneck.%20But%20hopefully%20it%E2%80%99s%20fixed%20today%20I%20check%20at%2010pm%20lastnight%20and%20it%20was%20working%20better%20than%20at%207pmish%3C%2FLINGO-BODY%3E
Occasional Contributor

I just wanted to write this, to get it out there, possibly to channel frustration but most to see what other techs are doing out there for their WVD deployments that utilize FSLogix and Azure Premium Files.  After the stunt Microsoft pulled today hosing AzureAD, users are unable to sign into WVD hosts because their profiles are stored on Azure Premium Files which they cannot successfully authenticate to.

 

My hope is that Microsoft has this fixed by the morning.  I know they are working on it....but I can't come to work tomorrow and tell everyone they can't sign in to work.  I need a solution, or an alternative in case Microsoft cannot reverse this by morning.

 

Right now I'm thinking, and this would be painful, is to just turn off FSLogix so users would be running local profiles.  I don't like the idea of this because it seems there will be a lot of aftermath cleanup to do, but I suppose it's better than the alternative of not being able to sign in.

 

Anyone else facing the same dilemma?

3 Replies
If you have a server in azure you could host it on a drive attached to that vm but beware of maxing out on iop/throughput as the vm spec is the bottleneck. But hopefully it’s fixed today I check at 10pm lastnight and it was working better than at 7pmish
@StevenR I'm just finishing for the night....the fix must have just hit our tenant not too long ago because I was able to successfully connect with 1 test account but not the other. About an hour later, I was able to connect with the other test account. I was preparing for the worst case scenario tomorrow morning. Now let's hope it stays that way for the next 5 hours when people start logging in!
The issue was during the Azure Outage: CA - Authentication errors across multiple Microsoft services (Tracking ID LN01-P8Z). Once services were restored, there were 4-5 .vhd profiles that had open file handles on them. The problem was, I could not see those open file handles within Azure Storage Explorer. I ended up having to create a new storage account and use the objectspecific registry settings for FSLogix for the affected users, and route their profiles to the new location. Fortunately I was able to copy their .vhd files from a recent backup over to the new storage location so they didn't' lose everything.
After the fact, I found a really useful powershell command that would have saved me from doing all of this. This is even helpful today, because sometimes we have an issue where users try to sign in but their .vhd profile "is being used by another smb process" even though it's not attached to the host. The commands that I found useful were:
Get-AzStorageFileHandle -Context $storageAcct.Context -ShareName $shareName -Path $filePath followed by Close-AzStorageFileHandle -Context $storageAcct.Context -ShareName $shareName -Path $storagePath -CloseAll

It was failing at first, even through the Azure CLi, but I found I had to whitelist my IP address that was trying to connect through the Azure CLi in the browser . I got that IP address by going to Azure AD sign in logs. Hope this helps someone with future issues.