Windows - Error starting GLPI Agent service

[ngaillard-gantois]

Bug reporting acknowledgment

Yes, I read it

Professional support

Yes, I know

Describe the bug

On Windows startup, many users get an error 0x000000424 with the message indicating an error to open GLPI Agent service.

Affected OS for now is Windows 10 Pro and Windows 11 Pro. Agent is installed via GPO with provided VBS script.
GLPI Agent version from 1.6 to 1.7.1 seems to be affected.

I didn't find helpful events in Event Viewer at first glance.

To reproduce

1. Start the computer and logon
2. Error happening

Expected behavior

Normal start without error

Operating system

Windows

GLPI Agent version

1.7, 1.6.1, 1.6

GLPI version

Not applicable

GLPIInventory plugin or FusionInventory for GLPI plugin version

GLPI Inventory v1.3.3

Additional context

No response

[g-bougard]

Hi @ngaillard-gantois

this is the first time I heard about such issue. Maybe something in your conf is triggering an issue.

Have you a screenshot of the error users receive ? Is GLPI-Agent service running after the error is reported ?

[ngaillard-gantois]

Please find the message :

Currently I don't know if service is running after the error but I will check next time if users report it.
We use this setup options right now 👍

SetupOptions = "/quiet AGENTMONITOR=1 ADDLOCAL=ALL RUNNOW=1 SERVER='https://glpi.app.gantois.local/'"

[g-bougard]

Okay, so indeed, this is a problem related to GLPI-AgentMonitor. It fails to access GLPI-Agent service.

I think this can happen if the service failed to start or is still not fully started when the user logs. I'm not sure, @redddcyclone have you any clue to understand why such error can occur in GLPI-AgentMonitor?

@ngaillard-gantois You still can disable GLPI-AgentMonitor on computers where it happens too often.

P.S.: @redddcyclone probably the error message should still be more accurate so users knows the error is identified by GLPI-AgentMonitor

[redddcyclone]

Hi all

@ngaillard-gantois could you execute the command sc.exe query glpi-agent in both user context and administrator (elevated) context and post both outputs here?

@g-bougard Error 0x00000424 is ERROR_SERVICE_DOES_NOT_EXIST. The only instances I've seen this error on my tests were when the service literally wasn't installed. If the service is starting or failed to start, the Monitor shows this status correctly.
Also, I will work on improving the Monitor errors.

[g-bougard]

So maybe the agent installation just failed. @ngaillard-gantois you'll have to verify if agent service is really installed on the related computers. And maybe just reinstalling the agent can fix the problem.

[ngaillard-gantois]

I will communicate with our users to call us right when the error happening.
However, if the update or reinstall of the agent take too much time, can this error happen ?

[redddcyclone]

@g-bougard I have just commited the change you requested. GLPI Agent Monitor now prints the error message together with the code and I replaced the error message box caption from just "Error" to "GLPI Agent Monitor - Error"

[ngaillard-gantois]

I checked on two computers and service is not present when I use sc.exe query glpi-agent

[g-bougard]

Hi @ngaillard-gantois

so the agent service has not been enabled or it fails to start. Can you figure out why ? Is it set to manual starting or did you forget to set a server ? Can you export the HKEY_LOCALMACHINE/Software/GLPI-Agent and share it (obfuscating the server config or any sensible data) ?

[ngaillard-gantois]

I just checked on affected computer, service is not present but the registry value exist.

I think the agent fails to reinstall or reconfigure properly on update, but not on all computers.

[g-bougard]

Also check the Installer subkey. Then check also the C:\Program Files\GLPI-Agent\logs\glpi-agent.log file. Is it empty or is it reporting any error and is it reporting it stops ? Maybe the agent just fails to start if it tries at a moment a required resource like network is not available.

[ngaillard-gantois]

This is installer subkey :

On agent log, the last line is [Thu Jan 11 10:13:58 2024][info] GLPI Agent exiting (5148) and since this computer have the problem. But when I launch the VBS script with Verbose = Yes, i get this message :

[g-bougard]

Can you run the script with cscript from an administrative console ? This will give you a better log on output you can share here:

cscript //nologo glpi-agent-deployment.vbs

[ngaillard-gantois]

