We are struggling to find a solution for this one. We got no firewalls in place between the isilon and the clients. There is no firewall installed on the Windows 7 clients. The error does not happend on every client whicht is a miracle because we use GPOs, Central Software Distribution and Images for Windows Installation, but still the clients behave different.
Allow Trusted Locations and Procteded Views is Setup like you recommended in your Blog.
The error appears when a user locks his workstation with an opened but unsaved document and comes back in after 30 or more Minutes and hits the safe button.
did you try to run tcpdump on Isilon and Wireshark on the client and try to capture that period of time when this issue occurs. Once captured you can ask Isilon support to help you review it.
Just for giggles try the settings i provided in this thread.
We are unable to perform an tcpdump on isilon, this cluster is way to slow for this. I cannot see anything withing this trace pointing to an error. The SR is open for a few months but still without a solution.
I even applied your solution last tuesday, but again without any improvements.
I got four X200 Nodes each with 10 1TB SATA and a single SSD having 7500 SMB connections. There is diskless A100 as well (but without any use, EMC overlooked that our rusty VTL is not listed in their HCL). Whenever I start a capture the node stops responding to any new connection. With an clusterwide tcpdump the whole cluster stales.
From my point of view the sizing is way to small. I made a presentation showing up the sizing is to small. They expected to push out 12.000 Protocol Request with the nodes w. 11 1TB SATA drives each. SyncIQ to the secondary site is running as well. They agreed and we added a ssd of the delivered nodes and another node to each site.
tcpdump troubles even if filtering traffic from/to a single test client?
Have you considered using the idle A100 and a dedicated address pool
for testing/tcpdump with selected clients? (Some might say using Backup-A100
for NAS traffic is not recommend, but should be fine for isolated test cases.)
If you see "file in use" error and network trace shows STATUS_SHARING_VIOLATION and your cluster version is 220.127.116.11 -18.104.22.168 : with high chance you have to upgrade to OneFS 22.214.171.124.