BOXI Grooming: Prune Your Input and Output FRS
Origin of a Cluttered FRS
Business Objects XI has a way of making more sub-folders than files. Seriously, take a close look at your Input and Output File Repository Servers, or rather your FRS on the disk. You will notice a crazy number of folders. As objects get deleted in Business Objects XI their corresponding files are removed from the FRS; however, their sub-folder is not. Since there is nearly a 1 to 1 ratio of files to folders this lack of folder clean-up leads to a lot of empty folders and an inefficient FRS (and any resulting file system back-up).
Keeping Your FRS House in Order
Since you see the most efficient system, you want to clean up this folder mess. Well, BO has a tool for that and you already own it. You can invoke it merely by putting the command-line parameter “-prune” on the Input FRS and the Output FRS.
Making -prune Work for You
I recommend that before you start you shut down your BOXI system’s web front-end. This will keep users from receiving errors or possibly impacting the prune activity. Yes, this requires downtime to do it properly and only experience will tell you how long it takes (depends on how much mess needs to be cleaned and how fast your servers are). Now in CCM shutdown your FRS servers.
Do the next steps one at a time unless you are in a rush. Modify the command-line parameters by appending the parameter “-prune”, be sure to include a space between it and the final parameter that was present before you started. Also you can add “-trace” as a switch to capture a log of the actions.
Completing your FRS Prune
Now start the FRS that you just modified and you will observe that it maintains a “starting” status until it finishes. You can watch it through your servers task manager, top, or other corresponding process manager. You could also watch it through the log file it creates with the included “-trace” parameter. When it finishes, remove the parameters you added and proceed to the next one. If both have completed the prune then you are done and as long as you removed the parameters that you added you are ready to roll.
Additional Information
I suggest counting sub-folders and files before and after. This will help you understand the impact of what you just did. Please keep in mind that the “PRUNE” command does not clean-up any dead pointers (objects in the CMS that lost the files the point to). Prune only cuts the dead branches and it doesn’t touch a single leaf or leafy branch. Enjoy the analogy 
More FRS Prune Resources
Over at “let’s learn business intelligence” they have a good video walk-through of a real, live FRS prune on a BOXI system. Check it out: http://www.letslearnbi.com/2009/05/business-objects-prune-and-trace.html.
Tips for Installing FixPacks in Business Objects XI 3.1
Lately I have been faced with the need to install a FixPack on one of my Business Objects Enterprise XI 3.1 systems. Doing so has reminded me of some key points and tips that I wanted to share with the Business Objects community. FixPacking BO 3.1 is truly a different experience:
Not Your Father’s BO FixPack
Like everything else in life, FixPacks have changed and evolved with the Business Objects product. Some of the notable changes for BO XI 3.1 FixPacks are:
- FixPacks are no longer suite wide. You need the FixPack for the specific Business Objects product you wish to patch (such as Enterprise, Live Office, Crystal Reports 2008, etc.)
- You must first install the patch on a node where a CMS server is located. According to some SAP-BO support engineers the safest choice in a distributed environment is to install the FixPack one node/machine at a time. So if you have multiple CMS nodes, install on those first one at a time, then install on the other servers one at a time. This makes for a VERY lengthy FixPack deployment, but it is the safest method. I have also had several senior support engineers confirm that the only requirement is to patch 1 node hosting a CMS first, then after that patch is completely started you can patch all of the rest, staggering them by 5-10 minutes each.
- Stop all BO servers except for a single CMS, Input/Output File Repository Servers, CMS database, and Server Intelligence Agent (SIA). If a CMS in the cluster is not up and running the install will not work properly or at all (this is true for all servers, regardless of their role). The SI Agent must also remain up on all nodes to be patched.
- Czech and Finnish Language Packs are now available (as of FP 1.3/1.4)
FixPack Installer Beware
Here are a few cautions/warnings that stand out to me:
- EVERY Business Objects component must be on the same version. If you patch a dedicated CMS server, you must also patch any other nodes that are a part of your cluster, such as processing servers or Live Office servers, etc. Also any clients, Designer and DeskI need to be patched as well. Another reason to use WebI exclusively, no client patches needed (unless we are talking about WebI Rich Client).
- Don’t forget to redeploy the patched BusinessObjects web components. The deployment method will vary based on your original web component deployment.
- Temp Directory: When working with the Windows Installer Package, be sure to either manually extract the installation files to a desired location, or to change your user’s “TEMP” environment variable to the true location to which you want these very large and many files extracted. Actually, on second thought, ALWAYS change your “TEMP” path environment variable to a location with enough space (a few GB); I have seen the installer, in the midst of installing fill up my C: drive with temporary files that it works with after all of the unpacking and hours into the patch installation. Be careful here, plan ahead.
These are just a few of my notes and pointers for now on the top of my head. I will update this article later with my more complete notes or with any of your suggestions offered through the comments below.
