Atera conflict with COM/Serial ports

Atera's data collection and storage methods can, in some instances, lead to issues with the functionality of specific software applications. Typically, when such problems occur, you will receive a notification indicating that the COM port is either already in use or being utilized by another application.

If you encounter COM port issues on devices with the Atera agent installed, you can start by uninstalling the Atera agent from the affected device and then performing a device reboot. This step allows you to determine whether Atera is the root cause of the problem.

If the issue persists after these actions, it is unrelated to Atera. On the other hand, if the COM port problem is resolved after uninstalling the Atera agent and rebooting the device, it becomes evident that the Atera agent was indeed responsible for the issue.

COM ports solution

Currently, the most effective solution to resolve this issue involves disabling the specific component within the Atera agent responsible for data collection and storage. This can be accomplished by employing a script in combination with our feature-based threshold monitoring.

COM Port Script

Initially, upload the script provided below to your Atera instance. Refer to our article titled "Create or Upload Scripts" for further guidance.

$File = Get-Item -Path "C:\Program Files\Atera Networks\AteraAgent\Packages\AgentPackageMonitoring\OpenHardwareMonitorLib.dll"
$FileScript = Test-Path "C:\Program Files\Atera Networks\Remove_OpenHadrwareMonitor.ps1"
$Size = $File.Length

if ( $FileScript -ne 'False' ) {
Set-Content "C:\Program Files\ATERA Networks\Remove_OpenHadrwareMonitor.ps1" 'Stop-Process -Name AgentPackageMonitoring -Force -ErrorAction SilentlyContinue
Remove-Item -Path "C:\Program Files\Atera Networks\AteraAgent\Packages\AgentPackageMonitoring\OpenHardwareMonitorLib.dll" -Force -ErrorAction SilentlyContinue
New-Item -Path "C:\Program Files\Atera Networks\AteraAgent\Packages\AgentPackageMonitoring" -Name "OpenHardwareMonitorLib.dll" -ItemType "file"-Force -ErrorAction SilentlyContinue'
}
Start-Sleep -Seconds 5
if ( $Size -gt 2 ){
cd "C:\Program Files\Atera Networks"
.\Remove_OpenHadrwareMonitor.ps1
}
else {
exit 
}

Once the script is uploaded to your Atera instance, it should be utilized with a script-based threshold item to disable the component in question. To accomplish this, we suggest duplicating the existing threshold profile associated with your device and subsequently integrating the previously mentioned item.

Setup Script-based threshold item

1. Navigate to the affected agent's console from the Atera dashboard and select the assigned threshold profile. If you haven't assigned a threshold profile, please refer to the article "Create or Edit an Alert Threshold Profile" for detailed instructions on how to create a profile.

The threshold profile page appears

2. Click the dropdown menu located next to the "Save" option, and choose "Save as."

3. Enter the name for the cloned profile, and proceed by clicking on "Apply."

The cloned profile page will appear

4. Within the cloned profile, select "New Item" to generate the Script-based threshold item.

5. In the Threshold Item window, opt for "Script-based" and populate the specified fields with the necessary information.

• Alert Title: Choose a descriptive name for the alert.
• Monitoring Script: Select the script uploaded in the "COM Ports Script" section.
• Alert Severity: Specify the desired severity level.
• Threshold Value Type: Set it to "Text."
• Operator: Choose "Contains."
• Value: Enter "OpenHardwareMonitor removed."
• Time Period: Set to "1.5."

After configuring all the relevant fields, click "Add."

6. After adding the Script-based item, make sure to Save the threshold item.

You're all set. Be sure to assign the profile to the affected agent. For further guidance, please refer to the article provided below.

• Assign a threshold profile to customers, folders, or agents

Important notes

Once the script-based threshold profile is established, the component responsible for data collection and storage will be disabled. Consequently, all alert functionality will be deactivated, and devices subjected to this procedure will no longer generate alerts within Atera. Additionally, the metric functions will also cease to operate.

The script is configured in a manner that if an agent update occurs and the data collection and storage component is repaired, the script-based threshold item will once again disable the component, automatically resolving the issue.