Patience please – async processes at work

One thing that I have touched on before is the asynchronous behavior of the some of the processes in Project Server and Windows SharePoint Services 3.0.  This is still catching some people out.  For instance, if you provision a new PWA site and then decide you want to change something - so you delete it - it looks like it has gone right away.  However, the site collection that was created as part of the process (usually /PWA) takes a while to be removed.  This means you may see an error if you try to re-create the PWA site immediately.  Another point of confusion is the "Waiting to be processed" message in the queue service of PWA.  This can sit there and look like it is doing nothing, when it is actually waiting for some other background task to complete.  Canceling and retry may make no difference - it will go when it is ready.  Of course there are times when something has gone wrong and it will never process - such as the queue service not running.  Perhaps a password has changed - or a connectivity or permission issue is stopping the account running the queue service from being able to get to the jobs (the queue jobs are held in the Project Server database tables).  Normally a look in the ULS logs or event logs will give clues to both these types of failures and also sometimes the reasons why a job may just be sleeping.

 For some internal details of the queue service take a look at the TechNet article at

The most common time for patience if if you have saved and closed a large project to the server and you are working on a low bandwidth or high latency connection.  This scenario was virtually impossible with 2003 but with 2007 it can be done.  However the save and check-in of the project may still take a while from the point you click the button on the client - and you may well find that the project is still checked out if you try to open it up too soon.  And remember - force check-in will not speed anything up - this just puts another job on the queue!

Technorati Tags:


