Skip to Content

Symptom

Patching to SAP BI 4.1 will indeed break your Active Directory Single Sign On in one or two places if your Web Application Server is Apache Tomcat.

Environment

  • SAP BusinessObjects Business Intelligence Suite 4.0
  • Apache Tomcat


Solutions

Don’t worry, the solution(s) are simple!

1: Your .properties files

It is widely documented that when you patch, the content of the webapps folder will redeployed therefore all customisations will be lost.

The solution is to of course either manually re-apply the changes you have made or better, from SAP BI 4.0 you can save the updated .properties in a folder and they will get redeployed automatically.

See SAP Note 1615492

2: Your Apache Tomcat server.xml

This one was a bit trickier!  The problem is that manual authentication is still working and Silent SSO is working for some of the users.  The others receive a HTTP error.

Turns out patching from SAP BI 4.0 to SAP BI 4.0 will also install a new version of Apache Tomcat (From Tomcat 6 to Tomcat 7).  The installation folder is a bit different too:

  • Old Location: C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\
  • New Location: C:\Program Files (x86)\SAP BusinessObjects\tomcat\

Doing so, the content of your server.xml has been lost.  Simply edit the new server.xml and make sure to re-apply the

maxHttpHeaderSize=”65536″ value in the Connector Port.

More details about this: SAP Note 1631734

Hope it helps!

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Andy Roche

    Patrick, thanks for the information. With regard to the customization of the .properties files.  As noted in SAP Note 1615492 if you make sure that the custom .properties files are copied to <BOE_HOME>\SAP BusinessObjects Enterprise XI 4.0\warfiles\webapps\BOE\WEB-INF\config prior to the update you will find that the files will exist in the new environment after the patch. This is because when the patch is run it will update the contents of the warfiles folder and then perform a WDeploy into the new Tomcat folder which will bring the custom .properties files with the deployment.

    Also, if you are currently supporting cross-domain AD authentiaction you will also need to add the domain to the username stated in the SPN section of the AD auth plugin.  Ex. if the SPN was BI4_service and the domain is FOOBAR.COM then the SPN would now be shown as “BI4_service@FOOBAR.COM” instead of “BI4_service”. Apparently this was due to a change they made under the hood. 😉

    (0) 
      1. Andy Roche

        Sorry, you caught me between edits.  I apologize if it sounded like I was correcting you.  I was only saying that if we implement this prior to the update we will not only protect the custom settings from the 4.0 to 4.1 update but also from all future patches as well.

        I apologize for any confusion.

        (0) 
        1. Patrick Perrier Post author

          The main point of this article is that the server.xml will get overwritten as SAP BI 4.1 includes a new version of Tomcat (Solution 2 above).  This can’t be avoided.

          The rest about .properties (Solution 1) has largely been discussed in many other posts.

          (0) 
          1. Andy Roche

            Very true. It would be nice if they would go ahead and set the server.xml to support SSO in Tomcat7, but for now we must all remember to replace it.

            (0) 
  2. Noel Scheaffer

    We upgraded from 4.0 SP06 to 4.1 SP01 Patch 2 on November 2nd.  We had some (not all) users having problems getting logged into BOBJ.  Since it was affecting only some users we thought it had something to do with our load balancing environment.  I came across this blog post and thought item #2 might make a difference.  So I made the changes last night and it did the trick.

    Thanks!

    (0) 
  3. Neal Gosz

    I have a question.  I had a client that wanted me to install Explorer 4.0 to test out, and it broke their SSO.  Are these the main spots to check to reconfigure SSO and what do I reset?  The settings appear correct in the CMS, but we’re not sure about Tomcat as the biservice would not create a ticket when running in the Command Prompt.

    Thanks

    (0) 

Leave a Reply