App Manager Errors and Configuration Challenges

[mikey090tx]

Hello All-

We recently purchased Habitat and have been spending some time trying to configure App Manager. I have gone through some of the documentation, old thread posts and some of the Youtube videos to try and find answers and I have not been able to. I hope that we can get some assistance that may help us use this tool to it's full potential.

We followed the process to import the plugin and all appears to be functional and licensed. I setup workstations as Enabled and have approved a few applications from the Application management list. I setup 1 device as our Cache device and configured a shared folder as our cache repo location. We are using a username / pw account that has access to the folder share that would allow access to distribute content from the cache to the repo.

In App Manager, we have configured the schedule delay to 5 Minutes with scan speed in Rabbit Model. We see the counts for Agents and App Affected. Under Repo version we just get Choco version unknown.

I tried to replicate the steps taken by Cubert to run a manual action to confirm all is working as expected on a few agents by performing a manual update /scan. In the script "Habitat Application Manager Service" we returned an error in Step 102. failed in the Else section at step 102. The reason: Row index out of bounds. I ran this on 3 machines and they all have the same error reported.

In the Console view of App Manager, no machines are listing any managed application version details, we are getting scans and software details but no other information if returned to help up proceed with application management.

Any help getting us in the right direction would be greatly appreciated.

[Cubert]

I've posted a quick/ silent video that walks through the basic settings needed to get agents rolling. This video enables a single client that has 3 agents in one location. This is the most basic of setups.


YouTube Video


To narrate the video:

We start by launching the client console for the client we want to enable chocolatey for.
We enable workstations.
We set one agent (1) as the caching manager (responsible for making cache and updating cache. Also responsible for REPO versioning).
We launch the location console and update that location with available cache share info (please verify permissions work)
We then check and if needed enable in the main view all apps we want available.
We then enable from the client app list client apps we want to auto install / update.
Set a Caching Schedule


Now wait, as a first time client there are several things that will need to happen before agents show data. You will find over the next 24 hours several scripts schedules created on each agent. The first Habitat App Manager script will look for and install if missing the Chocolatey framework, Next it will schedule a the same script now to test for pre-existing packages and import them into Automate database. The script will then schedule the install of the packages you enabled. The caching agent will also need to go through all this but then it has to capture all the approved packages from Chocolatey and update the cache and also update the versions for the REPO.

Some things to consider are timing. Since the caching agent has to get Chocolatey installed and packages listed before it can cache packages. This sometimes takes a cycle longer than a standard agent, this may cause agents to also now take another full cycle to get packages installed and updated versions listed in database.

Now you can follow the caching agents script logs and command logs to see what outputs your getting during script runs. This will tell you what function of script was run and the outputs of those commands. If you run into trouble you will need these logs and screenshots to post here for help.

So initial setups allow 48 to 72 hours after all is setup before expecting accurate and complete data. If you schedule caching agent for anything other than daily to start will possibly delay data by that many days.

[mikey090tx]

Cubert-

thanks for posting and sharing the video, I reviewed the steps taken and also the notes that you included in the reply and can say that this was configured in a similar fashion. I have setup 1 device as our cache agent and when I queue the task to check for the version of applications, some apps are fetched while others are showing empty folders. This is happening for applications like Firefox / Wireshark which are part of the standard app list.

I took some time to review the Chocolatey package details and confirmed the app name and stable packages existed and verified that they matched (name / App package). In the app list we continue to show version unknows and in the console, some of the devices that are listed in the tools\ habitat app manager are not showing the the devices having an application.

At this moment I am only trying to at least get to push 1 application to a small group of devices to confirm that the tool is able to manage identifying the application on a device and then updating this as needed. This is currently not working as expected because versions are not returned to the tool and some files are not being downloaded.

Any further assistance would be appreciated, I also sent a PM regarding these issues.

[Cubert]

I'll post a reply for each issue as it will take a little time to write the responses:



Empty Cache Folders

I have setup 1 device as our cache agent and when I queue the task to check for the version of applications, some apps are fetched while others are showing empty folders. This is happening for applications like Firefox / Wireshark which are part of the standard app list.

This is common and in most cases perfectly OK.

Reason:
Chocolatey uses a manifest, (instructions file) for each package, on how to install product and where product files are located. Chocolatey will create a folder with the apps version number included in name for every package you add to Cache Share. But it may only include in the root directory the manifest file.

Example:(firefox)
Share= \myserver\myshare\habitat\packages\firefox-123.321\ (empty)
Share= \myserver\myshare\habitat\packages\firefox-123.321.nget

So there is a, and excuse me if I have suffix of the file wrong, firefox file in the root of packages and also a folder that is empty.


In the manifest file it tells Chocolatey to get Firefox-123.321_(32/64)bit.exe directly from mozilla.org as its a freely available file and needs no 3rd party hosting. This is solely up to the creator of the package (manifest).

Now this may account for most of your issues but there could be other issues if your not able to find any files referencing your packages. in this case I would monitor caching agents c:\windows\ltsvc\habitat\packages folder during a cache update to see what files are created during the cache update process.

[Cubert]

I took some time to review the Chocolatey package details and confirmed the app name and stable packages existed and verified that they matched (name / App package). In the app list we continue to show version unknows and in the console, some of the devices that are listed in the tools\ habitat app manager are not showing the the devices having an application.

The caching agents are responsible for versioning of the master Package list and should be doing so daily (once its up and fully configured). Below is a video on how to run the Master Versioning function, execute this on the caching agent and see what it returns.


Test Run Master Versioning function

Google is being really slow to process today so it may take a short bit for video to process completely

[Cubert]

After 24 hours your new client should look somewhat like this,

Screenshot 2023-11-07 111536.png (43.21 KiB) Viewed 17609 times

[Cubert]

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.

[mikey090tx]

Cubert-

I appreciate the notes and feedback that you provided, I was allowing some time to pass to test and collect information. I followed the steps as outlined and some of those made a difference, unfortunately it had the wrong effect. I set 1 application as our test software for updating (WinRar), I confirmed that files were retrieved, that the chocolately services existed and deployed the framework to my test devices. When I rescanned agents and the tool ran, it actually started installing Winrar on devices that did not have this previously installed.

As you can expect, our goal was to manage and update existing versions and not deploy. At this point I am ready to remove the plugin and start fresh to see if that makes a difference.

I have machines reporting a software installed that is not actually present and all updates have been placed on hold until we can configure this properly.

I plan to follow the steps outlined to remove plugins to hopefully start fresh with no issues.

I do want to note that we also run Patch Remedy and that tool is working as expected.

[Cubert]

When you only want to update a package but not also install it, it should be added to you approved packages list but as disabled.

This should cause it to be available for updates when called but not be included in the Install list for pushing out packages. This will cause the package to be versioned and updates available via cache share. But no agent will have that package added as a approved install. If an agent already has it manually installed it will be seen , added to the installed packages list for agent and then maintained moving forward.

[Cubert]

If you have a scenario where you have a installed package on an agent and do not want to install or update that agents current package version then removing the package from the approved list will result in that package being ignored during update functions.

Keep in mind this however does not guarantee that the package does not update. A manual update or if package self updates then updates may still happen on agent.