The Oracle 12c 32-bit client requires a little bit of extra attention.
I’ve previously written about best practices for installing the 64-bit and 32-bit Oracle clients on a single Microsoft Windows server that needs to support SAP BusinessObjects BI 4 (see related article, Installing Two Oracle Clients on One Server). Those best practices still apply, but I encountered a small wrinkle with Oracle 12c and apparently I’m not the only one.
The installation of the 64-bit client goes smoothly. It’s only when you attempt to install the 32-bit client that you may encounter the following error, “[INS-10102] Installer initialization failed.”
The issue seems to occur when a previous installation of the Oracle 32-bit client (for example, the older 11g client) was previously installed. The registry key named HKEY_LOCAL_MACHINESOFTWAREORACLE has a value named inst_loc behind, which interferes with the Oracle 12c 32-bit installation.
Simply remove the offending inst_loc value from the registry.
Then you’ll be able to install the 32-bit client successfully.
Additional fun with Oracle 12c SQL Loader
The 64-bit Oracle 12c client tools also have a small issue with the SQL Loader utility (sqlldr.exe). SQL Loader is not required by SAP BusinessObjects Business Intelligence 4, but I thought I’d document the issue here anyway – “The program can’t start because oranfsodm12.dll is missing from your computer. Try reinstalling the program to fix this problem.”
Reinstalling the client tools won’t help because the issue is an Oracle defect, which is described on the Oracle Technology Network. To resolve, make a copy of the oraodm12.dll in the bin directory and rename it to oranfsodm12.dll.
What is your experience with SAP BusinessObjects BI4 and Oracle 12c? Share you thoughts in the comments below.
Password changes from remote desktops need not involve a ritual goat sacrifice.
I use a Apple MacBook Pro for work and do most of my client work using Microsoft Remote Desktop, either natively on my Mac or via a VMware Fusion VM running Windows 7. It works great, other than you have to remember that Remote Desktop keyboard shortcuts are slightly different than regular ones. And of course the Mac keyboard adds its own spin to shortcuts. Probably the most challenging thing I have to do is periodically change my password on customer systems. After a bit of research I discovered that changing passwords is easier if you use the Microsoft Windows on-screen keyboard.
To launch the on-screen keyboard in Windows Server, go to Start -> Run and type osk into the dialog box.
The on-screen keyboard will appear on the Remote Desktop.
When the on-screen keyboard appears, press <CTRL> and <ALT> (illustrated as steps 1 & 2) from your physical keyboard. For a Mac keyboard, use <OPTION> for the <ALT> key. While holding down the physical <CTRL> and <ALT> keys, click the <DELETE> key using the on-screen keyboard (illustrated as step 3).
The standard Windows lock screen will appear. Choose Change a password… and change password according to your organization’s security policies.
Mission accomplished, whether on a Mac or a PC. Thanks to Bill Schultz for explaining how to do this procedure on Microsoft TechNet.
What kinds of tricks do you use with Microsoft Windows and Remote Desktop?
Create public shortcuts to make everyone’s life easier.
When installing software on Microsoft Windows server operating systems like Microsoft Windows Server 2008, I like to create a small number of frequently used programs and folders such as the ODBC DSN panels (see related article, More Fun with 64-bit Windows and ODBC) as desktop shortcuts. By default, these shortcuts are placed on my personal desktop, stored in a folder like
C:Users<username>Desktop. But you can share these desktop shortcuts with your fellow administrators by using Windows Explorer to copy the shortcuts from your personal desktop to the public desktop, which is located at
C:UsersPublicDesktop. The public desktop is a hidden folder, so you’ll want to show hidden folders in your Windows Explorer. Choose Organize from the Windows Explorer menu, then Folder and search options. Choose “Show hidden files, folders, and drives” from the “Hidden files and folders” option on the View tab, as shown below.
Don’t go overboard with too many shortcuts and annoy your coworkers, but here are some suggestions:
- 32-bit ODBC DSN Panel
- 64-bit ODBC DSN Panel
- Tomcat Configuration
- SAP BusinessObjects Central Configuration Manager (CCM)
- SAP BusinessObjects BI Launchpad
- SAP BusinessObjects Central Management Console
- SAP BusinessObjects File Repository Server folders, if on remote server
What kinds of Microsoft Windows tricks do you use to make administering SAP BusinessObjects easier?
Unix and Linux users can easily determine the uptime of their system by entering the command who -b. Microsoft Windows users can determine their system uptime by following Microsoft KB article 555737.
- Go to “Start” -> “Run”.
- Type “CMD” and press “Enter” key. A DOS-style command window will appear.
- From the command window, enter the command “net statistics server” or “net stats srv” at the prompt and press “Enter” key.
- Look for the line that start with “Statistics since …”, which provides the time the server was last booted.
Definitely an article worth bookmarking.
Still making fun of the Microsoft Windows ODBC panel.
The new Information Design Tool (IDT) in SAP BusinessObjects Business Intelligence 4.0, like the other client tools in the suite, is a 32-bit application. Even if the IDT is installed on a 64-bit version of Microsoft Windows, it wants to use 32-bit ODBC DSN’s created with the 32-bit ODBC panel, not 64-bit DSN’s. If you attempt to create a new universe connection and specify a 64-bit DSN name, the following error appears.
[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application
To resolve the issue, make sure you’re using the 32-bit ODBC panel (see related article) at
C:WindowsSysWoW64Odbcad32.exe. If you are running the client tools and server on the same platform, create a 32-bit ODBC DSN for the Information Design Tool and a 64-bit ODBC DSN for the server (BI Launchpad, Web Intelligence Processing Server, etc.). Make sure both DSN’s have identical names.
Remember that Crystal Reports 2011, Crystal Reports 2013, and Crystal Reports for Enterprise clients are also 32-bit. If they are installed on the BI4 server (which is supported, but oddly enough not recommended), they will also require 32-bit ODBC connections even though the Crystal Reports Processing Server requires 64-bit ODBC connections. Note that the legacy Crystal Reports 2011/2013 Processing Server will also require 32-bit ODBC connections.
Having fun with 64-bit Windows and ODBC? You may find my other articles on ODBC helpful.
A simple trick for managing two versions of Oracle client tools.
One dose of Oracle is enough for most people. Unless you need two. There are two common scenarios for SAP BusinessObjects Business Intelligence 4.0 customers that require installation of 32-bit and 64-bit client tools on the same server.
The first scenario occurs when the BI platform and its client tools are installed on the same server. The BI 4.0 platform is (mostly) 64-bit, yet all of its client tools such as the Information Design Tool or Universe Design Tool are 32-bit. A second scenario occurs when the BI 4.0 platform must support Crystal Reports 2011 reports (Or Crystal Reports 2013 on the BI 4.1 platform). The Crystal Reports 2011 processing server requires 32-bit middleware even though new Crystal Reports for Enterprise reports use 64-bit middleware (Microsoft SQL Server users should read my related article More Fun with 64-bit Windows and ODBC).
Distinguishing between the two Oracle installations can be challenging, particularly when default home folder names are used. The example below has two client tool installations using the default folder names, client_1 and client_2. But which one is 32-bit? Which one is 64-bit? These are questions that shouldn’t be asked during groggy 2:00 AM support calls.
To minimize the confusion, simply rename the default directories when installing the Oracle clients. The 64-bit middleware should be installed first. I use a directory name of client_64. Then I install the 32-bit middleware, using a directory name of client_32. The final result is shown below. Notice that I also use C:Oracle as the home directory, not the C:app[username] nonsense that Oracle sets as a default directory.
Now there isn’t any ambiguity, either in Windows Explorer or in the PATH environmental variable. The folder names are self-documenting. But be sure that both installations have identical copies of a single, standard tnsname.ora file in their respective network/admin folders.
UPDATE (March 31, 2014): Oracle 11g isn’t supported on Windows Server 2012 R2 so I installed Oracle 12c clients for the first time. I typically use the Administrator installation option for both 64-bit and 32-bit clients, but the 32-bit client complained. I opted instead for the Runtime installation option for the 32-bit client, which installed without complaining. This type of install still provides 32-bit SQL*Plus, so that’s good enough for me.
I hope this simple naming trick makes your server easier to manage.
Copying ODBC DSN’s from XI 3.1 to BI4 need not be a tedious chore.
I’m still having fun with 64-bit Windows and ODBC. This time, I’m working with SAP BusinessObjects Business Intelligence 4.0 SP2 Patch 10 (BI4) instead of my previous exploits with SAP BusinessObjects Enterprise XI 3.1 (see related article, More Fun with 64-bit Windows and ODBC). My challenge was to easily copy ODBC DSN’s from a customer’s existing XI 3.1 environment to their new BI4 environment without hours of tedious typing in the Windows control panel.
The procedure is simple enough, as ODBC DSN’s are stored in the Microsoft Windows registry. Simply use the registry editor on the source machine to export the
HKEY_LOCAL_MACHINESOFTWAREODBC tree. Move the generated registry file to the destination machine and load using the registry editor. But when moving between 32-bit Windows and 64-bit Windows, there’s a small catch.
In 64-bit Windows,
HKEY_LOCAL_MACHINESOFTWAREODBC is where the 64-bit DSN’s are stored. 32-bit DSN’s are stored in
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeODBC. This means that the 32-bit DSN’s that you import from the 32-bit XI 3.1 server automatically become 64-bit DSN’s on the BI4 server by virtue of their registry location.
SAP BusinessObjects BI4 is primarily 64-bit, so most services like the Web Intelligence Processing Server will be looking for 64-bit DSN’s. However, Crystal Reports 2011 and 2013 are 32-bit (even on the BI4 server), so it will look for DSN’s in the second Wow6432Node. I ended up creating these 32-bit DSN’s manually using the ODBC panel on our BI4 staging server (see related article, SAP BusinessObjects BI4 is (Mostly) 64-bit).
However, once I have both 32-bit and 64-bit DSN’s created on the staging server, I can move them easily to other 64-bit Windows machines. I just have to remember to export both the HKEY_LOCAL_MACHINESOFTWAREODBC and HKEY_LOCAL_MACHINESOFTWAREWow6432NodeODBC keys.
TIP: Remember that each set of DSN’s has its own control panel. To avoid going insane during testing, take a moment to create separate desktop shortcuts to the 32-bit and 64-bit ODBC DSN panels on your 64-bit Windows server (see related article, More Fun with 64-bit Windows and ODBC).
For more information, check out this related thread on the BusinessObjects Board (BOB).