( Geek2Live.net )

I’ve had my Macbook 13″ for over a year now, and have adapted to using OS X Snow Leopard with VMWare Fusion running multiple VM’s as required.  My job as the SBO Team Lead means that I provide BDM support (aka demo’ing BusinessObjects software), staying current with new releases and being a technical lead, as well as occasionally doing actual development work.

I’ve had several frustrations with optimising VMs to run for demos.  Pausing my VMs caused poor performance, and even cold-booting the VMs still didn’t perform as well as I’d like.  I attribute this mainly to the bottleneck caused by my 320GB 7200rpm internal hard drive.  Both my CPU and RAM seem to never max out while running VMs – current specs being 2.4 GHz and 4GB RAM.

I’ve been planning to upgrade for a while and I’ve finally signed the documents and ordered the new laptop.  I’m staying with MacBooks, but am going to try out Bootcamp this time.

Here’s the specs:

• 15″ Apple MacBook Pro
• 3.06 GHz CPU
• 8GB RAM
• 256GB SSD (Photofast G-Monster)
• Matte screen (glossy screens = mirror)

The Photofast SSDs apparently sustain 270Mb/s reads and writes, so I’m expecting this baby to fly!  I could have stayed with a 13″, but I would only have been able to get a 2.53 GHz CPU and the screen size is also getting on my nerves recently.

In terms of the software setup, as I’ve had to reduce my hard drive space because of the cost of SSDs (this one is costing me AUD $1,450, ouch), I’m going to dedicate most of the drive to a Bootcamp partition, and the rest of the space will house a Snow Leopard OSX partition.

I’m planning to install Windows Server 2008 R2 x64, with all the usual workstation apps such as Microsoft Office, and this WinServer instance will also be joined to our corporate domain.  I’m also planning to install:

• SQL Server 2008 (DBMS only)
• Oracle 10G XE
• SAP BusinessObjects Enterprise XI 3.1
• SAP Data Services XI 3.1
• Crystal Reports 2008
• Xcelsius 2008

You may wonder why I’m only going with XI 3.1, and not 3.2?  Well (and listen clearly anyone working for SAP) as Edge XI 3.1 SP2 (or XI 3.2) hasn’t been released yet, all of our in-house developed Rapid Marts for clients aren’t backwards compatible.  And a lot of our clients are using Edge XI 3.1, so this means I need to ensure my development platform is compatible with most of our clients.  Frustrating, but necessary… (sidepoint – I heard from the BOB forum the other day that Edge XI 3.1 SP2 has been delayed till mid-2010!)

I’m going to setup the WinServer instance similar to the internal CDI image that SAP release, which means that all the services that run the DBMS, BOE and DS will all be stopped on startup (making sure the system boots very quickly), and then use batch scripts to start up separate components as required.  I will also start to compile multiple demo databases, universes, dashboards etc and hope to grow a large collection of demo material.

I will then setup OSX to use VMWare Fusion to use the Bootcamp partition, which will mean that most of the time I’ll still be able to be in OSX if I’m not demoing etc.

Apparently the timeframe for delivery is 7-10 days because of the matte screen and modded CPU.  I’m hoping to spend a weekend getting everything up and going – I’m really looking forward to it actually, kind of sad – then I’ll be looking to benchmark and take some video tests.  I’m expecting a beast of a machine, but as to how beefy, remains to be seen.

Stay tuned for more in the new few weeks…

- Josh

Service Pack 2 for SAP BusinessObjects Enterprise was recently released, and included some great new features like Web Intelligence Input Controls – see Coy Yonce’s blog post here (needs an SAP login).

However, my frustrations lie in that no SP2 for Edge XI 3.1 was announced.  Remembering back several years, service packs for BOE could be applied to Edge and even Crystal Reports Server, as they were all compatible.

However, it seems that the codebase has started to diverge, or the teams responsible for service packs aren’t coordinated across the different platform offerings.

As a consultant who deploys Edge frequently, this is frustrating considering that there are no discernible differences when using BO Edge compared to BO Enterprise.  Having no programming background at all, I may be swinging wild here, but it seems to me that using license keys to switch features on and off (like clustering, or Federation) would be simpler than diverging what is essentially the same codebase and maintaining separate service pack and fix packs.

I’m not across the success of SAP BusinessObjects Edge in the greater world community, however in Australia it is becoming a very successful platform, and I often need to tell our clients that they have to wait another (estimated) 6 months for a service pack, when the features they require are already available to Enterprise users.

