gavsto / automateapi

Powershell Module for the ConnectWise Automate API

AutomateAPI

Latest Tested Versions (as of 2023-11-15):

Automate	Extension	ScreenConnect	Plugin
v23.0.9.392	v4.4.0.2	v23.6.8.8644	v7.1.23001.13

Note: A Partner "ClientID" token is needed with Automate 20 Patch 11 and above. See https://developer.connectwise.com/ClientID

Features

1. Get, search and return PowerShell objects for pre-defined searches or custom conditions using Get-AutomateComputer. See https://github.com/gavsto/AutomateAPI/wiki/Get-AutomateComputer

2. Identify agents that are online in Control and offline in Automate. See https://github.com/gavsto/AutomateAPI/wiki/Autofix-Broken-Agents

3. Autofix agents that are broken using Repair-AutomateAgent. See https://github.com/gavsto/AutomateAPI/wiki/Autofix-Broken-Agents

4. New - Invoke-AutomateCommand, used like this Get-AutomateComputer -ComputerId 1 | Invoke-AutomateCommand -PowerShell -Command "Get-Service"

A PowerShell Module created by Gavin Stone (Gavsto) for the ConnectWise Automate API

How do I get Going

See https://github.com/gavsto/AutomateAPI/wiki/Pre-requisites-and-Install

Then https://github.com/gavsto/AutomateAPI/wiki/Getting-Started-and-Connected

Then https://github.com/gavsto/AutomateAPI/wiki/Get-AutomateComputer

If you're interested in repairing broken agents https://github.com/gavsto/AutomateAPI/wiki/Autofix-Broken-Agents

I want to help

Great - dig in and submit a pull request! Please make sure your follow the conventions set by the other modules. Write documentation for functions, support pipeline input where required etc.

Significant Contributions

Darren White for his pre-input, ongoing code support with the code and then his extensive support in helping me get the Control portions of this module down from 10 minutes to 25 seconds per 2500 PCs. You are definitely a legend, Darren.

Special Thanks

Special thanks to a number of people whose help (and in certain cases code) I have used within this project

Chris Taylor where I have re-used and modified certain parts of the ConnectWise Control module to send commands to Control and his ConnectWise Automate module so we can reinstall services

Mendy Green for helping me test the initial code

Davíð Snædal for his assistance before this module even started with guidance on connection to the Automate REST APIs

ConnectWise for absolutely smashing the delivery of their API

automateapi's Issues

Get-AutomateAPIGeneric returns 401

Hello everyone!

Attempt to use the API after a long time. Calling get-automatecomputer after connecting with an admin account returns 401:

PS C:\Users\Documents\OneDrive> Connect-AutomateAPI
Successfully tested and connected to the Automate REST API. Token will expire at 2021-04-13T13:11:03

PS C:\Users\Documents\OneDrive> Get-AutomateComputer -AllComputers
Get-AutomateAPIGeneric : Failed to perform Invoke-RestMethod to Automate API with error The remote server returned an error: (401) Unauthorized..Exception.Message
At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI\1.1.1\Public\Get-AutomateComputer.ps1:264 char:16

• ... Return Get-AutomateAPIGeneric -AllResults -Endpoint "computers" ...

•             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
  • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-AutomateAPIGeneric

Can anyone please advise if I am doing anything incorrect from my end? This used to work until a month ago. Thanks!

Reinstall Agent on Mac duplicates the agent

When I run the repair option of AutomateAPI on Mac computers it duplicates the computer in LT, but when I run the repair option using this code, they are quickly fixed and not duplicated:
#maxlength=100000
#timeout=900000
sudo /usr/local/ltechagent/uninstaller.sh
cd /tmp
curl -L -o 'LT_Install.zip' TOKENURL
unzip -o LT_Install.zip
chmod 755 LTSvc.mpkg
chmod 755 config.sh
sudo installer -pkg LTSvc.mpkg -target /
Do you think we can test/change the AutomateAPI code to use this one?
Thanks!

Switch usage on Invoke-ControlCommand feels redundant

Is -Powershell -Command necessary? How about:

-Powershell "Bla"
-Batch "Bla"

Look into replacing paging with the cmdletbinding attribute supportspaging

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_functions_cmdletbindingattribute?view=powershell-6#supportspaging

