Hello everyone,
We are currently trying to query a “Bridge Technologies VB Series” probe (VB330) located at a different site for our customer, using a proxy, without success (WINHTTP_TIMEOUT).
The proxy is reachable via the URL "proxy.edv.int" on port 8088 (not real values, just to explain here), and HTTP requests are basically successfully answered, for example via Postman or using PowerShell’s Invoke-WebRequest:
The proxy is configured to allow the remote probe’s IP address.
To provide the proxy to DataMiner, it has also been configured for the Windows SYSTEM user:
The settings of the probe element (based on latest connector version 1.4.2.5) are as follows:
As said above, without success(WINHTTP_TIMEOUT). It also doesn’t work with any other combination of strings/Ips/Ports in the edit mask (other issues then).
So our questions are:
• Is this the correct way to configure and use a proxy for the element?
• If not, what would be the correct configuration or solution to enable this http polling via proxy?
• What other issue could potentially be causing this issue?
Streamviewer output comes like this:
Ping on the probe is not answered, but the Web interface is accessible and operable in the element.
DataMiner is version 10.6.0 CU2.
Maybe one more thing to consider:
We are accessing the probe with http authentication, as shown in screenshot below.
Don’t know if the combination of proxy and authentication is maybe part of the problem.
Excerpt of the log output:
2026/06/01 16:59:32.577|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|7992|CProtocol::AddToExecute|DBG|2|Group 250 not added, it is already on the stack.
2026/06/01 16:59:32.577|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|7992|CProtocol::AddToExecute|DBG|2|Group 105 not added, it is already on the stack.
2026/06/01 16:59:32.577|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|7992|CProtocol::AddToExecute|DBG|2|Group 140 not added, it is already on the stack.
2026/06/01 16:59:32.577|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|28424|CParameter::RunQActions|DBG|5|QAction 21000 finished
2026/06/01 16:59:32.690|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|12320|CProtocol::ProcessHttpResult|INF|3|Error : 12002. [ERROR_WINHTTP_TIMEOUT]
2026/06/01 16:59:32.690|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|12320|CProtocol::LogHttpRequest|INF|3|<- 16:59:32 - GET http://1xx.xx.x.x1:80/probe/generaldata
2026/06/01 16:59:34.576|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|28424|CParameter::RunQActions|DBG|5|Find QAction 21000
2026/06/01 16:59:34.576|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|28424|CParameter::RunQActions|DBG|5|Run QAction 21000
2026/06/01 16:59:34.576|SLProtocol - 10808 - BridgeTech VB330 - xxx - Copy|28424|CQAction::Run|INF|2|QAction [21000] triggered by [pid=20985/idx=-1/pk=/user=]
Input: new = <NULL>
Input: old = <NULL>
Input: extra = <NULL>
We are running out of ideas, so any suggestion is very welcome.
Thanks, Regards
Jörg
Instead of a proxy, have you considered using DataMiner Edge Manager (see About Edge Manager | DataMiner Docs)? It requires DataMiner 10.5.10/10.6.0 (or higher) and the installation of a zrok agent on the remote location.
This seems a good fit for your setup.
From a configuration point of view, everything looks correct at first glance.
Do you know whether the proxy requires authentication? If so, I can see that the Invoke-WebRequest is being executed in the context of your user account, whereas DataMiner is running as the SYSTEM account. That difference could be significant if the proxy requires user-specific credentials.
Another thing worth testing is increasing the timeout from 1500 ms to 10000 ms. Depending on the proxy and the remote endpoint, 1500 ms may be too short, and increasing the timeout would help determine whether the issue is simply related to the request taking longer than expected.