Does anyone else see a need for coordinated delivery of service packs for the BI platform?  Or perhaps someone from SAP can weigh in on why they are delivered separately?

If there are good reasons, I’d love to hear them as most of the annoyance comes from the lack of communication.

– Josh

After trying to think of of another useful topic, I realised that configuring Single Sign On with Active Directory and Vintela in XI 3.1 is something that is rarely covered, and I used to have quite a lot of trouble with it.

By adapting a document on the SAP Support Portal, I now use a sure-fire method to configure AD SSO with Tomcat, the default web application server that ships with BusinessObjects Enterprise/Edge XI 3.1.  It’s worked every time I’ve used it.

Firstly, let’s define our server names and IPs (you must obviously adjust these and the commands below to reflect your server names and IPs – I have underlined commands that need to be changed to help):

• Domain Name: POWI (FQDN: POWER.INTERNAL)
• Service Account: bo.service (password: admin)
• Domain Controller: vs-dev-ad-dc.POWER.INTERNAL (IP: 192.168.5.1)
• BO Server: vs-dev-ad-bo.POWER.INTERNAL (IP: 192.168.5.2)
• BusinessObjects AD Group: POWI\Business Objects

Step 1

Create an Active Directory service account, bo.service (pass: admin).  On the BusinessObjects server, add the POWI/bo.service user to the Administrators group.  Also assign them the following rights in the Local Security Policy snap-in:
•    Act as part of Operating System
•    Log on as a Batch Job
•    Log on as a Service
•    Replace a Process Level Token

Step 2

Run the following command on the Active Directory server:

ktpass -out BOSSO.keytab –princ BOSSO/bo.service.power.internal@POWER.INTERNAL -mapuser bo.service@POWER.INTERNAL -pass admin -kvno 255 -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT

The output from the above command should be similar to:

Targeting domain controller: vs-dev-ad-dc.POWER.INTERNAL
Using legacy password setting method
Successfully mapped BOSSO/bo.service.power.internal to bo.service.
Key created.
Output keytab to BOSSO.keytab:
Keytab version: 0x502
keysize 81 BOSSO/bo.service.power.internal@POWER.INTERNAL ptype 1 (KRB5_NT_PRINCIPAL) vno 255 etype 0x17 (RC4-HMAC) keylength 16 (0x209c6174da490caeb422f3fa5a7ae634)

Step 3

Run the following command on the Active Directory server:

setspn -l bo.service

The output should be similar to:

Registered ServicePrincipalNames for CN=bo.service,CN=Users,DC=POWER,DC=INTERNAL:
BOSSO/bo.service.power.internal

Step 4

Go to properties of the ‘bo.service’ user in Active Directory and under the Delegation tab, set ”Trust this user for delegation to any service (Kerberos only)’ to on.

Step 5

Move the BOSSO.keytab file that was created on the Active Directory server (refer Step 2) to c:\winnt\ of the BusinessObjects server.

Step 6

Generate the requisite SPN’s by running the following commands on the Active Directory server:

setspn -a HTTP/vs-dev-ad-bo bo.service
setspn -a HTTP/vs-dev-ad-bo.power.internal bo.service
setspn -a HTTP/192.168.5.2 bo.service

The output from the above commands should be similar to:

HTTP/vs-dev-ad-bo
Updated object
Registering ServicePrincipalNames for CN=bo.service,CN=Users,DC=POWER,DC=INTERNAL
HTTP/vs-dev-ad-bo.power.internal
Updated object
Registering ServicePrincipalNames for CN=bo.service,CN=Users,DC=POWER,DC=INTERNAL
HTTP/192.168.5.2
Updated object

Step 7

Run the following command on the Active Directory server to view all of the created SPNs:

setspn -l bo.service

The output should be similar to:

Registered ServicePrincipalNames for CN=bo.service,CN=Users,DC=POWER,DC=INTERNAL:
HTTP/192.168.5.2
HTTP/vs-dev-ad-bo.power.internal
HTTP/vs-dev-ad-bo
BOSSO/bo.service.power.internal

Step 8

Within the BusinessObjects Central Management Console, within the Windows AD Authentication area, do the following:

1. Enable Windows AD
2. Set the AD Administration Name: POWI\bo.service
3. Set the Default AD Domain: POWER.INTERNAL
4. Add AD Group: POWI\Business Objects
5. Set ‘Use Kerberos Authentication’
6. Set the Service Principal Name: BOSSO/bo.service.power.internal
7. Set ‘Enable SSO for Selected Authentication Mode’

