Applying HF

I wrote a batch file to do this and deployed it through SCCM. I didn't get the results I was expecting. In fact, I got some very weird results. I've opened a ticket with DameWare Support. This is what it says:

"We're currently trying to upgrade our Windows 10 Enterprise environment from DameWare MRC client agent v11.2 to v12.1. I had just successfully pushed out v12.1 to our pilot group through SCCM, when our Information Assurance team informed me that we needed to update v12.1 to include Hotfix 2 or later. So I integrated the v12.1 upgrade with the HF3 update into a single SCCM Application (and Package). I created a batch file that upgrades 11.2 to 12.1, uninstalls and reinstalls 12.1 if it already exists, and copies the HF3 files to the C:\dwrcs directory. The batch file works when run directly in a clean machine (non-domain member, no malware protection, etc), and runs directly on a regular environment machine. When run as either an SCCM Application or Package, I get very different results. Even as a required Application, I might need to retry the installation several times in Software Center before it takes. If installed as an SCCM Package, it looks like the HF3 files are copied to the dwrcs directory, but other files disappear, like more than 20 of them, rendering the service non-startable."

I wrote a batch file to do this and deployed it through SCCM. I didn't get the results I was expecting. In fact, I got some very weird results. I've opened a ticket with DameWare Support. This is what it says:

"We're currently trying to upgrade our Windows 10 Enterprise environment from DameWare MRC client agent v11.2 to v12.1. I had just successfully pushed out v12.1 to our pilot group through SCCM, when our Information Assurance team informed me that we needed to update v12.1 to include Hotfix 2 or later. So I integrated the v12.1 upgrade with the HF3 update into a single SCCM Application (and Package). I created a batch file that upgrades 11.2 to 12.1, uninstalls and reinstalls 12.1 if it already exists, and copies the HF3 files to the C:\dwrcs directory. The batch file works when run directly in a clean machine (non-domain member, no malware protection, etc), and runs directly on a regular environment machine. When run as either an SCCM Application or Package, I get very different results. Even as a required Application, I might need to retry the installation several times in Software Center before it takes. If installed as an SCCM Package, it looks like the HF3 files are copied to the dwrcs directory, but other files disappear, like more than 20 of them, rendering the service non-startable."

Hey we've had the same problem... very mixed results.  Some update, some connect but get a warning that FIPS mode is not available, connect anyway, and some don't connect at all, meaning we then have to right click the dameware icon and run as administrator, supply domain admin credentials, then do a remove service and install service on the workstation, then close it and run dameware mrc under our normal user and then we can connect.

A real PITA. 

The programs relatively unchanged in the last decade.  Starting to think about looking to see what else is out there.  Prior to Dameware we just used VNC, but a security pen test we paid for got on a server via VNC... they somehow enumerated the registry and got the credentials for it and got in.  Thankfully it was a white hat pen-test we paid for.  We switched to damewhere with AD authentication plus shared secret and FIPS mode.  Our yearly pen tests since then haven't been able to exploit that avenue yet.

Support and I were able to work this out. First, the HF files are only applied to the Client installation folder (C:\Program Files\SolarWinds\DameWare Mini Remote Control x64, in our case), and NOT the Agent folder (C:\Windows\dwrcs).

Then we built a new MSI using the Mini Remote Control Client Agent Builder and did not select any of the additional module or driver check boxes. This created an agent installer that passed our security vulnerability scans (the original reason for trying to use the HF files), but we couldn't connect to the remote agent using smart card. I then built a second new agent installer, but this time selecting the FIPS module and smart card drivers. This agent passed our vulnerability scans AND we were able to use smart cards to connect to remote agents.(It might be that the additional keyboard or mirror drivers are the files that pop the vulnerability scan, but I haven't had the time, or really the inclination to delve any deeper into the issue).