Posts tagged "Windows"

Migrating Business Objects Enterprise from Windows to Linux

The Linux operating system has established itself as an industry standard for enterprise applications. However, not all flavors of Linux are supported for running Business Objects Enterprise systems. Red Hat Enterprise Linux (more or less version 4 and 5 of the server) and SUSE Linux Enterprise Server (version 9 and 10) are supported as of XI 3.1 Service Pack 3. Given the cost of ownership and the robustness of the operating system, more businesses are looking to Linux as viable option when considering upgrading their servers. This article captures some of the concerns that a BOE system administrator might have when considering or planning a migration of their system from a Windows server to a Linux environment.

You Still Need Windows


If you are thinking you could liberate your office of all PCs after a successful Business Objects Linux migration, you are quite mistaken. Your universe development will still require the use of Designer. Any plans to migrate content between environments using Import Wizard will also

SQL Server Connections


When you are running Report Servers and/or Connection Servers on a Windows Server then you can get away with using the veryquick-to-configure OLE DB Microsoft SQL Server connection. These are the simplest connections to configure because they require no configuration on the client. If you are planning to move to Linux get ready for this simplicity to change.

Only ODBC or JDBC connections are supported for Linux servers (depending on version of BO and MS SQL Server database). This means that not only are you going to have to convert all of your OLE DB connections to ODBC/JDBC, but you are also going to have to start configuring any Windows machine that needs to run Designer (or Desktop Intelligence) with an appropriate and name-matching DSN. Yes, running on Linux now makes MS SQL Server connections just as difficult as Oracle connections (or maybe worse).

Unmanaged Disk File Destinations – Scheduling to File Shares


If you are familiar with Linux than you probably already thought of this one. When you are running job servers on Windows users can ad-hoc enter in any UNC File Share path as a destination for their scheduled job. They only need to be sure that the security of the file share is configured to allow the job server to write a file to it.

With Linux things are not so simple. In order for the BO job server to be able to write to a file share the file share needs to be mounted to the Linux server. Therefore, as user would have to communicate their file share first to a system administrator, who then needs to mount the file share and confirm to task completion to the user. After all of this is done the user can proceed to schedule a job to deliver a file to the file share; however, the user will need to know the exact name that was used to mount the file share. Yes, it just got a lot more complicated.

To make matters worse, the system administrator would need to have “root” access to be able to mount the file share. Samba will need to be installed as well on the server. The file share will have to mounted on all machines that are running the job servers int he cluster (unless server groups as used). Also the system administrator will need to make sure that the mount of the file share is persistent, so that it remains even if the server is rebooted.

File Repository Server on a File Share


In most cases production systems store the File Repository System on a separate file server. In Windows you don’t need to configure the machine running the Input/Output FRS servers to be able to connect to the file share. On a Linux server you would have to mount the file share first to the machines running FRS and then you would need to make sure that the mount was always present on the machine. I don’t think it would be a good idea to use a Windows files share here with Samba, perhaps it would not even be supported.

Kiss Your Windowed GUI Good-bye


CCM and all of its little attached tools are all either command-line driven or ASCII-based GUIs. None are too bad or difficult to deal with, but this is a change for sure.

Much Remains Unchanged


While the above discussed changes are unavoidable, it should be noted that most of the functionality of Business Objects XI Enterprise is unchanged when the servers are run on Linux machines. CMC still runs pretty much the same as does InfoView and Web Intelligence. The end user, report/universe developer, or CMC user would really not notice much of a difference in their interfaces.


CMS Cluster Summary and the CMSClusterMembers Registry Key

A “CMS Cluster” is a group of Business Objects XI Central Management Servers (abbreviated CMS, which is a BO service\daemon) that are interrelated and connected so that they may work in conjunction to manage the various other BO servers and provide most of the basic functionality of Business Objects. Clustering them allows for greater capacity management (each Central Management Server can generally support about 500 to 600 concurrent users, based on usage) and fail-over capability. In other words, having a CMS cluster consisting of at least 2 CMS is a VERY intelligent design decision for any Business Objects XI environment requiring any fault tolerance.

Creating a CMS cluster is not too complicated, but for now outside the scope of this article. You should understand that pretty much every other BO service will benefit by being aware of this CMS Cluster. The cluster name is defined in the specifications of each server’s CCM configuration (BusinessObjects XI R2) or that of its Server Intelligence Agent (Business Objects XI 3.X). The way that the BO server is aware of the members of the CMS cluster is through server operating system registry key. The name and path of this key on the Windows OS is:

HKEY_LOCAL_MACHINE\SOFTWARE\\Business Objects\Suite 11.5\Enterprise\CMSClusterMembers

One thing important to note about this key is that it is self-maintained. If a CMS is joined or removed from the CMS Cluster than the other BO servers running on a node will communicate with the CMS Cluster and update the registry key to reflect the valid members of the CMS Cluster. Now this is not exactly real-time updating, but rather it occurs at start-up of the BO server (I mean a service, such as Web Intelligence Report Server) or even at enabling of a disabled server.

Reflecting on what I’ve just written I a reminded that it is a good thing to create a CMS Cluster that only contains one CMS. There are no negative impacts that I know of and this allows for scalability as you can easily add in a CMS to the cluster with this already configured.