Jump to content

Braingears

Members
  • Content Count

    101
  • Joined

  • Last visited

  • Days Won

    11

Braingears last won the day on December 14 2020

Braingears had the most liked content!

Community Reputation

22 Excellent

5 Followers

My Information

  • Agent Count
    1500+

Recent Profile Visitors

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

  1. Getting some feedback, would it be convenient if I added a -Parameter that would also remove ScreenConnect/Control? Something like: Uninstall-Automate -DelScreenConnect
  2. The script writes the file to: C:\Support\Automate\GPO\{418AB5AD-364B-4BC1-8058-BC2697890A5C}\DomainSysvol\GPO\Machine\Scripts\Startup\CWAutomateDeploy.bat Then performs the import to Active Directory (The UID may differ. Sort by date to be sure): \\SERVER\sysvol\DOMAIN.COM\Policies\{06CB11DF-D162-4291-BDCB-4A8743E6DCEB}\Machine\Scripts\Startup\CWAutomateDeploy.bat
  3. I actually updated the scripts yesterday to return information if the Agent was already installed, and will Uninstall the Mac agent for troubleshooting purposes prior to install. Deploy Agents - Automate Scripts - Cool Tools - MSPGeek I've included a copy of what the Automate Script automatically generates for the Mac (including the token for the Client\Location already inserted for you). I've also added several remarks so you can tell what's going on. ## ScreenConnect for Mac / Mac (Terminal-as-Root) ## #timeout=30000 #maxlength=9000000 sudo cat /usr/local/ltechagent/state | g
  4. I've updated the scripts after GitHub's changes requiring TLS 1.2/1.3. The Mac Install script will now Uninstall / Install the Automate Agent for ScreenConnect / Terminal If you've created a GPO in the past, use the Remove GPO then re-run Create GPO on your AD Domain Controllers.
  5. @dekafox - The sad truth is that if the MSI installer worked 100% of the time as it's supposed to, there would be little need for these deployment scripts. The original reason I created the script was to make agent deployments as simplistic as possible while identifying as many of the typically identified issues, and self remediating them within the script (or a second run of the script). It also has to be considered that there may also be environmental (on the computer it's running on) issues that may be effecting the outcome as well. That is where the exit codes become useful. Every ti
  6. I've noticed SSL/TLS changes with GitHub's sites. I am currently making changes and testing on all operating systems. Up until recently, as long as PowerShell was installed on WinXP and Win2003, the scripts still worked. I've also improved the Mac installation, and should be available soon.
  7. It's attempting to deploy via WinRM and WMI. It simply means that both protocols are not accessible from the domain controller you are pushing from. There is a chance that it's attempting to push to another device using the last updated DNS entry. The next steps would be using Active Directory GPO Startup Script.
  8. @Joshua Your welcome. I've recently updated the GitHub script to resolve SSL/TLS dependencies now being required on the Cloud Servers. The -Verbose read-out will give more detailed information on failures to download. If there are actual installation issues, review the log files located in the C:\Windows\Temp folder.
  9. @WConsulting- It means that for whatever reason it cannot download the MSI from the server. It's typically either a locally installed AV blocking it, or a perimeter firewall not allowing it through. Use the URL and attempt to download directly from that computer, and the issue with often reveal itself.
  10. I appreciate the inspection and feedback. I really haven't seen issues where the startup scripts are running before the Automate services have checked in. Review the transcript which is written to C:\Windows\Temp.
  11. @dekafox - Have you seen any false offline R&R's? You could always delete the files located in C:\Support\Automate\. I originally left them there for reference. On the other hand, the actual CWAutomateDeploy.bat file is accessible by anyone on the domain if they know where to look (in SYSVOL share). The same argument could be said about placing the Agent.MSI in the NETLOGON share. In all of these cases, there's a privileged user already behind the firewall and authenticated against the domain controller.
  12. @WConsulting - I apologize for the work that you had to do. I must have missed updating this post. I replaced all of the agent deployment scripts above. If the locations are connected with the Domain Controller, you can use the 'Agent Deploy via Domain Controller'. It will query all computers that have logged into the domain with the past 30 days, then will push to them. Hidden into the PowerShell module (starting at line 1104), is New-IPRange module. If you extract and use it, it will allow you to manually enter an IP Range, then pipe it into Push-Automate.
  13. When you generate the Token, the MSI installer file will always be hard coded with the original LocationID you selected. When the PowerShell script is executed, it uses the LocationID specified in the parameter instead (although the file that is downloaded in the C:\Support\Automate\ folder is still hard coded with the original Location). So... Yes @Mark Hodges, you can use the same token and specify the LocationID in the script parameter.
  14. The scripted action will be performed on whatever @ComputerID@ you assign in the script.
  15. The process is actually very easy. Use a CMD or PowerShell to query for exactly what you want, then use Function 'ExtraData Set Value' to write it to the EDF. I'm attaching an example I created for getting BitLocker status. Check - BitLocker Status.xml
×
×
  • Create New...