Issue

• It may be required to repackage application data which results in an application getting a slightly different executable file, name, or version. 
• Sometimes it can even result in that the applications getting a completely different executable file or name. 
• When it comes to software recognition these changes can cause problems.

Solution

• The most important thing when it comes to repackaging data is to not make any changes to the executable file. 
• Our software recognition rules can handle that some data looks a bit different depending on the source, but some values need to remain constant in order for the right data to be picked up, see image.

• The example above shows the rule for "Adobe Acrobat Distiller 1".
• Here we allow the definitions for Name, Manufacturer, Language, and Version to differ.
• That is achieved by using the wildcard character %. However, the Executable Definition is not allowed to be anything else than acrodist.exe.
• The common rule is that we never use wildcard characters in the executable file for an application.
• In this case, if the executable file does not come as acrodist.exe, it most likely means that the file is not the main executable file for the application Adobe Acrobat Distiller 1.
• Even small changes can lead to bigger issues when it comes to repackaging.
• In the example, a small change such as referring to the application as "Distiller" or "Acrobat" would result in an inability to recognize the application properly.
• This would need to be rectified by sending in a ticket to Support for the Data Intelligence Service (DIS) to update the rules for the application.