everyone. If you don't want to read through it all, the question I have is: What would cause the Oracle 11g Client Installer to not install all of the registry keys properly? I'm not sure how specific this is to my environment, so I'll try to be as specific as I can and this first paragraph may not be relevant. If it's not, I apologize.
I'm installing the Administrative deployment of the Oracle 11g Client Installer, and after installing all of the 32/64-bit ODBC Drivers, testing the credentials, SunGard EAS 11.5, etc... I receive an error from EAS 11.5 telling me...
Lucky for me, that's me! The problem is that other people are already in EAS so obviously it's not a server failure, which, since every machine is Windows 10 r14393 64-bit, leads me to the only difference between the environments: The Registry.
During the installation, I change the REG_SZ insta_loc in HKLM\Software\Oracle\ from C:\Program Files\Oracle\Inventory to C:\Program Files (x86)\Oracle\Inventory so it installs correctly. In a good install, the following registry keys appear:
Lately, only the following keys have been appearing, when installed from either my Network (Admin) Account, or the local Administrator, over the network or locally from the HDD:
Can anyone help me figure out (or answer) why the Oracle Installer(s) would only install certain registry keys? I feel like the only thing that would interfere with an install is permissions, but I've tried the same two Admin accounts I've previously and successfully installed this on to no avail. Thanks!
I recreated one of the computers in a different group policy and the install worked. The original group policy I had them in was set to automatically install certain .MSI files, and I believe those files wrote to directories with the SYSTEM account instead of using User privileges which disallowed me from writing to the directories and creating the necessary keys.
Related
In my organization a project has begun to install SCCM on every computer. My job is to filter out computers which do not have SCCM installed on them (that part is done), find out why and try to install.
Unfortunately, I’m inexperienced with SCCM logs and find it hard to locate the problems (if there are any) and there is a huge number of devices I have to check all by myself and accessing each computer’s C$ will take years.
The OS of the problematic computers are Windows 10/7/XP/Server 2016.
Can anyone help me with these issues please?
Thanks in advance
The client install logs on the local machine are here C:\Windows\ccmsetup\Logs. You could script something to pull the logs and dump on a network share.
You can pull the CMTrace.exe from the server install directory to read the logs.
They are most likely failing for the same reason, I would start with looking at the firewall and make sure WinRM is enabled.
There are 3 methods to installing the agent GPO, Login Script, or from the console.
When I tried to manually uninstall VMWare Workstation 14... It gives me this error...Windows installer Service Could Not Be Accessed .... I'm using corporate machine, could this possibly mean I have to contact my sys admins and have them remove it? Has anyone had this problem before and solved it?
I wasn't going to post this - I think I misunderstood your scenario - but here goes, maybe see if some ideas pop up:
A few questions:
Does this happen with other packages on the box as well?
Do you see the same problem with the VMWare package on other boxes?
Do co-workers - with similar login credentials and rights - see the same problem(s)?
Did you ask you system administrator what policies apply for the install / repair of MSI packages? Maybe group policy blocks them? Is this a package you downloaded yourself, or is it "blessed" by a sys-admin?
Do you know if this is a 32-bit or 64-bit package? Do you have a tool to open the MSI? If you got Orca - open the MSI and go to View => Summary Information... - what does the Platform field say?
When things like this happens, you should generally first hit the vendor site looking for user forums, knowledge bases, support contact information etc... Unless you have a service agreement, in which case you should obviously just call them and enjoy some nice waiting music.
A quick search:
https://kb.vmware.com/s/article/2004136
https://kb.vmware.com/s/article/1031032 (for installations inside virtuals)
https://kb.vmware.com/s/article/1004802 (for installations inside virtuals)
Maybe try msiexec /regserver first - it seems to be the most harmless option. My guess is that this is a policy thing which locks the whole Windows Installer service from running. What security software do you have installed on the box?
A customer installing my companies software package has no problem installing the package silently when running as an admin account. The software and the service both install correctly and start up post installation. However - they need to push this application to all the computers in a particular group.
They are using SCCM (I do not know the version) and the software package is a InstallShield .exe packaged .msi.
When they try to use the NT Authority\System user to push the package to their test device, the installation fails soon after the 3rd party software package that is included completes. The error log displays that it is a SDDL error 1943. Any idea why this would occur on the NTA\System account and not on a local admin account for a given machine?
The silent install string we are using is setup.exe /s /v" /qn AgreeToLicense=Yes SetupType=Typical"
I'm not a dev, so I dont have direct access to any code in the software, simply a tier 3 tech support working with customers.
Sounds like your MSI is using the MsiLockPermissionsEx table to specify an SDDL string on some resource its installing or configuring (either file, directory, service or registry entry). Either the SDDL string is misconfigured (unlikely if it works from one account but not another) or the ACL on the target directory/service/registry key have become corrupted, which isn't completely unheard of.
You could try getting the customer to deploy a domain account as local admin to the computers and then set SCCM to run the package with this account. I wouldn't recommend this though as it carries inherent security risks of its own.
I'm afraid this may be one that your developers (or whoever created the MSI) need to work out with the customers to find out which resources are at fault and progress the diagnosis.
Sorry I couldn't be of further help.
I think I have found the issue. During install the .msi writes a file to the desktop to be read for configuration settings for the service as being installed. I had the file (and I am sure the customer did as well) already written to the desktop when I tried to invoke the System User for install. This does seem to be an ACL issue, in reference to the System User read/writing to a local user desktop. When the file was deleted, I received error 1406, that it could not write the value of a key. Looking on the desktop, the file had also never been written to the local desktop. When the file was already there (as such with a previous install) I get the error in the original post. At this point I am moving forward testing this as an ACL error and notifying the devs of my findings.
I've downloaded oracle 12c on my personal laptop. Check system compatibility (alls good). However, towards the end Im getting an error stating "Oracle Services for microsoft transaction server" denied".
Please assist,
Googling the error message leads to this as the first result:
http://www.dba-oracle.com/t_ins_20802_oracle_services_for_microsoft_transaction_server_failed.htm
Which basically says to ignore the message and run the Database Configuration Assistant manually to finish configuring the database.
When an installation fails, you should check the installation log for more details.
In my case, the log file said "hostname too long", so I shortened the host name and was able to do a successful install.
I faced the same issue recently and it was regarding [INS-20802] Oracle Database Configuration Assistant failed error. I think the solution for it will of help in your issue too.
I tried several of the following methods for resolving the issue :-
Disabling Windows UAC
Disabling firewall
Disabling antivirus - mine was a fresh VM, so disabled Windows Defender
Adding localhost IP i.e., 127.0.0.1 to the hosts file etc.
but none of them helped.
At last I found this, which suggested installing Microsoft Visual C++ 2010 Redistributable Package (x86) and this solved the problem in a matter of seconds! I just had to click 'Retry' on the installation dialog.
Do you have local "Admininstrator" rights on the account that your are installing Oracle into?
The Oracle Universal Installer is trying to create the MTS service and access is being denied. This is why I usually don't take the default install, and use the "custom" install and select the components I want. OUI will then work out the dependencies and install the correct components.
With this type of failure, you should have had an option to "ignore/skip" the error and the installer should continue and install the database objects - you shouldn't need to re-install the database objects as the the MTS service component should install after the data objects are created and they are not reliant on each other. Unfortunately the installer status will still show "failed" because of that one component failing.
I'm trying to use this Visual Studio extension for 2013, which recreates the built-in installer functionality from Visual Studio 2008/2010: http://blogs.msdn.com/b/visualstudio/archive/2014/04/17/visual-studio-installer-projects-extension.aspx?CommentPosted=true&PageIndex=2#comments
It works, allowing me to edit the project as before. It has the install and uninstall commands when right-clicking the install project, too. It installs fine.
When I try to uninstall, though, I get the following error and then the uninstall rolls back:
Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Wow6432Node\Microsoft\
EAPSIMMethods\18\FastReauthContext. Verify that you have sufficient
access to that key, or contact your support personnel.
I am not doing anything with that registry key, and there don't seem to be any relevant results on google-- at least not in the normal top 5 pages. Does anyone know what causes this or how I can fix it?
While I am not able to uninstall, I am able to increment the version of the package and allow it to remove the previous install and install the new version (all at once) successfully.
I am using Windows 8.1 Pro 64 bit, the projects are compiled for <AnyCPU>, and the installer is configured for x86.
EDIT I am running Visual Studio as Admin. When uninstalling from the Control Panel, I am also clicking the 'allow' button in the UAC dialog window that pops up.
I know how to give myself access to a registry key (permissions). I want to know why this key is trying to be removed. I support this app on several machines and I don't want to have worry about remembering an uninstall hack in the future.
EDIT This only seems to be an issue for a 32x installer on a 64x OS or a Windows 8 issue. I was able to use the same 32x installer to successfully uninstall the app on a 32x Windows 7 machine.
This must be an environmental problem, that key doesn't have anything to do with installers. EAP-SIM is an authentication protocol for wireless networks. The FastReauthContext key almost surely was meant to avoid having to provide a username+password each time your machine reconnects to the network. Which makes the registry key content very sensitive of course, it can only be read by a service that runs with the System account.
So, something goofy going on with your networking setup. Verify that you can successfully reconnect to such a network. If you used a VPN before then make sure it is active again. Something like this. Update your question with anything that might be relevant to networking when you first installed the app.
I have had similar problem and what I found out this is caused by MSI attempting to delete whole "Software\Microsoft" section in the registry. Lucky you that it encounters this error and rolls everything back.
So the solution is the following:
Since you have installed your program whenever you try to uninstall it the system will run msi from cache that is usually located C:\Windows\Installer.
Find your package in the cache. Here is an article that may help you http://csi-windows.com/blog/all/27-csi-news-general/334-identifying-cached-msi-packages-in-cwindowsinstaller-without-opening-them
Open the package in Orca. You must do this as administrator.
Go to Registry table and find record with "Software\Microsoft" as a key. Most likely the Name column will contain either "-" or "*" value. This means that during uninstall MSI will try to delete whole "Software\Microsoft".
Either change the Name value to empty or "+" or try to change key to something like "Microsoft". The second option will cause that installer will not find the key to delete during uninstall, but it will skip this error and let you uninstall your program.
You installed an untested installer on your dev machine? Speaking from experience, don't do that! Snapshotted VM's are cheap and will save you from this sort of pain.
Visual Studio Deployment Projects (or VSI as it's now called ) is known for creating very poor quality installs. The combination of those two put you where you are today.
I would need to look at the full uninstall log and your MSI using ORCA to understand exactly what is going on. MSI Zap and a manual cleanup of resources is probably required at this point.