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?
Related
VS Code keeps updating. I think it might be my workstations configuration. I have two accounts assigned to me on the domain for security. One for regular usage and a second with elevated privilege's. I login with the regular and have VS Code configured to always start as Administrator which prompts me for my second elevated user credentials.
Can this be causing the issue and what can I do to help VS Code with the update process?
The key seems to be the shortcut to open VS Code. The properties for the shortcut showed it was opening and running in my regular login account profile directory. When I switched the shortcut to my elevated profile account the updates stopped happening every time I opened VS Code.
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
I wrote an agent that runs every 1:00 AM daily, but fails to execute the routine mysteriously. I've checked the agent log and saw that it ran and ends without any error. What I've been thinking about is when I trigger the agent or ran it manually it executes the routine I coded successfully and not when it is scheduled. I really don't know what's the issue there, thanks for help in advance.
there are a few things to try
Check the trigger property on the agent and set it to run on All documents or change it to None. Test both scenarios. There are some issues with this setting.
When you run an agent manually from the notes client or designer you are running it using the credentials from you id file. When running it scheduled you use the credentials from the server.
Make sure your server have enough access to perform what your script does. There is also a setting in the agent for increasing what the script is allowed to perform.
If you have access to the server console you can trigger the agent to run on server using the command: tell amgr run "database.nsf" 'agentname'
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.
Folks,
I've got a strange issue at the moment with a visual studio 2010 built MSI...
When I run the msi, it performs a few tasks, then executes a tool we built - this tool then carries out some more advanced work we couldn't do within a custom task.
The issue here, is then when the msi starts my custom built tool, it doesn't execute it with the same credentials as I start the MSI with (i.e. my administrative login).
Is there a parameter I can pass to an MSI to enforece this? Or perhaps I can pass the credentials to the process when I start it?
My process is started using Process process = Process.Start(procInfo) nothing fancy. I've also noted the ability to pass in a parameterised username/password/domain, but this will vary depending on the user who is installing - can this be extracted from the installer somehow?
Any help (or questions) welcomed.
Dave
EDIT: for clarity... I'm running the MSI under my domain account, and I want my custom process to run under that 'context'. At present, it starts (regardless of whether I start as administrator or not) under the SYSTEM account (rather than mydomain\me). I'm using Windows Server DataCenter edition if that helps...
I should also add, I think this is a policy issue, but I've no idea what to check/where to check...
By default Windows Installer runs custom actions as the current user. If the MSI is elevated, custom actions will run as the elevated user.
Please note that if you are running the MSI as an Administrator, it doesn't mean your custom actions will have full Administrator privileges. On Vista or higher any user can gain Administrator privileges through elevation.
So if your custom actions need Administrator privileges, make sure they use the msidbCustomActionTypeNoImpersonate flag so they run under the local system account.
If this is not the problem and you just need access to the current user data, can you please give me more details?