Support Forum

bmcfarlane wrote: ↑Thu Apr 16, 2020 4:51 pm Yeah I was thinking about this more and I think doing an EDF like you have for the POSH stuff at the location level as well would really help as if someone deploys and agent that we don't want to 3rd party patch it would be a manual change to block it at the computer level but if the location already had the Do not install 3rd party updates via Habitat EDF in place it would default to the right setting for the location.

JVDMAAT would you agree with BMCfarlane that an EDF would satisfy your needs aswell?

Yes, an EDF would probably suffice. (If not long term, it'll be a quick-fix for now).

Can I have my cake and eat it? And make the EDF "Don't auto-deploy 3rd party updates"? (ie, still allow the systems to be scanned. (and thus easily reported on), and through that also allowing manual deployment from the Client level for the occasional one that can/needs to be upgraded.

Yes sir...

I am working on this for release 1.0.0.39, We just released 1.0.0.38 today which added other functionality and I didn't want to mix more eggs into the batter..

The first version of this is coming out in build 1.0.0.40

An EDF at the location level will cause the agents in that location to excluded from updates.

I am working on an issue where we can still version them in some manor.

The issues with this are that for us to get accurate versions we still need chocolatey installed and we need to sidestep any associations as well as any updates. There may be some future tweaking needed..

I have version 1.0.0.41 of the Habitat Plugin. I had to modify line 9 of the script in order for chocolatey to install. It said IF FILE Exists when it should have been IF File not Exists. Then I had to put "C:\Documents and Settings\All Users\Application Data\chocolatey\choco.exe" in quotes.

When I finally got the chocolatey install to work on a few machines I ended up getting a 429 error during the chocolately install (Too many requests from the remote server). Is there a better way to install chocolately for an environment with over 1600 agents?

Thanks

Hmmm... I wonder how that changed? fat fingers I say...

We have found and updated the script for 1.0.0.42

I really am not trying to be negative but it concerns me a bit when QC issues have happened multiple times in this module and it automatically rolls out to a large number of our clients. Could you share your practice about how you are testing these updates so that issues like the ones that have been pointed out are caught before release?

I have to answer to my clients if things go wrong and I think it is good due diligence to understand how the scripting is QC'd.

I notice repo version is saying none on mine. How do I set the repo version?

bmcfarlane wrote: ↑Mon May 11, 2020 11:45 pm I really am not trying to be negative but it concerns me a bit when QC issues have happened multiple times in this module and it automatically rolls out to a large number of our clients. Could you share your practice about how you are testing these updates so that issues like the ones that have been pointed out are caught before release?

I have to answer to my clients if things go wrong and I think it is good due diligence to understand how the scripting is QC'd.

This is fully understandable. P4A was founded and is operated by Shannon Anderson with the help and support of a few fellow Automate systems engineers that assist in the design and testing of the different plugins we create. Most of the tools you see in Habitat have spent years being harden before they make it to Habitat. Once in Habitat they are set on a schedule to be improved and combined to work together with other plugin items.

There are times when we add in little extras and after a quick inspection of the data gets pushed out. You saw this in a simple log statement we placed in the script not to long ago that because of the style of "goto" we used originally pushed back by one causing the last issue. Well during that fix I fat fingered what was to be a very simple fix causing issue number 2. It this was a change in the plugin that had been significant or the ability to have wide spread changes, it would not been rushed to release but would go through our process of QC where it would be pushed to a secondary Automate host with active agents to verify compliance.

So to give you the short answer, We QC all major changes and additions for basic functionality and adverse effects but small typos and quick fixes do not always get as much time on the grinder. You wouldn't expect any adverse effects from changing a label or adding in a new link to data (non writer). We do take QC seriously and are very agile to changes needed in our processes.



Hope this answers your questions on QC