I tried but this time installation is done correctly (I see the service in Windows). I will try on another affected computer with AGENTMONITOR=1 (last time I set it to 0 expecting to remove the message to user, but it's not working anyway...)

[g-bougard]

Hi @ngaillard-gantois

just a point I remember, are you eventually using an old vbs ? I mean, did you use the same vbs from an older version for which you just updated the agent version ?
If yes, can you download the latest vbs and use it after you updated it to use your private options ?
It was enhanced for v1.6 with a better handling of installation errors.

[ngaillard-gantois]

I have the latest version of VBS since the deployment of 1.6.1. I have checked another computer today and no problem with cscript after set Reconfigure to Yes. On reconfigure = No, the VBS say GLPI agent is already installed but without service on the computer.

I will check with the users in start of next week to see if it's ok or not.

[ngaillard-gantois]

Today I have the same error on my computer after I reboot, but the service is present (with sc.exe query glpi-agent). I think this time the message appears on GPO execution and reconfiguration of GLPI agent. I don't have more information with other users right now, but I will continue to track this issue in our company.

[mrgeppetto]

I was having a similar problems trying to update all our agents on our network. Using PDQ Deploy, I ended up running a script to stop the glpi-agent process from version 1.5 and uninstall using the 1.5 installer and then running the 1.7.1 installer. So far this has been the only way without getting some weird error. I havent noticed any other errors and the new services seems to exist. We are using the agent-monitor and it has it's own process. This is my first time updating the agents remotely but it seems like once we finish the re-install, the computer needs to be restarted for the agent monitor to relaunch. So what my steps were

1: Script to stop-process on "glpi" to stop -- Stops all active glpi processses
2: Uninstall using the msi installer of the currently installed version
3: Install the new version of the glpi agent

If you have the agent monitor you need to restart the computer which I will do during off hours.

[teckoppt]

Hi,

Try this, change script option like print.

After that, unninstall GLPI Agent and reboot computer.

[MarcSamD]

Hi there,
I have similar issue and didn't find the root cause but still have some findings and guess below:

1. This issue does not appear on manual installation of the .msi,
2. This issue frequently appear on upgrade of GLPI Agent via GPO or scheduled task (both using the new VBS script),
3. Thus it is very likely that one of the criteria for this issue to happen is to have the VBS script run using the user "system".

MSI debug logs comparison between a failed installation (left) and a successful installation (right).

Conclusion: under some circumstances (system user and other criteria tbd), the installation of glpi-agent service fails (either because the former version of this service has not been properly removed, either for another reason tbd).

[g-bougard]

Hi @MarcSamD

2. This issue frequently appear on upgrade of GLPI Agent via GPO or scheduled task (both using the new VBS script),

when you said "both using the new VBS script", can you confirm the version you're using ? or when did you download the version you modified ?

Generally on windows, this kind of service installation error also happen when a file wasn't released by the operating system. This may happen for example if a service thread is blocked and still running so it locked files to be replaced. Were there any other errors in the log before that one ?

Can you share from that log all the line related to a custom action containing "ServiceConfig" in its name ? i.e. "SchedServiceConfig", "ExecServiceConfig" & "RollbackServiceConfig". This may give some clue to understand if something is wrongly handled by WixToolSet service configuration custom action.

[MarcSamD]

Hi @g-bougard

The VBS script that I used is the Dec 22, 2023 one (feat: GLPI Agent 1.7.1 release).

The service error in my previous screenshot is the first error and difference between a good install and a failure. See below the others lines:

MSI debug logs comparison between a failed installation (left) and a successful installation (right).

[g-bougard]

To be sure, can you share the Windows OS version for each of that clients ?

You can check the MSI log for such property lines:

...
Property(C): VersionNT = 1000
...
Property(C): VersionDatabase = 200
Property(C): VersionMsi = 5.00
Property(C): VersionNT64 = 1000
Property(C): WindowsBuild = 22621
Property(C): ServicePackLevel = 0
Property(C): ServicePackLevelMinor = 0
Property(C): MsiNTProductType = 1
...
Property(C): MsiNetAssemblySupport = 4.8.9032.0
Property(C): MsiWin32AssemblySupport = 10.0.22621.2506
Property(C): RedirectedDllSupport = 2
Property(C): AdminUser = 1
Property(C): MsiRunningElevated = 1
Property(C): Privileged = 1
Property(C): USERNAME = Windows User
Property(C): DATABASE = C:\Windows\Installer\212bf53.msi
Property(C): OriginalDatabase = C:\Windows\Installer\212bf53.msi
Property(C): VersionHandler = 5.00
Property(C): UILevel = 5
...

Even AdminUser, MsiRunningElevated, Privileged and USERNAME are interesting to know. You may also check the differences between the working and failing case for that properties.

[MarcSamD]

All the properties are the same, the only difference is the user (system vs normal admin user).

Details of the differences:

All the *Folder properties will be C:\Windows\system32\config\systemprofile\* vs C:\Users\username\AppData\*
And Property(N): LogonUser = SYSTEM , Property(N): UserSID = S-1-5-18 vs Property(N): LogonUser = username , Property(N): UserSID = S-1-5-21-123456-123456-123456

Details of the same:

Property(N): ProductState = 5
Property(N): CLIENTUILEVEL = 3
Property(N): REMOVE = ALL
Property(N): MsiSystemRebootPending = 1
Property(N): VersionDatabase = 200
Property(N): VersionMsi = 5.00
Property(N): VersionNT64 = 603
Property(N): WindowsBuild = 9600
Property(N): ServicePackLevel = 0
Property(N): ServicePackLevelMinor = 0
Property(N): MsiNTProductType = 1
Property(N): WindowsFolder = C:\Windows\
Property(N): WindowsVolume = C:\
Property(N): System64Folder = C:\Windows\system32\
Property(N): SystemFolder = C:\Windows\SysWOW64\
Property(N): RemoteAdminTS = 1
Property(N): GPTSupport = 1
Property(N): OLEAdvtSupport = 1
Property(N): ShellAdvtSupport = 1
Property(N): MsiAMD64 = 6
Property(N): Msix64 = 6
Property(N): Intel = 6
Property(N): AdminUser = 1
Property(N): MsiTrueAdminUser = 1
Property(N): TTCSupport = 1
Property(N): MsiNetAssemblySupport = 4.8.4084.0
Property(N): MsiWin32AssemblySupport = 6.3.19041.3636
Property(N): RedirectedDllSupport = 2
Property(N): MsiRunningElevated = 1
Property(N): Privileged = 1
Property(N): USERNAME = pc
Property(N): DATABASE = C:\Windows\Installer\2ab764b1.msi
Property(N): OriginalDatabase = C:\Windows\Installer\2ab764b1.msi
Property(N): UILevel = 2
Property(N): Preselected = 1
Property(N): ACTION = INSTALL
Property(N): ROOTDRIVE = D:\
Property(N): CostingComplete = 1
Property(N): OutOfDiskSpace = 0
Property(N): OutOfNoRbDiskSpace = 0
Property(N): PrimaryVolumeSpaceAvailable = 0
Property(N): PrimaryVolumeSpaceRequired = 0
Property(N): PrimaryVolumeSpaceRemaining = 0

[g-bougard]

Hi @MarcSamD

Property(N): WindowsBuild = 9600

Are you telling this problem occurs on a Windows 8.1 OS or Windows Server 2012 ? If yes, can you reproduce the problem on a more recent OS version ? To be honest, I won't investigate such problem on a such old system as the real problem could be related to a still fixed system bug.

[MarcSamD]

Hi @g-bougard , no the OS is Windows 10 Enterprise 22H2.

WindowsBuild = 9600 is not reserved only for Windows 8.1. Windows 10 can be from 9400 and higher and in fact it seems that all the Windows 10.0 family share the same WindowsBuild 9600.
VersionNT64 = 603 is for the Windows based on Windows 10.0

In summary due to changes in the behaviour of Windows 10 it is not possible to reliably identify a Windows 10 Operating System from within an MSI.

[g-bougard]

Oh yes, I remember now they made some changes against that number. So MSI is not sharing the right buildnumber.

Can you test and reproduce the problem with a nightly build ? If you can, I'll propose you to test a build without the ExecServiceConfig custom action as it seems to fails. That custom action is used to configure the service restart in case of failure. I guess this is just a symptom as it seems to fail because the service seems to have been marked for deletion if I trust the error message. Do you see any message before that error which explains why the service has been marked for deletion where it should just have been deleted ? I think this can only happen if a service used file is still opened.

Would you mind to share the failing log so I can dig myself in it ?

[MarcSamD]

1. I did reproduce the issue with a nightly build (1.8-gitb99231f3).

2. There are error messages before, about failing to stop the service:

MSI (s) (40:D0) [16:51:44:258]: Executing op: CustomActionSchedule(Action=EndTask,ActionType=3137,Source=BinaryData,Target=WixQuietExec,CustomActionData="C:\Windows\SysWOW64\schtasks.exe" /tn "GLPI Agent" /end)
MSI (s) (40:60) [16:51:44:263]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA497.tmp, Entrypoint: WixQuietExec
MSI (s) (40:F8) [16:51:44:263]: Generating random cookie.
MSI (s) (40:F8) [16:51:44:272]: Created Custom Action Server with PID 30360 (0x7698).
MSI (s) (40:58) [16:51:44:333]: Running as a service.
MSI (s) (40:58) [16:51:44:337]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
WixQuietExec:  ERROR: The system cannot find the file specified.
WixQuietExec:  
WixQuietExec:  Error 0x80070001: Command line returned an error.
WixQuietExec:  Error 0x80070001: QuietExec Failed
WixQuietExec:  Error 0x80070001: Failed in ExecCommon method
MSI (s) (40:D0) [16:51:44:540]: Executing op: ActionStart(Name=StopServices,Description=Stopping services,Template=Service: [1])
CustomAction EndTask returned actual error code 1603 but will be translated to success due to continue marking
MSI (s) (40:D0) [16:51:44:541]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=1300000)
MSI (s) (40:D0) [16:51:44:541]: Executing op: ServiceControl(,Name=glpi-agent,Action=2,Wait=1,)
MSI (s) (40:D0) [16:51:46:075]: Executing op: ActionStart(Name=DeleteTask,,)
MSI (s) (40:D0) [16:51:46:076]: Executing op: CustomActionSchedule(Action=DeleteTask,ActionType=3137,Source=BinaryData,Target=WixQuietExec,CustomActionData="C:\Windows\SysWOW64\schtasks.exe" /f /tn "GLPI Agent" /delete)
MSI (s) (40:88) [16:51:46:081]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIABAC.tmp, Entrypoint: WixQuietExec
WixQuietExec:  ERROR: The system cannot find the file specified.
WixQuietExec:  
WixQuietExec:  Error 0x80070001: Command line returned an error.
WixQuietExec:  Error 0x80070001: QuietExec Failed
WixQuietExec:  Error 0x80070001: Failed in ExecCommon method
MSI (s) (40:D0) [16:51:46:266]: Executing op: ActionStart(Name=DeleteServices,Description=Deleting services,Template=Service: [1])
CustomAction DeleteTask returned actual error code 1603 but will be translated to success due to continue marking

