If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Scheduled Tasks and passwords
Is it possible to schedule a task without providing a user password,
even if it's a single-user XP setup without one? I can't find anything in MS help that directly speaks to the matter. It seems that only scheduled tasks installed from outside, so to speak, such as google updater, are actually accepted and run. Scheduling my own tasks always returns a "maybe-it-won't-run" error message at the end of the wizard, and they don't. Examples are MSE, which I don't have running real time but want to run manually, and JkDefrag.exe, an executable not installed via Control Panel. Thanks. Gene XP/SP3 |
Ads |
#2
|
|||
|
|||
Scheduled Tasks and passwords
I just found the answer:
http://technet.microsoft.com/en-us/kb/kb00310715.aspx Seems strange to set up a scheduler and then not make it available to a large bulk of users who don't use passwords with their XP installations. Gene On Fri, 25 Sep 2009 17:15:45 -0600 wrote: Is it possible to schedule a task without providing a user password, even if it's a single-user XP setup without one? I can't find anything in MS help that directly speaks to the matter. It seems that only scheduled tasks installed from outside, so to speak, such as google updater, are actually accepted and run. Scheduling my own tasks always returns a "maybe-it-won't-run" error message at the end of the wizard, and they don't. Examples are MSE, which I don't have running real time but want to run manually, and JkDefrag.exe, an executable not installed via Control Panel. Thanks. Gene XP/SP3 |
#3
|
|||
|
|||
Scheduled Tasks and passwords
wrote:
gene wrote: Is it possible to schedule a task without providing a user password, even if it's a single-user XP setup without one? Scheduled tasks run under the specified Windows account. To use that account requires logging into it. That you chose to reduce or eliminate logon security doesn't obviate the other security measures in Windows. It seems that only scheduled tasks installed from outside, so to speak, such as google updater, are actually accepted and run. Only if you installed while logged on under an admin-level Windows account because then that installer can modify the registry to, in your example, define NT services. Under an admin-level account, an installer can also, for example, add registry entries to the Windows Firewall to add exceptions for itself (so you never get prompted). Scheduled tasks do NOT require you or the host to actually login before the tasks can be executed. It's not like those tasks are waiting around for you to login. If you schedule a task then it runs at that time whether or not anyone has logged into their Windows account. Task Scheduler runs as an NT service. That means it is running even when no one is logged in. For it to run its tasks, it needs to run them under an account and that means having to prove it has the proper credentials to use that account. Any account with a blank password is an insecure account. Don't expect Microsoft to make everything insecure because it is convenient for you by eliminating the login screen. Google Updater does not run as a scheduled task. It runs as a background job. It is an NT service set to Manual mode which means it will start when a Google program calls it. Google is a company so you never did identify WHICH of their programs you installed that added a scheduled task. It would've helped to know. In a virtual machine, I installed Google Toolbar. It did not add a scheduled task. I then installed Google Earth and it did install a task (by creating a .job file). Did it need a password? No. Why? Because it configured the task to run under the "System" account, not under your own admin or LUA account. Don't need a password for the System account. It has higher privileges than admins but it does require that you were logged in as an admin to create this task. You cannot use the *wizard* to define a task to run as SYSTEM but you can use the 'at' command to add the job under that account; see http://support.microsoft.com/kb/223375. Try running the 'at' command while logged under a limited account. See, it won't run. You get an "access denied" error. For Google to have added the scheduled task that doesn't use a password then it runs under the SYSTEM account and you ran that installer while logged in as an admin. There are many reasons why you must be logged in as an admin to install programs. Google often gets around Windows security regarding permissions for installing programs and to execute them by copying (rather than installing them) into your user profile folder. %userprofile% for your account has both read and write permissions. Executables you copy there can run even when not logged on under an admin-level account. They simply side stepped security by placing their files where the user that logs on has full permissions which is their %userprofile% folder. It is rude behavior and some companies have changed permissions on %userprofile% to prevent this security workaround. Google is not interested in preserving the security of your host. Infiltration doesn't like security. You will be far safer if you create a LUA account and use that from now on as your normal login account. The Administrator account should *never* be used for normal work. It shouldn't even be used as the normal admin-level account. It may be the only account you have left when your user profile(s) gets corrupted for the account under which you normally login. Administrator should only be used in emergencies. In fact, if you plan on using an admin-level account, you should create an alternate admin-level account and log onto that one WHEN you need to perform admin duties. Administrator is for emergencies, alt-admin is account for normal admin duties, and a LUA account should be your normal login account. If you use an admin-level account as your normal login account, it's up to you to control security. After all, you've elected yourself the admin. Scheduling my own tasks always returns a "maybe-it-won't-run" error message at the end of the wizard, and they don't. Examples are MSE, which I don't have running real time but want to run manually, and JkDefrag.exe, an executable not installed via Control Panel. Thanks. How does a program login to an account without using its login credentials? You use a blank password for convenience and thereby reduce security. One convenience feature does not mean it propagates across all security components of the OS. Also, in the example scenario you gave using Google, it is not running a scheduled task under a user account but instead under the SYSTEM account (but you had to be logged in at the time that scheduled job got defined to run under SYSTEM). I just found the answer: http://technet.microsoft.com/en-us/kb/kb00310715.aspx Seems strange to set up a scheduler and then not make it available to a large bulk of users who don't use passwords with their XP installations. Not strange at all. NT-based versions of Windows are MULTI-user operating systems (well, multi-account since concurrent active accounts is a kludge in Windows whereas UNIX was designed for concurrent multi-user) that include account privileges and access control. You aren't running a DOS/9x version of Windows geared to just one user. Care to come up with your statistics regarding "large bulk of users"? If Microsoft lost all its single user licensed, non-corporate, consumer- grade customers, they would still flourish. The bulk of Windows features are not geared toward personal one-user insecure scenarios. |
#4
|
|||
|
|||
Scheduled Tasks and passwords
The length of your reply seems in direct proportion to the absurdity
of providing, or not greying out, a task scheduler that doesn't work with single-user accounts and doesn't give an error message until after users have spent time trying to set up a task. Let's add that MS's tech paper on LUAs is addressed to "business decision makers" and "IT Professionals," hardly your typical single user set up or a very practical way to use a home computer. If you actually have a suggestion to offer, perhaps a workaround, I'm all ears. But do limit yourself to a sentence or two or three (and I'll go back to bottom posting). Btw, the two instances of Google Task Update User (each followed by a alphanumeric and either Core or UA at the end) are situated in the Task Scheduler. If they aren't scheduled tasks, what are they doing there? Gene On Fri, 25 Sep 2009 20:46:14 -0500 VanguardLH wrote: wrote: gene wrote: Is it possible to schedule a task without providing a user password, even if it's a single-user XP setup without one? Scheduled tasks run under the specified Windows account. To use that account requires logging into it. That you chose to reduce or eliminate logon security doesn't obviate the other security measures in Windows. It seems that only scheduled tasks installed from outside, so to speak, such as google updater, are actually accepted and run. Only if you installed while logged on under an admin-level Windows account because then that installer can modify the registry to, in your example, define NT services. Under an admin-level account, an installer can also, for example, add registry entries to the Windows Firewall to add exceptions for itself (so you never get prompted). Scheduled tasks do NOT require you or the host to actually login before the tasks can be executed. It's not like those tasks are waiting around for you to login. If you schedule a task then it runs at that time whether or not anyone has logged into their Windows account. Task Scheduler runs as an NT service. That means it is running even when no one is logged in. For it to run its tasks, it needs to run them under an account and that means having to prove it has the proper credentials to use that account. Any account with a blank password is an insecure account. Don't expect Microsoft to make everything insecure because it is convenient for you by eliminating the login screen. Google Updater does not run as a scheduled task. It runs as a background job. It is an NT service set to Manual mode which means it will start when a Google program calls it. Google is a company so you never did identify WHICH of their programs you installed that added a scheduled task. It would've helped to know. In a virtual machine, I installed Google Toolbar. It did not add a scheduled task. I then installed Google Earth and it did install a task (by creating a .job file). Did it need a password? No. Why? Because it configured the task to run under the "System" account, not under your own admin or LUA account. Don't need a password for the System account. It has higher privileges than admins but it does require that you were logged in as an admin to create this task. You cannot use the *wizard* to define a task to run as SYSTEM but you can use the 'at' command to add the job under that account; see http://support.microsoft.com/kb/223375. Try running the 'at' command while logged under a limited account. See, it won't run. You get an "access denied" error. For Google to have added the scheduled task that doesn't use a password then it runs under the SYSTEM account and you ran that installer while logged in as an admin. There are many reasons why you must be logged in as an admin to install programs. Google often gets around Windows security regarding permissions for installing programs and to execute them by copying (rather than installing them) into your user profile folder. %userprofile% for your account has both read and write permissions. Executables you copy there can run even when not logged on under an admin-level account. They simply side stepped security by placing their files where the user that logs on has full permissions which is their % userprofile% folder. It is rude behavior and some companies have changed permissions on %userprofile% to prevent this security workaround. Google is not interested in preserving the security of your host. Infiltration doesn't like security. You will be far safer if you create a LUA account and use that from now on as your normal login account. The Administrator account should *never* be used for normal work. It shouldn't even be used as the normal admin-level account. It may be the only account you have left when your user profile(s) gets corrupted for the account under which you normally login. Administrator should only be used in emergencies. In fact, if you plan on using an admin-level account, you should create an alternate admin-level account and log onto that one WHEN you need to perform admin duties. Administrator is for emergencies, alt-admin is account for normal admin duties, and a LUA account should be your normal login account. If you use an admin-level account as your normal login account, it's up to you to control security. After all, you've elected yourself the admin. Scheduling my own tasks always returns a "maybe-it-won't-run" error message at the end of the wizard, and they don't. Examples are MSE, which I don't have running real time but want to run manually, and JkDefrag.exe, an executable not installed via Control Panel. Thanks. How does a program login to an account without using its login credentials? You use a blank password for convenience and thereby reduce security. One convenience feature does not mean it propagates across all security components of the OS. Also, in the example scenario you gave using Google, it is not running a scheduled task under a user account but instead under the SYSTEM account (but you had to be logged in at the time that scheduled job got defined to run under SYSTEM). I just found the answer: http://technet.microsoft.com/en-us/kb/kb00310715.aspx Seems strange to set up a scheduler and then not make it available to a large bulk of users who don't use passwords with their XP installations. Not strange at all. NT-based versions of Windows are MULTI-user operating systems (well, multi-account since concurrent active accounts is a kludge in Windows whereas UNIX was designed for concurrent multi-user) that include account privileges and access control. You aren't running a DOS/9x version of Windows geared to just one user. Care to come up with your statistics regarding "large bulk of users"? If Microsoft lost all its single user licensed, non-corporate, consumer- grade customers, they would still flourish. The bulk of Windows features are not geared toward personal one-user insecure scenarios. |
#5
|
|||
|
|||
Scheduled Tasks and passwords
On Sep 25, 7:15*pm, wrote:
Is it possible to schedule a task without providing a user password, even if it's a single-user XP setup without one? *I can't find anything in MS help that directly speaks to the matter. It seems that only scheduled tasks installed from outside, so to speak, such as google updater, are actually accepted and run. Scheduling my own tasks always returns a "maybe-it-won't-run" error message at the end of the wizard, and they don't. Examples are MSE, which I don't have running real time but want to run manually, and JkDefrag.exe, an executable not installed via Control Panel. Thanks. Gene XP/SP3 Is that the message you see: "maybe-it-won't-run" or do you see some other message? It is possible to create a scheduled task to run without a password (yes, to your question), but not recommended by Microsoft. You won't read about it from them since it involves overriding some built in security measures, but that is up to you. Everyone should agree that good security requires users to have passwords, but if it is just you on your system it may be more convenient at times not to have one. Please read the rest here and decide what you want to do. Some things are not suitable for STs - like those that may require a user response to an error or question. So after you create your task, you should of course test it under various conditions. Not so popular advice from me to troubleshoot STs: It is strongly suggested that the task be assigned to a user that has a password (not the Administrator), so create a new user with a password just for tasks or add a password to your account if needed. You can temporarily assign yourself a PW to test and worry about this later. If you don't use an account with a password, you will get an error trying to create the task. The task will still be created, but will not run properly. There is a way around this, but get this working first to be sure your mechanism is not afflicted. Stop the Task Scheduler service. Delete or rename the probably cluttered ST log file: c:\windows \schedlgu.txt Restart the Task Scheduler service to create a new log. Browse to the c:\windows\tasks folder to see all your tasks. The Next Run Time and Last Run Time columns are of interest. Choose to Add Scheduled Task. Create a new task to run Command Prompt once, now. If you don't have a PW, you will get an error trying to create it (more on that later). It will still be created, but will never run. Right click the new Command Prompts task and choose Run and a command window should open immediately. If not, something is wrong. If yes, your mechanism is sound. Look in the log file to see your results. You know how to remove the log now, so that is up to you. Be sure the Task Scheduler service is running again. Try to Run your troublesome task, observe the columns, and the log. If your task fails to run manually, the errors in the log file are the clues to what to do next. |
#6
|
|||
|
|||
Scheduled Tasks and passwords
On Sat, 26 Sep 2009 07:41:53 -0700 (PDT)
Jose wrote: There is a way around this, but get this working first to be sure your mechanism is not afflicted. Stop the Task Scheduler service. Delete or rename the probably cluttered ST log file: c:\windows \schedlgu.txt Restart the Task Scheduler service to create a new log. Browse to the c:\windows\tasks folder to see all your tasks. The Next Run Time and Last Run Time columns are of interest. Choose to Add Scheduled Task. Create a new task to run Command Prompt once, now. If you don't have a PW, you will get an error trying to create it (more on that later). It will still be created, but will never run. Right click the new Command Prompts task and choose Run and a command window should open immediately. If not, something is wrong. If yes, your mechanism is sound. Look in the log file to see your results. Thanks. The error I get is the standard one - "The new task has been created but may not run... The specific error is 0x80070005: Access is denied." Tried Run with the new Command Prompt task and got no response (didn't run at specified time either). Assuming your method works, the question is, what could be wrong? Gene |
#7
|
|||
|
|||
Scheduled Tasks and passwords
On Sep 26, 11:57*am, wrote:
On Sat, 26 Sep 2009 07:41:53 -0700 (PDT) Jose wrote: There is a way around this, but get this working first to be sure your mechanism is not afflicted. Stop the Task Scheduler service. Delete or rename the probably cluttered ST log file: *c:\windows \schedlgu.txt Restart the Task Scheduler service to create a new log. Browse to the c:\windows\tasks folder to see all your tasks. *The Next Run Time and Last Run Time columns are of interest. Choose to Add Scheduled Task. *Create a new task to run Command Prompt once, now. *If you don't have a PW, you will get an error trying to create it (more on that later). *It will still be created, but will never run. Right click the new Command Prompts task and choose Run and a command window should open immediately. *If not, something is wrong. *If yes, your mechanism is sound. *Look in the log file to see your results. Thanks. *The error I get is the standard one - "The new task has been created but may not run... The specific error is 0x80070005: Access is denied." * Tried Run with the new Command Prompt task and got no response (didn't run at specified time either). Assuming your method works, the question is, what could be wrong? Gene Sounds like it is working fine. You can create a new account with a PW just for STs. You can assign your account a PW and use it, and still have the system to log you in automatically when XP starts (convenient). If your Administrator account does not have a PW, you can create a password and use that, but if you ever forget the Administrator password and need it you will regret forgetting it, followed by regretting assigning one in the first place. For STs, even the Administrator user assignment must have a PW. You can assign your task the NT AUTHORITY\SYSTEM account when creating it (or modify the Properties). No PW required since this is a system account. Look at the Properties of any existing tasks - they may be using that already. If you assign your task to someone else, you can manually run it and it shows running, but may not "see" it so you can then check the Task Manager and ST log to see what it is doing. The command prompt for example - if you use NT AUTHORITY\SYSTEM, it will run, but you won't see it since you are not logged in that way. This is why you may want to test your mechanism by assigning yourself a PW temporarily and get the command task to run and open a command window, then work on your new task. |
#8
|
|||
|
|||
Scheduled Tasks and passwords
On Sat, 26 Sep 2009 10:04:37 -0700 (PDT)
Jose wrote: Sounds like it is working fine. You can create a new account with a PW just for STs. You can assign your account a PW and use it, and still have the system to log you in automatically when XP starts (convenient). This is why you may want to test your mechanism by assigning yourself a PW temporarily and get the command task to run and open a command window, then work on your new task. Set up a second user account with admin privileges and the command prompt task ran fine. As did the defragger I wanted to schedule. The MSE task has a syntax error that I'm researching. Then I came across a registry hack to turn the password-required feature off with Scheduled Tasks, as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa Value name: limitblankpassworduse, Type: REG_DWORD, Data: 0 (disabled) 1 (enabled) Is there any downside to disabling it, assuming an assortment of anti-malware programs? One thing I notice after disabling it (in non-password account) is that when the defragger runs, it runs entirely in the background, no interface onscreen, unlike the password account (and normally). Does that seem right? Thanks, Gene |
#9
|
|||
|
|||
Scheduled Tasks and passwords
On Sep 26, 4:51*pm, wrote:
On Sat, 26 Sep 2009 10:04:37 -0700 (PDT) Jose wrote: Sounds like it is working fine. You can create a new account with a PW just for STs. You can assign your account a PW and use it, and still have the system to log you in automatically when XP starts (convenient). This is why you may want to test your mechanism by assigning yourself a PW temporarily and get the command task to run and open a command window, then work on your new task. Set up a second user account with admin privileges and the command prompt task ran fine. *As did the defragger I wanted to schedule. *The MSE task has a syntax error that I'm researching. Then I came across a registry hack to turn the password-required feature off with Scheduled Tasks, as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa Value name: limitblankpassworduse, Type: REG_DWORD, Data: 0 (disabled) 1 (enabled) Is there any downside to disabling it, assuming an assortment of anti-malware programs? One thing I notice after disabling it (in non-password account) is that when the defragger runs, it runs entirely in the background, no interface onscreen, unlike the password account (and normally). *Does that seem right? *Thanks, Gene This is not in my list, but sounds interesting, but also threatening - here's why from a Google search: http://www.derkeiler.com/Newsgroups/...4-08/2498.html There are other results that read to the effect that it opens a wide hole in your security where a remote user/malware, FTP sites, Telnet, Terminal Services, etc. may connect to your machine over the Internet - they don't need a password either! Microsoft documentation doesn't even want to talk about it. So why is it there?! Even the NT_AUTHORITY method has a little eeeew factor to it, but it is okay for me here and sometimes people don't go for the more sensible options and insist on no passwords. I think there is some other way that is more convoluted, so I don't even have it in my notes - too messy. I would rather try to think of ways to do things without circumventing security. I don't use STs or JKdefrag, but that product has a WWW page and about halfway down they talk about using a ST: http://kessels.biz/JkDefrag/ Good find though - I know more now than I did. |
#10
|
|||
|
|||
Scheduled Tasks and passwords
On Sat, 26 Sep 2009 17:41:09 -0700 (PDT)
Jose wrote: This is not in my list, but sounds interesting, but also threatening - here's why from a Google search: http://www.derkeiler.com/Newsgroups/...4-08/2498.html There are other results that read to the effect that it opens a wide hole in your security where a remote user/malware, FTP sites, Telnet, Terminal Services, etc. may connect to your machine over the Internet - they don't need a password either! Microsoft documentation doesn't even want to talk about it. So why is it there?! Even the NT_AUTHORITY method has a little eeeew factor to it, but it is okay for me here and sometimes people don't go for the more sensible options and insist on no passwords. I think there is some other way that is more convoluted, so I don't even have it in my notes - too messy. I would rather try to think of ways to do things without circumventing security. I don't use STs or JKdefrag, but that product has a WWW page and about halfway down they talk about using a ST: http://kessels.biz/JkDefrag/ Good find though - I know more now than I did. Thanks for the help. I didn't know about the defrag's later versions or name change. Gene |
#11
|
|||
|
|||
Scheduled Tasks and passwords
gene wrote:
The length of your reply seems in direct proportion to the absurdity of providing, or not greying out, a task scheduler that doesn't work with single-user accounts And therein lies the crux of your hypothesis. NT-based versions of Windows are *not* single-user operating systems. That you use it that way doesn't mean that's is how it was designed. You can use a screwdriver as a hammer. You're using a rather large OS for your personal needs; i.e., you limit the functionality of a large OS to your specific needs. You might buy a SwissChamp Swiss Army knife (see http://tinyurl.com/2b5bgx) but never actually use more than a third of this "blades", and yet it might not have exactly the tool set that you would design just for personal use. and doesn't give an error message until after users have spent time trying to set up a task. It won't until it tries. As far as I know, the TS wizard only queries the SAM database regarding login credentials when you attempt to enter them during the wizard (you get prompted after creating the job for the login credentials). It never verifies that the job will actually run under that account specified within the job. It doesn't know that until runtime. For example, you can create jobs for existing accounts but which won't run now but you aren't done completing your setup so that job, when it does run, will run okay then. Let's add that MS's tech paper on LUAs is addressed to "business decision makers" and "IT Professionals," hardly your typical single user set up or a very practical way to use a home computer. While Microsoft did come up with "home" editions of their Windows product (which crippled some features), it was a derivative of a product that was primarily geared toward corporate use and management. The single-user schema died with the DOS/9X versions of Windows. If you actually have a suggestion to offer, perhaps a workaround, I'm all ears. But do limit yourself to a sentence or two or three (and I'll go back to bottom posting). You already found the answer: you must provide *complete* login credentials for the account under which you want to run the scheduled tasks (with the exception of the SYSTEM account but you cannot use the Task Scheduler wizard for that). Btw, the two instances of Google Task Update User (each followed by a alphanumeric and either Core or UA at the end) are situated in the Task Scheduler. If they aren't scheduled tasks, what are they doing there? You first mentioned "Google Updater" and that runs as an NT service (so it gets rolled under one of the svchost process instances that you see in Task Manager's Processes tab). Now you're mentioning other tasks (which, I believe, are what I saw when Google Earth was installed). Saying "Google Updater" didn't provide a clue as to which of Google product's that you installed as that utility is included in several of them. The scheduled tasks you now mention are probably from you installing Google Earth (but that is not conclusive since I didn't install all of Google's software programs and you didn't mention which one you installed). They are scheduled tasks but have you *looked* under which account they are executed? If the SYSTEM account then the installer used the 'at' command or similar to create the .job file for that scheduled task (and no login credentials are required for SYSTEM but then you had to be logged under an admin-level account when you ran that installer). If not the SYSTEM account, the installer can use the crypto API to get your login credentials to add them to the .job file that it created (while you were logged on as an admin-level user). If you're interested in learning more about Windows security from participants in newsgroups, visit the: microsoft.public.windowsxp.security_admin group I've seen users there that are far more intimate with the inner workings of Windows and its security mechanism than I. Since you got the answer (which you didn't want but is still the answer), I don't see the point of further trying to explain why someone else's code that is geared towards a mass community of users doesn't do exactly what you want it to do. |
#12
|
|||
|
|||
Scheduled Tasks and passwords
|
#13
|
|||
|
|||
Scheduled Tasks and passwords
On Sun, 27 Sep 2009 13:16:37 -0300
John John - MVP wrote: Then I came across a registry hack to turn the password-required feature off with Scheduled Tasks, as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Lsa Value name: limitblankpassworduse, Type: REG_DWORD, Data: 0 (disabled) 1 (enabled) Is there any downside to disabling it, assuming an assortment of anti-malware programs? Yes, this can potentially open a security hole the size of Texas on your machine! If you do not restrict the use of blank passwords to console logon only you should make sure that Remote Desktop is not enabled! The real fix to the this password problem is to properly password protect your user account! Use a good strong password on all your accounts and use the Auto Logon feature if you wish to logon without having type your password. Accounts with null passwords are nothing but problems waiting to happen. I didn't specify that this is XP Home, which doesn't have Remote Desktop. I was unaware of the Auto Logon feature and in the zillions of articles I've come across about passwording accounts have never seen it mentioned as a practical method for single users to get around the login screen. Thanks. Gene |
#14
|
|||
|
|||
Scheduled Tasks and passwords
MS explicitly designed and marketed and sold XP for a variety of user
setups, one of which was as a single-user OS (esp. XP Home), and knows well from its help lines and from other sources how XP is being used. Are you saying that MS knowingly misrepresented its product? Your monikor Vanguard and length of posts suggests someone who once learned the Leninist notion of propaganda as being the conveying of many ideas to (relatively) few people, but has yet to figure out that doing so doesn't necessarily require the use of many words. First, however, I'd suggest your time would be well spent on a notion Lenin was big on, namely learning how to think (one of its useful byproducts is being able to judge better when to go long or short). -G On Sat, 26 Sep 2009 23:17:26 -0500 VanguardLH wrote: gene wrote: The length of your reply seems in direct proportion to the absurdity of providing, or not greying out, a task scheduler that doesn't work with single-user accounts And therein lies the crux of your hypothesis. NT-based versions of Windows are *not* single-user operating systems. That you use it that way doesn't mean that's is how it was designed. You can use a screwdriver as a hammer. You're using a rather large OS for your personal needs; i.e., you limit the functionality of a large OS to your specific needs. You might buy a SwissChamp Swiss Army knife (see http://tinyurl.com/2b5bgx) but never actually use more than a third of this "blades", and yet it might not have exactly the tool set that you would design just for personal use. and doesn't give an error message until after users have spent time trying to set up a task. It won't until it tries. As far as I know, the TS wizard only queries the SAM database regarding login credentials when you attempt to enter them during the wizard (you get prompted after creating the job for the login credentials). It never verifies that the job will actually run under that account specified within the job. It doesn't know that until runtime. For example, you can create jobs for existing accounts but which won't run now but you aren't done completing your setup so that job, when it does run, will run okay then. Let's add that MS's tech paper on LUAs is addressed to "business decision makers" and "IT Professionals," hardly your typical single user set up or a very practical way to use a home computer. While Microsoft did come up with "home" editions of their Windows product (which crippled some features), it was a derivative of a product that was primarily geared toward corporate use and management. The single-user schema died with the DOS/9X versions of Windows. If you actually have a suggestion to offer, perhaps a workaround, I'm all ears. But do limit yourself to a sentence or two or three (and I'll go back to bottom posting). You already found the answer: you must provide *complete* login credentials for the account under which you want to run the scheduled tasks (with the exception of the SYSTEM account but you cannot use the Task Scheduler wizard for that). Btw, the two instances of Google Task Update User (each followed by a alphanumeric and either Core or UA at the end) are situated in the Task Scheduler. If they aren't scheduled tasks, what are they doing there? You first mentioned "Google Updater" and that runs as an NT service (so it gets rolled under one of the svchost process instances that you see in Task Manager's Processes tab). Now you're mentioning other tasks (which, I believe, are what I saw when Google Earth was installed). Saying "Google Updater" didn't provide a clue as to which of Google product's that you installed as that utility is included in several of them. The scheduled tasks you now mention are probably from you installing Google Earth (but that is not conclusive since I didn't install all of Google's software programs and you didn't mention which one you installed). They are scheduled tasks but have you *looked* under which account they are executed? If the SYSTEM account then the installer used the 'at' command or similar to create the .job file for that scheduled task (and no login credentials are required for SYSTEM but then you had to be logged under an admin-level account when you ran that installer). If not the SYSTEM account, the installer can use the crypto API to get your login credentials to add them to the .job file that it created (while you were logged on as an admin-level user). If you're interested in learning more about Windows security from participants in newsgroups, visit the: microsoft.public.windowsxp.security_admin group I've seen users there that are far more intimate with the inner workings of Windows and its security mechanism than I. Since you got the answer (which you didn't want but is still the answer), I don't see the point of further trying to explain why someone else's code that is geared towards a mass community of users doesn't do exactly what you want it to do. |
#15
|
|||
|
|||
Scheduled Tasks and passwords
|
Thread Tools | |
Display Modes | |
|
|