Invoke-AutomateAPIMaster : An error has been thrown.

Sorry for the duplicate issue, but I'm having the same problem as Issue #67 . I'm running the powershell commands from a workstation, not my Automate server if that helps. Full log from powershell:

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS C:\Windows\system32> Import-Module AutomateAPI
PS C:\Windows\system32> Connect-AutomateAPI
Please enter your Automate Server address, IE: rancor.hostedrmm.com: https://
Please enter API Client ID (Required for 2020.P11 and above):
Please enter your Automate Username:
Please enter your Automate Password:
Please enter your 2FA Token:
Successfully tested and connected to the Automate REST API. Token will expire at 2022-01-07T20:16:34
PS C:\Windows\system32> Connect-ControlAPI
Please enter your Control Server address, the full URL. IE https://control.rancorthebeast.com:8040: http://:8040
Please enter your Control Username:
Please enter your Control Password:
Control Extension version 4.3.0.2 enabled: True
Server version is 21.13.5058.7951.
Successfully tested and connected to the Control API.
PS C:\Windows\system32> Get-AutomateComputer -ComputerID 2
Invoke-AutomateAPIMaster : An error has been thrown.
at Invoke-AutomateAPIMaster, C:\Program
Files\WindowsPowerShell\Modules\AutomateAPI\1.1.5\Private\Invoke-AutomateAPIMaster.ps1: line 75
at Get-AutomateAPIGeneric, C:\Program
Files\WindowsPowerShell\Modules\AutomateAPI\1.1.5\Public\Get-AutomateAPIGeneric.ps1: line 146
at Get-AutomateComputer, C:\Program Files\WindowsPowerShell\Modules\AutomateAPI\1.1.5\Public\Get-AutomateComputer.ps1:
line 413
at , : line 1
-->
-->
At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI\1.1.5\Public\Get-AutomateAPIGeneric.ps1:146 char:27

• ... $Result = Invoke-AutomateAPIMaster -Arguments $Arguments

•                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
  • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-AutomateAPIMaster

PS C:\Windows\system32>

If this needs to be run directly on the Automate server, I'm waiting for a maintenance window to restart the server after upgrading powershell from v4. The Powershell version was too low to run Install-Module commands. We also self-host and are using control plugin, not a separate control server if that matters at all.

The initial error from Invoke-AutomateAPIMaster.ps1 is getting hung up on line 75: $Result = Invoke-WebRequest @arguments

I'm not entirely sure what all goes into the @arguments field. Some direction there might help troubleshoot why it's throwing an error.

Allow invoking CMD/PowerShell via Automate instead of Control

There is the known issue where the Control API does not support 2FA/MFA authentication, which limits a reasonable number of people from using the Invoke-ControlCommand function. We have the ability to implement similar functionality (though maybe not as efficient execution) via the Automate Computers/$computerID/CommandPrompt endpoint.

This can be assigned to me, as I intend to work on implementing this.

API vs username and password.. scripting possible?

          Did you get this resolved?  I have been using the module across many upgrades (well into 2023 versions) without issue. I am using the APIKey authentication method though, not username/password.

Originally posted by @DarrenWhite99 in #72 (comment)

Would you be able to share how you set this up to use the api vs the username and password setup? Also did you automate the process? Thank you in advance

Invoke-AutomateAPIMaster : An error has been thrown.

I can connect to the api but I can't pull any information. I get misc errors regarding Invoke-AutomateAPIMaster

(tested on multiple computers. PowersShell version: 5.1.19041.546 )

Get-AutomateClient - Allclients
Invoke-AutomateAPIMaster : An error has been thrown.
at Invoke-AutomateAPIMaster, C:\Users\REDACTED\Documents\WindowsPowerShell\Modules\automateapi\1.1.4\Private\Invoke-AutomateAPIMaster.ps1: line 75
at Get-AutomateAPIGeneric, C:\Users\REDACTED\Documents\WindowsPowerShell\Modules\automateapi\1.1.4\Public\Get-AutomateAPIGeneric.ps1: line 146
at Get-AutomateClient, C:\Users\REDACTED\Documents\WindowsPowerShell\Modules\automateapi\1.1.4\Public\Get-AutomateClient.ps1: line 85
at , : line 1
-->
-->
At C:\Users\REDACTED\Documents\WindowsPowerShell\Modules\automateapi\1.1.4\Public\Get-AutomateAPIGeneric.ps1:146 char:27

