Recently I’ve had to install Oracle Grid 12.2 on Windows Server 2012 for a client. Normally this wouldn’t be blog-worthy but this time the installation threw up several headaches that I’ve not encountered before, and one I had and should have known better!
First, the schoolgirl error. Always make sure you run the Oracle Universal Installer with the Run as Administrator option. Frustratingly, if you don’t Oracle doesn’t immediately throw an error, but waits until you are at the point where it wants to write registry keys before informing you of a problem. At this point it has already done quite a bit of the configuration work so re-trying the install often fails if you simply try to rerun it. The only solution is to fully de-install Grid using this Oracle note: https://docs.oracle.com/database/121/CWLIN/rem_orcl.htm#CWLIN350 and retry the install. Far from ideal.
The second problem is one that plenty of people have hit, Oracle and Windows password complexity mismatch. This is a bug that I really cannot understand why Oracle haven’t fixed yet, but perhaps it’s more complex than I am giving them credit for. If whilst doing a software install you get an error during the installation window about ‘Couldn’t create Oracle home user’ and you DEFINITELY ran the installer as Admin, then chances are you’ve fallen foul of this. The issue is fully repeatable. All you need to do is:
- Check your Windows password complexity rules in local security policy -> account policies -> password policy are set to enabled
- Run the Oracle installer for the database
- Select Software only (or create DB if you want)
- When prompted for user details, make sure you select ‘New user’
- Enter a basic password like Oracle12
Oracle will accept the password without complaint and will continue with the install seemingly fine. However when it get’s to 86% it fails with the below error:
Failed to Create oracle Oracle Home User
2 solutions, one not recommended, but both require backing out the install:
- Switch off the password complexity rules – not recommended for obvious security reasons but you may need to do this if you need a certain password
- Redo the install but make sure the password matches your complexity rules
Simple fixes but very unnecessary.
The third headache was a bit more complex. After uninstalling Grid and reinstalling it successfully, time came to install the DB software and create our new DB. The software installer threw an error I had not seen before:
Failed to create user ACLs
This points to a privileges or permissions issue, but I’m running the install as Administrator so I should have all the access needed. Checking the log file shows that the installer is trying to write Oracle registry keys but checking them against a working install shows they all appear correct. I can click ‘Ignore’ on the error and the installer completes but it then will not allow me to create a DB using that software installation, giving a further error complaining of being unable to write to the controlfiles. I can write to that location, and when I check the controlfile it refers to is there and can be opened by my user. Strange.
I did what every modern DBA does and turned to Google which has saved all of us on many occasions. Nothing. Only 1 hit for ‘Failed to create user ACLs’ which mentions Oracle and I have a different error message. Nothing on Oracle Support either. Looks like I’m on my own with this one. Time to think it through logically.
- ACLs – Access control lists, so for some reason Oracle doesn’t think I have permissions when Windows thinks I do?
- What user does Oracle try to use when I use the ‘Run as Admin’ option? Is it really using ‘Administrator’? How can I find out? If you are lucky enough to have auditing turned on (it’s off by default but I really do recommend turning it on!) then you can check commands run with elevated privileges in the Security Event viewer. Fortunately this was enabled for me and suddenly the issue became clear…
This server was setup to use Danish language as it’s default. Oracle however loaded most of the text in English, so I didn’t need to change it for the install. In a Danish server the admin account is called ‘Administratör’ and Oracle cannot handle the special characters. The solution to this one is to create a new user with Admin privs and run the installer using that account instead. Another non-perfect solution.
Even more unhelpfully, if you click ignore enough times for all these issues the installer completes and reports success even though the registry keys aren’t set, some files aren’t installed and any attempt to create a DB will fail. I have raised a bug report with Oracle which has been acknowledged but not yet actioned.