[Squashman]

Sometimes you just need to keep things simple.
I think it is amazing some of the things you do for your customers but sometimes less is more.

Educating your customers on how to do things themselves can go a long way. If you charged them per hour for all the time to develop these scripts, plus paid everyone here who helped you develop that script they may think twice about asking you to do what you are doing.

I am all for automating things as long as it is a simple and easily implemented solution. But, when you have to "Jerry" rig something...(no pun intended), it ends up snowballing into an even larger Hodge-podge of fixes and patches to the point of having so much tape on it, it fails and then nobody knows how to fix it.

[scrfix]

I agree with keeping things simple however I also don't give up with a given task just because it is hard to do. I am the type of person that keeps at something no matter what blockage is thrown in the way.

Make no mistake, this is not just for clients. This is for the technicians and myself as well. Technicians tend to make mistakes when working with clients computers even with proper protocols in place, especially if they are new technicians that are not yet aware of the protocols in place. Anything that I can do to automate a task so that I am not liable for a technicians mistake is well worth the time I spend on it.

I don't think that I would utilize the term "rig" with Jerrys programming. Jerry obviously has skills that supercede my own and I am very grateful that he actually takes his time to help myself and other like me.

Educating customers sounds like a good approach however in actual reality it takes unnecessary time away from the technicians, myself and leaves open room for a now newly supported object because we taught it to them. All of the studying and research that I have done pertaining to this project has been in my spare time. As previously mentioned, if I can learn it I will.

I have thus far learned from this endeavor that:

1. schtasks is not available on XP Home.

2. JT.exe does not support the logon as batch user right if you do not enter a username and password.

3. The API function still does not allow the scheduled task to run properly unless you know the credentials even if you utilize the checkbox.

4. AT.exe will create a task and run automatically under the System only. It will not transfer over a mapped drive.

5. AT.exe does not have the capability of changing its name or many other desired functions so it is for all intents and purposes for this project it is a deprecated program as comparison to schtasks.exe or jt.exe.

6. Many 1000's of other people are looking for a solution to this issue just like me and have not found one.

7. Legally, you cannot just transfer over schtasks from one OS to another.

8. If you utilize any of those combination of the above programs in an attempt to check the run only checkbox, without the proper credentials, the box may check but the task still does not run properly.

9. If you utilize any of the combination to make the scheduled task and then utilize a Macro to check the box as described above, the task will run properly.

10. There are a number of other smaller items not listed here that I have learned from this as well. I would not consider learning anything a waste of time.

As far as payment, once again I agree with you however I am once again grateful for people such as Jerry, myself and everyone else that help others out without reservation.

As far as I can tell, with the help of everyone that has interacted with this project I am the first one to put a work-a-round out for this. There are 3 items out there that claim to be able to accomplish this task but I have attempted 2 out of the 3 and end up with the same issue; it doesn't run the task. The third one is a python conversion script however there was no place to download it and no examples to work with in order to get it working.

I have yet to attempt my Macro not running interactively. Perhaps I can run it hidden and then it becomes a better a work-a-round. I just don't like the fact that it takes the 3 seconds and actually shows the user what is happening. I would rather it didn't. If I run the EXE with no interaction perhaps it will not show it and give the appearance that I am looking for.

I thank everyone that has helped with this project.

[Squashman]

Maybe you can look into using CRON for Windows. It may solve your issue but may also open up a whole new set of problems. There is a couple of different implementations of CRON for Windows out there. For all I know there may be a better Task Scheduler daemon out there then what Windows has.

If you were on a Unix system you would not have these problems with scheduling tasks. CRON just works. I am not sure if it works the same way as it does in Unix on Windows. You would have to test it.

Here are a couple of different ones you could try.
http://www.nncron.ru/
http://www.cronforwindows.com/
http://www.z-cron.com/scheduler.html
http://cronw.sourceforge.net/

This also looked interesting. But probably isn't going to work for what you want to do.
http://www.snapfiles.com/reviews/Kar...nonceaday.html

[scrfix]

Squashman,

Thanks for the wincron idea. I researched that avenue prior to researching the schtasks, jt, at avenue.

The programs need to be installed onto the comptuer. I don't have access to install software on every computer I am working with.

Although off the subject with this new discovery of NSIS, this program is designed to be a windows installer and install other programs automatically. This programmed opened up a whole new world to me. There is a security pack I intall for my clients which includes 5 different pieces of software. If I can program them to install automatically... that would be wonderful.

[TheOutcaste]

Originally Posted by scrfix

3. The task doesn't run. I can only presume it is because of what Jerry mentioned before about the logon as batch user right not being set. I don't know how to check that so I could not verify and I did not hear back from him when I asked above.

Sorry about that, overlooked that post somehow. You can set that right using ntrights.exe, from the Server 2003 Resource kit.
The built-in help doesn't list that right as one it supports, but this KB article does.

I haven't had any luck with it though. I monitored the registry while creating a task, and lsass.exe does set that right in the Security data base when a task is created, and that change was noted in the Event Viewer. That's the only rights change noted.
ntrights also adds the right as evidenced by the Event Viewer.

Doesn't seem to make a difference unless you use the correct password for the account. SchTasks in XP sets the credentials, it doesn't have the switch that Vista does that sets the flag to use the current credentials.

