-2

I want to configure Cisco Jabber and enable the function of the PickupGroup and HuntGroup in Cisco Jabber. For this I have to adapt an xml file (jabber-config-defaults.xml) in C:\Program Files(x86)\Cisco Systems\Cisco Jabber. I have to paste this piece of code

<userConfig name="EnableCallPickup" value="True"/>
<userConfig name="EnableHuntGroup" value="True"/>

But this subsequent adaptation of the xml file should be made unnecessary. For this I have to use a msi editor z.b. ms orca or pantaray superorca and change parameter(s).

Q: Which parameter(s) I have to change in the MSI-Editor to enable PickupGroup and HuntGroup and not have to adapt the xml-file after installation?

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Niki
  • 17
  • 4
  • The issue with the question is that it is not related to development, but to configuring Cisco's MSI file. Apart from that, the Xml file will most likely be inside a CAB file embedded inside the MSI file, and that's not something that a MSI editor such as Orca can change. Note also that if Cisco has certificate signed their MSI file then altering it will destroy that cert sign check - you're basically hacking another company's signed MSI file, and that's rather tricky. – PhilDW Jun 07 '18 at 23:55

1 Answers1

0

UPDATE: After reviewing the answer below, I want to add some more general comments on software deployment. This is an important topic for your own software as well. Understanding what corporate deployment needs can help you make software that is better accepted in corporate settings - very important!

  • Check for deployment tips in a database online. You can often find help here: https://www.itninja.com/software-library (hints for deployment of various software). In this case (sample deployment db entries): 1, 2, 3.

  • Check with the vendor. Check if there is a document for administrators available with regards to deployment on the vendor site - or give their support department a call. There is often advice or recommendations in such documents with hints on how to best deploy the software. It could be as simple as setting a few PUBLIC properties instead of creating a complex XML file.

  • Check with the packaging / deployment team. Most large companies have people specializing in software deployment. Give them a call. They might even have a support agreement with the vendor.

Note! Not actual parameters, just a sample, check documentation:

 msiexec.exe /i YourPackage.msi ENABLECALLPICKUP=1 ENABLEHUNTGROUP=1

The following answer tries to explain customization of MSI installations in some detail - PUBLIC PROPERTIES, transforms, and more: How to make better use of MSI files.

Getting It Done: Without the actual MSI it is always hard to say what the best approach would be. One of the easier approaches - in my opinion, and if you are doing a corporate package - is to make an admin image of your package. Not the best approach technically, but it usually gets the job done:

 msiexec.exe /a YourPackage.msi

Then select an extraction folder for your setup interactively. Alternatively, if there is no GUI, specify an output path in your extraction command:

 msiexec.exe /a YourPackage.msi TARGETDIR=C:\MyExtractedFiles

If the MSI is wrapped in an EXE file, please try this rather messy answer: Extract MSI from EXE.

Now you can find the XML in question in the extracted files, and you can "hotfix" the content of the file - provided it actually exists on disk. Then you run the install on your workstations from the admin image you have created - via SCCM or some other deployment mechanism.

Generated XML: It is also possible that there is no XML file in the extract, but that it is written by a custom action or a third party XML writing mechanism (for example from WiX, Installshield, Advanced Installer, etc...). There is no way for me to tell without the MSI. Then you need to update custom tables in the MSI to set the settings in question, or in the case of a home-grown custom action from the vendor, post-process the file written with your own custom action. This can take quite a while. You might be able to use WiX to do the post processing, but this is not entirely trivial to tweak.

Upgrade Warning: When you "hotfix" the XML file to install, you should be aware that it is not that easy to overwrite it on upgrades. It is technically better to convert the XML file entries to WiX XML update statements (or equivalent in other deployment tools), since this allows you to "pinpoint" changes in the file with accuracy without worrying about file-overwrite scenarios (which can be hard to work out). Essentially: files with different modify and change dates will not be overwritten by Windows Installer by default (this is a long story with lots of surprises to deal with).

Major Upgrade Only: If you use major upgrades to upgrade your application, and you fully uninstall your old version before installing the new one (early placement of RemoveExistingProducts in the InstallExecuteSequence), then you will generally not see any problems overwriting the settings with new ones as changes are wiped out - removed - on uninstall, and the default content is installed fresh (reverted, not overwritten) - which is actually a common problem for people when they don't expect this behavior. Will the config file be changed by the user after installation - in a way you want to preserve?

More on administative installations:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164