Jump to content

Agent Deploy - Generate Installers with Tokens


Recommended Posts

Will generate ticket with Windows MSI, Mac, and Linux installers with tokens.
• Enter # of months until the token expires. If left blank, the default is 12 (enter number only)
• Enter alternative LocationID. If left blank, it will default to the Location where the script was executed from. 
• Enter Email address if you want to receive an email with all of the links.
• Additional PowerShell and Mac Terminal Scripts will be included to make deployments easier. 

Due to the latest vulnerability patches, we can no longer download any Automate Installer that is not downloaded with an Authenticated Automate User. With the help of Darren White creating the Token Generator, I've created Automate scripts to easily create the Automate Installers with Tokens and will currently create tokens from 1 month to years.

I've also updated the "Agent Deploy - Create GPO on DC" to create a "CW Automate Agent Deployment" GPO and automatically link it to the root of the domain (optional parameter). 

**Caution** This not a ConnectWise Automate blessed method of creating installer tokens, and the the developers could change the installer methods just like the did with the previous installers at any time. This is also true for the tokens themselves in the `installertokens` table. 

Agent Deploy - Generate Installers with Tokens.xml Agent Deploy - Remove GPO on DC.xml

Agent Deploy - Create GPO on DC.xml

Edited by Braingears
Updated 'Create GPO' due to accidentally applying Mac Token when creating .bat
  • Like 4
Link to post
Share on other sites

Nice, this is what I was envisioning to build for us internally, so I appreciate it. Question, is there any upper limit on the installer tokens that you have come across? For example, is 120 months a valid input? I assume no process from CWA rolls through and wipes these tokens out that we have found yet?

Link to post
Share on other sites

Although I did not limit the number of months that you could enter, it's my personal recommendation not to exceed 1-2 years. Fortunately every time you use the links provided it will download the most up-to-date agent installer to be used. On the other hand, I have no idea what CW Automate developers plan to do or change in the future. None of us expected the typical generic installers would be locked down, and they might also make changes to the Deployment.aspx or `installertokens` table in the future. The official web portal only creates these tokens for 24 hours and clears out expired tokens in a nightly routine. Time will tell...

 

Link to post
Share on other sites
Posted (edited)

hmm...Bitdefender is blocking the powershell script that creates the Automate.bat file....not sure how to work around that without putting environments at risk.  It obviously doesn't like system calling powershell (we've had that problem using a batch file with BD to deploy automate).

Kinda makes sense...system running a powershell command to download something from internet.  its exactly what we do not want to be happening..until we do

Edited by Mark Hodges
Link to post
Share on other sites

I must be missing something because every it downloads an installer is says the package cannot be opened. 

 

Logs state:

Automate Installer Exit Code: 1620
Automate Installer Logs: C:\WINDOWS\Temp\Automate_Agent_2020-07-06_10-38-23.log
The Automate MSI failed. Waiting 15 Seconds...
Installer will execute twice (KI 12002617)
Automate Installer Exit Code: 1620
Automate Installer Logs: C:\WINDOWS\Temp\Automate_Agent_2020-07-06_10-38-42.log

 

 

Link to post
Share on other sites
Posted (edited)

It took me a minute, but I figured out what happened. The script generated a .bat file with the mac agent token instead of the windows one, I manually edited the bat file and it's working.

 

So basically once I run this I have to go manually edit the bat file with the right installer token. I can't find where it is generating the bat file yet to fix it. 

I found where to fix the issue I'm running into. On the Create GPO on DC script at line at line 46. I adjusted installer_token to installertoken_msi. Once I did this it began working, it makes sense though since the last intaller_token was the mac token. 

 

Thanks again for doing all the heavy lifting! 

 

::---------------------------------------------------------------------------------
::  Script      : Install ConnectWise Automate Agent
::  Version     : 1.0
::  Written by  : Chuck Fowler
::---------------------------------------------------------------------------------
:: The Token "@InstallerToken@" will Expire on @expirationdateutc@ UTC

%windir%\system32\WindowsPowerShell\v1.0\powershell.exe -Command "Invoke-Expression(New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/Braingears/PowerShell/master/Automate-Module.psm1'); Install-Automate -Server '%redirhostname%' -LocationID @TargetLocationID@ -Token '@InstallerToken_MSI@' -Transcript"

 

Edited by DeWaynePeden
Updated information.
Link to post
Share on other sites

The script for deploying the GPO references '@InstallerToken@ when creating the .bat file. Because the last agent generated is the mac agent. So it applies the mac token. When I changed the link at line 46 to create the bat file using @installer_token_MSI@ it pulled the windows token and generated the correct installer. There was no issue downloading an installer, it just downloaded and configured and .msi installer with a mac token so it never worked.

 

I hope that makes sense. 

  • Thanks 1
Link to post
Share on other sites

Bummed that we have to rip out our existing .vbs-based agent installer GPOs, but whatever.
This looks to be a great solution. The token gen works, the GPO deployment works, the LTService install works, but my GPO-deployed test agents are failing to register.

Automate_Deploy.txt is showing several instances of this:

