I am using windows 10 task scheduler to run tasks that require me using my personal user account (its necessary to use my user and not system user because of permission issues - I am part of an organization).
In windows 7 computers everything worked fine but as we upgraded to win 10 I cant run the tasks without using the System user (as mentioned before it doesn't work because of permissions).
I get the following error
Additional Data: Error Value: 2147943726
all I found online was an advice to use the system user other then that nothing :-(
please save my day.
here is a picture of the settings that I want to change.
Today I got the same problem, (HRESULT) 0x8007052e (2147943726) "unknown user name or bad password"
My solution: was to Re-Asign the User on the "Change User or Group" button to get the lattest Active Directory information of the User.
Then I could Run the Task Again...
As a better practice, you could use an "Aplicative" User instead of a
regular User which change more often in regular basis.
If you use your account, it may change your password every some
quantity of days... and you will need to "fix it" again...
If you use an "Aplicative" account, it may change less than regular
User...
You could do this by going to the task tab "General",
then "Change User or Group" and assigning the "Aplicative" account,
then "OK" Button.
I had the same issue with the windows task scheduler.
The reason for the failure is the recent change in the password of the system user which was configured at the time of task creation.
Solution:
Go to properties of task
Under General tab, click on "Change User or Group..."
Enter the username in the field "Enter the object name to select"
This will ask for Authentication, provide your credentials
Thats it !
I had to select the option to "Do not store password. The task will only have access to local computer resources.", which was fine based on what the task was defined as. For me, I suspect some sort of recent patch or security hardening caused this as it seemed to move through our environments at similar but different days.
After reading this post this is what worked for me.
Go to properties of task
Under General tab, at the bottom of that window you will see
Configure for: Change that to the system you are using
(in my case server 2012 R2) hit ok and enter your password.
I know it is a late answer, I had the same issue today, a scheduled task I had created a long time ago and stopped running a week ago. Turns out I had changed the password for my username which was the issue. once I went back to the task, made a chance I was asked for the password again.
Go to Control Panel>System and Security>Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment -> Log on as a batch job
Add the System User.
What I realized is that failure is tied to a password expired policy. The PC got a sort of "frozen" state for the scheduler until a new password is set. The problem is solved once the new password is taken into account by the system.
Highly recommended to perform a little change for the scheduler to ask a new password entry and update the task.
When choosing "Run whether user is logged in or not" on Windows Server 2019 I was getting the error message:
An error has occurred for task Dealer Portal data import. Error message: The following error was reported: 2147943712
There is a Group Policy setting that stops this working, you can disable it with the following steps:
Start > Run > secpol.msc
Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication
Disable that
Now you can save the Scheduled Task
You can also simply edit the properties of each task (you don't have to change anything), hit ok, and you'll be prompted for your new password. "Conveniently", I didn't see a way to do all of them at once.
We had the same problem with Windows 2012 server machines being cloned on a vmware ESX server. The clone/deployment script used sysprep to make every machine individual. With this the users assigned with the scheduled task got screwed up. Our solution was to re-generate the task via batchfile during startup of the machine:
REM Delete the task:
SCHTASKS /Delete /TN "NameOfScheduledTask" /f
REM Create a task to run every 5 minutes
SCHTASKS /Create /TN NameOfScheduledTask /SC MINUTE /MO 5 /TR "some command for task" /NP
Related
I am currently trying to use the Windows Server 2019 Task Manager tool to plan an activity.
The activity should be the execution of C:\Windows\System32\logoff.exe 5 or 10 minutes after the user (Administrator) Autologon.
Automatic Logoff should only occur when Autologon for Administrator executes. For example, everytime the server is restarted after an update, but not when a user enters as Administrator or other specifying his/her password.
I have set the Autologon using a Microsoft app which can be found at this link: https://learn.microsoft.com/en-us/sysinternals/downloads/autologon
I am now struggling trying to identify the correct event ID and the right settings to make all of it work in Task Manager.
For now, I have set this one: C:\Windows\System32\logoff.exe as the event that should be executed upon the occurrence of the AutoLogon, but as for the latter, I have no idea on how to set it.
Could you please help me out finding a solution?
On my PC I use two operation systems Windows 8 and Ubuntu 14.04. I noticed that after booting Linux and then rebooting to Windows, Windows show the wrong time (Windows clock is 2 hours behind).
I checked in the Linux - time is correct.
I checked time settings - both OS have UTC+2 time zone and option to set time from the Internet.
If I correct time in Windows and do not boot Linux everything is O.K. But at list single loading Linux makes time shift.
I have tried to remove the option for setting time from the Internet.
But manual time setting option changed nothing. What should be done to see the same time in the both operating systems?
That's very popular problem.
All you need to do (and that's really the rightest way) is to say Windows that you hardware time is UTC.
To do it just add the following DWORD key to the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
and set its value to 1.
Also you can youse QWORD key instead of DWORD if you have 64bit Windows. But, as far as I know, it's not necessary.
The simplest solution is to set time zone UTC (London) in Linux.
I faced a similar problem, and my solution is quite simple without changing any configs of your operating system.
Requirements: Need to have a internet connection for time sync. Have admin privileges.
You need to enable windows time service
Go to services by typing in the search bar.
Open services
Search for windows time service (W32Time)
W32Time Service
Change the Startup Type to Automatic
Change Startup type
Creating a small bat script file
Open Notepad and create a file with the following command.
w32tm /resync
Save it anywhere with .bat extension. (Remember its location)
Schedule a task
Go to Task Scheduler by typing it in the search bar
Open Task Scheduler
Right click on the empty space > create new task
Create New Task
Give your task a name and description
Change "When running the task, use the following user account" to any admin user or admin group account.
Select "Run whether user is logged on or not"
Check the box for "Run with highest privileges"
Check the box for "Hidden" and "Configure for" = Windows 10
Go to Triggers tab, add the following triggers by clicking on "New..."
First Trigger
"Begin the task:" Select "At startup"
In Advanced settings, check the box for Enabled
Second Trigger
"Begin the task:" Select "At log on"
"Settings" Select "Any user"
In Advanced settings, check the box for Enabled
Go to Actions tab, create a new action by clicking on New...
"Action:" Select "Start a program"
In "Program/script" browse and select the file you created earlier.
And then click OK
Go to Conditions tab
Check the box "Start only if the following network connection is available"
Select your internet network or you can select "any connection" as wild card.
Go to Settings tab.
Check "Allow task to be run on demand"
Check "Run task as soon as possible ..."
Check "If the task fails, restart every" select "1 minute", "Attempts to restart up to:" 3 times
Check "Stop the task if runs longer than:" 3 Days
Check "If the running task does not end when requested, force it to stop"
"If the task is already running, then the following rule applies:"
Select "Do not start a new instance"
I had the same problem recently. My solution is:
First make sure you have the correct time zone
Set BIOS time to local time.
In Linux, edit /etc/default/rcS by replacing UTC=yes with UTC=no.
Reboot.
I've just created two Windows VM's in Azure, one 2012 Datacenter and a 2008 R2 SP1 and i am not able to connect via remote desktop to either of them. Both machines are running under the same cloud service and the RDP ports are mapped to two distinct public ports. Every time i try to connect i get the error message "The logon attempt failed".
Using NMAP in a Linux VM i also have there, i was able to check that the port 3389 is OPEN in both machines. Also, the public RDP ports respond correctly (e.g. are open).
I tried to enter using two different Windows 7 client machines, also with no lock. MSTSC version is 6.3.9600.16415, in both machines. I've used both the .rdp file, downloaded from the "Connect" option in the windows azure dashboard and a brand new RDP connection created by me - same result.
I've tried also to upgrade the VM size from small (1 core, 1.5 GBRam) to medium (2 cores, 3.6 GBRam), restart, setup a new clean windows VM, with different credentials... nothing changed, same result.
The really odd thing is that i was able to connect, after several failed attempts, to one of the VM's, the 2012 one, but only one time - after that, no luck, always "The login attempt failed".
What worked for me was changing the RDP login screen to use a different account, and use the "local account" which is the name of the VM and the username, like so:
TheVMName\TheAdminUsername
Where TheVMName is the name of your VM, and TheAdminUserName is the admin user name you used for that machine.
I was able to find/confirm the latter on the Reset Password screen under the SUPPORT + TROUBLESHOOTING section on the left.
Since Windows 10, you need the domain is automatically set to MicrosoftAccount followed by your email address as username. MicrosoftAccount\My#UserName.com
Instead, the username is like UserName.com\My.
This worked for me.
I have no idea why, but the solution is simple (works every time, at least for me): I was copy-pasting the passwords from a KeePass, as i use this to generate and maintain the huge amount of credentials i use one way or another.
SOLUTION: instead of copy-paste, type the password
The drawback is that i have to use simpler passwords for this access
I've tried to login and failed using windows 8.1 Pro to an azure vm. The message I got repeatedly was "Login Attempt Failed". So my specific problem wasn't that i couldn't connect to the machine but that it couldn't authenticate...even though my my Administrator username and password were correct.
The way I logged into the machine was to provide the host name then the username:
Host\Username
My Azure account did not have a domain controller setup.
It was simply looking for it's local host machine name.
This link helped: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-log-on-windows-server/
May be following can help:
In this screen please select the option "Use a different account":
Further type in "Domain\Username"
TIPS:
- The "Domain" can be found on the "Overview" page for your VM in Azure. It's appearing as:
Public IP Address: [SomeIPValue].
- If you do not remember or have "Username" & "Password".The local admin "Username" & "Password" can be set to get access under:
Azure -> Your VM page -> Support + Troubleshooting -> Reset Password.
I've had a similar problem and it turned out that my password wasn't complex enough.
It was really confusing that Azure Portal even let me create a VM with such a password.
It was resolved by going to the VM page -> Support + Troubleshooting -> Reset Password and specifying a more complex password (both case letters, numbers, special characters and doesn't contain username).
Thanks to Jagjit Singh whose answer pointed me in the right direction. Hope this helps somebody.
I found that, while creating VM, if we put password without any special characters, then it still accepts the password but the login to the VM will fail using that password. It gives an error "The logon attempt failed".
It may work after the "Reset password" option but sometimes it shows "Failed to reset password".
So better to put a proper password.
I know this question is too old, answering for new visitors.
Easy solution would be, you can try to add new user or reset the password from Azure Portal
This will add the user if it does not exist, and you can try logging in with new account.
Issue : "The logon attempt failed". ( Windows azure Machine)
I have tried multiple option didn't help, hence updating this as correct answer , it worked for me .
Solution :- While creating the password/updating for windows azure vm create the password as recommended by Azure with prescribed. Main issue with password .
Steps as below for Issue fix.
Once logged in Azure portal, click on VM windows machine , go to (Support and Troubleshoot)
update the password as recommended by Azure as below
(Password must have 3 of the following: 1 lower case character, 1 upper case character, 1 number, and 1 special character.)
Password :- updated as 13 char which include 1 Capital, Lower Case and Special ,1 number .
Password:- Azureuser#123
After updating the password as Microsoft Suggested it worked for me and able to connect windows machine as below
Able to connect as below
Try about method it should work, if issue please suggest.
We need to have strong password when we create user account for VM ..
It was annoying when I encountered this.I was only succeed when I reset my password step. Issue with portal allows is to create week password while creating VM and validation rules are different while RDP to using week password.Same validation rules applies when we re-setting password.
I'm trying to setup a cron task in Plesk to run a short script every 5 minutes, I've just moved from a managed hosting account to a full access Plesk VPS, and I'm a little lost on a couple of things, this one in particular, when I go to Server > Scheduled Tasks I get a list of 'system users' as below, but I'm not sure under which user to make the cron task, any ideas?
adm
apache
bin
daemon
ftp
games
gopher
.. going all the way down to webalizer
The cron script path is below if that's relevant as to which user to choose -
/var/www/vhosts/mysite.com/httpdocs/scripts/index.php
If you are going to create subscription-level task, than you can create cron/windows scheduler task in:
"Subscriptions" > your subscription > "Websites & domains" > click on "Show advanced operations" > "Scheduled Tasks" > there will be only one name of FTP user of your subscription.
Note: Pay attention to interface changes for Plesk 11.5 and Plesk 12+ - there is no need to open "Show advanced operations".
The latest Plesk 12.5 provide a lot of options to cover most of the task cases:
Plesk 12.5
Other Plesk versions support only "Run a command" option:
Plesk 12.0
Plesk 11.5
If you need just answer, in "Server" -> "Scheduled Tasks" you can choose:
FTP user of your subscription mysite.com
your can choose root, but it's not recommended for security reasons.
For Plesk version below 12.5 to schedule execution of PHP script on Windows there is two ways:
Direct call of php binary with your script as argument.
Path to executable file: C:\Program Files (x86)\Parallels\Parallels Panel\Additional\PleskPHP55\php.exe
Arguments: path to you script like C:\inetpub\vhosts\domain.tld\httpdocs\script.php
Note: Pay attention to interpretation path, ...Additional\PleskPHP55\php.exe it path for PHP 5.5, you can change PleskPHP55 to PleskPHP5, PleskPHP53 or PleskPHP54 to use another PHP version.
Call script via request to your site:
Path to executable file: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments: -c "(new-object system.net.webclient).downloadstring('http://domain.test/script.aspx')"
https://www.motherhost.com/help/creating-or-removing-scheduled-tasks-in-plesk/
Creating a Scheduled Task in Plesk 10:
You can set up Scheduled Tasks in Plesk by doing the following:
Log into Plesk*
Click on the Websites & Domains tab.
Click on Show Advanced Operations (a small grey link in the middle of the page), if the advanced options are not already shown.
Click on Scheduled Tasks.
Select the appropriate system user.
Click on Schedule New Task.
Fill out the form as follows:
Switched On: Check the box to turn on the scheduled task.
Description: A short description to remind you what this scheduled task does.
Scheduler Notification: If you want an email every time this runs, select the appropriate option, otherwise select Do Not Send. You may provide an email address where you want the notifications sent to.
Path to executable file: Specify the path to the file you wish to execute. For Windows servers, it would be something like this:
C:\Program Files (x86)\Parallels\Plesk\Additional\PleskPHP5\php-cgi.exe
Arguments: D:\Inetpub\vhosts\mydomain.tld\httpdocs\myscript.php
For Linux servers with Plesk, ir would be something like this:
/var/www/vhosts/domain.tld/httpdocs/myscript.php
Replace domain.tld with your domain name, and myscript.php with the appropriate subfolder(s) (if any) and filename.
Task Priority: Select Low, Normal or High.
Specify when to run your command by selecting the appropriate checkboxes in the Hours, Days of month, Months or Days of week fields.
Click OK to schedule the task or click Run Now to schedule the task and immediately run it.
You will be taken back to the Scheduled Tasks screen and you should see your new scheduled task listed at the bottom.
Removing a Scheduled Task in Plesk 10
Logging into Plesk*
Click on the Websites & Domains tab.
Click on Show Advanced Operations (a small grey link in the middle of the page), if the advanced options are not already shown.
Click on Scheduled Tasks.
Select the appropriate system user.
Check the box next to the Scheduled Task you want to remove.
Click on the Remove button.
It will load a new page and ask if you really want to deleted it. Check the Confirm Removal box and click on the OK button.
You will be taken back to the Scheduled Tasks screen and it should say: "Information: Scheduled tasks were removed."
Use this command:
php -q httpdocs/scripts/index.php
I have a couple of scheduled tasks that run VBS script. It used to be set to "Run as" the person who has left our company. Obviously, after his account was removed, I had to change the tasks to run as another user.
We have an AD account that I setup to use to "run as" for each task. Tested the tasks by running it, scheduling it to run 2-3 minutes from now, and it worked. So, I scheduled the tasks to run everyday at the certain time. The next day the tasks failed with a following error:
The attempt to log on to the account associated with the task failed,
therefore, the task did not run.
The specific error is: 0x80070569: Logon failure: the user has not
been granted the requested logon type at this computer. Verify that
the task's Run-as name and password are valid and try again.
So, I go in and see that "Run As" logon stays the same, so I re-enter the password and test the task again. It runs fine, which tells me that it recognizes the logon and password used in the "Run As" property. The next day it fails again.
Any suggestions, recommendations at what to look at?
Thanks everyone!
The account your Scheduled Task is running as needs to have the "logon as a batch job" right given to it. Use the Group Policy editor (gpedit.msc) to add that right to the relevant account. Navigate down to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment, and find Logon as a Batch Job. Then, add the account in question to that policy.
If it's helpful to anyone else, I had to set the GPO to enforced for my purposes.