Earlier today, I was trying to run a batch file as a scheduled task, using a non-admin service account. It didn't work, but the scheduled tasks interface didn't provide a lot of info to go on.
After double-checking file system permissions, and running Filemon to try and figure out where stuff was failing, I found out that the task scheduler actually creates a log file. By default it seems to live at %SystemRoot%\Tasks\SchedLgU.Txt, but that location can be changed in the registry by modifying the LogPath value at HKLM\SOFTWARE\Microsoft\SchedulingAgent.
That log file contained an error message (well, several...) that quickly lead me to Microsoft Knowledgebase article KB867466. Turns out that on Windows Server 2003 member servers, non-admin users running non-interactively don't have Read or Execute permissions to cmd.exe...
After fixing the permissions, the job ran fine.
That's when I discovered that the batch file was making some assumptions w.r.t. the user's regional settings, so I switched to a VBScript instead. If I'd done that in the first place, I wouldn't have had to spend 15 minutes fighting with the task scheduler, since the permissions issue doesn't apply to cscript.exe...
Oh well.
I was writing some unit tests today where I wanted to start some process asynchronously, but have it automatically exit after a specified number of seconds. Preferably something that's available on a standard W2K3 box, so that I wouldn't be creating any additional prerequisites for other developer boxes or the build machine.
Usually I just use ping -t -n count host for this, but I was also thinking that it would be nice to be able to terminate the process before the timeout. Not sure exactly how I came across it, but somehow I found waitfor.exe lying around in my system32 directory.
WAITFOR uses a mailslot to wait on or send a signal to. The waiting and sending can happen on the same machine, or the signal can be sent across the network.
In one command prompt, you perform the wait:
C:\\> WAITFOR /T 42 SignalName
In another, you send the signal:
C:\\> WAITFOR /SI SignalName
Way nicer than the old-fashioned approach of having process A poll a directory until process B has created a particular file. And, no less important, if the signal is not received within the specified timeout, you get:
C:\\> WAITFOR /T 1 Godot
ERROR: Timed out waiting for 'Godot'.
C:\\>_
:-)
Just a quick reminder to myself, so that I can forget about it...
Fiddler can act as a man-in-the-middle and decrypt SSL traffic, but then System.Net.Security rightfully complains about an invalid remote certificate ("The remote certificate is invalid according to the validation procedure."). This results in a System.Net.WebException "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.".
To prevent this from happening:
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
Just be sure to not include this in production code :-)