C4A 3.6 updates/changes

[Cubert]

I am not sure how this is possible. Any updates should be matching the plugin GUID and operating a replace query to update existing plugin entry, not create a new one.

We used this code in all our plugins to update them as we release new builds. In seven years I seen this only twice and your number 2.

So how I would fix and test is:

Remove all Chocolatey for Automate plugin entries, restart the DBagent to flush plugins out of current service. Download the latest build from our site and install as a new plugin. Restart the DB agent once again to load plugin and restart your Control Center.

Monitor over next 48 hours to see if any new entries start to pop up. Report back if you do.

I'll look at update script to see if there is any language we can add to prevent this from occurring.

[PL-MSTech]

We need a view in the plugin to show us the inconsistencies between machines at a client site.
The site I have been struggling with testing from day one with 3.5 is looking better for sure, but even though each machine shows green for 'current' there are still inconsistencies. I realize that it may be the machine, or an application, etc. that is possibly causing some packages to fail - and that I have to look at the logs... but WHICH MACHINES - and WHICH PACKAGES? At this point, I have to manually type out the globally approved list into a spreadsheet and look through EACH machine to see what packages have failed on which machines... then I can look at the logs to see what happened.
Furthermore - and better - why not have a log of failed package installs - or missing packages along with the machine they belong to?

[Cubert]

That's a good request!

Let me ponder this a little to see where/how to best display this data. I am kinda thinking the Client Approved list gets a menu item for each package that would display a list of agents either with or without that package installed.


I am leaning to the latter, display a list of agents missing that package? This means you would need to click on any /all enabled packages one at a time from the client approved packages view and select from a pop up menu to view agents missing package. This would then create a new window with a list of agents currently missing package in question. This new view could allow you to launch an agent console directly from agents list to quickly get to the script and command logs of the agent.

This would be the first step to a larger set of functions that could provide some level of accountability to failures.


Is this something you could see value in?

[PL-MSTech]

I believe it would definitely be a move in the right direction... also, I believe something like a dataview showing the whole list of machines at a site - with a column for each approved package, and the rows for each package indicated as 'installed' 'not installed' 'not attempted' 'failed' etc. would be great!
This way we get it in one table - without having to view a status of each machine or each package.

[Cubert]

I just pushed out 3.6.0.8 that now includes a new Client Audit Tool,

This tool will display a list of agents that currently do not completely follow the clients approved package policy. This tool will allow you to install or uninstall any package listed in tool. You can also launch the agents console from the tool making it quick to jump over to agent command logs to see tool in action. All install and uninstall commands sent from tool are direct commands to agents and are not monitored for success or fail. The agent will be rescanned on next scanning interval and will adjust its packages installed list at that time. If you want to see the updates in the plugin immediately the you will need to force a agent scan and allow scan to complete.


To open Audit Tool:

ClientAuditTool-Menu.png (42.82 KiB) Viewed 9683 times

Install Missing Software on agent (7zip)

ClientAuditTool.png (29.6 KiB) Viewed 9683 times

[Cubert]

Let me know how it works for you.

[PL-MSTech]

Shannon... I sent you an email regarding the update question... and thought I would pick back up here...
From: <sanderson@plugins4automate.com>
Date: Tue, Apr 2, 2024 at 8:26 AM
Subject: RE: Chocolatey
To: Linley, Patrick (mstech) <patrick@mstech.info>
Patrick,
I will be glad to give you some assistance. To allow us to convers easily, and share data without loosing you in the sea of emails I get daily, let’s open a new post on viewforum.php?f=83. This forum is specifically setup to manage Chocolatey for Automate issues. In the post, explain what you have done thus far and the results your seeing. Provide screenshots if available and any script and command logs from agents where applicable. This will help greatly to allow me to assist.
Thanks

So... yes, I think the audit tool does help... however, when we approve an app globally, for example, it doesn't appear to be approved for client machines.
We are seeing different installed versions of managed applications on machines that are showing any managed applications.... do these need to be completely removed manually in order to get everything 'aligned'?
Also, should "Approved Packages" = "Managed Applications"?
Your latest email says to download the latest version of Chocolatey for Automate 3.5.0.9, but I have 3.6.0.9 installed.... I think the web page link also shows 3.5.0.9, but also downloads 3.6.0.9. I got this email 4/1/24, but I believe I have been on 3.6.0.9 for quite some time.... could it have updated through the solution center? ---- oh, it looks like I got an email regarding 3.6.0.9 on 1/27/24

I suppose that's a start.

[Cubert]

Ah, I am glad I sent you here!, Now I will have a history of what we talked about from last support and can assist you further.

I think the audit tool does help

Awesome!

Your latest email says to download the latest version of Chocolatey for Automate 3.5.0.9, but I have 3.6.0.9 installed.

