I have standalone cluster 6.5.664.9590 on Windows Server 2019 with gMSA security.
Successfully deployed Patch Orchestration Application (POA) v1.4.1.
In GPO set "Notify to download updates".
POA successfully find and download updates, but does not install updates.
The Node Agent NTService does not creates repair tasks for installing updates on the nodes.
Get-ServiceFabricRepairTask empty.
Every ~3 minutes the following line logged in System log:
The Windows Modules Installer service entered the running state.
and after a few seconds, it shows:
The Windows Modules Installer service entered the stopped state.
Link on issue: https://github.com/microsoft/Service-Fabric-POA/issues/34
Add below section in your clustermanifest.
"ClientIdentities": [
{
"Identity": "NT AUTHORITY\SYSTEM",
"IsAdmin": true
}
]
Related
Bash task is giving below error when running on self hosted windows agent -
Windows Subsystem for Linux has no installed distributions.
##[error]The process 'C:\Windows\system32\bash.exe' failed with exit code 1
Windows subsystem is installed and I can execute bask scripts by logging into agent but bash task does not work.
Happy to provide more information if required
bash task in Azure Devops not working on self hosted windows agent
That is because the WSL installed per a specific user, but if we run the self-hosted agent as service, it will using the NETWORK SERVICE/SYSTEM account instead of local user account.
You could try to set Log On As with the specific user (It should be the same user as you installed WSL. Then restart your server.
Detailed step for setting the Log On As with the specific user:
Press the Win + R keys on your keyboard, to open the Run window. Then, type “services.msc” and hit Enter or press OK.
Find the service for the self-hosted agent and right click it, select Properties, switch to Log On tab.
Change the account to the specific user.
For example, I use xxxxxx\leoliu account to login the server 2019:
Then install WSL with that account. After that, I open the services.msc and change the Log On As with that user:
Last but not least, restart your server, just restart the services is not enough.
Now, I could use my self-hosted agent to run the bask task:
Agent Version and Platform
2.173.0
on
centos-release-7-6.1810.2.el7.centos.x86_64
It's a release agent for a deployment pool.
Azure DevOps Type and Version
dev.azure.com (cloud)
What's not working?
# Running run once with agent version 2.160.1
./run.sh --once
Scanning for tool capabilities.
Connecting to the server.
2020-08-25 21:31:02Z: Listening for Jobs
Agent update in progress, do not shutdown agent.
Downloading 2.173.0 agent
Waiting for current job finish running.
Generate and execute update script.
Agent will exit shortly for update, should back online within 10 seconds.
‘/root/azagent/_diag/SelfUpdate-20200825-213148.log’ -> ‘/root/azagent/_diag/SelfUpdate-20200825-213148.log.succeed’
Scanning for tool capabilities.
Connecting to the server.
# this now runs indefinitely
Is there a way to stop the auto update? Multiple agents on production machines are offline and I have, as of now, no idea how to fix that.
agent.log
Edit: It is a Release Agent in a Deployment Group. Also, there is a Github issue now https://github.com/microsoft/azure-pipelines-agent/issues/3093
To resolve the Authentication failed with status code 401 you can try steps below:
1.Create a new PAT with manage permission:
Then reconfigure the agent with config.sh file.
2.If that not works, try creating a new Agent pool to register new agents:
To stop the auto update, you should disable this option (Organization settings=>Agent Pools=>Settings):
We have created an application using Install4j. This application has a service, created by using "Install a Service" action, with "auto start" attribute set.(The application launcher is a "Service" type with unix option "Auto-start service for Linux packages".)
For CentOS7, CentOS6, ,RHEL7, RHEL6 platforms the service starts automatically when the system is rebooted.
For Suse Enterprise Linux 12.x series, the service could not be started on system boot up. It is working fine, when invoked manually by command "/etc/init.d/{service-name} start".
When we check for the deployed files, the service file is copied to /etc/init.d/ folder and corresponding entries K50{service-name}, S50{service-name} files created at /etc/init.d/rc2.d/, /etc/init.d/rc3.d/, /etc/init.d/rc4.d/, /etc/init.d/rc5.d/. The service is turned on by chkconfig for 2,3,4,5 run levels. But when we reboot the machine, this particular service is not even attempted in the startup process.
Please suggest.
Problem: System Center Endpoint Protection keeps deploying itself from SCCM to the computers and servers after I manually delete them, even if the SCCM server got completely removed recently. Though AFAIK the deployment tasks weren't deleted, only the services stopped and SCCM related programs uninstalled. Also the server (Hostname: SCCM_SERVER) was shutdown.
If I open one of the servers and go to Configuration Manager, I see that Assigned management point is still SCCM_SERVER.
Question: Not having been delved into SCCM administration prior, how is this happening? Did it create windows services on each machine? Could there be additional SCCM administration sever running somewhere else? I checked GPO/scheduled tasks - nothing. How does the deployment work? And how do I stop it?
Also, if additional information related to the software/hardware/network is required please ask.
Regards,
Sai
Have you checked the log file EndpointProtectionAgent.log? Maybe it can give us some clues.
If you want to decommission SCCM, you could uninstall the SCCM client.
The correct way is edit the Client Settings node in the Administration workspace first.
Modify the device settings "Install Endpoint Protection client on client computers", choosing False or No will not uninstall the Endpoint Protection client. To uninstall the Endpoint Protection client, set the Manage Endpoint Protection client on client computers client setting to False or No. Then, deploy a package and program to uninstall the Endpoint Protection client.
#About client settings in System Center Configuration Manager
I have followed this guide to install a jenkins slave on windows 8 as a service:
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service#InstallingJenkinsasaWindowsservice-InstallSlaveasaWindowsservice%28require.NET2.0framework%29
I need to run a job that interact with the desktop (run an application that opens a browser etc.). So after I have installed the slave as a service (running jnlp downloaded from the master) I have changed the service "Log on" to "Allow to interact with display".
For some reason its only possible to enable this for the "Local System account" even though its recommended to run the service as a specified user, eg. jenkins.
But nothing happens when I execute the job, the browser is not opened. If I instead stop the service and just launch the slave through the jnlp file the job runs fine - the browser is opened.
Anybody had any luck interacting with the desktop when running a jenkins windows slave as a service?
Services run since Vista in Session 0 and the first user is now in Session 1. So you can't interact any longer. This is called Session 0 Isolation.
Microsoft explains this here and here. You have to use 2nd Program which uses IPC to communicate to the Service.
I had lots of issues running Jenkins in Windows using the service.
Instead I now disable the service and run it from CMD.
So open CMD.
cd C:\Program Files (x86)\Jenkins
java -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar
jenkins.war --httpPort=9091
To resolve it, first create Windows auto-logon as I explain here:
https://serverfault.com/questions/269832/windows-server-2008-automatic-user-logon-on-power-on/606130#606130
Then create a startup batch for Jenkins agent (place it in Jenkins directory). This will launch agent console on desktop, and should allow Jenkins to interact with Windows GUI:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be download from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
EDIT :
If you're getting black screenshots (when using Selenium or Sikuli, for example), create a batch file that disconnects Remote Desktop, instead of closing the RDP session with the regular X button:
%windir%\system32\tscon.exe %SESSIONNAME% /dest:console
Consider running the Java slave server directly at startup and then using something to monitor and restart should the server go down (e.g., Kiwi Restarter).
Please check the services (# TestNode) make sure the "Interactive Services Detection" service is STARTED, by default the startup type is set to Manual, you may like to set it to automatic as well.
After service started, when you run your test in the Test Node, you will see something like the below:
Click on it and choose view the message
You will see the activities happen there. Hope this helps :D
Note: If login with other account and cannot view the Interative Services Detection prompt, restart the service again.
My Jenkins Service runs as user "jenkins" and all I did was to create Desktop folders in: C:\Windows\system32\config\systemprofile\desktop and if 64 bit Windows also in C:\Windows\SysWOW64\config\systemprofile\desktop - then it runs perfectly.
Make sure that Desktop folders are created as such:
%WINDOWS%/System32/config/systemprofile/Desktop
%WINDOWS%/SystemWOW64/config/systemprofile/Desktop
Presence of those can sometimes be mandatory while running some Java software as a Service.