<!-- Device Inventory Manager — https://wiki.cyberguard.srl/dim/networking/network-devices/troubleshooting/ -->

# Troubleshooting

## The installation fails

Look at the exit code and the message of the `--install` command (see [Installation](https://wiki.cyberguard.srl/dim/networking/network-devices/installation.md#3-install)).

| Problem | Solution |
| --- | --- |
| The command refuses to start | Open the prompt with **Run as administrator**. |
| The code is not valid or already used | A code is valid for 24 hours and for one installation. Generate a new one in the configuration of the probe. |
| The service cannot be reached | Check that the machine can reach `cyberguard-api-network-itn.cyberguard.srl` on TCP port 443 (see [Requirements](https://wiki.cyberguard.srl/dim/networking/network-devices/requirements.md#firewall)). You can test it with `Test-NetConnection cyberguard-api-network-itn.cyberguard.srl -Port 443`. |
| Installation interrupted after the registration | The code has been used: generate a new one and run the command again. |
| Exit code `2`: installed but not started | Start the service with `Start-Service CGDIMNetworkProbe` and check the Windows event log (see [The probe logs](#the-probe-logs)). On a new machine the first start can be slow: restarting the machine often solves it. |
| **Generate installation code** is not active | Add at least one target to the probe. |

## The probe is not recent

**Probe Info** shows a grey dot when no scan has arrived within the scan interval.

1. On the machine, check that the service is running: `Get-Service CGDIMNetworkProbe`. If it is stopped, start it with `Start-Service CGDIMNetworkProbe`.
2. Check that the machine can reach `cyberguard-api-network-itn.cyberguard.srl` on TCP port 443.
3. Check the Windows event log (see [The probe logs](#the-probe-logs)).

While it cannot reach Device Inventory Manager, the probe keeps using the last configuration it received, but its results do not arrive.

If the machine was reinstalled, the probe's registration is lost with it: install the probe again with a new installation code.

## No devices appear, or some are missing

A device is listed only if it answers the ping **and** an SNMP query of the probe. Check, for each missing device:

| Cause | How to check | Solution |
| --- | --- | --- |
| The device does not answer the ping | `Test-Connection <IP>` from the probe machine | Allow ICMP from the probe to the device, in the device and in the firewalls between them. |
| SNMP is not enabled, or the device accepts queries only from some addresses | The configuration of the device | Enable SNMP and allow the IP address of the probe. |
| UDP port 161 is blocked | The rules of the firewalls between the probe and the device | Allow UDP 161 from the probe to the device. |
| Wrong credentials | Compare the community, or the v3 user, protocols and passwords, with the device | Correct the [SNMP credentials](https://wiki.cyberguard.srl/dim/networking/network-devices/configuring-targets.md#snmp-credentials) in the portal. |
| The target does not include the device, or has no credentials | The **Targets** of the probe | Add the address to a target and assign the credentials. |

With SNMP v2c, a device that receives a wrong community does not answer at all: for the probe it looks exactly like a device without SNMP. When in doubt, check the community character by character.

A large network takes longer to scan: wait for the scan to end before looking for missing devices.

## A device is Disconnected

A network device becomes **Disconnected** when it has not answered for more than 7 days: it was switched off, replaced, moved to a network the probe does not scan, or its SNMP configuration changed. It becomes **Active** again as soon as it answers a scan. If the device no longer exists, delete it from its page.

## Weak SNMP community

The device answers to an easily guessable community, such as `public` or `private`. Anyone who can reach the device can read its configuration. Set a different community on the device, or move to SNMP v3, and update the [credentials](https://wiki.cyberguard.srl/dim/networking/network-devices/configuring-targets.md#snmp-credentials) of the probe. A target with no credentials uses `public` and causes the same warning.

## Running a diagnostic scan

The diagnostic scan tells you, for each address of each target, whether it answered the ping and SNMP, and why a device was not included. It runs one scan in the foreground and **does not send any result** to the portal.

From an administrator prompt, on the probe machine:

```powershell
C:\CyberGuard\DIM-NetworkProbe\CyberGuard-NetworkProbe.exe --diagnose
```

Run it from `C:\CyberGuard\DIM-NetworkProbe`: the probe uses its own registration to read the configuration. The service can keep running.

The diagnostic generates the same network traffic as a normal scan. The log is shown on screen and saved in `C:\ProgramData\CyberGuard\NetworkScan\`; the last line shows its full path. It contains no passwords, but it does describe your network: share it only with support, and delete it when you no longer need it.

## The probe logs

The probe writes its events to the Windows **Application** log, with the source **CyberGuard Network Probe**. Open **Event Viewer** › **Windows Logs** › **Application** and filter by that source.

## Contacting support

If the problem persists, open a support request and attach:

1. the version of the probe, shown in **Probe Info**;
2. the output of the `--install` command, if the problem is the installation;
3. the log of a [diagnostic scan](#running-a-diagnostic-scan), if devices are missing;
4. the events of the probe from the Application log.