OCSInventory-NG / WindowsAgent

OCS Inventory NG Agent for Windows

Home Page:http://www.ocsinventory-ng.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

64 Bit OCS Agent not working because of Saas.ps1

itsul opened this issue · comments

commented

General information

Operating system : Windows 10

OCS Inventory information

Windows agent version : 2.9 - 2.10.1 64-BIT Version testeted, maybe more?

Problem's description

We testet the OCS Windows Agent in the 64-Bit version on multiple computers but every time it will stuck on inventory. After a lot of troubleshooting we figured out the issue is caused by the pre installed plugin "Saas.ps1". After we removed it from the folder the agent is working fine and without issues. So we tested the powershell script, the output was nothing, because our system language is german which is not handeled in the code, so we added one line:
}elseif($lang.Name -eq "de-DE"){
$pwlang = "Eintragsname"

That seemed to work we got then the expected output but the Agent still stucks because of this script while inventorying. I think there should be better handling for this, the whole agent should not get stuck because of one script. Even if the output is nothing it gets stuck. We did not get this running.
For us is the only solution is to delete this script for each installation which we will avoid. Or use a other version of the Agent. Sadly there is no option in the agent installer to not install this script. So we are forced to use 32-Bit I guess or a older version without it.

Inventory log file ( optional )

This snipped shows that the client is always stuck on this plugin. This is always the last line of the log:
ISLLight_nWPDHXwPKi

The log on the ocs server did not show any intresting things. We even did capture the packages with Wireshark and noticed that not until this script is done running nothing intresting will be send to the ocs server. Only one thing which seemes somewhat like a hello could we capture and this lines up with the log we have.

Same problem for me since i upgrade my server under version 2.12.0 and client in 64bits version 2.10.1.0. It's not happening for all windows client. The problem is coming that this is a powershell command (saas.ps1) and on some computer this command is stuck and consume over 30 % of the cpu process. After killing the powershell process in action , the service start normaly.
By the way, what is the purpose of this plugin installed by default without having the choice of disabling it.
Sincerelly

The same problem has been spotted erratically (completely at random) on different kind of Windows computer (Server and Workstation) for us. Agent is stuck and never stop because a CMD.exe that locks handle to Saas.ps1.xml and OCSInventory.log is stuck and never stop.

Considering the output of Saas.ps1 does not seems to correspond to any value displayed on OCS web interface, can someone explain the use of this "mandatory" plugin?

The plugin itself is weirdly written.
What is the point of overwriting the cmdlet Get-DNSClientCache with a function? Isn't it overkill to use ipconfig /displaydns and parse the output as a String when you can manipulate object in PS with a simple cmdlet?
Is it to provide compatibly with possible PS version that does not support Get-DNSClientCache? (Version deployed on outdated version of Windows).

Whereas there is issue in the implementation of CCapExecute (with resource locking) or the PS script itself, something should be done to fix the issue. Version 2.10.1.0 is bugged on Windows.

IMHO, CapExecute should implement mechanism to handle stuck processes and not "trust" any plugins to "just work" without failure.

As for current mitigation, I will do like @itsul by removing Saas.ps1 plugin.

EDIT: I answer my first question about Saas.ps1. I haved searched the documentation and found out what is the use of Saas plugin: https://wiki.ocsinventory-ng.org/04.Management-console-and-its-advanced-features/Managing-SAAS-inventory/

On our OCS server configuration we have: One application register but INVENTORY_SAAS_ENABLED is OFF. There is no point to execute the plugin then? We have to manually delete the plugin ourselves...