Tag Archives: connectwise

Reinstalling Connectwise Automate (Labtech) on Linux machine after cloning a disk in Azure

Connectwise Automate / Labtech agent icon

This is a pretty basic post and doesn’t go into the requirements to do a Linux version of sysprep, but I needed to temporarily clone a RedHat server in Azure that had the Connectwise Automate agent on it this morning. After a reboot, the server was showing up in Automate as the same id as the previous server which is not what we needed.

The documentation for the Linux agent is pretty lacking and restarting agents did not seem to fix the issue.

By changing into the location of the Automate agent, you can run the uninstaller.sh app and then reinstall with a new installer.sh that is typically going to be already downloaded to your home/ltechagent directory. Poking around it was easiest to remove and readd as a new agent.

Documenting as I’m sure I or other people will need this again.

cd /usr/local/ltechagent
sudo ./uninstaller.sh
cd ..
ls  -al
#No lttechagent directory should exist anymore

#change to location where labtech installer was downloaded, typically in the home directory and already unzipped.
cd ~/ltechagent
chmod +x install.sh
sudo ./install.sh
ps -ef | grep ltech
#Should see two results of the agent running
#View results of install
cat /tmp/ltech_install_log.txt
#refresh Automate console to see machine showing up correctly

Fixed – Screenconnect blocked by Windows Smartscreen

Due to an expired code sign certificate, the version of Screenconnect that is launched from Connectwise Automate (aka Labtech) fails to run on 2 of my Windows 10 machines but works fine on the rest of the machines. The error message “Your administrator has blocked this application because it potentially poses a security risk to your computer”. The ones that fail are running Windows 1809 and 1903 so I suspect that there is some of the new features of SmartScreen are enabled and older versions do not have these settings.

Your administrator has blocked this application because it potentially poses a security risk to your computer

Checking out the file used for Screenconnect, I saw that the certificate used to sign the exe file expired on February 1st this year, but I’m not sure why my machines suddenly started to refuse to run it the last few days of March.

The Screenconnect.WindowsClient.exe is downloaded to a random subdirectory of appdata\local\apps\2.0 so I recommend you navigate to this directory and then search for *.exe and check the correct screenconnect file as per the screenshot below which shows the certificate expiring on the 1st February

ScreenConnect certificate expiry dates

After searching around and contacting Connectwise Support they advised me this would be fixed in an upcoming version. In the meantime setting the registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\Security\TrustManager\PromptingLevel\Internet to a string type of Enabled will allow the ClickOnce application to popup and this allows the dialog box to give an option as to whether the file should be run or not (the previous setting was Disabled). This then allows the user to select yes to install and run the file overriding the invalid SSL certificate.

Obviously this is not a great idea but it does allow you to run Screenconnect from within the Automate window. (The other alternative is to use the Screenconnect website itself to connect).

Fixed: Connectwise and roaming profile permissions issues

A while back we started using Connectwise for our Helpdesk system and we use roaming profiles for our techs. Unfortunately Connectwise has to write to the appdata directory and the permissions were not set for Connectwise to write the files correctly and it also assumed that your appdata directory was going to be on c:\ rather than \\server…..
It took some digging and trial and error before we were able to get this working – the solution is to do the following from a command prompt –
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\caspol -machine -addgroup LocalIntranet_Zone -url “file://server/user$/%username%/appdata/*” FullTrust -name Andy-PsaIntranet

I think the name parameter can be anything but we set it to firstname-PsaIntranet. Also note the appdata has the path to appdata but with forward slashes instead of back slashes.

Connectwise is a great tool but whatever you don’t do, don’t use the hosted version – the performance and the lack of options and features that are crippled in the hosted product makes a very frustrating end user experience. Last night we switched over to an inhouse version and I found that I had to create a new data directory in the connectwise directory. Note this was after doing the incredibly annoying “clear cache” function in Connectwise. Create %appdata%AppData\connectwise\psa\cache\companyurl.com\companyname\connectwiseuserid\data