• ... $Result = Invoke-AutomateAPIMaster -Arguments $Arguments

•                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
  • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-AutomateAPIMaster

Issue with Get-AutomateComputer or Compare-AutomateControlStatus or Both?

Issue with Get-AutomateComputer or Compare-AutomateControlStatus or Both?

WARNING: Property Name is not supported by this version of Control
WARNING: Property CreatedTime is not supported by this version of Control
WARNING: Property GuestOperatingSystemManufacturerName is not supported by this version of Control
WARNING: Property GuestOperatingSystemName is not supported by this version of Control
WARNING: Property CustomProperty1 is not supported by this version of Control
WARNING: Property CustomProperty2 is not supported by this version of Control
WARNING: Property SessionType is not supported by this version of Control

I receive these warnings now when trying to compare or repair. This started after upgrading Control to version: 21.8.3663.7830

Thanks! :-)

Connect-ControlAPI throws 500 Internal Server Error

It looks like the 22.2.x.x Control server series may have broken connectivity. Now when I go through the authentication process, the result reads:

Exception: C:\Users\[xyz]\Documents\PowerShell\Modules\AutomateAPI\1.1.4\Public\Connect-ControlAPI.ps1:193
Line |
 193 |  …             Throw "Attempt to authenticate to the Control server has  …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Attempt to authenticate to the Control server has failed with error Response status code does not
     | indicate success: 500 (Internal Server Error).

I just updated the server again to the latest release (v22.2.7294.8116) and getting the same result.

Connect-ControlAPI: Modify url checking

Modify the url checking to allow urls to contain an arbitrary port number and an arbitrary suffix

A Partner "ClientID" token

I've noticed I need a ClientID token to get this thing to work. You refer to https://developer.connectwise.com/ClientID but it's behind a login portal. Would it be possible to provide instructions how to get this ClientID token?

Love your work by the way.

Online / Offline status not clear enough

AutomateAPI/AutomateAPI.ps1

Line 533 in a18566a

[Parameter(Mandatory = $false, ParameterSetName = "CustomBuiltCondition")]

Refactor this to reflect a boolean with a name of -Online, taking $true or $false.

Cache SessionID values from Get-AutomateControlInfo in $script scope variable

Since we can only get this information 1 machine at a time, it would be very useful if the module stored it at least for the course of the session as to prevent long lookup times.

No support for -WhatIf on Set function(s)

As we add functionality that not only reads from the environment, but starts making changes, we should probably look into making sure the PowerShell built-in capabilities like -WhatIf are actually implemented, as well.

Internal monitor lookup fails

We have seen this in one or two environments in testing and believe it is due to a bug in the API. If you get this and are willing to test then please contact me directly.

Invoke-ControlCommand does not return results

1. Connect to your Control instance with a good user.
2. Invoke-ControlCommand
3. See errors
   
4. Get no response back from the session.
5. Verify that the session got the command and returned a result
   

Required Permissions

Hi Gavsto,

Great work! Very usefull to integrate Control a bit better in Automate. I'm scripting some checks now so I can monitor them. Starting with this in powershell, it will ease the login procedure to automate the functions. If running from Automate Script, you can even set the login details in Automate and pass them as a variable to the script.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$Pass = ConvertTo-SecureString '(Password)' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential ("(User)", $Pass)
Import-Module AutomateAPI
Connect-AutomateAPI -clientid '(clientid)' -server '(Automate URL)' -Credential $Cred
Connect-ControlAPI -credential $cred -Server '(Control URL)'
#Eny command here to create output

But now the big question:
Say I want to make a service account in both Automate and Control to use it in the script. What are the minimum permissions required to accomplish this? Because I want to script this, I dont want it to use MFA. So my only option seems like to check the Integrator Checkbox in Automate. However, this account needs to be Super Admin to be able to access computers. So a Super admin with this username and password permissions without MFA is not the best choise.
Any advise?

Same is for Control. But it seems like the control user can be limmited to view only.

Control requests failing

I am receiving the following error when running any comparison, for example: Get-AutomateComputer -NotSeenInDays 30 | Compare-AutomateControlStatus

