Lotus Nut

Tomorrow evening (Wednesday, June 24, 2009) we will have some downtime on almost all of the BleedYellow servers. This includes the Connections and Sametime servers. It's a planned, routine maintenance outage to load some fixes, etc...

Thanks!

Nope, I'm not talking about a blog for people into fast and furious 4 bangers (no offense to 4 banger drivers - like myself - who aren't fast or furious).

I'm talking about the new blog that IBMer Scott O'Keefe has started related to the Domino Configuration Tuner (DCT). You should go check it out at 'Tuner Blog. The first post is related to the "Check for Updates" option that's available with the template in which you can get the latest template from IBM as well as the latest updates to the rules. He also lists some of the new rules with the latest release.

You should really look into DCT if you haven't already. And with the 'Tuner Blog now active, I'm certain that Scott, et. al. will be looking for feedback!

Paul Mooney reminded us the other week that we should do this - and I agree! Over at Vaughan Rivett's blog, he's discussing some of the misunderstandings surrounding DAOS. He brings up several good points, but does question whether DAOS should be enabled on mail.box files. Of course, each situation may be a little different for every environment, so it's up to you to determine if you want to do this. But keep in mind that, like Vaughan states, DAOS is for any application - not just mail!

If I'm a daosified mail user and am using a CRM application to save a copy of an email message directly into the CRM, then if DAOS is enabled for the CRM application the attachment will be shared in DAOS! But if I want to send that email to a colleague and mail.box doesn't have DAOS enabled, then that attachment will be written to mail.box and then when it's delivered to the recipient's mail file DAOS would associate it as a duplicate from my mail file. But, if mail.box has DAOS enabled, then the attachment will never be pulled back out of DAOS (meaning there will not be the disk i/o associated with the transaction) and the router will know that it already existed in DAOS and not try to pull it back out. So, in most cases you will want to enable DAOS on your mail.box files. (Of course multiple server hops will not be aware of this currently, but for mail users on the same server it should be ok.)

Also remember that you'll need to enable transaction logging on your mail.box files. This may mean that you will need to disable the notes.ini settings for MailBoxDisableTXNLogging=1 and/or RM_NO_LOG_LARGE_OBJECTS=1. You will also need to manually enable transaction logging on the database with the router off by using load compact -T on each of your mail.box files.

By default, BES debug logs are enabled at installation. They are not only enabled, but they have no roll-off time specified. I have seen this cause drive space issues (not to mention performance issues associated with so many heavily fragmented small files...)

To remedy this, you can open the BlackBerry Server Configuration and go to the Logging tab. From there, you will need enable the "Debug log auto-roll" and specify the number of days you wish to keep the logs in the "Debug log maximum daily file age" settings. In the example below, we will only be keeping 30 days worth of logs. After restarting the BES task and all of the BlackBerry Services, the files will be automatically purged.



Some notes:

You may just wish to restart the entire server instead of each of the individual services.

The daily folders will still exist, so do not panic if you still see them. They will exist because of three log files. By default, all BB phone calls are also logged. This is how your phone call logs get restored when you activate a new device. There are also some 2 SMS and PIN messaging log files. These are empty files by default, but administrators can enable this logging (without you being aware of it, by the way - you did know this, right?).

So go ahead and clean up your BES servers and try to remember to modify these logging parameters when you install the server (note to self...).

We've started a new shared blog: BleedYellow Site Feedback. Make sure that you subscribe to it to receive announcements on site updates, maintenance, downtime, etc... as well as some general posts to respond to questions that people may have.

The first post is about some scheduled downtime Saturday evening.