Support Forum

The new Habitat Application Manager is a deployment and update manager for third party applications running on Windows agents inside ConnectWise Automate. This allows the MSP the ability to install application if needed but better yet Habitat auto detects what applications maybe installed on the end agent and matches up packages in it's approved applications list with installed software to update and manage the application moving forward.

Here is how it works:
The Habitat Application Manager uses Chocolatey.org (NuGet) framework to assist in the management of available application versions and their installation. Habitat does this by deploying the chocolatey framework to each agent enabled for management, assigns a single agent at each location the job of caching all packages approved on the client locations cache drive. The rest of the agents are instructed to receive their updates via this cache drive providing a huge savings in bandwidth and insuring that service limits are not exceeded.

***Note***
For application installs and updates to be distributed a caching drive must be setup and available at each client location.

As updates are reported to Habitat and Schedules permit, updates of the cache are made then agents are instructed to update their applications.

Most of the functions in the Application Manager are script based which means that although the command to do something was given it may take several minutes or more to actually complete the task. You can monitor the status of any of the functions in the script logs inside the agent console for the agent in question.



Application Manager:

The application Manager is accessible from the main Habitat Console and allows you to configure the application searches and set repository packages definitions. Once you have a package selected you can see in the right pane the number of applications names that match your search or toggle over to see the number of agents that will be affected by the software search.


Turtle and Rabbit
There is a master speed setting that controls how often in a day the services for the plugin run. This is depicted as a rabbit or a turtle in the console. In turtle mode application caching and agent syncs are preformed only once a "scheduled" day where in rabbit mode they are preformed several times over the same scheduled day.

A scheduled day by default is everyday or daily. However you can control this by changing the schedule in each of the client consoles when enabling a client for management.

There is a delay setting what controls the staggering of agent script schedules so not all agents try updates or version checks at the same time. You can stagger script schedules by (X) minutes for each agent from the agent before it.



Client Console:

The client console is where you enable the clients for management by clicking the servers and /or workstation check boxes. You can set a schedule for each client independently of each client. Clients can run daily, weekly or monthly. You can pick the day of the week or the day of the month that you would like automation scripts run on the online agents.




Each agent has several functions available to them by selecting then from the agent list and right clicking them to expose the agents action menu.

Action Menu:

• Open Agent Console - Both open agent console and location console launch Automates consoles.

• Open Location Console

• Deploy Framework - Allows you to manually deploy the framework to an agent (optional)

• Set As Caching Agent - Sets the agent as the responsible agent.

• Set As Stand Alone Agent - Sets the agent as the direct to repo access agent.

• Set As Normal Agent - Sets the agent as standard agent that access all packages from cache.

• Update Now - Schedule update script now

• Run Version Scan - Schedule versioning check for now

• Enable/Disable Auto updates

• Update Repo Cache - Scheduled repository update now

• Install Software From Repo Cache - Schedules install of cached software

• Install Software From Community Repo - Installs any package directly from chocolatey repository

By default the schedule is daily which gets a client going typically in just a few hours depending on what agents are online and such. Most clients will be up and running in 24 hours so allow a little tile for automation to sort out a newly enabled client. Once you have the client running and acceptable data in the plugin you can back the automation down to a weekly or monthly task. Set your delay (in seconds) for 2 or 3 to stagger the agents just a little and you should be off to the races.


To Cache or not to Cache, Why do we Cache!

Long story short is that over the years Chocolatey.org has started to throttle and block the public repositories from high volume usage. So when they see multiple Chocolatey agents trying to make requests to the public repo they start to throttle you and if it continues over time they start blocking the locations IP address for several hours at a time. This causes havoc with trying to keep locations with large networks up to date. So by default we suggest using caching and we made it as easy as possible to setup and execute.

At the heart of the system is the ability to use cache drive locations to feed the mass of agents while having just one agent actually stepping out on to the internet to manage the cache at each location. This saves time and energy it would otherwise take to allow each agent at the location to download the same packages repeatedly. This also prevents exceeding the community repository limits and causing agents to skip installs and updates.


To configure cache if it is not already done so for a location is to provide a easily accessible network share on the local client network or through a VPN where roughly 1 .5 GB of application cache can be stored. This storage should support most every need for cache management. You can use NAS drives, Domain shares and workgroup shares, any SMB accessible storage should do. You must supply a valid username and password for the share for the backend to work correctly.

If you are using VPN enabled networks at any location that shares storage with another location then you only need one caching agent for the storage location. You do not need to set a caching agent at each location but only set a caching agent at any one location to manage the cache. The cache share and caching agent do not need to be on same network segment as long as caching agent can see caching share on network.

Stand alone agents ignore the cache process and go direct to public repo. Be careful in how you use these, if you mix them in with caching agents on the same network location then they may cause the throttling of your caching agent.