Step 9

Modify the SIA service on the BusinessObjects server to run as the POWI\bo.service domain user.

Step 10

You should now be able to get SSO onto locally installed tools (ie Designer, Webi Rich Client) by starting the application, selecting the authentication method to be Windows AD, and without inputting a username and password, clicking OK.  You should be logged in as your AD user.

Step 11

Create a file called c:\winnt\bsclogin.conf on the BusinsesObjects server, and put in it the following text:

com.businessobjects.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required debug=true;
};

Step 12

Create a file called c:\winnt\krb5.ini on the BusinessObjects server, and put in it the following text:

[libdefaults]
default_realm = POWER.INTERNAL
dns_lookup_kdc = true
dns_lookup_realm = true
udp_preference_limit = 1
[realms]
POWER.INTERNAL = {
kdc = VS-DEV-AD-DC.POWER.INTERNAL
default_domain = POWER.INTERNAL
}

Step 13

To test that the krb5.ini file was created successfully, undertake the following:

1. Navigate to \Program Files\Business Objects\javasdk\bin on the command line
2. Execute ‘kinit bo.service‘, then input your password
3. A ticket should be created

Step 14

On the BusinessObjects server, open up the Tomcat Configuration application, then go to the Java Options input, and add the following lines (restart Tomcat once done):

-Djava.security.auth.login.config=C:\winnt\bscLogin.conf
-Djava.security.krb5.conf=C:\winnt\Krb5.ini

Step 15

Modify the \Program Files\Business Objects\Tomcat55\webapps\InfoViewApp\WEB-INF\web.xml file and allow users to see authentication options by changing the authentication.visible tag to true.

Step 16

Modify the \Program Files\Business Objects\Tomcat55\conf\server.xml file, by change the following line to increase the MaxHttpHeaderSize element to ‘16384′:

<Connector URIEncoding="UTF-8" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="16384" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="80" redirectPort="8443"/>

Step 17

Modify the \Program Files\Business Objects\Tomcat55\webapps\InfoViewApp\WEB-INF\web.xml file as follows:

1. Change authentication.default to ’secWinAD’
2. Change siteminder.enabled to ‘false’
3. Change vintela.enabled to ‘true’
4. Remove comment tags (<!–, –>) from around the authFilter filter element
5. Change idm.realm to ‘POWER.INTERNAL’
6. Change idm.princ to ‘BOSSO/bo.service.power.internal‘
7. Remove comment tags (<!–, –>) from around the authFilter filter-mapping element

Step 18

On the BusinessObjects server, open up the Tomcat Configuration application, then go to the Java Options input, and add the following lines:

-Dcom.wedgetail.idm.sso.password=admin (password for bo.service user)
-Djcsi.kerberos.maxpacketsize=0
-Djcsi.kerberos.debug=true

Step 19

Remove the following from the Java Options input in the Tomcat Configuration (if they exist):
•    Debug =true in the bsclogin.conf (set by default)
•    -Dbobj.logging.log4j.config=verbose.properties (may have been added to Java Options)
•    -Dcrystal.enterprise.trace.configuration=verbose (may have been added to Java Options)
•    -Djcsi.kerberos.debug=true (may have been added to Java Options)
•    Dcom.wedgetail.idm.sso.password=admin (only remove if you have a valid keytab configured)
•    Switch Tomcat 5.5 back to run as the local system (if running under service account for verbose tracing)

Step 20

Encrypt your service account password by coping the BOSSO.keytab (created during Step 2) to the c:\winnt directory on the BusinessObjects server, then specify the following in the \Program Files\Business Objects\Tomcat55\webapps\InfoViewApp\WEB-INF\web.xml (after the idm.princ setting):

<init-param>
<param-name>idm.keytab</param-name>
<param-value>c:\winnt\BOSSO.keytab</param-value>
</init-param>

Step 21

Remove the wedgetail.password option from the Tomcat Configuration Java Options. At this point your Vintela SSO should work with InfoView.

References

I was only able to document the above using the (very) detailed PDF document on Vintela SSO provided by Tim Ziemba at the following SAP Support Note: http://service.sap.com/sap/sapnotes/display/1261835.

If any SAP BusinessObjects staff read this post, it would be fantastic if all this knowledge that is being captured in the SAP Support Portal could be filtered and pushed back into the standard documentation, as this sorely lacks the detail required to implement Vintela SSO.