Who the heck is SPSTaskUser?

And more importantly why is he filling up my Application logs with these:

Windows cannot unload your classes registry file - it is still in use by other applications or services. The file will be unloaded when it is no longer in use.

Perplexed? I was. Until I spent a couple of days with a very fabulous Microsoft support person (Thanks Tracy!) going through a few errors we were having on a couple of our portals.

SharePoint (both SharePoint Portal Server [SPS] and Windows SharePoint Services [WSS]) have a few combinations of installs:

  1. SharePoint Portal Server using the built-in database engine (plain old MSDE)
  2. SharePoint Portal Server using SQL Server
  3. Windows SharePoint Services using the built-in database engine (new and cool WSMSDE)
  4. Windows SharePoint Services using SQL Server

Each has it's merits and downfalls (MSDE is limited to 2GB whereas WSMSDE doesn't have that limitation). Normally in a development setup you might decide to just install option #1, SPS with the built-in database engine. After all it's easy right? You don't have to do worry about a separate install of SQL and it's service packs and all that mumbo-jumbo. With that combo though comes, your friend and mine, SPSTaskUser. I was really perplexed as to who this user was? I certainly didn't create him. After a little Googling, others mentioned him (but usually it was "Who is this SPSTaskUser?"). However, just like why the infant universe did not simply spread out evenly after the Big Bang 14 billion years ago, the answer is here.

Installing SPS in this configuration creates a new local machine account called SPSTaskUser. The default website Application Pool (and all portals created after that on this server) will use a predfined Network Service account to do all the SPS crawling. When you set this up and your crawler kicks off (in my case it was every 10 minutes) you'll get a pair of messages in your Application Event Log like this:

2/18/2005 4:00:05 PM Userenv 1516 NT AUTHORITY\SYSTEM SERVERNAME Windows unloaded user S-1-5-21-2435244326-407298798-4041372769-1009_Classes registry when it received a notification that no other applications or services were using the profile.

2/18/2005 4:00:01 PM Userenv 1524 SERVERNAME\SPSTaskUser SERVERNAME "Windows cannot unload your classes registry file - it is still in use by other applications or services. The file will be unloaded when it is no longer in use.

It's rather annoying and was causing me some grief as I personally don't like anything but Information in my Application logs (and even then I get a little torqued about the amount of those Windows creates). Anyways, we spent some time and I was convinced that we hadn't created that user. SharePoint also creates a new scheduled task in the Windows Task Scheduler for each crawl of some content (luckily WSS only installs don't have this). That task will run as, you guessed it, SPSTaskUser. And we all know that when Scheduled Tasks run as a local account rather than a domain one it causes problems don't we kids?

We didn't find there were performance issues with the server, but it was dang annoying. There's two ways to fix this blip. The easiest answer is to just use SQL instead of MSDE. With SQL as the backend, two things happen. The Application Pools for the websites use a named user (a domain account you create with a non-expiring password) rather than the built-in NETWORK SYSTEM account. Second, the Default Content Access account (or Application Pool account, I can't remember which) that you specify to crawl content will be the account that runs the Scheduled Tasks. Problem gone, Application logs clean. Move along. A second option (although I haven't tried this) is to keep on using MSDE (although why would you?) and manually replace the Scheduled Task account with some domain account that you have for this type of stuff. That should fix it but your mileage may vary so caveat emptor.

One note, I don't know if WSMSDE creates this guy or not so maybe someone can confirm that and post a comment on it. I suspect it might not and the SPSTaskUser only gets created with SharePoint Portal Server and MSDE because it's the one doing the crawling of content (WSS searches content using SQLs Full Text Search engine).

Anyways, hope that helps someone out there and have a great weekend!

1 Comment

  • This was helpful because I've been chasing down these errors. I have a scheduled task running a vbscript every 15 minutes and the only useful recommendation I found was to use load UPHClean, which I don't want to do. I may be able to possibly work around it now that I know what's likely casuing it. Thanks for sharing!

Comments have been disabled for this content.