The Control Server is version: 20.11.1622.7619

PS C:\Users\demo\Documents\GitHub\AutomateAPI> Get-AutomateComputer -NotSeenInDays 30 | Compare-AutomateControlStatus
Checking to see if the recommended Internal Monitor is present
Internal Monitor is present
Invoke-ControlAPIMaster : An error has been thrown.
at Invoke-ControlAPIMaster<Process>, C:\Users\demo\Documents\GitHub\AutomateAPI\Public\Invoke-ControlAPIMaster.ps1: line 91
at Get-ControlSession<End>, C:\Users\demo\Documents\GitHub\AutomateAPI\Public\Get-ControlSession.ps1: line 165
at Compare-AutomateControlStatus<End>, C:\Users\demo\Documents\GitHub\AutomateAPI\Public\Compare-AutomateControlStatus.ps1: line 127
at <ScriptBlock>, <No file>: line 1
-->
--> Incorrect syntax near '>'.
Incorrect syntax near '>'.
At C:\Users\demo\Documents\GitHub\AutomateAPI\Public\Get-ControlSession.ps1:165 char:24
+ ...            $AllData = Invoke-ControlAPIMaster -Arguments $RESTRequest
+                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-ControlAPIMaster

Invoke-ControlAPIMaster : An error has been thrown.
at Invoke-ControlAPIMaster<Process>, C:\Users\demo\Documents\GitHub\AutomateAPI\Public\Invoke-ControlAPIMaster.ps1: line 91
at Get-ControlSession<End>, C:\Users\demo\Documents\GitHub\AutomateAPI\Public\Get-ControlSession.ps1: line 210
at Compare-AutomateControlStatus<End>, C:\Users\demo\Documents\GitHub\AutomateAPI\Public\Compare-AutomateControlStatus.ps1: line 127
at <ScriptBlock>, <No file>: line 1
-->
--> Cannot perform an aggregate function on an expression containing an aggregate or a subquery.
At C:\Users\demo\Documents\GitHub\AutomateAPI\Public\Get-ControlSession.ps1:210 char:28
+ ...            $AllData = Invoke-ControlAPIMaster -Arguments $RESTRequest
+                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-ControlAPIMaster

