0

Workstations have multiple drive mappings to shares on SRV01. One share has application executables for a network enabled accounting and tax prep program. After a reboot, all mapped drives work properly. The tax prep program can be launched from the share and in some cases will open and function properly until a specific functionality is used. Other workstations will have errors immediately upon opening the application. In either scenario, it is predictable when the error will show up once it has presented previously, and as soon as an error shows up all mapped drives to SRV01 will go offline or inaccessible from the workstation. Then user has to log off or reboot before everything will reconnect. The error messages do usually state something about the drive being inaccessible, but as I mentioned access is fine to all shares (through Windows Explorer, and I've verified permissions) before the error and as soon as the error is thrown all the drives disconnect. This includes shares completely unrelated to the application.

This is an intermittent issue that has been difficult to track down. The vendor of the software denies it's their application of course. I'm looking for confirmation of my conclusion that the application is at fault, or any guidance on what else I can investigate. Thanks!

2
  • so this is a multiuser app? as you have it on a share. could it be it creates some file locks which are not released properly when a second user opens it?
    – Zina
    Dec 27, 2017 at 19:42
  • @zina it is multiuser, I would say that bad file locks are a possibility but I'm not sure if that would fail so spectacularly as to offline all the other mapped drives (which the app would have no locks on).
    – Ethan
    Dec 28, 2017 at 2:20

2 Answers 2

1

This reminds me of a problem which we had: some particular software packages began throwing errors which were network or file-not-found type unrecoverable errors. Most other software which relied on the same mounted shares did not seem to be affected.

I believe the issue was that the group policy was being refreshed periodically (refresh interval is about 90 mins IIRC), and the mounts were configured to be deleted and remounted, instead of simply refreshed. We adjusted the configuration and the problems went away.

The software in question was simply not fault tolerant, probably it was a bound data control used on a (database application) form that was not properly handled.

https://technet.microsoft.com/en-us/library/cc770902(v=ws.11).aspx

2
  • I'll check again tomorrow but I believe I had checked for GPO drive mappings and there were none. The "workstation setup" for this application relies on it being ran from a known drive letter share and it does everything based off that going forward. I have seen documentation from the vendor about any GPO drive shares being set to not use the recreate option so that is a good thought.
    – Ethan
    Dec 28, 2017 at 2:24
  • confirmed- no GPO drive mappings. Thanks for the tip.
    – Ethan
    Dec 28, 2017 at 16:06
0

Antivirus turned out to be the culprit. Other network applications started to have similar "access denied" messages pop up and all drive shares on the associated server would disconnect. Sometimes it would be predictable when this would happen and sometimes not. Stumbled across a new section in our Antivirus software that detects "encryption" activities and then if it deems them malicious will mark the host (read: workstation) as un-trusted on the network. Sure enough this tool had log messages flagging files pertaining to each affected application. Re-configuring white-lists seems to have cleared things up.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .