Like a lot of other applications out there the BlueJeans Desktop App MSI comes in two flavours: Per User MSI & Per Machine MSI.
Today, it is possible to have both installed on the same machine, but I have an increasing number of customers who have users with both installed and want to be able to clean it up. I have put together a cleanup script that handles uninstalling our application, but what I need to know from the community is whether I should utilize PowerShell to connect to each machine and run the script remotely or deploy the script via SCCM, IBM BigFix etc. to each machine and run the script locally?
A copy of my script can be found here: https://github.com/stuartminch/powershell/blob/master/cleanup_utility.ps1
If you have two separate MSI installers (User MSI & Per Machine MSI) the easiest way would be to use MSI {GUID} to uninstall them.
example msiexec.exe /x {GUID} /q
If you have them installed on a machine you can find uninstall string with GUID under
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{GUID}\UninstallString
You can then configure it in SCCM.
Best practice would be to configure the deployment along with uninstall so if you deployed it through SCCM just add Uninstall commands there.
Related
I'm having trouble with installing PowerShell 5 on Windows Server 2012 R2 using Packer.
To install PowerShell 5.1, I'm using chocolatey
powershell
iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex
choco install PowerShell -y
I need to to do this for two packer builder:
Amazon Web Services EC2 AMI.
Hyper-V Vagrant.
With the Amazon Web Services EC2 AMI I've tried executing the above from the following locations
As part of the user_data_file script.
As an inline provision script.
I've added the windows-restart provision in the flow after the execution of the fragment.
Similarly I've tried the same with the Hyper-V Vagrant both as part of the Autounattend flow and as an inline provision.
In both cases the installation fails because the user profile is not created. At least I think that is the problem. As a reference, I've faced the exact same problem when installing sql server express.
Has anyone managed to accomplish this flow and what is your recommendation?
PowerShell package uses MSU (Windows Update file). There are a couple of considerations here:
Ensure Windows Updates Service is turned on. Chocolatey doesn't do that yet, although there is an issue filed.
MSUs must be run locally from the machine. So if you are running over WinRM, you instead need to have it set up a scheduled task to call choco install and then run it that way.
Yes, that second point is accurate. No, it is not Chocolatey's fault. That's a Microsoft design decision with MSU files. It's a real PITA.
FYI - BoxStarter handles it appropriately, and it can be used with Packer. You will find less pain if you look there.
HTH
Install4J stores a registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\ej-technologies\allinstdirs* in windows when running an installer. Presumably it does something similar on Linux and MAC.
Is there a way to prevent this, and all other other permanent OS parameters, with a command line option? We run integration tests that actually run the installer and run then the application, but this then pollutes our registries, getting in the way of doing manual installations of the same application on our development machines.
As of 6.1, there no way to prevent this. I have added this to our issue tracker.
Few machines have 'MyApp.exe' installed using ClickOnce. And I have created a new MSI Windows Installer for 'MyApp.exe' using MS Visual Studio 2013 Setup and Deployment. I have a requirement that when my new MSI Installer runs it has to automatically remove/uninstall all previous 'MyApp.exe' (installed using ClickOnce) and install the new exe. Installer has to do it as part of its installation process.
Is this even possible? ClickOnce doesn't make any registry entries, so how can I get the Upgrade codes/Product codes which I can feed to Windows Installed 'Upgrade Paths' to upgrade it. ClickOnce is per user installation, but Windows Installer is not.
Is it even possible for Windows Installer to uninstall ClickOnce installed application ?
Any help is greatly appreciated. Thanks
ClickOnce is a per-user deployment experience and MSI is usually a per-machine experience. Per machine can't clean up other people's profiles. The only way I know is to do an active setup trick to run a program for each user who logs on and then execute a script to do cleanup. Either that or put first-run code in the applicaton itself to do the same.
We are having build environment where we did not use any tools like Cruise control , TFS or buildforge.
We are purely depend upon Msbuild and powershell. We decided to automate the deployment process.
As we are using VMWare ESXi to meet our Virtual machine needs. We decided to use VMWare powercli to automate deployment process.
After build is over , VMware powercli will revert the snapshot of VM to fresh state and we tried using Invoke-VMScript to do automated deployment.
But as our deployment has UI , this is nearly impossible as Powercli try to invoke UI in session 0 and it doesn't support UI application.
Does any body overcome this problem and installed your application successfully in Virtual machine?
I have some experience in the area. I use PowerCLI and Windows Remote to get the job done. I have a machine with VMWare snapshot where windows remoting is activated and configured and then I use PowerCLI to revert to snapshot and power the machine on and then I call Invoke-Command. Not sure if it will survive the UI thing, but worth a try. First make sure that you can execute your task from PowerShell and if yes - then windows remouting will most probably be able to do it as well. You can read how to configure Windows Remouting here:
http://amarchuk.blogspot.com/2011/10/windows-remoting-and-powershell.html
We have a large application that has been developed over 15 years and in installed in 200+ client locations. The application currently consists of an Access database and a bunch of executable and report files located on a network share. A Setup.EXE file is run on each client machine (dlls are installed on the client) and then the client machines run the executables directly from the network share. During our upgrade procedure the new executable and report files are copied to the network share and that way each client gets the update immediately.
Our current installation program is very old and, among other things, it doesn't handle x64 so we are in the process of moving to a new deployment tool. At the same time we are migrating client Access databases to SQL Server. I am having difficulty finding a deployment tool to do what we require. Specifically we need the install/upgrade file to do the following:
It must be able to be run from a client machine on a network and copy the new executable and report files to the network share. That share could be a Linux box or a dumb storage device.
Accept a password before running the installation
Allow the user to select the network share as the location to copy the executables
It must NOT add anything to the client machine from where the package is run (Add/Remove Programs, registry, etc.)
Connect to a SQL Server database and run a script
The install/upgrade must be contained in a single, standalone .msi or .exe file. (no dependencies on dlls or frameworks other than those that come with Windows XP)
The file must be able to be run in one simple step. It is the end user that runs the upgrade without our support and without involvement from IT.
It looks like the closest thing to what I need is WiX but the problem there is that whenever the .msi file is run from a client, the client machine thinks that a program is being installed so it allows the client machine to uninstall the product, which is not acceptable.
If the product were written today it would certainly be architected differently but it currently is what it is and we can’t change that. Any help here would be greatly appreciated!
WiX is just a toolset built on top of Windows Installer technology. It makes many things easier and simpler as well as hides lots of Windows Installer weird features... But, it is still limited by Windows Installer, its underlying technology.
Your list of requirements made me think that Windows Installer is not the right technology to choose. I would assume that you'll spend more time on workarounds, than on functional code... But I have no experience with other installation technologies, so I'll leave those recommendations to others.