Monthly Archives: December 2010
Join me on Sametime via BleedYellow.com
Hey, why aren’t you on Sametime at bleedyellow.com? Get with the program. With all this talk about social media, If you’re not on this public Sametime community, you’re missing out on one of the best ways to get connected to your fellow Lotus professionals, including me.
Here are the steps to connect to Sametime using the server at BleedYellow:
1. Visit http://www.bleedyellow.com and register an account. Be sure to use your real name.
2. Start Notes. Pull down File – Preferences, expand the Sametime preferences and click on Server Communities.
3. The first time you add a community, Click Reset User (If you are already connected to your internal community, just click the Add New Server Community button). It will prompt for new credentials. Enter the credentials that you just created at the bleedyellow.com website. For convenience, check the boxes to remember password and automatically login.
4. Click Login. It will log you into Sametime and return to the Preferences screen. Click OK.
5. Expand the sidebar by clicking on the Sametime icon on the right side of Lotus Notes.
6. Add contacts to your contact list. Click on the icon to add contacts. Follow the instructions on the screen to add contacts.
Now let me know you’re there so I can add you to my buddy list too. If you see the green dot by my name, it’s OK to send me a message.
Cheers,
-David
The Notes Guy In Seattle, but serving clients around the world.
The Secret to Keeping the junk out of your Sent folder
Quick Tip: This will help keep the junk out of your sent folder and keep your mail file smaller.
Step 1: Create a folder called “Delete Later” (or just use the Junk folder).
Step 2: ALWAYS use Send and File instead of Send. If the message is important, it should be filed into the appropriate folder. If it is not, then file it in the “Delete Later” folder.
Step 3. Whenever you get a quota warning, start by deleting all the messages in the Delete Later folder.
If I had it my way, the option to send without filing a message would not even exist. I preach this method to my users and have seen some users trash 1/4 to 1/3 of all their sent mail using this method. That’s a huge savings of space and clutter.
If you liked this tip, please rate it and spread the word. If you didn’t, please keep it a secret.
Making a REAL difference in your inbox management. (HINT: Don’t use Domino inbox maintenance!)
When I was in college, I had a professor who demanded all computer programs be written modularly, broken into logical functions and procedures that were short enough to be viewed on one screen without scrolling. We would get a one letter grade deduction for each procedure in the program that did not fit on one screen. (at that time, one screen was 25 lines) His reasoning was that troubleshooting a unit of code was vastly more difficult when the entire piece could not be viewed at one time.
This same best practice applies to most everything you view on the computer including websites and INBOXES. That’s right. The moment you have to scroll your inbox to view all the messages, you have reached the point of functional breakdown. Once you have to scroll the inbox, those messages not on the screen are less likely to be looked at ever again and it is very unlikely it will ever get back to not scrolling without radical action. Why? Because it literally becomes endless. That is, you can’t see the ends. Other than the size of the slider in relation to the bar, there is no way to tell how many messages are in the inbox. And as the saying goes, out of sight, out of mind. It is vastly easier to keep an inbox to less than one screen full than it is to reduce an inbox to one screen once the scroll bar appears.
Some people would have you believe the Inbox Maintenance feature is the greatest thing to come along for maintaining your inbox. WRONG. All it does is hides the problem and makes it even harder to fix later. Once you remove the messages from the inbox without adding them to another folder, they become lost in the morass of the All Documents view, forever inseparable from the messages that have been properly filed except through creative coding of an agent. Sure, that will temporarily improve server performance, but it does not go far enough to address the real problem: degraded human performance. The server will tolerate an inbox with several hundred messages. But humans performance degrades as soon as they don’t all fit on one screen. (This is the one advantage of using the preview pane on the side rather than the bottom.)
WHAT YOU NEED TO KNOW
Step 1: Empty your inbox.
– Create a folder called “Inbox 2010”
– Open your inbox and select all messages. All of them. On a PC type Ctrl-A to select all.
– Drag them to the new folder you just created. You now have an empty inbox. You can always go back and deal with those messages you moved when you have extra time. But we both know that won’t happen.
Step 2: Keep the inbox empty for as long as you can.
– Make it your goal to eliminate all new messages promptly. Whenever possible, process each one only once. Read it, act on it and delete or file it. Much like a video game, your goal is to “kill” the emails. You lose as soon as your inbox gets large enough to scroll.
Step 3: Game Over: Start again.
– When you get the scroll bar for the inbox, repeat step 1 again.
You can simplify the process of filing messages if you install Swiftfile, the free add-on from IBM that learns your message filing habits and gives quick links for the 3 folders you will most likely want to file the message. In just one click the message is filed and next one opened. (see screen shot)
For more on this topic, check out the book Getting Things Done by David Allen.
Notes Admins: It’s that time of year. Remember how to create those holidays for importing into calendars?
It’s December. By now your HR department should have published the holidays for next year for your company. But did you add them to your Domino Directory and did you let HR tell people how to add them to their calendars? Shame on you if you didn’t. But it’s not too late. Here is a quick reminder of the steps:
- Get your list of holidays from HR for each country you have users. Remember, they are different around the world.
- Open the Domino Directory and go to the view: Configuration – Miscellaneous – Holidays
- There are already national holidays listed, but leave those alone. Those are the official holidays which may not correspond exactly with the days your company takes off. Instead, create a new set of holidays. When you do this, put them into a group named appropriately, for example “2011 Office Holidays – Canada”. I like to put the year first so it is easier to find in the list.
- If you already have a holiday listed, just edit it and update the dates and change the group. Be careful about repeating the entry for more than one year. Most HR departments don’t finalize the holidays more than 1 year in advance and they don’t always follow a set rule, so talk to your HR department first.
- Tell your users how to import the new holidays. Repeat this information again in January when everyone is back from their vacations. Some people who have a lot of vacation to burn are already gone for the year and won’t go back to read your message. Ideally, this message would come from HR and would be included where ever they post the holiday list.
You should also ensure new hires are given the instructions on how to import calendar entries. And just in case you forgot how to do that…
- Open your calendar.
- In the Action buttons, click on More – Import Holidays.
- Select the groups of holidays you want imported. Here is where you’ll be glad you put the year first. If you work with users in other countries, you may want to import the holidays for those countries too.
Consider this my holiday gift to you. Happy Holidays!
(You read it, now please rate it.)
How to build a predictable server replication scheme
One day your CFO calls you at 9:45 AM and says “London is waiting on the financial report I just updated in the Notes database. When will that get replicated over to the server in London so they can work on it?” You think to yourself “I don’t know, first it has to go to the hub and then to the London server and the schedule for each is every 60 minutes from 12:01 AM to 11:59 PM. That’s two replication events, so it means it could happen anytime between right now to 2 hours from now.” So you say to her “I’m not sure, but I can force that over right now.” You drop what you were doing and go to force the replication process. Has this ever happened to you?
Well with proper planning your answer could have been as simple as “Sure, the hub replicates with your server every hour on the hour and then with the London server 10 minutes past the hour. Your data will replicate to the hub at 10:00 and at 10:10 it will replicate to London.” She hangs up happy and you go back to your work.
In my years supporting a broad variety of environments ranging from 5 to 90,000 users, I have figured out a number of tips like this one that can make a big difference in the operation of your Notes environment. When I shared them with my friends at IBM services, they adopted these as best practices when working with their customers. I would like to share those tips with everyone.
When it comes to monitoring replication events, it’s easier to troubleshoot replication issues and to predict when replication will occur if the replication times are listed explicitly in the connection document instead of using a time range and interval. The reason is the replication interval starts when the previous replication event is finished. So if the replication interval is set to 60 minutes and the first replication starts at 8:00 AM and takes 5 minutes to complete, the next replication will occur at 9:05 AM, not 9:00 AM. Then the next will be at 10:10 AM, etc. causing a drift in the replication time. You can avoid this drift by explicitly listing the replication times. To define replication to occur at an explicit time, the connection times should use the format “8:00 AM; 9:00 AM; 10:00 AM” etc. and the interval should be “0”. Also set a replication time limit with a value less than the interval so replication events do not overlap. Explicitly defining the times is particularly useful when data must travel through multiple servers to get from one end user to another and a fast, predictable delivery time is needed. This is more efficient than setting the replication interval ridiculously short to compensate for the seemingly unpredictable nature of using the time range/interval method.
Now let’s say you have a hub server that is running 4 replicator tasks and you need it to replicate hourly with 24 different servers. You can schedule it to replicate with 4 servers at a time, 10 minutes apart. so a part of that schedule might look like this:
From to Schedule
Hub Mail01 7:00 AM, 8:00 AM; 9:00 AM; 10:00 AM; 11:00 AM; 12:00 PM; 1:00 PM; 2:00 PM; 3:00 PM; 4:00 PM; 5:00 PM
Hub Mail02 7:00 AM, 8:00 AM; 9:00 AM; 10:00 AM; 11:00 AM; 12:00 PM; 1:00 PM; 2:00 PM; 3:00 PM; 4:00 PM; 5:00 PM
Hub Mail03 7:00 AM, 8:00 AM; 9:00 AM; 10:00 AM; 11:00 AM; 12:00 PM; 1:00 PM; 2:00 PM; 3:00 PM; 4:00 PM; 5:00 PM
Hub Mail04 7:00 AM, 8:00 AM; 9:00 AM; 10:00 AM; 11:00 AM; 12:00 PM; 1:00 PM; 2:00 PM; 3:00 PM; 4:00 PM; 5:00 PM
Hub Mail05 7:10 AM, 8:10 AM; 9:10 AM; 10:10 AM; 11:10 AM; 12:10 PM; 1:10 PM; 2:10 PM; 3:10 PM; 4:10 PM; 5:10 PM
Hub Mail06 7:10 AM, 8:10 AM; 9:10 AM; 10:10 AM; 11:10 AM; 12:10 PM; 1:10 PM; 2:10 PM; 3:10 PM; 4:10 PM; 5:10 PM
Hub Mail07 7:10 AM, 8:10 AM; 9:10 AM; 10:10 AM; 11:10 AM; 12:10 PM; 1:10 PM; 2:10 PM; 3:10 PM; 4:10 PM; 5:10 PM
Hub Mail08 7:10 AM, 8:10 AM; 9:10 AM; 10:10 AM; 11:10 AM; 12:10 PM; 1:10 PM; 2:10 PM; 3:10 PM; 4:10 PM; 5:10 PM
Hub Mail09 7:20 AM, 8:20 AM; 9:20 AM; 10:20 AM; 11:20 AM; 12:20 PM; 1:20 PM; 2:20 PM; 3:20 PM; 4:20 PM; 5:20 PM
Hub Mail10 7:20 AM, 8:20 AM; 9:20 AM; 10:20 AM; 11:20 AM; 12:20 PM; 1:20 PM; 2:20 PM; 3:20 PM; 4:20 PM; 5:20 PM
Hub Mail11 7:20 AM, 8:20 AM; 9:20 AM; 10:20 AM; 11:20 AM; 12:20 PM; 1:20 PM; 2:20 PM; 3:20 PM; 4:20 PM; 5:20 PM
Hub Mail12 7:20 AM, 8:20 AM; 9:20 AM; 10:20 AM; 11:20 AM; 12:20 PM; 1:20 PM; 2:20 PM; 3:20 PM; 4:20 PM; 5:20 PM
While I’m talking about replication times, I should mention that it’s wise to not have any replication going on while the nightly maintenance tasks are running, like Design and Compact. This is usually between 1:00 AM and 4:00 AM. (Check your program documents and the “ServerTasksAtn=” parameters in the notes.ini.) If you have servers in different time zones, be sure replication does not occur between them during the maintenance window of either server. For example, if you have a server in London (time zone GMT) and another server in New York (time zone GMT -5) and they both have a maintenance window from 1:00 AM to 4:00 AM, then from the London server’s perspective, no replication should occur between the times of 1:00 AM – 4:00 AM or 6:00 AM – 9:00 AM GMT. From the New York server’s perspective, no replication should occur between 8:00 PM – 11:00 PM or 1:00 AM – 4:00 AM EST. If you have more than two or 3 time zones to deal with, create a table and indicate the maintenance window of each server in its local time and translate it into the time zone for each server that replicates with it.
This may seem like a lot of effort compared to using a replication interval, but this little bit of planning makes a huge impact on managing large domains. It will also help preserve your sanity. (I have constructed a replication schema that involved 200+ servers replicating through 4 hub servers spanning 20 time zones and these techniques were absolutely essential to make it manageable and predictable.)
Regarding mail routing using connection documents, even though there is an option for “Pull-Push” on the router type setting, the actual behavior of pull is to tell the other server to push. As a result, if there are any firewalls between the servers, the firewall rules must allow both servers to initiate a conversation on port 1352 for NRPC mail routing. This also applies to mail routing via Notes Named Network (NNN). This is critical because if two servers are in the same NNN, but the firewall prevents either server from initiating the conversation, then mail will fail. This is true even if there is a valid path between the two that involves a third server. If they are in the same NNN, they MUST be able to connect directly to each other.
In a hub/spoke configuration, let the hub initiate the replication so you only have to check one log to see the results.
A few other tips:
Create a view in the Domino Directory to display connections by both source and destination servers.
In a hub/spoke configuration, let the hub servers initiate the replication so you only have to check one log to see the results.
Create a connection that replicates from spoke to hub that runs once per day as a safety.
Always use DNS names rather than IP addresses unless that is not an option (like servers isolated via firewalls)
Do not use hosts file or lmhost file to define addresses.
Use Notes Named Networks for mail routing whenever possible.
Beware of putting servers in the same NNN that do not have a direct path between them.
Disable replication on Templates and change replication priority on templates to Low, then set connections to only replicate medium and high. Now they won’t replicate and they won’t report an error.
The Notes Guy in Seattle 