Adminstration rules #2, #4, #21

Sriram asked for the rationale behind rules #2, #4, #21 of the Golden Rules for Domino Adminstrators. So here we go. These admin rules are designed to protect from trouble. Breaking them requires that you know what you are doing, which is quite different from thinking you know what you are doing. So unless you have three good reasons (one is not enough, also two is not sufficient, three is the number) stick to them.

2. Never ever use operating system tools to manipulate (copy, delete, rename or create) Domino databases. This includes using FTP to move databases to other locations!
   When you touch databases with operating system tools you expose yourself to unnecessary risk. You might be logged in as a different user than the Domino task and break file attributes (owner/permission). When you copy a NSF you actually create a replica - and 2 replicas on one server is forbidden (it definitely screws up DAOS). You also might end up to copy a file out of reach. Database deletion/rename is an adminp task so links can get adjusted. When you FTP a NSF you copy the ODS and eventual containing problems (beside the file access rights). With replication only documents get transmitted - if that doesn't work you have a problem you need to fix anyway. Furthermore you risk to try operations while a Domino is running and corrupt the databases in the process. So all risk, no rewards

4. Always use the server console for unscheduled replications. Never use the client replicator page for that
   The replicator page runs from the user workstation with the user rights. You will route the replication traffic through the client network. You will screw up replication formulas (if there are any) and you won't discover a connection issue between the 2 servers. You also block your own replicator. All disadvantages, no rewards

21. Never to use backup copies of ID files when users forget their password. Use IDVault and password recovery
    The fact that an admin has access to a backup copy of an ID file including a password invalidates the WHOLE security model since an admin can decide to impersonate anyone. It is sloppy security not worth to be called that. Also old copies might have old keys. Handling id files is staff intensive. So: All work and risk, no rewards
    Update: As Manfred pointed out in the comment: includes the risk of permanent data loss when document encryption keys are in that id.

Of course that's just a very compressed summary. Keep in mind: We must all face the choice between what is right and what is easy
As usual: YMMV