Microsoft

Recently I've been debugging a SQL Server 2005 replication setup, where the "Distribution clean up" job for the distributor database was failing. The error message in the agent history was:

Executed as user: <sqlagent_serviceuser>. Could not remove directory <UNC_path_to_snapshot_directory>.
Check the security context of xp_cmdshell and close other processes that may be accessing the directory.
[SQLSTATE 42000] (Error 20015).  The step failed.

The “<sqlagent_serviceuser>” was the Windows user that the SQL Server Agent service was running under, while the “<UNC_path_to_snapshot_directory>” was the network path to the directory where snapshots where created.

Looking around on some discussion forums, I found the same message reported several times but without any real solution; at least no solution that would work when I tried to apply it to this particular setup. Most answers to the problem focused on the xp_cmdshell procedure mentioned in the error, and how it would require certain configuration at the server end.

However, one answer on the MSDN forums did give a useful clue — it pointed to the SQL Books Online article about Securing the Snapshot Folder (which I should've read right away, really). In a note, this page reads:

If a publication is dropped, replication attempts to remove the snapshot folder under the security context of the SQL Server service account. [...]

It's the SQL Server service account reference which is essential: even though the SQL Agent service account may be the one mentioned in the error message, the actual account that is used to try and delete the snapshot directories is the SQL Server service account instead. Giving that service account the necessary access rights fixed the problem; as in the Task Scheduler case, accurate error reporting on Microsoft's side might go a long way towards people disliking their software less.

Apparently, the task scheduler in all Windows NT-derived versions up to (and including) Windows Server 2003 cannot run jobs under the "NT Authority\Network Service" security principal; "NT Authority\System" is the only so-called well-know security principal that can be used with it. Support for running tasks as "Network Service" or "Local Service" was only added in Task Scheduler 2.0, which is the version that ships with Vista and will be also included in Windows Server 2008.

Side note: I wonder why the link above, being a command reference for an administrative tool, is on the MSDN and not on the Technet site.

Practical implication is that without being able to use the "Network Service" principal, a distinct network account (domain account or server account) is required for any job that needs to access any network resource. This also means keeping track of another account and password — and taking care of controlling and auditing it's access; whereas the "Network Service" principal cannot normally be used for interactive sessions.

Annoyingly, the task scheduler UI also does not tell you that you can't if you try, but rather gives the un-helpful message "Access is denied. You do not have permission to perform the requested operation".
The same message is also shown when, for a regular account, the password entered does not match the actual account password. (This happened to me because the keyboard layout on a remote desktop session turned out to be not what I thought it was)
Anyone know if the error reporting has improved anything in the new task scheduler?

Not sure that I have enough of it, but I can try anyway. Here's one for the unlucky administrators who have an Exchange server amidst their server farm.
If a windows server running Exchange 2003 logs the following error event in the System log when it is restarted:

Access denied attempting to launch a DCOM Server. The server is:
{9DA0E106-86CE-11D1-8699-00C04FB98036}
The user is SYSTEM/NT AUTHORITY, SID=S-1-5-18.

then one possible cause is that the Microsoft Search service is missing a startup dependency on the Exchange Information Store – which is not obvious from anything in the event message or the surrounding ones. Searching the web does not list anything relevant at first either, you have to check lower ranked results to find the solution listed in the post by user "zeeshan_xt" in this message board thread. Hopefully this post helps it move up a bit.