PS>TerminatingError(Get-Date): "Cannot bind parameter 'Date' to the target. Exception setting "Date": "Cannot convert null to type "System.DateTime".""
PS>TerminatingError(Add-Member): "A positional parameter cannot be found that accepts argument '([int]((Get-Date) - (Get-Date (Get-ItemProperty "HKLM:\SOFTWARE\LabTech\Service").HeartbeatLastSent)).TotalSeconds)'."
PS>TerminatingError(Add-Member): "A positional parameter cannot be found that accepts argument '([int]((Get-Date) - (Get-Date (Get-ItemProperty "HKLM:\SOFTWARE\LabTech\Service").LastSuccessStatus)).TotalSeconds)'."

LTErrors.txt is indicating failed signup:

LTService  v200.251     - 7/15/2020 12:42:22 PM     - Failed Signup, Will wait over 30 minutes to try again.:::

But manual execution of the GPO batch file command results in successful agent registration.

Any ideas?

Edited by drinkxon
Link to post
Share on other sites

@Braingears This is great! Thanks for putting in the time to build it out and share it.

Agent Deploy - Create GPO on DC script
I noticed that the powershell script on line 49 was missing "Import-Module GroupPolicy" at the start. Once i added this the script ran perfectly.

Link to post
Share on other sites

My test states:  ErrorDescription The system cannot find the file specified. 

I delayed the logon script by several minutes due to the possibility of network connections not being up while the script is running but I get the same deal.

 

Event ID 1130

 

  ErrorCode 2 
  ErrorDescription The system cannot find the file specified.  
  ScriptType 0 
  GPODisplayName CW Automate Agent Deployment 
  GPOFileSystemPath \\test.lcl\sysvol\test.lcl\Policies\{670905DF-4B4F-462C-BF29-CEAF296B41EF}\Machine 
  GPOScriptCommandString CWAutomateDeploy.bat 

Link to post
Share on other sites
On 7/16/2020 at 10:40 PM, Chris said:

@Braingears This is great! Thanks for putting in the time to build it out and share it.

Agent Deploy - Create GPO on DC script
I noticed that the powershell script on line 49 was missing "Import-Module GroupPolicy" at the start. Once i added this the script ran perfectly.

It's assumed that the domain controller with FSMO roles attached would have the module by default. Please continue to test, if I need to add it, I will. 

 

Link to post
Share on other sites
  • 2 weeks later...

ok, so I've used this a few times in the past and suddenly I am not getting the emails, nor am I seeing a ticket created so its failing on something.  In automate how do I see if the token is actually being generated.  I opened the location and looked through the tabs but did not see it listed there anywhere on the ones I know it was working on (I kind of expected to find it under the info tab to be honest).

NM, damn thing is working today...but I guess the question still stands, can we see the agent installer in the gui or is it just stored in the DB?

 

Edited by Mark Hodges
Link to post
Share on other sites

@Mark Hodges There is a Script Log that displays the token when run. You can see and verify the tokens in the `InstallerTokens` table. 
The logging is also enabled on line one, so you should be able to see if every line was executed within the Script Logs. 

@Jacobsa Perfect. Make it work for you, and make it fit YOUR needs.

Link to post
Share on other sites
  • 3 weeks later...
On 7/15/2020 at 11:31 AM, drinkxon said:

LTErrors.txt is indicating failed signup:


LTService  v200.251     - 7/15/2020 12:42:22 PM     - Failed Signup, Will wait over 30 minutes to try again.:::

 

We're having this occur randomly after a few days to a few weeks on agents that were previously successfully working.  Running the reinstall script (this same script with tokens) seems to get it back and working, but I don't know why they're randomly failing after some time.

Link to post
Share on other sites
  • 3 weeks later...

So, in our testing we've found that all you need is a valid token to deploy for any client. The token will set the default location for the client, however it can be overridden by specifying a LocationID in the PowerShell command.

So, what we're thinking about doing is putting the token in an online location accessible to the onboarding scripts. The tokens can expire monthly, and the scripts can pull the token into a variable on demand. One token updated and posted each month, all the scripts reference it.

The question I have is related to the security around the tokens. Is the token just as vulnerable as the installer itself (the issue that started this whole mess earlier this year). eg: do we need to password protect, whitelist, etc. access to the token?

Please feel free to point out why this is a terrible idea or otherwise.

Thanks,

Link to post
Share on other sites
  • 1 month later...

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. 

Link to post
Share on other sites
  • 4 weeks later...

Been looking at this and testing a few things - I really like the self-healing part of it, but since it is a startup script, I'm concerned it could kick off before the Automate Agent service has a chance to check in.  If that happens and the machine has been shut down overnight or for a couple days, will that still trigger the uninstall-reinstall?  Looking through the PS it pulls, as of right now it looks like it sees the agent as offline if it's over 10 minutes since last check-in, and my concern is if that could lead to excessive reinstalls from machines being turned off overnight or for several days.

Thinking on this, could this be handled by having the batch file try to start the Automate service before it kicks off the install check?  if it's already running, that should do nothing, but if it hasn't started yet, that could let it start up and check in before the install module runs its "is it online?" check.

 

Also based on what Ian mentions about security, I'm wondering if it would be a good idea to add a bit to the end of the "Deploy GPO" script to clean up after itself and delete the files outside  the newly created GPO that contain the token? It would still be reachable inside the GPO itself obviously(and setting the deploy GPO script to run monthly could provide a rotation there to limit the window of usability) but it would at least raise the bar a bit on someone stumbling across it.  And maybe lock permissions on the GPO down to just machine accounts and domain admins? There is a Powershell command that could be used to set permissions, so that could theoretically be tossed onto the end of the deploy script too.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...