none
Access won't start via Task Manager if set to run unattended RRS feed

  • Question

  • I have moved some scheduled tasks that run an Access 2016 database from a Windows 7 pc to a Windows 10 pc. Surprisingly this has been difficult.

    The tasks need to run unattended so the "run whether user is logged in or not" switch on the task is set to true. This seems to be the issue with Windows 10; it will not run Access if that setting is turned on. The task runs as executed as soon as that setting is off. The account I'm logged in to is an admin account; the behavior is the same whether run by trigger (time of day or event) or manually executing the task. I've some posts on the general topic of exe's not executing, and taken those measures to no avail, including

    - put the command into a bat file and run the bat file

    - make sure these folders exist:
    C:\Windows\System32\config\systemprofile\Desktop
    C:\Windows\SysWOW64\config\systemprofile\Desktop

    - run with highest rights

    - if attempting to run a 32 bit program, include path to cmd like C:\windows\Syswow64\cmd.exe /C

    I've tried many other things most of which I'd suspect are less to the issue at hand. Nothing needed from the network for this.

    I wrote a small Access program that logs when it's opened in a table and sure enough, there are no entries if run with "run whether user is logged in or not" on. This was a test to make sure that in the context of the system user that it might not be visible in task manager when running.

    It can't be this hard, but with Windows 10 it seems to be. Is there a workaround?



    • Edited by rusticloud Tuesday, February 25, 2020 9:08 PM
    Tuesday, February 25, 2020 8:28 PM

All replies

  • I don't think Office apps like to run unattended. In a similar case IT configured the VM to login at startup, and then start my app. Everyone happy.

    -Tom. Microsoft Access MVP

    Tuesday, February 25, 2020 9:44 PM
  • See Considerations for server-side Automation of Office, specifically:

    • from a Windows workstation other than the interactive station of the user who is logged on
    • They assume an interactive desktop and user profile.
    • Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component
    • Problems using server-side Automation of Office
      • User Identity
      • Interactivity with the desktop
      • Reentrancy and scalability
      • Resiliency and stability
      • Server-side security

    You say the account you are logged into is an admin account, but are you sure that is the account that Access is using when it executes unattended? I doubt it. Executing unattended would cause the same problems as server-side execution.

    I here you saying, well that can't be; Microsoft would not prevent us from processing data in the manner you need to. The thing is that you just cannot do it using Office technology. I assume you can use SQL Server. You might not have heard of SQLite but it is supplied with current versions of Windows 10.



    Sam Hobbs
    SimpleSamples.Info


    Tuesday, February 25, 2020 9:51 PM
  • Thanks Sam and Tom. It *is* behaving as if running Office apps unattended is not permitted, but I've never seen mention in forum posts of that change of behavior from Windows 7 (those posts may exist but I've never seen them), which seems odd given that it at least used to be a common practice. Certainly on Windows 7 it was permitted. I believe that it does use the System account when running or trying to run unattended.

    The link that Sam provided does speak directly to this issue. It says not supported or recommended, but I don't see it saying not permitted explicitly. But none of the workarounds I've tried have gotten it to work and maybe it's not an option in fact.

    There is no way that the process in Access is going to be moved to some server side process at this time, it's a complex import routine. In a year, it will be possible due to a pending rewrite. There are some third party task scheduler offerings out there, I may have to resort to that. Otherwise we could keep Windows 7 active on a vm that only handles this one task.

    But with your input at least I now understand definitively that it's not something obvious that I've missed - it's a capability of the older OS that is not available in the newer OS, or at least that's how I interpret it.



    • Edited by rusticloud Tuesday, February 25, 2020 11:11 PM
    Tuesday, February 25, 2020 10:19 PM
  • It was not supported in the old Windows. It worked but it was not guaranteed to work and that article explains why it would fail when it did fail. There are some Access enthusiasts that will say that Access can do everything SQL Server can do but Microsoft never intended that.

    You say some third party task scheduler offerings but that won't make Access work unattended like you need. Your organization needs to begin a transition to SQL Server. A rewrite is an excellent time to do the transition. If you are an Access VBA developer then you need to learn VB.Net or C#. You might not accept that now but hopefully you will before it is too late to do the rewrite the right way.



    Sam Hobbs
    SimpleSamples.Info

    Wednesday, February 26, 2020 2:40 AM
  • It worked perfectly for this org since the middle 90s, only time it's been an issue has been this transition to windows 10. I'm sure the additional restrictions are a good move for many reasons.

    This system is already on sql server. It's a complicated very old school line of business application that I inherited years ago. They have everything lined up now for a rewrite and this need will go away at that time. But until then this has to keep ticking over, one way or another.

    Wednesday, February 26, 2020 2:45 AM