Environment

Two small networks connected via a hardware VPN that is established by two identical Netgear FVS318 routers. 

Problem

User has always been able PING remote machines from XP and Vista machines using the remote machine names. Pinging from the XP machine stopped working, although pinging from Vista still works. Pinging the IP address still works.

Troubleshooting

On the XP machine, in the TCP/IP Properties, NETBIOS over TCP/IP is enabled.

I tried some of the NBTSTAT commands in this article but could only confirm that the local XP computer didn't know about the machine names on the remote network:

How To Diagnose and Test TCP/IP or NetBIOS Network Connections in Windows Server 2003

This article points out that ports 137 and 138 must be open for NETBIOS over TCP/IP to work:

How to configure a firewall for domains and trusts

I checked 137 and 138 on the remote machine's firewall and they were in fact open to receive traffic from to the local machine's subnet.

Solution

Finally I turned on XP firewall success and failure logging on the remote machine, then pinged it from the working local Vista machine. In the firewall log, I noticed that the remote machine was sending a UDP packet on port 137 to the local Vista machine.

I recalled that I had recently updated group policy on the local network to disallow the File and Printer Sharing Exception (which includes ports 137 and 138) from the remote network. I was thinking that I didn't want people in the remote office to access files on the local network.

Once I changed the File and Printer exception in the local network's Group Policy to include both the localsubnet and the remote subnet, NETBIOS over TCP/IP started working again. I guess I'll just have to trust the passwords on the local network to prevent unauthorized browsing from the remote network.

In summary, the "trick" was to realize that when sending a NETBIOS over TCP/IP request, the local machine must be able to receive UDP packets on port 137. 

Problem

In testing Spiceworks today, I discovered that a Vista machine was reporting that it had two antivirus products installed. Even after following the instructions Manually uninstalling the Client/Server Security Agent from a computer running Windows Vista, Spiceworks was still reporting Trend as installed as well as NOD32 (which really is installed). I downloaded and ran WMI Diagnosis Utility from Microsoft, but that didn't fix it either.

Solution 

Finally I found a Microsoft forum post that led me down the right path. With many thanks to its author prabhu_hv, here is a modified procedure to only delete one antivirus product:

1. Click Start, go to Command Prompt, and right-click to Run as administrator.
2. Run the command wbemtest and click Connect button.
3. Enter "root\SecurityCenter" in the Namespace field and click OK.
4. Click on "Enum Instances" button. Enter "AntivirusProduct" as the superclass name and click on OK.
5. You should see two AntiVirusProduct.instanceGuid entries. Double-click on each one and review the properties to determine which Guid corresponds to the antivirus product that is no longer installed. Then close the Object Editor.
6. In the Query Result window, highlight the incorrect AntivirusProduct and click on the Delete button. Then click Close to close the Query Result window.
7. Click the Exit button to exit the Windows Management Instrumentation Tester.

At this point, WMI and thus Spiceworks should only report the "real" antivirus product.

Symptom 

I'm running running ESET Remote Administrator 2.0.56. After upgrading from the trial to the purchased version, I started receiving the event below in my Application Event
Log.

Source:  ERA
Event ID:  502
Type:  Error
Description: The description for Event ID ( 502 ) in Source ( ERA ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Error: Update failed, code: 4, additional code: 8193.

Solution 

Here's the solution provided by ESET support:

1. Open the Remote Administrator Console (RAC).
2. Go to Menu >> Tools >> Server options... >> Updates tab.
3. Make sure you have the correct user name and password.
4. Click on Update Now button.

Sure enough, although I had updated the username and password in the 2.7 mirror setup, I had forgotten to update them in the RAC as well (where the 3.0 mirror is configured). Once I made that change, the errors stopped appearing in my event log.