Desperate help in fixing broken Profiles.

Question

I have a thread on Reddit here: https://www.reddit.com/r/sysadmin/comments/o0rzt3/in_desperate_need_of_help_with_a_problem_with/

Here is a copy of my issue.

Having major issues.

We have AD on Server 2019, and we also run Remote App with Session Hosts etc. Basic run of the mill setup. Clients are all Windows 10 21H1. We also run WSUS (which is helping my problem be manageable). We also run FSLogix for roaming profiles. For those that don't know, FSLogix uses a VHD file for mounting effectively the AppData folder for the user.

The problem:

We are getting a few updates that are causing a problem. The problem is that the VHD mounts, but you cannot assign a drive letter to it to be able to read it. FSLogix doesn't add a drive letter but seems to mount the VHD (I see the file getting read) but it keeps saying it's already mounted, seems it just can't read it.

The VHD files are on a Synology NAS. The problem occurs on both VHD or VHDX files. I have played with the SMB settings and I have tested on my home PC, that has Synology NAS and WIndows 10, just no domain, but I don't seem to have the issue at home.

The Updates are as follows (for both Windows Server (Session Hosts) and Windows 10:

KB5001337

KB5001330

KB5001406

KB5003173

KB5003171

KB5003637

KB5003646

There can't be the exact same problem with every single update. I am starting to think that something these updates do, is a symptom and the actual problem is something on our network, maybe even a configuration issue. The ONLY thing that I can think of that is glaringly different on my works network as opposed to home, is that here at work we have Multicasting disabled on the network. But I also can't imagine that being the problem.

I really need help working this out. WSUS lets me manage these updates but I am now concerned we will be open to other issues these updates solve. I really need to get to the bottom of this issue. Any help in further diagnosing, and/or suggestions on what to look at next would be much appreciated.

Answer 1

Hi,

Thanks for posting in Q&A platform.

Please understand, due to the environment limitation, it is hard for us to reproduce and analyze this behavior in our lab. Some necessary network traffics should also be collected for further analyzing this issue. However, analysis of log is beyond our forum support level and due to forum security policy, we have no such channel to collect user log information. If this issue is urgent, I would suggest you contact Microsoft Customer Support and Services where more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.

You may find phone number for your region accordingly from the link below:

https://support.microsoft.com/en-us/help/4051701/global-customer-service-phone-numbers

Best Regards,
Sunny

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Hello @Shaun Williams ,

I am not familiar with your type of set-up (I have been retired for a few years now) but, if it makes sense to you, you could try the following on a client:

• Issue the command: logman start why -ets -p Microsoft-Windows-SMBClient Smb_Info -o why.etl.
• Try to connect to and use the profile.
• Issue the command: logman stop why –ets.
• Issue the command: wevtutil qe /f:text /lf:true /q:"*[System[EventID = 30406 or EventID = 30407]]" why.etl | findstr "SMB.send SMB.receive".
• Review the output of the process and verify that it matches your expectations; post here if there are things that seem odd to you.

Gary

Answer 3

Hi @Shaun Williams

Did you ever find a slution to your problem? We are experiencing the exact same issue, we have a call rasied with Microsoft but we are not getting anywhere fast. The issue has been occuring since we installed the May (I've not confirmed if it happened with the April update).

I've created the logs that @Gary Nebbett has suggested and passed it over to our storage provider. I'll be honest, I'm not sure if it will provide any isight.

Regards

Answer 4

Hello @Shaun Williams ,

Julian took the risk and shared some data with me. My current suspicion is that an update to vdhmp.sys is causing the problem; vdhmp.sys seems to be included in the updates that you mentioned (at least, those for which I could find a list of affected files).

The problem seems to be use of the file system control code FSCTL_VIRTUAL_STORAGE_QUERY_PROPERTY issued by the routine VhdmpiInitializeScsiStateForSurface, which fails with error code STATUS_NOT_SUPPORTED when sent to some NAS servers.

Anything that you can add to firm up or refute this suspicion would be appreciated.

If the suspicion is founded, then there is probably no workaround to enable continued use of the NAS but the information could help in discussions with the NAS manufacturer.

Gary