I am trying to script the uninstallation of some MS Office programs, and I'm wondering if anyone can help me figure out how to find the ProductID code I will need to add to the xml file? I know that for Standard it is "standard" and for ProPlus it is "ProPlusR", but I also need to uninstall Home Business 2013 (might be Small Business 2013?), and I can't figure out what the ProductID needs to be. I have queried an installed version of it with powershell, but the "ProductID" property is always blank, so that doesn't help either.
So far, I have tried the following without success: HomeBus, HomeBusR, SmBus, SmBusR, Business, HomeBusiness, SmallBusiness, HomeBusinessRetail, SmallBusinessRetail.
The answer I would prefer, is how I can find this info myself, as I will likely have additional versions I need to script, but I appreciate whatever help anyone can provide.
Thanks,
Andrew
The uninstall command line of an installed application is recorded in Windows registry under the keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
The second key exists only on 64-bit Windows and is for 32-bit applications the same key as the first one, see Registry Keys Affected by WOW64.
The applications (products) installed with Microsoft Installer (MSI) are registered with their unique identifiers under registry key :
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products
Related
I'm a starting dev and this site helped me a lot so far, thought somebody could maybe help with this. I have a SSD with 16kb sectors and couldn't install SQL Server 2022, ran the offered command solutions (did a bunch of other things in between, install and uninstall etc).
Now I find myself completely unable to even access SQL from shell (and also unable to uninstall express duplicates). Does anyone perhaps know what I could've messed up ? Tried to find solution on the website (and else) and couldn't find my specific problem.
Thanks in advance for any help.
EDIT : just realized the screens are in french, my bad. The shell screen states that <sqllocaldb> isn't recognized as a command name or function etc. First (white) screenshot is of my services displaying how I can't start SQL with an error code.
For some reason I can't get SQL Server 2017 installed on my Windows 10 machine.
First thing to do with this buggy installer is that I had to uninstall VCRuntime 2017 in order for the installer to work.
And now, the installer is stuck at this point exactly every time I try to install it:
What I've tried so far:
Killing msiexec process
Running the setup with additional parameter as mentioned here
Setup.exe /SkipInstallerRunCheck
Restarting ... reinstalling ... turning off anti-virus ...
[Solved]
The problem was due to a background download that was taking forever especially on a low internet speed (i.e. python or R-support component).
[Solution]
If you really need python or R-support just wait until download is complete
Else, deselect python and R-support from the component list.
(or) kill the child process for python or R-support component downloader from task manager.
UPDATE:
The actual problem turned out to be the R-support component(s) slowly downloading in the background locking up the installation GUI
with no notification or warning show to the user as to what is
actually going on.
So it seems this "locked install problem" can be caused by installing several different components, at least by Python or R-support. As mentioned below, please check any available logs or event logs for clues.
In summary, options:
Maybe try to unselect such components for install if you do not need them.
If you need the components, leave the setup to complete, and check progress in log files as explained below. Verify Internet access (proxy?).
Stuck Download?
UPDATE: Did you see this blog? Looks like the setup tries to download and install the Python runtime, and this can take forever. Are you behind a proxy btw? No direct connection to the Internet? If so I suppose this could also cause further problems. Probably not the cause, but worth a mention.
Apparently you can check the following log file for progress for the installation:
%ProgramFiles%\Microsoft SQL Server\140\Setup
Bootstrap\Log\DATE_TIME\RSetup.log
DATE_TIME in the above path must be converted to your valid values. For example: 20170804_162723 (date part and time part).
See this answer as well: SQL server 2016 installation freeze. You could also try the suggestion to deselect all components you do not need to prevent any background downloads?
General Debugging
Leaving in the general purpose debugging suggestions below.
Generic Advice: From experience I would create a new local admin user and try to install using that account. This is to avoid any "unclean" or special conditions that have occurred in your user profile or registry during regular Windows use. Might not do much, but sometimes it gets the job done with surprising ease. Worth a try I think.
Some Further Things: I wrote up a little check list a while back, I'll add it and see if it inspires some new ideas that can help you. See under "Core Deployment Problems". That first "check list" was condensed from a longer and somewhat excessive first writeup - one of those answers that unintentionally turned into a blog and maybe a hard one to read.
Logging: Did you check log files and / or event logs properly for clues as to what is happening? I find the best approach for deployment to enable logging for all MSI installations. The performance hit it triggers is minuscule compared to the benefit of having a real log-file always available when you suddenly need one. You can enable logging for all MSI files as explained on installsite.org (section: "Globally for all setups on a machine"). MSI log files will then just sit in your %TEMP% folder after installation. They have a random hex name, and you can flush them all regularly if you do not need them. You sort by modify date / time to find the latest one(s) created - obviously.
Jedi trick: You will want to go home and re-think your life if you don't enable logging for all MSI files. Moral of the story: MSI log files are cool. They are very verbose, but they are beautiful. There are some hints on interpreting them here (bottom).
My 2 cents: SQL Server Installer consists of several small MSI installers. MSI installers can only be installed one after each other (as fas as I know). In my case, I launched another MSI setup while installing SQL Server. This caused SQL Server Setup to hold until I finished the concurrently running setup.
So, at least in my case the problem was self-made.
You have to remove configuration settings for SQL Server from Windows Registry editor.
Sql server
2017
VS
By the end of last week our central IT Department introduced SCCM and applied it to a bunch of clients in our division. My colleagues and I work as so called "IT-Partner" in a 1st level support for a few hundrets of colleagues. Now we're facing some problems with our new SCCM System (installed packages do not work etc.) Now we'd like to "reset" applications so the SCCM Agend will reinstall them. I've read something about the detection methods but unfortunatelly I do not really know how they work nor I know where those methods are saved. I want to "analyse" those methods so I know which file to modify / delete that the agent will reinstall the application.
By the way, how much time does SCCM take from "assigning" a package to applying to the client?
Assuming you only have the client and no access to the SCCM Console the detection methods can be found using WMI. They are stored in root\ccm\CIModels in the Class Local_Detect_Synclet.
The format is XML in one column and it is designed so that all kinds of detection methods can basically be represented in the same style so it's not very readable but you should be able to get some basic understanding about the detection method used.
Keep in mind this is only true if the software was deployed in the "new" (introduced in sccm 2012) application format and not for the "old" package/program format.
If you want more detail I once tried to automate the process of triggering a reinstall for any given application but ultimately failed due to problems with the chache/distribution point. I posted all my findings here.
So from an application POV. When you deploy an app the detection method is setup in SCCM to determine wether or not the application installed successfully. This detection method could be configured a variety of ways. For example, it could check to see if the msi code is installed to determine success, it could check the .exe and compare it to a specific version, or even check a registry file for existence. In order to change/modify these detection methods you should be an SCCM admin and be able to login to the console. From there you would select the specific application or package you want to analyze and click through the properties of the deployment.
Running Windows 10, Visual Studio Community 2015, and SQL Server 2014 Express. I also have .Net 3.5, 4.0, 4.5 installed.
My SqlDataConnection is throwing the compile time error "The type provider 'Microsoft.FSharp...' ... Error reading schema. The .NET SDK 4.0 or 4.5 tools could not be found". Searching for solutions I got directed to some registry keys.
In
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows
I have two keys: \v8.0A and \v8.1A. (I didn't have a key for any v7.xxx) I got to these keys from one online answer to this issue. Each of those keys has three keys under it: WinSDK-NetFx...Tools. For v8.0A the ellipses are "35" and for v8.1A they are "40". Plus each key is repeated with + "-x64" and + "-x86".
These six keys all have string values of "InstallationFolder" (as well as "ComponentName" and "ProductVersion").
I go to the installation folders, and each one has ResGen.exe and SqlMetal.exe (which are the files other answers said to look for). So it seems like I have the requisite registry keys which point to the requisite exe's.
Next to the installation folders for v7.0A and v8.1A, I also have one for v10.0A. So I tried creating some additional registry keys named v10.0A. In those v10.0A keys I tried putting the v10.0A folder as the InstallationFolder and I also tried putting the v8.1A folder as the installationFolder. (One reason I tried this permutation is because the error message asks for SDK 4.0 or 4.5, whereas the v10.0A folder has NETFX 4.6 Tools. So I tried to resolve possible inconsistency between v4.5 and v4.6 by varying the registry keys under v10.0A and using the path to v4.5 in the v8.1A folder.)
I've probably gone on too long trying to give the pertinent info. But I have the most current software installed and updated, and I"m trying to follow previous solutions given. And I'm stuck. Maybe all the newest versions aren't yet gotten tied together with each other?
Any help appreciated much.
Edit: Doing some more web searching, I'm now finding more fixes with more details. This one in particular looks very promising:
Need clarification regarding Microsoft.FSharp.Data.TypeProviders
But I won't get to work on it until the end of today. So that link may be my answer, but I can't confirm for a bit.
Worth checking you are using the nuget version of the F# type providers. The version bundled with the framework does not have the fix applied that extends the list of registry keys searched to cope with later versions of the SDK (as would be installed on Windows 10)
https://github.com/fsprojects/FSharp.Data.TypeProviders/issues/21#issuecomment-337444919
apologies in advance, I am still an Installshield newbie!
I am currently using installsheild 2010 for an isntall packed for my application (ds2). My trouble is I need to remove a previous incarnation of that project which was created with an installshield 2008 as a merge module (ds1), not a installer in its own right.
So the old version (ds1) is currently lacking in upgrade code etc, and only has access to a Product Version and Package code.
The new program has the usuall Upgrade, package, product codes (ds2).
Is there anyway to either associate the old product mergeModule to the new application so it can be uninstalled as a 'previous version'. Or is there another method where i can ask installshield to "remove anything with product code xxxxxxxx"
I hope that's clear enough for a response!
Thanks in advance
UpgradeCode is only needed for FindRelatedProducts to determine the ProductCode. RemoveExistingProducts uses that ProductCode to do the removal.
You can author a Major Upgrde based on a fake UpgradeCode knowing that it won't find anything. Then you can use a Type 51 Set Property custom action to assign the known ProductCode to the ActionProperty used by the Major Upgrade rule. Then RemoveExistingProducts will come by and uninstall that product.