But these error messages also exist in the case of a successfull install.

There are many cases a service cannot be deleted and a computer reboot is necessary before reinstallation. To avoid this, we should priorly close any handles opened to the service, but it is not so easy to find programatically. Still MMC (services panel) and GLPI Agent Monitor are two obvious culprit.

3. I can help to test with a custom build. And I can share full logs but privately.

[g-bougard]

Okay, that error is anyway a problem if the service is still running and should have been stopped during an upgrade.

I also think the problem is related to opened handles. I think I still had such trouble when having the service MMC panel opened. We should probably find a way to detect if handles are still opened for the service before trying to remove it.

I wonder if I can add a check before the service deletion and after the service stop to decide to abort the upgrade id service is still running.

You can send me privately your log in a zipped file toward: gbougard <at> teclib <dot> com

[g-bougard]

Thank you for the log.

Anyway, the error on StopServices action is not relevant. Indeed, this one is normal as this action is started in different context and the only context we want it to be run is the uninstall of the previous version. And I think this step was working in your log. Even the DeleteServices action seems to work. This means the service is probably removed as expected during the uninstall of the previous version.

Finally the first relevant error is this one:

MSI (s) (0C:00) [17:54:58:884]: Executing op: ActionStart(Name=InstallServices,Description=Installing new services,Template=Service: [2])
MSI (s) (0C:00) [17:54:58:885]: Executing op: ProgressTotal(Total=1,Type=1,ByteEquivalent=1300000)
MSI (s) (0C:00) [17:54:58:885]: Executing op: ServiceInstall(Name=glpi-agent,,ImagePath="C:\Program Files\GLPI-Agent\perl\bin\glpi-agent.exe" -I"C:\Program Files\GLPI-Agent\perl\agent" -I"C:\Program Files\GLPI-Agent\perl\site\lib" -I"C:\Program Files\GLPI-Agent\perl\vendor\lib" -I"C:\Program Files\GLPI-Agent\perl\lib" "C:\Program Files\GLPI-Agent\perl\bin\glpi-win32-service",ServiceType=16,StartType=2,ErrorControl=1,,Dependencies=[~],,,Password=**********,Description= is an inventory agent. It is intended to upload system inventory toward a GLPI server on a regular basis.,,)
MSI (s) (0C:00) [17:54:58:888]: Product: GLPI Agent 1.7.1 -- Error 1923. Service '' (glpi-agent) could not be installed. Verify that you have sufficient privileges to install system services.

