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

Both plans allow you to install and update 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.

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 ad hoc sessions. If you need to manage ongoing maintenance for a computer older than 7 days, you will need to upgrade to Standard.

Standard includes unlimited computer onboardings.

Onboarding a computer does not count towards your standard licenses.

You will see a check mark in the top-left corner of the computer icon when reviewing.

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 ad hoc session has been run against it after the computer has been in ImmyBot for more than 7 days.

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 not, this computer will be added to your active maintained computer count, and maintenance can be performed on it.

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.

We utilize an external PCI DSS-compliant platform to handle all billing.

You can feel safe saving your Deployments. Think of them as documentation of how things SHOULD be. If you want ImmyBot to automatically enforce deployments, you need the ImmyBot Standard plan, which allows you to create schedules.

Think of it as Group Policy that updates only when you manually run gpupdate /force or configure a schedule. We understand that updating and installing software on existing computers can be intrusive to users, which is why we schedule these actions and allow users to postpone them through interactive emails.

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

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 in which every computer gets the same 365 applications. Simply create a deployment for those 365 applications for all computers under that tenant.

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

2. WMI is broken on the machine (Usually on older machines)

The workflow begins when you unbox the system from Dell, HP, Lenovo, Microsoft, or your manufacturer of choice. At the out-of-box screen, insert the USB drive containing the ImmyBot.ppkg file in its root directory.

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)

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 in the root of the flash drive. After you install Windows, it will automatically apply the provisioning package. You should have only one .ppkg file per USB drive; otherwise, you will have to manually select which one to use.

I’ve found that 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.

We will automatically install Dell, HP, and Lenovo driver and BIOS updates through those manufacturers’ tools (Dell Command, HP Image Assistant, and Lenovo System Update).

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.

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

2. Create a Deployment for "Apply Provisioning Package (PPKG)" to deploy the PPKG to the specified machine

Dell, HP, and Lenovo are considered trusted manufacturers. A trusted manufacturer is expected to provide unique serial numbers for its devices. We rely on trusted manufacturers and device serial numbers during device identification. If the agent reports that it comes from a trusted manufacturer and a computer already exists in ImmyBot with the same manufacturer and serial number, we will automatically associate the agent with the existing computer.

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.

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 that subsequent tasks that configure user-level settings, such as the default PDF handler and browser, have access to the primary person’s profile and the HKCU hive where those settings reside.

Yes, you would accomplish this with tags.

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. We recommend using oAuth over DEM user.

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

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

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

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

The ImmyAgent is written in .NET, and as such supports the same Windows versions the .NET runtime supports. The Agent has continued to move forward onto newer, supported .NET releases since the .NET 7 to .NET 8 transition referenced in earlier versions of this FAQ. As a result, Windows 7 and Server 2008 are no longer supported by ImmyBot; see the notice at the top of this page for details. Older, unsupported systems may continue to work inside ImmyBot with the necessary updates applied; however, we do not offer support for unsupported machines.

• Internal testing has shown that Win7 and similar machines can sometimes still run the agent as long as they have the necessary updates, using a third-party tool such as Legacy Update.
• See Supported Operating Systems

[!DANGER] We do not endorse or support agents that utilize Legacy Update or similar tools. The best thing to do is upgrade the system. Use at your own risk.

No. We may get there someday, but for the time being, our platform is Windows only.

See Supported Operating Systems

Yes and no. While we don’t actively consider it during the design phase of the agent, it has had a fairly high degree of success with ARM devices.

ImmyBot’s EV code-signing certificate changed on Feb. 11th, 2025 (a day ahead of the prior certificate’s Feb. 12th, 2025 expiration, to ensure a smooth transition).

This certificate is used to sign the Agent binaries and installers delivered to machines.

The new certificate’s Organization(O) and Common Name(CN) fields changed from Immense Networks to ImmyBot LLC.

Current Certificate (since Feb. 11th, 2025):

CN=ImmyBot LLC, O=ImmyBot LLC, L=Baton Rouge, S=Louisiana, C=US

Prior Certificate:

CN=Immense Networks, O=Immense Networks, L=Baton Rouge, S=Louisiana, C=US

If you followed either the Security Software Exclusions or ThreatLocker Setup guides before this change and have not yet done so, you should go through the guides again and add the new certificate in addition to the existing certificate exclusion, since older binaries signed with the prior certificate remain in circulation and continue to be valid.

