I'm coming to the end of a week of training in a Microsoft Official Curriculum (MOC) Course. I should expect that best practices and gotchas would be covered, especially since this is an Install and Configure course, but I know better. Here are the things that I've seen that make my stomach turn:

Requiring Students to log on as Administrator

I've said this before and I'll say it again. If you say that it's a best practice to rename the administrator account and not use that name for a real account, then don't use it in your training material. Because when you use it in your training material, you are teaching the folks who don't know any better that it is an okay practice. And that means you're sending a conflicting message. The Active Directory administrator account for the labs has been administrator. Now the thing of it is that the labs were already set up with a multitude of other accounts. It would have been a simple thing to add just a single more account, with Domain Admin privileges, that wasn't named Administrator (or simply rename the Administrator account).

Telling the Students to use sa

Yes, indeed, I've seen in the labs where a connection was made and the connection was made using the sa account. This goes back to the previous point. If you tell us not to use it in real life, then don't train folks to use it in your curriculum! There was absolutely no need for it in the lab. Another account, with much, much lower privileges would have done the job just fine. What makes this more vexing is that in other labs, other accounts were used with lower privileges which the student had to manually set. No sa. Ever!

Telling the Students to use db_owner when it's not necessary

There have been several cases where the application in question makes a read against a single table. So of course the application has us configuring the connection account as a member of the db_owner fixed database role. What? Why? Since the labs are pre-built, it would have been a simple measure to have created a role already with the appropriate permissions. Explain in the documentation that this is in keeping with the Principle of Least Privilege and all the student has to do is add the account to the correct role (since you already have them adding the user to a role).

Having the Students perform critical actions and not covering what they should be aware of

In this case the lab had the students create a database master key. I won't go into the why. However, there was absolutely no talk about ensuring you've got that key backed up. For instance, here's what Books Online has to say about ensuring the key gets backed up:

We recommend that you back up the master key as soon as it is created, and store the backup in a secure, off-site location.

So why wasn't this mentioned? Remember, this was an install and configure class, so that's exactly the sort of thing I expect to find covered. If you're going to say to do something in a real production instance, then train us to do it when we cover the material and do the lab.

Be consistent in your documentation

There was talk about setting up Kerberos Service Principal Names (SPNs) and there were examples given how to use SETSPN in the documentation. However, the syntax was like so:

setspn daserver1 -a http/daserver1.reskit.microsoft.com

While that syntax is correct based on what's given here, it's opposite of how the SETSPN examples are written almost everywhere else I've seen, which looks like this:

setspn -a http/daserver1.reskit.microsoft.com daserver1

So why, in this course, are things different? Why confuse students by not staying consistent? There's no reason not to do so.