One of the practises we took to years back was creating a Group Policy Object (GPO) at the domain level and calling it the "Default Domain Security Policy - MPECS".
Into that GPO would go settings such as enabling encryption between domain members, servers, and others if they were able.
One thing to keep in mind when setting up such a policy at the domain level, or even attached to a given SBS OU, is to make sure that any GP settings in any of the other GPOs will not conflict.
Default Domain Security Policy - MPECS
We would also rename the default administrator's account in that GPO along with an Enforced GPO created and linked at the SBSComputer level that set the local admin account to "Administrator".
Today, out of the box, SBS 08 disables the default admin account during setup. In turn, the user account we created during setup or in the Answer File would be the "default" domain admin account.
This is awesome as it removes one possible attack vector altogether.
Since we are already used to having different domain admin account names at our client sites, this new setup will fit nicely with our already in place management processes.
We keep an audit of every client hardware and software configuration down to the server BMC passwords, UPS passwords, router and access point codes, and more. Access to the audit notes for our technicians can be via RWW or on a Windows Mobile 6 device with encryption enabled on the storage card.
An excellent article on Microsoft's position is by Jesper Johansson: Security Watch Why You Should Disable the Administrator Account.
Note item 6: Don't Rename It! Indeed, we did find resources indicating that renaming the Admin account was a good thing. We now know that this practice is wrong. So, we will be looking to work through our client's accounts and restructure them accordingly ... on our own time.
Microsoft Small Business Specialists
*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.