Disclaimer:Yes, security fanatics may not approve of this (but, hey, they would probably never really approve of anything, anyway). However, for most pragmatists, this is a feasible solution with acceptable risk to an elevated credentials problem.
Cisco requires the user context for the execution of CiscoJabberSetup.msi to have local administrator privileges on the computer where it is to be installed:
This is a one-time problem for the initial installation, which must be performed by administrators.
It is also a recurring problem because the Cisco-provided update mechanism (using configuration settings in jabber-config.xml and jabber-update.xml) prompts for elevated credentials if the user doesn't have them.
This challenge has remained unchanged for many years, so it stands to reason that Cisco is not inclined to improve this installation/update approach. The usually recommended solution to apply software installation settings via a Group Policy Object (GPO) poses additional challenges:
The CiscoJabberSetup.msi file is multi-language. Since no command-line switch can be supplied via the GPO software installation, it must be run through an Orca transformation to eliminate all but the desired language code (for us that's "1033" for US English) to match the local settings. Extra step, extra work, no good.
Speaking of no command-line switches when using the GPO software installation preference... CiscoJabberSetup.msi actually has a lot of extremely useful ones, so using another mechanism would expand the available installation features greatly.
Wrapping the CiscoJabberSetup.msi execution into msiexec.exe (instead of the crude "double-click" installation method) provides yet more command-line options for the installation or upgrade.
Finally, GPO software installation policies do not have a mechanism to test for up-to-date existing installations, outdated older existing installations, or missing installations of Cisco Jabber, and can therefore not provide different actions based on individual scenarios. In our case, for example, we want first-time installations to be performed manually by administrators. Once installed, we want upgrades to newer versions to be hands-off. However, we do not want the upgrade mechanism to perform fresh installations if Cisco Jabber doesn't already exist locally.
Using a Powershell logon script GPO we can check all the boxes:
Analyze the provided Cisco Jabber software package to determine the new version code.
Analyze the local registry to find the version code of a potentially existing installation of Cisco Jabber.
Decide under which conditions to proceed with the installation.
Retrieve securely stored admin credentials.
Execute the Windows Installer with desirable options.
Continue/exit without waiting for the installation to complete.
There are complex methods available to actually retrieve database parameter information directly from the MSI file. A much simpler method is to take advantage of Cisco's consistent use of the README_install.txt file that is part of the package. Simply searching for a pattern will get us the new version number.
The HKLM:\Software hive of the local registry contains a key with values for "DisplayName" and "DisplayVersion" for Cisco Jabber if it is already installed.
Match up the desired conditions for installation to proceed. In our case, we want an installation object with "DisplayName" equal to "Cisco Jabber" to exist. If it does exist then we want the "DisplayVersion" of that object to not be equal to the new version determined in Step 1 in order for the installation to proceed (upgrade only, no fresh install).
Securely storing an admin password for use on any computer in advance is the interesting part. The trick is to first create an encryption key, use that encryption key to convert the interactively retrieved password string and store it in a file, and finally to put that encrypted password file together with the key in your staging location.
Now the Windows Installer msiexec.exe can be launched with admin credentials. An added benefit is that we can avoid an Orca transform by providing multiple application arguments for the CiscoJabberSetup.msi file itself (in our case that's "CLEAR=1 LANGUAGE=1033 AUTOMATIC_SIGN_IN=true RESET_JABBER=1") and also for the msiexec.exe file (here we use "/passive /norestart").
Powershell starts a new process for this, so the script can exit without having to wait for the installation to complete.
Putting it all together:
Provide a network share that is accessible by the users (read/execute for share, folder, files - if lower then make sure users can traverse down the folder hierarchy).
Download the latest Jabber for Windows package from Cisco and extract the CiscoJabberSetup.msi and README_install.txt files.
Un-comment, modify, and run the special code section of the Powershell script (lines 47-54) just once, then comment or delete this section from the script. This will create the encrypted key and password files AES.key and adminpwd.txt. Do not allow this part of the script to execute as part of the user policy GPO!
Modify the folder/file paths in the script according to your environment, and then stage all 5 files in the network share: CiscoJabberSetup.msi README_install.txt AES.key adminpwd.txt UpdateCiscoJabber.ps1
Create and link a simple GPO in your domain with a user policy to launch UpdateCiscoJabber.ps1 as a Powershell logon script. Alternatively, if you have many users logging on with cached credentials (such as before manually connecting to your domain network via VPN, for example) then create and link a simple GPO with a task scheduler definition to launch this script X minutes after logon (implying that by then they will have connected to the domain network via VPN) - make sure to add execution policy parameters to the command line as required for your environment.
Simply overwrite your existing version of the CiscoJabberSetup.msi and README_install.txt files in your network share with the latest version you have obtained from Cisco. The next time users log on, the script will find mismatched versions and perform an upgrade. Take a quick peek at the new README_install.txt file to make sure that Cisco hasn't thrown a wrench into things - adjust the pattern and substring search (lines 17-18) if needed. This hasn't happened in a very long time but you never know.
As always, this is a best-effort document only - test and use at your own risk... free but no warranties.
I want to change my CUCM 12.5 cluster to mixed mode. Cisco Doc says we need to have " Export-controlled Functionalityallowed" in the token when we generate from smart account. I can see no such option in my smart account. How can I get it?
Hi All, We are getting outbound international calls failed with dest cause code 127, when made via Jabber (12.7) while deskphone (majorly 7965) and CIPC calls are getting matured properly. Call Flow: Jabber > CUCM > SIP Trunk > ISP (SBC...
On our one of the client-side, all the users faced a call transfer issue over a weekend.Now this reflects in the call reporting as well.The reports below details given that, calls to operator queues on 5/30/2020 from 12:00A Saturday to 12:00A Sunday....
Hi there, sorry if this has been answered I was not able to find exactly what I was looking for. We have a single CUCM cluster on version 12.5 with the servers defined by FQDN in system > server.7800 and 8800 phones. I was curious if we have ...
From the perspective of an external user on the internet who is provided with a web link to join a CMS space as a webrtc guest. On clicking the link they are resolving a DNS A record that resolves to several expressway servers (cluster) Generally spe...