11

A colleague has a batch script program which needs to to run on a Windows Server in console mode, so that it has access to a Windows interactive session. The server is rebooted at regular intervals automatically (there's an unrelated closed-source application that runs on this machine that we have no control over). After a reboot he wants to automatically start a Windows interactive session and have this script run, plus the service needs to also have access to network resources (CIFS drives, in particular).

Here's what we've tried so far:

  1. Start as Windows service. This failed, since a Windows service can either have access to interactive session or to network resources, but never both.
  2. Used Microsoft management console to add the script to run at startup, however this did not work.
  3. Used an HKLM registry key to start to run this script, however it only gets started when we manually open a remote desktop session on the server.
  4. Creating a scheduled task. The program invoked did not have access to interactive windows session.

Any other suggestions? (Or maybe he missed something when he set up one of these suggestions?)

raam86
  • 6,785
  • 2
  • 31
  • 46
Plutor
  • 2,867
  • 2
  • 25
  • 29
  • Why is a restart needed to recycle the resources of a messy 3rd party app? Just kill it (the OS does the housekeeping) – Assaf Lavie May 24 '09 at 15:57

5 Answers5

9

In case "Interact with desktop" on the service is not enough (I have seen a handful of cases where it is not), you can combine it with AutoAdminLogon. Create three (or four for a domain) REG_SZ values under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:

  • DefaultUsername
  • DefaultPassword
  • DefaultDomain
  • AutoAdminLogon

AutoAdminLogon should be set to the string "1", the others are self-explanatory.

Obviously this has security issues big enough to fly Jupiter through.

JimG
  • 1,782
  • 8
  • 9
  • This ended up being the solution. We had tried the HKLM entry before, but not with AutoAdminLogin set. It's a security issue, but since they are behind-the-firewall server farm machines, it's not really a significant one. – Plutor May 28 '09 at 17:32
  • @JimG Cool solution, but can we achieve this without writing the password in clear text? – school_guy Jun 15 '18 at 14:38
  • Thank you for being the only one to bring this up in the various answers to this question. We're going with this route for some automated testing servers. We had our agent instance running as a service but ended up hitting blocking issues with our target application needing complex desktop interaction... Can't believe this was so difficult! – RileyLabrecque Feb 05 '21 at 02:31
  • Microsoft Documentation on this: https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon > You can use the Sysinternals tool AutoLogon to enable this functionality easier. This tool also helps you to use an encrypted version of password. – RileyLabrecque Feb 09 '21 at 06:20
  • 1
    I had to set DefaultDomainName as well. I set it to our short domain name, and Set DefaultDomain to our FQDN. – RileyLabrecque Feb 09 '21 at 07:33
1

See my similar question and real answer to it: How to start a process from windows service into currently logged in user's session NOTE: "Interact with desktop" checkbox is not enough at all.

Community
  • 1
  • 1
Shrike
  • 9,218
  • 7
  • 68
  • 105
1

Have you tried having your script run as a Windows service, but allowing it to interact with the desktop?

Specifically:

  1. Go to the service properties page
  2. Click on the "Log On" tab
  3. Select "Local System account"
  4. Check "Allow service to interact with desktop"
Jack Leow
  • 21,945
  • 4
  • 50
  • 55
  • 2
    He already tried this. Unfortunately, logging into a Local System account prevents the script from accessing network resources, which we need to be able to do. (I'll update the question to reflect this.) – Plutor May 28 '09 at 15:00
0

I recommend going about this another way. You could build another Windows app that communicates via IPC to the Windows Service and that could be what deals with the closed souorce application. But if you must, you can specify an option in the service (you can do this through MMC, registry, etc). Basically, you can see this option by going to Computer Management->Services and Applications->Services->Right click your service->Change account to Local System and check "Allow system to interact with desktop."

However, again, I recommend choosing another path.

BobbyShaftoe
  • 28,337
  • 7
  • 52
  • 74
0

I had to do something similar recently; a route that I found but discarded due to security concerns is to have the interactive service set self as running in interactive mode and then run the ImpersonateUser function in the win32 API, which I think will provide the benefits of both a user and the interactive session available from the LocalSystem.

Needless to say, if someone broke into a service that did that, they would have total control of the machine.

Paul Nathan
  • 39,638
  • 28
  • 112
  • 212