MSI (s) (0C:00) [17:54:58:889]: Executing op: ActionStart(Name=RollbackServiceConfig,,)
Error 1923. Service '' (glpi-agent) could not be installed. Verify that you have sufficient privileges to install system services.

Of course the 1923 error is probably wrong as the installer is running with elevated privileges. Have you checked the service is still defined in service MMC panel after such a failure ? If yes, it means it has not been deleted. You can eventually check the glpi-agent log to see if it has been stopped. If it has been, you should see in the MSI debug file which StopServices action triggered the stop. So if you see a stop in agent log file, and the service is still defined in MMC, this gives the clue the service has not been deleted. If you see the service is stopped in agent log and it is no more defined in MMC, this should tell us the installer really fails to install it, but actually I don't how this can happen.

[MarcSamD]

Yes, the service is still defined in service MMC panel after such a failure.
Its status is stopped and its startup type is disabled. Trying to enable the service or to start it will issue an error that the service is marked for deletion.

[g-bougard]

I modified one thing in the installer and it will be available from next nightly build:

1. actually, registry values are associated with the same MSI package "component" than the service setup
2. the service setup must be in the MSI package component of the binary file we want to start as service, here glpi-agent.exe
3. this means if that component is in trouble, the registry values may be lost, and this is one of the symptom we can see in the current issue

