I spent the past couple of weeks nearly full time trying to get Wnpak 4.9 installed on Windows Server 2016. I spent hours on the phone with Honeywell tech support (a couple of them were outstanding). My IT group helped out by installing modern versions of .NET rather than the outdated ones called for by Honeywell that are now considered security risks. Then I spent days trying to get the Client program working on at least one PC.
Today I finally got the Client program working. Here is what I learned:
[Tech Note: Contrary to what Honeywell Tech Support told me, the server does NOT need to be able to telnet to the client computer on port 5555, but the client computer does need to be able to telnet to the server. There are no Winpak services running on the client PC, so the client PC will never be listening on ports 5555 and 5556, so telnet won’t work to the client (nor does it need to). Telnet is only being used to test the ports, not to transfer info.]
The rest of this is on page 4 of the Client-Server Troubleshooting Guide from Honeywell.
On the server in a Domain, the account that runs the Winpak services needs to be a domain account and needs to be an admin on the system. It does NOT need to be a domain admin, contrary to what Honeywell tech support said repeatedly.
On client computer, run the user modification tool “Honeywell.Winpak.Services.Utility.exe” in the installation folder. This Honeywell program must be given the same domain account name as the server’s Winpak services so the client can authenticate when connecting to the server.
(example location: Winpak_4.9_Installation\Tools\WIN-PAK Services User Modification Tool\Honeywell.Winpak.Services.Utility.exe)
Type in the username domain\account_name
Type in the password
Let it run and it will set the credentials that it will use to connect to the server. Click OK when it says it is done.
Again, the credentials should match what the server uses to run the Winpak services on the server. If you run the Windows “Services” app on the server, at the bottom of the list it will show the Winpak services and to the right will show the username domain\account_name account. In a domain, the services must be run by a domain account, not by winpakuser.
MY GRIPES
Win-Pak started back in the 1990s as a Northern Computers product and has been tweaked and tweaked over the decades to work with more modern operating systems. Win-Pak seriously needs to be re-written, get rid of the many prerequisites for installation, streamline it so it simply installs and works. Then update the actual function of the reporting area that hasn’t changed for 20 years. So many custom reports can be done via SQL, why not incorporate that into the user interface and make the software a lot more useful? I get the feeling that Win-Pak is a cash-cow for Honeywell and they don’t really want to invest a lot into it. That is the case for the card access panels as well. The “new” MPA2 panel is absurd, using RJ45 adapters for readers, and a plastic cover thing over the motherboard that actually gets in the way of the power wires from the power supply.
The NetAXS panel had a ton of problems (e.g, TLS 1.0 and 1.1, firmware out of date, a low limit on how many custom users can be assigned to a door, odd jumper needed for the power-fail terminal), but was the best layout I’ve seen for a panel offered by Honeywell. All the reader inputs were clearly marked and color coded. All the relays and inputs were clearly marked. AND… it controlled 4 doors instead of just 2 on the MPA2. Currently if a 4-door panel fails, I have to replace it with two MPA2 panels. That is stupid in 2022. Quit jacking around your customers Honeywell.