Running an accessDb 2016 Makro from Windows Task Scheduler

user_1796841 0
Viewed 62

I have a AccessDB Macro i want to run from the windows task scheduler which requires access to the mapped network drives of the user running the task.

After some initial trouble i found out, that since access 2016 the macros won't run when the access db is being executed as a background process. So i switched the type of the scheduled task to Windows 2003/XP which still executes the task in the foreground.

The problem with this apparently is, that using this type of task, the network connectivity is not available anymore.

Is there a way to run a Windows 2003/XP type task while still retaining the mapped network drives and network connection of the user that executes the task?

I launch the macro via

"path/to/msaccess.exe" "path/to/db.accdb" /X RunMacro
scheduler ms-access ms-office
2 Answers

It is probably caused by the SMB network protocol.

Windows XP doesn't know about SMB2/3, while Windows 10 by default does not activate SMB1 because of a potential security risk.

However, it is simple to activate SMB1 in Windows 10 (feature select). So, if you can live with that security risk, you could try to activate the SMB1 protocol to see if that makes a difference. If not, it can be deactivated easily.

user_35272970

The Windows task scheduler is not the best solution. Microsoft states the following:

All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.

Read more about that in the Considerations for server-side Automation of Office article.

user_16033510
Related