Comments (23)

  1. AlyssaG says:

    Hi Brian,

    I have a somewhat related error to MSPS and MOSS and the Project Server Queue.  Wondering if you happened upon something similar…

    In cleaning up an unused web app that was used to host a PWA site, i have gotten a ton of application error messages to the effect of

    Event Type: Error

    Event Source: Office SharePoint Server

    Event Category: Project Server Queue

    Event ID: 7626


    Cannot start queue. SSP: 8cf16df8-2999-441d-8106-c3536492cdbf  SiteUID: 5f3b7e24-5f8b-4c2e-bde8-848d957c7a61 Url:  Queue: TimesheetQ

    The information in the logs on the server basically state the same information as what’s in the event log.  I deleted the PWA site first, then the SharePoint web application sometime last week, however I am still getting the messages.  The SiteUID from the app log entry above is for the deleted PWA web app.

    Thanks, in advance,


  2. Hi Alyssa,

    It sounds like the PWA site was deleted through Central Admin before the PWA instance was removed through Manage PWA Sites in Shared Service Providers (or at least before this process had asynchronously completed). If it still shows in the SSP then try and delete from there.

    Best regards,


  3. msczr says:

    We have a problem with the queue of Project Server 2007.

    When the operating system is restareted the queue service "Microsoft Office

    Project Server Queue Service" is correctly started, but it seems not to work.

    The jobs in the queue are in the state "waiting to be processed".

    If I manually restart the service, the queue start to work correctly and

    process the jobs.

    This behavior  happens every time that the system is restarted.

    Other persons have met the same problem?

    Where we can find some information about this problem ?


  4. Hi msczr,

    This looks like a timing issue.  When the queue is working you will notice that there are two (or more if you have multiple SSPs) instances each of the eventing and queueing services.  The first appears to start for you OK, but it is the subsequent ones that do the work – which for you are not starting.  I would expect you to see errors in the ULS logs indicating why these are not starting correctly.  It may be that SQL Server was not available (a typical error if everything is on the same server and SQL doesn’t start quickly) so setting the service to have a pre-requisite of SQL may allow it to start correctly first time.

    Best regards,


  5. Dinesh says:

    We have an issue with project server. Every night 1AM our application server(running project services) logs DB connection errror (event id 5586). It doesn’t log this error at any other time.Other Web front ends don’t have DB connection issues. There were cube build related errors(we have around 50 PWA sites). I did stop the cube build job, still the error gets logged daily at 1AM, Other error thrown just before that is -” Failed to execute timer job ‘ApplyResourceCapacityTimeRangeJob’. Error: This operation returned because the timeout period expired. (Exception from HRESULT: 0x800705B4)”

    These problems started appearing after we tried some stsadm restore operations for few SharePoint sites. Some times some of the project queue jobs do get stuck & fail. Out setup is RTM version of MOSS & Project Server 2007 with SQL 2005

  6. gigirex says:

    Brian, excellent response!

    This is exactly what happen when all the serviceas are on the same machine.

    I have resolved this problem linking the start of the project queue services to the Sql Server Agent (that start only when all the databases are up and running):

    Windows Registry Editor Version 5.00







    Thank you again.


  7. Hi Dinesh,

    You should be able to see either from the description of the job, or by identifying the Guid, which ApplyResourceCapacityTimeRangeJob is failing.  Possibly it is something left over from a deleted site.  Easiest option may be to disable it from Central Administration, Operations, Timer Job Definitions.

    Best regards,


  8. Dinesh says:

    Thanks for your response Brian.

    Figured out that there is some authentication issue with domain server. Domain server doesn’t respond for a minute around 1AM. Hence the DB connection errors are logged & the jobs are failing. Is it possible to shift those jobs (‘ApplyResourceCapacityTimeRangeJob’)to some other time other than 1AM so that it can succeed?(There are around 50 jobs one each for PWA)

  9. Hi Dinesh,

    I am not aware of a way of doing this (short of hacking the SharePoint config db and changing the job – which of course I cannot condone) but I will ask around.

    Best regards,


  10. SteveW says:

    Hi Brian,

    If you could answer this you would make a whole bunch of very frustrated people happy…..  😉

    (1) I take a full farm backup using STSADM of my prod box which has PS2007 running on WSS 3.0.

    (2) Then I attempt to create a copy of the farm on a different server ( the DEV server ). I create an installation of PS2007 including up to PWA.

    (3) I delete all databases except the sharepoint management dbs.

    (4) I create a new SSP called SSP2, and move the management and PWA to it. It has a new database name. I delete the original SSP so that I can restore onto the box.

    (5) I then restore the prod farm from backup using:

    STSADM -o restore <\DEV_SERVERShare> <Prod_GUID_from_the prod_farm_backup> -restoremethod new

    (6) Then I make sure I move the PWA and admin into the new SSP and delete the old SSP2, but not delting the SSP2 database ( attempting to delete the db causes it to fail ).

    (7) I do an IISRESET.

    (8) I then run RelinkAllWSSSites http://<dev_server&gt; http://dev_server>/PWA ( note if I use the port ID seems to make it fail, so I ignore the port ID ). Thsi links all the original PWA project sites intot he new system.

    Now – it all works BUT the QUEUE seems to ignore the new system.

    Brian, please do you have any ideas on why the queue might do this? I tried delaying the start to let SQL catch up but no joy.

    Is there a better way to duplicate a farm and have a different server name on the destination server? In effect I am migrating prod to dev.

    Many thanks – a good solution will solve I think a whole lot of pain for a lot of people.

    Thanks in advance,


  11. Hi SteveW,

    Not sure where you got the steps from but I haven’t seen this process used before and can imagine that it leaves some disconnection in the relationship between the PWA site and the project application.  If you just install your dev box to get Central Admin working then do a full farm restore – change the name of the server – all should be well.  See my postings on moving production to development and

    I don’t know of a supported way to get you working the way you have migrated.

    Best regards,


  12. Albert says:

    Greetings Brian,

    I’m developing an application which uses the PSI to programmatically create and update projects.  Sometimes they include hundreds of tasks and thousands of associated custom fields, assignments and dependencies.  

    Smaller updates seem to work, but larger ones appear to be getting stuck in the queue.  I have three jobs which have been pegged at 50% done for several days, one since last week.  All say they are in the processing state of an update from the PSI.

    The 3 projects are visible from the ProjTool, but not the PWA Project Center.  They occupy positions 1,2 & 3 in the queue.  From the  sequence of jobs started by my app, I think it’s the final one, an update which includes a flag telling the PSI to publish the project that’s getting stuck.  I cannot cancel any of the jobs.  Doing so has no apparent effect in the Queue Manager job listing.  Of course stopping and restarting the queue service or rebooting the server have no effect on this.

    At the time that the 1st job entered the queue, I find this error in the Windows app event log:

    Faulting application, version 12.0.6211.1000, stamp 46ce70f1, faulting module kernel32.dll, version 5.2.3790.4062, stamp 46264680, debug? 0, fault address 0x0000bee7.

    Following this, I get repeated warnings such as this:

    Standard Information:PSI Entry Point:


    Correlation Id: 2e832c71-775b-4e71-a9b5-02c618ebdc00

    PWA Site URL: http://prjsvr01/pwa2

    SSP Name: SharedServices1

    PSError: Success (0)

    Jobs locked by machine ‘PRJSVR01’ were unlocked and made available to other running queue services. The queue type (project queue, timesheet queue etc) which was non-responsive is: ‘ProjectQ’. Queue instance UID of the non-responsive queue is: ‘f5211a00-08be-4ea4-92f8-be45683f9e7b’

    Have I somehow mangled the queue beyond repair?  I’m thinking it’s time to re-install Project Server since it’s only a dev host at this point and doesn’t contain any actual user data.  Still that would be a hassle if avoidable since it would mean recreating a number of enterprise custom field defs.

    Any ideas?

    Thanks in advance, Albert

  13. Hi Albert,

    I assume you are breaking the dataset up into chunks of less than 1000 total rows in the dataset (see the SDK).  It would be helpful to have the event ID, or information from the ULS logs relating to these errors with the specific ID of the error as then I can search for other occurences.  The messages themselves are fairly generic.

    Best regards,


  14. Albert says:

    Hello Brian,

    Thanks for your quick reply.  First the good news.  

    After doing some research yesterday, I discovered that we hadn’t applied the Infrastructure Update from 2007.  After doing so, the queue managed to clean itself up, with the stuck jobs going from 50% done to simply failed.  The same PSI project update that I ran last week which initiated the problems, today ran successfully!  

    Yes, I have to break up my datasets into rows of less than 1000.  That was a fun little gotcha to come across.

    While IT applied the update, I looked into the ULS, as you suggested.  What a bear.  I have no idea how to find items in there that might be relevent to the errors I see either in the event log of in the Queue Manager.  I did notice that there are some utils which claim to make reviewing the trace logs easier.  You reccomend any in particular?

    Also, despite my update via the PSI now running to completion w/out appearant error, as far as the app’s concerned, there are still a failed job in the queue that I don’t understand:


    Error summary/areas:

    The web that you are trying to create already exists.





    From the trace log, I see this perhaps related record (how would I know?):

    "No SP web associated with project"

    Any clues what it’s talking about, or if they’re related?

    Your feedback’s much appreciated!

    Cheers, Albert

  15. Hi Albert,

    My recent screencast shows how to use Excel to make ULS logs more manageable – and also has some links to other tools I think the error mentioned above can be ignored as it looks like the code when publishing tries to create a workspace even when one already exists.  There is a lot of work going on to ensure categories and errors are valid in the logs – but much of this will not help with the current release – but I hope the tools mentioned can help you find your way through the logs.

    Best regards,


  16. smckeown says:


    I have a problem with the queue.  What I see is that for in that every project I save and publish typically there are about six queue jobs created.  Those jobs are Project Save from Professional, Project Publish Notifications, Project Publish, WSS Workspace create, Reporting (Project Publish), and Project Check-In.

    For each save and publish five of these six jobs complete. The Reporting (Project Publish) never completed.  It fails as Failed But Not Blocking Correlation.

    Any input is welcome,


  17. Hi smckeown,

    The ULS logs should give you more information on the failure – or even clicking on the error in the queue display may give the same info.  Potentially something in the project cannot publish to reporting – probably due to a previous reporting sync.  Typical reasons are that a custom field or resource hasn’t been correctly sync’d to the reporting DB and therefore the project cannot write that data to the reporting database. Correcting the inital problem should mean your project reporting jobs will complete – but first find the initial problem.

    Best regards,


  18. HyderZaidi says:

    Hi Brain

    We are facing "While communicating with the Project Server an error occured. Check connectivity with your administrator to determine if further action is necessary Title is required " issue on our production server, when some one tries to amend his current week timesheet. I have check the queue and it gives the message

    Error summary/areas:



    Error details:

    <?xml version="1.0" encoding="utf-16"?>



    <class name="Queue">

    <error id="26000" name="GeneralQueueJobFailed" uid="1f6078f1-63a6-4eac-8f67-225406306f9e" JobUID="f72f5367-833b-4729-82d3-6d711e05f2a3" ComputerName="EPMPROD" GroupType="TimesheetUpdate" MessageType="UpdateTimesheetMessage" MessageId="1" Stage="" />




    I am also copying the SSP log file in order to figure out what exactly goes wrong in our production environment

    04/17/2009 13:57:50.90 Microsoft.Office.Project.Server (0x1E4C) 0x180C Project Server                 Project Server Queue           7h51 Medium   PWA:http://epmprod:90/PWA, SSP:SharedServices1, User:DomainAdministrator, PSI:   [QUEUE] TimesheetQ No available group 0dd7a736-79b2-4527-b455-6c90a0360b33

    04/17/2009 13:57:50.92 w3wp.exe (0x1654)                       0x08E0 Windows SharePoint Services   General                       8m90 Medium   76 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.

    04/17/2009 13:57:50.95 w3wp.exe (0x1654)                       0x0EC0 Windows SharePoint Services   General                       8m90 Medium   79 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage.

    04/17/2009 13:57:51.01 Microsoft.Office.Project.Server (0x1E4C) 0x19EC Project Server                 Project Server Timesheet       8tei Medium   PWA:http://epmprod:90/PWA, SSP:SharedServices1, User:Domainusername, PSI:   [QUEUE] Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints. eb62fc0d-a385-4cad-b168-dd04dfd8f472

    I have move the same data into test environment but surprisingly no such issue found in test environment.


    Hyder Zaidi

  19. Hi Hyder,

    You may need a support incident to dig deeper into this one. The constraints error – and the fact that it did not reproduce in your test environment makes it look like a timing issue.  Does it reproduce consistently in production? Deleting and re-creating the timesheet may clean things up.

    Best regards,


  20. HyderZaidi says:

    Hi Brian,

      Yes it now produce consistently in production box. As a contingeny, I already asked my timesheet users to re-create their timesheets (copying snap in paint) and delete problematic timesheet and plan all amendments on plain paper and re-create their timesheet in one go, this is also suggested by MS support enginer, but neither I nor my users satisfy with this steps as it creates frustration and wasted their valuable time to record their actual working hours


    Hyder Zaidi

  21. Hi Hyder,

    Do you have a consistent repro from a clean timesheet?  Does the problem recur?  I am sorry this problem is frustraing you, but currently this is the only workaround.

    Best regards,


  22. Kelly says:

    Hi Brian.  I’m new to Project Server 2007 and have enjoyed your blog very much.  

    I recently encountered a strange error within Project Server 2007 and was wondering if you could assist.  I am trying to configure the build settings for the cube database.  When I start "Microsoft Office Project Server Queue Service" service, I get the following two errors (Event ID 7761 and 7757).  I am uncertain of why these errors occurred and have not found a resolution for them.  

    Any assistance you can provide would be greatly appreciated.




    Event ID 7761

    Standard Information:PSI Entry Point:

    Project User: SWNAKMS_DVService

    Correlation Id: 49168496-2e8f-47a3-abdc-5107b0fd06db

    PWA Site URL: http://pwa.disney.pvt/CORE

    SSP Name: TechSourceSharedServices

    PSError: Success (0)

    An unxpected exception occurred in the Project Server Queue. Queue type (Project Queue/Timesheet Queue): TimesheetQ. Exception details:

    The site with the id 838f8688-9213-4a3b-ae6f-6eaf2c5e18f8 could not be found.


    Event ID 7757

    Standard Information:PSI Entry Point:

    Project User: SWNAKMS_DVService

    Correlation Id: cc30777d-12d7-40a7-acf4-7785f4f3a75b

    PWA Site URL: http://pwa.disney.pvt/CORE

    SSP Name: TechSourceSharedServices

    PSError: Success (0)

    Queue System Restarting due to an unexpected error. Queue type (Project, Timesheet queue etc): ProjectQ.  Error: System.Xml.XmlException: Root element is missing.

      at System.Xml.XmlTextReaderImpl.Throw(Exception e)

      at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res)

      at System.Xml.XmlTextReaderImpl.ParseDocumentContent()

      at System.Xml.XmlTextReaderImpl.Read()

      at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)

      at System.Xml.XmlDocument.Load(XmlReader reader)

      at System.Xml.XmlDocument.LoadXml(String xml)

      at Microsoft.Office.Project.Server.Errors.PSError..ctor(String xmlString)

      at Microsoft.Office.Project.Server.BusinessLayer.Queue.Receiver.CleanupCompletedThreads()

      at Microsoft.Office.Project.Server.BusinessLayer.Queue.Receiver.ThreadEntry()

  23. zeeshan0333 says:

    Dear Sir,

    I have installed the project server 2007 for learning purpose and have the same issue. when i try to save the project it goes into wait state and that wait never ends. I am trying to correct the problem as you describes above but fining it difficult because I am totally new to project server. If you provide any new solution to resove this issue i ll be thankful.


Skip to main content