Windows 10 (2004) FSMGMT.MSC on Server 2008R2 file server

[tosh74]

Since recently upgrading to 2004 I have an issue when running fsmgmt.msc when listing sessions on a 2008r2 server. When listing shares and open files it works correctly and quickly. When I attempt to list Sessions the open file pane list about 2 sessions (starting with A's) then sits at not responding, waits a few more seconds, lists a few more but eventually hangs. I have to then force a close and perform the same thing on the 2008r2 server. I can browse the shares no problem from explorer on the Win10 machine. I tend to use this when users call for remote assistance and they have problems reading the machine name from the asset tag

 

Anyone seen this or give me some idea what to look at?

 

Cheers

[Michael]

Could this be an SMB issue possibly?

[HPlum78]

I reckon your going to find this is something to do with SMB, but TBH and you ain't going to like it get off server 2008r2 and kill SMB v1 in the process as there as some let's say issues with it!

[tosh74]

Thanks for your thoughts. I did suspect an SMB issue. Time to dig out the Shark

[Michael]

Another solution would be to upgrade 2008 R2 > 2012 R2 or higher, which should resolve the issue.

[mrcrazy04]

I think it’s worth pointing out that Microsoft stopped supporting Server 2008R2 in January, unless you pay them lots of money, so I’d strongly recommend upgrading to a supported operating system (Server 2012 or later).

Beyond the SMB issues, there won’t be any new patches, which increases the risk of the server being compromised. If you’re using the server to administer other systems, then that could make it easier for an attacker (or sophisticated malware) to steal credentials and compromise the entire domain.

 

If for some reason you need to continue running Server 2008R2, then it should be isolated as much as possible from the rest of the network (ideally with firewall rules to restrict access to certain services from hosts that need it), and either removed from the domain, or never accessed using privileged domain credentials (like domain admin). Doing this should only be a stopgap measure though, as it doesn’t entirely eliminate the risk.