below is a screenshot from fiddler when it fails:
![Screenshot 2020-12-14 174731](https://user-images.githubusercontent.com/76008419/102149697-a5740e00-3e34-11eb-90d0-049e9f96e953.png)

Include additional API functionality in Get-AutomateComputer excluded fields, included fields etc

This manipulates how the object is returned.

ClientID appears to be required when making CWA REST calls.

Recently, I've started getting the following error when trying to use AutomateAPI:

Get-AutomateAPIGeneric : Failed to perform Invoke-RestMethod to Automate API with error The remote server returned an error: (401) Unauthorized..Exception.Message
At C:\Users\rbartram\Dropbox\Powershell Scripts\Modules\AutomateAPI-master\Public\Get-AutomateComputer.ps1:430 char:20

Using Postman, I found that "clientid" is needed in the headers.

I've gotten around this by inserting a clientid statically as follows, but this can't be the best way to address this...

            ##Rob 2020-12-16 - Switching to $headers to include clientid
            $headers = @{
                'clientid' = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
                'Authorization' = $script:CWAToken.Authorization
            }
            ##/Rob 2020-12-16

            try {
                ##Rob 2020-12-16 Switching to $headers to include clientid
                #$return = Invoke-RestMethod -Uri $URLNew -Headers $script:CWAToken -ContentType "application/json" -Body $Body
                $return = Invoke-RestMethod -Uri $URLNew -Headers $headers -ContentType "application/json" -Body $Body
                
                #/Rob 2020-12-16
            }

Enable Mac/Linux support for Control Commands

This will involve fixing Invoke-ControlCommand to allow it to deal with returns from Mac and Linux.

Create Invoke-AutomateAPIRestMethod function

Create an Invoke-AutomateAPIRestMethod function, instead of a separate "Set-AutomateAPIGeneric" function.

Example code:

Function Invoke-AutomateAPIRestMethod
{
param(
    $Endpoint,
    $Method,
    $Body)
    $TokenExpiration = [DateTime]::Parse($TokenObject.ExpirationDate)
    if((Get-Date) -gt $TokenExpiration)
    {
        Connect-AutomateAPI
    }
    Invoke-RestMethod -Uri "$($script:baseurl)$Endpoint" -Method $Method -Headers $script:header -Body $Body #-ContentType "application/json" 
}

Include support for tiering IDs, ExcludeFields, IncludeFields and OrderBy in Generic API

Include support for tiering IDs, ExcludeFields, IncludeFields and OrderBy in Generic API

Invoke-ControlCommand adaptive polling rate

The function checks for the task to complete with 1 second delays between checks. Commands with very long timeouts could be checked less frequently, especially as time goes on.

Example: If a command could run up to 10 minutes, after 5 minutes of waiting the polling frequency could change to every 5 or 10 seconds with little impact.

Get-AutomateComputer -ComputerID could easily support pipline input

Simply change the parameter block for $ComputerID to include ValueFromPipeline =$true

Unauthorized on Repair-AutomateAgent

Jobs are not processing properly

Invalid anti-forgery token

Control: 2020.13
Automate: 2020.11

I have had this issue for a while now.
Even the current git version throws

Invoke-ControlAPIMaster : An error has been thrown.
at Invoke-ControlAPIMaster<Process>, C:\Program
Files\WindowsPowerShell\Modules\AutomateAPI-git\Public\Invoke-ControlAPIMaster.ps1: line 92
at Connect-ControlAPI<End>, C:\Program Files\WindowsPowerShell\Modules\AutomateAPI-git\Public\Connect-ControlAPI.ps1:
line 231
at Connect-APIs, C:\Lokal\FixAutomateAgentsViaControl.ps1: line 7
at <ScriptBlock>, C:\Lokal\FixAutomateAgentsViaControl.ps1: line 10
at <ScriptBlock>, <No file>: line 1
-->
--> {"errorType":"UnauthorizedAccessException","message":"Invalid anti-forgery token","detail":null}
-----> Use 'Connect-ControlAPI' to set new authentication.
At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI-git\Public\Connect-ControlAPI.ps1:231 char:41
+ ... Extension = Invoke-ControlAPIMaster -Arguments @{'URI' = "ReplicaServ ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-ControlAPIMaster

ConvertFrom-Json : Cannot bind argument to parameter 'InputObject' because it is null.
At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI-git\Public\Invoke-ControlAPIMaster.ps1:171 char:46
+             $SCData=$(Try {$Result.Content | ConvertFrom-Json} Catch  ...
+                                              ~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [ConvertFrom-Json], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.ConvertFrom
   JsonCommand

Without commenting the regex out there's also a parsing error:

parsing "https?://[a-z0-9][a-z0-9\.\-]*(:[1-9][0-9]*)?(\/[a-z0-9\.\_\-\/]*)?$" - Unrecognized escape sequence \_.
At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI-git\Public\Connect-ControlAPI.ps1:93 char:13
+         If (!($Server -match 'https?://[a-z0-9][a-z0-9\.\-]*(:[1-9][0 ...
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException

Connect-AutomateAPI using -Credential and -TwoFactorToken fails

When attempting to use pscredentials an error is presented
"Attempt to authenticate to the Automate API has failed with error Cannot validate argument on parameter 'Uri'."

Speed up Control calls by using Parallel blocks or a better endpoint

AutomateAPI/Public/Compare-AutomateControlStatus.ps1

Line 60 in d6cc5fb

$ControlSessions = Get-ControlSessions

Invoke-ControlCommand; Cannot bind argument to parameter 'InputObject' because it is null

Invoke-ControlCommand -SessionID $SessionID -TimeOut 120000 -MaxLength 10240 -Command "Invoke-WebRequest -UseBasicParsing 'https://bit.ly/ltposh' | Invoke-Expression; Restart-LTService" -PowerShell

This works but spits out the following below every time. Any ideas?

ConvertFrom-Json : Cannot bind argument to parameter 'InputObject' because it is null.
At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI\1.1.1\Public\Invoke-ControlCommand.ps1:149 char:51
+ ...            Write-Error "$(($_.ErrorDetails | ConvertFrom-Json).messag ...
+                                                  ~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [ConvertFrom-Json], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.ConvertFromJsonCommand

Invoke-ControlCommand :
At line:1 char:1
+ Invoke-ControlCommand -SessionID 04f633ff-b408-4592-b216-cfa1f2bf19a8 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-ControlCommand

Feature request: Compare-ControlAutomateStatus

Because Automate came with Control some time ago, Automate agets where removed when a computer was ready for trash. But Control sessions remained in control.
So it would be a great feature to aslo have a check that will compare the Control agents to Automate Agents to see how many sessions are left from unmanaged computers.
This will make us able to cleanup old computers without going through the list with thousants of items.

Index operation failed

Trying to run the command Get-AutomateComputer -Online $False | Compare-AutomateControlStatus

I used Connect-AutomateAPI and Connect-ControlAPI before. Verified that I have the correct monitor in Automate.

Client Name not showing in Compare-AutomateControlStatus when results pulled in module

Client Name not showing in Compare-AutomateControlStatus when results pulled in module

Need to put an if in the building of the object to call the appropriate client name

Issue in Get-ControlSessions

`PS C:\WINDOWS\system32> Get-AutomateComputer -ComputerId 13126 | Get-ControlSessions
Get-ControlSessions : The input object cannot be bound to any parameters for the command either because the command
does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline
input.
At line:1 char:42

• Get-AutomateComputer -ComputerId 13126 | Get-ControlSessions

•                                      ~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidArgument: (@{Id=13126; Loc...ystem.Object[]}:PSObject) [Get-ControlSessions], Par
    ameterBindingException
  • FullyQualifiedErrorId : InputObjectNotBound,Get-ControlSessions

Index operation failed; the array index evaluated to null.
At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI\1.1.3\Public\Get-ControlSessions.ps1:99 char:25

•                 If ($_.Date -ge $SCConnected[$_.SessionID]) {
  

•                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidOperation: (:) [], RuntimeException
  • FullyQualifiedErrorId : NullArrayIndex `

Get-AutomateComputer does not exist anymore

please update this document as the commands mentioned in the article do not exist anymore and even if we use the old module the Fix does not work as the base module has been changed.

Regards
Vibhu

Controlapi - 404 Not Found

In an effort to resolve the index operation bug throwing antiforgery warnings, I pulled the latest master. When that didn't fix it I updated to the below versions:

Automate v20.0.373 (Patch 11)
Automate Control Plugin 6.5.20005.6
Control 20.13.1905.7657

I can login using connect-automateapi, but when I try to login with connect-controlapi I get the below error. This exact URL was working fine before the latest bugs/updates.

Please enter your Control Server address, the full URL. IE https://control.rancorthebeast.com:8040: https://cwa.somedomain.com/connect
Please enter your Control Username: Admin
Please enter your Control Password: **********
Attempt to authenticate to the Control server has failed with error The remote server returned an error: (404) Not
Found.
At C:\Program Files\WindowsPowerShell\Modules\automateapi\Public\Connect-ControlAPI.ps1:181 char:21

• ... Throw "Attempt to authenticate to the Control server has ...

•             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : OperationStopped: (Attempt to auth...4) Not Found.
    :String) [], RuntimeException
  • FullyQualifiedErrorId : Attempt to authenticate to the Control server has failed with error The remote server re
    turned an error: (404) Not Found.

Module prefix naming

Per discussion with @dkattan

While we're on the topic of naming, I would like to propose that we begin to use a module prefix to potentially disambiguate our methods from other modules.

-CWControl
-CWManage
-CWAutomate

Similar to how you would use Get-Az* when talking to Azure.

I know with the custom module I had started writing (not published anywhere, so no conflicts), I had started using CWAutomate as my prefix for this exact reason. I believe there is also a way to set the default prefix, and allow users to override that prefix when they import a module, we probably want to account for that if/when the prefix is modified.

This would also be a functionality-breaking change, unless we include aliases for the existing function names. I'm not sure if we would want to look at starting a new major version at this point, or more likely just add the aliases in the definitions for now?

Write Error Exception on v1.1.1

When following the instructions verbatim i get the error below. I did not have this issue following the same steps on v1.0.9. I fully uninstalled the module and reinstalled to test.

Both APIs successfully test and get tokens as well as the monitor is successfully installed on my instance. Both my Automate and Control server are CW hosted.

Cannot bind argument to parameter 'InputObject' because it is null.
Microsoft.PowerShell.Commands.WriteErrorException

Each machine also has the

JobType         : Restart Automate Services
JobState        : Completed
JobHasErrors    : True
JobResultStream :
AutofixSuccess  : False

Can you use this to update Extra Data fields for a machine?

Was hoping I could use this to not only get a list of machines that fit certain requirements, but then be able to loop through each machine and set one of their extra data fields to a certain value, is that possible with this?

Prompting for Automate Server when using -twofactortoken

Connect-AutomateAPI -ClientID $ID -Credential $Credential
-Server $server -SkipCheck
-TwoFactorToken $TwoFactorPasscode

Output:
Please enter your Automate Server address, IE: rancor.hostedrmm.com:
Expected:
Successfully tested and connected to the Automate REST API. Token will expire at 2022-03-0
1T18:24:49

Wondering if this is expected but when removing -TwoFactorToken it works correctly

Quiet parameter is not quiet

When using Connect-AutomateAPI -Quiet or connect-ControlAPI -quiet, the output shows "True". So in the end, its not that quiet.

It might be usefull for scripting to make it really quiet.

Unable to save Control Credentials in Set-CredentialsLocallyStored

At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI\1.1.1\Public\Helpers\Set-CredentialsLocallyStored.ps1:96 char:43
+             Connect-ControlAPI -Server '' -Force
+                                           ~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Connect-ControlAPI], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,Connect-ControlAPI

Connect-ControlSession does not accept Control SessionID

Connect-ControlSession should accept a parameter for Control SessionID, instead of just Automate computer name or ID, per @dkattan

Invoke-ControlCommand online check

If a command is executed against an offline computer, there is no need to wait until the timeout for a result. It should be queued and then the function can exit immediately.

Index operation failes; the array index evaluated to null

Index operation failed; the array index evaluated to null.
At C:\Program Files\WindowsPowerShell\Modules\AutomateAPI\1.1.1\Public\Get-ControlSessions.ps1:99 char:25

•                 If ($_.Date -ge $SCConnected[$_.SessionID]) {
  

•                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidOperation: (:) [], RuntimeException
  • FullyQualifiedErrorId : NullArrayIndex

Invoke-ControlCommand authorization can timeout when using the API key

The API Key is used to create a token that has a time limited validity of about 20 minutes. When using the API Key for authentication, if the command is allowed to run longer than this the token can expire.

This would not stop the remote command from running, but Invoke-ControlCommand would begin to get authorization failures while waiting.

Network Device data collection

Would find it useful to gather info on network devices, will be working on implementing this myself if it is not already in the pipeline

Add reverse search (find agents in Control and not in Automate)

Add reverse search (find agents in Control and not in Automate)

Credential handling needs reworked

Credential storage to local disk does not include Control credentials (#32), and helper functions are not intuitive nor follow Microsoft Verb best practices. See example code below for possible additional ideas:

#region *-CwaCredential
function Set-CwaCredential {
    [CmdletBinding()]
    Param (
        [parameter(Mandatory=$true,ValueFromPipelineByPropertyName,ValueFromPipeline)]
        [ValidateNotNull()]
        [System.Management.Automation.PSCredential]
        [System.Management.Automation.Credential()]
        $Credential = [System.Management.Automation.PSCredential]::Empty  
    )

    # Store credential for later use.
    Write-Verbose "Credential username = '$($Credential.UserName)'"
    $Script:CwaCredential = $credential
}

function Get-CwaCredential {
    [CmdletBinding()]
    Param (
    )

    $Script:CwaCredential.UserName
}

function Remove-CwaCredential {
    [CmdletBinding()]
    Param (
    )

    $Script:CwaCredential = $null
}

function Save-CwaCredential {
    [CmdletBinding()]
    Param (
        [String]
        $Path = "$env:USERPROFILE/.CwaCredential.xml"
    )

    $Script:CwaCredential | Export-CliXml -Path $path
}

function Load-CwaCredential {
    [CmdletBinding()]
    Param (
        [String]
        $Path = "$env:USERPROFILE/.CwaCredential.xml"
    )

    if( Test-Path -Path $Path ){
        $Script:CwaCredential = Import-CliXml -Path $Path
    }
}



#endregion *-CwaCredential