Help Getting Chocolatey for Automate Going

[PL-MSTech]

We are making progress, but many of the applications still have this error in commands from the script:
You cannot call a method on a null-valued expression.
At C:\Windows\LTSvc\Chocolatey\GetPKGVersion.ps1:48 char:8
+ if ($dir.StartsWith($Package,"CurrentCultureIgnoreCase")) {
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull

chocolatey-error.png (41.2 KiB) Viewed 62224 times

[Cubert]

From your image it looks like some of the versioning is now updating where others remain with the error you are reporting.

The error is the POSH script failing and returning the error instead of a version value. The error being reported is that "$Package" is null so trying to run a method "StartsWith" fails when compared to NULL.

I believe that a previous issue caused apps to be reported as installed but not so your seeing these packages now fail version tests.

Here I run the same POSH script with a bogus package name, one I know is not installed (swan).

Screenshot 2023-09-07 090601.png (19.43 KiB) Viewed 62216 times

How to fix:

We need to flush these applications from the database for this agent. We can do one of two things:

#1 Remove all agent data and allow it to regenerate. Create a new Automate script with one line that executes SQL code. In SQL code area of function place this SQL query.

Code: Select all

DELETE FROM plugin_p4a_chocolatey_agent_apps;

This will flush all agent data from table and allow you to start fresh with all agents reporting no software. The plugin (24 hours) should rebuild all installed apps for each agent.

#2 Remove only for 1 agent. Create a script and place a one liner SQL execute function. Add the following line.

Code: Select all

DELETE FROM plugin_p4a_chocolatey_agent_apps WHERE ComputerID = '%computerid%'

This query will delete all apps for the computerID that the script is running on. You would execute this script on the agent you want to clear out and start over. The script will pickup on the %computerid% as a script variable and will put the agents ID in that field when script runs.

All these do is remove the data from the table, the plugin will need to continue to run as normal to rebuild this list again.


Lets see if that resolves the issue of versioning for you

[Cubert]

You had also mentioned something about dependencies.

If you are using the public repo directly then dependencies are installed with any package that defines the dependency. The problem comes up when you start using caching functions.

When using caching the agent installs from a provided source (local cache share) if a package requires a dependency it looks to the source its on for that dependency to be there. This means that the cache must host the dependency along with the package that looks for it for it to install along with the called package.

Very similar to the Chocolatey.extentions being added to the approved apps list, also should any dependencies you may need to successfully install selected packages. Adding to the approved software list allows it to be selected to send to caching location so its available when a package requests it.

Some packages may have different packages that do or do not require dependencies.

A good example I believe is 7Zip. If your installing 7zip or 7zip.portable there maybe a dependency but I have not seen any dependency issues with 7zip.install. 7zip.install will also install and register as a Windows Application in the windows registry making it also available in the installed software list for Windows. 7zip and 7zip.portable do not do this when installed via chocolatey. Thus picking the best packages to install from chocolatey is crucial for "expected operation" of plugin.

[Cubert]

I will also fix the versioning script in next build to not pass errors back but to pass "not installed" back so that is errors happen in future that the response is more understandable.

[PL-MSTech]

I flushed the agent data on 9/7 as you instructed and just looked at everything today.
It seems the scripts are still running multiple times per day, but were NO apps on ANY machine under "Managed Applications"... ALL blank...?
Looks like (most, but not all of) the apps were installed under "Installed Software" , but not "Managed Applications".

I ran each and every 'enabled' app on the caching server and it appears that A FEW are popping back into THAT machine.
Is this something you failed to mention that I needed to do after clearing the agent data?

What else do I need to try now?

[Cubert]

I ran each and every 'enabled' app on the caching server and it appears that A FEW are popping back into THAT machine.

I am not sure what you mean by this, "run" enabled app on caching server?

The caching agent is a flag that is used to denote what agent at any given location is set to be responsible for keeping cache updated. This is a completely independent job from being a agent in the location and subject to the enabled apps for the client.

What you will see is that the caching agent runs the automation script more often then a standard agent. All agent run script to test for and upgrade and then again for versioning of installed software. The cache manager agent will run a minimum of 3 and 4 times a day as it will also check the caches versions and update the cache if needed.

That's the process, in your case you are not seeing anything in managed applications but do see managed apps in installed software side. We are **noting that you may see some in installed software and some packages may be missing in installed software if the chocolatey package does not register software to Windows during installs. This would be expected behavior for those packages.

The versioning pass of the automation script for you is failing to either capture agent list, version that list or save that list to SQL. Let me go clear one of my clients managed apps list from the database and run a few tests to see if I can duplicate your issue. It is quite plausible that we broke one thing when fixing another and I am not seeing it because my data was already intact.

I'll respond back before days end.

[Cubert]

Ok, I believe I found the issue, during the latest round of updates the script was altered and the wrong table was in the SQL query so the table that houses the managed apps was not getting data inserted. I didn't notice as my development system's table was already up to date.

See if build 3.5.0.16 resolves this issue.

Click Here to Download

The plugin should auto update tonight if left alone.

[PL-MSTech]

Ok... looks like (at this initial test site anyway), the managed apps are showing up.
But it doesn't look like the "you cannot call a method" has cleared up.

Also, some script results return a statement like this:
Command returned [firefox] current version is [ 117.0.1 ]
And some return an 'OK' like this:
Command returned [dropbox] current version is [ OK ]

If it returns the 'OK' does that mean no update is needed, and if it returns the version, then it is going to update?
Because for notepad++, the result was: Command returned [notepadplusplus.install] current version is [ 8.5.6 ], even though the repo cache (and all other machines) was at 8.5.7... and it still didn't update.
The script has been running each day on those 2 machinnes shown in the image, and the repo cache version has been at 8.5.7 for a long time, but that result (current version is 8.5.6) still shows up every day... so why are the scripts on those machines not noticing that they need an update?

chocolatey.png (70.93 KiB) Viewed 62091 times

________________________________
New site that I am testing, since I have made so many changes to this one... set the caching agent, verified the share on the location... ran the 'update repo cache' option.
I can watch the caching agent download and unpack each package into the C:\Windows\LTSvc\Chocolatey\packages folder.
When the script is done, one of the last results I get is "Copy to location drive successful." -- but nothing is copied to the location share... thoughts?

[Cubert]

Share permissions is most likely your issue.

If agent downloads directly then fails to copy to share, then its share permissions.

The odd thing is in step #83 of the ELSE section of script is a POSH script that runs to copy all the files to cache.

In that POSH script it returns a test for the file as true or false

Code: Select all

Test-Path %locationdrive%\Chocolatey\packages\@REPONAME@* -pathtype leaf

This is saved to the variable @FILECACHE@ , Then we test to see if @FILECACHE@ is = to False and if so we go off and log the failure.

Screenshot 2023-09-19 094121.png (9.82 KiB) Viewed 62077 times

But instead you get "Copy to location drive successful." which denotes a successful test (True).



Here s the full POSH script code, It tests the network connection, It removes any old items and then copies new item, then tests item is there. Returns True if file was copied and false if file is missing.

Code: Select all

net use %locationdrive% /user:%cacheuser% @mycachepass@
Remove-Item %locationdrive%\Chocolatey\packages\* -Recurse -Force
Copy-Item -Force -Recurse %ltsvcdir%\Chocolatey\packages\* -Destination %locationdrive%\Chocolatey\packages\ -PassThru
Test-Path %locationdrive%\Chocolatey\packages\@REPONAME@* -pathtype leaf

[PL-MSTech]

Ok, for new new location... I am a little confused and trying to determine if there is an issue with the LTSVCDIR variable... it doesn't seem to pull the actual directory in scripts.... and was wondering if that was part of the issue.
I apparently did get the cache share fixed b/c the packages are there today, but none of them are showing in managed applications.... so do I have to do something special to get it going on each location -- like manually 'Install software from repo cache' - for the caching agent - or all machines, initially?
We did so much manual deployment and updates to your plugin for my initial location, I don't know where to begin now with a new one.
Thanks