Domino Thoughts

Have you ever deleted a user from Domino and added them to the Deny Access group only to have HR come back and say, "We've rehired John Doe and he needs back into Notes right now." Of course you have, and if you've ever done this,  you may have come across an issue trying to get the user connected back in after removing their name from the Deny Access group and trying to get the user setup in Notes again. This is because the NameLookup cache hasn't expired.  

To get the user on to the server, you can issue the command "show nlcache reset" on each server they need access to. So if you've got a mail server, directory server, catalog server, Sametime server, app server that they need to get on to, you'll need to go to each server's console and issue the command.  Or, you can use the Send Command to Selected Servers dialog in the admin client to send the command once to all the servers you want.

Another use for this command is if a user changes their Internet password and it "isn't working" - submit the command and they'll be able to get in.

Working on an issue with directory assistance this morning - an admin had created a new directory database to support external users and added it to the existing DA.nsf.  While testing the database, the test external users couldn't login - got an invalid password error everytime.  Reviewing the configurations, everything looked fine.

I got involved and enabled debug_directory_assistance=1 and debug_namelookup=1 and started testing.  The debug output revealed that the search wasn't hitting the new directory database, even though a "show xdir" showed it was there and further checking revealed it was configured as expected.

Then I went to look at the design and found out something interesting. There were duplicate views and forms in the database, and the database was using a "newer" design than the server.  After replacing the design of the database and rebuilding the views, the users were able to login successfully.

There is a technote that describes this situation as well, though it refers to Domino 7, guess it isn't just that release ;). The important thing to look for is two "Directory Assistance" views visible in the view navigator. If you see this, you'll want to replace the design.

As many of you that know me are aware, my son Andrew has cystic fibrosis. He's 15 now, a freshman in high school and on the freshman baseball team and also participates in Model United Nations. He's pretty healthy for someone with the disease and we're very grateful.

Great Strides is the biggest fund raiser for the Cystic Fibrosis Foundation and I'm asking for your help. Please make a donation by clicking the link here, or use the button on the right side of the website. The CF Foundation is the biggest supporter of research to find a cure and development of new therapies for CF patients.  

Please watch the video by comedian and long-time CF Foundation supporter Lewis Black ("The Daily Show") for more information. Thanks!



You can find more info at his site - http://andrewsangels.com

Working with a client recently, we came across some unusual behavior with one mail file. The user reported that his database had gotten to be 64GB and he wasn't sure how.  Looking at the database properties, it did show up as 64GB, but there were only around 10K documents and the percent used in the database was around 3%.  Something wasn't quite right.

Running a compact -c managed to get the database back down to around 2 GB, but over a few days, the database grew again to where it was 7 GB with no document growth as the user was archiving documents as well.  I created a new replica of the database and monitored the size for a few days and it remained steady, nothing like the original.  Looking at the database properties on the original database, I found that the Advanced Database property to "Optimize Document Table Map" was checked for some reason. This isn't the normal setting for a mail file, and apparently there's a reason for it.



While this setting is supposed to improve performance of databases, in this case it didn't. This may be due in part to the use of views that are Form specific can cause too many documents to be eligible for inclusion in a view - I'm not a developer so I can't be definitive about it.  

To fix this issue, a compact -f was executed to disable the setting and correct the database size. After that was done, the database has seen "normal" growth since.

So the lesson here is - just because you read that something is good for you, doesn't always make it so.

I came across a Twitter post that referenced a Facebook photo gallery (Facebook login required) that a user posted regarding all the crashes and fault reports he was filling out, and evidently not getting any response.  Reading the comments the user adds, he isn't getting a response from the recipient of the comments.

The fault report can be a valuable tool in resolving issues - or it can send your users further over the edge if not used wisely. Here are my suggestions if you're going to enable comment collection on the fault reports:

1. If you're going to ask your users for comments after a crash, you better read them and act on them.  They are already "unhappy" about whatever lost documents/data they were working on, don't make it worse by not doing anything with the information they give you.


2. Respond to the comments. Acknowledge the user's comment so they at least think you're doing something about it. That way the user gets that "warm fuzzy" feeling that you care. This alone can help win a user over.


3. If you don't want the comments, configure the ADC to just submit the crash files in the background so the user isn't involved. This way you'll get the information you want, and not make your user any more upset than they currently might be.


4. Actually look at the diagnostic reports and see what's going on!!  I can't tell you how many times I take a look at a customer environment where they have diagnostic collection configured and just ignore it - it's a black hole that apparently no one cares about. Well, my friends, that's the first step to user/management anger and enough reason to find something else that "works" better.  

One more thing, if you collect the crash info, run the analyzer task on the database so you can see if there are some issues occurring more often than others and then find the fix. Many times there's a Hot Fix or update to a new maintenance release that resolves the issue. Things you can push out easily with SmartUpgrade - this is where it really proves useful.


IBM Tech Note - What is Automated Diagnostic Collection?

N/D 8.5 Admin Help - Setting up automatic diagnostic data collection on clients

We're working with a customer on deploying a custom app to some users' Blackberry devices and everything so far has gone well.  One user called to say that they haven't seen the icon on their device yet. Going through the BES policy logs (thankfully, one of the smaller logs), I found that the user was causing the following error to be written to the log:

[20000] (09/15 13:47:13.750):{0xB70} {username@domain.com, PIN=XXXXXXXX, UserId=419}PollForMissingApps: GetHHCodePackages reported: HHCM_DEVICE_NOT_SUPPORTED.  Upgrade your copy of device.xml

