powerchute be 9.2.1 console/server on Server 2012R2 can't find Win10 agents on the network

[BillP]

I have three Smart-UPS SMT1500's, connected by USB to three different machines. Two of these are running Windows 10 (build 15063, version 1703, Spring 2017) and I have the BE Agent installed on them. The third machine is running Server 2012 R2 and I have the Agent, Server, and Console installed there. The Server runs 24x7 and it is my intention that it be the UI for the other two PC Agents.

Well, that's not working. The BE Server can find the Agent running on its own machine, and I can see it in the Console, but "Add Device" on the console fails to find the other two agents (the ones on the Windows 10 machines). 

On each Windows 10 machine I can access the local Agent with http://127.0.0.1:6547. And also by http://(Win10 machine's own IP address):6547. However attempts to access http://(Windows 10 machine's IP address):6547 from other machines on the LAN all fail. I tried it from Windows 7, Windows 10, and the Server 2012 R2 machine. All fail with "took too long to respond". 

(Interestingly, attempting to access the Agent on the Server 2012 machine from another system by that method also fails, but with error message "invalid response". I don't need that to work... but it is curious. Is the issue that the Agent's http interface is "occupied" by the Server on the same machine?)

The Windows 10 machines do respond to pings at their IPs, and I can access their shares over the LAN via their IPs. So TCP/UDP connectivity is working. 

On the two Windows 10 machines there are two entries in the Windows Firewall "inbound rules" that should allow connections to "PowerChute Business Edition Agent".  I see no event log entries indicating that the Firewall has blocked any connections. 

By the way, it would be extremely helpful of both PSBE Agent and Server were far more proactive in logging. It should be possible to enable "verbose" logging and see a trace of each step in the search for agents and where it fails. In my current situation I don't know if anything at all is getting to the Agents or if they're failing to respond correctly. 

[BillP]

Hi,

On 1/24/2018 4:34 AM, Jamie said:

On each Windows 10 machine I can access the local Agent with http://127.0.0.1:6547. And also by http://(Win10 machine's own IP address):6547. However attempts to access http://(Windows 10 machine's IP address):6547 from other machines on the LAN all fail. I tried it from Windows 7, Windows 10, and the Server 2012 R2 machine. All fail with "took too long to respond". 

First, the Agent should be connected to using https://ip address:6547.  You wrote http multiple times which I am assuming are typo's but I wanted to mention this just in case.

If you cannot connect to any of the Agents remotely using https on port 6547 you need to check the network to determine what is blocking the Agents from publishing over the LAN. A way to test would be to run a packet capture (try wireshark) on each of the system. Example, set up an Agent on Windows 10 and run wireshark. On the Windows 7 system run wireshark and and attempt to connect to the Agent. Then compare the the packet captures. You should see the Win 7 system posting and the 10 system accepting. 

As for the Agents not being discovered. You should first correct the issue of not being able to connect the the Agents using the web interface. Then, verify that port 2161 TCP and UDP is not being blocked on the LAN. Port 2161 is the port the Agent use to communicate to the Server. Also, all Agents and the Server must use the same user name and password. If the user name and passwords do not match the Server will not discover the Agents. And, the Agent can only be monitored by 1 Sever so verify they are not being monitored by a secondary Server. 

If the port is open run the discovery and when doing so select new and enter the Agent IP address to see if the Server will connect.

[BillP]

First, if I try to use https, I get messages like this:

Bsxw9fx%2F5S17CJFGeDij3g%3D%3D.png

I get the same or equivalent results from IE (shown), Edge, Chrome, and Firefox. if I click through the warnings I get to the local Agent's login page. Here it is on Edge:

rNe%2Bcfk8PWd9Tl5Xnm01HQ%3D%3D.png

Firefox tells me why it's not trusted: 

127.0.0.1:6547 uses an invalid security certificate. The certificate is not trusted because it is self-signed.
The certificate is only valid for the following names: (list of IPs on the local machine, plus the machine's Windows network name) 

Is there a correct (not self-signed) certificate I can obtain?

You wrote: all Agents and the Server must use the same user name and password. They do. 

And, the Agent can only be monitored by 1 Sever so verify they are not being monitored by a secondary Server. They're not. 

Finally: Regarding Wireshark - can you please provide a complete list of port numbers used by your software? Thanks in advance!

[BillP]

Hi,

The reason for the warning is because you are entering https://127.0.0.1:6547 and the security certificate would have been created using the computers domain name or IP address. Please see Schneider Electric FAQ FA165288 "How to install a Browser Security Certificate for PowerChute Business Edition Agent." and this video https://schneider-electric.box.com/s/cze780xj9jhfn1v6mss14364g4wmin9z

As for the ports, the ports are listed in Schneider Electric FAQ FA159957 "Ports used by each component of PowerChute Business Edition."

[BillP]

After a LOT of trial and error, removing and reinstalling PowerChute BE on various machines, installing new copies of Windows on test machines and trying them, going through the UPS configurations for two different Smart-UPSs 1500SMTs over and over and over again so that PowerChute will show me something other than "not configured", and a LOT of other time when I had to abandon this quest and work on actual work... I have finally, I believe, isolated the problem. 

(I have three Smart-UPS 1500SMTs, but I figured I'd try to get just two working first.) 

PowerChute's console+server and "agent" don't communicate well, or at all, on machines that have more than one IP address. Especially if they're in different subnets (though I sometimes have seen the issue even when they're in the same subnet).

Just about all of my systems are running virtual machine environments (mostly Hyper-V, one of them VirtualBox), and these create an internal "switch" or other software-only device with their own IP addresses on their own subnets. 

This appears to hugely confuse PowerChute's agent-to-server communications. (It doesn't confuse anything else, but...)

I can't abandon the VM setups so I guess I'm just going to have to abandon the goal of having a single console that can show me the status of my three Smart-UPS's all at the same time. 

I guess APC abandoned that goal already since they eliminated the Server + Console from the latest versions of PC-BE. Boo! Which is why I'm still trying to use 9.2.1. And that means that this problem will never be fixed, because APC will not go back and fix an older version. 

Does anyone have any recommendations for alternate UPS monitoring software that's compatible with Windows and with the newer Smart-UPSs? And which works in the face of multiple IP addresses in different subnets, maybe can even work from within virtual machines, etc.? 

[BillP]

Hi,

Have you looked at monitoring the PCBE Agents via SNMP? With PCBE 9.5 SNMP is embedded or with the older versions you would enable SNMP on the Windows system. 

[BillP · Accepted solution]

I don't want to use SNMP. I don't want to have to configure a UI to use SNMP to show me just what I want for my three UPSs in a simple table. I want the nice all-UPSs-on-one-small-screen display that PCBE used to give me out of the box, with minimal configuration and twiddling needed. Removing that does NOT constitute an "upgrade". It is a serious loss of functionality.