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\
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.
The Best Way to Stop a Business Objects Server
Minimal Impact of Administrative Actions on BOXI
I would like to think that I am unique in many ways, but I think that I am very similar to others when it comes to my desire to minimize the impact of my administrative actions on my Business Objects XI instances. One way that I accomplish this is to carefully shutdown Business Objects servers in a very particular and simple manner.
Changes to Web Intelligence Report Server Require Restart
From time to time we all make changes to our Business Objects environment. Frequently I find myself making changes to the the Web Intelligence Report Servers (WIRS). Whether it is tweaking command-line parameters, CMC properties, logging status, making some obscure registry setting, or even patching DLLs; I am changing my WIRS and I need to restart it in order for the change to take effect. In some cases, my client runs 24/7 and has no real downtime and in other cases I need to make the change immediately and I need them to take effect yesterday. 
The Cleanest Restart You Can Ever Perform
In most cases the changes I make will not take effect without a restart. However, if I go directly to the Central Configuration Manager (CCM) and just stop the server(s) and then restart it, any reports (edits, paging, refreshes, etc.) will fail on the user’s side (or for the scheduled job). So what can I do to guarantee this does not happen??? Disable the server. Wait. Stop server. Restart Server. Enable the server.
Detailed Cleanest BO Server Stopping Procedure
- Disable the server: do this either in the Central Management Console (CMC) or in CCM, which ever you prefer, but I think that internally BO engineers prefer to use the CCM (its the icon with the cylinder and check mark).
- Wait: there is no golden rule on how long to wait, any amount of waiting is still better than none. During this period the server is finishing whatever work it was assigned and the CMS is not assigning it any new requests. You can observe this on the metrics tab of the CMC page for the server (if your server has metrics). I generally wait 30 minutes and I watch the CPU utilization (CPU time) of the WIRS’s process (yes, in Windows) to see that it is dormant.
- Stop the server: this one is easy. Just go to the CCM and stop the server you are targeting. You can do this from any server in the cluster. You should watch the executable to be certain that it goes away, disappears, or dies.
- Restart the server: Again stay in CCM, allow for at least 15 seconds from the stop, but this will depend a lot on how long you waited since the disabling of the server, I mean if it still has any active threads it will take longer to stop (see previous step for proper shutdown before restart). Allow the server to get fully started and registered with the CMS.
- Enable the server: again use CCM or CMC to do this. I suggest you make sure the server is started for a period of 30 seconds before you enable it and let the CMS have it back for abuse.
Note: I believe this same technique should work well for all Business Objects server, not just Web Intelligence Report Servers.
Please let us all know if you have any comments, suggestions, or anything else on your mind loosely related to this topic by leaving a comment.
