How to troubleshoot errors when installing AgentP

Example:

System.Management.ManagementException: Invalid class
  at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
  at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
  at AgentP.Server.DataCollection.ComputerInformationCollector.DetectOperatingSystemVersion()
  at AgentP.Server.AgentServer.MakeEnrollmentRequest()

Reason:

The WMI repository on the endpoint is probably corrupted.

Verify if you have an issue with the WMI repository by executing the following command in the command line:

wmic os

Solution:

To fix the WMI repository, follow this article: WMI: Missing or Failing WMI Providers or Invalid WMI Class

Example:

Method https://mobilecentraal.portnox.com/AgentpBackEndEnrollment/Enrollment
- There was no endpoint listening at
https://mobilecentraal.portnox.com/AgentpBackEndEnrollment/Enrollment
that could accept the message. This is often caused by an incorrect 
address or SOAP action. See InnerException, if present, for more details.

Reason:

The communication with Portnox Cloud is blocked.

Solution:

Type the following URLs in the browser on the same computer:

• https://mobilecentraal.portnox.com/AgentpBackEndEnrollment/Enrollment
• https://mobilecentraal.portnox.com/AgentpBackEndEnrollment/CheckForUpdates

As a result, your browser should display the following message: Method not allowed. This means the communication is working correctly.

Example:

Method https://mobilecentraal.portnox.com/AgentpBackEndEnrollment/Enrollment
- Response BadRequest, Internal error 15074: Organization not found for device
'Laptop' with login 'VORLON\kosh.naranek'

Reason:

Portnox Cloud was not able correlate between the domain name collected from the machine and the domain name configured in Portnox Cloud for the specific domain and LDAP Broker. For example, you may have configured vorlon.com as a domain name, but you didn’t configure vorlon, which is the name collected by AgentP.

Solution:

Add all relevant domain names to the broker configuration in Portnox Cloud: Settings > Authentication Repositories > DIRECTORY INTEGRATION SERVICE > Directory domains > Edit > Add new domain name.

Example:

An error occurred during communication with 'portnox-centraal-prod.servicebus.windows.net:-1'. Check the connection information, then retry.

Reason:

The computer is unable to connect to the Microsoft Azure server, for example, portnox-centraal-prod.servicebus.windows.net.

Solution:

• Review the topic that shows how to configure your firewall properly for AgentP: How to set up the firewall for AgentP to connect to Cloud.

• Check if a proxy is configured on the machine. If so, you may need to configure an exception for AgentP.

Example:

Product: Portnox AgentP -- Installation failed.
Product: Portnox AgentP -- Error 1920.
Service 'Portnox AgentP Client Service' (PortnoxAgentP) failed to start.
Verify that you have sufficient privileges to start system services.

Reason:

.NET 4.5 is not installed on the endpoint.

Solution:

Install .NET 4.5 on the endpoint and reinstall AgentP.

Solutions:

1. Add the shared folder as a shared path.

2. Configure the AgentP GPO processing wait time:

   Computer Configuration > Administrative Templates > System > Group Policy > Specify startup policy processing wait time > Enabled > Amount of time to wait (in seconds) > 30

Reason:

• AgentP was installed from an MSI file
• The MSI repository on the local computer is corrupt and needs to be repaired or rebuilt

Solution:

Rebuild the MSI repository on the computer:

1. Open an elevated command prompt.

2. Verify the WMI repository is not corrupt by running the following command:

   winmgmt /verifyrepository

   If the repository is not corrupted, a WMI Repository is consistent message will be returned; if you get something else, go to next step, otherwise if the repository is consistent, more troubleshooting will be required as the repository is not likely the problem.

3. Run the following commands to repair WMI:

   winmgmt /salvagerepository

   If the repository salvage fails to work, then run the following command to see if it resolves the issue:

   winmgmt /resetrepository

   After the last command, there should be a WMI Repository has been reset message returned that verifies the command was successful.

4. To perform a rebuild of the WMI repository:

   1. Disable and stop the winmgmt service

   2. Remove or rename C:\Windows\System32\wbem\repository

   3. Enable and start the winmgmt service

   4. Open the Command Prompt as Administrator

   5. Run the following commands:

      cd C:\Windows\System32\wbem\

      for /f %s in ('dir /b *.mof') do mofcomp %s

      for /f %s in ('dir /b en-us\*.mfl') do mofcomp en-us\%s

      Note:

      These commands will take a while to complete working.