So I moved the registry setup in its own component. I hope this can fix the current problem as this involves less resources interaction during components uninstall:

1. this is hard to say, but maybe the "in use" problem is indeed related to a still opened registry handle. And in that case, this won't impact service uninstall as that handle is not required by the service.
2. if the "in use" problem is still there after that, it won't at least no more prevent registry setup component to be managed as expected during upgrade

A point, this fix will only apply during upgrade of an installation with at least next nightly build installed as the fix only apply during the uninstall. So to test, first install next nightly build and try an upgrade to an older nightly build.

[MarcSamD]

Same installation service errors with the new nightly builds.

Testing procedure:

1. 1.7.2 is already installed
2. Installation of 1.8-git0f1e55b3 via Scheduled Task (vbs script) => failed
3. Installation of 1.8-git0f1e55b3 via MSI UI => ok
4. Installation of 1.8-gitcf993421 via Scheduled Task (vbs script) => failed

[g-bougard]

Scheduled Task ? Do you mean you run the VBS installer from a scheduled task to trigger the error ?
In that case, be sure to not use "GLPI Agent" as schedule task name.

I must check if I can reproduce with this way of doing.

[MarcSamD]

The task is named "GLPI-Agent Installation".

As explained in my first comment, the main difference between directly using the VBS or deploying via a GPO is the account that will be used, SYSTEM in the 2nd case.

Which is why creating a task running as SYSTEM and highest privileges is a good way to reproduce the same issue as GPO deployment.

[g-bougard]

I made my own tests using scheduled tasks setup to run as LocalSystem which starts a batch, and this batch starts the vbs using cscript.

I can't reproduce the failure while installing 1.8-git0f1e55b3 after 1.7.3 or 1.8-gitcf993421.
I can't reproduce the failure while installing 1.8-gitcf993421 after 1.7.3 or 1.8-git0f1e55b3. So it works back and forth between 1.8-gitcf993421 & 1.8-git0f1e55b3.
I always reproduce a failure while downgrading to 1.7.3 from 1.8-git0f1e55b3 or 1.8-gitcf993421. And I've in MSI log messages like:

MSI (s) (88:54) [18:14:42:017]: Disallowing installation of component: {2A05C39A-6BF8-1014-862A-CAD109011A8A} since the same component with higher versioned keyfile exists

