Windows task scheduler has one author(it is a login user account) and one user account (This account is used when this task is running). Which user is used for windows authentication If this task scheduler used to run the Talend Jobs and these jobs used connecting to remote MSSQL using windows authentication.
When talend jobs are scheduled through task scheduler, it will use run user account for connecting to SQL Server. (Not the author account)
Related
I have an Azure DevOps pipeline with a PowerShell task, which when triggered, successfully creates and configures a Windows Scheduled Task on my Windows Server.
The configuration sets the task to run using an AD Service account, 'Run whether the user is logged on or not' & 'Run with the highest privileges'.
When I try to run this task however, I get the message "The user account does not have permission to run this task."
If I manually create a scheduled task using all the same details, it runs without issue.
I've seen other threads about going into the C:\Windows\System32\Tasks folder, and change the security to update the Owner, but I still get the same result.
Has anyone had any luck setting a Scheduled task up via PowerShell script, and/or what the resolution to the permission issue?
After much tinkering around, I found that the Azure DevOps agent was set up using the default SYSTEM credentials.
I created a new ADO Agent that runs as an admin Service account, and when the Scheduled task was deployed, it ran without issue.
I have create Azure CI Pipeline using Classic Editor where I have Command Line task which open WPF Application, now the issue is when I configure Agent as Service this WPF Application runs in background not showing interface on front, but the same task is running properly when Agent is not running as service.
I require to open WPF Application when running Agent as Service.
I have also tried configuring agent with User Account but still facing same issue. WPF application runs in background. In task manager its showing application running but not appearing on screen.
For e.g :- Below Command I am writting to open exe in Command Line Task of azure devops CI pipeline.
**cd /D D:\Application_Build\Executable
start Sample.exe**
Above command works properly when agent is not running as service, but fail when configure agent as service.
Above command works properly when agent is not running as service, but fail when configure agent as service.
Based on your description, when you run the Agent as interactive mode. Agent will run using the account of the user who run the Agent. Then it will have enough permission to run the script.
When you run the Agent as service, it will use the NT AUTHORITY\SYSTEM account.
The permissions of this account are restricted. So it could cause this issue.
You could create an agent with the admin account or the your user account.
.\config.cmd --unattended --url https://myaccount.visualstudio.com --auth pat --token myToken --pool default --agent myAgent --runAsService --windowsLogonAccount myDomain\adminccount --windowsLogonPassword Password
On the other hand, you could navigate to local system -> Service and find the running agent service.
Then you could change the logon account as admin account.
Here is a doc about create agent.
I created a VSTS task PowerShell on Target Machines which executes a power shell on remote machine. This task is created as a part of release definition.
Logically speaking when I trigger a new release then build agent executes this power shell on remote machine. Let's say target machine is M1 & my build agent is running under a user account u1. I made u1 as administrator on M1.
If the account under which service agent is running is an administrator on target machine, then why do I need to explicitly mention the credentials again. If I do not specify the credentials, then it throw error.
Logically speaking when build agent execute any task then it would have the same identify under which build agent service is running. If that application is an administrator on target machine, then why do I need to pass credentials explicitly. Should it internally pass the identity.
Atul Sureka
Atul
Because it isn’t use the current user (build agent running account) for Resource UserName (uses Admin username) and it fails before deploying machine.
In other words, the check Resource Username action will be passed (will be failed if don’t specify the admin username) if you specify any user for Resource Username (Admin login name) even through the user isn’t existing in target machine. (You can set system.debug to true, then queue builds and compare the log)
I submit a user voice here: VSTS build PowerShell on target machine default user, that you can vote.
Get Cached Credentials in PowerShell from Windows 7 Credential Manager
This shows how to use a logged in user credentials in a powershell script. Can the same process be used in Task scheduler, so that the entered username and pword for the task, is then used by script above to pull the stored credentials.
Using Windows 2012 Task Scheduler which is supposed to support this
Trying to lean away from any storing passwords in encrypted files.
We have a SQL server (Name: SQL) that launches an SSIS job with proxy credentials (a service account), consisting of multiple steps.
One of these steps require files to be put in a local folder on a remote machine (Name: VM) and execute a program that securely copies these files to a service on the net. I have successfully ran both PowerShell and WinRM commands to do this (as administrator), but I need to find a way to run them without being an admin on SQL.
All of these steps work fine, when the service account is a local administrator of both SQL and VM. However, we do not want the service account to be a local admin on SQL.
The command I run is:
Invoke-Command -ComputerName vm.fqdn -ScriptBlock {E:\Share\ThirdParty\FTP_Admin\FtpUpload.bat}
I found a google post suggesting I need to give access to the root/CIIV2 namespace. I gave the service account full control and restarted the WinRM service.
When it fails (NOT running as administrator), the security log gets populated with 4656 event ID's.
Any idea what I can try? Been stumped on this for a while.
Here is the link on the Microsoft technet forums:
http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/70a5a870-b911-4b1a-9c68-e7d91142e511
Long story short - ensure the server has been patched to post SP1 (Server 2008 R2) at least if you are running into these problems.
By default, only administrators have access to the (default) runspace you are connecting to:
On the vm.fqdn, try running:
set-pssessionconfiguration -Name microsoft.powershell -ShowSecurityDescriptorUI
and grant full control to the service account. Restart the WinRM service (just confirm when asked).