Application of packets from near to far

Share your tips or issues concerning the WAPT Console or WAPT Agent here
Forum Rules
Community Forum Rules
* English support on www.reddit.com/r/wapt
* French community support is available on this forum
* Please prefix the topic title with [RESOLVED] if it is resolved.
* Please do not edit a topic that is tagged [RESOLVED]. Open a new topic referencing the old one.
* Specify the installed WAPT version, full version, and build number (2.2.1.11957 / 2.2.2.12337 / etc.) as well as the Enterprise/Discovery edition.
* Versions 1.8.2 and earlier are no longer supported. The only questions accepted regarding version 1.8.2 are related to upgrading to a supported version (2.1, 2.2, etc.).
* Specify the server OS (Linux/Windows) and version (Debian Buster/Bullseye - CentOS 7 - Windows Server 2012/2016/2019).
* Specify the OS of the administration/package creation machine and the machine with the problematic agent, if applicable (Windows 7/10/11/Debian 11/etc.).
* Avoid asking multiple questions when opening a topic, otherwise it may be ignored. If there are multiple topics, open separate topics, preferably one after the other and not all at the same time (i.e., do not spam the forum).
* Include code snippets, screenshots, and other images directly in the post. Links to Pastebin, Bitly, and other third-party sites will be systematically removed.
* As with any community forum, support is provided voluntarily by members. If you require commercial support, you can contact Tranquil IT's sales department at 02.40.97.57.55
Answer
vnatton
Messages: 6
Registration: January 9, 2024 - 1:53 PM

March 13, 2024 - 12:01

Good morning,

Yes, the title is unclear, but I didn't know how to phrase it briefly.

I was wondering if it was possible to apply packages with a "from near to far" priority order without the far-flung configuration overwriting the near-flung configuration?

Since this is still not clear, let me explain:
I have a package deployed across an entire OU, but I have one (or more) machines that are exceptions. Don't look at me sideways; we all have exceptions :P.
So I stupidly thought I'd just put the conflicting package on the machine. That was indeed stupid because it doesn't work. So here I am, asking if we could implement a "nearest to furthest" priority system for package application.

A concrete example:
I am installing Acrobat Reader across an entire OU, but some machines have a package of an older version of Acrobat Pro (which therefore does not depend on the same installer).
In my case, I could therefore put Acrobat Reader in conflict with my Acrobat Pro package without this generating errors or repeated uninstallation/reinstallation.
My current solution is to modify the Acrobat Reader package and put the exceptions there, which is ugly and not very sustainable...

Code: Select all

if already_installed == True:
  if installed_version =="{AC76BA86-1033-FFFF-7760-0E0F06755100}":
    print("Acrobat 2015")
  elif installed_version == '{AC76BA86-1033-FFFF-7760-0E1401753200}':
    print("Acrobat 2017")
  elif installed_version =='{AC76BA86-1033-FFFF-7760-0E1401753200}':
    print("Acrobat 2020")
  elif installed_version == '{AC76BA86-1033-FF00-7760-BC15014EA700}':
    print("Reader DC ou Acrobat DC")
  return "OK"
else:
  return "WARNING"
 
I certainly haven't considered all the ins and outs of such a modification, but since there are many of us here, I'm sure I'll find someone with a head fuller than mine.

Thank you for your feedback
Good day
Benoit
Messages: 43
Registration: June 26, 2023 - 11:52
Location: Tarbes

March 27, 2024 - 11:04

Hello,

I went through the same thought process, so I'm very curious to get an answer to this question.

Regards,
User avatar
dcardon
WAPT Expert
Messages: 1930
Registration: June 18, 2014 - 09:58
Location: Saint Sébastien sur Loire
Contact :

March 28, 2024 - 7:05 PM

Hello Vianney and Benoit,

this is a question that comes up quite regularly.

One possibility is to assign a "meta-package" to the OU that installs the corresponding Adobe package based on criteria you define.

Another possibility is to put the workstations in a different OU that doesn't inherit the same things.

If the issue arises due to support problems with different OS versions, it's possible to have several versions running in parallel and adjust the OS versions in the package's control file.

You could also look at Profile packages, which are based on Active Directory groups.

We'll discuss internally the scenario mentioned by Vianney and see how we could modify the dependency calculation engine, if possible. However, adding complexity at this level isn't always a good idea, as we can see with GPOs and inheritance blocking; in the end, we no longer understand why a GPO is applied or not...

Best regards,

Denis
Denis Cardon - Tranquil IT
Share your experiences on WAPT! Send us your blog and article URLs in the "Your Opinion of the forum, and we'll feature them on the WAPT
vnatton
Messages: 6
Registration: January 9, 2024 - 1:53 PM

April 2, 2024 - 11:41

Hello Denis,

I completely understand that a change like this wouldn't be insignificant.
Couldn't it be made "enabled" (this doesn't eliminate the "sensitive" aspect of such a change)?

I'm already working with a "core application" meta-package which includes the Acrobat Reader package, and since the "AcroPro" package is applied per machine, this causes an error with "AcroReader".
I wanted to avoid managing additional AD groups, which in my opinion aren't very user-friendly for colleagues who haven't implemented the solution.

Basically, the current solution for my situation would be to make the Reader package conflict with the "Acrobat Pro xxxx" AD groups and Acrobat Pro versions with the corresponding AD group as dependencies.

Have a good day and thank you for your response and for listening,
Vianney
Answer