Device.xml is the "master" list of Blackberry devices.  It includes model numbers, networks, and other information.  It is something that is copied into software packages by the apploader.  If the device isn't listed in the device.xml file, the software doesn't get deployed.  Checking the BES, the user had a model 8830m and our device.xml on the server didn't know what that was.  So there you go... any devices put out since this client's BES software was installed - and it's not that old, would be excluded from installing software.

To resolve the issue, you need an updated device.xml.  Where does one obtain a new version if they aren't ready to install BES 5.0?  Why, update your Blackberry Desktop Software, of course.  There's a RIM technote that tells the reader to just install the desktop software on the server, but why install Desktop software on a Server, especially when all you need is one file?  How about this - update the Desktop software on your Desktop and copy the file you need to the server?  The device.xml file is kept in c:\Program Files\Common Files\Research in Motion\AppLoader.   You need to replace it in the similar location on the BES server.

Next, on the BES server, go to the :\Program Files\Common Files\Research in Motion\shared\applications folder and in each application you've deployed, delete the PkgDbCache.xml and the specification.pkg file.  Also, go to the :\Program Files\Research in Motion\Blackberry Enterprise Server\PackageCace folder and delete all the subfolders in it.  

Now you can open up a command prompt and go to :\Program Files\Common Files\Research in Motion\AppLoader and enter the command "loader /reindex" to rebuild all the packages and include the updated device.xml.  

If you need to resend the software to the users, you can go into the Blackberry Manager, right-click on the user's name and choose the "Deploy Applications" action to force the policy to be checked.  Once this was done, the user's device picked up the software deployment policy and downloaded the application.

So, if your users get new devices quicker than you update the BES software, you'll want to check the device.xml file and update it before you deploy a custom app to them via the BES.

And one other item - what's with the using "you" and "your" for errors that reference the server.  Why not make the error "Upgrade the copy of device.xml on the server" - that's much plainer and easily understood.  By no means is this the only instance I've seen that type of error, but just thought I'd throw that out there.

We've seen this at a couple of clients recently running Domino 8.0.x. A user sends an email to a known, valid email address and it gets rejected.  The user receives a Delivery Failure Report with a generic "SMTP Permanent Error" message.  We get involved and look at the log and notice that the server which the message was sent to was "domain.com".  Looking up the MX records, we find that the MX record should be mail.domain.com or sometimes mail.hostingprovider.com.  Domino is using the domain's A record to send mail to for some reason. Evidently the cache used by Domino is incorrect.  Stopping and starting the router resolves the issue for the near term, but we have seen this come back periodically.  

There's a technote that talks about this issue. The workaround is to create a program document that periodically calls the "tell router update config" command which forces the router to clear the cache and try all pending messages again. We normally will set the program to run once an hour to reduce the possibility of a user reporting an issue.  There also may be a hotfix for this if you contact IBM Support. The technote refers to Domino 7, 8 and 8.5 as possible releases where this can occur.

For those that may not know how to create a program doc that calls a server console command:

1. Create a new program document in the Domino directory.


2. On the Basics tab, the Program field should have "nserver" entered.


3. In the command field, enter "-c "tell router update config"".


4. Change the schedule to whatever you're comfortable with.


5. Save and close the document.

My son Andrew has Cystic Fibrosis, a life-threatening genetic disease. 30,000 children and adults in the US have CF. Even as recently as the 1980's, the average life expectancy of a CF patient was less than 15 years.  Today, the average is 37 years. This is due to the remarkable research and the results of that research that is funded in part or in whole by the Cystic Fibrosis foundation.  The CF Foundation is now funding pharma companies to help develop treatments for the symptoms that affect CF patients as well as funding research to find a cure for CF.  

Andrew is now 14 years old, in eighth grade and looking forward to starting high school next year. He plays on two baseball teams and the school soccer team, as well as running around with friends. He is considered by his doctors as a very healthy CF patient, but still was hospitalized twice in the last 18 months for operations to remove mucus build-up in his sinuses, a side effect of his CF, as well as a CF "tune-up."  

This is an exciting time for CF researchers and CF families. One of the drugs funded by the CF Foundation is in Phase 2 trials. This drug treats one of the basic causes of CF, and the results so far are very encouraging.

The Great Strides walk that my family will participate in next month is the major fund-raising effort of the Cystic Fibrosis Foundation and provides the funds to support the types of research that are yielding fantastic results.  Please consider making a donation at my walk page to help us find a cure for Andrew and everyone else that has Cystic Fibrosis. Ninety cents of every dollar donated to CFF goes towards research and other efforts to support CF patients.

Please donate and help Andrew and others with CF. For more information about Andrew and CF, check out the Andrew's Angels website.

Thanks!

Next Tuesday, April 14 is the Los Angeles area LCTY.  The venue has moved due to responses from the IBM El Segundo facility to the Embassy Suites - LAX South.  If you haven't RSVP'd yet, you better do it quickly, go to the IBM website and sign-up today.

I will be at the event, so if anyone wants to meet up afterwards for a beverage, add a comment or email me.

PS - If you're in Florida next week Lotus911 is sponsoring LCTY events in Tallahassee and Jacksonville on April 14 and 15, respectively. Go to http://www.lotus911.com/register to sign up.

Too funny...a driver's truck drives off on its own at a 7-11 store in Laguna Beach.



The story