I feel like talking like a cave man because the concept is like starting fire when people start to understand the benefits.
For a long time, I’ve been a pundit of “DON’T USE STATIC IP CONNECTION DOCUMENTS!” Not everyone will listen, maybe because I sound like a radical cavalier consultant admin who knows everything – offering up such new fangled ideas to an organization who does not have a global active directory container or single company-wide DNS suffix.
Here’s why STATIC is so bad: Read the rest of this entry »
Posted by david, filed under Administration, Client config, Connection Docs, Standards. Date: March 27, 2008, 10:38 am | No Comments »
Today,
I received an email/phone call/IM about a super-VIP user who’s mailbox in South America had a problem.
This user travels frequently, has a 23GB mailbox, and refuses to carry a laptop. He travels from his Swiss office to Hong Kong, Singapore, and South America.
When he arrives in Argentina, he expects his replica to be up-to-date without problems. The issue is that the database is 23GB and the comm links to Argentina are very slow, so sometimes, replication delay can be up to 2 or 4 hours.
What I suggested that we do is to create his mailbox on the clustered servers in Argentina and then get the Swiss and Argetina local IT staff to coordinate with us every time he is going to travel so that we can change his home mail server. This will mean that mail will not need to replicate to the Argentina server from Switzerland, through the hubs in Hong Kong before he will receive it in his Inbox. Read the rest of this entry »
Posted by david, filed under Administration, Error Message, Inbox, NotesPeek. Date: March 25, 2008, 12:55 pm | No Comments »
The directory catalog is supposed to be used for mobile users so that they can address mail to users or groups remotely without having to have a replica copy of the huge NAB on their laptop. For some organizations, this is not a big deal, they can just create a local replica of the NAB if it’s small enough.
For other organizations the NAB is 1GB plus in size, and managing that on a local replica for all users, and even the possibility of security vulnerabilities can be a big issue.
Other environment use dc.nsf so that their users can search via first name instead of last name. (seriously, it happens).
Let me explain how it works: Read the rest of this entry »
Posted by david, filed under NAB, dircat. Date: March 18, 2008, 3:50 pm | No Comments »
Thought this is an option in the notes client when sending email, you can easily get around it by clearing the $KeepPrivate field.
Or alternatively, just hit the Printscreen key on the keyboard or use any other screen capture software.
Posted by david, filed under Tricks. Date: March 18, 2008, 3:20 pm | No Comments »
Last night, one of our admins accidentally replicated the R8 pilot server address book to a R6.5.6 production server address book through his notes client.
This royally screwed up the 6.5.6 address book. Some of the servers rebooted themselves, mail wouldn’t route, dc.nsf appeared to be out of order, etc.
We fixed it by manually replacing the address books on the bad servers at the file system level with a good copy from another server that hadn’t replicated the bad design yet. Another option to keep open is to keep a local replica of the NAB on all of your admin clients, and set your admin clients only to replicate with the server ever hour, 2 hours, or 4 hours. This way, the local replica copy of the NAB on the admin clients is pretty much up to date, but if something happens, it gives you a bit a time to discover that something is wrong. It’s not a perfect solution, but good (possible) option to have in place when you notice that something is very very wrong. A scenario might be that you discover your NAB is bad, and your local admin client hadn’t replicated for 3 hours and does not have the bad design. This can save you. Read the rest of this entry »
Posted by david, filed under Administration, NAB, R8, Templates. Date: March 18, 2008, 3:07 pm | No Comments »
We have sites in South America where network connectivity is very unreliable. We have MPLS lines connecting the remote offices in those locations, and we also have Internet access from each of the offices.
When setting up our replication/mail routing architecture in these locations where connectivity is unstable we got a little creative.
First, we have our hub servers in the Home office in Hong Kong. These hub servers do all of the replication from Hub to spoke. This cuts down on the overall replication overhead on the network. The idea is that cluster cache doesn’t have to be rebuilt every time if we have only the hubs replicating to the spokes. At the end of the day, network utilization and time required to replicate is actually lower.
We also put clusters in each site. This alleviates downtime in the event that one of the servers goes down. Since we have clusters, we can set the connection document to replicate with the cluster instead of the individual servers. This provides much benefit because replication still occurs if one server is down. It also reduces the network utilization in half because replication will only occur one time, to the cluster, instead of twice to each individual server. Read the rest of this entry »
Posted by david, filed under Administration, Connection Docs, Failover, Mail Routing. Date: March 12, 2008, 3:30 am | No Comments »
We have two hub servers in our environment that are clustered.
We use these as replication hubs to all of our spokes (local and remote sites). Additionally, these act as sort of a mail hub since all of our remotes sites are not directly connected to our home office site. Lastly, they also serve as outbound SMTP gateways.
Any mail that is sent from Chile to a user in Spain gets routed through Hong Kong since their is not a direct connection from Chile to Spain.
All servers in each site are in their own NNN (Notes Named Network). The Hong Kong site servers are in their own NNN. The hubs are in their own NNN.
This allows us to route mail through Hong Kong where necessary using mail connection documents. Read the rest of this entry »
Posted by david, filed under Administration, Connection Docs, Mail Routing. Date: March 12, 2008, 2:40 am | No Comments »
I take a look at our admin4.nsf database every morning as part of the things that I “check on” in our environment.
I usually look for pending deletes that other admins in other regions don’t have the access to approve, or don’t know to approve.
I also look at the errors to see who is using an ID file with a public key certificate that does not match their person document. This error pops up when they are using a certificate that is different than the one their person document was generated with.
This disallows adminp to update the Internet password field with their Lotus Notes Client ID file password. That option is set in the user security preferences on the Security Basics tab. Read the rest of this entry »
Posted by david, filed under Administration. Date: March 12, 2008, 2:18 am | 1 Comment »