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.
When installing Oracle 12c personal edition on a freshly minted Windows8.1 box I get the following error:
Title: Database Configuration ...
Error in Process:
C:\app\<username>\product\12.1.0\dbhome_1\perl\bin\perl.exe
Clicking ok and skipping gives the following error
[INS-20802] Oracle Database Configuration Assistant failed.
Details: The plug-in failed in its perform method ...
Trying lots of things but still come up with same error. Googling shows some users with the same error, but all end in dead-ends without a solution.
Any help much appreciated.
I had the same problem with Oracle Database 12c on a fresh Windows 8.1.
For me the solutions was deactivating a preinstalled McAfee.
I used the Windows-builtin-User during the Oracle-Database Installation.
Think this may be it. The new Windows user for the account was oracle-user. When I tried this with a username OracleUser the installation worked.
I also switched off the AntiVirus - not sure which fixed the problem
A colleague pointed me to this blog which gave a little more info.
Hope this helps someone
The issue is because of the Anti-virus program most probably McAfee. If you want complete instructions check this out - It is an explanation of the step by step installation process specifically on windows 8.1 and the perl.exe error
While installing my msi i get the follwing error
Error 1935. An error occurred during the installation of assembly component {98CB24AD-52FB-DB5F-A01F-C8B3B9A1E18E}. HRESULT: 0x800736B3. assembly interface: IAssemblyCacheItem, function: Commit, assembly name: Microsoft.VC80.CRT,type="win32",version="8.0.50727.42",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"
I do carry Microsoft_VC80_CRT_x86.msm in my MSI. But the problem is that i do not see this issue in all machines. This is faced only on a 2012 Windows Virtual machine.
Can anyone please tell me why this error would normally come?
I think you have a corrupted windows O/S. Otherwise it is correct to test on VM's configured with a variety of virgin operating systems that you want to support. Additionally I highly advise to never use this merge module. Instead using a bootstrapper/chainer (WiX Burn, InstallShield Setup Prereqs or Suite Installation ) to install the stand alone versions of the redist from Microsoft. This helps draw a line in the sand between a Microsoft problem and a problem with your installer. It also makes upgrade servicing easier.
I got the same error message on windows 7 (32bit).
This was caused by a failure in windows update for my case.
After that, I cannot install any other program on the computer. I searched from internet and found suggestions made by Microsoft engineers: repair the system from Original Installation disc with "update to latest" choice unchecked.
However, I found another simple solution which also works for my case.
1． Click START>> and type “regedit” to run register editor;
2． Find the following directory in register: HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control;
3． search by F3 for the key RegistrySizeLimit and double click the DWORD;
4． Change the key value into ffffffff(Hex) or decimal 4294967295, then click OK;
5． restart the computer;
6． run cmd.exe with Administrator's privilege, and type SFC /SCANNOW followed by Enter in command line; this scanning may take several minutes until the status is 100% and finishes;
Then the problem can be fixed!!
I got this error in my Win7x64 VM after I installed .NET Framework 4.5 required by my MSI. I had a fresh OS install with no Windows updates, plus VS2005 SP1. I ran this Microsoft FixIt: http://support.microsoft.com/kb/976982/en-us, but it did not help until I restarted the VM. Once I restarted the VM, the error disappeared. I think all I needed was a restart, but I provide the above details in case it was the FixIt that actually fixed it.
On a windows 2016 server, I solved the problem by resetting DCOM security to default
launch dcomcnfg
then set Default Authentication Level to Connect
and Default Impersonation Level to Identify
I suddenly cannot start IIS anymore on my Windows 2008 R2 server. The depending "Windows Actication Service" does not start.
In the Event Viewer I can see the following message:
"The Windows Process Activation Service failed to generate an application pool config file"
I've checked all IIS config files for typo's, none can be found.
I've tried to remove the IIS role from the server, which results in an error.
I'm totally desperate here. I've looked on Google for several hours, but none of the suggestions I've found helped.
Something has messed up permissions and the user account under which WAS runs does not have permission to create its working files. Probably you installed a service pack or similar.
Rebuild the box and apply all service packs to Windows before you install WAS, and then let it update itself and then install your own stuff.
Rebuilding boxes is no fun and takes far too long. Learn to use virtualisation and undo disks.
If you have another working server, you can import IIS configuration from there via Shared Configuration. I was able to resolve this error by doing so.
This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):
LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.". in light.exe(0, 0)
The FAQ is now deleted, however, the text from it said:
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Additionally, these are the errors that show up in the event log:
MSIInstaller: Failed to connect to server. Error: 0x80070005
Product: [ProductName] -- Error 1719. The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.
Intuitively:
VBScript and JScript were registered under admin.
Integration service has permissions for the desktop interaction and all the files
Builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)
I'm out of ideas so far.
How do I solve this problem while keeping ICE validation?
End of the story:
After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.
To disable ICE validation you can set SuppressValidation to true in the .wixproj file:
<PropertyGroup>
<SuppressValidation>true</SuppressValidation>
</PropertyGroup>
Or pass the -sval command line option to light.exe.
Adding the TFS build controller account to local admin group and restarting the windows service did the job for me.
I found the root cause. I tried everything I found, including custom validator extension similar to one posted in Re: [WiX-users] light.exe failed randomly when running ICEs..
It's not a concurrency issue as suggested in various threads. It's caused by a too large Process Environment Block (PEB).
It turns out Windows Installer can’t handle a process environment block larger than 32 kB. In my environment, due to number of variables set by the build system and their size (for example, PATH variable containing multiple duplicated values), PEB was about 34 kB.
Interestingly, per Environment Variables, Windows XP and 2003 had a hard limit of PEB set to 32 kilobytes. That would probably cause an easy-to-catch build break in an earlier phase of the build. Newer Windows' doesn’t have such limit, but I guess that Windows Installer developers limited their internal environment buffers to 32 kB and fail gracefully when the value is exceeded.
The problem can be easily reproduced:
Create a .bat file which sets environment variables which size exceeds 32 kB. For example, it can be 32 lines of set Variable<number>=<text longer than 1024 characters>
Launch cmd.exe
Execute the batch file you created
From the same cmd.exe window:
Try building the MSI package using WiX with ICE validation on OR
Run smoke.exe to validate your package OR
Simply run msiexec /i Package.msi
All the above commands will end up reporting Error 1719 - Windows Installer could not be accessed.
So, the solution is - review your build scripts and reduce number and size of environment variables so they all fit into 32 kB. You can easily verify the results by running:
set > environment.txt
The goal is to get file environment.txt smaller than ~30 kB.
The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:
Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:
ICE validation needs an interactive account or administrator privileges to be
happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).
imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.
I got the same error on Windows Server 2012 Datacenter as Build Agent.
To solve the problem :
List item
Go to Environment Variables on the build agent machine
Create two System Variables
"PF86" which is equal to "C:\Program Files (x86)"
"PF" which is equal to "C:\Program Files"
They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
Close and build and enjoy!
It worked for me. :)
UPDATE
I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.
I faced the same problem and did not like to suppress ICE validation. My setup: I used my own computer as a build agent on Visual Studio Online (VSO). My solution was to change the account used to run the service on my machine. Instead of using Network Service or Local Service I simply made the service log on with my own account which had all the necessary rights.
From http://wix.sourceforge.net/faq.html#Error217:
In WiX v3, Light automatically runs validation--
Windows Installer Internal Consistency Evaluators (ICEs)
--after every successful build. Validation is a
great way to catch common authoring errors that can lead to service problems,
which is why it’s now run by default. Unfortunately, there’s a common issue
that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to
fail. For details on the cause and how to fix it, see
Heath Stewart's Blog
and
Aaron Stebner's WebLog.
I was getting same ICE error, but the problem turned to be corrupted Windows Installer Service.
This solution worked for me:
http://support.microsoft.com/kb/315353
Log on to your computer as an administrator.
Click Start, and then click Run.
In the Open box, type cmd, and then click OK.
At the command prompt, type msiexec.exe /unregister, and then press ENTER.
Type msiexec /regserver, and then press ENTER.
Restart Windows
Also, verify that the SYSTEM account has full control access permissions to the
HKEY_CLASSES_ROOT hive in the Windows registry. In some cases, you may also have to add Administrator accounts.
I have some suggestions.
Try updating the Microsoft Installer version on the build server
Make sure you use the newest release of WiX 3.0, since it's 3.0 release stable now.
If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...
I got this error from my Azure build agent running on-premises.
My solution was to upgrade its user account from "Network Service" to "Local system account".
Go to your build machine and restart the Windows Installer service
None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:
Some of the WiX ICE validations are implemented using VBSCRIPT.
So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
Chances are that somehow the user that runs your build lost access to this DLL.
As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.
Here are the steps that I took to fix the issue:
Open cmd (run as admin) on the build agent machine.
Run RegEdit
Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
Look for the InprocServer32\Default Key
On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry
Once I updated the path, everything started working as usual.
My solution is similar to Vladimir's one. My CI user was admin of the computer.
But the following steps were mandatory to allow my jenkins build to succeed:
log in as CI user using rdp
open a dos command prompt
execute: %windir%\system32\msiexec.exe /unregister
execute: %windir%\system32\msiexec.exe /regserver
then i got a successfull job