If the operating system image is created without sysprepping, this could cause several devices to have the same device ID. Here is how it affects Cloud and AgentP.

• If AgentP is preinstalled but not enrolled: When a new device is being enrolled in Cloud, Cloud checks if there is a device with the same device ID in the database. If we find such a device, but the computer name is different, Cloud generates a new device ID for the device, and AgentP uses the unique device when creating the certificate. The logs show different devices. No issues.
• If AgentP is preinstalled and enrolled: In such a situation, AgentP already created a certificate for this device and several AgentPs on several machines use the same certificate. Therefore, Cloud treats them as a single device when authenticating. The logs show the same device with different names. The device must be re-enrolled using AgentP.

When checking Past activity in Alerts, you may come across different MAC addresses for the same device. These MAC addresses are also shown in alerts for other devices.

If the device is authenticated using AgentP and certificates, the MAC addresses are shown in alerts for informational purposes only. As long as the Certificate Issued To field is unique, there is no concern about the same MAC addresses, as they are not used in authentication.

There may be different reasons why the same MAC addresses appear for different devices, for example, if the devices are using external network adapters (Ethernet or WiFi, for example, on a USB dongle) which are switched between devices.

If the adapter configuration is incorrect on Windows, for example, the DigiCert Trusted Root G4 certificate is not checked, or the SSID name does not match case-sensitively with the SSID in the group, it means AgentP is being prevented from configuring the adapter.

AgentP can only configure the adapter if no other wired or wireless profiles (such as those pushed via MDM/UEM) are present. If another solution is pushing profiles, it can block AgentP and cause connection issues or warnings.

This error most likely occurs if old or conflicting Wi-Fi configurations for the affected SSID are present on the device and AgentP was unable to replace them with the correct configuration.

Resolution:

• Method 1: Forget the network. Delete existing Wi-Fi profiles for the affected SSID.

  For example, in a command prompt, run:

  netsh wlan show profiles
  netsh wlan delete profile name="SSID"

  After deletion, AgentP should automatically install the correct profile and certificate and connect to the network.

• Method 2: Manually trigger profile installation via AgentP.

  Open AgentP, go to the About tab, and in the Networks section, click on the configured SSID. AgentP will forcefully install the correct profile and certificate on the device.

When you enroll AgentP, no profile is downloaded or installed. Enrollment works correctly and no errors are reported in Cloud or in the operating system.

Solution:

Check if the following file exists: /var/agentp/unattended.cfg. If it exists, delete this file. Then, unenroll AgentP and enroll again. AgentP should then download the profile.

If the user interface of AgentP on macOS is completely empty when you run the application, it means that the user interface of AgentP is unable to communicate with the AgentP daemon that should be running in the background. The daemon is not running. This could happen if a third-party tool unregisters the daemon from the system.

Solution:

Execute the following script in a terminal window. This script that installs and starts the daemon.

APP="Portnox AgentP.app"
DAEMON=agentpx_daemon.plist
PLIST_DAEMON_FROM="/Applications/$APP/Contents/Resources/$DAEMON"
PLIST_DAEMON=/Library/LaunchDaemons/${DAEMON}
cp "$PLIST_DAEMON_FROM" ${PLIST_DAEMON}
/bin/launchctl load ${PLIST_DAEMON}

When AgentP is pushed to an iOS device through Intune or another MDM, it may install without showing any pop-ups. If this happens, the Wi-Fi profile is not installed correctly, and although AgentP appears enrolled and running, the user cannot join the Wi-Fi network created by AgentP.

Solution:

This issue occurs when the device’s default browser is not Safari. Only Safari displays the required prompts to approve the Wi-Fi profile and allow storage access. Set Safari as the default browser, then push AgentP again so that the prompts appear and the Wi-Fi profile installs correctly.

If you use a different browser, such as Chrome, the Configure option is not available in the AgentP user interface, and the iOS profile will not install automatically during AgentP onboarding or self-onboarding. In this case, you can try to install it manually.

To install the iOS profile manually:

• Launch the Files app.
• Tap Browse.
• Tap Downloads.
• Open the downloaded profile to start installation.
• Launch the Settings app.
• Find the new profile at the top of the Settings page.
• Tap Install to complete the profile installation.