[Note: Updated Feb. 22 2008, solution at the bottom]
I’m responsible for a couple of SharePoint 2007 (MOSS) farms where all SharePoint servers showed a number of annoying errors in the application event log.
Every minute the following three errors show up in the event log:
Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Timer
Event ID: 6398
Date: 3/6/2007
Time: 11:47:58 AM
User: N/A
Computer:
Description:
The Execute method of job definition Microsoft.Office.Server.Administration.ApplicationServerAdministrationServiceJob (ID 371548ff-a05e-41f0-90da-6f2d25fbb483) threw an exception. More information is included below.
Not enough storage is available to process this command.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
And
Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 7076
Date: 3/6/2007
Time: 11:47:58 AM
User: N/A
Computer:
Description:
An exception occurred while executing the Application Server Administration job.
Message: Not enough storage is available to process this command.
Techinal Support Details:
System.Runtime.InteropServices.COMException (0×80070008): Not enough storage is available to process this command.
Server stack trace:
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_IsContainer()
at System.DirectoryServices.DirectoryEntries.CheckIsContainer()
at System.DirectoryServices.DirectoryEntries.Find(String name, String schemaClassName)
at Microsoft.SharePoint.AdministrationOperation.Metabase.MetabaseObjectCollection`1.Find(String name)
at Microsoft.SharePoint.AdministrationOperation.Metabase.MetabaseObjectCollection`1.get_Item(String name)
at Microsoft.SharePoint.AdministrationOperation.SPProvisioningAssistant.ProvisionIisApplicationPool(String name, ApplicationPoolIdentityType identityType, String userName, SecureString password, TimeSpan idleTimeout, TimeSpan periodicRestartTime)
at Microsoft.SharePoint.AdministrationOperation.SPAdministrationOperation.DoProvisionIisApplicationPool(String name, Int32 identityType, String userName, String password, TimeSpan idleTimeout, TimeSpan periodicRestartTime)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
[…continues…]
And
Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 7076
Date: 3/6/2007
Time: 11:47:58 AM
User: N/A
Computer:
Description:
An exception occurred while executing the Application Server Administration job.
Message: Not enough storage is available to process this command.
Techinal Support Details:
System.Runtime.InteropServices.COMException (0×80070008): Not enough storage is available to process this command.
Server stack trace:
[…continues…]
Sometimes they are replaced with another three that has the same event id and source, but with the error message being “Old format or invalid type library” instead. The stack trace will differ a little bit.
Obviously it’s a timer job scheduled every minute that fails. The one in question is “Application Server Administration Service Timer Job”, which apparently is in charge of ensuring that the IIS application pools are in sync (or something like that). Nothing seems to be broken in the farm by the job failures.
And quite annoyingly: They all disappear when you reboot the server and will not reappear until after “a few days” in my case. I’m sure that the re-surface time will differ between systems.
I’ve read many proposed solutions for this error, including adding ram, disc etc., often claimed to work. I seriously doubt that any of these solutions actually work. My SharePoint servers are equipped with no less than 6gb of ram with default settings for all the application pools (I know that the ram is hardly utilized with these settings, but in my world it’s sometimes cheaper to go for a “standard server” where you only utilize 70% than one customized for your needs), plenty of disc etc.
As a side note you can also find references to this error in connection with SQL server 2005, the fix below possibly also work for that as well.
The solution turns out to be quite easy – the patch you are looking for is kb923028. It is an update for an error in the .NET 2.0 remoting subsystem, and has actually nothing to do with SharePoint at all. Reading the description it is quite hard to glean that it’ll solve your problem. MS support pointed me to it and it seems to work just fine.
Caveat: I’ve seen multiple versions of this file, the one I have working (until proven wrong) is “NDP20-KB923028-X86.exe” (1,936,224 bytes). I’ve tested another one with the same name with a filesize of 1,963,440 bytes that didn’t work.
The server has been chugging along for some time now (about a week) without the bug so let’s hope it’s all done.
That didn’t work…
Update: Finally a resolution
You need to look at hotfix KB946517, which will fix the problem. It is a private hotfix, so you’ll need to contact MS acquire it.
The servers have been running for about a week now, they are still ok and other people are also reporting success.
For the third time I’m confident that the problem has been solved – guess I don’t learn from experience 
18 Jul 2007 at 11:35
Thanks, for great advise. I had same thing in one MOSS installation. I tried to search for the hot fix that helped you (1,936,224 bytes), but I could not find it. I installed the hot fix received from the KB link you presented, but that did not fully resolve the problem. The error message changed to “Unknown Error”
Where did you obtain the other fix?
22 Jul 2007 at 20:40
I got it from microsoft premier support, however don’t get your hopes up after all
This time it took considerable longer for the servers to fail, but now they’ve been changed to “Path not found” and “Attempted to read or write protected memor” on the index server and the old “not enough storage” resurfaced on one of my frontend servers
Crap crap, MS insist that it is the correct fix and I believed them for a long time…
02 Aug 2007 at 1:40
It’s my first week at a new job and I am faced with the same challenge. M$ is mawing it over too. Will post if fixed …
Odd though – in your frontend server that is throwing “not enough space …” – is that error preceded by a sql exception a few seconds prior that references “proc_GetTpWebMetaDataAndListMetaData”?
A total guess here …
It almost looks like the worker process (w3wp.exe) is seeking a config value in the db, which is not found, defaults the null to a 0 (zero – the status is most likely a number after all). Now given that a sql return code of 0 means success, and not knowing what the sp is supposed to return (yet, though it is likely config & meta data), if a follow-on process then populates an instance of an object with the (non)members of the null recordset returned, then when that object is passed to the “Bind” method in the “DirectoryEntry” namespace no wonder an excetion is thrown – it can’t bind to null in the file system …
Now, which server is that db on and what is that proc supposed to be returning …
Please let me know if your log shows similar …
.\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS\
Thank you – J
03 Aug 2007 at 9:01
Hi joe
Sorry to disappoint you, but I’ve not seen that particular exception in the log. I’ve never seen that one to fail though.
I’ve tried to disassemble the code that’s failing, but the particular method in question (not even the entire class) is obfuscated, so there’s no peeking only guessing.
Interesting theory though. I think you got two separate problems and you should definitely prioritize the sql error above all else – it will most likely wreak things for you.
The DirectoryEntry that is failing to bind is actually not a directory on the file system, it refers to the Active Directory and the error seems to occur when the administration job tries to look *something* up in the local AD. Guessing from the context would be that it tries to find some information on either the application pool account or the machine account.
The resolution according to MS is to install the hotfix and in addition (if it doesn’t help) re-provision SharePoint, reinstall SharePoint and Reinstall .NET. I did all of that and seeing that it didn’t help the case has now been parked by MS – “waiting for SP1 where it will surely be fixed”.
07 Aug 2007 at 19:31
Thanks for the input Soren, still getting up to speed on AD & MOSS. BTW – latest from M$ … they are investigating (suspect) file locks as a potential source of the problem. I.e. … file written, follow-up (or external process) analyzes file locking it (even for reading), next write from the OSTimer spawned event fails due to intervening process not finished.
Changing when OSTimer executes would be a good test but … We had a reboot 5 days ago and the problem has yet to recur and we can’t duplicate it or identify the causal event.
Joy. Best of luck – J
06 Sep 2007 at 13:02
If you’re using MOSS 2007 check that you have the correct access for your service accounts that you are using to run the service Windows SharePoint Server Timer Service. I had to add it to the local administrators group on my SharePoint box and this removed the errors and left everything working hunky dorey.
Sometimes it’s the simple solutions that fix problems!
18 Sep 2007 at 13:22
Deidre – do nned to anything after you add the account, i.e. restart service or restart server?
Thanks
25 Sep 2007 at 22:05
Hi Deirdre
Interesting that it actually is an access rights problem.
However I don’t consider it a good work around to make the SPTimer service user a member of the local administrators. It goes against just about any security principle.
See the work around that I just added to the updated article. I would consider that a better solution.
14 Oct 2007 at 20:30
If it would not be solved:
Open Task Manager and select “View menu”. Click on “Select columns”. On the form check in the “Handle count” column. Order the task manager view by “Memory used”. If you would see that owstimer.exe were on the top and “Handle count” were higher than one – two times one thousend follow the next steps:
Apply hotfix KB923028. (Applies on .net framework 2.x, -not directly on MOSS).
- Make sure that nobody uses SP administration site.
- Open command prompt
- Navigate to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN (or where you have deployed SP)
- Run: psconfig.exe -cmd adminvs -unprovision
- Stop Windows SharePoint Services Administration service (net stop spadmin)
- Run: psconfig.exe -cmd adminvs -provision -port
- Start Windows SharePoint Services Administration service (net start spadmin)
11 Feb 2008 at 11:44
i had the same problem, what i did was as bellow.
went to contrl panel > open services > then go to windows sharepoint timer service then let it run as the computer administrator,
it sloved the problems uu la la la
02 May 2008 at 15:12
I was experiencing the same problems as described here. I have already applied hotfix KB946517 to all of the relevant servers but this does not fix the problems.
I can also confirm that adding the Timer Service account to the local administrators group solves the problem.
Admittedly, it’s certainly not the long term solution, but for now it will have to do until Microsoft release a fix for this.