The logon account for that service was correct and had the correct access rights. Furthermore, Windows didn’t give me any warning dialog boxes when I tried to start the service manually, so I had to look somewhere else. Obviously, it had something to do with the changing of the account, so I started my quest for the answer, searching in that direction.

After a lot of suggestions saying I should just reinstall the whole BES with the new account, I came across this article in the Blackberry knowledge base: link. It wasn’t exacly the same problem I had, but it sounded familiar and I had a hunch.

It turns out that during the installation of the BES Express software, it writes a few registry keys to “HKEY_CURRENT_USER”. These keys are required by the “Blackberry Administration Service Application Server” service. The new account for that service, can’t see these registry keys because the are in “HKEY_CURRENT_USER”. Because of that, it cannot start.

The solution is rather simple:

1. Login on the server with the old account that was used for the BES services.
2. Open regedit on the server
3. Take a backupof the registry! This is not required but, you never know…
4. Go to the following key: HKEY_CURRENT_USER\Software\Research In Motion\BlackBerry Enterprise Server
5. Right-click on the “BlackBerry Administration Service” key and choose “export” and save this export somewhere that is accessible (Doublecheck that the export range is set to “Selected branch”).
6. Log off and log in again with the new account that is used for the BES services.
7. Import the registry keys that you exported in step 5 by double clicking on the export file.

After this, the “Blackberry Administration Service Application Server” service should be able to start again and you will be able to browse to the webinterface.

Bookmark:

At first, it looked like a successful upgrade, untill we tried to go to our webmail (iNotes). After logging in, we got the following error:
Formula Error [/mail/jdoe.nsf] CN=John Doe/O=Acme

A quick look into this problem, made us look at the file “Forms85.nsf” in the “iNotes” folder. This file had been updated with the new fixpack and apparently, this was causing troubles.

A fix for this problem is, ofcourse, reverting to fixpack 2. We also found that replacing the “Forms85.nsf” file with an older version fixed the problem. So you can remain at fixpack 3, except for that file. We used the “Forms85.nsf” file from interim fix 1 for fixpack 2 (DominoServer_852FP2IF1) and iNotes was working again.

If you’re planning on installing fixpack 3 on a server that’s also used for iNotes, make sure you test that functionality before rolling it out to your users!

Bookmark:

One interesting feature that has been added, is a defragmentation option for the Traveler database. This should help performance in large environments. The defragmentation will start once you start the Traveler server again after upgrading, and can take a while before it completes (more than half an hour according to IBM). So keep that in mind when planning the upgrade. IBM recommends running the defragmentation once a month. Keep in mind that the Traveler and HTTP task need to be shutdown before doing the defragmentation.

The update can be downloaded from Passport Advantage or IBM Fix Central. I did the update on our server and everything went smooth. I just ran the executable and worked my way through the installation wizard. After that, I started the Domino server again and was greeted by Traveler 8.5.2.3. I also ran the Traveler installer on my mobile and it notified me that there was an update available for the client. So all in all, an easy and straightforward update!

The release notes can be found here.

Bookmark:

Link: Lotus Notes Wiki

Credit where it’s due: thanks to Mary Beth Raven for writing the article and Lotus_BE (Twitter) for tweeting the link.

Bookmark:

By default, quotas in Domino are based on the filesize of a (mail)file. This means that quotas only decrease when you compact a database. This can be major annoyance for users when they are over their quota, because when they delete mails, the quota doesn’t decrease until the compacter task has run on the server (in most cases, this only happens at night so your users have to endure a whole day of “over quota” messages).

When you use transactional logging, you can set the router to check the quotas by their “space used”, instead of their actual filesize. In that case, when a user deletes a mail from his mailfile, the quota is immediatly adjusted. So the user sees his mailfile getting smaller “on the fly”. The actual size of mailfile on the server stays the same ofcourse. Because of this, it is still a good idea to let the compacter task run once in a while, to decrease the actual filesize.

To set this up, just go the the server document. Go to the “Transactional logging” tab and change the value of “Quota enforcement”. Default, this will be set to “Check file size when extending the file”. Change it to “Check space used in file when adding a note”.

Bookmark:

There are two things you can do:
1) Add the following lines to the notes.ini file of the Traveler server .
NTS_IPC_TCP_Port=50125,<name/ip>
NTS_IPC_TCP_Port2=50126,<name/ip>

This isn’t really the solution, but it does work in some cases. It forces the Traveler task to bind on a certain IP or hostname in stead of binding on all interfaces. In some rare cases, this can bring down the response time of the Traveler server.

2) This is the big one: add the following to servlet.properties.
ntstimeoutsyncas=230000

This will up the time allowed for the server/device to respond (in ms). The parameter won’t be in the servlet.properties file by default, so just add it if it isn’t there. The value can be anything so there is some room for adjustment. The value described above worked for me.
The servlet.properties file can be found in the Domino data directory and can be edited with any text editor like Notepad.

Bookmark:

A temporary workaround is changing the group type of the ACL group to “multi purpose” or “mail”, adding it to access & delegation and then switching it back to “ACL”.

The bug is described in SPR #RREN843DXM and according to IBM, this should be fixed in 8.5.3, coming in Q2 of 2011.

Bookmark:

The installation takes a while and probably requires a reboot of your server. It doesn’t require a lot of changes to your Domino configuration. One thing you will probably need to do, is enabling DIIOP on the server. Too bad they didn’t choose LDAP here.
The new webinterface looks good and provides a lot of features the “old” Blackberry Manager client provides.

BES Express is free of charge, but if you want to download it, you need to “order” it from the Blackberry site for $0. After that, you get your SRP identifier and CAL.
The form and downloads can be found here.

Bookmark:

It may seem logic that it doesn’t save the settings, if you don’t apply them anyway. But I haven’t seen this behavior on other setting documents before, so I think it’s save to say that this isn’t intended behavior.

Bookmark:

The fix and installation instructions can be found at IBM Fix Central.

Bookmark: