From 24d74751f7ac4b711cfbb66aef6e80545cf25476 Mon Sep 17 00:00:00 2001 From: dkattan <1424395+dkattan@users.noreply.github.com> Date: Sun, 14 Jan 2024 14:22:13 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20@=20immense/?= =?UTF-8?q?immybot-documentation@59f33b32e8abb672a9e0948b7c2b43d77b04163a?= =?UTF-8?q?=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 404.html | 4 ++-- FAQ.html | 4 ++-- README.html | 4 ++-- add-users.html | 4 ++-- azure-graph-permissions-setup.html | 4 ++-- build-your-own-integration.html | 4 ++-- connectwise-automate-integration-setup.html | 4 ++-- connectwise-control-integration-setup.html | 4 ++-- connectwise-manage-integration-setup.html | 4 ++-- getting-started.html | 4 ++-- halo-integration-setup.html | 4 ++-- hashmap.json | 2 +- immy-commands.html | 4 ++-- index.html | 4 ++-- markdown-examples.html | 4 ++-- ncentral-integration-setup.html | 4 ++-- onboarding.html | 4 ++-- recommended-deployments.html | 4 ++-- releases.html | 4 ++-- scripts.html | 4 ++-- terminology.html | 4 ++-- troubleshooting.html | 4 ++-- user-roles.html | 4 ++-- windows-sandbox.html | 4 ++-- 24 files changed, 47 insertions(+), 47 deletions(-) diff --git a/404.html b/404.html index 15938005..e9c1b8f3 100644 --- a/404.html +++ b/404.html @@ -14,8 +14,8 @@ -
immy.bot

Appearance

404

PAGE NOT FOUND

But if you don't change your direction, and if you keep looking, you may end up where you are heading.
Take me home
- +
immy.bot

Appearance

404

PAGE NOT FOUND

But if you don't change your direction, and if you keep looking, you may end up where you are heading.
Take me home
+ \ No newline at end of file diff --git a/FAQ.html b/FAQ.html index b61a0d3f..7ac71c9d 100644 --- a/FAQ.html +++ b/FAQ.html @@ -38,7 +38,7 @@ -
immy.bot

Appearance

Frequently Asked Questions ​

What is the differrence between the Starter and Standard plan? ​

Both plans allow you to import all of your existing agents into ImmyBot if you use one of our support integrations.

Both plans allow installing and updating of the ImmyBot agent on all of your existing computers.

Both plans allow running maintenance on all of your computers given that the computer was imported into ImmyBot in the last 7 days.

Starter ​

Starter does not charge maintenance per computer since it does not support ongoing maintenance for your computers.

Once a computer has been in ImmyBot for at least 7 days, maintenance can no longer be executed against it. This includes all onboarding, full maintenance, and adhoc sessions. If you need to manage ongoing maintenance against a computer older than 7 days, then you will need to upgrade to Standard.

Standard ​

Standard charges per maintained computer since it supports ongoing maintenance.

What is a maintained computer? ​

Since we allow you to import all of your agents into ImmyBot, we don't simply charge per agent.

Instead, we only consider computers that have received ongoing maintenance.

A computer has received ongoing maintenance if an onboarding, full maintenance, or adhoc session has been run against it after the computer has been in ImmyBot for over 7 days.

Maintenance per computer ​

When maintenance is performed against a computer older than 7 days, ImmyBot will check the following:

  1. Is this computer already counted towards your maintained count?

    • If it is, then maintenance can be performed on this computer.

  2. Are we at the maximum number of maintained computers for this subscription?

    • If it is not, then this computer will be added to your active maintained computer count, and maintenance can be performed on this computer.

When a subscription is at the maximum maintained count, only maintenance for computers considered in the count will be allowed. In order to run maintenance on other computers, you can purchase more computer licenses for your subscription.

Do I need a separate USB/Installer per tenant? ​

No. Create a USB pointing to your own tenant (or create an “Onboarding” tenant) and don’t select the Auto-Onboard option.

You will change the tenant of the computer on the Onboarding area of the computer after it comes into New Computers

ImmyBot does not deploy anything automatically. You can feel safe saving your Deployments. Think of them like documenting how things SHOULD be. If you want Immy to automatically enforce deployments, you would need the Immy Deploy plan which allows you to create schedules.

Think of it like if Group Policy only updated if you manually ran gpupdate /force or otherwise specified a schedule for the gpupdates to happen. We understand that updating and installing software on existing computers can be intrusive to the user which is why we schedule these actions out and give the user the ability to postpone via interactive emails.

IMPORTANT: If you setup integration with your RMM, when you map an RMM client to an ImmyBot tenant, ImmyBot will begin running inventory scripts on those machines every 24 hours. These scripts are read-only, but if you have aggressive monitoring software it may cause false alarms.

What if I don’t know which user will be using the computer? ​

Do your best to find out, or assign machines to specific users ahead of time. Without this, user level customizations are impossible. However, you may find yourself in a shared-computer scenario where every computer gets the same 365 applications. Simply create a deployment for those 365 applications for all computers under that tenant.

Can Immy join AzureAD? ​

Yes. Create a deployment for the Join AzureAD task. We use the bulk enrollment technique and generate a provisioning package to join the machine to AzureAD. At the time of writing, this requires you to create a user in each customer’s tenant. We plan to remove this requirement in the future.

My AzureAD Join action is failing, what are some common fixes? ​

Check if MFA Requirement for Joining is enabled via Conditional Access or Azure Device Settings. MFA requirement for all users in Conditional Access will also block the execution, as the package_XXX user will encounter a MFA prompt. Most other situations are noted during execution failure.

Can Immy make deploying via Intune more simple? ​

Absolutely! There is a global Task labeled "Deploy ImmyAgent to Intune" that can do an excellent job of it.

  • Ensure you are using the Custom Graph Permissions
  • Ensure you have added the Graph Application permission DeviceManagementConfiguration.ReadWrite.All to your app registration
  • Ensure you have re-consented to your linked tenants with your new Custom registration
  • If there is a failure of the deployment, there is likely a permissions issue with the app registration

Can Immy help migrate my customers to AzureAD from On-Premises environments? ​

Yes, we have a Task that can migrate machines to associate the user’s profile to their Azure AD identity and join the machine to Azure AD. It can also do the same to and from Active Directory

Domain Join didn’t work, what gives? ​

Make sure there is a Domain Controller in Immy for the machine. If you are using a supported RMM like CW Automate/Control setup the integration so the Domain Controller is imported automatically. Otherwise, you’ll need to install the ImmyAgent on a domain controller for that customer.

If the Domain Controller doesn’t have the red “Domain Controller” designation, press “Run Inventory”. This may happen if it was recently added to ImmyBot.

Pay attention to the script output, Immy may be reporting that there is a name collision, or that it was unable to run scripts on the domain controller, usually due to security software.

Why are my computers stuck in Identification ​

  1. The machine has a security tool like Defender for Endpoint, Crowdstrike, Bitdefender or Threatlocker blocking our scripts from running
  • You'll want to create exclusions for ImmyBot
  1. WMI is broken on the machine (Usually on older machines)

Can you target devices in Azure Groups? ​

Yes, but ImmyBot requires an additional permission on the ImmyBot app registration. You need to grant the Microsoft Graph - Devices.Read.All permission in order for devices to be pulled from Azure Groups.

How do I uninstall the ImmyAgent? ​

Create a deployment for the "ImmyBot Agent" and set software should be to "Uninstalled"

image

Or

Run the following from Command Line

wmic product where name="ImmyBot Agent" call uninstall /nointeractive
wmic product where name="ImmyBot Agent" call uninstall /nointeractive

Or

$product = Get-WmiObject win32_product | `
+    
immy.bot
Appearance
Frequently Asked Questions ​
What is the differrence between the Starter and Standard plan? ​
Both plans allow you to import all of your existing agents into ImmyBot if you use one of our support integrations.
Both plans allow installing and updating of the ImmyBot agent on all of your existing computers.
Both plans allow running maintenance on all of your computers given that the computer was imported into ImmyBot in the last 7 days.
Starter ​
Starter does not charge maintenance per computer since it does not support ongoing maintenance for your computers.
Once a computer has been in ImmyBot for at least 7 days, maintenance can no longer be executed against it. This includes all onboarding, full maintenance, and adhoc sessions. If you need to manage ongoing maintenance against a computer older than 7 days, then you will need to upgrade to Standard.
Standard ​
Standard charges per maintained computer since it supports ongoing maintenance.
What is a maintained computer? ​
Since we allow you to import all of your agents into ImmyBot, we don't simply charge per agent.
Instead, we only consider computers that have received ongoing maintenance.
A computer has received ongoing maintenance if an onboarding, full maintenance, or adhoc session has been run against it after the computer has been in ImmyBot for over 7 days.
Maintenance per computer ​
When maintenance is performed against a computer older than 7 days, ImmyBot will check the following:
  1. Is this computer already counted towards your maintained count?
    • If it is, then maintenance can be performed on this computer.
  2. Are we at the maximum number of maintained computers for this subscription?
    • If it is not, then this computer will be added to your active maintained computer count, and maintenance can be performed on this computer.
When a subscription is at the maximum maintained count, only maintenance for computers considered in the count will be allowed. In order to run maintenance on other computers, you can purchase more computer licenses for your subscription.
Do I need a separate USB/Installer per tenant? ​
No. Create a USB pointing to your own tenant (or create an “Onboarding” tenant) and don’t select the Auto-Onboard option.
You will change the tenant of the computer on the Onboarding area of the computer after it comes into New Computers
ImmyBot does not deploy anything automatically. You can feel safe saving your Deployments. Think of them like documenting how things SHOULD be. If you want Immy to automatically enforce deployments, you would need the Immy Deploy plan which allows you to create schedules.
Think of it like if Group Policy only updated if you manually ran gpupdate /force or otherwise specified a schedule for the gpupdates to happen. We understand that updating and installing software on existing computers can be intrusive to the user which is why we schedule these actions out and give the user the ability to postpone via interactive emails.
IMPORTANT: If you setup integration with your RMM, when you map an RMM client to an ImmyBot tenant, ImmyBot will begin running inventory scripts on those machines every 24 hours. These scripts are read-only, but if you have aggressive monitoring software it may cause false alarms.
What if I don’t know which user will be using the computer? ​
Do your best to find out, or assign machines to specific users ahead of time. Without this, user level customizations are impossible. However, you may find yourself in a shared-computer scenario where every computer gets the same 365 applications. Simply create a deployment for those 365 applications for all computers under that tenant.
Can Immy join AzureAD? ​
Yes. Create a deployment for the Join AzureAD task. We use the bulk enrollment technique and generate a provisioning package to join the machine to AzureAD. At the time of writing, this requires you to create a user in each customer’s tenant. We plan to remove this requirement in the future.
My AzureAD Join action is failing, what are some common fixes? ​
Check if MFA Requirement for Joining is enabled via Conditional Access or Azure Device Settings. MFA requirement for all users in Conditional Access will also block the execution, as the package_XXX user will encounter a MFA prompt. Most other situations are noted during execution failure.
Can Immy make deploying via Intune more simple? ​
Absolutely! There is a global Task labeled "Deploy ImmyAgent to Intune" that can do an excellent job of it.
  • Ensure you are using the Custom Graph Permissions
  • Ensure you have added the Graph Application permission DeviceManagementConfiguration.ReadWrite.All to your app registration
  • Ensure you have re-consented to your linked tenants with your new Custom registration
  • If there is a failure of the deployment, there is likely a permissions issue with the app registration
Can Immy help migrate my customers to AzureAD from On-Premises environments? ​
Yes, we have a Task that can migrate machines to associate the user’s profile to their Azure AD identity and join the machine to Azure AD. It can also do the same to and from Active Directory
Domain Join didn’t work, what gives? ​
Make sure there is a Domain Controller in Immy for the machine. If you are using a supported RMM like CW Automate/Control setup the integration so the Domain Controller is imported automatically. Otherwise, you’ll need to install the ImmyAgent on a domain controller for that customer.
If the Domain Controller doesn’t have the red “Domain Controller” designation, press “Run Inventory”. This may happen if it was recently added to ImmyBot.
Pay attention to the script output, Immy may be reporting that there is a name collision, or that it was unable to run scripts on the domain controller, usually due to security software.
Why are my computers stuck in Identification ​
  1. The machine has a security tool like Defender for Endpoint, Crowdstrike, Bitdefender or Threatlocker blocking our scripts from running
  • You'll want to create exclusions for ImmyBot
  1. WMI is broken on the machine (Usually on older machines)
Can you target devices in Azure Groups? ​
Yes, but ImmyBot requires an additional permission on the ImmyBot app registration. You need to grant the Microsoft Graph - Devices.Read.All permission in order for devices to be pulled from Azure Groups.
How do I uninstall the ImmyAgent? ​
Create a deployment for the "ImmyBot Agent" and set software should be to "Uninstalled"
image
Or
Run the following from Command Line
wmic product where name="ImmyBot Agent" call uninstall /nointeractive
wmic product where name="ImmyBot Agent" call uninstall /nointeractive
Or
$product = Get-WmiObject win32_product | `
 
 where{$_.name -eq "ImmyBot Agent"}
 
@@ -51,7 +51,7 @@
 $product.IdentifyingNumber
 
 msiexec /x $product.IdentifyingNumber /quiet /noreboot
How/are we able to define which version of Windows is installed during the initial setup? ​
ImmyBot doesn't install Windows on bare metal. The workflow is you unbox the system from Dell, HP, Lenovo, Microsoft, or your manufacturer of choice and insert the USB with the ImmyBot.ppkg file at the root while the machine is at the out of box screen.
We don't image the machine, we script the factory image into compliance.
We can, however, install Feature Updates during Onboarding (as well as after Onboarding)
Since Immy.Bot doesn’t use an ISO, does it require a device to have the ability to have 2 USB devices plugged in? One for a Windows ISO and one for the ImmyBot ppkg? ​
If you want to wipe the computer you can use the Media Creation Tool to create a Windows Setup flash drive and then put our .ppkg file on it. After installing Windows, it will automatically apply the .ppkg
Does Immy rely on the Windows preboot for drivers during initial deployment, or does the ImmyBot agent installer have drivers? ​
Since we are working with the manufacturer's image, all drivers are typically installed. We will automatically install Dell, HP, and Lenovo driver and BIOS updates via those manufacturer's tools (Dell Command, HP Image Assistant, Lenovo System Update)
Does Immy’s setup process support a USB NIC for WiFi? If so, how do we present those drivers to Immy, or do we even need to? ​
I've found Windows has built in drivers for most USB NICs. If yours doesn't have drivers built into Windows, I'd suggest purchasing one that does.
SentinelOne - How do we define which site Immy.Bot places the agent in during installation of the S1 agent? ​
Supply ImmyBot with an API Key to SentinelOne, and Immy will look for a Site in your SentinelOne instance that matches the name of the Tenant you are onboarding the computer for.
Are there any repository limits for software deployments? Either to the size of custom software or number of custom installers we can upload? ​
There are currently no limits. Everything you upload goes into an Azure Storage Account created just for your ImmyBot instance. Don't be the reason we can't have nice things.
For computer rename, are there any other operators we can use when naming devices other then the ones shown? Can we add operators? ​
You can duplicate the Task into your instance an manipulate it however you like. If it's something you think other MSPs could use, I'd encourage you to submit a request on the ImmyBot Community and we can add it.
Employee profile caching during on-boarding - is this supported? If so/how? ​
ImmyBot will create a profile for the Primary Person you selected for this machine on the Onboarding screen (It does this via the "Create Profile for Primary Person" task)
We do this so subsequent tasks that set user level settings like default PDF handler and default browser, have the profile for the primary person and thus that user's HKCU where those settings live.
For purchasing Immy, do you guys prefer Credit card or invoice? Would you rather us pay monthly, or can we pay all upfront? ​
We prefer monthly credit card or ACH.
Is Immy able to group devices and then do role based deployments to them? I assume this is done by tags? ​
Yes, you would accomplish this with tags
BitLocker - does this write the key to Azure AD by chance? ​
Yes, but we can't verify that it is written to Azure AD as that would require additional privileges that our App Registration doesn't request.
We also write the Bitlocker Recovery Key to Active Directory for Domain Joined machines. This doesn't require any Group Policy setup, or line of site to the domain controller. This works as long as the machine is joined to a domain and there is a domain controller for that domain in ImmyBot.
Is Immy able to reset Windows / Wipe and Reload a computer? ​
Yes, the current process will be simplified but here's how to do it:
  1. Click Download ImmyAgent on the left to create a PPKG with the Windows Reset option selected
image
image
  1. Create a Deployment for "Apply Provisioning Package (PPKG)" to deploy the PPKG to the specified machine
image
ImmyBot Agent logs show an error of "The specified SAS token is expired" ​
This will occur if the device's system time is incorrect. Ensure that the system time is correct and then restart the ImmyBot Agent Service.
What are trusted manufacturers? ​
Dell, HP, and Lenovo are considered trusted manufacturers. A trusted manufacturer is expected to provide unique serial numbers for their devices. We rely on trusted manufactuers and device serial numbers during device identification. If the agent reports it comes from a trusted manufacturer and a computer already exists inside ImmyBot with the same manufacturer and serial number, then we will automatically associated the agent with the existing computer.
Can I embed the ImmyAgent into an image? ​
Create a PPKG and place it in C:\Recovery\Customizations, create the folder if it doesn't exist.
You can also use SetupComplete This method was confirmed working on Server 2022.
Place both the ImmyAgent EXE installer and the SetupComplete.cmd in the C:\Windows\Setup\Scripts directory Content of SetupComplete.cmd can be as simple as: start C:\Windows\Setup\Scripts\ImmyAgentInstallerBundle.exe /qn
A member of the ImmyBot community also likes to use the below method to embedded a PPKG into an image:
DISM.exe /Image:D:\mount /Add-ProvisionedAppxPackage /PackagePath:C:\Users\Moi\Downloads\ImmyBotAgentInstaller.ppkg
DISM.exe /Image:D:\mount /Add-ProvisionedAppxPackage /PackagePath:C:\Users\Moi\Downloads\ImmyBotAgentInstaller.ppkg
Do you take requests for features/software/tasks/scripts? ​
Yes, please feel welcome to submit a request on the ImmyBot Community

-    
+    
     
   
 
\ No newline at end of file
diff --git a/README.html b/README.html
index 29da8b05..20b42f91 100644
--- a/README.html
+++ b/README.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
Welcome to ImmyBot Docs Github Repo ​
Changes made to the main branch here are pushed to https://docs.immy.bot/ automatically.
Feel free to contribute! We may even make you a contributor
To test locally, start by cloning this repo then opening the folder in VS Code.
VS Code will recommend certain extensions when opening it the first time, we recommend you install these.
Then run the following to install the required dependencies
yarn install
yarn install
To host locally, run
yarn docs:dev
yarn docs:dev

-    
+    
immy.bot
Appearance
Welcome to ImmyBot Docs Github Repo ​
Changes made to the main branch here are pushed to https://docs.immy.bot/ automatically.
Feel free to contribute! We may even make you a contributor
To test locally, start by cloning this repo then opening the folder in VS Code.
VS Code will recommend certain extensions when opening it the first time, we recommend you install these.
Then run the following to install the required dependencies
yarn install
yarn install
To host locally, run
yarn docs:dev
yarn docs:dev

+    
     
   
 
\ No newline at end of file
diff --git a/add-users.html b/add-users.html
index 50ef72ea..1dbedf7f 100644
--- a/add-users.html
+++ b/add-users.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
Adding Users ​
Have the person attempt to login to ImmyBot. Have them request access:
image
Approve that access from a yellow indicator at the top of the screen.
image

-    
+    
immy.bot
Appearance
Adding Users ​
Have the person attempt to login to ImmyBot. Have them request access:
image
Approve that access from a yellow indicator at the top of the screen.
image

+    
     
   
 
\ No newline at end of file
diff --git a/azure-graph-permissions-setup.html b/azure-graph-permissions-setup.html
index 791ac79c..94e24d8e 100644
--- a/azure-graph-permissions-setup.html
+++ b/azure-graph-permissions-setup.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
AzureAD/365 Graph Permissions ​
Your first ImmyBot tenant will be automatically linked to the Azure tenant that you signed up for ImmyBot with. You can link other ImmyBot tenants to Azure from the tenant Azure tab.
Linking to an Azure Tenant ​
After creating an ImmyBot tenant, link it to an Azure tenant by navigating to the Azure tab in ImmyBot and entering the Azure tenant's principal id or domain and clicking Save.
Azure Permission Level ​
Once your ImmyBot tenant has been linked to Azure, you can set the Azure Permission Level from the tenant Azure tab. This allows ImmyBot to:
  1. Sync all users from the Azure tenant
  2. Sync all users from your customer's tenants (if your Azure tenant is a Partner tenant)
  3. Install the 365 applications a user is licensed for (Apps for business/Apps for entrprise/Project/Visio)
  4. Deploy software to Teams, On-Premises Security Groups (Ex. Everyone in the Engineering Team gets AutoCAD 2022)
The Azure Permission Level has two modes: Default and Custom
NB: In both the Default and Custom modes, you must manually provide consent for each customer you want to sync!
NB: When consenting to an Azure customer, you must authenticate using an administrator account from that customer!
 Consent can be initiated from within ImmyBot by clicking on the Consent (or Reconsent) button for the customer on either the Azure Settings page or on the Azure tab of the ImmyBot tenant linked to the customer.
Default ​
In this mode, you don't need to create an app registration. You consent as an administrator, allowing ImmyBot access users in your tenant and your customers tenants (if you have established GDAP relationships with your customers and have consented with an admin from that customer).
Custom ​
In this mode, you create an App Registration and provide its Application (client) Id and Secret to ImmyBot, allowing you to customize the permissions Immy has to you and your customer's environments.
Create an App Registration ​
Navigate to: https://aad.portal.azure.com/
Important! Your app registration must have a Web redirect uri of https://<your-domain>.immy.bot/consent-callback, replacing <your-domain> appropriately
Grant Permissions ​
See the screenshots below for the minimum permissions.
image
image
Create Client Secret ​
Assign GDAP Permissions to ImmyBot Service Principal ​
  • Create a Security Group in Azure AD called "ImmyBot Security Group"
  • Add the ImmyBot Service Principal to that group
  • For each customer in the Partner Center, add the "ImmyBot Security Group" and add the "Directory Readers" and "Global Reader" role.
Copy the Application (client) ID and Client Secret Value into the form in ImmyBot. ​
Common Issues ​
AADSTS500113: No reply address is registered for the application ​
This error occurs when the redirect uri is not set correctly on the custom app registration. Please follow these steps to set the redirect uri correctly:
  1. Navigate to the Azure Portal
  2. Navigate to the Microsoft Entra ID blade
  3. Navigate to the App Registrations blade
  4. Select the app registration you created for ImmyBot 
    • You may need to change the filter to "All Applications"
    • You can paste the Application (client) ID of your custom app registration into the search box to find it image
  5. Navigate to the Authentication blade 
    • Select "Add a platform"
    • Select "Web" as the type image
    • Enter https://<your-domain>.immy.bot/consent-callback as the redirect uri, replacing <your-domain> appropriately
    • Click "Configure" image

-    
+    
immy.bot
Appearance
AzureAD/365 Graph Permissions ​
Your first ImmyBot tenant will be automatically linked to the Azure tenant that you signed up for ImmyBot with. You can link other ImmyBot tenants to Azure from the tenant Azure tab.
Linking to an Azure Tenant ​
After creating an ImmyBot tenant, link it to an Azure tenant by navigating to the Azure tab in ImmyBot and entering the Azure tenant's principal id or domain and clicking Save.
Azure Permission Level ​
Once your ImmyBot tenant has been linked to Azure, you can set the Azure Permission Level from the tenant Azure tab. This allows ImmyBot to:
  1. Sync all users from the Azure tenant
  2. Sync all users from your customer's tenants (if your Azure tenant is a Partner tenant)
  3. Install the 365 applications a user is licensed for (Apps for business/Apps for entrprise/Project/Visio)
  4. Deploy software to Teams, On-Premises Security Groups (Ex. Everyone in the Engineering Team gets AutoCAD 2022)
The Azure Permission Level has two modes: Default and Custom
NB: In both the Default and Custom modes, you must manually provide consent for each customer you want to sync!
NB: When consenting to an Azure customer, you must authenticate using an administrator account from that customer!
 Consent can be initiated from within ImmyBot by clicking on the Consent (or Reconsent) button for the customer on either the Azure Settings page or on the Azure tab of the ImmyBot tenant linked to the customer.
Default ​
In this mode, you don't need to create an app registration. You consent as an administrator, allowing ImmyBot access users in your tenant and your customers tenants (if you have established GDAP relationships with your customers and have consented with an admin from that customer).
Custom ​
In this mode, you create an App Registration and provide its Application (client) Id and Secret to ImmyBot, allowing you to customize the permissions Immy has to you and your customer's environments.
Create an App Registration ​
Navigate to: https://aad.portal.azure.com/
Important! Your app registration must have a Web redirect uri of https://<your-domain>.immy.bot/consent-callback, replacing <your-domain> appropriately
Grant Permissions ​
See the screenshots below for the minimum permissions.
image
image
Create Client Secret ​
Assign GDAP Permissions to ImmyBot Service Principal ​
  • Create a Security Group in Azure AD called "ImmyBot Security Group"
  • Add the ImmyBot Service Principal to that group
  • For each customer in the Partner Center, add the "ImmyBot Security Group" and add the "Directory Readers" and "Global Reader" role.
Copy the Application (client) ID and Client Secret Value into the form in ImmyBot. ​
Common Issues ​
AADSTS500113: No reply address is registered for the application ​
This error occurs when the redirect uri is not set correctly on the custom app registration. Please follow these steps to set the redirect uri correctly:
  1. Navigate to the Azure Portal
  2. Navigate to the Microsoft Entra ID blade
  3. Navigate to the App Registrations blade
  4. Select the app registration you created for ImmyBot 
    • You may need to change the filter to "All Applications"
    • You can paste the Application (client) ID of your custom app registration into the search box to find it image
  5. Navigate to the Authentication blade 
    • Select "Add a platform"
    • Select "Web" as the type image
    • Enter https://<your-domain>.immy.bot/consent-callback as the redirect uri, replacing <your-domain> appropriately
    • Click "Configure" image

+    
     
   
 
\ No newline at end of file
diff --git a/build-your-own-integration.html b/build-your-own-integration.html
index 163fd68f..15b43557 100644
--- a/build-your-own-integration.html
+++ b/build-your-own-integration.html
@@ -38,7 +38,7 @@
     
   
   
-    
immy.bot
Appearance
Build Your Own Integrations ​
The goal of this feature is primarily for our own use to more rapidly implement integrations with other RMMs and PSA, but we have opened it up for you to create your own integrations as well.
Concepts ​
Behind the scenes, an integration is any class that inherits from the IProvider interface.
We have created a new Integration script type with New-DynamicIntegration and Add-DynamicIntegrationCapability Cmdlets that allow you to construct your own IProvider and give it capabilities, all within PowerShell.
Integrations capabilities are defined in interfaces typically prefixed with ISupports...
Let's say you want your integration to have a Client mapping UI in ImmyBot. You would implement ISupportsListingClients which has a GetClients method.
When loading your integration, the ImmyBot engine will recognize that integration is ISupportsListingClients and will show the Clients tab on the Integration page.
image
Dynamic Integration Capabilities ​
  • List Customers from the remote system so they can be mapped in the ImmyBot UI
  • List Computers/Agents (Think RMM Agent, AV agent etc) from a remote system
  • Provide an inventory script that returns the agent id (that gets mapped to the id from the API)
  • Provide Tenant level install tokens automatically scoped based on the Customer mapping above
  • Disable/Enable Maintenance Mode/Learning Mode in remote systems during maintenance
  • Respond to HttpRequests in PowerShell (like an Azure PowerShell function) but utilizing the Metascript engine
Basic Implementation ​
powershell
New-DynamicIntegration -Init {
+    
immy.bot
Appearance
Build Your Own Integrations ​
The goal of this feature is primarily for our own use to more rapidly implement integrations with other RMMs and PSA, but we have opened it up for you to create your own integrations as well.
Concepts ​
Behind the scenes, an integration is any class that inherits from the IProvider interface.
We have created a new Integration script type with New-DynamicIntegration and Add-DynamicIntegrationCapability Cmdlets that allow you to construct your own IProvider and give it capabilities, all within PowerShell.
Integrations capabilities are defined in interfaces typically prefixed with ISupports...
Let's say you want your integration to have a Client mapping UI in ImmyBot. You would implement ISupportsListingClients which has a GetClients method.
When loading your integration, the ImmyBot engine will recognize that integration is ISupportsListingClients and will show the Clients tab on the Integration page.
image
Dynamic Integration Capabilities ​
  • List Customers from the remote system so they can be mapped in the ImmyBot UI
  • List Computers/Agents (Think RMM Agent, AV agent etc) from a remote system
  • Provide an inventory script that returns the agent id (that gets mapped to the id from the API)
  • Provide Tenant level install tokens automatically scoped based on the Customer mapping above
  • Disable/Enable Maintenance Mode/Learning Mode in remote systems during maintenance
  • Respond to HttpRequests in PowerShell (like an Azure PowerShell function) but utilizing the Metascript engine
Basic Implementation ​
powershell
New-DynamicIntegration -Init {
     [OpResult]::Ok()
 } -HealthCheck {
     New-HealthyResult 
@@ -885,7 +885,7 @@
 }
 
 $Integration
image

-    
+    
     
   
 
\ No newline at end of file
diff --git a/connectwise-automate-integration-setup.html b/connectwise-automate-integration-setup.html
index 20f71b15..43375ac5 100644
--- a/connectwise-automate-integration-setup.html
+++ b/connectwise-automate-integration-setup.html
@@ -40,8 +40,8 @@
     
   
   
-    
immy.bot
Appearance
ConnectWise Automate ​
Setting up this integration allows you to
  1. Import customers from Automate
  2. Import computers from Automate
  3. Manage all computers in Automate without deploying the ImmyBot Agent
  4. Map customers from Manage to ImmyBot tenant based on existing Automate<->Manage relationship
Create ImmyBot Role ​
ImmyBot requires the following permissions in Automate
  • Core 
    • Clients.Read
    • Clients.Show All
    • Computers.Show All
    • Computers.Edit (For moving existing computers to new locations
    • Computers.Delete (For retiring duplicate computers)
    • Groups.Show All
    • Locations.Show All
    • Patch Manager.Read (Required if you want Immy to apply approved Windows Updates)
Immy-CWA-User Class Manager-Permissions
Create ImmyBot User ​
Enable Google MFA for ImmyBot User ​
The integration requires Google for MFA. Duo is not supported as Duo does not expose the MFA token anywhere for us to use and doesn't appear to be the standard TOTP like Google uses. You will need to exclude the integration user from your Duo deployment if using Duo and configure the Google MFA plugin for Automate for this user.
image
Import your customers ​
Alternatively, you can create/map only certain customers.
When you map a customer from an RMM, the computers will undergo Identification

-    
+    
immy.bot
Appearance
ConnectWise Automate ​
Setting up this integration allows you to
  1. Import customers from Automate
  2. Import computers from Automate
  3. Manage all computers in Automate without deploying the ImmyBot Agent
  4. Map customers from Manage to ImmyBot tenant based on existing Automate<->Manage relationship
Create ImmyBot Role ​
ImmyBot requires the following permissions in Automate
  • Core 
    • Clients.Read
    • Clients.Show All
    • Computers.Show All
    • Computers.Edit (For moving existing computers to new locations
    • Computers.Delete (For retiring duplicate computers)
    • Groups.Show All
    • Locations.Show All
    • Patch Manager.Read (Required if you want Immy to apply approved Windows Updates)
Immy-CWA-User Class Manager-Permissions
Create ImmyBot User ​
Enable Google MFA for ImmyBot User ​
The integration requires Google for MFA. Duo is not supported as Duo does not expose the MFA token anywhere for us to use and doesn't appear to be the standard TOTP like Google uses. You will need to exclude the integration user from your Duo deployment if using Duo and configure the Google MFA plugin for Automate for this user.
image
Import your customers ​
Alternatively, you can create/map only certain customers.
When you map a customer from an RMM, the computers will undergo Identification

+    
     
   
 
\ No newline at end of file
diff --git a/connectwise-control-integration-setup.html b/connectwise-control-integration-setup.html
index 44b4c35f..45c9d6e9 100644
--- a/connectwise-control-integration-setup.html
+++ b/connectwise-control-integration-setup.html
@@ -39,7 +39,7 @@
     
   
   
-    
immy.bot
Appearance
ConnectWise Control ​
Setting up this integration allows you to
  1. Import customers from Control
  2. Import computers from Control
  3. Manage all computers in Control without deploying the ImmyBot Agent
  4. Remote into computers from the ImmyBot interface using Control (Note: We default to requiring customer consent, you can disable this under Settings->Preferences)
  5. Fix the Automate agent using the Control agent (by creating a cross-tenant deployment for the Automate Agent and creating a schedule for your customers)
Install ImmyBot Extension for Control ​
imageimageimage
FAQ ​
What custom property do I use?
By default most ConnectWise Control instances you would select 1 for the ClientName CustomProperty field, this is the "Company" property in Control. Secondary group is any number between 1-8 that you would like to group from based on Control groups. You can find more infomation about Control custom propertys here; https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Administration_page/Appearance_page/Add_custom_properties_to_sessions
Import your customers ​
Alternatively, you can create/map only certain customers.
When you map a customer from an RMM, the computers will undergo Identification
Troubleshooting ​
ConnectWise Control uses Sqlite under the hood, making it vulnerable to performance issues unless aggressive Database Maintenance Tasks are enabled.
While ImmyBot only uses Control (and other integrations) to spawn an out-of-band connection, over the course of time the database can grow as ImmyBot establishes this connection on each machine once every 24 hours to collect inventory.
Commands go into the SessionEvent table with EventType = 44 Responses go into SessionConnectionEvent with EventType = 70
Automatic Cleanup ​
Ensure you have the following maintenance actions: Access Sessions: Purge records of session activity older than 7 days for all events EXCEPT AddedNote
image
Access Sessions: Purge records of session connections older than 7 days for Host and Guest connections
image
Manual Cleanup ​
If you host Control yourself, you can restore performance by doing the following
Download and Install DB Browser for SQLite on your server Open C:\Program Files (x86)\ScreenConnect\App_Data\session.db Navigate to SQL Editor Paste in the following SQL
Soft delete all commands and responses (This usually solves the problem without kicking everyone out of Control) ​
sql
update SessionEvent set EventAttributes = 1 where EventType = 44;
+    
immy.bot
Appearance
ConnectWise Control ​
Setting up this integration allows you to
  1. Import customers from Control
  2. Import computers from Control
  3. Manage all computers in Control without deploying the ImmyBot Agent
  4. Remote into computers from the ImmyBot interface using Control (Note: We default to requiring customer consent, you can disable this under Settings->Preferences)
  5. Fix the Automate agent using the Control agent (by creating a cross-tenant deployment for the Automate Agent and creating a schedule for your customers)
Install ImmyBot Extension for Control ​
imageimageimage
FAQ ​
What custom property do I use?
By default most ConnectWise Control instances you would select 1 for the ClientName CustomProperty field, this is the "Company" property in Control. Secondary group is any number between 1-8 that you would like to group from based on Control groups. You can find more infomation about Control custom propertys here; https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Administration_page/Appearance_page/Add_custom_properties_to_sessions
Import your customers ​
Alternatively, you can create/map only certain customers.
When you map a customer from an RMM, the computers will undergo Identification
Troubleshooting ​
ConnectWise Control uses Sqlite under the hood, making it vulnerable to performance issues unless aggressive Database Maintenance Tasks are enabled.
While ImmyBot only uses Control (and other integrations) to spawn an out-of-band connection, over the course of time the database can grow as ImmyBot establishes this connection on each machine once every 24 hours to collect inventory.
Commands go into the SessionEvent table with EventType = 44 Responses go into SessionConnectionEvent with EventType = 70
Automatic Cleanup ​
Ensure you have the following maintenance actions: Access Sessions: Purge records of session activity older than 7 days for all events EXCEPT AddedNote
image
Access Sessions: Purge records of session connections older than 7 days for Host and Guest connections
image
Manual Cleanup ​
If you host Control yourself, you can restore performance by doing the following
Download and Install DB Browser for SQLite on your server Open C:\Program Files (x86)\ScreenConnect\App_Data\session.db Navigate to SQL Editor Paste in the following SQL
Soft delete all commands and responses (This usually solves the problem without kicking everyone out of Control) ​
sql
update SessionEvent set EventAttributes = 1 where EventType = 44;
 update SessionConnectionEvent set EventAttributes = 1 where EventType = 70;
update SessionEvent set EventAttributes = 1 where EventType = 44;
 update SessionConnectionEvent set EventAttributes = 1 where EventType = 70;
You will need to commit the changes in DB Browser. You can do this by clicking Write Changes at the top by clicking File->Save If you forget to tdo this it will prompt you to commit the changes, when you exit, click yes.
The reason this works is because the UI doesn't fetch soft-deleted items, so things become much snappier.
However, if it doesn't work, do you following
Delete commands and responses older than 7 days ​
sql
-- Delete queue commands in db older than 7 days
 DELETE
@@ -58,7 +58,7 @@
 DELETE
 FROM SessionConnectionEvent
 WHERE (EventType = 70) AND (Time < DATETIME('now', '-7 day'))

-    
+    
     
   
 
\ No newline at end of file
diff --git a/connectwise-manage-integration-setup.html b/connectwise-manage-integration-setup.html
index d246805d..a751515d 100644
--- a/connectwise-manage-integration-setup.html
+++ b/connectwise-manage-integration-setup.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
ConnectWise Manage ​
Setting up this integration allows you to
  1. Deploy Software to machines covered by a certain agreement type
  • Example: Deploy Huntress to all customers with a Managed Security Agreement
  1. (Preferred) Deploy Software to machines covered by an Agreement with a specific Addition
  • Example: Deploy SentinelOne to all computers that have SentinelOne as an Addition on their agreement
If you use Automate, setup the Automate integration first and import your customers from there. Importing customers from Manage generally results in many unnecessary Tenants being created in ImmyBot. You can link Automate to Manage to leverage the existing mappings between Automate<->Manage instead of manually mapping your Manage customers
Create an ImmyBot Role with the following permissions ​
  • Company -> Company Maintenance -> Inquire Level (All)
  • Finance -> Agreements -> Inquire Level (All)
  • Procurement -> Product Catalog -> Inquire Level (All)
  • Procurement -> Product -> Inquire Level (All)
  • System -> API Reports -> Inquire Level (All)
Create an API Member ​
Go to System -> Members and create a new API Member
Create a new API key
Plugin the API Keys in ImmyBot ​
Create a new PSA Link and fill in the Provider Info
CW Manage Pod v1 ​
Go to Show More -> Integrations
Add CW Manage Pod
Go to ConnectWise -> Setup Tables -> Manage Hosted API -> +
image

-    
+    
immy.bot
Appearance
ConnectWise Manage ​
Setting up this integration allows you to
  1. Deploy Software to machines covered by a certain agreement type
  • Example: Deploy Huntress to all customers with a Managed Security Agreement
  1. (Preferred) Deploy Software to machines covered by an Agreement with a specific Addition
  • Example: Deploy SentinelOne to all computers that have SentinelOne as an Addition on their agreement
If you use Automate, setup the Automate integration first and import your customers from there. Importing customers from Manage generally results in many unnecessary Tenants being created in ImmyBot. You can link Automate to Manage to leverage the existing mappings between Automate<->Manage instead of manually mapping your Manage customers
Create an ImmyBot Role with the following permissions ​
  • Company -> Company Maintenance -> Inquire Level (All)
  • Finance -> Agreements -> Inquire Level (All)
  • Procurement -> Product Catalog -> Inquire Level (All)
  • Procurement -> Product -> Inquire Level (All)
  • System -> API Reports -> Inquire Level (All)
Create an API Member ​
Go to System -> Members and create a new API Member
Create a new API key
Plugin the API Keys in ImmyBot ​
Create a new PSA Link and fill in the Provider Info
CW Manage Pod v1 ​
Go to Show More -> Integrations
Add CW Manage Pod
Go to ConnectWise -> Setup Tables -> Manage Hosted API -> +
image

+    
     
   
 
\ No newline at end of file
diff --git a/getting-started.html b/getting-started.html
index 7985094e..3a9b98f7 100644
--- a/getting-started.html
+++ b/getting-started.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
Getting Started / Thinking with Immy ​
The goal of ImmyBot is to setup a computer knowing only the customer and the end user.
Thinking with Immy means thinking in terms of how things "Should" be.
You teach Immy how things "should" be by creating Deployments.
null
null
How things "Should" be is often dependent on external factors. For example
  • Customer A should have SentinelOne because they pay for it
  • Person A should have Visio 365 because he has a license for it
Luckily, deployments can be conditionally applied based on the result of scripts that reach out to external sources
null
null
This is out of the box functionality in ImmyBot. I'm just showing you how it works to illustrate the power of the rules engine.
Overview ​
ImmyBot deploys 2 things:
  1. Software
  2. Tasks
Tasks are for anything that isn’t software, think Bitlocker, Power Options, etc.
  • You can use Tasks to configure software by selecting a "Configuration Task" for the software
  • Configuration Tasks are useful for configuring the application (even if the application wasn't installed by ImmyBot)
  • Configuration Tasks run after Immy determines the software is installed
  • Configuration Task parameters are available in all scripts related to the software
ImmyBot tests everything it does before and after it does it.
  • Software 
    • Version Detection - Runs before install to determine if installation is necessary, and after to verify the desired version is installed 
      • DisplayName 
        • Contains
        • Regex
        • Traditional (Wildcard *)
      • UpgradeCode (For MSI based installs)
      • Script 
        • Must return a version or null
    • Test Script - If software is installed, the failure of this test (the test script returning $false) will trigger a "Repair" action (default Uninstall/Install) of the application 
      • Example: Check to verify Foxit PDF Editor is the Preview handler extension is working in Windows Explorer, reinstalling the PDF Editor usually corrects this scenario
  • Tasks 
    • Test script (When using separate scripts)
    • Combined script returns $false when $method is 'test'
Example: Adobe Reader ​
We find that most MSPs install Adobe Reader by default so ImmyBot includes a Recommended Deployment that states
  • "the latest version of Adobe Reader should be installed for all Workstations and Portable Devices"
When this rule applies (i.e. it isn't disabled or overridden by a more specific rule) ImmyBot will do the following:
  1. Find the latest available version of Adobe Reader by running the Adobe Reader "dynamic version" script that uses a public API to return the latest full version number of Adobe Reader, as well as the URL to download it, the latest patch version of Adobe Reader, and the URL to download it.
  2. Determine the installed version (if any) by looking for Adobe Reader in Add/Remove Programs on the machine
  3. Queue an Install or Upgrade task (depending on the previous step)
  4. Set Adobe Reader to be the default PDF handler by running the "configuration task" that verifies that Reader is the default handler for .PDF files for each user on the machine.

-    
+    
immy.bot
Appearance
Getting Started / Thinking with Immy ​
The goal of ImmyBot is to setup a computer knowing only the customer and the end user.
Thinking with Immy means thinking in terms of how things "Should" be.
You teach Immy how things "should" be by creating Deployments.
null
null
How things "Should" be is often dependent on external factors. For example
  • Customer A should have SentinelOne because they pay for it
  • Person A should have Visio 365 because he has a license for it
Luckily, deployments can be conditionally applied based on the result of scripts that reach out to external sources
null
null
This is out of the box functionality in ImmyBot. I'm just showing you how it works to illustrate the power of the rules engine.
Overview ​
ImmyBot deploys 2 things:
  1. Software
  2. Tasks
Tasks are for anything that isn’t software, think Bitlocker, Power Options, etc.
  • You can use Tasks to configure software by selecting a "Configuration Task" for the software
  • Configuration Tasks are useful for configuring the application (even if the application wasn't installed by ImmyBot)
  • Configuration Tasks run after Immy determines the software is installed
  • Configuration Task parameters are available in all scripts related to the software
ImmyBot tests everything it does before and after it does it.
  • Software 
    • Version Detection - Runs before install to determine if installation is necessary, and after to verify the desired version is installed 
      • DisplayName 
        • Contains
        • Regex
        • Traditional (Wildcard *)
      • UpgradeCode (For MSI based installs)
      • Script 
        • Must return a version or null
    • Test Script - If software is installed, the failure of this test (the test script returning $false) will trigger a "Repair" action (default Uninstall/Install) of the application 
      • Example: Check to verify Foxit PDF Editor is the Preview handler extension is working in Windows Explorer, reinstalling the PDF Editor usually corrects this scenario
  • Tasks 
    • Test script (When using separate scripts)
    • Combined script returns $false when $method is 'test'
Example: Adobe Reader ​
We find that most MSPs install Adobe Reader by default so ImmyBot includes a Recommended Deployment that states
  • "the latest version of Adobe Reader should be installed for all Workstations and Portable Devices"
When this rule applies (i.e. it isn't disabled or overridden by a more specific rule) ImmyBot will do the following:
  1. Find the latest available version of Adobe Reader by running the Adobe Reader "dynamic version" script that uses a public API to return the latest full version number of Adobe Reader, as well as the URL to download it, the latest patch version of Adobe Reader, and the URL to download it.
  2. Determine the installed version (if any) by looking for Adobe Reader in Add/Remove Programs on the machine
  3. Queue an Install or Upgrade task (depending on the previous step)
  4. Set Adobe Reader to be the default PDF handler by running the "configuration task" that verifies that Reader is the default handler for .PDF files for each user on the machine.

+    
     
   
 
\ No newline at end of file
diff --git a/halo-integration-setup.html b/halo-integration-setup.html
index 25a1f8b7..6eb38e0b 100644
--- a/halo-integration-setup.html
+++ b/halo-integration-setup.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
HaloPSA ​
Setting up this integration allows you to
  1. Deploy Software to machines covered by a certain contract type
  • Example: Deploy Huntress to all customers with a Managed Security Contract
  1. (Preferred) Deploy Software to machines covered by an Contract with a specific recurring invoice item
  • Example: Deploy SentinelOne to all computers that have SentinelOne on a recurring invoice as a recurring invoice item on their contract
Create an ImmyBot Application under /config/integrations/api/applications ​
  • Under the details section, select the Client ID and Secret Authentication Method
  • Generate and copy the Client ID and Client Secret
  • The Login Type should be "Agent", and you should select an "Agent to log in as"
Permissions: ​
  • read:customers -> Yes
  • read:contracts -> Yes
  • read:items -> Yes
  • edit:items -> Yes (*should not be needed > 2.99, API bug will not allow listing items without edit rights)
  • read:invoices -> Yes
  • read:software -> Yes
  • read:assets -> Yes (*future feature of the integration will include asset population, not currently necessary)
  • edit:assets -> Yes (*future feature of the integration will include asset population, not currently necessary)
Plug in the Client ID and Client Secret in ImmyBot ​
Create a HaloPSA Integration Link and fill in the Integration Settings
image

-    
+    
immy.bot
Appearance
HaloPSA ​
Setting up this integration allows you to
  1. Deploy Software to machines covered by a certain contract type
  • Example: Deploy Huntress to all customers with a Managed Security Contract
  1. (Preferred) Deploy Software to machines covered by an Contract with a specific recurring invoice item
  • Example: Deploy SentinelOne to all computers that have SentinelOne on a recurring invoice as a recurring invoice item on their contract
Create an ImmyBot Application under /config/integrations/api/applications ​
  • Under the details section, select the Client ID and Secret Authentication Method
  • Generate and copy the Client ID and Client Secret
  • The Login Type should be "Agent", and you should select an "Agent to log in as"
Permissions: ​
  • read:customers -> Yes
  • read:contracts -> Yes
  • read:items -> Yes
  • edit:items -> Yes (*should not be needed > 2.99, API bug will not allow listing items without edit rights)
  • read:invoices -> Yes
  • read:software -> Yes
  • read:assets -> Yes (*future feature of the integration will include asset population, not currently necessary)
  • edit:assets -> Yes (*future feature of the integration will include asset population, not currently necessary)
Plug in the Client ID and Client Secret in ImmyBot ​
Create a HaloPSA Integration Link and fill in the Integration Settings
image

+    
     
   
 
\ No newline at end of file
diff --git a/hashmap.json b/hashmap.json
index 40b70e61..fc66d3b5 100644
--- a/hashmap.json
+++ b/hashmap.json
@@ -1 +1 @@
-{"recommended-deployments.md":"bf148213","readme.md":"438fc68f","connectwise-automate-integration-setup.md":"8e02436d","getting-started.md":"77eeb39a","halo-integration-setup.md":"88bc1610","azure-graph-permissions-setup.md":"3fed08cf","ncentral-integration-setup.md":"3ada0ca9","faq.md":"0dd929cc","onboarding.md":"aa130f5b","index.md":"f2f4a8f7","connectwise-manage-integration-setup.md":"1a6ece37","immy-commands.md":"3f95c339","connectwise-control-integration-setup.md":"71f4a6e4","releases.md":"0cef9d51","add-users.md":"f8ba72ba","user-roles.md":"83b890f7","markdown-examples.md":"00357284","windows-sandbox.md":"420f9908","build-your-own-integration.md":"b4fea51b","scripts.md":"7cb2a745","troubleshooting.md":"3e2ed566","terminology.md":"3d3e6554"}
+{"add-users.md":"f8ba72ba","azure-graph-permissions-setup.md":"3fed08cf","halo-integration-setup.md":"88bc1610","recommended-deployments.md":"bf148213","connectwise-manage-integration-setup.md":"1a6ece37","index.md":"f2f4a8f7","onboarding.md":"aa130f5b","windows-sandbox.md":"420f9908","faq.md":"0dd929cc","connectwise-control-integration-setup.md":"71f4a6e4","scripts.md":"7cb2a745","terminology.md":"3d3e6554","getting-started.md":"77eeb39a","readme.md":"438fc68f","connectwise-automate-integration-setup.md":"8e02436d","user-roles.md":"83b890f7","troubleshooting.md":"3e2ed566","markdown-examples.md":"00357284","ncentral-integration-setup.md":"3ada0ca9","immy-commands.md":"3f95c339","releases.md":"0cef9d51","build-your-own-integration.md":"b4fea51b"}
diff --git a/immy-commands.html b/immy-commands.html
index a49d2371..25d635b1 100644
--- a/immy-commands.html
+++ b/immy-commands.html
@@ -38,7 +38,7 @@
     
   
   
-    
immy.bot
Appearance
Metascripts / Cloud Scripts ​
A Metascript is a script that runs scripts. These scripts run in the backend of ImmyBot.
A Metascript can run a script on a computer using Invoke-ImmyCommand.
Example ​
powershell
$ServerPSVersionTable = $PSVersionTable
+    
immy.bot
Appearance
Metascripts / Cloud Scripts ​
A Metascript is a script that runs scripts. These scripts run in the backend of ImmyBot.
A Metascript can run a script on a computer using Invoke-ImmyCommand.
Example ​
powershell
$ServerPSVersionTable = $PSVersionTable
 $ComputerPSVersionTable = Invoke-ImmyCommand {
     $ServerPSVersionTable = $using:ServerPSVersionTable
     Write-Host "Running from $env:ComputerName but ImmyBot backend is running PowerShell $($ServerPSVersionTable.PSVersion)" -ForegroundColor Green
@@ -193,7 +193,7 @@
 $versionString = $url -split '/' | select -Last 1 -Skip 1
 $latestVersion = $SoftwareVersions | sort SemanticVersion | select -last 1
 $createdVersion = Add-SoftwareVersion -SoftwareVersion $latestVersion -SemanticVersion  $versionString -Url $url
Get-AllLocalScripts ​
Coming Soon
Get-AllGlobalScripts ​
Coming Soon
CW Automate Commands ​
Invoke-CWAQuery ​
Coming Soon
Invoke-CWARestMethod ​
Coming Soon
Get-CWARestPages ​
Coming Soon

-    
+    
     
   
 
\ No newline at end of file
diff --git a/index.html b/index.html
index 9f9eca89..d8a58b73 100644
--- a/index.html
+++ b/index.html
@@ -38,8 +38,8 @@
     
   
   
-    
-    
+    
+    
     
   
 
\ No newline at end of file
diff --git a/markdown-examples.html b/markdown-examples.html
index 61cca229..532079f2 100644
--- a/markdown-examples.html
+++ b/markdown-examples.html
@@ -38,7 +38,7 @@
     
   
   
-    
immy.bot
Appearance
Markdown Extension Examples ​
This page demonstrates some of the built-in markdown extensions provided by VitePress.
Syntax Highlighting ​
VitePress provides Syntax Highlighting powered by Shiki, with additional features like line-highlighting:
Input
```js{4}
+    
immy.bot
Appearance
Markdown Extension Examples ​
This page demonstrates some of the built-in markdown extensions provided by VitePress.
Syntax Highlighting ​
VitePress provides Syntax Highlighting powered by Shiki, with additional features like line-highlighting:
Input
```js{4}
 export default {
   data () {
     return {
@@ -103,7 +103,7 @@
 ::: details
 This is a details block.
 :::
Output
INFO
This is an info box.
TIP
This is a tip.
WARNING
This is a warning.
DANGER
This is a dangerous warning.
Details
This is a details block.
More ​
Check out the documentation for the full list of markdown extensions.

-    
+    
     
   
 
\ No newline at end of file
diff --git a/ncentral-integration-setup.html b/ncentral-integration-setup.html
index f1db3221..2a9aa039 100644
--- a/ncentral-integration-setup.html
+++ b/ncentral-integration-setup.html
@@ -40,8 +40,8 @@
     
   
   
-    
immy.bot
Appearance
N-Central Integration ​
Setting up this integration allows you to
  1. Import customers from N-Central
  2. Import computers from N-Central
  3. Manage all computers in N-Central without deploying the ImmyBot Agent
Create ImmyBot Role in N-Central ​
ImmyBot currently requires the following role permissions to operate correctly:
Devices ​
  • Devices View 
    • All Devices -> Read Only
  • Direct Support 
    • Command Prompt -> Manage
    • File System -> Manage
  • Remote Control 
    • Custom -> Manage
    • Take Control -> Manage
  • Network Devices 
    • Add/Import Devices -> Manage
    • Edit Device Settings -> Manage
Create an "ImmyBot" role in your N-Central instance using above roles. 
Create ImmyBot user in N-Central ​
Create a new "ImmyBot" user in the instance with the "ImmyBot" role applied. 
Login to the new ImmyBot user to get MFA code and accept EULA ​
Once you have created the new ImmyBot user account, you must attempt to login so that you may retrieve the MFA key, and complete any initial setup. After entering the accounts email and password, there will be a MFA QR code displayed. You MUST press the "CAN'T SCAN IT?" button to get the Base32-encoded MFA key. After saving the key, use a site such as this to get the current token from the key, or temporarily scan the QR code on a device to complete sign-in. 
TIP
Make sure you accept the EULA when you login, otherwise the computers will not import!
Add integration for N-Central ​
After completing setup in N-Central, it's time to add the integration to ImmyBot. Navigate to the "Integrations" page in ImmyBot, and create a new "N-Central" integration. Input all the N-Central user account data to the fields on the right. 
Press the "Verify Credentials" button, then, if completed successfully, press the button again to save the integration.
Import your customers ​
Alternatively, you can create/map only certain customers.
When you map a customer from an RMM, the computers will undergo Identification
Troubleshooting ​
My customers are showing up but no computers ​
Login to N-Central as the ImmyBot User and accept the EULA

-    
+    
immy.bot
Appearance
N-Central Integration ​
Setting up this integration allows you to
  1. Import customers from N-Central
  2. Import computers from N-Central
  3. Manage all computers in N-Central without deploying the ImmyBot Agent
Create ImmyBot Role in N-Central ​
ImmyBot currently requires the following role permissions to operate correctly:
Devices ​
  • Devices View 
    • All Devices -> Read Only
  • Direct Support 
    • Command Prompt -> Manage
    • File System -> Manage
  • Remote Control 
    • Custom -> Manage
    • Take Control -> Manage
  • Network Devices 
    • Add/Import Devices -> Manage
    • Edit Device Settings -> Manage
Create an "ImmyBot" role in your N-Central instance using above roles. 
Create ImmyBot user in N-Central ​
Create a new "ImmyBot" user in the instance with the "ImmyBot" role applied. 
Login to the new ImmyBot user to get MFA code and accept EULA ​
Once you have created the new ImmyBot user account, you must attempt to login so that you may retrieve the MFA key, and complete any initial setup. After entering the accounts email and password, there will be a MFA QR code displayed. You MUST press the "CAN'T SCAN IT?" button to get the Base32-encoded MFA key. After saving the key, use a site such as this to get the current token from the key, or temporarily scan the QR code on a device to complete sign-in. 
TIP
Make sure you accept the EULA when you login, otherwise the computers will not import!
Add integration for N-Central ​
After completing setup in N-Central, it's time to add the integration to ImmyBot. Navigate to the "Integrations" page in ImmyBot, and create a new "N-Central" integration. Input all the N-Central user account data to the fields on the right. 
Press the "Verify Credentials" button, then, if completed successfully, press the button again to save the integration.
Import your customers ​
Alternatively, you can create/map only certain customers.
When you map a customer from an RMM, the computers will undergo Identification
Troubleshooting ​
My customers are showing up but no computers ​
Login to N-Central as the ImmyBot User and accept the EULA

+    
     
   
 
\ No newline at end of file
diff --git a/onboarding.html b/onboarding.html
index a69a682d..41f5316b 100644
--- a/onboarding.html
+++ b/onboarding.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
Setup your first Computer ​
When you first login to ImmyBot the Getting Started Wizard will be prompt you to create your ImmyBot flash drive, and plug it into the new computer.
THIS IS A ONE TIME PROCESS, YOU DO NOT NEED TO CREATE A FLASH DRIVE FOR EACH CLIENT. YOU WILL CHANGE THE CLIENT AFTER THE MACHINE IS IN IMMYBOT
image
We recommend unboxing a physical computer (Dell, HP, or Lenovo) so we can demonstrate applying the latest manufacturer BIOS and driver updates.
If you insist on testing on a virtual machine, do the following to receive the PPKG inside an ISO, then mount it to the VM, and press the Windows Key 5 times when you are at the Region Selection screen. If you are past the region selection screen, simply double click the PPKG from the mounted disk
image
image
Once the computer is identified, you will be directed to that computer to begin the Onboarding process:
image
ImmyBot needs:
  1. Customer
  2. Primary User (That will be using the computer, optional but recommended)
image
You only have one customer and one person right now, and it’s your MSP and you. That’s fine, we’ll pretend we’re setting up a computer for you and your MSP.
TIP
Customers can be imported from your RMM or PSA, or by setting up the Azure integration
TIP
People are imported from your customers' Azure AD via the Azure integration
An "Onboarding" session will be created for this computer, and ImmyBot will apply the "Recommended Deployments"
TIP
You can add your own Deployments and re-run this session as many times as you like until everything is to your liking.

-    
+    
immy.bot
Appearance
Setup your first Computer ​
When you first login to ImmyBot the Getting Started Wizard will be prompt you to create your ImmyBot flash drive, and plug it into the new computer.
THIS IS A ONE TIME PROCESS, YOU DO NOT NEED TO CREATE A FLASH DRIVE FOR EACH CLIENT. YOU WILL CHANGE THE CLIENT AFTER THE MACHINE IS IN IMMYBOT
image
We recommend unboxing a physical computer (Dell, HP, or Lenovo) so we can demonstrate applying the latest manufacturer BIOS and driver updates.
If you insist on testing on a virtual machine, do the following to receive the PPKG inside an ISO, then mount it to the VM, and press the Windows Key 5 times when you are at the Region Selection screen. If you are past the region selection screen, simply double click the PPKG from the mounted disk
image
image
Once the computer is identified, you will be directed to that computer to begin the Onboarding process:
image
ImmyBot needs:
  1. Customer
  2. Primary User (That will be using the computer, optional but recommended)
image
You only have one customer and one person right now, and it’s your MSP and you. That’s fine, we’ll pretend we’re setting up a computer for you and your MSP.
TIP
Customers can be imported from your RMM or PSA, or by setting up the Azure integration
TIP
People are imported from your customers' Azure AD via the Azure integration
An "Onboarding" session will be created for this computer, and ImmyBot will apply the "Recommended Deployments"
TIP
You can add your own Deployments and re-run this session as many times as you like until everything is to your liking.

+    
     
   
 
\ No newline at end of file
diff --git a/recommended-deployments.html b/recommended-deployments.html
index 79b866f1..e676af4f 100644
--- a/recommended-deployments.html
+++ b/recommended-deployments.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
Recommended Deployments ​
Create Profile for Primary User ​
This allows Immy to set default browser and pdf editors.
Remember how Microsoft made default PDF handler and default browser user level settings? These settings are stored in the profile of the user. Specifically in the user’s registry. But this is a new computer, and there is no user registry because the user hasn’t logged into the computer, and therefore a profile doesn’t exist for us to specify those settings. Rather than requiring you to ask the user for their password, we fetch their SID from AzureAD. If we find that the user is synced from Active Directory, we will use the SID from Active Directory. If the user is cloud only, we use their Azure AD SID. For the more discerning you may be wondering how we deal with the UserChoice hash, the anti-tamper mechanism preventing the automatic setting of these preferences.
Microsoft 365 Apps ​
Immy installs the apps the selected user is licensed for. Immy contains recommended deployments for
  • Apps for business
  • Apps for enterprise
  • Project
  • Visio
You may be tempted to disable these because you are afraid Immy will install all of these apps on every computer. These deployments are limited using a “Metascript” filter that reaches out to the Microsoft Graph API to determine whether the selected user has a license for the product in question.
Dell/Lenovo/HP Updates ​
ImmyBot will install the latest updates from Dell, HP, and Lenovo, including driver updates and BIOS updates.
You may be tempted to disable these Deployments as you don’t want HP updates applying to your Dell. This won’t happen. Each deployment uses a Filter script to ensure that these updates only apply to the appropriate machines
Adobe Reader ​
You may be tempted to disable this deployment because not all of your customers use Adobe Reader. You should instead leave it enabled and handle exceptions to the rule. See more under “Deployment Resolution”
Set Computer Name and Domain Join ​
This is one that I’d advise you to turn off, and instead customize for each customer. We leave it as a recommended deployment mostly to raise awareness that ImmyBot has the capability, but fully expect you to override it to suit your needs.

-    
+    
immy.bot
Appearance
Recommended Deployments ​
Create Profile for Primary User ​
This allows Immy to set default browser and pdf editors.
Remember how Microsoft made default PDF handler and default browser user level settings? These settings are stored in the profile of the user. Specifically in the user’s registry. But this is a new computer, and there is no user registry because the user hasn’t logged into the computer, and therefore a profile doesn’t exist for us to specify those settings. Rather than requiring you to ask the user for their password, we fetch their SID from AzureAD. If we find that the user is synced from Active Directory, we will use the SID from Active Directory. If the user is cloud only, we use their Azure AD SID. For the more discerning you may be wondering how we deal with the UserChoice hash, the anti-tamper mechanism preventing the automatic setting of these preferences.
Microsoft 365 Apps ​
Immy installs the apps the selected user is licensed for. Immy contains recommended deployments for
  • Apps for business
  • Apps for enterprise
  • Project
  • Visio
You may be tempted to disable these because you are afraid Immy will install all of these apps on every computer. These deployments are limited using a “Metascript” filter that reaches out to the Microsoft Graph API to determine whether the selected user has a license for the product in question.
Dell/Lenovo/HP Updates ​
ImmyBot will install the latest updates from Dell, HP, and Lenovo, including driver updates and BIOS updates.
You may be tempted to disable these Deployments as you don’t want HP updates applying to your Dell. This won’t happen. Each deployment uses a Filter script to ensure that these updates only apply to the appropriate machines
Adobe Reader ​
You may be tempted to disable this deployment because not all of your customers use Adobe Reader. You should instead leave it enabled and handle exceptions to the rule. See more under “Deployment Resolution”
Set Computer Name and Domain Join ​
This is one that I’d advise you to turn off, and instead customize for each customer. We leave it as a recommended deployment mostly to raise awareness that ImmyBot has the capability, but fully expect you to override it to suit your needs.

+    
     
   
 
\ No newline at end of file
diff --git a/releases.html b/releases.html
index b2df58d4..d5cdd84a 100644
--- a/releases.html
+++ b/releases.html
@@ -38,7 +38,7 @@
     
   
   
-    
immy.bot
Appearance
Releases ​
0.60.0 ​
Released 01-09-24
Automatic ImmyBot Version Upgrades ​
When a new version of ImmyBot is released, you can now specify if you want to automatically update to that release after a specified amount of time. This behavior is configurable in preferences.
image
Release Channel ​
The release channel determines what versions of ImmyBot are available to you. You can now choose which release channel you want to subscribe to.
The available channels are: Alpha, Beta, and General.
  • Alpha: This channel contains releases that have passed development but may still be unstable. Only use this channel if it's absolutely necessary for a critical fix or to test brand new features and provide feedback.
  • Beta: This channel is for early adopters and contains releases that are in the final rounds of testing. Use this channel to test new features and provide feedback.
  • General: This channel contains releases that have been tested and are ready for general use. This is the recommended channel for stability.
All instances will default to the General channel.
You can change your channel on the System Update Page.
image
ImmyBot is on .NET 8 ​
The ImmyBot backend is now running .NET 8. While this doesn't introduce new features to end users, it does provide better performance and newer development features that benefit ImmyBot.
Cross-Tenant Deployment Change Requests ​
A new application preference has been introduced that when enabled will require MSP non-admin users to submit change requests when creating or updating cross-tenant deployments.
image
On a per user basis, you can additionally opt-out of requiring change requests by assigning the user the following capability from the edit user page:
image
Change requests are submitted from the deployment details page in the same area you would normally create and update a deployment.
image
Once submitted, the change request can be reviewed in a read-only format. MSP non-admins will have the option to edit the change request, while MSP admins will have the ability to approve or deny the change request.
MSP non-admins see ​
image
MSP admins see ​
image
All open change requests can be seen from the deployment list page.
image
Improvements ​
  • Added hidden column to the detected computer software table that shows the potentially matched global software id
  • The tenant software search tab on the tenant details page now renders as a filterable table with the ability to export
  • Automatic ImmyAgent updates are now enabled by default
  • When creating a new deployment, selecting Onboarding Only will now default to "Value from: deployment".
  • Changed notifications list page to hide resolved notifications by default
  • Deployments page will now default to grouping by tenant
  • IntelliSense can be restarted without refreshing the browser
Bug Fixes ​
  • Fixed issue with some property text in the audit table colliding with other property text
  • Fixed issue where unmatched software in the detected computer software table were not filterable
  • Fixed an issue where detection could fail with "Exception of type 'CwAutomateProvider.CwAutomateHttpException' was thrown." when checking for windows patching. It will now skip windows patching, provide a more useful message, and continue the session.
  • Fixed an issue where creating/updating deployments for integration group targets was not saving the selected tenant
  • Fixed an issue where starting ephemeral agent would cause an error on some older machines.
  • Fixed an issue where the getting started wizard was popping up even when a computer had already been added
  • Fixed an issue where the software repair custom script was not showing up under the Repair Strategy label on the software details page
  • Persistent Agent main connection will now more aggressively obey System Web proxy when attempting to connect.
  • Fixed an issue where Immy Agent EXE downloads would produce a corrupted binary.
  • Fixed an issue where upgrade code and product code were failing to match to global software during detection
  • Fixed issue where Azure Tenant Problem notifications were being created when there were not actually any problems
0.59.3 ​
Released 12-20-23
Bug Fixes ​
  • Fixed a caching issue where adhoc deploying to multiple computers and then re-running a session would sometimes trigger the session for a different computer
  • Fixed an issue where msp admins would sometimes show up as MSP Tenants
  • Fixed an issue with the detected computer software table where it was not updating information after re-running inventory
  • Fixed an issue where configuration task actions would sometimes not showing the detect stage progress line
0.59.2 ​
Released 12-19-23
Bug Fixes ​
  • Fixed issue with showing media on the media list page
  • Fixed issue on the tenant details page where the batch actions button on the computer table was not working
  • Fixed issue with calls to Get-ImmyComputer from metascripts where it was incorrectly excluding computers that were excluded from maintenance. This check is only supposed to happen when resolving computers for a deployment or a schedule.
0.59.1 ​
Released 12-13-23
Bug Fixes ​
  • Fixed issue where Computers and Tenants were still being included in the preview for the Edit Deployment screen even though the tenant had the "Exclude from Cross Tenant Schedules and Deployments" preference set
  • Fixed a caching issue where scheduled maintenance sessions were not always picking the correct deployment
0.59.0 ​
Released 12-12-23
Detected Computer Software Export ​
We added a page to view all computer detected software and a button to export it to a csv file.
You can access this page from /reporting/detected-computer-software. Values from this table are populated from inventory.
OAuth Parameters ​
Added the ability to create and select auto-refreshing OAuth tokens as script parameters
Added a button to the Azure Partner Settings page to pre-consent customers to the default or custom app registration via the Partner Center API
This removes the need to provide consent for each customer manually using an admin account from the customer
Added an OAuth Token Acquisition mechanism to allow Partner admins to give ImmyBot consent to use the Partner Center API
Automatic ImmyBot Agent Updates (Alpha) ​
When a computer attempts to run a script and we establish an ephemeral agent connection, we now also upgrade the ImmyBot Agent if it is outdated. This is currently in alpha and can be opted into from the Application Preferences page.
Improvements ​
  • You can use the new ScriptTimeout attribute to override the default execution time of 60 seconds in integration scripts (Supports up to 300 seconds)
  • Integrations supporting ISupportsHttpRequest now display the HttpRequest Uri
  • Added integration release stage badges to indicate whether an integration is in the Alpha, Beta, or Production stage.
  • Uninstalling software no longer enforces required parameters specified by the deployment.
  • [Alpha Opt-In] Write-Progress -Activity "Activity 1" -Status "Migrating" Calling Write-Progress with both Activity and Status parameters creates a new row on the action in the session. This helps visualize the progress of long running tasks.
  • Added BitLocker Status to the logical disk tab on the computer details page
  • Added TPM Version to the overview on the computer details page
  • Added disabled deploy button next to configuration tasks with a tooltip explaining that they cannot be deployed directly. The missing deploy button was causing confusion.
  • Added a docs link for agent identification failures under the computer page -> pending tab.
  • Updated help text of desired software state - Latest Version, to read "Will install/update the software to the latest version"
  • Added a link to the ordering page from the deployment list page
  • Updated the execution order help text to read "All tasks that are limited to onboarding computers will be executed at the beginning of the session in the onboarding stage, following the sequence in which they are listed. Once the onboarding process is complete, we will proceed to execute all other actions, also in the order they are listed."
  • Added 'Azure Tenant Problems Detected' notifications to indicate errors and other detected problems related to Azure tenants
  • Made notification creation more performant
  • Added User preference area and moved the theme toggle to it.
  • Improved some UI color settings
  • Creating, updating, and deleting schedules show up in the audit table.
  • Maintenance tasks can now specify an integration to link
  • Fixed an issue on startup that was causing some startup jobs to not run
  • The logic that ensures we have online agents before running a script on a computer no longer runs if we have an active ephemeral agent connection
  • Added AssignmentScope as a script parameter. Possible values are CrossTenant, SingleTenant, and Individual.
  • When ImmyBot restarts, we no longer cancel sessions due to them being considered "outdated". This was an old piece of code that was there to prevent accidental reboots during business hours. This check is no longer needed since we check for active hours and business hours during the maintenance session when deciding if the computer needs to reboot.
  • Important - ImmyBot agents that are installed with automatic onboarding will now ALWAYS automatically onboard. Before, we would optionally not perform onboarding if the agent resolved to an existing computer that had previously run at least one maintenance session.
  • Removed converted parameter values from parameter validation responses since it could possibility contain sensitive data and the value was not being used on the frontend
  • Invoke-CommandCached and Invoke-AtomicCommand cmdlets are now available for use inside Filter Scripts.
  • Action errors regarding missing/failed software prerequisites now show the software's name instead of the type and identifier.
  • Changes to software prerequisites now show up in the audit table
  • Added a link to the ImmyBot community forum to the navbar
  • Minimizing the script editor persists any ephemeral tabs you had open.
  • Extended the ephemeral agent disconnected text to say "This computer does not have an ephemeral agent. An ephemeral agent will connect when a script is run against this computer."
  • Several new Azure-related notifications have been added
  • Fixed an issue where multiple sidebars could be showing and overlapping at the same time
  • Parameter descriptions are now always visible. Before, they were only visible if you were overriding the default value.
  • Improved styling of default value key/value pair parameters on the deployment form
  • Improved serial execution of maintenance tasks by adding a more visible locking mechanism. You can now see who the currently executing computer / session is.
  • Added a check when creating or updating a deployment that warns you when a duplicate deployment is detected. You have the option to replace the existing deployment or fix the newer one such that it is no longer a duplicate.
  • Schedules and Adhoc Deployments now apply batching to create the maintenance sessions. We've seen about a 6x improvement in speed in creation.
  • Debounced script editor changes to prevent Intellisense crashes
  • You can now save scripts that have syntax errors by acknowledging the confirmation modal. Useful for saving unfinished scripts or scripts that may not actually have syntax errors when run on an endpoint
  • Improved ImmyAgent setup when deploying new instances that should result in fewer errors and faster instance setup
  • Improved performance of session cancellation by simplifying the database queries
  • Adding an invisible Formatter, so that information can be easily hidden. Using this to hide ParameterSetBinding messages.
  • In the Debugger section Parameters and Variables, the subsections are now open by default
  • In the Script Details section for the Type dropdown, the Software Auto Update element has been removed
  • Added integration capability ISupportsAgentDownload. Allowing integrations to provide their own "Download Installer" script.
  • Added integration capability ISupportsAuthenticatedDownload. Allowing integrations to provide authentication information without leaking sensitive information.
  • N-Central integration has finally graduated from Beta status, and can now be found in the Integrations page 🎉
Bug Fixes ​
  • Fixed an issue where some ImmyBot tenants linked to Azure customers were getting reset to Partner type within ImmyBot 
    • For Customer tenants that are erroneously set to Partner in ImmyBot, you can fix these by finding the customer on the Azure Settings page, and unlinking/relinking it
  • Fixed an issue where full maintenance schedule sessions did not have the "Full Maintenance" tag in the sessions table Fixed an issue with N-Central integration failing to re-authenticate after ~24hrs of running.
  • Fixed an issue where starting ImmyBot remote control for an outdated agent was kicking off a session that contained actions other than the agent update.
  • Fixed an issue with license descriptions now showing on the deployment page
  • Fixed potential null reference exception on Deployment page when ValidateScript is used
  • Fixed an issue where wiped computers were not being treated as wiped if an existing computer was found. A wiped computer is one where the hostname and OS install date are different that the computer we already see inside of ImmyBot.
  • Fixed a divide by zero error that could occur while computing a software installer's download speed.
  • Set the audit user text to show the user's email address if the user does not have a first or last name specified
  • Fixed an issue where some ImmyAgent & Ephemeral Agent binaries included some unsigned assemblies, falsely triggering some security tooling like ThreatLocker.
  • Fixed an issue where Immy Starter plans were able to select the schedules nav item
  • Fixed an issue where resolving agent identification issues resulted in "404 - entity could not be found."
  • Fixed an issue where resolving agent identification issues with "Let Immy Try again" was not doing anything.
  • Fixed an issue where some ImmyBot agents were failing to connect to ImmyBot when it was re-installed
  • Fixed an issue where only the ImmyBot team could view global dynamic integration types
  • Fixed an issue with scheduling the user computer affinity job once a day
  • Removed some old migration code that was delaying startup and potentially causing issues
  • Fixed an issue where some Immy Agent upgrades would leave installs dead in the water due to a config parsing issue.
  • Fixed an issue where sometimes analyzing an installer package would cause an IOException.
  • Fixed an issue where a software prerequisite would not be installed if an "update if found" deployment for the prerequisite resulted in "no action" because it was not found on the endpoint. Now, an install action for the prerequisite will be created anyway.
  • Fixed an issue where selecting text on expanded script-runs would collapse the script
  • Fixed an issue with fetching CW Manage agreement products where the deployment would show "Server error. Please contact your Administrator." Occurred when CW Manage attempted to return several hundred agreement products.
  • Fixed an issue running invoke-immycommand from a cloud script against a computer that would throw an error during the preflight check, "Value cannot be null. (Parameter 'psComputers')".
  • Fixed issue removing previous pages breadcrumbs on the session list page
  • Fixed an issue on the onboarding form where mandatory parameters would not show the input by default if the parameter was dynamically discovered
  • Fixed several minor issues found with the agent installer download modal and the getting started wizard modal
  • Fixed a caching issue with inserting session logs into the database
  • Fixed a caching issue with detected software from a machine
  • Fixed an issue where database queries to get a list of sorted deployments during a maintenance session were not being cached
  • Fixed an issue where the Package Analyzer would throw a The process cannot access the file error
  • Fixed issue with our script analyzer rule for detecting missing $using: in Invoke-ImmyCommand
  • Fixed the N-Central issue that keeps appearing "InvalidLoginCredentialsException: New tab request failed!"
  • ParameterSetBinding should not emit output.
0.58.3 ​
Released 11-1-23
Notifications ​
Notification Sidebar ​
We have updated how our notification system works.
The bell icon in the navbar will provide a number of the unacknowledged notifications you have.
image
The sidebar will show when clicking this icon.
image
Notification History ​
You can access all notifications from the primary sidebar under "Show More" -> "Notifications". By default, it will only show you unacknowledged notifications. You can click the "reset" link or change the filter on the "Acknowledgement" column to view acknowledged notifications.
image
Silencing notifications ​
From the notification sidebar, you can silence notifications by the notification type or for the specific object the notification was for.
image
You can then view all of your silenced notifications from the notification history page.
image
Notification Types ​
We have plenty of notification types in the pipeline. Here are the notification types currently implemented.
  1. Integration Unhealthy - a notification to let MSP users know that an integration has become unhealthy
  2. Access Requested - a notification to let MSP users know that someone is requesting access to their instance of ImmyBot
  3. Large Script Output - a notification to let MSP users know that a specific script has outputted a large amount of data. When scripts like this run during maintenance for hundreds of devices, it can easily cause high CPU and memory which leads to sluggish performance and potential crashes.
  4. Unacknowledged Recommended Deployments - a notification to let MSP users know that there are new recommended deployments that need to be allowed or denied.
Some notification types that will be coming soon include, but are not limited to:
  1. Agents Requires Manual Decision - a notification that lets MSP users know there are agents pending identification that could not be automatically resolved to a computer and require manual actions.
  2. ImmyBot Updated - a notification that lets MSP users know that ImmyBot has been updated to a newer version
  3. Cross-Tenant Deployment Requires Approval - a notification that lets MSP admin users know that a cross-tenant deployment was created or modified and needs approval from an MSP Admin. (Feature coming soon)
  4. Azure related notifications
Improvements ​
  • Updated variable alert on the license details page to be the same alert shown on the software details page -> license help alert
  • Added random jitter to the time we schedule some of our recurring jobs so that we reduce high database load due to all instances kicking off the jobs at the same time.
  • For maintenance sessions that target a specific item, a session log has been added at the beginning that provides the name of the maintenance item
  • Added auditing for static software versions and static maintenance task parameters
  • Schedules that target a specific maintenance item will now always create a maintenance session for every computer resolved in the schedule's target group. If the computer does not have a deployment for the specified maintenance item, then the session will complete instantly with no actions added.
  • Upgraded PowerShell Editor Services from 3.6 to 3.13
  • Batch actions sidebar now slides out underneath the navbar to not block actions
  • Batch actions sidebar background color was updated to provide more contrast
  • You can now restart Intellisense from the status bar. 
    • image
  • Intellisense will restart automatically when changing script type.
  • Removed dependency on Ace.js that shaved off 366KB from the project
  • Made a slight performance change to schedule logic that should result in faster start times for schedules with many computers
  • Added a "Job Args" property to the session details page info panel that expands to show more data associated with the session.
  • ImmyBot no longer tries to run scripts against non-Pro N-Central agents
  • Added custom PSScriptAnalyzerRule with Code Action to detect and fix missing $using: scope modifier in Invoke-ImmyCommand 
    • image
Bug Fixes ​
  • Fixed an issue with azure tenant data sync job not getting scheduled correctly
  • Fixed an issue with cloud deployments targeting tags where the session would error in a NotImplementedException
  • Fixed an issue where agent updates only maintenance sessions were not viewable by a non-msp admin even if the computer was under their tenant
  • Improve deadlock handling when integrations need to be created, removed, or re-initialized
  • Fixed an issue where users were unable to upload license files
  • Fixed an issue on instance startup where integrations were possibly initializing twice unnecessarily
  • Added a default timeout of 5 minutes to every API request made to Automate. We were not specifying a timeout before so the request could have been long-lived
  • Improved the initialization of the CW Automate integration by reducing the number of times we instantiate an API client to communicate with the Automate Server
  • Refactored the logic that handles enqueuing scripts to execute over CW Automate to prevent potential locking and add additional debug logging
  • Fixed an issue where the system status page was not showing metrics under CW Automate and CW Control when it should have
  • Fixed issue where Intellisense would be unrecoverable after selecting script type Software Auto Update
  • Fixed an issue where provider sync jobs could continually enqueue when only one should ever be enqueued at a time.
  • Fixed an issue where CWControl provider would fail to initialize due to Azure changing the machine hostname, causing it to exceed maximum expected length 
    • image
  • Fixed an issue where some actions would result in an error of "Invalid maintenance action type."
  • Fixed a potential issue with all providers remaining unhealthy upon server starting up
  • Improved the load time of the application on startup
  • Fixed an issue where some more known bad device ids were being used to uniquely identify a computer, e.g. ffffffff-ffff-ffff-ffff-ffffffffffff
  • Fixed an issue where ImmyAgent provider would fail to initialize due to Azure changing the machine hostname, causing it to exceed maximum expected length. 
    • image
0.58.2 ​
Released 10-11-23
Audit Page ​
An audit page was added that MSP admins can use to view changes made to objects such as Target Assignments and Scripts. This also includes changes made to global objects. This is part one of an effort to provide more transparency around changes made to global data. This page is accessible under Show More -> Audit, or "your-instance.immy.bot/settings/audit".
Improvements ​
  • Get-ImmyComputer -IncludeTags from a filter script or a meta script now include the tags for the computer's tenant and primary user
  • Improved our resiliency for Redis reconnection for background jobs
  • Updated the Hangfire Service watcher to fix common issues that may occur when it restarts
  • Improved some internal logging that will help diagnose application crashes
  • Added some additional logging to detect performance issues related to CW Control connection events
  • Added support for putting an agent in maintenance mode at the beginning of a session
  • Sessions with reboot preference set to force now only force a reboot at the beginning and end of the session. Reboot checks after each action will only reboot if necessary.
  • Added the ability to toggle online status support for agents of an integration since some dynamic integrations don't support online status
  • The "Install Agent" button on the computer details page now kicks off a maintenance session instead of installing behind the scenes
  • Updated the version of our dependency on the Azure.Storage.Blobs package, which provides better performance.
Bug Fixes ​
  • Fixed some theme styling issues on some of the tables
  • Fixed an error in the web inspector console that was reporting BackendVersion was null
  • Fixed an issue where array parameters that used [ValidateSet] would not render the dropdown of valid values
  • Fixed an incorrect variable name in the license alert on the software details form. $LicenseFile should have been $LicenseFilePath
  • Fixed an issue where the session resume button would stay disabled if you clicked it but didn't confirm the action.
  • Fixed an issue where deployment parameters were not showing in the correct positions Fixed an issue with the Package Analyzer failing to download some software hosted behind CloudFront CDN.
  • Fixed an issue where Invoke-CommandCached would return objects slightly differently than expected, causing some unexpected behavior for scripts.
  • Fixed an issue where the "Show value view" on a parameter form would not actually show the parameter values
  • Fixed an issue with agent inventory identification where old agents tied to a computer were not getting replaced by the a newer agent
  • Fixed an issue where a phase could be considered successful if the agent went offline at just the right time
  • Fixed an issue where an agent going offline would fail a maintenance task action during the Download Installer phase
  • Fixed an issue where refreshing the computer's connected status would throw an error regarding some agents not supporting the ability to refresh an agent's online status
  • Fixed a potential null reference exception that was thrown when reloading integration types
  • Fixed an issue where dynamic integration agents were not syncing updated data, such as changed name, serial number, or osname
  • Fixed an issue with pending connectivity kicking off incorrectly for disabled/unhealthy links
  • Fixed an issue where the ImmyAgent provider would fail to initialize due to Azure changing the machine hostname, causing it to exceed maximum expected length.
0.58.1 ​
Released 09-28-23
Improvements ​
  • Made errors that occur while interacting with the graph api show on the frontend to help guide the user on how to resolve common Azure configuration problems
  • Added the ability to specify a docs url for dynamic integrations that will be shown on the integration edit details page
  • Added the installer download url to the session log when attempting a BITS or basic download
  • ImmyBot now defaults to dark mode unless the browser preference is set to light
  • Moved immy support access preference to the top of the preferences page
  • Made Add-UriQueryParameter no longer require -Parameter when Uri is passed in via Pipeline
  • Added the ability to trigger an agent sync from an integration on the clients tab and agents tab
  • Added support for incoming http request inspection to integration audit logging
  • Added support for non-mandatory integration method parameters
  • Dynamic Integrations that support agents can now specify whether the agent supports an online/offline status. Some integrations were defaulting to always online which caused issues with the pending connectivity logic
  • Updated session log text about retrying to fetch PowerShell version
  • Added a better error message when a dynamic version script returns a newer version than what was detected previously in the session. The message is "The dynamic version script is returning a newer version than what was retrieved the last time the script was ran. If so, re-deploy this action. We will automatically handle this scenario in a future release."
Bug Fixes ​
  • Fixed an issue with onboarding and deployment parameters where the form would sometimes not render due to hidden errors. The errors are now visible in this case.
  • Fixed an issue on the onboarding form where values specified on the deployment form were not considered when resolving any errors
  • Fixed a bug where only the first 300 Azure customers of a partner tenant would show up in the Azure customer mapper
  • Fixed an issue where global software -> agent integration dropdown was showing local integrations
  • Fixed a bug where linking an az customer would incorrectly set the az tenant type as Standalone, preventing usage of the graph api for that customer
  • Fixed an issue where sessions would sometimes not show the computer name, and links to the computer would result in a 404
  • Fixed an issue where a license couldn't be deleted because it was used by a deployment that was no longer showing the license selector. The selector now shows and the license can be successfully removed from the deployment
  • Fixed a rare issue where agents would fail to be synced if the integration reported multiple agents with the same agent id
  • Fixed an issue where Immybot.Agent.Shared.dll from the ImmyBot agent MSI installer was not signed
  • Fixed an issue where linking a dynamic integration client was removing other agents incorrectly during the sync
  • Fixed a bug where tenant select boxes couldn't be searched on provider client link pages
  • Fixed an issue where custom app reg could not be changed without first toggling permission level
  • Fixed an issue where reloading integration types would result in a permission error
  • Fixed an issue where the unlinked msp client banner would show up even when the msp client was linked
  • Fixed an issue that was preventing the ImmyBot agent's .dlls to be signed
  • Removed extra "$" in front of version in the dynamic version response
  • Removed the agent's client name from the agent tab to prevent confusion
  • Fixed an issue where a pending agent "Let Immy Try Agent" action was not working as expected
  • Fixed an issue where a script dropdown would show incorrect results if it was toggled to only show global scripts or toggled to only show local scripts
  • Fixed a "downlaod" typo in "Action To Take"
0.58.0 ​
Released 09-13-23
Bring Your Own Integrations ​
The goal of this feature is primarily for our own use to more rapidly implement integrations with other RMMs and PSA, but we have opened it up for you to create your own integrations as well.
https://docs.immy.bot/build-your-own-integration.html
New Parameter New-OAuthConsentParameter ​
This parameter creates a button that will perform the oauth code authorization flow and allow you to use the response in the script.
https://docs.immy.bot/scripts.html#parameters
Agent Tracking ​
The Computer -> Agents tab now includes all agents, not just ones used to run scripts. This is preparation for the upcoming computer/tenant offboarding feature. Which will allow us to not only uninstall the agents from the machine but de-provision them from their respective platforms.
Metascript WebHooks ​
You can now receive web requests from within Metascripts.
The webhook URL is {your-domain}.immy.bot/api/v1/webhooks/{web-hook-id}, and it accepts Post and Get requests. The webhook id can be retrieved from $Hook.Id
An example scenario is this can be used to map Toast buttons to actions in ImmyBot.
powershell
$Hook = New-ImmyWebHook
+    
immy.bot
Appearance
Releases ​
0.60.0 ​
Released 01-09-24
Automatic ImmyBot Version Upgrades ​
When a new version of ImmyBot is released, you can now specify if you want to automatically update to that release after a specified amount of time. This behavior is configurable in preferences.
image
Release Channel ​
The release channel determines what versions of ImmyBot are available to you. You can now choose which release channel you want to subscribe to.
The available channels are: Alpha, Beta, and General.
  • Alpha: This channel contains releases that have passed development but may still be unstable. Only use this channel if it's absolutely necessary for a critical fix or to test brand new features and provide feedback.
  • Beta: This channel is for early adopters and contains releases that are in the final rounds of testing. Use this channel to test new features and provide feedback.
  • General: This channel contains releases that have been tested and are ready for general use. This is the recommended channel for stability.
All instances will default to the General channel.
You can change your channel on the System Update Page.
image
ImmyBot is on .NET 8 ​
The ImmyBot backend is now running .NET 8. While this doesn't introduce new features to end users, it does provide better performance and newer development features that benefit ImmyBot.
Cross-Tenant Deployment Change Requests ​
A new application preference has been introduced that when enabled will require MSP non-admin users to submit change requests when creating or updating cross-tenant deployments.
image
On a per user basis, you can additionally opt-out of requiring change requests by assigning the user the following capability from the edit user page:
image
Change requests are submitted from the deployment details page in the same area you would normally create and update a deployment.
image
Once submitted, the change request can be reviewed in a read-only format. MSP non-admins will have the option to edit the change request, while MSP admins will have the ability to approve or deny the change request.
MSP non-admins see ​
image
MSP admins see ​
image
All open change requests can be seen from the deployment list page.
image
Improvements ​
  • Added hidden column to the detected computer software table that shows the potentially matched global software id
  • The tenant software search tab on the tenant details page now renders as a filterable table with the ability to export
  • Automatic ImmyAgent updates are now enabled by default
  • When creating a new deployment, selecting Onboarding Only will now default to "Value from: deployment".
  • Changed notifications list page to hide resolved notifications by default
  • Deployments page will now default to grouping by tenant
  • IntelliSense can be restarted without refreshing the browser
Bug Fixes ​
  • Fixed issue with some property text in the audit table colliding with other property text
  • Fixed issue where unmatched software in the detected computer software table were not filterable
  • Fixed an issue where detection could fail with "Exception of type 'CwAutomateProvider.CwAutomateHttpException' was thrown." when checking for windows patching. It will now skip windows patching, provide a more useful message, and continue the session.
  • Fixed an issue where creating/updating deployments for integration group targets was not saving the selected tenant
  • Fixed an issue where starting ephemeral agent would cause an error on some older machines.
  • Fixed an issue where the getting started wizard was popping up even when a computer had already been added
  • Fixed an issue where the software repair custom script was not showing up under the Repair Strategy label on the software details page
  • Persistent Agent main connection will now more aggressively obey System Web proxy when attempting to connect.
  • Fixed an issue where Immy Agent EXE downloads would produce a corrupted binary.
  • Fixed an issue where upgrade code and product code were failing to match to global software during detection
  • Fixed issue where Azure Tenant Problem notifications were being created when there were not actually any problems
0.59.3 ​
Released 12-20-23
Bug Fixes ​
  • Fixed a caching issue where adhoc deploying to multiple computers and then re-running a session would sometimes trigger the session for a different computer
  • Fixed an issue where msp admins would sometimes show up as MSP Tenants
  • Fixed an issue with the detected computer software table where it was not updating information after re-running inventory
  • Fixed an issue where configuration task actions would sometimes not showing the detect stage progress line
0.59.2 ​
Released 12-19-23
Bug Fixes ​
  • Fixed issue with showing media on the media list page
  • Fixed issue on the tenant details page where the batch actions button on the computer table was not working
  • Fixed issue with calls to Get-ImmyComputer from metascripts where it was incorrectly excluding computers that were excluded from maintenance. This check is only supposed to happen when resolving computers for a deployment or a schedule.
0.59.1 ​
Released 12-13-23
Bug Fixes ​
  • Fixed issue where Computers and Tenants were still being included in the preview for the Edit Deployment screen even though the tenant had the "Exclude from Cross Tenant Schedules and Deployments" preference set
  • Fixed a caching issue where scheduled maintenance sessions were not always picking the correct deployment
0.59.0 ​
Released 12-12-23
Detected Computer Software Export ​
We added a page to view all computer detected software and a button to export it to a csv file.
You can access this page from /reporting/detected-computer-software. Values from this table are populated from inventory.
OAuth Parameters ​
Added the ability to create and select auto-refreshing OAuth tokens as script parameters
Added a button to the Azure Partner Settings page to pre-consent customers to the default or custom app registration via the Partner Center API
This removes the need to provide consent for each customer manually using an admin account from the customer
Added an OAuth Token Acquisition mechanism to allow Partner admins to give ImmyBot consent to use the Partner Center API
Automatic ImmyBot Agent Updates (Alpha) ​
When a computer attempts to run a script and we establish an ephemeral agent connection, we now also upgrade the ImmyBot Agent if it is outdated. This is currently in alpha and can be opted into from the Application Preferences page.
Improvements ​
  • You can use the new ScriptTimeout attribute to override the default execution time of 60 seconds in integration scripts (Supports up to 300 seconds)
  • Integrations supporting ISupportsHttpRequest now display the HttpRequest Uri
  • Added integration release stage badges to indicate whether an integration is in the Alpha, Beta, or Production stage.
  • Uninstalling software no longer enforces required parameters specified by the deployment.
  • [Alpha Opt-In] Write-Progress -Activity "Activity 1" -Status "Migrating" Calling Write-Progress with both Activity and Status parameters creates a new row on the action in the session. This helps visualize the progress of long running tasks.
  • Added BitLocker Status to the logical disk tab on the computer details page
  • Added TPM Version to the overview on the computer details page
  • Added disabled deploy button next to configuration tasks with a tooltip explaining that they cannot be deployed directly. The missing deploy button was causing confusion.
  • Added a docs link for agent identification failures under the computer page -> pending tab.
  • Updated help text of desired software state - Latest Version, to read "Will install/update the software to the latest version"
  • Added a link to the ordering page from the deployment list page
  • Updated the execution order help text to read "All tasks that are limited to onboarding computers will be executed at the beginning of the session in the onboarding stage, following the sequence in which they are listed. Once the onboarding process is complete, we will proceed to execute all other actions, also in the order they are listed."
  • Added 'Azure Tenant Problems Detected' notifications to indicate errors and other detected problems related to Azure tenants
  • Made notification creation more performant
  • Added User preference area and moved the theme toggle to it.
  • Improved some UI color settings
  • Creating, updating, and deleting schedules show up in the audit table.
  • Maintenance tasks can now specify an integration to link
  • Fixed an issue on startup that was causing some startup jobs to not run
  • The logic that ensures we have online agents before running a script on a computer no longer runs if we have an active ephemeral agent connection
  • Added AssignmentScope as a script parameter. Possible values are CrossTenant, SingleTenant, and Individual.
  • When ImmyBot restarts, we no longer cancel sessions due to them being considered "outdated". This was an old piece of code that was there to prevent accidental reboots during business hours. This check is no longer needed since we check for active hours and business hours during the maintenance session when deciding if the computer needs to reboot.
  • Important - ImmyBot agents that are installed with automatic onboarding will now ALWAYS automatically onboard. Before, we would optionally not perform onboarding if the agent resolved to an existing computer that had previously run at least one maintenance session.
  • Removed converted parameter values from parameter validation responses since it could possibility contain sensitive data and the value was not being used on the frontend
  • Invoke-CommandCached and Invoke-AtomicCommand cmdlets are now available for use inside Filter Scripts.
  • Action errors regarding missing/failed software prerequisites now show the software's name instead of the type and identifier.
  • Changes to software prerequisites now show up in the audit table
  • Added a link to the ImmyBot community forum to the navbar
  • Minimizing the script editor persists any ephemeral tabs you had open.
  • Extended the ephemeral agent disconnected text to say "This computer does not have an ephemeral agent. An ephemeral agent will connect when a script is run against this computer."
  • Several new Azure-related notifications have been added
  • Fixed an issue where multiple sidebars could be showing and overlapping at the same time
  • Parameter descriptions are now always visible. Before, they were only visible if you were overriding the default value.
  • Improved styling of default value key/value pair parameters on the deployment form
  • Improved serial execution of maintenance tasks by adding a more visible locking mechanism. You can now see who the currently executing computer / session is.
  • Added a check when creating or updating a deployment that warns you when a duplicate deployment is detected. You have the option to replace the existing deployment or fix the newer one such that it is no longer a duplicate.
  • Schedules and Adhoc Deployments now apply batching to create the maintenance sessions. We've seen about a 6x improvement in speed in creation.
  • Debounced script editor changes to prevent Intellisense crashes
  • You can now save scripts that have syntax errors by acknowledging the confirmation modal. Useful for saving unfinished scripts or scripts that may not actually have syntax errors when run on an endpoint
  • Improved ImmyAgent setup when deploying new instances that should result in fewer errors and faster instance setup
  • Improved performance of session cancellation by simplifying the database queries
  • Adding an invisible Formatter, so that information can be easily hidden. Using this to hide ParameterSetBinding messages.
  • In the Debugger section Parameters and Variables, the subsections are now open by default
  • In the Script Details section for the Type dropdown, the Software Auto Update element has been removed
  • Added integration capability ISupportsAgentDownload. Allowing integrations to provide their own "Download Installer" script.
  • Added integration capability ISupportsAuthenticatedDownload. Allowing integrations to provide authentication information without leaking sensitive information.
  • N-Central integration has finally graduated from Beta status, and can now be found in the Integrations page 🎉
Bug Fixes ​
  • Fixed an issue where some ImmyBot tenants linked to Azure customers were getting reset to Partner type within ImmyBot 
    • For Customer tenants that are erroneously set to Partner in ImmyBot, you can fix these by finding the customer on the Azure Settings page, and unlinking/relinking it
  • Fixed an issue where full maintenance schedule sessions did not have the "Full Maintenance" tag in the sessions table Fixed an issue with N-Central integration failing to re-authenticate after ~24hrs of running.
  • Fixed an issue where starting ImmyBot remote control for an outdated agent was kicking off a session that contained actions other than the agent update.
  • Fixed an issue with license descriptions now showing on the deployment page
  • Fixed potential null reference exception on Deployment page when ValidateScript is used
  • Fixed an issue where wiped computers were not being treated as wiped if an existing computer was found. A wiped computer is one where the hostname and OS install date are different that the computer we already see inside of ImmyBot.
  • Fixed a divide by zero error that could occur while computing a software installer's download speed.
  • Set the audit user text to show the user's email address if the user does not have a first or last name specified
  • Fixed an issue where some ImmyAgent & Ephemeral Agent binaries included some unsigned assemblies, falsely triggering some security tooling like ThreatLocker.
  • Fixed an issue where Immy Starter plans were able to select the schedules nav item
  • Fixed an issue where resolving agent identification issues resulted in "404 - entity could not be found."
  • Fixed an issue where resolving agent identification issues with "Let Immy Try again" was not doing anything.
  • Fixed an issue where some ImmyBot agents were failing to connect to ImmyBot when it was re-installed
  • Fixed an issue where only the ImmyBot team could view global dynamic integration types
  • Fixed an issue with scheduling the user computer affinity job once a day
  • Removed some old migration code that was delaying startup and potentially causing issues
  • Fixed an issue where some Immy Agent upgrades would leave installs dead in the water due to a config parsing issue.
  • Fixed an issue where sometimes analyzing an installer package would cause an IOException.
  • Fixed an issue where a software prerequisite would not be installed if an "update if found" deployment for the prerequisite resulted in "no action" because it was not found on the endpoint. Now, an install action for the prerequisite will be created anyway.
  • Fixed an issue where selecting text on expanded script-runs would collapse the script
  • Fixed an issue with fetching CW Manage agreement products where the deployment would show "Server error. Please contact your Administrator." Occurred when CW Manage attempted to return several hundred agreement products.
  • Fixed an issue running invoke-immycommand from a cloud script against a computer that would throw an error during the preflight check, "Value cannot be null. (Parameter 'psComputers')".
  • Fixed issue removing previous pages breadcrumbs on the session list page
  • Fixed an issue on the onboarding form where mandatory parameters would not show the input by default if the parameter was dynamically discovered
  • Fixed several minor issues found with the agent installer download modal and the getting started wizard modal
  • Fixed a caching issue with inserting session logs into the database
  • Fixed a caching issue with detected software from a machine
  • Fixed an issue where database queries to get a list of sorted deployments during a maintenance session were not being cached
  • Fixed an issue where the Package Analyzer would throw a The process cannot access the file error
  • Fixed issue with our script analyzer rule for detecting missing $using: in Invoke-ImmyCommand
  • Fixed the N-Central issue that keeps appearing "InvalidLoginCredentialsException: New tab request failed!"
  • ParameterSetBinding should not emit output.
0.58.3 ​
Released 11-1-23
Notifications ​
Notification Sidebar ​
We have updated how our notification system works.
The bell icon in the navbar will provide a number of the unacknowledged notifications you have.
image
The sidebar will show when clicking this icon.
image
Notification History ​
You can access all notifications from the primary sidebar under "Show More" -> "Notifications". By default, it will only show you unacknowledged notifications. You can click the "reset" link or change the filter on the "Acknowledgement" column to view acknowledged notifications.
image
Silencing notifications ​
From the notification sidebar, you can silence notifications by the notification type or for the specific object the notification was for.
image
You can then view all of your silenced notifications from the notification history page.
image
Notification Types ​
We have plenty of notification types in the pipeline. Here are the notification types currently implemented.
  1. Integration Unhealthy - a notification to let MSP users know that an integration has become unhealthy
  2. Access Requested - a notification to let MSP users know that someone is requesting access to their instance of ImmyBot
  3. Large Script Output - a notification to let MSP users know that a specific script has outputted a large amount of data. When scripts like this run during maintenance for hundreds of devices, it can easily cause high CPU and memory which leads to sluggish performance and potential crashes.
  4. Unacknowledged Recommended Deployments - a notification to let MSP users know that there are new recommended deployments that need to be allowed or denied.
Some notification types that will be coming soon include, but are not limited to:
  1. Agents Requires Manual Decision - a notification that lets MSP users know there are agents pending identification that could not be automatically resolved to a computer and require manual actions.
  2. ImmyBot Updated - a notification that lets MSP users know that ImmyBot has been updated to a newer version
  3. Cross-Tenant Deployment Requires Approval - a notification that lets MSP admin users know that a cross-tenant deployment was created or modified and needs approval from an MSP Admin. (Feature coming soon)
  4. Azure related notifications
Improvements ​
  • Updated variable alert on the license details page to be the same alert shown on the software details page -> license help alert
  • Added random jitter to the time we schedule some of our recurring jobs so that we reduce high database load due to all instances kicking off the jobs at the same time.
  • For maintenance sessions that target a specific item, a session log has been added at the beginning that provides the name of the maintenance item
  • Added auditing for static software versions and static maintenance task parameters
  • Schedules that target a specific maintenance item will now always create a maintenance session for every computer resolved in the schedule's target group. If the computer does not have a deployment for the specified maintenance item, then the session will complete instantly with no actions added.
  • Upgraded PowerShell Editor Services from 3.6 to 3.13
  • Batch actions sidebar now slides out underneath the navbar to not block actions
  • Batch actions sidebar background color was updated to provide more contrast
  • You can now restart Intellisense from the status bar. 
    • image
  • Intellisense will restart automatically when changing script type.
  • Removed dependency on Ace.js that shaved off 366KB from the project
  • Made a slight performance change to schedule logic that should result in faster start times for schedules with many computers
  • Added a "Job Args" property to the session details page info panel that expands to show more data associated with the session.
  • ImmyBot no longer tries to run scripts against non-Pro N-Central agents
  • Added custom PSScriptAnalyzerRule with Code Action to detect and fix missing $using: scope modifier in Invoke-ImmyCommand 
    • image
Bug Fixes ​
  • Fixed an issue with azure tenant data sync job not getting scheduled correctly
  • Fixed an issue with cloud deployments targeting tags where the session would error in a NotImplementedException
  • Fixed an issue where agent updates only maintenance sessions were not viewable by a non-msp admin even if the computer was under their tenant
  • Improve deadlock handling when integrations need to be created, removed, or re-initialized
  • Fixed an issue where users were unable to upload license files
  • Fixed an issue on instance startup where integrations were possibly initializing twice unnecessarily
  • Added a default timeout of 5 minutes to every API request made to Automate. We were not specifying a timeout before so the request could have been long-lived
  • Improved the initialization of the CW Automate integration by reducing the number of times we instantiate an API client to communicate with the Automate Server
  • Refactored the logic that handles enqueuing scripts to execute over CW Automate to prevent potential locking and add additional debug logging
  • Fixed an issue where the system status page was not showing metrics under CW Automate and CW Control when it should have
  • Fixed issue where Intellisense would be unrecoverable after selecting script type Software Auto Update
  • Fixed an issue where provider sync jobs could continually enqueue when only one should ever be enqueued at a time.
  • Fixed an issue where CWControl provider would fail to initialize due to Azure changing the machine hostname, causing it to exceed maximum expected length 
    • image
  • Fixed an issue where some actions would result in an error of "Invalid maintenance action type."
  • Fixed a potential issue with all providers remaining unhealthy upon server starting up
  • Improved the load time of the application on startup
  • Fixed an issue where some more known bad device ids were being used to uniquely identify a computer, e.g. ffffffff-ffff-ffff-ffff-ffffffffffff
  • Fixed an issue where ImmyAgent provider would fail to initialize due to Azure changing the machine hostname, causing it to exceed maximum expected length. 
    • image
0.58.2 ​
Released 10-11-23
Audit Page ​
An audit page was added that MSP admins can use to view changes made to objects such as Target Assignments and Scripts. This also includes changes made to global objects. This is part one of an effort to provide more transparency around changes made to global data. This page is accessible under Show More -> Audit, or "your-instance.immy.bot/settings/audit".
Improvements ​
  • Get-ImmyComputer -IncludeTags from a filter script or a meta script now include the tags for the computer's tenant and primary user
  • Improved our resiliency for Redis reconnection for background jobs
  • Updated the Hangfire Service watcher to fix common issues that may occur when it restarts
  • Improved some internal logging that will help diagnose application crashes
  • Added some additional logging to detect performance issues related to CW Control connection events
  • Added support for putting an agent in maintenance mode at the beginning of a session
  • Sessions with reboot preference set to force now only force a reboot at the beginning and end of the session. Reboot checks after each action will only reboot if necessary.
  • Added the ability to toggle online status support for agents of an integration since some dynamic integrations don't support online status
  • The "Install Agent" button on the computer details page now kicks off a maintenance session instead of installing behind the scenes
  • Updated the version of our dependency on the Azure.Storage.Blobs package, which provides better performance.
Bug Fixes ​
  • Fixed some theme styling issues on some of the tables
  • Fixed an error in the web inspector console that was reporting BackendVersion was null
  • Fixed an issue where array parameters that used [ValidateSet] would not render the dropdown of valid values
  • Fixed an incorrect variable name in the license alert on the software details form. $LicenseFile should have been $LicenseFilePath
  • Fixed an issue where the session resume button would stay disabled if you clicked it but didn't confirm the action.
  • Fixed an issue where deployment parameters were not showing in the correct positions Fixed an issue with the Package Analyzer failing to download some software hosted behind CloudFront CDN.
  • Fixed an issue where Invoke-CommandCached would return objects slightly differently than expected, causing some unexpected behavior for scripts.
  • Fixed an issue where the "Show value view" on a parameter form would not actually show the parameter values
  • Fixed an issue with agent inventory identification where old agents tied to a computer were not getting replaced by the a newer agent
  • Fixed an issue where a phase could be considered successful if the agent went offline at just the right time
  • Fixed an issue where an agent going offline would fail a maintenance task action during the Download Installer phase
  • Fixed an issue where refreshing the computer's connected status would throw an error regarding some agents not supporting the ability to refresh an agent's online status
  • Fixed a potential null reference exception that was thrown when reloading integration types
  • Fixed an issue where dynamic integration agents were not syncing updated data, such as changed name, serial number, or osname
  • Fixed an issue with pending connectivity kicking off incorrectly for disabled/unhealthy links
  • Fixed an issue where the ImmyAgent provider would fail to initialize due to Azure changing the machine hostname, causing it to exceed maximum expected length.
0.58.1 ​
Released 09-28-23
Improvements ​
  • Made errors that occur while interacting with the graph api show on the frontend to help guide the user on how to resolve common Azure configuration problems
  • Added the ability to specify a docs url for dynamic integrations that will be shown on the integration edit details page
  • Added the installer download url to the session log when attempting a BITS or basic download
  • ImmyBot now defaults to dark mode unless the browser preference is set to light
  • Moved immy support access preference to the top of the preferences page
  • Made Add-UriQueryParameter no longer require -Parameter when Uri is passed in via Pipeline
  • Added the ability to trigger an agent sync from an integration on the clients tab and agents tab
  • Added support for incoming http request inspection to integration audit logging
  • Added support for non-mandatory integration method parameters
  • Dynamic Integrations that support agents can now specify whether the agent supports an online/offline status. Some integrations were defaulting to always online which caused issues with the pending connectivity logic
  • Updated session log text about retrying to fetch PowerShell version
  • Added a better error message when a dynamic version script returns a newer version than what was detected previously in the session. The message is "The dynamic version script is returning a newer version than what was retrieved the last time the script was ran. If so, re-deploy this action. We will automatically handle this scenario in a future release."
Bug Fixes ​
  • Fixed an issue with onboarding and deployment parameters where the form would sometimes not render due to hidden errors. The errors are now visible in this case.
  • Fixed an issue on the onboarding form where values specified on the deployment form were not considered when resolving any errors
  • Fixed a bug where only the first 300 Azure customers of a partner tenant would show up in the Azure customer mapper
  • Fixed an issue where global software -> agent integration dropdown was showing local integrations
  • Fixed a bug where linking an az customer would incorrectly set the az tenant type as Standalone, preventing usage of the graph api for that customer
  • Fixed an issue where sessions would sometimes not show the computer name, and links to the computer would result in a 404
  • Fixed an issue where a license couldn't be deleted because it was used by a deployment that was no longer showing the license selector. The selector now shows and the license can be successfully removed from the deployment
  • Fixed a rare issue where agents would fail to be synced if the integration reported multiple agents with the same agent id
  • Fixed an issue where Immybot.Agent.Shared.dll from the ImmyBot agent MSI installer was not signed
  • Fixed an issue where linking a dynamic integration client was removing other agents incorrectly during the sync
  • Fixed a bug where tenant select boxes couldn't be searched on provider client link pages
  • Fixed an issue where custom app reg could not be changed without first toggling permission level
  • Fixed an issue where reloading integration types would result in a permission error
  • Fixed an issue where the unlinked msp client banner would show up even when the msp client was linked
  • Fixed an issue that was preventing the ImmyBot agent's .dlls to be signed
  • Removed extra "$" in front of version in the dynamic version response
  • Removed the agent's client name from the agent tab to prevent confusion
  • Fixed an issue where a pending agent "Let Immy Try Agent" action was not working as expected
  • Fixed an issue where a script dropdown would show incorrect results if it was toggled to only show global scripts or toggled to only show local scripts
  • Fixed a "downlaod" typo in "Action To Take"
0.58.0 ​
Released 09-13-23
Bring Your Own Integrations ​
The goal of this feature is primarily for our own use to more rapidly implement integrations with other RMMs and PSA, but we have opened it up for you to create your own integrations as well.
https://docs.immy.bot/build-your-own-integration.html
New Parameter New-OAuthConsentParameter ​
This parameter creates a button that will perform the oauth code authorization flow and allow you to use the response in the script.
https://docs.immy.bot/scripts.html#parameters
Agent Tracking ​
The Computer -> Agents tab now includes all agents, not just ones used to run scripts. This is preparation for the upcoming computer/tenant offboarding feature. Which will allow us to not only uninstall the agents from the machine but de-provision them from their respective platforms.
Metascript WebHooks ​
You can now receive web requests from within Metascripts.
The webhook URL is {your-domain}.immy.bot/api/v1/webhooks/{web-hook-id}, and it accepts Post and Get requests. The webhook id can be retrieved from $Hook.Id
An example scenario is this can be used to map Toast buttons to actions in ImmyBot.
powershell
$Hook = New-ImmyWebHook
 $Hook.PublicUri | Add-UriQueryParameter @{
     MyParam = "MyVal"
 }
@@ -89,7 +89,7 @@
 Invoke-RestMethod 'https://<yourvault>.vault.azure.net/secrets/secretname?api-version=7.1' -Header $Headers | Select -Expand Value
image
Access arbitrary Azure authenticated resource URIs ​
powershell
$Headers = Get-ImmyAzureAuthHeader -ResourceUri 'https://vault.azure.net'
 Invoke-RestMethod 'https://<yourvault>.vault.azure.net/secrets/secretname?api-version=7.1' -Header $Headers
$Headers = Get-ImmyAzureAuthHeader -ResourceUri 'https://vault.azure.net'
 Invoke-RestMethod 'https://<yourvault>.vault.azure.net/secrets/secretname?api-version=7.1' -Header $Headers
Improvements ​
  • Added the capability for ImmyAgent Provisioning packages to be downloaded an ISO. image
  • Added date/time tooltips to session times to see specifically when a session started
  • Removed automatic software evaluation run from computer details page
  • Adds Open remote session buttons to the computer deployment list.
  • Adds a checkbox to include/exclude offline computers from the computer list page.
  • Configuration task parameters are now available in software test scripts.
  • Added OS Name and Manufacturer to the Computer Overview tab.
  • Added dependency badges to maintenance action items
  • Added default to maintenance action table to hide actions with No Action to reduce clutter.
  • Removed unnecessary show preview div from Computer Details->Software tab
  • Removed automatic software evaluation from Computer Details page
  • Added Remote Session button on Edit Deployment page
  • Added offline computer checkbox filter to computer list page
  • Fixed test script result parsing and added config task variables to it
  • Removed legacy TestResult syntax from SoftwareVersion scripts
  • Added date tooltips to sessions/actions times
  • Set JobArgs to Suppress reboots when running action from Computer Details; Needs Attention
  • Moved the drag handle for RMM Priority ordering to the left side
  • Start system required inventory in overwrite existing command
  • Added dependency badge to maintenance session action list item and action table
  • Refactored to keep GetAuthConnectionString() private and added -Endpoint KeyVault as an alias for the resourceUri
  • Added parametersetnames to Get-ImmyAzureAuthHeader to differentiate between orthogonal use cases
  • Default to hiding 'No Action' in the computer actions table
  • Removed string expansion from MetascriptHost to prevent need for backticks in Set-ComputerName Metascript
  • Decreased timeout for the pending reboot check as this could cause sessions to hang for an unnecessarily long period of time if the script doesn't respond
Bug Fixes ​
  • Fixed 'Rerun' button action not suppressing reboots.
  • Fixed maintenance action start and end time issues showing the wrong times
  • Fixed an issue where the computer would show online even though all agents were disabled.
  • Maintenance Task parameters and built in variables values are preserved and no longer string expanded in the Metascript context, allowing you to pass these values unaltered to scripts run via Invoke-ImmyCommand
  • Fixed UTC/local issues with action start and end time
  • Fixed online status for disabled RMMLinks
0.37.10 ​
Released 2020-12-15
Bug Fixes ​
  • Fixes an issue on the computer software list where some fields were not immediately updating.
  • Reduces padding of each item in the software list
  • Fixed issue where scripts would occasionally fail to execute as the user even though the user is logged in
  • Invoke-ImmyCommand no longer returns System.Object instead of $null, making it easier to detect null results
  • $using variables no longer throw a null reference exception when the value is null in the parent context
  • $using variables will issue a warning when they are not present in the parent context, previously a NullReferenceException was thrown both when the variable was declared but had a null value and when the variable was not declared. (Sometimes null is a valid value)
0.37.9 ​
Released 2020-12-14
Bug Fixes ​
  • Fixed regression in 0.37.8 that broke inventory for most machines
0.37.8 ​
Released 2020-12-12
New Features ​
  • Adds a helpful alert letting the user know that user scripts with a user action trigger of Run once at login, Run at every login, and Active Setup at login will run immediately if the user is logged in.
Bug Fixes ​
  • Fixes an issue running some inventory scripts against computers running PowerShell 2.0 (And possibly other PS versions, causing inventory to fail and computer names to be displayed as GUIDs)
  • Un-reversed order of first and last names on edit deployment page
  • Adds missing maintenance task category to the maintenance task details page
  • Fixes an issue where we were not properly updating the maintenance action if the desired state was Update If Found and the software was not present` 
    • Now properly resolves the action result to Success, the Action Type to No Action, and the Action Reason to Software Missing.
  • Fixes issue where RunAsUser fails because user is not a local admin
  • Fixed issue where Immy was pre-selecting incorrect Software after analyzing non-MSI installers
  • Fixes error when using 'Update if Found' with ninite packages.
0.37.7 ​
Released 2020-12-10
Enhancements ​
  • Allows for saving scripts while focused in the editor by pressing Ctrl S.
  • Adds an alert prompting to save changes when navigating away from a modified script
Bug Fixes ​
  • Fixes a permission issue when searching the computer list by primary user
  • Fixed object serialization issue from Windows Server 2003 machines
0.37.6 ​
Released 2020-12-09
Bug Fixes ​
  • Fixes an issue where CW Control RMM Links were failing if the CW Control URL contained a specific route. 
  • Fixes the excel export on the Deployment page's Affected Computers panel
  • Fixes a bug on script details form where the scripts timeout was not showing the correct value
  • Fixes a bug when viewing the script details in a modal, where the default timeout was not being supplied.
  • Resolves issue where Immy incorrectly reports "User is not logged in" when a user is logged in over RDP
  • Fixes a bug on the computer details page sessions tab where sessions for other computers show up if you change the time filter
  • Fixes a bug in the computer list page, if the computer name is missing, we now show the device id
Enhancements ​
  • If a provider fails to initialize, it will be automatically disabled to increase the overall health of Immy.
0.37.5 ​
Released 2020-12-08
New Features ​
  • Function Scripts! Keep your code dry! You can now call scripts from other scripts. Simply create a new script with category Function, define your logic, and then call the function from another MetaScript.
  • Adds a new column to the session table called "Type" to indicate whether the session was "Scheduled" or "Manual".
Bug Fixes ​
  • Fixed duplicate persons issue. Syncing persons from azure users now checks if there is an existing person with the same user principal name (email) and will update that person instead of creating a new one.
  • Fixes an issue where the onboarding form's primary user selector was returning people outside of the selected tenant (Only an issue for MSP users).
  • Fixes a bug where the New and Copy as New buttons were missing from the script selector.
  • Fixed an issue with Immybot using the incorrect software version when deploying the "latest" version
  • You can now analyze a version without specifying the "Installer Executable Path" if the file is a zip file
  • Renamed metascript Get-RmmProvider to Get-RmmInfo and added the information required to retrieve EDFs for Clients and Computers from Automate
  • Addresses memory performance issues with the computer list page
  • Fixes some default properties when loading the maintenance task form in a modal. Fixes a bug in Invoke-ImmyCommand where providing the same $using variable with different capitalization threw a duplicate variable error.
Enhancements ​
  • Added logic to auto select an existing software by upgrade code on the software version upload page
  • Updates the deployment form's software, version, and configuration task "View" buttons
0.37.4 ​
Released 2020-12-08
Bug Fixes ​
  • Fixed an issue with inventory scripts being retried every minute on devices that return exceptions
0.37.3 ​
Released 2020-12-01
Bug Fixes ​
  • Fixed issue with terminal not rendering output when launched from Edit button on session logs
  • Fixes an issue where the suggested rmm link name conflicted with an existing name
  • Set the Hangfire Redis MaxStateHistoryLength to 5 to fix issues with uncontrolled memory leak
0.37.2 ​
Released 2020-11-24
Hotfixes ​
  • Fixed several broken maintenance session links that were not bringing the user to the correct page.
  • Fixed an error in metascripts about the use of duplicate $__using variables.
  • Fixed an issue rendering the xterm terminal within the script editor modal.
0.37.1 ​
Released 2020-11-23
Hotfixes ​
  • Fixed filter scripts to only return a single computer when run for a maintenance session. Not doing this was causing memory to balloon up unnecessarily.
0.37.0 ​
Released 2020-11-23
Enhancements ​
Check out our new documentation site! https://docs.immy.bot/
Actionable Software Inventory ​
  • Updated the Software tab to now provide actionable buttons for software and maintenance tasks that are not compliant
Automatic Onboarding ​
  • Plug in the USB drive and setup begins automatically without having to login to Immy 
    • Create a new Windows 10 Setup USB Package and enable the auto-onboarding option
  • Added a new tab called Sessions that allows a user to easily see computer sessions without leaving the computer details page
  • Added an Onboarding tab to the computer details page to allow easier changing of customer and primary user
Script Engine ​
  • Simplified Filter Script syntax, removed -TargetType and -TargetGroupFilter as these are selectable in the UI
  • Added xterm.js to the Script Editor for better handling of large return payloads
  • Write-Host output is no longer suppressed when run within Invoke-ImmyCommand
  • Write-Debug, Write-Verbose, Write-Warning, and Write-Error all work both within Metascripts, and scripts run via Invoke-ImmyCommand (Note: $DebugPreference and $VerbosePreference need to be set to 'Continue' as the PowerShell default will suppress the output from these cmdlets)
  • Write-Host in Metascripts and Cloudscripts supports -ForegroundColor, -BackgroundColor and -NoNewLine parameters
  • Terminal now formats Errors and many other objects according to the PowerShell 7 default
  • PowerShell 7 $ErrorView= 'ConciseView' is now supported
  • Exceptions thrown within scripts now show the script line instead of a backend stack trace
  • Added $AzureTenantId variable to all scripts
Stability ​
  • Fixed memory leak in the user affinity job that was causing instances to hang on an error page
  • Added availability health checks for some azure resources to help diagnose issues faster.
Hotfixes ​
  • Fixed an issue where renaming a computer did not immediately show the change in the browser
  • Fixed an issue with sending test emails from the smtp page. It would sometimes incorrectly throw an error about enabling authentication
  • Added Update If Found desired state for Ninite Software
  • Fixed selecting a software on the deployment page to auto select "Installed" and "Latest" as the default options
  • Fixed an issue where it was not possible to view global maintenance task scripts from within the Maintenance Task interface
  • ImmyAgent no longer executes Batch/CommandLine as PowerShell
Security ​
  • Get-ImmyComputer no longer returns computers from other tenants when run by a non-MSP user
0.36.4 ​
Released 2020-11-19
Bug Fixes ​
  • Moved the pending reboot check from the beginning of the session to the beginning of the execution phase so computers do not reboot during detection. Computers usually run detection during the day and we do not want to reboot computers while they are being used.
0.36.3 ​
Released 2020-11-13
Bug Fixes ​
  • Fixes bug where rebooting a computer would sometimes hang the maintenance session
  • Fixes a typo reading for onboarding -> ready for onboarding
  • Fixed issue preventing a computer from rebooting if necessary before it starts a maintenance session
  • Fixes an issue where an action would immediately fail if the computer failed to reboot 
    • e.g. A software is supposed to be uninstalled and then reinstalled. After the uninstall, a reboot may be attempted. If it fails, we will now still attempt the reinstall anyway.
  • Fixes a critical bug that could allow a person to be incorrectly associated with another tenant.
0.36.2 ​
Released 2020-11-04
Bug Fixes ​
  • Fixed an issue where the Update Now and Postpone buttons were missing on the maintenance email when they were set to be shown by its schedule.
0.36.1 ​
Released 2020-11-02
Bug Fixes ​
  • Run Maintenance button at the top of the Computer Details Page now suppresses reboots by default
  • Edit PSALink page no longer throws exception when CWManage API returns duplicate companies
  • Updated task type and task category label names on the task form
  • Fixed a null reference exception when calling Get-ImmyComputer passing in InventoryKeys
0.36.0 ​
Released 2020-10-26
Features ​
  • New and improved Computer Details Page that shows much more details
  • Added Inventory Task feature
  • Added a System Status Page that shows script execution metrics for enabled RMM Providers
  • Added a System Update Page that allows an administrator to update to newer versions of ImmyBot when they are released
  • Implemented Downgrade logic for software
Enhancements ​
  • Optimized script execution when using the CW Control RMM Provider
  • Optimized background job scheduling
  • Re-designed the Computer List Page
  • Merged the Onboarding and Pending Computer Pages into one page called New Computers
  • Made the ImmyAgent more scalable
  • Added a loading animation when filtering the Computer List Page
  • When a session expires and the page is reloaded, you will now be redirected back to the page you were on
Bug fixes ​
  • Fixed CW Control extension to work on latest version of CW Control (2020.11)
  • Fixed session failing with Ninite fails to download
  • Fixed a CORS issue when new instances are registered with uppercase characters
  • Fixed an edge case when scripts erroneously indicate they have been modified when pressing cancel
  • Removed validation requirement for username in SMTP settings
  • Fixed Automate Computers with UTC+0 (UK) do not sync due an issue with using DateTime.Subtract(0)
  • Fixed an error occurring on Windows 7/PS 2.0
  • Fixed an edge case where a server got caught in an endless reboot
  • Removed the WiFi SSID minimum length for PPKGs
  • Fixed a bug where license files did not download before running the Test script
  • Fixed an issue where User Context Scripts were returning 'gt' is not recognized
  • Fixed a bug where maintenance tasks were performed out of order when there was a software dependency
  • Fixed a bug on the Deployment Page where selecting a domain controller was causing an error
  • Fixed a bug in metascripts where Get-ImmyComputer -TargetType TenantDomainControllers was failing
  • Fixed bug where the Users List showed a System user
  • Fixed a bug where bulk software detection failed on PS 2.0 and PS 3.0 when using [Guid]::new
  • Fixed a bug where the CW Automate Provider was not leveraging the 301 command
  • Fixed a bug where the ImmyAgent did not start on VMware VMs due to lack of BoardSerialNumber
  • Fixed some edge cases where sessions kept getting stuck in the Created status
  • Fixed a bug where the ImmyAgent was defaulting to 10 seconds for the script execution
  • Fixed a bug where the software selector on the license form was showing parameters for linked maintenance tasks
  • Fixed a bug where maintenance task fields Hidden and Default Values were not saving on Create
  • Fixed a bug in the package analyzer where it was throwing Key Not Found for Inno version 6 installers
  • Fixed a bug with Deployments using a desired state of Uninstall/NotPresent that was causing failures due to missing required parameters
  • Fixed a bug with maintenance task parameters not being provided to software install scripts
  • Fixed a bug where users could not open the Maintenance Session Details Page for computers they onboarded
  • Fixed a bug where deployments for maintenance tasks with password parameter types were unable to be deployed
  • Fixed a bug where the Current User user action trigger was not available for scripts created on the software version form
  • Fixed a bug where the RMM to PSA auto client mapping failed when the RMM returns non-unique external ids
  • Fixed a bug where non-msp users could not access software or deploy the ImmyAgent
0.35.16 ​
Released 2020-10-23
This is the first release in the release cycle

-    
+    
     
   
 
\ No newline at end of file
diff --git a/scripts.html b/scripts.html
index 89eb447d..bb265d6f 100644
--- a/scripts.html
+++ b/scripts.html
@@ -38,7 +38,7 @@
     
   
   
-    
immy.bot
Appearance
Scripting Guide ​
Best Practices ​
  • Use Ctrl+Shift+F or Ctrl+P in our script editor to find scripts that already do what you want. There is a lot of good logic in the built in function scripts
  • Have a machine you can test on
  • Have a separate machine to test your sanity if you bork your first machine
  • Test by clicking Open Debugger in the logs 
    • This gives you all available parameters on the left so you can test the script in its natural context
    • You can quickly revise the script here until it works as expected
    • Saving the script here saves it permanently
  • Don’t hardcode paths to installer or license files, instead rely on $InstallerFile and $LicenseFilePath
  • Don’t hardcode license values or other sensitive information, instead utilize $LicenseValue or a custom parameter
  • Avoid (where possible) installers that have client specfic licenses or customizations built in 
    • If a generic installer isn't available (BitDefender) use Dynamic Versions (and potentially a URL parameter) to specify the download URL per customer or perhaps use an API to find the URL for the given customer
    • If the URL requires authentication, use a custom Download script to perform the authenticated download (CrowdStrike/SentinelOne)
  • Don’t repeat yourself. Leverage function scripts to reuse code
  • Include code to verify that the script did what it intended to do 
    • For Tasks, implement a “test” script
    • For Software, make sure your Detection method works, and optionally implement a Test script to verify things are in working order 
      • When a software Test script returns $false, ImmyBot will re-install the software.
  • Use Metascripts, especially if your script needs to restart the machine or access APIs like IT Glue and therefore will contain sensitive data like API keys
  • Use throw “The bad thing that happened, what user should do” to prevent cascading failure. That message will be shown to the user in a prominent location so they can take corrective action
  • Tasks have a “test” mechanism that should return $true or $false to indicate compliance
While it may be cumbersome to write additional logic to verify your work, the reward of knowing exactly how many machines are or are not compliant with your desired state is worth it. Without it, you are flying blind. With it, you know exactly how many machines require additional attention, giving you the opportunity to write better code that handles more edge cases. See the Helper Function section to see how we make your life easier.
Script Types ​
  • Software Detection
  • Software Action (Install/Uninstall/Update)
  • Maintenance Task Setter
  • Metascript (Deployment Target)
  • Filter Script (Deployment Target)
  • Device Inventory
  • Function
  • Dynamic Version
  • Download Installer
  • Module
  • Preflight
  • Integration
Software Detection ​
Software Detection scripts are used to determine whether an existing software is present and what version it may be.
Avoid custom detection scripts where possible. Software with a custom detection script can't be matched to pre-existing inventory data on the machine, making it difficult to report on how many machines have the software already. Further, the "Assignable" software tab won't work since that matches the detection method to existing inventory data. However if your software doesn't create an entry in Add/Remove Programs, you may have no choice but to use a custom detection script. It is important to note that a lot of software creates hidden entries under Add/Remove Programs, ImmyBot inventories these hidden entries, further reducing the need for custom detection scripts.
When you write your custom detection script, your best bet is to find a exe or dll file under Program Files<software name> or ProgramData<softwarename> that shows the version when you right click on it and go to Properties. To retrieve this version use a script similar to the following:
powershell
Get-Command "C:\Program Files*\<softwarename>\mysoftware.exe" -ErrorAction SilentlyContinue | %{ $_.Version.ToString() }
Get-Command "C:\Program Files*\<softwarename>\mysoftware.exe" -ErrorAction SilentlyContinue | %{ $_.Version.ToString() }
If there is no exe or dll file containing the version, perhaps there is a .ini, .config, .json or .xml file that contains the installed version.
If all else fails, you can simply return "1.0" if a file associated to the software exists.
These scripts must return a string that will cast to a valid System.Version. Returning an actual System.Version will fail. (Although we may correct this in the future) For example
$version = [String]"1.2.3"
+    
immy.bot
Appearance
Scripting Guide ​
Best Practices ​
  • Use Ctrl+Shift+F or Ctrl+P in our script editor to find scripts that already do what you want. There is a lot of good logic in the built in function scripts
  • Have a machine you can test on
  • Have a separate machine to test your sanity if you bork your first machine
  • Test by clicking Open Debugger in the logs 
    • This gives you all available parameters on the left so you can test the script in its natural context
    • You can quickly revise the script here until it works as expected
    • Saving the script here saves it permanently
  • Don’t hardcode paths to installer or license files, instead rely on $InstallerFile and $LicenseFilePath
  • Don’t hardcode license values or other sensitive information, instead utilize $LicenseValue or a custom parameter
  • Avoid (where possible) installers that have client specfic licenses or customizations built in 
    • If a generic installer isn't available (BitDefender) use Dynamic Versions (and potentially a URL parameter) to specify the download URL per customer or perhaps use an API to find the URL for the given customer
    • If the URL requires authentication, use a custom Download script to perform the authenticated download (CrowdStrike/SentinelOne)
  • Don’t repeat yourself. Leverage function scripts to reuse code
  • Include code to verify that the script did what it intended to do 
    • For Tasks, implement a “test” script
    • For Software, make sure your Detection method works, and optionally implement a Test script to verify things are in working order 
      • When a software Test script returns $false, ImmyBot will re-install the software.
  • Use Metascripts, especially if your script needs to restart the machine or access APIs like IT Glue and therefore will contain sensitive data like API keys
  • Use throw “The bad thing that happened, what user should do” to prevent cascading failure. That message will be shown to the user in a prominent location so they can take corrective action
  • Tasks have a “test” mechanism that should return $true or $false to indicate compliance
While it may be cumbersome to write additional logic to verify your work, the reward of knowing exactly how many machines are or are not compliant with your desired state is worth it. Without it, you are flying blind. With it, you know exactly how many machines require additional attention, giving you the opportunity to write better code that handles more edge cases. See the Helper Function section to see how we make your life easier.
Script Types ​
  • Software Detection
  • Software Action (Install/Uninstall/Update)
  • Maintenance Task Setter
  • Metascript (Deployment Target)
  • Filter Script (Deployment Target)
  • Device Inventory
  • Function
  • Dynamic Version
  • Download Installer
  • Module
  • Preflight
  • Integration
Software Detection ​
Software Detection scripts are used to determine whether an existing software is present and what version it may be.
Avoid custom detection scripts where possible. Software with a custom detection script can't be matched to pre-existing inventory data on the machine, making it difficult to report on how many machines have the software already. Further, the "Assignable" software tab won't work since that matches the detection method to existing inventory data. However if your software doesn't create an entry in Add/Remove Programs, you may have no choice but to use a custom detection script. It is important to note that a lot of software creates hidden entries under Add/Remove Programs, ImmyBot inventories these hidden entries, further reducing the need for custom detection scripts.
When you write your custom detection script, your best bet is to find a exe or dll file under Program Files<software name> or ProgramData<softwarename> that shows the version when you right click on it and go to Properties. To retrieve this version use a script similar to the following:
powershell
Get-Command "C:\Program Files*\<softwarename>\mysoftware.exe" -ErrorAction SilentlyContinue | %{ $_.Version.ToString() }
Get-Command "C:\Program Files*\<softwarename>\mysoftware.exe" -ErrorAction SilentlyContinue | %{ $_.Version.ToString() }
If there is no exe or dll file containing the version, perhaps there is a .ini, .config, .json or .xml file that contains the installed version.
If all else fails, you can simply return "1.0" if a file associated to the software exists.
These scripts must return a string that will cast to a valid System.Version. Returning an actual System.Version will fail. (Although we may correct this in the future) For example
$version = [String]"1.2.3"
 return $version
$version = [String]"1.2.3"
 return $version
will work, but currently
$version = [System.Version]"1.2.3"
 return $version
$version = [System.Version]"1.2.3"
@@ -121,7 +121,7 @@
         extraQueryParameters = $null)]
     $OAuthInfo
 )

-    
+    
     
   
 
\ No newline at end of file
diff --git a/terminology.html b/terminology.html
index f54481b0..7648c47b 100644
--- a/terminology.html
+++ b/terminology.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
Terminology ​
Tenants ​
These are your Customers. We recommend syncing Tenants from CW Automate or Azure.
User Computer Affinity ​
ImmyBot periodically runs whoami /upn on all computers and keeps a rolling list of the last 10 UPNs. It assigns the Primary User of the computer to the "Person" (Synced from Azure) with the matching UPN.
For environments without AzureAD, ImmyBot will lookup the UPN of the Person from a Domain Controller in the computer's Tenant
Deployment ​
Deployments were originally called "Assignments" and are still called Assignments under the hood.
Note: You won't see the word "Assignment" in the user interface anywhere, but we plan to re-rename "Deployment" back to "Assignment" it in a future release.
A deployment is a rule that assigns Software or Tasks (Collectively known as "Maintenance Items") to a Target.
Deployments are conceptually similar to Group Policies in that they assign settings to a group of users or computers.
DO NOT BE AFRAID TO SAVE YOUR DEPLOYMENTS. THEY DO NOT APPLY AUTOMATICALLY.
If you DO want your Deployments to be applied automatically, you need to create a Schedule.
Deployment Resolution ​
Also known as
  • Creating Exceptions
  • "Winning" Deployments
  • Dealing with Snowflakes
Like Group Policies have a "Winning Policy", ImmyBot must have a "Winning Deployment" for a given Maintenance Item on a computer.
Let's say you have a customer "Contoso" that uses Adobe Acrobat instead of Adobe Reader, and you would like that to be installed instead.
First, create a Deployment that sets the desired state of Adobe Reader to Uninstalled for Contoso
Then, create a Deployment that Installs Adobe Acrobat for their computers
Target ​
A "Target" is a grouping of computers (or Tenants in the case of "Cloud Tasks")
ImmyBot's ability to resolve Targets to a group of computers is perhaps its most powerful feature.
For example, you can select a Group of users from AzureAD (which includes on-prem synced groups, and Teams) and ImmyBot will automatically resolve that to the list of computers in use by the people in that group.
If you enable PSA integration, a Target could be all computers covered under a certain type of Agreement, or computers covered by an Agreement that includes a certain product.
This is particularly useful for security software, help desk portals, or anything else in your stack that you may only want to be installed for customers that are paying you for it.
Offboarding ​
Conversely, you could create Deployments that remove your stack for customers you are offboarding.
  • Create an "Offboarding" product in your PSA
  • Create a deployment for each of the pieces of software you would like removed setting the desired state to Uninstalled
  • Target all customers with the "Offboarding" product on their agreement
Note: ImmyBot even honors the date range on additions, making scheduled offboarding easier if say the customer wants your software removed on the last day of the month.
Maintenance Session ​
A Maintenance Session is conceptually similar to running gpupdate /force
In other systems, different types of maintenance happen on their own schedule. Windows Updates may run on Tuesday night, but Third Party updates may run on Wednesday night, and auto-fix tasks may run whenever an alert is fired for a failed monitor, which has its own polling interval.
By forcing all automation to happen in a sequential set of actions we call a Maintenance Session, we can deliver predictability not only as to what changes will be made, but also when.
This also provides a cohesive mechanism for setting up a new computer. At best in traditional RMMs you can assign Monitors that detect the absence of required software and run Install scripts when they are missing, but this doesn't scale as pre-requisites and exclusions are required.
Imagine if Group Policy could reliably deploy any type of software, and gpupdate /force worked reliably off-net, and when you ran it, it gave you real-time feedback about exactly what it was doing. Also imagine that it could optionally notify the end user before and after with a branded email telling them exactly what is being done, that optionally lets them cancel.
That's a Maintenance Session.
You can view Maintenance Sessions for all computers under Computers->Sessions
Or, you can view Maintenance Sessions for a specific Computer under the Sessions tab for that Computer
Maintenance Session Stages ​
Detection Stage ​
During the Detection Stage, ImmyBot "Detects" which Maintenance Actions are necessary to bring the computer into compliance. These Actions are added to the Maintenance Session.
This is a read-only process, and typically done while the user is active. This is so ImmyBot can notify the user of changes that will occur later during the Execution Stage. By doing this during the day, and scheduling Execution for later, we are giving the end user the best possible chance to be aware of the upcoming maintenance, Postponing if you allow. The Postpone feature is very popular among engineers that do may need to leave renderings and analysis tasks running overnight.
Execution Stage ​
Maintenance Action ​
null
A Maintenance Session has one or more Maintenance Actions. A Maintenance Action could be to install software, apply a Windows Update, or run a Task.
The image below depicts a typical Maintenance Session with many Maintenance Actions
Software ​
Software, in the context of ImmyBot refers to Software objects in My Software or Global Software.
My Software - Initially empty. When you upload your own software to ImmyBot, it goes into My Software
Global Software - Read-Only, managed by the ImmyBot team.
At the bare minimum, Software requires a Detection Method. Software can have many Software Versions.
null
Pre-Requisities ​
This is a VERY powerful, and critically underrated feature in ImmyBot. ImmyBot resolves dependencies recursively, with built-in circular reference detection.
Common uses for Pre-Requisites include
  • Ensuring a piece of software is installed before installing another 
    • C++ Redistributables before 3CX Client
    • Office is installed before an Outlook Add-in
  • Ensuring a piece of software is uninstalled before install another 
    • Removing Adobe Acrobat Reader before installing Adobe Acrobat Professional
Install required dependencies ​
Ordering Maintenance Actions ​
Detection Method ​
A Detection Method is required in order to know whether or not a piece of Software is installed on a machine.
For Software, the detection method must returns the version of the software installed on the machine, if any.
For Tasks, the Detection Method is the "test" mechanism, which must return true or false to indicate whether or not the machine is in compliance.
Software Version ​
null
Task ​
A Task (aka Mainenance Task) is a catch-all for anything that isn't software.
null
or
null
Task Modes ​
Enforce ​
Runs the "test" script, if the test returns false, runs "set", then runs "test" again to verify.
Audit ​
Runs the "test" script which should return true or false. It can output whatever it wants, but the last output should be boolean.
Monitor ​
Runs the "get" script, which can return anything. Useful for collecting data like Bitlocker Keys, Quickbooks Licenses, or any other piece of information you are interested in.
Scripts ​
From the above diagrams, you can see that scripts are the building blocks for higher level objects like Software and Tasks.
Execution Context ​
System ​
Run as a service on the machine
User ​
Will attempt to run as the logged on user
Metascript ​
Runs in the ImmyBot backend, and can spawn code on the system by using Invoke-ImmyCommand
Cloud Script ​
Runs in the ImmyBot backend, but intended to be run against a Tenant (perhaps for the purpose of getting or setting some setting in 365/Azure or some other system with an API). These are used exclusively in Tasks targetting "Tenants".
Schedules ​
Used to run maintenance periodically on machines. Can optionally be limited to a single Maintenance Item.
NOTE You must also have a Deployment for the Maintenance Item to set the desired state. Imagine a scenario where you need to ensure a single piece of software is up-to-date on all computers except for a CNC machine. Create 2 deployments, the first setting the desired state to Installed->Latest for all computers, then a second stating that the desired state is Ignored for the CNC machine. When you create the schedule, the software will be ignored for the CNC machine.
Integrations ​
To ImmyBot, an RMM is a system that provides a list of computers, and a mechanism to run PowerShell scripts on them.
To avoid having to deploy the ImmyAgent to existing machines, ImmyBot optionally integrates with RMMs like ConnectWise Automate and ConnectWise Control and uses their agents instead. These systems are not as performant as the ImmyAgent, but can suppliment ImmyBot functionality.
For example, if you add an RMM Link for ConnectWise Control, you can open a remote session to the computer directly within ImmyBot:
If you add an RMM integration for ConnectWise Automate, Scheduled Maintenance Sessions will apply all Approved Windows Updates using the ConnectWise Automate API based on your Approval Policies in Automate Patch Manager.
You can even add multiple RMMs of the same type, which is often useful in merger and acquisition scenarios. You may choose to use ImmyBot as your single pane of glass to manage both, or simply let ImmyBot be a neutral third party for facilitating the consolidation of RMM agents to the parent company's RMM.
Identification ​
Because the same computer often exists in multiple RMMs (Like how CW Automate typically installs CW Control Automatically), ImmyBot prevents duplicates by identifying the computer by a unique id. We DO NOT use MAC Address! This unique id persists even if you wipe and reload the machine.
When a new machine is detected, it first goes to New Computers->Actively Identifying 
It uses the following script to collect the UUID from the machine:
gwmi Win32_ComputerSystemProduct | select -expand UUID
gwmi Win32_ComputerSystemProduct | select -expand UUID
This value is static even if you wipe and reload the machine, although we have VERY rarely seen this value change following a BIOS upgrade or due to a mainboard fault. We chose this value instead of Mac Address or Hard Drive serial number because of issues other systems have with USB Ethernet cables and hard drive replacement. We did not use serialnumber because we learned that many computers do not have serial numbers.
In practice, this value works almost too well. Machines you just wiped and expect to find in New Computers, are often associated to their pre-wiped computer objects. To find them, you often have to search for the serial number of the computer in the Computer List. In 0.40.1 we began using the Windows OfflineInstallationID value to identify when an existing computer has been wiped so we can set its status to "Needs Onboarding" which causes it to show up under New Computers as expected.
If it is a machine ImmyBot has seen before, it will be associated to the existing Computer, and you will find a new entry under the Computer's Agents tab. Under the hood we call these entries "RmmComputers".
Computers can have one or more RmmComputers(Agents). You can think of these as logical "pathways" to the computer. We only need one to be online to function.

-    
+    
immy.bot
Appearance
Terminology ​
Tenants ​
These are your Customers. We recommend syncing Tenants from CW Automate or Azure.
User Computer Affinity ​
ImmyBot periodically runs whoami /upn on all computers and keeps a rolling list of the last 10 UPNs. It assigns the Primary User of the computer to the "Person" (Synced from Azure) with the matching UPN.
For environments without AzureAD, ImmyBot will lookup the UPN of the Person from a Domain Controller in the computer's Tenant
Deployment ​
Deployments were originally called "Assignments" and are still called Assignments under the hood.
Note: You won't see the word "Assignment" in the user interface anywhere, but we plan to re-rename "Deployment" back to "Assignment" it in a future release.
A deployment is a rule that assigns Software or Tasks (Collectively known as "Maintenance Items") to a Target.
Deployments are conceptually similar to Group Policies in that they assign settings to a group of users or computers.
DO NOT BE AFRAID TO SAVE YOUR DEPLOYMENTS. THEY DO NOT APPLY AUTOMATICALLY.
If you DO want your Deployments to be applied automatically, you need to create a Schedule.
Deployment Resolution ​
Also known as
  • Creating Exceptions
  • "Winning" Deployments
  • Dealing with Snowflakes
Like Group Policies have a "Winning Policy", ImmyBot must have a "Winning Deployment" for a given Maintenance Item on a computer.
Let's say you have a customer "Contoso" that uses Adobe Acrobat instead of Adobe Reader, and you would like that to be installed instead.
First, create a Deployment that sets the desired state of Adobe Reader to Uninstalled for Contoso
Then, create a Deployment that Installs Adobe Acrobat for their computers
Target ​
A "Target" is a grouping of computers (or Tenants in the case of "Cloud Tasks")
ImmyBot's ability to resolve Targets to a group of computers is perhaps its most powerful feature.
For example, you can select a Group of users from AzureAD (which includes on-prem synced groups, and Teams) and ImmyBot will automatically resolve that to the list of computers in use by the people in that group.
If you enable PSA integration, a Target could be all computers covered under a certain type of Agreement, or computers covered by an Agreement that includes a certain product.
This is particularly useful for security software, help desk portals, or anything else in your stack that you may only want to be installed for customers that are paying you for it.
Offboarding ​
Conversely, you could create Deployments that remove your stack for customers you are offboarding.
  • Create an "Offboarding" product in your PSA
  • Create a deployment for each of the pieces of software you would like removed setting the desired state to Uninstalled
  • Target all customers with the "Offboarding" product on their agreement
Note: ImmyBot even honors the date range on additions, making scheduled offboarding easier if say the customer wants your software removed on the last day of the month.
Maintenance Session ​
A Maintenance Session is conceptually similar to running gpupdate /force
In other systems, different types of maintenance happen on their own schedule. Windows Updates may run on Tuesday night, but Third Party updates may run on Wednesday night, and auto-fix tasks may run whenever an alert is fired for a failed monitor, which has its own polling interval.
By forcing all automation to happen in a sequential set of actions we call a Maintenance Session, we can deliver predictability not only as to what changes will be made, but also when.
This also provides a cohesive mechanism for setting up a new computer. At best in traditional RMMs you can assign Monitors that detect the absence of required software and run Install scripts when they are missing, but this doesn't scale as pre-requisites and exclusions are required.
Imagine if Group Policy could reliably deploy any type of software, and gpupdate /force worked reliably off-net, and when you ran it, it gave you real-time feedback about exactly what it was doing. Also imagine that it could optionally notify the end user before and after with a branded email telling them exactly what is being done, that optionally lets them cancel.
That's a Maintenance Session.
You can view Maintenance Sessions for all computers under Computers->Sessions
Or, you can view Maintenance Sessions for a specific Computer under the Sessions tab for that Computer
Maintenance Session Stages ​
Detection Stage ​
During the Detection Stage, ImmyBot "Detects" which Maintenance Actions are necessary to bring the computer into compliance. These Actions are added to the Maintenance Session.
This is a read-only process, and typically done while the user is active. This is so ImmyBot can notify the user of changes that will occur later during the Execution Stage. By doing this during the day, and scheduling Execution for later, we are giving the end user the best possible chance to be aware of the upcoming maintenance, Postponing if you allow. The Postpone feature is very popular among engineers that do may need to leave renderings and analysis tasks running overnight.
Execution Stage ​
Maintenance Action ​
null
A Maintenance Session has one or more Maintenance Actions. A Maintenance Action could be to install software, apply a Windows Update, or run a Task.
The image below depicts a typical Maintenance Session with many Maintenance Actions
Software ​
Software, in the context of ImmyBot refers to Software objects in My Software or Global Software.
My Software - Initially empty. When you upload your own software to ImmyBot, it goes into My Software
Global Software - Read-Only, managed by the ImmyBot team.
At the bare minimum, Software requires a Detection Method. Software can have many Software Versions.
null
Pre-Requisities ​
This is a VERY powerful, and critically underrated feature in ImmyBot. ImmyBot resolves dependencies recursively, with built-in circular reference detection.
Common uses for Pre-Requisites include
  • Ensuring a piece of software is installed before installing another 
    • C++ Redistributables before 3CX Client
    • Office is installed before an Outlook Add-in
  • Ensuring a piece of software is uninstalled before install another 
    • Removing Adobe Acrobat Reader before installing Adobe Acrobat Professional
Install required dependencies ​
Ordering Maintenance Actions ​
Detection Method ​
A Detection Method is required in order to know whether or not a piece of Software is installed on a machine.
For Software, the detection method must returns the version of the software installed on the machine, if any.
For Tasks, the Detection Method is the "test" mechanism, which must return true or false to indicate whether or not the machine is in compliance.
Software Version ​
null
Task ​
A Task (aka Mainenance Task) is a catch-all for anything that isn't software.
null
or
null
Task Modes ​
Enforce ​
Runs the "test" script, if the test returns false, runs "set", then runs "test" again to verify.
Audit ​
Runs the "test" script which should return true or false. It can output whatever it wants, but the last output should be boolean.
Monitor ​
Runs the "get" script, which can return anything. Useful for collecting data like Bitlocker Keys, Quickbooks Licenses, or any other piece of information you are interested in.
Scripts ​
From the above diagrams, you can see that scripts are the building blocks for higher level objects like Software and Tasks.
Execution Context ​
System ​
Run as a service on the machine
User ​
Will attempt to run as the logged on user
Metascript ​
Runs in the ImmyBot backend, and can spawn code on the system by using Invoke-ImmyCommand
Cloud Script ​
Runs in the ImmyBot backend, but intended to be run against a Tenant (perhaps for the purpose of getting or setting some setting in 365/Azure or some other system with an API). These are used exclusively in Tasks targetting "Tenants".
Schedules ​
Used to run maintenance periodically on machines. Can optionally be limited to a single Maintenance Item.
NOTE You must also have a Deployment for the Maintenance Item to set the desired state. Imagine a scenario where you need to ensure a single piece of software is up-to-date on all computers except for a CNC machine. Create 2 deployments, the first setting the desired state to Installed->Latest for all computers, then a second stating that the desired state is Ignored for the CNC machine. When you create the schedule, the software will be ignored for the CNC machine.
Integrations ​
To ImmyBot, an RMM is a system that provides a list of computers, and a mechanism to run PowerShell scripts on them.
To avoid having to deploy the ImmyAgent to existing machines, ImmyBot optionally integrates with RMMs like ConnectWise Automate and ConnectWise Control and uses their agents instead. These systems are not as performant as the ImmyAgent, but can suppliment ImmyBot functionality.
For example, if you add an RMM Link for ConnectWise Control, you can open a remote session to the computer directly within ImmyBot:
If you add an RMM integration for ConnectWise Automate, Scheduled Maintenance Sessions will apply all Approved Windows Updates using the ConnectWise Automate API based on your Approval Policies in Automate Patch Manager.
You can even add multiple RMMs of the same type, which is often useful in merger and acquisition scenarios. You may choose to use ImmyBot as your single pane of glass to manage both, or simply let ImmyBot be a neutral third party for facilitating the consolidation of RMM agents to the parent company's RMM.
Identification ​
Because the same computer often exists in multiple RMMs (Like how CW Automate typically installs CW Control Automatically), ImmyBot prevents duplicates by identifying the computer by a unique id. We DO NOT use MAC Address! This unique id persists even if you wipe and reload the machine.
When a new machine is detected, it first goes to New Computers->Actively Identifying 
It uses the following script to collect the UUID from the machine:
gwmi Win32_ComputerSystemProduct | select -expand UUID
gwmi Win32_ComputerSystemProduct | select -expand UUID
This value is static even if you wipe and reload the machine, although we have VERY rarely seen this value change following a BIOS upgrade or due to a mainboard fault. We chose this value instead of Mac Address or Hard Drive serial number because of issues other systems have with USB Ethernet cables and hard drive replacement. We did not use serialnumber because we learned that many computers do not have serial numbers.
In practice, this value works almost too well. Machines you just wiped and expect to find in New Computers, are often associated to their pre-wiped computer objects. To find them, you often have to search for the serial number of the computer in the Computer List. In 0.40.1 we began using the Windows OfflineInstallationID value to identify when an existing computer has been wiped so we can set its status to "Needs Onboarding" which causes it to show up under New Computers as expected.
If it is a machine ImmyBot has seen before, it will be associated to the existing Computer, and you will find a new entry under the Computer's Agents tab. Under the hood we call these entries "RmmComputers".
Computers can have one or more RmmComputers(Agents). You can think of these as logical "pathways" to the computer. We only need one to be online to function.

+    
     
   
 
\ No newline at end of file
diff --git a/troubleshooting.html b/troubleshooting.html
index f9f2535e..d603069c 100644
--- a/troubleshooting.html
+++ b/troubleshooting.html
@@ -38,7 +38,7 @@
     
   
   
-    
immy.bot
Appearance
Troubleshooting ​
Identification Failures ​
Needs a Manual Decision ​
Generally you will click "Agent Re-installed"
Often when an RMM Agent gets re-installed, it will get a new id in the RMM (ComputerId in Automate, SessionID in Control). ImmyBot will recognize that it is the same computer, but due to the fact that virtualization technologies and hard drive cloning can lead to the same scenario, we require you to tell us whether we should overwrite the existing RmmComputer, or keep both. 99% of the time you will click "Overwrite Existing". If the machine was in fact cloned, you would click Keep Both, in which case Immy shims the duplicate UUID with its own to prevent collisions.
Pending Computers ​
Computers in the pending status have yet to be identified.
Computers may get stuck here if we are unable to run our Ephemeral Agent
null
Top 3 reasons for Identification Failures
  1. SSL Inspection blocking our websocket
  2. Security Software blocking PowerShell
  3. Incorrect time is preventing SSL/TLS connection
To understand the various reasons identification can fail, it helps to understand how ImmyBot executions PowerShell
  1. RMM or ImmyAgent runs Immybot.Agent.Ephemeral.exe
  2. Immybot.Agent.Ephemeral.exe establishes a secure websocket to wss://subdomain.immy.bot and runs Invoke-PSPipeHost.ps1
  3. Immybot.Agent.Ephemeral.exe feeds Invoke-PSPipeHost.ps1 PowerShell over a pipe from the websocket session
null
The most common cause of identification failure is security software.
To know if this is the case, pull the logs from C:\ProgramData\ImmyBotAgentService*.log
image
Normal Immybot Agent logs look like this:
2022-06-14 00:02:25.560 -05:00 [DBG] Hosting starting
+    
immy.bot
Appearance
Troubleshooting ​
Identification Failures ​
Needs a Manual Decision ​
Generally you will click "Agent Re-installed"
Often when an RMM Agent gets re-installed, it will get a new id in the RMM (ComputerId in Automate, SessionID in Control). ImmyBot will recognize that it is the same computer, but due to the fact that virtualization technologies and hard drive cloning can lead to the same scenario, we require you to tell us whether we should overwrite the existing RmmComputer, or keep both. 99% of the time you will click "Overwrite Existing". If the machine was in fact cloned, you would click Keep Both, in which case Immy shims the duplicate UUID with its own to prevent collisions.
Pending Computers ​
Computers in the pending status have yet to be identified.
Computers may get stuck here if we are unable to run our Ephemeral Agent
null
Top 3 reasons for Identification Failures
  1. SSL Inspection blocking our websocket
  2. Security Software blocking PowerShell
  3. Incorrect time is preventing SSL/TLS connection
To understand the various reasons identification can fail, it helps to understand how ImmyBot executions PowerShell
  1. RMM or ImmyAgent runs Immybot.Agent.Ephemeral.exe
  2. Immybot.Agent.Ephemeral.exe establishes a secure websocket to wss://subdomain.immy.bot and runs Invoke-PSPipeHost.ps1
  3. Immybot.Agent.Ephemeral.exe feeds Invoke-PSPipeHost.ps1 PowerShell over a pipe from the websocket session
null
The most common cause of identification failure is security software.
To know if this is the case, pull the logs from C:\ProgramData\ImmyBotAgentService*.log
image
Normal Immybot Agent logs look like this:
2022-06-14 00:02:25.560 -05:00 [DBG] Hosting starting
 2022-06-14 00:02:25.799 -05:00 [INF] Starting Immybot Agent
 2022-06-14 00:02:25.943 -05:00 [INF] Using configuration file stored at: C:\ProgramData\ImmyBotAgentService\config.json
 2022-06-14 00:02:26.875 -05:00 [DBG] Initializing IoT Hub connection
@@ -99,7 +99,7 @@
 2022-09-21 12:24:50.171 -04:00 [ERR] Application shutting down (App lifetime token cancelled)
 System.IO.IOException: Cannot access a closed stream.
 at System.Net.Http.HttpConnection.RawConnectionStream.WriteAsync(ReadOnlyMemory`1 buffer, CancellationToken cancellationToken)
To correct it, you need to bypass SSL Inspection for your instances hostnames/IPs, which are found under Show more > integrations > Fetch IP Address and Hostnames
Group Policy Objects ​
Computer Configuration | Policies | Administrative Templates | Windows Components | Windows PowerShell | Turn on Script Execution (Enabled)
User Configuration | Policies | Administrative Templates | Windows Components | Windows PowerShell | Turn on Script Execution (Enabled)
These GPOs have been known to cause issues with running scripts.

-    
+    
     
   
 
\ No newline at end of file
diff --git a/user-roles.html b/user-roles.html
index 565cfe1a..72a4956a 100644
--- a/user-roles.html
+++ b/user-roles.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
User Roles ​
MSP Admin ​
  • Full Access, no restrictions
MSP Non-Admin ​
  • Cannot create/edit/delete Schedules
  • Cannot create/edit/delete Users
  • Cannot create/edit/delete Cross Tenant Deployments
  • Can create/edit/delete Single-Tenant and Individual Deployments 
    • NOTE: You can disable this in Settings->Preferences with the "Allow Non-Admin Users to Manage Deployments" setting
  • Can access terminal on all machines and edit scripts 
    • NOTE: You can disable this in Settings->Preferences with the "Allow Non-Admins and Non-MSP Users to Use Terminal and Edit Scripts" 
      • Disabling this prevents these users from being able to run arbitrary code on devices
Customer (Tenant) Admin ​
  • Can view/edit Computers, Schedules, Licenses and Deployments for their Tenant
  • Can create users in their tenant
  • Software they upload is owned by their tenant and are not visible to other tenants
  • Licenses they create are owned by their tenant and are not visible to other tenants
Customer (Tenant) Non-Admin ​
  • Cannot create Schedules
  • Cannot create Cross Tenant Deployments
  • Cannot create Users
  • Can create Deployments scoped to individual Computers and People

-    
+    
immy.bot
Appearance
User Roles ​
MSP Admin ​
  • Full Access, no restrictions
MSP Non-Admin ​
  • Cannot create/edit/delete Schedules
  • Cannot create/edit/delete Users
  • Cannot create/edit/delete Cross Tenant Deployments
  • Can create/edit/delete Single-Tenant and Individual Deployments 
    • NOTE: You can disable this in Settings->Preferences with the "Allow Non-Admin Users to Manage Deployments" setting
  • Can access terminal on all machines and edit scripts 
    • NOTE: You can disable this in Settings->Preferences with the "Allow Non-Admins and Non-MSP Users to Use Terminal and Edit Scripts" 
      • Disabling this prevents these users from being able to run arbitrary code on devices
Customer (Tenant) Admin ​
  • Can view/edit Computers, Schedules, Licenses and Deployments for their Tenant
  • Can create users in their tenant
  • Software they upload is owned by their tenant and are not visible to other tenants
  • Licenses they create are owned by their tenant and are not visible to other tenants
Customer (Tenant) Non-Admin ​
  • Cannot create Schedules
  • Cannot create Cross Tenant Deployments
  • Cannot create Users
  • Can create Deployments scoped to individual Computers and People

+    
     
   
 
\ No newline at end of file
diff --git a/windows-sandbox.html b/windows-sandbox.html
index 67cf26ac..dd941347 100644
--- a/windows-sandbox.html
+++ b/windows-sandbox.html
@@ -38,8 +38,8 @@
     
   
   
-    
immy.bot
Appearance
Testing with Windows Sandbox ​
Windows Sandbox is a fast loading disposable container in Windows that loses all settings when shutdown or restarted. It is very convenient for testing software deployments. It should be noted that not all software is compatible with Windows Sandbox, particular software that installs drivers or requires restarts.
If you haven't used Windows Sandbox before, you can enable it by opening Windows PowerShell as Admin and running the following command:
powershell
Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online -NoRestart
Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online -NoRestart
Download Windows Sandbox file (.wsb) ​
Wait for ImmyBot Agent to install 
Onboard the Sandbox 
This will create an "Onboarding" Session (sessions are like running gpupdate) that will apply all applicable Deployments (deployments are like Group Policies)

-    
+    
immy.bot
Appearance
Testing with Windows Sandbox ​
Windows Sandbox is a fast loading disposable container in Windows that loses all settings when shutdown or restarted. It is very convenient for testing software deployments. It should be noted that not all software is compatible with Windows Sandbox, particular software that installs drivers or requires restarts.
If you haven't used Windows Sandbox before, you can enable it by opening Windows PowerShell as Admin and running the following command:
powershell
Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online -NoRestart
Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online -NoRestart
Download Windows Sandbox file (.wsb) ​
Wait for ImmyBot Agent to install 
Onboard the Sandbox 
This will create an "Onboarding" Session (sessions are like running gpupdate) that will apply all applicable Deployments (deployments are like Group Policies)

+    
     
   
 
\ No newline at end of file