Support Forum

after a litte testing:

if i use a fresh uninitialized variable which is not set in line 91
(eg @MYENCODEDSRCWS@ ) then it is filled corretly in line 93 und if i use it in line 94
the command works

maybe a bug in connectwise ? Variable set as contant maybe a string var which is not long enough to take the uuencoded string ?

i also tried to copy shell result of command line 93 manually in debug to the var @MYENCODEDSOURCEWORKSTING@ and this works, too.

frankbe wrote: Fri Mar 14, 2025 2:07 pm i have habitat - can i use your download link or does that effect our license ?

I typically will update Habitat within a few days of any Chocolatey For Automate update in 3..7, I have in this case as well, Should see a Habitat 1.0.1.51 that now has this build deployed.

I hope you see my post before ? Do you have the same strange effect on the vars in the script ?
I see no reason, why the %shellresult% is not put into the @myencodedsourceworkstring@
in debug, after execute og line 93 the var @MYENCODEDSRCWS@ is empty
Then i added line 94 and set @MYENCODEDSRCWS@ explictly to %shellresult%

After this change my source is added to the list. But is it correct, that theres is no default source with priority 0
a choco source list on the agent also gives my added source only and not the default one with prio 0

PS C:\Users\Administrator> choco sources
Chocolatey v2.4.3
chocorepo - http://host.de:8080/nuget/chocopublic/ (Authenticated)| Priority 5|Bypass Proxy - False|Self-Service - False|Admin Only - False.

That is strange, and yes, I see odd things with CW all the time—things that should work but don’t. A partial reason for this isssue is that there are areas where we call script execute on a PowerShell process, and other areas where we write out the PowerShell script to a file and then execute the file as a shell execute command. Both do the same thing, but we’ve found that if we have to write variables out to a script, sometimes it works and sometimes it fails. Also, Execute script runs a different PowerShell instance, so importing modules and installing modules can be a real pain.

Your fix is valid, and I will add this to our scope.

Regarding "Using Sources"
If you choose to use other sources, you will need to define all sources you want to use. When using sources, we assume that the MSP wants to control all flows and will define the flows available (flow = repository).

To resolve your issue of wanting the default Chocolatey repository and a proxy repository:

Add the Chocolatey repository as “chocolatey” with a priority of 0 to the approved sources list.

Assign that source, along with any other source, to the agent, location, or client.

You can manually add unlimited sources to the source list, and you can assign one or more sources to any client, location, or agent.


And, Thus the loop we have been debugging. That loop, loops through all assigned sources to agent and adds all the sources assigned. Reason we declair the variables in the loop is to clear the values to blank after each cycle of loop.

sorry, but there is another problem.

It seems, that setting sources seems to work with my little change.

But if i in a client-> Computer right click -> Manage Agent Sources, it shows not the same as if i use
choco sources directly on the agent.
Which script is setting the database entries for the sources ?

When the system preforms a normal scan it also scans sources.

So a manual scan or the next automated scan should show all the agents currently applied sources.

When the system preforms a normal scan it also scans sources.

So a manual scan or the next automated scan should show all the agents currently applied sources.

-> sorry, but it does not work. i have agents where choco sources shows the correct 2 repos and
manage agent sources shows only one.

-> sorry, but it does not work. i have agents where choco sources shows the correct 2 repos and
manage agent sources shows only one.

After a review of the script, you are correct. The source scan was in the wrong position in the script. We have several tests we perform to see if we need to perform a default source reset before moving on to package versioning functions. The source scan processes need to be performed before these tests, as the tests will send the thread to the version scans function after tests causing source scan to be skipped.

I have corrected this action in build 3.7.0.15.

Here is what that correction looks like, Moved lines in red above lines in green.

ok, that works, thanks

3.7.0.15 is shaping up to be a nice release when it gets pushed.

Fixed several things, updated a few things and am now using the new update logs table in mySQL. This is the first step in getting valuable reports in Chocolatey for Automate. Individual package update versions by date updated.



As you can see we have a typo in our logs, correcting that. (This is why we test and test again...)