Only way I can see to do it on XP is to program it some flavor of C or .net so you can call the Windows API. That would also solve the problem of schtasks.exe not being included in XP Home.

I still don't see why you can't just create a user to use for running scheduled tasks. You can hide it from the end user fairly well so it's not likely to be deleted. Then you would know the password, and wouldn't have to worry about the credentials.

The following will do just that.

• Creates a ScheduledTasks folder under Windows\System32
• Creates a User Profile folder named TaskAccount under Windows\System32\ScheduledTasks
• Hides these two folders
  Since we are creating the folder first, the folder will be empty. You can put the folder anyplace to hide it
  I chose Windows\System32\ScheduledTasks as an example
• It creates the user TaskAccount
• Hides the user from the Welcome screen and User Accounts control panel.
  This also prevents the Administrator account from vanishing from the Welcome screen if it's the only account.
• Creates the task
• Assigns the batch logon rights

The User account will not appear on the Welcome screen or in User Accounts.
It does appear in control userpasswords2 and in the Local Users and Groups snap in, as well as in the output of Net User.
This could use some more error checking, as it doesn't check to see if the account already exists. The password is in plain text; can't really hide it in a batch file, but you can obfuscate it quite a bit. But adding an echo statement would display it.

Set _Username=TaskAccount
Set _UserPass=Password
Set _ProPath=%SystemRoot%\System32\ScheduledTasks\%_Username%
If Not Exist "%_ProPath%" (
  md "%_ProPath%"
  Attrib +h +s "%_ProPath%"
  Attrib +h +s "%_ProPath%..\"
)
Net User |Findstr /I "%_Username%"
If %Errorlevel%==1 (
  Net User %_Username% %_UserPass% /add /profilepath:"%_ProPath%" /passwordreq:yes /passwordchg:no /fullname:"DO NOT DELETE - Scheduled Tasks Account."
  Net LocalGroup Administrators %_Username% /add
  Net LocalGroup Users %_Username% /Delete
  Reg Add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /V %_Username% /T REG_DWORD /D 0 /F
)
schtasks /create /RU %_Username% /RP %_Userpass% /SC Minute /mo 1 /TN "My Task" /ST 00:30:00 /TR "\"C:\Script Folder\test.cmd\""
ntrights -U %_Username% +R SeBatchLogonRight

The NSIS script you posted looks promising. Haven't had time to look at it yet, but it's already using the ITask and ITaskTrigger calls, so should be easy to add the IScheduledWorkItem::SetFlags and IScheduledWorkItem::SetAccountInformation bits to set the Run only if logged on flag and be able to forgo entering the password.
Looks like the GUID for IScheduledWorkItem is A6B952F0-A4B1-11D0-997D-00AA006887EC, found that here

Looks like a .NET library for Visual Studio can be found here
A New Task Scheduler Class Library for .NET

[scrfix]

Hi Jerry,

The reason I did not want to go with creating a separate username is because it could be seen and removed from control userpasswords2. I also did not want the password being changed from there.

However I did look down that road when you mentioned it before. I found out that I can stop someone from changing their password with: net user username /passwordchg:no
I could not find a way to stop them from deleting the username other than putting in "TaskScheduler - Do Not Delete" as the username.
As far as the plain text password; for this particular application I wouldn't care about that.

I found that library earlier and read over that. Unfortunately, the original article that has all of the details is not available and when I signed up for an account and went to download the zip files, they were not available. I wrote to the writer of the article and never heard anything back. I did try to figure stuff out but hit a dead end with that one.

As far as the API call, NSIS utilizes the API call.
The NSIS is so easy to read and use. It took me less than 1/2 hour to read through some examples and figure out how to program that thing. However once again, I hit a dead end. It created the task, it set the checkbox, the task did not run. If I created the task and then utilized that Macro to check the checkbox then it ran perfectly however at that point in time, I could just utilize schtasks.exe to create the task and then utilize the Macro to check the checkbox and not need NSIS other than if I want an extremely nice installer package which I don't need nor want for this application. Other applications however that NSIS is awesome!

I found that pinvoke.net page as well however the warning detoured me away from attempting anything. I could not find any examples to work with so that led me to a dead end. I did not realize however that NSIS utilized that.

Warning: Part of the Task Scheduler 1.0 Interfaces, which consists of IEnumWorkItems, ITask, ITaskScheduler, ITaskTrigger and IScheduledWorkItem. Generally this is useless - use ITask (which inherits from IScheduledWorkItem) instead. Not all methods have been tested, so be careful!

Perhaps that warning is why NSIS doesn't work.

I will attempt your method of creating another username. I would rather have this working within the same username however I believe that this method is probably one step above the Macro method. I didn't like that method unless it can be hidden. However it is pretty solid. I have tested it on around 10 machines thus far with all success.

I found out that if I utilize the jt.exe instead of schtasks.exe that resolves the xp home issue as well. The working method thus far is utilizing the jt.exe to create the task and then utilizing the macro to check the checkbox. The task will run inside the username. It is not the best method but it works.

I will attempt to work with the method you have provided this weekend.

Thanks Jerry.

[Squashman]

Yeah, but how many people really know about control userpasswords2. Most people are not going to even know it exists.