Installing Two Oracle 12c Clients on One Server

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 Release 1 (12.1.0.2.0) and apparently I’m not the only one. To the best of my knowledge, I believe the issue is resolved in Oracle 12c Release 2 (12.2.0.1.0).

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.”

Oracle 12 32 bit trick 01 500The 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_MACHINE/SOFTWARE/ORACLE has a value named inst_loc behind, which interferes with the Oracle 12c 32-bit installation.

Oracle 12 32 bit trick 02 500

Simply remove the offending inst_loc value from the registry.

Oracle 12 32 bit trick 03 500

Then you’ll be able to install the 32-bit client successfully.

Oracle 12 32 bit trick 04 500

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.”

Oracle 12c SQL Loader Issue

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.

Changing Your Windows Password from a Remote Desktop

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.

Remote Desktop Password Reset 01

The on-screen keyboard will appear on the Remote Desktop.

Remote Desktop Password Reset 02-400When 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).

Remote Desktop Password Reset 03-400

The standard Windows lock screen will appear. Choose Change a passwordand change password according to your organization’s security policies.

Remote Desktop Password Reset 04

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 Popular Windows Desktop Shortcuts for All Users

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:\Users\Public\Desktop. 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.

Microsoft Windows Show Hidden Files Folders and Drives

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?

How to Find Microsoft Windows Uptime?

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.

  1. Go to “Start” -> “Run”.
  2. Type “CMD” and press “Enter” key. A DOS-style command window will appear.
  3. From the command window, enter the command “net statistics server” or “net stats srv” at the prompt and press “Enter” key.
  4. Look for the line that start with “Statistics since …”, which provides the time the server was last booted.

Definitely an article worth bookmarking.

The Fun Never Ends with 64-bit Windows and ODBC

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.

Installing Two Oracle Clients on One Server

A simple trick for managing two versions of Oracle client tools.

One dose of Larry Ellison is enough for most people. Unless you need two.  There are two common scenarios for SAP BusinessObjects BI4 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 BI4 platform is (mostly) 64-bit (see related article, SAP BusinessObjects BI 4 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 BI4 platform must support classic Crystal Reports (2011/20132016).  The Crystal Reports 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 3: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 SAP BusinessObjects BI server easier to manage.

Still Having Fun with 64-bit Windows and ODBC

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_MACHINE\SOFTWARE\ODBC 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_MACHINE\SOFTWARE\ODBC is where the 64-bit DSN’s are stored. 32-bit DSN’s are stored in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC.  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, classic Crystal Reports 2011/2013/2016 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_MACHINE\SOFTWARE\ODBC and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC 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).

Related Articles

For more information, check out this related thread on the BusinessObjects Board (BOB).

Adding Central Configuration Manager (CCM) to Windows Server Startup Folder

A simple but useful trick.

One of the first things I like to do after installing SAP BusinessObjects is copy the Central Configuration Manager (CCM) shortcut to the Microsoft Windows Start Menu startup folder.  Most SAP BusinessObjects administration is handled from the browser-based Central Management Console (CMC). But when I bother to actually log directly into the Windows server, the CCM is generally the first thing I want to check.  Adding it to the startup folder to automatically launch saves me some time.

Central Configuration Manager XI 3.1
Windows 7 and Windows 2008 handle the start menu differently than their predecessors (see related post Windows 7/Windows 2008 Start Menu), so here is the procedure.

First, navigate to the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\SAP BusinessObjects BI platform 4.0\SAP BusinessObjects BI platformdirectory and copy the Central Configuration Manager shortcut to the Windows clipboard.  The ProgramData folder is hidden, so you’ll want to set Windows Explorer options to show hidden files and folders.

Next, paste the shortcut in the adjacent C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup folder.

The Central Configuration Manager (CCM) will now start automatically when you log into the server using Remote Desktop.

More Fun with 64-bit Windows and ODBC

All I can say is “SysWoW64! That’s really intuitive, Mr. Ballmer!”

This week, I helped a customer install SAP BusinessObjects XI 3.1 SP3 on Microsoft Windows Server 2008 64-bit using Microsoft SQL Server 2005 for the system (CMS) and audit databases.  And once again, I was tricked by Microsoft’s ODBC Data Sources panel into creating 64-bit ODBC connections that were rejected by the XI 3.1 installation program.  XI 3.1 is fully supported on 64-bit operating systems, but it’s still a 32-bit application that requires 32-bit database connectivity.  The whole experience felt like deja vu, and sure enough, I blogged about this topic over two years ago when it burned me the first time.  So let’s review (from Microsoft Support article 942976):

The 64-bit version of the Odbcad32.exe file is located in the C:WindowsSystem32 folder.  This 64-bit version appears on the Windows Start menu.

The 32-bit version of the Odbcad32.exe file is located in the C:WindowsSysWoW64 folder.  This version does not appear on the Windows Start menu.

Got that?  64-bit code is stored in a folder named “System32” and 32-bit code is stored in a folder named “SysWoW64”.  And both ODBC panels are identical in appearance – there’s no real clue to which one you’re using.  All I can say is “SysWoW64! That’s really intuitive, Mr. Ballmer!”

During the XI 3.1 installation, the dialog box for establishing the BusinessObjects system and audit databases for Microsoft SQL Server will have the “Consume DSN created under WOW64” box checked by default.  You should see your 32-bit DSNs on the list of available DSN’s.  If your DSNs refuse to apper until you uncheck the “Consume DSN created under WOW64” box, that’s your clue that you goofed up and created 64-bit DSNs.  Attempting to proceed further will cause the installation program to generate a humiliating STW00225 (Audit connection) and/or STW00226 (system/CMS connection) error message.

SAP tries to warn us with the following note in the supported platforms document:

BusinessObjects products use the 32-bit ODBC registry on all versions of Windows. To administer 32-bit ODBC DSNs on 64-bit versions of Windows, run the 32-bit ODBC Administrator, located here: C:WindowsSysWOW64odbcad32.exe

Thankfully, the upcoming release of SAP BusinessObjects Business Intelligence 4.0 is fully 64-bit, allowing the use of 64-bit DSN’s to Microsoft SQL Server.  So it won’t be long before we can all put this ODBC controversy behind us. Well, all of us except for Mr. Ballmer.

UPDATE: Although the SAP BusinessObjects Business Intelligence 4.0 platform is 64-bit, it is not fully 64-bit (see related article, SAP BusinessObjects BI 4 is (Mostly) 64-bit).  In particular, Crystal Reports 2011 still requires 32-bit database connectivity (see related article, Still Having Fun with 64-bit Windows and ODBC).

Best Practices for SAP BusinessObjects and ODBC

To minimize some of the confusion, create clearly labeled desktop shortcuts to the 32-bit ODBC panel (C:WindowsSysWoW64 folder) and the 64-bit ODBC panel  (C:WindowsSystem32 folder) before even attempting your SAP BusinessObjects installation.  Then create your DSNs via the appropriate shortcut (32-bit for XI 3.1 and lower, 64-bit for BI 4.0 and higher).  On Microsoft Windows 2008 Server, I move these shortcuts to the hidden folder C:UsersPublicDesktop so the rest of the administrative team can use them.

I used to recommend adding _32 as a suffix to your DSN names to remind everyone that they are 32-bit connections.  But then SAP BusinessObjects Business Intelligence 4.0 arrived. Crystal Reports 2011 is still 32-bit on the server, so I now prefer that the 32-bit DSN and 64-bit DSN share the same name.

Thank you, Mr. Ballmer.