This is probably an issue with downgrade support. But this doesn't happen while upgrading.

So do you always have failure on your side or only sometime ? What options are you using for the installer in your vbs files ? Can you detail how you define scheduled tasks to be sure I'm not missing something from the context.

[MarcSamD]

1. I always have failure when I update an agent the first time. Then it will work after a computer reboot (because the service is removed then). This is why currently my workaround is to start glpi-agent installation everyday by scheduled task (knowing the vbs will bypass the installation if the version is already the same).
2. SetupOptions = "/QUIET ADD_FIREWALL_EXCEPTION=1 RUNNOW=1 AGENTMONITOR=1 HTTPD_TRUST='127.0.0.1/32,10.10.10.10/32' SERVER='https://servicedesk.mycompany.com/marketplace/glpiinventory/'"
3. Refer to the screenshots below:
   
   
   

Knowing the content of "glpi-agent-deployment.bat" is

@echo off
echo Last running date was %date% at %time% > %~dp0runninglog.log
cscript //Nologo "%~dp0glpi-agent-deployment.vbs"

[g-bougard]

Hi @MarcSamD

I think I found the problem: Glpi-AgentMonitor is still running and the installer is not able to stop it during the upgrade. I audited more deeply the Glpi-AgentMonitor code and found it always keep a opened handle on the service. So as the installer fails to end the process, this makes the installer fails on the service uninstall as a handler is still in use.

Indeed, the installer manages to stop the monitor but only when you run the installer from the user session.

So I modified the installer to kill the process in place of asking it to quit just before stopping the service. In my tests, this seems to fix the problem.

I really don't know if this is also your problem. I hope the installer fix I pushed will fix your problem. Please test upgrades with the next nightly build. In my tests, this still works on upgrading from 1.7.3.

@redddcyclone About the service opened handle, I think you should not keep that handle opened and request it each time you want to check the service status. I don't know if this can be a performance issue, but eventually you can use a greater delay to check service status. Actually, as I understand from the code Glpi-AgentMonitor checks service status every 100 ms. For any user feeling, I think this won't change anything if you use a delay of 250 ms, 300 ms or even 500 ms.

FYI, maybe this is a good news, but with all the work on that problem, this gave me some clue to manage Glpi-AgentMonitor restart. I'll try to add this support in 1.8.

[redddcyclone]

Hi @g-bougard

I don't remember why exactly I used a global service handle, maybe performance concerns... Actually, some revisions ago, the handles were managed locally inside a single function, opened and closed when needed.
Anyway, I did test it, uninstalling the Agent while the monitor was open to test if the messages updated and there was no problem involving the open handle. I didn't try to run the uninstaller on system context though.

About the 100ms timer, it was a mistake on my part, I was likely testing and forgot to set it to a higher value.

I'll make changes for this and commit them soon. Anyway, if you are able to, there's no problem in killing the monitor process forcefully if needed.

Thanks!

[g-bougard]

I didn't try to run the uninstaller on system context though.

Yes, I missed that too and I still thank you @MarcSamD to have help me to identify that issue proposing a reliable way to reproduce.

About the 100ms timer, it was a mistake on my part, I was likely testing and forgot to set it to a higher value.

I'll make changes for this and commit them soon. Anyway, if you are able to, there's no problem in killing the monitor process forcefully if needed.

Thanks you, I'm waiting you commits to update windows installer. I won't be available next week, so I'll integrate it the following week at last. This still will be before the next release, so that's fine ;-)

My last commit has still modified the installer to just kill the monitor process.

[redddcyclone]

@g-bougard

I have already commited this change to my repo! I tested uninstalling the agent under the Local System account (with psexec) while the Monitor was running and the uninstallation was successful. Please report me if you find any more problems!

[g-bougard]

@redddcyclone

Thank you I'll check that on my come back after a week. I'm off right now.

[MarcSamD]

I confirm that GLPI-Agent update is now working under system account with the nighly 1.8-git0a77a793 and 1.8-gitd493d729.

The last minor issue is that GLPI-AgentMonitor is not restarting automatically after updating the Agent, but a manual start or a computer reboot will fix it.

[g-bougard]

Hi @MarcSamD

thank you for that feedback and your investment to help us understand the problem.

I'm confident now I can close this issue.

About the last minor issue, as I said earlier, I think this should be possible in a near future, but I think this is too short for the next release.