0

Believe it or not, this question is related to a real, production process. Because the company we are working with is run by cave men, I think, but... Yeah. Anyway.

There is a scheduled task on this machine that connects to an email server (using an IMAP utility we wrote in house) and downloads any attachments that have been sent in the last day. This works just fine when we run it under a user account on the system, but that means we have to keep changing the password (read: it means this process fails once a month when we forget to change the password).

Obviously, the standard procedure would be to run it as a system account so that we don't have to worry about that, and we do have some other jobs that run as NT AUTHORITY\SYSTEM. This one, however, does not. That's because when we try to run this as SYSTEM, it says that it did its job, but the directory that's supposed to contain all of the attachments it downloaded remains empty while the inbox remains full.

IANASA (I am not a sysadmin!): What can I do to make this run? (Preferably without having to set some kind of a reminder on my calendar that says, "Hey, go change the goofy passwords on your batch jobs.")

3
  • System shouldn't have any restrictions the prevent it from running a program and saving files to local disk. Have you tried running your utility as system while logged on interactively to see what gives? I'd use psexec to launch a cmd prompt as SYSTEM and then launch the IMAP downloader from there to watch what happens. Could also add in some debugging using Process Monitor or even WinDbg. Dec 12, 2013 at 18:45
  • Ok, I just Googled PsExec and ... Yeah, I don't think I have any business doing anything involving that tool on our server.
    – archer884
    Dec 12, 2013 at 19:02
  • Lets start with the basics...What version of Windows are you running?
    – Ramhound
    Dec 12, 2013 at 20:02

1 Answer 1

0

Short version: there is no account (SYSTEM included!) that is able to find something that just isn't there.

You guys ready for this? Here's a code snippet from the script this job was running:

Add-Type -Path ($env:UserProfile + '\bin\Email\Email.dll')

...Bet half of you have already figured out why this won't run correctly under NT AUTHORITY\SYSTEM, haven't you.

Because the script was attempting to check the user's home folder for the utility, it failed to find anything remotely executable when the user was set to SYSTEM. We finally noticed this when we dug into our logs and noticed that there weren't any for when the utility was supposed to be running under SYSTEM.

Hopefully this question will save some other poor sap a little time next time the impossible ("Seriously? Something SYSTEM can't do? How is that possible?) happens.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .