Mike,
Thank you for the insight. That is actually helpful, a previous set of instructions did not inform me the the KeepConn was limited to 65535. That aside I did have group policies in place to create the registry entries for these items but they may not have been working.
In context, what is happening is a customer is running a report and the report takes LONG to run, about 25 minutes (personally I don't think there is any excuse for an application report to take 25 minutes but that is not terribly relevant). The report spends most of its time displaying "sorting" in the toolbar. During this sorting time if there is no action on the drive it could possibly disconnect under the default 10 minute value.
Just seems odd that the application would be "sorting" and that would cause no network activity. I think the user typically runs a second session of the application and runs other parts of the application while the report is being created. I will review the registry on the workstation that runs these reports tomorrow and I will see if that makes any difference. I will also look for those delayed write failures, but there isn't really much "writing" going on in this process.
Thank you for the insight. That is actually helpful, a previous set of instructions did not inform me the the KeepConn was limited to 65535. That aside I did have group policies in place to create the registry entries for these items but they may not have been working.
In context, what is happening is a customer is running a report and the report takes LONG to run, about 25 minutes (personally I don't think there is any excuse for an application report to take 25 minutes but that is not terribly relevant). The report spends most of its time displaying "sorting" in the toolbar. During this sorting time if there is no action on the drive it could possibly disconnect under the default 10 minute value.
Just seems odd that the application would be "sorting" and that would cause no network activity. I think the user typically runs a second session of the application and runs other parts of the application while the report is being created. I will review the registry on the workstation that runs these reports tomorrow and I will see if that makes any difference. I will also look for those delayed write failures, but there isn't really much "writing" going on in this process.