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.")

  • 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. – ssnobody Dec 12 '13 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 '13 at 19:02
  • Lets start with the basics...What version of Windows are you running? – Ramhound Dec 12 '13 at 20:02

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.