Jump to content

JamesRood

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

1 Neutral

My Information

  • Agent Count
    > 6000 Agents

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That's correct, as per my original post
  2. Yeah I saw the exact same thing and did quite a bit of digging about the whole QFE thing but essentially settled that I will have a few that just don't detect properly. I was on a tight schedule to get these monitors out in just a couple of hours so didn't have the time to troubleshoot too much. Thankfully CW gave us another month so the pressure has been relieved a little bit! Thanks for replying to Roland 👍
  3. So, you're here because tomorrow 1 months time on 1st September you're going to lose a bunch of Automate agents due to TLS 1.2 compatibility. https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Supportability_Statements/Supportability_Statement%3A_TLS_1.0_and_1.1_Protocols_Unsupported So there's some measures that while not foolproof, I whipped up in a couple of hours yesterday to at least get a good head start on sorting these devices out. 1) 2 Searches, one that identifies Vista and below that will be gone no matter what you do, and one that identifies your Windows 7, Server 2008 and Server 2008 R2 machines that you can at least try to save 2) 2 remote monitors. One that looks for if the TLS 1.2 Patch is even applied to the machine, and one that checks if the DisabledByDefault registry key is set to 0 3) 2 scripts that can be used as an Autofix action to install the patch and set the registry key if necessary So, 1). Attached are the two searches. 2) You will want two remote monitors assigned to a group that you have limited to the 7-2008-2008R2 search. The first is an EXE monitor with this as the EXE. You want to monitor for the condition of "Exists". "%windir%\System32\WindowsPowerShell\v1.0\powershell.exe" -noprofile -command "(get-hotfix -Id KB3140245,KB4019276 -ErrorAction silentlycontinue).hotfixid" This is your monitor for if the patch is installed or not. Second monitor is to check if the registry key is set correctly. For this you can use a Registry key remote monitor to look at the following key. You want to monitor for a condition of "0". SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\DisabledByDefault 3) The Autofix scripts. First is "Enable TLS 1.2". You will need Darren White's Email Technician function script, otherwise just remove lines 8,9,10,13,14,15. You can then set this script as an Autofix action for your remote monitor checking for the registry key Second is "Deploy TLS1.2 Patch". You will need to enter the URL's to the patches here which you can download from the MS website. I wasn't sure if these were static URL's or not so I downloaded them and uploaded them to our web server which is why I've stripped the URL's out. You can get the downloads from the links provided in ConnectWise's KB article at the top of this post. Again you can then set this as an Autofix action against your monitor to check if the patch is installed. This patch will also set the registry keys as well as installing the patch. NOTE! It does not do anything but download the file on servers by default. You can edit lines 22 and 25 to GOTO :Install Patch instead if you want to allow it to automatically make changes to servers as well. It will not reboot machines as the WUSA command has the /norestart switch. You can drop that if you want to force reboots. I will throw one disclaimer out there. The Deploy TLS 1.2 script has had limited testing. We found that out of the machines that we tested that failed to have the patch installed, there was an underlying issue with patching in general. EDIT: So it would appear that there is another registry key potentially required. And that is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp and KKLM\SOFTWARE\Wow6432node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp for 64 bit machines. The value required is "DefaultSecureProtocols" and it needs to be set to 0x00000800 Again you can just fire up remote monitors for these, and then have an autofix script to set these appropriately. All I did for mine was copy the Enable TLS 1.2 script and swap out lines 6 and 7 appropriately like below (Note the OS Versions it runs on were changed for line 7 from Windows Server to Windows 64 bit) EDIT EDIT: So at least 1 ConnectWise support rep has also advised that .NET Framework 4.5 or higher has to be installed on the endpoint. You can quickly setup a remote monitor for this with the below configuration, and then script the install if it fails. Deploy TLS 1.2 Patch Script.xml Enable TLS 1.2 Script.xml XP-2003-Vista Search.xml 7-2008-2008R2 Search.xml
  4. Hey all, Attached are two scripts. "EXAMPLE - IT Glue Credentials" - This could easily be a scriptlet as well, but you could pretend this would be any other script where you would want to have credentials from IT Glue to do something with them. This script then calls... "FUNCTION - Retrieve IT Glue Credentials" - This is the script that does the work to go off and pull the credentials from IT Glue Assumptions You're syncing Automate and IT Glue, or at least have the names of your clients in IT Glue exactly match those in Automate. You have an Enterprise IT Glue plan Things you need to do before using Step 4 in "EXAMPLE - IT Glue Credentials" - This variable needs to be set to the exact name of the password you want to pull from IT Glue. Limitation here is that you need consistency in your password naming - we use a PowerShell script to pre-populate various password records for ones we'd want to pull into Automate Step 4 in "FUNCTION - Retreive ITGlue Credentials" - This query needs to be updated with a 'centralised' Server that you want to run the PowerShell from that goes off to do the IT Glue query. This was so I knew PowerShell versions wouldn't get in the way of the script and that my IT Glue API key wasn't being exposed to hundreds of servers. Step 6 in "FUNCTION - Retreive ITGlue Credentials" - This PowerShell script needs to be updated with your IT Glue URI and your API Key. This API Key obviously needs the Password Access box ticked... What you should then have at the end of it are two variables, @username@ and @password@ - You can then use these in your Automate script. There is some basic error checking built in - one for if it simply can't find the credentials, and one for if the PowerShell command fails for some reason. These are then tied to Script GoTo's in the EXAMPLE script that you can then log off of if you wish. FUNCTION - Retreive ITGlue Credentials.xml EXAMPLE - IT Glue Credentials.xml
×
×
  • Create New...