LanGuard operations require certain network settings and security permissions to be configured.
Connectivity check failures can result in the following commonly reported scenarios:
- Access denied errors in scans, remediation jobs, and agent deployments.
- Computers showing up as offline when they are actually connected and online.
- Network path not found messages in remediation jobs.
- Remediation jobs and agent deployments stuck in the pending state.
- Agent scans or updates not initiating.
The following tests should be performed using the same account which is running the GFI LanGuard 12 Attendant service, which is typically the domain admin account in single-domain environments. This account is also referred to as the “currently logged on user” in LanGuard. In single-domain environments, it is used to connect to all computers in LanGuard with administrative rights.
In multi-domain environments, in the last two tests, use the account used to make the connection with the test target depending on its location in the network. This is typically what you define in “alternative credentials” in the computer’s properties in LanGuard.
See Best Practices for Setting up Account Permissions with Alternative Credentials for more details. Once the account is validated, perform the following tests:
Please validate the following permissions:
- Ping the computer
- Resolve the computer using the hostname and IP address
- Connect via Remote Registry
- Access the C$ Administrative Share
- View the Event Log Remotely
- Query via WMI (Windows Management Instrumentation)
Ping the computer
Confirm that you can successfully ping the computer via the hostname as well as the fully qualified domain name. Ensure that the correct IP address is being pinged. This is a hard requirement.
Resolve the computer using the hostname and IP address
NSLookup is a command prompt utility that finds Name Server information by querying the Domain Name System (DNS).
Use the NSLookup to:
- Verify forward DNS lookup with the following command:
nslookup hostname.domain.localreplacing hostname.domain.local with the fully qualified domain name of the test computer. This should return the fully qualified domain name and IP address of the target.
- Verify reverse DNS lookup with the following command:
nslookup 22.214.171.124replacing 126.96.36.199 with the computer's IP address. This should also return the same fully qualified domain name and IP address as with the forward lookup test.
Sample output below:
Additional notes for this test
- This test may not be valid when the target is a non-domain joined computer, also known as a WORKGROUP computer. You would typically not place such computers in the domain’s DNS server. However, you still need to successfully resolve the hostname in some way. One such solution is using the C:\Windows\System32\drivers\etc\hosts file on the LanGuard server to bind the hostnames and IP address of the target together. For more details, refer to Setting up a Workgroup Computer for LanGuard Operations
- If reverse lookup does not work, the connectivity may still succeed. However, if the reverse lookup points to a wrong host, you must correct this discrepancy in the DNS server’s reverse lookup zone. It is strongly recommended to have consistent forward and reverse lookups configured in the DNS server for optimal operations.
Connect via Remote Registry
Using the Remote Registry service, LanGuard can query the registry of a target computer remotely to pull important data such as the OS build and installed patches. Check if you can manually query the registry of a computer from the LanGuard server successfully:
- Ensure the Remote Registry service is started and set to Automatic startup on the target computer.
- Log on to GFI LanGuard server using an account with administrative access.
- Open the LanGuard server’s registry (regedit.exe).
- Go to File > Connect Network Registry.
- Enter the IP Address of the target machine and click on OK.
- Once connected, a new hive will appear for the target machine. Ensure you can browse to the following path: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog
Access the C$ Administrative Share
Administrative shares are the default network shares created by the Windows OS. LanGuard uses administrative shares such as C$ to obtain and store information on connected computers. Verify that LanGuard can access the C$ share and write to it:
- Ensure File and Print sharing is enabled on the target computer.
- Ensure that the default administrative C$ share has been created.
- Log on the LanGuard server using an account with administrative access.
- Go to Start > Run and type the following command:
\\hostname\C$Replace hostname with the target computer name.
- You may be prompted for credentials, especially if it is a computer in a different domain or a WORKGROUP computer. In this case, authenticate using the same account that you would specify in LanGuard.
- A File Explorer window should pop up, showing the contents of the C drive on the target computer.
- Browse to Windows > System32
- Create a text file called test.txt.
- After confirming that the file is created, you can delete it.
View the Event Log Remotely
Some monitoring checks in LanGuard retrieve information from the Windows event logs remotely from the target computer. The following test will ensure that the LanGuard server has access to this information:
- Log on the LanGuard server using an account with administrative access.
- Go to Start > Run and type the following command: eventvwr
- Click Action and select Connect to another computer.
- Enter the fully qualified domain name of the target computer (or simply the hostname if it is a WORKGROUP computer) in the Another Computer text box.
- Check the Connect as another user checkbox and click the Set user button on the right.
- In the window that pops up, specify the same credentials that LanGuard will use to authenticate with the target.
- Click OK.
- Ensure you can view each of the Windows event logs of the target computer.
Query via WMI (Windows Management Instrumentation)
LanGuard queries connected computers via WMI to obtain several key details, especially during scans. Below are two tests to verify that the LanGuard server can run WMI queries on the target computer:
- Type the following in an elevated command prompt window:
wmic /node:188.8.131.52 /user:domain\user cpu get loadpercentageBe sure to replace 184.108.40.206 with the target computer’s IP address, domain with the NetBIOS domain name, and user with the account’s logon name. Use the same account that LanGuard will use to authenticate with the target.
- You will be prompted for the account’s password. This will be masked the moment you start typing it.
- If the query is successful, it returns the CPU usage on the target as logged by the WMI service.
Example output below:
C:\Windows\system32>wmic /node:192.168.1.83 /user:my\admind2 cpu get loadpercentage
Enter the password :************
- Log in to the LanGuard server using the credentials you are attempting with the check/scan.
- Go to Start > Run and run mmc.
- Go to File > Add / Remove Snap-in and select WMI Control from the Available snap-ins
- Click Add.
- Choose Another Computer in the window that pops up and enter the IP Address of the target computer.
- Click Finish and close the Add/Remove Snap-in Dialogue box by clicking OK.
- Expand WMI Control node under Console Root.
- Right-click on the WMI Control node and go to Properties.
- You should see a window pop up that shows a message that says
Successfully Connected to : \\220.127.116.11in the General tab, where you will see the computer’s IP address instead of 18.104.22.168. This tab will also show you other details such as the Processor and OS.