Here is a quick How-to get rolling with first client.


Until you turn on the automation and enable the first client nothing will happen with Application Manager. Turning on the Automation will allow it to schedule the correct scripts and functions when needed but if no clients are enabled, the automation really has nothing to do.

Once you enable the first client and that clients repository cache is created on the “Location Drive” the system will have the information needed to start filling in the global views.



Do the following:


Main Console set delay to 3 minutes and make sure your seeing Rabbit.



Next Open Automated services and enable 3rd Party App Manager Services.


Enable 3rd Party Updates services here….



Lastly Enable a client. Go to a Client Console and find the Habitat Application Manager tab. Enable at least workstations or servers checkbox. Right click an agent in the list to set is as the “Caching Agent”. The Caching agent is the agent that will retrieve the packages from Chocolatey.org and store them on the “Location Drive” All other agents will only look at “Location Drive” for packages.

Keep in mind that all “functions” are Automate Scripting based and when a function is selected you will need to allow time for the script to execute on end agent. This means that if you select to “Update Now” and in just a few seconds you select to run version scan that you may have Automate drop one of the commands thinking it’s a duplicate scheduled script. Allow a few minutes between Client level functions so the scripts have time to run through queues.

This also means you can “see” what the scripts are doing on each agent by looking at the agents console and reviewing the scripts and commands logs. You will see every activity that a script takes against the agent. This is needed information when trying to troubleshot issues with agents. If you post to the forums, we will typically request this log data so we can see how the agent reacted to the commands being sent.



Once this is all set the first time, I would suggest a DBagent restart to make sure everything kicks off in Automate. Afterwards if nothing else is done you should have some level of data in the different fields for “Online” agents in about 12 hours or so depending on time of day your configuring the client.


Good luck,

You may have packages that have dependencies (other packages) that are needed to complete the install of the package in question.

A common dependency is chocolatey-core.extension which is not installed by default with chocolatey framework but is used with several larger packages like Google or Adobe. So although this is not a package you want to look for and update it may be needed in your cache location drive to satisfy the needs of other software packages you do want to distribute.

Just add it to your search and activate it. That's it.

Hi! I am trying to setup the 3rd party app manager tool. We don't have a location drive that we could use like a nas or other share drives on a server. I am assuming we can't use OneDrive?? We are a MSP and don't have a drive that all clients could access or any servers in our own environment. How could we setup the location drive??

Typically you have 2 options with Chocolatey.

Note, that this is client location specific so would need to be by location when setup.

If a location has many mobile agents or a few stationary agents the setting all agents for the location to standalone will typically work with out issues.

If a location has many stationary agents then the Chocolatey Repository will start to throttle or even block requests to the repository when their limits are reached. A Chocolatey MSP license for each agent would eliminate the limits placed on a location but at I believe the writing of this email is $17 bucks a year per agent which can get expensive fast if client location has hi agent counts. So we get around this by creating a cache and assigning an agent to be the cache manager. This way only the cache manager speaks to repo and thus you never hit any limits. This cache manager agent downloads and places the files need on a share and then all other agents at location (not set as standalone) will use cache to get installs and updates.

So you can set cache up several ways.

1. Use a NAS

• Share Agent Folder

• Hang a USB drive or thumbstick

The cache typically uses (depending on approved application list size) less than 1GB of storage so anything from a simple allocation of a folder on an agent and sharing it out to the locations local network, to having a NAS or sending out a thumb drive to a single agent at a location for the purpose of caching will suffice.

You only need a simple permissions on the share to allow read from anyone and write from agent or user assigned to share. This allows the caching manager agent to post to share and all other agents to read from share.

If non of these options are available then your only option is to set all agents as stand alone agents then either purchase the MSP licenses for any location bigger than about 5 agents. We start seeing issues with limiters around the 5 agent mark of any one location. Laptop roamers are mostly exempt from the limits as they move around to different IP networks and as such do not trigger limiters as often.

When Adding Approved Packages It’s Good Practice

When using Caching Sites you should consider any supporting packages you might need to also have so that your primary packages can complete install or updates successfully.

3 common packages to include with your Approved Packages list should be:

chocolatey
chocolatey-compatibility.extension
chocolatey-core.extension


If you find that packages are failing to install or update then these may be a cause. Add them to your approved packages list and update the site cache for each location.
Afterwards select the chocolatey-core.extension package’s menu from Approved Packages list and click to install to all agents. You can also push chocolatey-compatibility.extension or allow auto installer to pick it up and install it during install cycle.

You will need chocolatey-core.extension for many of the packages you want to install or maintain from Chocolatey.org so don’t forget to add these to you Approved Packages list.