Use advanced RemoteFX graphics for RemoteApp – Disabled
If the setting does not work there is a unexpected issue that can rise. The mouse polling rate.. That case happen if one of your user use a gaming mouse. Usually the polling is around 125 hz by default. Most gaming mouse go around 1000 hz.
Such polling really make the server unresponsive for the user session.
I rarely do a post that promote a tool, but I had to do it this time, as I will share a tip if you can’t find where you used space go inside a Windows Server 2019 VM.
Explorer and tool like windirstat don’t see to list hidden folder that start with $.. (metadata file and stream in example) as such it seem a common pattern to be unable to locate where the disk space go.
To illustrate the problem seen I will paste picture from SF that I seen that illustrate the same problem as I seen;
As seen in this example the data is 99% full, but on explorer or windirstat’s windows you can see the files take only 33G out of the 500G available.
I suggest the tool WizTree to find the space in such case for the time other way exist.
Today I wanted to discuss a bug I encountered that got some major impact. The setup is Windows Server 2019 and some Windows 10 client. The bug wasnt present when the server were on 2008R2. The problem seen was when I edit a file over VPN on the file share, the file lost it’s security acl to become orphan and it disappear from the user view at the same time.
It’s a strange bug as the user can see only the folder where he got access to, but when the bug appear the file lost it security at all. Only an admin can take back the file ownership back.
From my research the error seem related to the Palo Global Protect VPN’s software that badly redirect DNS query, and do error out on ldap/kerberos lookup for the domain name. Which seem to lead to authentification error, even if the share is already open.
The symptom I had was;
Only able to map the network drive by the IP.
Such error flood inside wireshark for the remote computer;
DNS QUERY for _ldap._tcp.dc._msdcs.domain fail. (not found)
Such DNS entry can be validated that way;
Validating the DNS entry confirm it work on the LAN, but not from the VPN’s endpoint.
What I discovered is for these clients the mapping was working correcty by using the FQDN directly, not the DFS nameshare or the hostname of the server, really the FQDN, like \\server.domain.com.
The bug seem really related to the globalprotect vpn software, but with this small tip atleast you can bypass that bug.