Every once in a while, location detection stops working.

[mrosen]

Hi. I now again have a workstation that has stopped entirely to detect any ZCM locations (Agent 17.4.1.26). This happens in our environment at some point in time to maybe 1% of the workstations, and I can't find a reason. let alone a way to stop it from happening.

When the locations work properly, every time a network connection in Windows 10 (1809, Enterprise) changes, a few seconds later the ZCM Agent automatically does a refresh, and when that's done shows the new location.

When this issue occurs, the most visible change is that the Agent suddenly no longer does its refresh when something changes in the network connections of windows, regardless what the change is.

I've tried to find something meaningful in the logs, but so far unsuccesful.

I'm greatful for any tips how to start further debugging. Opening a SR is possible, but the problem is that his usually triggers attempts to fix the underlying machine, which is fine. But I'm after diagnosing why and how this happens in the first place, and how to stop it. Proper location detection is vital in or environment at all times, we can not allow it to fail so often.

[CRAIGDWILSON]

I can't say I've seen that before....So an SR would be recommended.  What you can do is enable Debug Logging on the zone as well as a special "Location" debug key.  That way when it does happen, you can provide good logs to support.

One thought is ZENworks is picking up and using a "Virtual Adapter" of some sort and that is throwing off calculations.  The ZCC can be used to define virtual adapters so they are not used.  The most common ones, such as VMware Adapters, are recognized by default.  However, this tends to not be random or sporadic.

--

https://support.microfocus.com/kb/doc.php?id=3418069

HKLM\Software\novell-zes\log

Make a DWORD value set to 1 for any of the components below (case sensitive): Location

[mrosen]

Thanks Craig. I know the TID, but:

The diagnostic package is encrypted and not readable outside of an SR.

The registry key given may seem interesting, and it's set (ftr, the key "log" doesn't even exist by default), but I've not been able to find the log file (if it's even a log file at all) that comes with it. The TID is unclear what the result of that regkey is supposed to be. If it's just more detail in the diagnostic package, than that's (for me at ths point) not very useful.

[CRAIGDWILSON]

The logs would not be for you to decipher...but it would allow you to have the data for ZENworks Support to analyze.

I can't say I've seen your issue before, which is why it would likely be better to get support to look at it....especially since you are in a position where they can be created.

[mrosen]

I may have to do that, especially as I seem to have hit the next issue. While I'm trying to find why this machine no longer acts upon network changes, I found that I can't see the network provider order (failed to get NetworkProviders).
Further checking so far indicates that this fails on every machine with FDE active. And FDE adds another NetworkProvider, PBACredMan, and it *seems* that one breaks the Provider Order. I'm doing some more tests now.

[mrosen]

I was right.

Removing "PBACredMan" from all three registry keys under "HKLM\SYSTEM\CurrentControlSet\Control\Networkprovider\Order" makes the Provider Order display work again.

[CRAIGDWILSON]

I've replicated that issue, but I do not believe it is related in any way to your location issue.  AFAIK, it only involves the gui to change the registry values.....but the registry values actually used exist and have values.

That being said, I'm making a defect for that issue.

There was a similar one I created for 1709, but it impacted all of the ZENworks Credential Managers.  The issue was new to 1709 and fixed in 1803 w/o a code change on our part.  I suspect that the PBA credential manager may have continued to be impacted in 1803 and beyond but nobody ever noticed since the issue was only seen using a hard to find Hidden GUI.

[mrosen]

I don't think it's the same issue as past 1709 with the other providers. The PBACredMan entry *is* there in the newly introduced Registry Key with sane values.

I agree though that it's likely unrelated to my location issue. I see that issue in machines that work fine re: location too. But something is amiss here nonetheless and should be fixed. Networkproviders are sort of important, and nobody knows what other issues the failure to list them in the UI triggers elsewhere.

[CRAIGDWILSON]

I have created a defect over the issue so hopefully it will be resolved....

[mrosen · Accepted solution]

I solved this very instance. It was caused by updating OpenVPN Client from 2.4.7 to 2.4.8, that somehow breaks the location detection. Downgrading to 2.4.7 fixes it. I also opened a Bug with OpenVPN.

https://community.openvpn.net/openvpn/ticket/1237

[CRAIGDWILSON]

Note: I was able to duplicate the issue with OpenVPN 2.8 on my side.

I created a ticket with MF development as well.