0

We recently moved from an SBS2003 domain to one with Windows Server 2012R2. This machine is our DC and acts as a fileserver as well. Our client machines are all running Windows 7.

I have had a scheduled task on my machine for a number of years, which ran just fine. It executes some code in a MS Access database. The initial portion of the code is running fine. It has access to the back-end database on the remote server and updates everything within the database as expected. It also creates and writes to a local file as expected.

However, it is stopping when it gets to the steps that write files to the remote server share (same server on which the back-end .mdb is housed). It creates the empty text file as I can see it with 0KB, but then fails to write anything to it. The file is being referenced by it's path "\\server\share\directory\filename.txt" and not a mapped drive.

The task is set to use the domain admin account, without needing to be logged in, and with the highest privileges. This user account has all the appropriate share, directory, and file permissions on the remote server and it has been granted Batch Logon rights on the remote server. It is not in the list of accounts that are denied these rights.

If I manually run the task from the task scheduler while I'm logged (and the computer is unlocked) in under my account, it runs fine.

If I change the scheduled time to run while I'm logged in during the day, it runs just fine.

However, when it is supposed to run at night, I encounter this problem. I am still logged in, but the computer will be locked at this time. Again, this ran without issue on the old server.

I can only assume it's a permissions issue, but cannot figure out why it works when I'm logged in to the client machine using my own login. I've been Googling myself to death trying to find a solution, but have not made any progress. Any help would be greatly appreciated.

Thanks, Paul

Paul C.
  • 1
  • 3
  • Does the Task Scheduler reports that the task ended ok ? If yes, do you have the possibility to modify your script to redirect errors for the identified line to a log file ? – krisFR May 29 '15 at 20:51
  • No, it is not ending and the MS Access process is left open as well. – Paul C. May 29 '15 at 20:55
  • I just did another test and found that the issue is caused when the computer is locked. It does not appear to have anything to do with the time at which it is run. – Paul C. May 29 '15 at 22:19
  • Did you check "Run whether the user is logged on or not" in the "General" tab of your task properties ? – krisFR May 29 '15 at 22:22
  • Yes, this option is checked. The task does kick-off, but the writing to the shared folder is what's failing under this condition. – Paul C. May 29 '15 at 22:39
  • If you set it to write to a file on your local PC, does it run when the PC is locked? That would make sure it's not a problem with, e.g. a recent Windows update to Access or Task Scheduler locally. What about if it writes the file to local disk, then tries to copy it to the share? What else did you change on the server - might there be a different AntiVirus realtime scanner make or version jumping on the file as soon as it's opened? Can you run SysInternals' ProcessMonitor on the server to log when the task is running, filter it by local shared folder path `d:\share` and look for ACCESS DENIED – TessellatingHeckler May 29 '15 at 22:57
  • Try having your script mount the share (to an alternate location), write the file, then unmount the share when it's done. – Gene May 30 '15 at 00:11
  • @TessellatingHeckler: The portion of the script that writes to a local PC file doesn't have any issues. The remote server's AV isn't different, but we are using a different back-up solution. However, I don't understand how that would affect the writing of the file only when the local PC is locked. I'll have to look into the processmonitor to see if I can find anything. I have reviewed the server's security logs and haven't been able to find anything telling. – Paul C. May 30 '15 at 04:07
  • @Gene: I'm not sure what you mean by mounting a share to an alternate location. – Paul C. May 30 '15 at 04:11
  • Hmm. I don't think a new backup solution or AV would do anything only when the PC is locked, either. But I can't see why it would be a server permissions issue - and if it's writing local files then can it be a local permissions issue either? Did you upgrade the domain or join the computers to a new domain? Maybe the domain security policy is more restricted. Can you try a script which writes to a network share and run it as a standard user account - maybe a local workstation administrator but definitely not the domain admin - to see if the domain admin account is more restricted in 2012R2? – TessellatingHeckler May 30 '15 at 05:04
  • @PaulC. you can define where a share is mounted. Since the share is already mounted before the system is locked you could mount it to another location to avoid a conflict, then write the file to that new location. http://www.howtogeek.com/118452/how-to-map-network-drives-from-the-command-prompt-in-windows/ – Gene May 30 '15 at 18:03
  • @Gene - I am not using mapped drives as those don't work with Batch Logons. – Paul C. May 30 '15 at 18:31
  • @TessellatingHeckler - I'll give it a try with my own account to see what happens. I was thinking about doing this, but forgot to give it a whirl. The old server was the previous DC. The new server is the new DC for the same domain. The PC's are on the same domain. I've been scouring the group policies to see what might be restricting the access, but haven't uncovered anything. Maybe you are right and it's a built-in restriction of the domain admin. I'll reply back later to let you know what happens. – Paul C. May 30 '15 at 18:35
  • I changed the task to run using my own credentials and ended up with the same result. It created the empty text file and then failed to write any data to it. – Paul C. May 31 '15 at 16:43
  • I decided to change the program to first write the file locally and then copy the file to the server once complete in case something was locking it once opened as suggested above. Unbelievably, the same thing is now happening when it tries to write the file locally. I can only assume it is something in my code, but am not sure why it would work fine when run while logged in. – Paul C. Jun 02 '15 at 12:09
  • As a test, I added a few lines of code that will write a one-line test file to the same local directory. It created the file just fine, but then couldn't get past creating the problematic file right after that. I would assume a problem in the code that is generating the output to the file, but cannot figure out why it would work just fine when run by myself. – Paul C. Jun 03 '15 at 11:45
  • Well, I've been screwing around with this for another month and have come to narrow the problem down, but not resolve it. – Paul C. Jun 27 '15 at 13:29
  • The VBA runs up until an openrecordset on a query that includes tables linked by ODBC (either MySQL or SQL Server). Similar queries in the same program that are run via a macro execute just fine. Queries in the VBA that only include MS Access tables (linked or local) work just fine. Queries in VBA via ODBC that are opened with a specified connection string work fine. And, everything works just fine when I log on to the client locally. – Paul C. Jun 27 '15 at 13:35
  • Based upon the above, I don't think it's a server based permissions issue. I am wondering if there is some weird ODBC permissions issue that is preventing this from working properly using "LOGON AS BATCH" permissions. – Paul C. Jun 27 '15 at 13:36

0 Answers0