Yea, that's a typo.. it should read 3.6.0.9. No Worries...

when we approve an app globally, for example, it doesn't appear to be approved for client machines.

This is expected behavior. Think of global is a master list of packages and their versions. This list then populates each client individually so you can select from master list to approve packages for each client. One client may get (Wget) where another client does not. Approving a package for a client is a 2 step process. Add to global and enable at the client.

We are seeing different installed versions of managed applications on machines that are showing any managed applications.... do these need to be completely removed manually in order to get everything 'aligned'?
Also, should "Approved Packages" = "Managed Applications"?

Managed packages and Approved packages are not the same! You can have one without the other.

You can have Managed packages with or without any Approved packages. Managed packages are any packages that were installed using the package manager, in your case Chocolatey. Approved packages are packages you as the MSP would like to allow to be available to any agent for install (if set to). A prime example is the Chocolatey App itself. It is required for this plugin to work correctly, it will be installed as a managed app whether approved or not, enabled or not.

A user can also manually install applications using Chocolatey, you will see any package that was installed using Chocolatey.

I hope this helps explain the different aspects of packages.

[PL-MSTech]

Is approving the app a 2-step process for the whole client or for each machine?
I would expect that it be for the whole client, as if you click the approve apps button, it says 'enable or disable for the client'.
For example, if I have approved 7zip.install globally, do I only need to add it to the approved applications list for 1 machine and expect that it will get installed to all client machines at that location, or does it need to be installed to each and every machine, then added to the approve list for each machine as well?

I would expect the process to work this way:
1. Setup cache server
2. Approve apps globally
3. Open client/location, click 'Approve Apps' and choose which apps to install
4. Right-Click cache server and choose to 'update now' to do an immediate update of all packages on the share
5. Once the apps are on cache server, either force an immediate installation of apps on the client machines by right-clicking and choosing 'update now' - or wait until scripts run
6. Once all scripts have run and apps have been installed, all apps with all current versions should appear under 'managed applications' tab

What am I missing? I even have machines where chocolatey is a 'managed application' but it is not being updated to a current version - one even shows 0.10.15, where others at the location show 1.1.0, 1.3.1, etc

Thanks

[Cubert]

Correct, Think of the global app list as just a list of apps you want to "monitor" the version numbers of. Then at the client is where you actually approve a package. The approved packages at this level cover all agents "Enabled" under the client.


As for the process, your pretty close.

1 Add and Enable to the global apps list all apps you want to allow across MSP
2 (if using choco proxy) add proxy source to global source lists - optional
3 (if using Chocolatey Licenses) add license text to global license configuration. - optional
4 (if using Network Cache) Edit each location console under client, Add network info along with user and password to network drive EDFs -optional
5 Open C4A in Client console, enable workstations and / or servers
6 Once Agent list appears, If using either sources or network cache, select one agent at the location you want to enable network cache, right click and open menu and select "Set Location To Use UNC cache" or "Set Client to Use Sources" if you are using either Network cache or Sources like a Chocolatey proxy or other repos. - optional
7 (If using a Chocolatey License) select agent, right click menu and select to "Push out Chocolatey License" - optional
8 Select Approve Apps button, approve one or more software titles for the client. -optional
9 Select the Set Schedule button, defaults to daily updates. Select to reschedule to weekly or monthly if needed. -optional
10 (if using Network Cache) select an agent for each location using network caches. Select 1 agent at location and right click menu to select to "Set Agent As Cache Manager". This forces this agent to populate the cache and maintain it. -optional

At this point you could stop and the plugin should take over and start managing agents. You have the option to manually force agents to proceed but you would need to do it in the correct order to not receive bad data or errors.

Example: Running an agent scan when the Chocolatey framework has not yet been deployed to agents would cause a script error and no data from agent.

Each agent has a set of EDFs under "Chocolatey" that set the state of the agent and also records it's progress. You can use the EDFs to trigger certain actions.

Example: You deployed a source but decided it was bad so you updated the source and want the agents to reprocess the sources. By editing the agents EDF, unchecking the Sources Enabled checkbox and making sure the Enable Sources checkbox is checked, the agent will rejoin the deploy sources group and then redeploy new sources you configured.

It may take a little time for an agent to walk its way through each step (sub group) to get to installing and updating packages which is the final steps for a successfully managed agent.


Also I can not stress enough to make sure you always add and approve Chocolatey itself and it's dependencies.

Visit this post for more on why we add these and what actually to add.
viewtopic.php?t=6319

When you go to post an issue with a deployment or such make sure to include a screenshot of all your EDF settings for the agent in question. Include what groups you currently see agent in. Any script and or command logs the agent may be generating during any given phase of the process.

I hope this helps!