Various Tips & Performance Considerations for Domino.
This is from our personal experience as Domino consultants. YMMV - Your mileage may vary -- more likely, your business environment may make other options more viable, more attractive.
MAIL FILE RELATED
1. Keep in-box size down
(e.g. plug for in-box maintenance - see ND8.x + docs)
In-box w/25% of docs in in-box saw 50% lower cpu load and 50% faster response time, than mail files were users had most docs in in-box.
2. Either give uses FT index for searching or prohibit simple search
(Prohibit simple search is 8.0 or higher database/application property.)
Non FT Index searches have 20% higher CPU hit. In addition, they tend to give better results especially since temporary indexes can only get so big.
Also, very large applications can have issues with re-building or bulding new FT indexes as it is done in the system temp folder by default (Can be changed to another drive.)
3. Better to have a fewer large e-mails than a tons of smaller ones as there is more to index.
However, this is usually off-set by the issue of diskspace. Eg. Get rid of the multi-store of attachments through DAOS.
If the mail files are 4GB to 10GB or higher, better to implement archiving of old documents as it also will clear the in-boxes, too.
4. Is this a webmail server? If so, what is your max iNotes attachment upload size?
Set the maximum HTTP upload attachment size to just under the max size in the mail server router.
5. In-line images are preferred by users, but not by admins.
In-line images drop out when forwarded and original was encrypted, or if converted from CD to MIME and back or vice-versa.
In-line images are more resource intensive (assuming they link to images in the local note and not the good spam from your favorite retailer).
6. IMAP is better than POP3.
ASPs love POP3 because you download the mail and they don't have to store, back it up, or restore it. The client software has to store it.
It's a nightmare of synching issues and where did that message go. Turn off POP, let the users do IMAP. Or better yet, add on Traveler.
7. Switch to OoO Service instead of OoO Agent
When all servers are 8.0 or higher, Notes clients are 8.0 or higher, and mail design is 8.0 or higher, it's time to finally turn on OOS.
Gotcha: There is a bug, where if OoO Agent is enabled during switchover in a mail file, the disable may not take. You may have to manually fix a user's mail file.
(delete the agent, profile settings, etc.) Don't let the gotcha stop you, though. Do the switch during a corporate vacation black-out period.
8. If privacy and corporate privacy/security is considered a "performance" metric, then turn off image loading for new emails.
Most email bulk mail senders (good or bad) want to track whether or not you have opened/read the email. They know if you've opened the email because one or more the images in the page is a tracker image.
If you do not want competition, solicitors, or bulk mail senders to immediately know if the email was read, then turn off the automatic displaying / loading of images for new emails.
Note this will not stop the user from manually clicking the "Show Images" link/button at the top of the e-mail. But this restores the control of the privacy back to the recipient of the email rather than the sender.
Administrators can force this selection, or the individual users can choose whether his/her images display.
SYSTEM MAIL RELATED
1. In-box maintenance can be a close friend.
But you may not have any work friends when the users have to go to All Docs to find that missing doc that you cleared out via the in-box maintenance policy.
Although I love this feature, I personally lean to an archiving policy. You can configure w/o policies on the server document, as well.
2. Once you turn on an archiving policy, you cannot really go back to nothing.
You can only change your mind on where. Choose carefully and be ready to manually move mail from the previous user set-up archives to the new company wide destination. (BTW, MW has a tool to migrate mail from one mail file
to another.)
3. DAOS is GREAT if users e-mail each other on same more server enough.
DAOS can save you bunches of hard disk space if:
- Your users do a majority of internal mail (which is more true for larger companies).
- Your users do a majority of e-mail to users on same server as you.
Potential Cons:
- DAOS requires Transaction Logging which requires dedicated hardware.
- DAOS puts all attachments on file store, which means you have to work w/backup techs to also use shadow or "hot agent" backup on attachments.
Small Company Alternative:
- Archive.
SYSTEM PERFORMANCE RELATED
1. One partition per server is slightly better. Than more than one on beefy hardware.
One Domino (e.g. /local/notesdata) partition uses up less processor (about 5-10%) and lest disk IO (about 5-10%) and slightly worse response time (about 1%).
The obvious "exception" is VMware VMs, the added flexibility and management of smaller or lower use Domino servers as VMs outweighs the extra system overhead.
2. If using transactions logs, keep the separate from OS and Domino data folder.
- LOCAL storage (Network storage is generally slower than local, and if network goes down, HUGE corruption can result.)
- Separate adapter/bus and drive from the Domino data and system data. Otherwise, the system might actually be slower, and MUCH LESS stable with very large mail-files and/or heavy use as disk I/O is much worse.
Example: 1000 users on a duel core 2.6 Mhz processor could see peak availability down to 25% and with 250ms response times (assuming network is keeping up). Same system with Trans-logging enabled on it will generally have faster reboot times because it can replay the most recent updates to an app/database.
3. Make sure backups are using either Shadow type backups or "hot agent" (open file) backup software.
Using regular file backup on open/in-use files/apps is always bad, and practically ALWAYS causes corruption. VMware snapshots of a Domino VM don't seem to cause corruption with local storage. The snapshot is backed up "hot", and is okay, because the open files are technically on a separate/new/temporary set of disks. Of course, you should not run multiple layers of snapshots, and should commit/delete the snapshots once the backup(s) are completed.
4. Antivirus updates on Domino will eventually kill you router and/or crash or conflict w/backup and Transaction logging software.
I have the most experience w/Symantec. Three times in the last 5 years, I have seen where an automatic update causes routers to crash after loaded and then crash at each automatic restart until the services are dropped out of the notes.ini. In all three cases, it didn't affect all servers in an environment, just a lucky few. The fix was always the same. De-install the Symantec server and remove the current config app, and re-install from scratch. As for the conflict with backup, we could not specifically find the smoking gun, but we found that when A/V was off, there was no issue with Tivoli backups and restores with transaction logs. To solve this problem both times, we updated the Symantec and Tivoli to same fairly current date releases.
5. Emergency Archive Trick
If disk space is critical on a server, admins can issue the load compact -a ... w/ -a flag (see help doc). This will do an archive now, rather than waiting for the next scheduled event. This is assuming that users have archiving enabled for at least a few of them.
6. DCT is a must tool to be run every year or so.
Domino Configuration Tuner tells you if you forgotten and left a debug parameter in that can hurt performance, it gives you various notes.ini variables, and other hints/tips to increase performance or reduce a bottleneck.
7. SANs are GREAT! Most of the time . . .
A good SAN is great because you do things like give Domino more disk space while the server is up-and-running. However, if the private network of the SAN has issues, or the SAN is having space or storage subsystem performance issues, then watch out. It's going to be a VERY bad day. Older servers w/lots of local storage makes for a great mail archive server.
Minimum SAN requirements:
a. Domino has dedicated disk subsystem w/separate cards/busses.
b. Keep minimum 80-100MB/sec throughput through all the components "end-to-end" DPAR chain.
c. Increase/maximize caches to minimize re-reads and maximize write speeds.
d. Do NOT share fabric, DAC (array controllers), and disk LUNs with other servers. Domino mail usage/load is inherently dynamic and unpredictable.
e. Know daily, seasonal, and yearly usage peaks before implementing the SAN.
f. Reduce SAN usage, by offloading "old" data to archive servers - especially useful, for large mail files with very big in-boxes and all document views.
8. Lots of Users on a Mail Server?
Yes, when / if...
a. It's good to gather them in mail sub folders say 100-500 at a time. It easier allows backup software and console commands to run on parts of mail folder. This can be very important for tight backup windows or running that compact or fixup at lower use windows.
b. Many more than 5000 users can be assigned a home server on a duel or quad core server if the concurrent usage is less than 2k or so. However, as mail files gradually go from 100MB to 10GB, the CPU and temp file indexing costs and memory costs of handling those mail files can cause a perfect storm. Signs of environment going bad = corruption. Are there people constantly going corrupt and you know it's not a "cold" backup? Then look for a significant load increase.
c. Cluster tasks also have a load. A separate NIC is really a must for any mail server. I'm also a fan of pairing for simply cluster fail-over than the more complicated 5 ways.
d. If you are in a mail cluster, make sure that your load (CPU, memory, and server availability index) is low enough to handle a fail-over. (2 servers = 50% load max individually. 3 servers = 66% load max individually.)
9. Disk Space Considerations:
a. Frequently compacting w/space reduction is great, but causes more fragmentation. This seems worse on Windows than Linux. If on Windows, make sure you maintain the 15% free space so you can defrag once a year or so. It will help you server disk I/O performance w/MS Windows 2003 and 2007.
b. Keep at least 10% free. The Domino server may be able to run hours w/ 0 bytes free, but you'll have mail.box and mail.nsf corruptions.
10. Keeping Domino and clients current generally will see improvements in scalability.
10,000 users simulated on 6.5 and 7.0 on same hardware showed 20% CPU improvement, slightly better disk I/O, and more than twice the memory usage. (notes.net)
12,000 and 14,000 users are R8 also saw CPU improvements, a little disk improvements (depending on transaction logging, DAOS, etc.), slightly higher network I/O (more features = more to transfer), and once again, more memory usage. As server memory has been much higher, the cost of more memory use is negligible for the CPU and I/O savings.
Mail Performance Optimization in Notes.ini:
NSF_DBUcache_max_entries=6100
NSF_DBcache_maxentries=6100
NSF_buffer_pool_size_MB=512
These deal with application caching. More and less disk i/o but more memory.
ConstrainedSHMSizeMB=2560
The ConstrainedSHMSizeMB depends on how much memory the Router task can have. In a 64bit OS, even if Domino is 32bit (like on Linux), it can still address almost 4GB, so you can see a big improvement since each server task can consume a lot of server memory for high utilization. The sys-epoll feature in the modern Linux kernel, and Domino 7 and higher auto doing the "tunekml" caused the Linux platform to see a 400% increase of max mail users. Now the Linux hardware even w/ the 32bit Domino limitation sees much closer load capabilities as the iSeries and 64bit Windows 64bit with 64bit Domino. Because 64bit memory means there is more to address, it also has more overhead, so immediately more memory was consumed as a base starting point.
Server_Max_Concurrent_trans=200
server_pool_tasks=100
These control port and transactions optimization for network I/O.
Port Settings:
Network Compression Checkbox: Compresses into less gabby and often, but larger packages and compresses data. Decent I/O but includes a small CPU hit.
Encryption: Encrypts the transmission using the keysize of the server and person ID key sizes. (anywhere from 512 w/R4 to 2048 w/8.0).
- Note: This would tempt you to do key rollover. This worked great for several clients, but can occasionally blow up somebody and cause weird issues for the server or client affected. If you are publicly traded, have PII, PCI, or SOX data, you probably have to have encryption on w/highest possible key size.
11. Network Performance:
a. Use Pull/Pull so you can "stream" replication. Streaming is much faster and keeps the network busy for bursts and overall saves I/O due to chunking of packages. I know if not by the "book", but those replication and mail hubs just sit most of the time anyway. Kill 'em and save yourself a few 1000 bucks if not on a CEO package.
b. Controlling mail routing slows down mail delivery than if all servers are in the same NNN/DNN. However, it can better manage network packets and pathways. Networks admins don't generally like the constant Domino chatter, they tend to like to keep it running along certain paths. One option I've seen multiple times, is limiting all of sites Domino servers to a set of switches, so to the chatter stays on the "Domino network".
12. Routing:
a. Have server connections documents doing Mail Routing, route with 1 document pending unless you have to pay telcom usage tolls on your telcom bills.
b. Think before setting up delayed larger mail size messages. Generally users forget it's one and end up sending same large e-mail multiple time which costs you more storage in the Sent folders, higher disk usage, and frustrated users.
c. If a larger install, I like having 2 servers which have Configuration documents allowing them to send SMTP mail outside the local Domain. Likewise, I prefer two Domino servers running SMTP with the Listener enabled in the server documents. This way you can setup secondary MX from your gateway or cloud anti-spam filter service/server so mail still flows.
d. Let servers keep the mail in the original formats (Notes/CD vs. SMTP/MIME). The transfer back and forth hurts fidelity. Most of the time, don't set the Person docs to choose a delivery type. Let it take the current/incoming type.
e. Set your mail servers max message size like this:
User mail servers: 50mb.
Hub/SMTP routing servers: 55mb.
Max iNotes upload size: 49.5mb.
f. What about CEOs and other VIPs who should get much bigger?
Put them all on one server and give higher message size limit in specific server configuration document. Watch out if they send mail to the peons. You might actually need to increase the peon servers max sizes then, too. Oh the fun.
13. Replication:
General Notes:
a. I personally like my rep connection docs to only do replication and my mail routing ones to only do routing. Add comments each time you make a change, so you know 3 years later why "this" is this way.
b. Unless you are connecting different countries and the amount of application replication is extreme, don't follow "the book". That "administration" server that does really nothing but registrations and adminP stuff for the Domino directory, isn't usually doing much. Make it the replication hub. Or if you have mail relays that do nothing but mail relaying, and if under utilized as they are often are, make them do it.
c. Watch out for two replication docs replicating same documents at same time. If they beat the indexer, which is possible on really busy servers, you can have replication conflicts or duplicate docs.
d. Separate replications into Pull/Pull so you can use streaming replication for better and faster network I/O.
e. Make sure every mail server has a connection document to every other mail server (or one cluster mail server member if a cluster) so that mail moves don't die. They don't need to be often.
f. Make ONE regional hub replication server, and have it replicate all system stuff. If you have separate apps servers, make the "main" or "first" one the replication hub for apps. If you have mail servers, replicate to the main mail servers (e.g. the main cluster member). For any spokes not part of a cluster IGNORE THE BOOK, and create a connection document for each server for mail moves. Otherwise, they'll always die.
14. Backup and Low Memory / Crash Issue in 6.5, and 8.0 and 8.5.0:
I like shadow backups better than our older "hot agent" ones. The hot agent ones tend to still cause low memory issues, and contend for network and disk I/O more.
Specifically, 6.5.x, 7.0.x, and 8.0.x and 8.5.0 all had a problem with crashes after backups.
To set up this perfect storm you need, Transaction logging on, hot agent backing up both the NSFs and the logs, and add some good old A/V to add some mystery. Now do a fix-up or something else that assigns a new DBIID, so that every huge honkin mail file of the 500-2000 users on the box is touched and needs backup. The result is that during to recently after the next scheduled Tivoli backup, the server availability index might still be 80% or higher, and the concurrent clients may only be 500 or less, but the client response time is in the toilet, and the only thing you notice is that memory is maxed. The next thing you know is that your console is 100% responsive, but you cannot load your mail file, and then the corruption of mail file starts, you then have you and Domino running fixup over-and-over, and you have this huge beefy box that cannot keep 500-2000 users up and running.
One of the SPRs for this is: SPR #DSTT6APL83. See document swg21211241.
It was finally fixed in 6.55 FP2, 6.5.6, 7.0.2 (but came back and then was fixed again), and 8.0.0, 8.5.0.
To add additional protection, two new notes.ini came out of this:
NSF_BACKUP_MEMORY_CONSTRAINED=1
NSF_BACKUP_MEMORY_LIMIT = <size> (Default is 20MB, enter in #bytes. IBM recommends 300MB or less. Each Tivoli thread can use this much RAM so keep it low enough.
(These do require Domino services restart. Set config don't work.)
The NSF_BUFFER_POOL_SIZE_MB UBM cache settings that are common in a search engine result, don't help at all for the crash issue EXCEPT for an old Notes.ini having the old good values to use. Domino 8 has new recommendations for correct size of this notes.ini.
The SERVER_MAX_NOTEOPEN_MEMORY_MB = <limit> (and another ending in _KB). This can help Domino throw away open cached Notes quicker. This seemed to help IF AND ONLY IF with this issue it has enough not currently in use that it can close.
More Tips:
a. Limit backup to not 2AM (with updall). Also, don't run a compact w/size reduction, or fixup during the scheduled back-up window.
b. If you number of users is low (<2k), you aren't doing DAOS, then consider not running transaction logging if using a shadow solution.
(Especially if it's stealthy enough for Domino to not have a shared memory state to store of it.)
c. If you have constant corruption, don't just fixup as a task, find out WHY!
d. Check for disks going bad. Check for bad network I/O to SAN storage where disk caches are failing because I/O is too slow.
e. Look for a hung tasks or another scanner (e.g. A/V) running on the file.
f. If it happens at the same time(s) of day, and you know it's not backup, then check again. Almost all the time, in my experience, it's always been a combination of cold backup, A/V, or a custom processes touching / moving something in the O/S.
g. Don't use the /3GB switch. I constricts the OS and puts apps and OS at odds. Unless you want to spend days tweaking off and on with the possibility of an upset VIP mail user, don't do it.
15. Sizing Notes:
a. 1 processor + 4GB RAM = 1000-1500 concurrent users on one box. (Depending on indexing and load.)
b. 2 processors + 4-8GB RAM = 1500-2500 concurrent users on one box.
c. Domino data on separate disk or LUNs than Domino executable. System OS commonly on local. Transactions should be on local. Okay if Domino executable folder also on local or same physical bus or even drive. Separate bus/LUN for DAOS attachment storage. (Don't forget backup exclusions for this "hot" locations.)
d. If local storage, at least 4 times the amount of disk storage you think you need.
Replication hubs and routing hubs are a waste. Don't bother unless you are SO BIG you actually might really need one. Just have your "main" mail server(s) be the routing hub to other locations. For replication, make your admin server be the replication hub if desired.
16. Sametime should be separate server.
a. Limits of version compatibility and/or timing will eventually bite you.
b. Increases Domino services restart time.
c. More likely to have memory servlet leak then core Domino services and require sporadic restarts. Otherwise, you can have Domino running years, if it wasn't for us wanting to put a new version on.
d. Chat is Domino-based. New meeting services are Websphere based (which is good in my opinion.)
17 Traveler can be on same or different server.
a. Install on a mail server if load is low enough and concurrent Traveler users under around 250 to 300 or so.
b. Install on separate server if mail server load is high already, or you will have >500 concurrent users.
c. Mail files do NOT need to be on the Traveler server, unless network I/O is slow to this external/DMZ server. In which case, the usual solution is to install on the web mail server(s).
d. Use Traveler policy settings for standardize features and add security options for wipe and passcode to unlock device.
ADMINISTRATION / HELP DESK
1. If adminP can do, let it do it.
Don't do anything manually that adminP can do. NEVER rename a user using just the person doc.
2. Use the CA process.
It's easy to set up. It's great and you don't have to worry about who has the cert.id and the oucert.ids.
Just put in ID recovery first.
3. Do either ID Recovery or ID Vault.
I like ID Vault, but it's a little more effort to set up and to watch over the OU admins. The ID Recovery route is pretty mindless. If you already have ID Recovery, upgrading to ID Vault is the way to go, but it's work, that isn't needed right now, since Domino 8 and 8.5 still use ID Recovery just fine. If you don't have either installed, do ID Vault. Otherwise, don't feel a lot of external or self pressure to get ID Vault up-and-running unless you have some other toolset that needs it.
For ID Recovery, MW has a custom "mail" template that sorts and displays the users with the latest re-cert w/o all the extra user mailbox stuff you don't need.
4. Limit who has Administrator and Full-Access Administrator Access
If you are large enough to have a help desk, give them the roles and access needed to register, recertify, rename, and the Database Administration security access in the Domino server documents.
Added a new server? Don't forget to setup the security tab.
5. Know when ACLs are changed.
Add an event handler to let you know when ACLs are updated.
6. Give your Developers a Dev/Test Server.
Don't let them deploy to production. Set them to "Restricted" in the Security tab in the Server doc. Require them to have a sysadmin-type documentation page in the app with the set-up instructions. (e.g. the Using Document works pretty well.) Have them tell you briefly what any scheduled agents do.
7. Recertify Early.
Give yourself a monthly reminder to go to the Certificate Expiration view and recertify anyone less than 60 days. It's easier to recertify, than do so after they expired, especially if the user has more than one machine.
If recertifications fail:
a. Check if they have more than one workstation.
b. Did IT too lock down the Domino folders so the user cannot write to the ID file?
c. Did they have a botched name change or not using the "new" ID that you thought they were using - They are a different person/ID.
8. Name Changes to IDs MUST BE BACKED UP.
If your culture won't let you use ID Recovery or ID vault and just have the IT network share to put IDs, get the ID after a user accepts the name change. If a user loses a workstation and the ID, you can recertify an expired ID manually, but you cannot user an old ID which had a name change to recertify.
9. Make sure Admin4.nsf is replicating properly.
a. Replicate from the Admin server to the App and Mail "main" servers and any server not in a cluster under a "main" server (Names.nsf, too, of course).
b. Use pull-pull to make sure that is both ways. Or if you paranoid, do pull/push from the admin server.
c. Admin4.nsf cut-off/purge should be longer than the maximum time it takes to get to the farthest replication point and back again plus a couple days. Typically, that means nothing less than 7 days and 21 is typical. However, large shops can easily have an admin4.nsf app over 1GB, so they often reduce to 14 days.
d. AdminP takes forever. Yes, it does. Don't bypass it. Just check back later today. Also, readers and author field updates are only done weekly, so name changes obviously could take a week.
e. If something fails, the server action document that would have marked it complete will display instead a red X with a fail reason. Fix the fail reason and then click the check-box to re-process the action.
10. Broken Replication - WATCH OUT!
If a server has an even minutely important app on it and it hasn't replicated properly in a while, do NOT just fix it and replicate. You will get old stuff coming back into your good stuff!
If it is a directory, you'll get old deleted people back again.
If it is the admin4.nsf app, you'll get old requests back again.
If it is a mail file, you'll get old mail back into the in-box, and a mad exec yelling at you.
If it is a directory catalog, you'll get old entries back, but the fix for this one is minor - just rebuild it.
You get the idea.
When you eventually get bit by this, and you will, there is a way to find these documents (plus a few false positives). All docs have a replicated into this specific replica date in the document properties. MW has code in the Support Reference library that you can setup and run to find all these documents. Then you can weed out good docs first and delete all the old docs that came back.
11. Roaming in 8.5 From PC to Mac / XP to MS Vista or Windows 7? Watch out!
a. Roaming is broken from PC to Mac. There is a problem with the workspace coming over. Even after you get past that there will be strange "You are not authorized" error dialogs that pop up with each scheduled replication. They have something to do with the sidebar apps. Only turning off Roaming for the user kills the sync working. You can kill the workspace folder (O/S folder - not the chicklets workspace), and it will go away for a few hours.
Turn off roaming for user before you switch them from PC to Mac.
b. Also, we have problem with roaming from XP for users where they were off of C:\Program Files\ or \Documents and Settings instead of c:\Program Files (86)\ or \Users. We turn off Roaming for these users, upgrade their workstation(s), manually moving their bookmarks and names.nsf, and workspace NDK file. We turn it back on after the migration is complete.
12. Watch Performance Statistics. aka Use the Monitoring tab.
The easiest and my preferred way to watch the services and statistics is to have Monitoring start with the Admin client and then use that for quick looks and a starting point for issues.
Over time, you will just know how fast your users use up disk space, when is your highest number of sessions, etc. You won't need the extra reporting unless you just want it for some internal paperwork.
13. Have Domino in a VM?
Make sure that the check-box in the Settings of the VM has time synch on. Make sure the VMware Tools tray icon has it enabled, too, if using MS Windows or it won't "take".
Alternately, you can use NTP, but I've seen Domino servers move hours into the future in an hour on older VMware 5.x and early 6.0 ESXi hosts when the CPU slicing is heavy. If you are using Linux, you can install the VMware tools or even the OpenTools. In fact, OpenTools is the standard way in the mainstream Linux distros.
14. DDM (Domino Domain Monitoring). Use it?
DDM is a great tool to roll up events and issues from multiple servers to a main server for review and action.
a. My opinion: It's great, but after I solve all the issues, I just check it occasionally.
b. I have notifications set up (error handlers) for big items and still bypass DDM for these major issues.
c. Definitely setup DDM filters to reduce the clutter. You don't want to see it and you don't want to store it.
d. DDM uses replication (but by the Events task). You will see a small replication load increase using DDM roll-up.
Do NOT roll up a server that is off-line (old server doc). Otherwise, the roll-up server's (target's) Event task will display an annoying message every second complaining that it cannot reach the source server.
For some migration and external monitoring (outside the local Domain), see document: swg27009312. (It's not on the IBM site anymore.)
15. Domino Configuration Tuner
Run this tool. It will tell if you have debug parameters accidentally still in your notes.ini. It will tell you if there is a better way of doing X than old X. It will also give you various tips based on your environment for making basic configuration changes. It can also do such things as see broken replication and tell you where you are missing a connection document, etc.
16. Archiving & Journalling
Archiving is generally the concept of a user's mail content getting archived to a separate location to save space and indexing resources in the primary/real mail file.
Journalling is the concept of capturing some or all mail as it goes passed the router for audit or legal purposes. Journalling can be used as archiving when it's desired to capture old mail together for corporate wide retrieval or data/knowledge mining rather than user retrieval.
17. NRPC Security & Internet Protocols
Lotus Notes w/ Lotus Domino server support encryption, but it is data encryption not transmission. To enable transmission, you simply go to the port on EITHER the client or the server (I recommend the server) and click the check-box to enable it. Encryption is enforced with either end having it on and is based on the certificates present in the server and user ID files. (Compression requires both ends to have it enabled.) For SMTP, IMAP, HTTP, LDAP, etc encryption, Domino uses standard keyring and SSL certificates. This requires setting up either/or both CA and a Domino Certificate Admin app to create a keyring and then load with the certficates from the third-party signer. It is easily possible to use a self-cert, but it won't be trusted in web browsers or mail clients -- I don't recommend it.
MISCELLANEOUS GOTCHA LIST
1. Pay attention doing mail file design replacement. I've seen multiple cases of accidental Domain (names.nsf) to mail file design replace from Help Desk doing the person doc instead of the mail file. Either limit the Help Desk access to names.nsf (by setting to Editor access maximum) or stress the importance of paying attention.
2. Use the Full Access Admin field and enter the "god id" or yourself if you are the primary admin. It's great for getting into something if you've accidentally locked yourself out of a mail file or system application because of a botched ACL update.
3. Don't leave debug parameters in after the issue is fixed. They can often hurt performance and fill up disks.
4. Don't drop Passport/maintenance, unless you are willing to drop anti-virus task add-on and backup updates. Eventually one of the other two, will become incompatible with Domino. It's usually the anti-virus.
Once is NT 4 FP6, I think, MS accidentally made sure that Domino crashed when started after the FP was added. They also have done that often that old FrontPage programming killing other packages, IE killing Netscape, Money taking out Quicken, etc, in the distant past. These days, we see pretty regular issues with third-party vendors scrambling to get their software compatible with "this week's" Tuesday/Wednesday MS OS updates.
5. Don't make the god ID, you're real name. What happens when you leave? They will most likely have to keep your ID just in case, forever. Make a separate ID for your "god" identity.
On the other hand, who doesn't want to remembered long after they are "gone". Make it your name. ;-)
6. Never just move Transaction Logging files on to another drive "letter". Domino just uses the same files over and over. The temptation to do this is when something wrong with the backup software marking them expired and Domino not realizing so the drive gets used up. Restart the Domino services and see what is still remaining afterward the next start when Domino does the clearing of old ones. If any are left, then shut down Domino again, and get the Tivioli (or other vendor) guys in to figure out why they are expiring the files after back-up.
7. Never use the Tivoli GUI logged into the server w/o the /admin console flag. You will crash the Tivoli add-on and should then restart Domino services. The crashed add-on will restart, but also put up nasty crash messages that will get you paged by the system log monitoring folks. Just take the pill and restart the whole MS Windows OS after stopping the Domino services.
8. Make developers use design templates to roll new features to custom applications. This way, if the new design is nasty, you can roll back to the previous template for the application. Make them use roles and map the roles to groups or users in the ACL. Don't let them hard-code names to features/roles in the application. It doesn't scale or adapt to changes well.
9. Watch what tasks create a new DBIID when Transaction logging is enabled/in use. That makes the "hot" back-up agent back up the whole thing again, rather than just the "delta" of what is changed. This is a good way to get your back-up folks frustrated and low on disk space themselves.
10. Watch other processes touching Domino applications/databases and causing corruption. If you see this happening, look to backup software and Anti-virus as the first offenders where the file types/extensions to exclude were not set correctly. Look next for the person who just wanted to do a "quick backup" and thought they do it "fast enough to not cause corruption".
11. If you decide to nip those pesky mail rules by turning off "pre-delivery mail agents" to save a few CPU cycles, you might also break an application you have on the same server which could auto process/file documents after receiving via mail-in database document. I personally don't think it is worth the headache.
12. If all users are Notes 6 or higher, take away their designer access to their mail file. OoO/Out of Office only needs editor access. It will keep them from changing their design and creating custom code. Definitely don't leave them with manager access. We are long passed the old days where the user was the god of their data and their stuff. Now they are dogs that beg crumbs from you like you beg, from risk management and hr, the new corporate gods. ;-) On the other hand, even the dogs get crumbs from the master's table, and are deserving (aka beloved) for the best that the master has.
13. Watch for users that forward mail from their Lotus account to their personal "x" account at home, which they might think is a good idea to forward all his/her mail to their work account. That way they can get all their mail from either. Not only will you mail hopping round-and-around filling up an in-box, but you are probably "letting them" violate a corporate security policy of internal corporate docs "leaking out".
previous page
|