Agent Rollout Options
Deploying the agent to an environment is no small task no matter what the product. Installing a piece of software on a machine that has to meet local prerequisites as well as communicate with a remote machine to pull down policy data involves a great many variables that can complicate matters. And then there is the delivery mechanism. Some environments may require multiple ways of installing an agent to do a successful rollout. Ivanti has simplified the agent installation process down to a single universal STPlatformUpdater.exe file. It is the same installer for all Windows customers. This gives you a payload that can be delivered using a number of different methods.
Push Installation from the Console
Using Ivanti’s agentless technology, you can push an agent install out by simply selecting a machine from the machine group or from Machine View and installing an agent with the policy desired. This is the quickest and easiest way to rollout the agent, but is bound by the same requirements as agentless scans.
In cases where there are a small number of machines that are not reachable agentlessly, you can consider performing a manual agent installation. The manual process requires you to enter a few variables (console hostname, port, passphrase or credentials, and policy) during the installation of the agent. This can be done quickly and easily for small numbers of machines, but becomes less viable the larger the target base becomes.
The STPlatformUpdater.exe file used for manual installation can be found here:
Installing Agents from the Cloud
If you are using Protect Cloud synchronization, you have the ability to install a Security Controls Agent from the cloud. This is particularly helpful if you have target machines that are away from the corporate network and unable to contact the console. For more information, see Installing and Supporting Agents on Internet-based Machines.
The requirements for installing an agent with this method are:
•You must have a Protect Cloud account
•The target machine must have Internet access
•The Security Controls console must be registered with Protect Cloud (Tools > Options > Protect Cloud Sync)
•There must be at least one policy that is configured to allow synchronization with Protect Cloud (see the Sync with Protect Cloud check box on the agent policy General Settings tab)
•You cannot install a cloud-based agent on a Ivanti Security Controls console machine
•Each user that installs an agent must have administrator access on their target machine
The STPlatformUpdater.exe allows command-line execution so install can be scripted and delivered in a number of different ways. The command-line options are all detailed in the Creating and Using a Manual Installation Script topic. Delivery of the STPlatformUpdater.exe and execution using a command-line can be performed in a number of different ways quickly and easily. The problem here typically is how many agent policies need to be rolled out. Each policy means a different script and then sorting out which machines get what can be more difficult.
The ability to push the agent from the Ivanti Security Controls console is nice to have, but if you are pushing the agent to 1000 machines in a machine group that is setup by an IP range, and if you hit 90% of the targets the first time through, what do you do with the remaining 10%? Using Ivanti Security Controls custom patch feature we can scan the same group and detect if the agent is installed and only install on machines it is not installed on. This can be helpful in many ways. Every few weeks or months an additional scan can be run to pick up machines that may have slipped through the build process and not received an agent.
Using the options above, you can get creative with scripting options and deliver the agent in a number of different ways. The STPlatformUpdater.exe file can be wrapped in a self-extracting zip to extract and execute a command-line installation that is delivered via email (the .exe file is roughly 17MB). This can be used to reach some users who are rarely in the office. The same could be delivered through a hosted weblink. The user would simply click on the download and run the file to execute. In this case the user doing the executing would need local administrator rights, but in many cases where the user is at a standalone site or is a heavy remote user this is often the case. For customers who image using ghost or sysprep or some other means, you cannot install the agent and make it part of your image due to the nature of how the agent registers itself with the console for security purposes. You can embed the scripted install into the image so that the first time it reboots it can run the agent installation and be up and running as part of the build process.
Was this article useful?
Copyright © 2019, Ivanti. All rights reserved.