views:

1115

answers:

4

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?)

A: 

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
A: 

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
A: 

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
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
A: 

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
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