I’m not a Microsoft Windows administrator and I don’t play one on television, but sometimes I need the answer to when I last changed my Windows password, when it will expire, and which Active Directory (AD) groups I belong to.
Here is a command that describes an AD user. Open the Command Prompt app in Windows (either desktop or server) and enter the following:
C:\> net user [username] /domain
For example, to look up AD user dallasmarks type:
C:\> net user dallas.marks /domain
You can also investigate the current user using an environment variable:
C:\> net user %USERNAME% /domain
A potential drawback to the net user command is that long AD group names are truncated. To get around this, open up the PowerShell editor instead of the Command Prompt and type in the following:
If the term ‘Get-ADUser’ is not recognized as the name of a cmdlet, function, script file, or operable program, you’ll need to install the RSAT (Remote Server Administration Tools) for Active Directory.
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 (184.108.40.206.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 (220.127.116.11.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.”
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_MACHINE/SOFTWARE/ORACLE 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:\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.
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
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?
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.
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 specify 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 for the default directory.
Now there isn’t any ambiguity, either in Windows Explorer or in the PATH environmental variable. The folder names are self-documenting. Be sure that each installation has an identical copy of a single, standard tnsname.ora file in their respective network/admin folders.
UPDATE (March 31, 2014): Oracle 11g is no longer 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.
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).
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.
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.
Here is a useful Microsoft MSDN article about Remote Desktop Services Shortcut Keys. For example, use <CTRL><ALT><MINUS KEY> to capture (screen print) images of individual windows from a Remote Desktop session.