Unable to run MyDefrag automatically

[KenWA]

I am running Windows XP Pro SP3 as a single user/administrator and have now upgraded to MyDefrag 4.2.6.  My repeated attempts to run an automatic defrag always fails.  I select "Add Task" in Control Panel and use the browse button to enter
"C:\Program Files\MyDefrag v4.2.6\Scripts\OptimizeDaily.MyD".  Select daily, enter time, enter a Password and click "Finish" only to get the following message "The new task has been created, but may not run because the account information could not be set.  The specific error is 0x8007005:Access denied.  Try using the Task page browse button to locate the application."

Needless to say the task does not run as scheduled.  What am I doing wrong?

[jeroen]

I think you are trying to create the scheduled task while being logged in as a normal user? You have to be logged in as administrator to create a task.

p.s. On the internet I see that you can get the same error message when logged in as administrator, but have not set a password for the administrator userid (password is blank).

[KenWA]

I did try being the administrator but it seems it falls down on the password part.
Under the circumstances then I will be unable to schedule a scan.  As a single user I have not set a password and have no intention of doing so.  Strange isn't it how Windows gets more and more complicated and leaves the single ordinary user floundering among all the overkill in security demanded by multi-users.

Thanks for the information.

[amk]

In XP regular user may shedule job, executed under administrator account. For that he must know administrator login/password (on my observation password must be nonempty, "runas" also not works if password is empty).

[jeroen]

Under the circumstances then I will be unable to schedule a scan.

Create a userid that has administrator permissions and a password, for scheduling tasks only.

[Henno]

Something like this is much easier:
schtasks /create /tn "Jeroen Kessels MyDefrag" /tr """"C:\Program Files\Jeroen Kessels\MyDefrag\MyDefrag.exe"""script.myd" /sc "ONIDLE" /I 10 /ru "System"

This will create a job that runs under the local system account.

reg, Henno.

[KenWA]

Never having used User IDs or Administrator IDs I find these suggestions baffling.  What really intrigues me is that I have other scheduled tasks running on a regular basis (Antimalware for instance) which I set up without this performance.  I have two antispyware and 1 antivirus program which perform regular daily updates and scans and they do not demand administrator rights or passwords.  Why is this otherwise beautifully simple and user-friendly program so demanding?  Could this be a suggestion for a rewrite for the next version?

Regards,  Ken

[BloodySword]

Moving files on a drive is a deeply system operation. Do you think that ANY operating system grants a user or even a guest to defragment your drives? And if you run your antivirus scans without administrator rights, then the scanner won't be able to scan all files on your drives.

[Henno]

Never having used User IDs or Administrator IDs I find these suggestions baffling.  What really intrigues me is that I have other scheduled tasks running on a regular basis (Antimalware for instance) which I set up without this performance.  I have two antispyware and 1 antivirus program which perform regular daily updates and scans and they do not demand administrator rights or passwords.  Why is this otherwise beautifully simple and user-friendly program so demanding?  Could this be a suggestion for a rewrite for the next version?

Regards,  Ken

It's all a matter of permissions.
If you choose to use the PC with a user that's in the local administrators group, then that's your choice and software installations will be easy.
However, your system is more vulnerable to changes you don't want, such as malware, viruses etc.
So if you don't want that and you want to log on as a regular user, you have to change the permissions of these tasks to at least Administrator and preferably local system account.

reg, Henno.

[BloodySword]

Unfortunally today working in a user limited environement is not secure anymore because malware and other unwanted software is able to get administrator rights anyways.

[cg]

Never having used User IDs or Administrator IDs I find these suggestions baffling.  What really intrigues me is that I have other scheduled tasks running on a regular basis (Antimalware for instance) which I set up without this performance.  I have two antispyware and 1 antivirus program which perform regular daily updates and scans and they do not demand administrator rights or passwords.  Why is this otherwise beautifully simple and user-friendly program so demanding?  Could this be a suggestion for a rewrite for the next version?

Most application developers today recognize that if they don't adapt to the security present in the operating system, they won't be fully compatible.  You ask why some other programs are able to do things without Administrator Rights or passwords - well most programs that need low-level system access run as a windows service.  For example when I install an AntiVirus program it has to plug into the lowest level of file access to intercept I/O before it gets to the OS.  One of the best ways to program around security is to build your program as a windows service.  When you install it with Administrator rights, the service is then trusted by the OS and is essentially running with full system rights to everything on your computer.   Basically you then have a front end application that gives the end user the ability to interact with your program and it communicates to the service layer which has the full system rights regardless of whether the user does or not.

Unfortunally today working in a user limited environement is not secure anymore because malware and other unwanted software is able to get administrator rights anyways.

Working in a limited environment still is far more secure than not at all.  Malware and unwanted software gets on a person's computer because the user does something they shouldn't.  Like click an executable attachment in an email from someone they don't know.

[boco]

Too much software on Windows still relies on Admin rights. It's simply too annoying for John Do if every 2nd application fails to run due to insufficient permissions.

The problem is of historic nature. In a *NIX environment the tight security was there from the start and all software has been designed to deal with it. The same doesn't hold true for Windows. Previous consumer Windows (..., Win3.1, Win95, 98 and ME) had no restriction at all. Windows NT up to 5.0 was primarily intended for corporate customers. Windows XP was the first NT based OS hitting the masses. User account has Admin rights by default, yeah. Many otherwise good software programs are still in the Win9x era, security-wise.

[poutnik]

Unfortunally today working in a user limited environement is not secure anymore because malware and other unwanted software is able to get administrator rights anyways.

Not always, not easily and not only in windows. If all the systems use admin / user approach, there is the sense.

[poutnik]

Never having used User IDs or Administrator IDs I find these suggestions baffling.  What really intrigues me is that I have other scheduled tasks running on a regular basis (Antimalware for instance) which I set up without this performance.  I have two antispyware and 1 antivirus program which perform regular daily updates and scans and they do not demand administrator rights or passwords.  Why is this otherwise beautifully simple and user-friendly program so demanding?  Could this be a suggestion for a rewrite for the next version?

Regards,  Ken

Those application either may not run in elevated privilegies,
either they use GUI running as common user ( e.g. PerfectDisk) and service under SYSTEM account.
The program does not seem to be demanding more that some its users.     

[cg]

Many otherwise good software programs are still in the Win9x era, security-wise.

You hit the nail on the head!  That's exactly why some programs still have security issues.  Either they write with no security in mind - or they're written with the assumption that everyone has admin rights.  That's becoming less frequent now as Microsoft is taking a similar approach that Linux systems have in that the user doesn't have write access to much of the system - only to the areas that the USER controls.  And such if a program is designed with that in mind - it will work fine in a tightly controlled security environment.

We had to redesign much of the product I develop on because it was initially designed in the Win9x era where everything was FAT32 with no lock down.   Once NTFS and user permissions really started becoming the norm (especially in businesses), we had to adjust.