I need to stop and start IIS server for TFS build. When do this using .bat file iisreset /stop, similarly for start.
When I do this I get
Access denied, you must be an administrator of the remote computer to use this command. Either have your account added to the administrator local group of the remote computer or to the domain administrator global group.
Please note: This is Windows server 2019
I am already admin of this machine.
I have given read/write access to everyone in this folder.
I have unset EnableLUA to '0' in the registry as told in link for site
Above all these, I restarted machine.
I still get error in TFS build.
When you start a build in TFS the execution of that build is effectively done by a build agent. A build agent is just a service running on any particular machine. So, your batch file that shall start/stop the IIS service will be executed by whatever build agent is running your particular build.
This in terms means that your batch file is executed by the user that is used to run the build service. If that user does not have the necessary admin rights you face this particular error message.
What you need to do is make sure that all accounts that you use to run your build agents have administrative permissions on whatever machine you want to start/stop IIS.
You are trying to do IISRESET in your batch script. You need to be an Administrator as basic right to execute IISRESET command. So the account which the build is running needs to be part of the Admin group on the box.
Other approach is to stop and start w3svc using sc config commands or NET STOP WAS /Y and NET START W3SVC
Both of your answers are correct, I added the 'Network Service' of TFS to admin group of machine. Then build was success. Administrative tools>Computer Management> Local Users and Groups>Groups>
Inside Administrators and Users add 'Network Services'. If you don't find 'Network Service' then change location to your computer node and add them.
Related
We are trying to integrate MicroFocus UFT testing into an Azure DevOps CI\CD pipeline using a self-hosted EC2 build agent (let's call the build agent UftServer). UftServer has MicroFocus UFT One installed and the pipeline uses the MicroFocus Azure DevOps extension see here to start the test.
Everything works as expected when a full screen RDP session is open to UftServer. When the pipeline runs, we can watch UFT One open our application and run the specified test. Results post back to Azure DevOps with pass\fail and life is good.
However, when the RDP session is closed, the UFT pipeline step fails to execute the test. It mentions a credentials error, but the problem clearly seems to be the closed RDP session.
From the test results we assume that a full screen RDP session needs to be active for UFT One to execute the tests properly (it detects the screen resolution so that it knows where certain menus are in our application).
So, rather than open the RDP session to UftServer from my local system (which won't necessarily be open when the pipeline runs), we created a second build agent RDPLauncher in the pipeline (also self hosted EC2), and execute the following script on it before launching the UFT test on UftServer:
$RemoteUftServer = "UftServerIp"
$RemoteUftUser = "Administrator"
$RemotePwSecretId = "uft"
$RemoteUftPw = ((Get-SECSecretValue -SecretId $RemotePwSecretId).SecretString | ConvertFrom-Json).password
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /v "AuthenticationLevelOverride" /t "REG_DWORD" /d 0 /f #to disable cert check
cmdkey /generic:"$RemoteUftServer" /user:"$RemoteUftUser" /pass:"$RemoteUftPw" #to set RDP creds
mstsc /v:"UftServerIp" /admin /f
Write-Host "mstsc command ran successfully, qwinsta results:"
qwinsta
When we run this script manually RDPed into RDPLauncher, the full screen RDP session to the UftServer opens as expected and runs the test.
Further, we can disconnect from RDPLauncher and the RDP session from RDPLauncher to UftServer remains open and the pipeline still runs successfully.
It is great to not have the RDP session open from my local system, but the pipeline still lacks a critical automation piece.
When the pipeline runs the above script on RDPLauncher (rather than me running it manually RDPed into RDPLauncher), it succeeds, but then the UFT test fails as if the session isn't open.
So, from the pipeline, how do we remotely open the full screen RDP session from RDPLauncher to UftServer?
The script above works when I run it from RDPLauncher, but doesn't seem to have the same effect when the Azure DevOps Agent service runs it from the pipeline.
Both build agents are running Windows 10.
Any help is appreciated :)
I suggest you to first configure everything before the pipeline run.
1, Remember the credential.
2, After the above steps, click remember your password after you input the password.
And then, in your pipeline, only need a pipeline definition like the below will be able to connected to the remote server with rdp file(no need other interactive steps.):
trigger:
- none
pool: VMAS #This is a self hosted agent pool, the pipeline is runnning based on a server in this agent pool, and the rdp file is also in this server.
steps:
- script: |
# echo %username%
# mkdir "C:/xxxyyyzzz"
C:\Users\Administrator\Desktop\VM.rdp # Here is the path of the rdp file on my side.
displayName: 'Run a one-line script'
In an azure devops build pipeline running on a self-hosted windows agent, I am trying to execute a tool that run a docker container.
Unfortunately I get this error :
Failed to start: failed to create container: Error response from daemon: CreateFile c:\Users\BUILDAGENT\.aerokube\selenoid: Access is denied.
The build agent is configured with its own windows local user "BUILDAGENT", so he has permissions on the C:\Users\BUILDAGENT\ folder
Looking at the process manager, I see that except com.docker.service, the others docker processes are running with the user that launched the Docker Desktop (my coworker).
If I restart windows and relaunch docker myself, the settings selected by my coworker ("Disk Image Location" for instance), are not restored...
Is there a way to make docker run as a daemon on startup with a specific user (service or system user, but not mine or my coworker) ?
Once this is done I guess I just have to give permissions for that specific user on the C:\Users\BUILDAGENT\ folder to solve my issue, right ?
Update :
I added my BUILDAGENT user in docker-users group, and it solves the permission issue, but I still would like to run docker as a service, instead of login as my local user to launch it with its GUI...
but I still would like to run docker as a service, instead of login as my local user to launch it with its GUI
You could try to create a task scheduler to run docker with that specific user when your PC starts.
Please check this thread How to create an automated task using Task Scheduler on Windows 10 for some more details.
In this case, docker will start automatically every time you start your computer.
I am using the datastax-community-64bit_1.2.5.msi for installing on Windows VM. I am using the silent install command
msiexec /i
C:\ddapplications\cassandra\datastax-community-64bit_1.2.5.msi /quiet
/qn /le C:\ddapplications\cassandra\installlog.txt
If I run the installation command from the command line it installs as expected. No issues.
If I run the command from a Windows Service that runs as LocalSystem, I get the following error.
Is this a known issue? Is there a workaround? I also manually tried creating a group named WORKGROUP and adding the SYSTEM user to that group.
The SYSTEM user exists in the VM.
=== Logging started: 6/7/2013 23:52:23 === Error 1609. An error occurred while applying security settings. WORKGROUP\SYSTEM is not a
valid user or group. This could be a problem with the package, or a
problem connecting to a domain controller on the network. Check your
network connection and click Retry, or Cancel to end the install.
Unable to locate the user's SID, system error 1332
=== Logging stopped: 6/7/2013 23:52:25 ===
Is your VM in a domain? What is the service that you are using to trigger the installer running as?
A possible workaround may be to make that service run as Administrator.
I have just updated jenkins to 1.5. My windows slaves were disconnected during the upgrade and now I cannot connect them again. I start the windows slaves with:
javaws.exe slave-agent.jnlp
I get this error:
I can remote to the windows slaves just fine so they are running.
This is a new, known issue due to this Security Advisory. Additional information, including several fixes/workaround can be found HERE.
Personally, since our Jenkins is on a secured, private network, going to Manage Jenkins -> Configure Global Security, and under Project-based Matrix Authorization Strategy enable “connect” in the “slave” section, for user “Anonymous” was sufficient to get us working.
In order to always assure correct update, the following steps must occur:
How to update Jenkins Slave in Windows
go to services.msc type "je" to find jenkins slave service and stop it from running
do: sc delete jenkinsslave-c__h (or the name the service has)
to know the name of the service, go to services.msc and open "Jenkins Slave" properties (it is auto/ highlighted)
if it is only "marked for deletion" close "Services" window (this will effectively delete the service)
go to c:h\ dir (or the dir where jenkins is running) and delete all files, letting workspace dir untouched
for %i in (*) do if not %i == workspace del "%i"
open "Java Control Panel" (search "Configure Java" on start button) and set Security to Medium
Configure Path where Jenkins worspace will operate at http://server:8080/jenkins/computer/node_to_use/configure
go to http://server:8080/jenkins/computer/node_to_use and run "Launch"
do: file>install as service; ok.
go to services.msc and refresh with F5 in order to appear "Jenkins Slave"
stop the service
open properties, and in the LogOn tab at "This account:" insert ".\user" being the user the admin user of the machine (or as the tested used via GUI login). Insert the password.
Set to automatic start on boot with following conditions:
delayed mode;
2 retries on failure (1 minute interval)
Assure user has needed files and access permissions
Go to Computer Management (right click#My Computer > Manage)
System Tools > Event Viewer > (Windows Logs >) Application > right click and choose Properties > "Overwrite events as needed"
run Jenkins slave
For some months we've run Hudson on a Windows XP "server" under a user account. This means someone manually logs in and starts Hudson via a .bat file (that sets up a few environment variables, then runs java -jar hudson.war)
However a few recent power cuts have resulted in the requirement to have Hudson start automatically at the time the server boots up. So I've turned to looking at Hudson running as a Windows Service. This would allow Hudson to start automatically with Windows, and would not require a specific user account.
I've managed to install it as a service, and I've changed hudson.xml so that the batch file is run rather than java directly. I do this because we build with git on Cygwin and SHELLOPTS=igncr must be set before bash starts java/Hudson.
The service seems to start properly, and the web interface is present and functional. However, it appears that the user that Hudson is now running under is unable to write/modify existing jobs in C:\hudson:
FATAL: Could not checkout 4a121704f178123c36f6ab4e861b3c771953b187
hudson.plugins.git.GitException: Could not checkout 4a121704f178123c36f6ab4e861b3c771953b187
at hudson.plugins.git.GitAPI.checkout(GitAPI.java:382)
at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:529)
at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:521)
at hudson.FilePath.act(FilePath.java:676)
at hudson.FilePath.act(FilePath.java:660)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:521)
at hudson.model.AbstractProject.checkout(AbstractProject.java:833)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266)
at hudson.model.Run.run(Run.java:948)
at hudson.model.Build.run(Build.java:112)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:118)
Caused by: hudson.plugins.git.GitException: Error performing c:\cygwin\bin\git.exe checkout -f 4a121704f178123c36f6ab4e861b3c771953b187
at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:302)
at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:276)
at hudson.plugins.git.GitAPI.checkout(GitAPI.java:380)
... 12 more
Caused by: hudson.plugins.git.GitException: Command returned status code 1: error: git checkout-index: unable to create file .gitignore (Permission denied)
error: git checkout-index: unable to create file .gitmodules (Permission denied)
error: git checkout-index: unable to create file Makefile (Permission denied)
I'm not really a Windows sort of person, but I thought perhaps if I added "Full Access" Security permissions to C:\hudson for the user "LOCAL_SERVICE" then that might fix it. Alas, it did not. I also tried full permissions for the user "Everyone" but that also did not solve the problem.
What am I missing here? Is there any way to allow a process running as a Service unfettered access to a subdirectory on a local disk?
How about you change the user that the service is running as. So create a new "technical" user account whose password nobody knows (except an envelope in your safe) and make this user the owner of all your hudson job folders. This also has the advantage that you can take permissions away from hudson. This way a Hudson job can not act as an admin on your windows machine.
The advantage of a service compared to a scheduled job is, that it restarts when it crashes.
Instead of running it as a service, maybe you should use Task Scheduler to set the process to run at logon, then have the user account auto-login. This is probably going to be much less hassle than dealing with service permissions, especially if you have to communicate with other machines.