No. Binaries and installers signed with the prior certificate remain valid and continue to work indefinitely since they were signed before that certificate’s expiry. Only agent releases and installers generated after the transition are signed with the current certificate. This is why it’s important to keep the prior certificate exclusion in place for instances with pre-existing machines.

Supply ImmyBot with an API Key to SentinelOne, and ImmyBot will look for a Site in your SentinelOne instance that matches the name of the Tenant you are onboarding the computer for.

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 sight 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.

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

Starting in ImmyBot 0.82, the silent install for the EXE bundle is -y /qn The SetupComplete.cmd after updating to 0.82 can be: start C:\Windows\Setup\Scripts\ImmyAgentInstallerBundle.exe -y /qn

A member of the ImmyBot community also likes to use the method below to embed a PPKG into an image:

DISM.exe /Image:D:\mount /Add-ProvisioningPackage /PackagePath:C:\Users\Moi\Downloads\ImmyBotAgentInstaller.ppkg

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 computer’s tenant in the Onboarding area after it appears under New Computers.

Create a deployment for the "ImmyBot Agent" and set "Software Should Be" to "Uninstalled."

Or run the following from Command Line:

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

Or from PowerShell:

$product = Get-WmiObject win32_product | where {$_.name -eq "ImmyBot Agent"}
Write-Host $product.IdentifyingNumber
$Arguments = "/x $($product.IdentifyingNumber) /quiet /noreboot"

Start-Process -FilePath msiexec -ArgumentList $Arguments -Wait -Passthru

System update notifications indicate that we’ve released new features or bug fixes for your ImmyBot instance. Here’s what you need to know:

• Updates typically take 5-10 minutes to apply and restart your instance
• During the update, your instance will not be accessible
• No maintenance sessions are triggered on endpoints as a result of the update
• Any running sessions will be restarted after the update completes

If you prefer to automate updates, you can schedule a time for automatic system updates under Show More > Preferences. This allows you to set updates to occur during non-business hours to minimize disruption.

Files uploaded through ImmyBot Remote Control are stored in a specific location on the target computer:

%ProgramData%\RemoteControl\Shared

This folder contains all files transferred during remote control sessions. You can access this location directly through File Explorer or by running a command prompt and navigating to the directory.

Yes, we welcome feature requests and contributions from our community! Please submit your requests on the ImmyBot Community portal. Our team regularly reviews these requests and prioritizes them based on user demand and alignment with our product roadmap.

Make sure there is a Domain Controller in ImmyBot for the machine. If you are using a supported RMM such as ConnectWise Automate/Control, set up the integration so that 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. ImmyBot may report a name collision or an inability to run scripts on the domain controller, usually because of security software.

The "Set Computer Name and Domain Join" task needs to be run serially. If you’re doing a large batch of onboardings, they may get stuck on this task. Ensure that all of the computers and Domain Controllers are online and connected to ImmyBot to ensure that they get through that task quickly.

Ensure that the system time is correct, and then restart the ImmyBot Agent Service.

Branding information is here. If you want to change your ImmyBot subdomain, you need to submit a ticket to ImmyBot support.

There are a couple of ways to do this.

1. Within your instance: Show More > SMTP > Click on "Fetch IP Addresses and Hostnames"

   • If you see 7 IP addresses under "immy.bot IP Addresses" then you’re on App Service
   • If you see 2 IP addresses under "immy.bot IP Addresses" then you’re on Kubernetes

2. Run DIG against your instance URL

   • If you get a CNAME Record back then you’re on App Service
   • If you get an A Record back then you’re on Kubernetes

No.

• The IP addresses that your agents and instance utilize for command and control.
  • The new IP addresses will be sent along with the notification email.
• You will see better stability overall, but especially during workload bursts within ImmyBot

No. Your instance will be down for 3 to 7 minutes while the instance spools up on the cluster.

For the most part, nothing. Your endpoints will automatically reconnect to the new infrastructure. There will be no changes to deployments, software, tasks, etc., since they’re agnostic to the platform they’re on.

If your instance is not running at least ImmyBot 0.72.0, you will need to update it. To update your instance:

1. Log in as an MSP Admin.
2. Navigate to Show More > System Update.
3. Follow the on-screen instructions to complete the update.

If your instance is not updated by the time the migration window starts, we’ll update your instance as part of the migration process.