One problem I have seen a few times is the Project Web Access site provisioning running into issues. If it fails completely then the error messages are pretty good - and you can generally resolve the issue and re-try and everything will be good. However, what do you do when it just sits on "Waiting for Resources" and nothing happens? The quick answer is that this relies on the SharePoint Timer Service and a couple of Shared Service Provider services that can be viewed through Timer Job Definitions (Shared Services Timer Job and Project Server Synchronizing Job for 'SharedServices1' - or whatever yours is called). If these are not running then you will be "Waiting for resources" for a very long time! Also there could be multiple versions of the timer jobs if you have multiple SSPs so it can get confusing, particularly as the first one does not differentiate by name. (Clue - the JobId in the URL for the job is the Id of the timer job row in the Objects table in SharePoint_Config database, and the Properties column from this row will lead you to the Guid of the TargetSharedResourceProvider - which will be the Id of the Shared Services Provider also in the same table.)
So to dig a little deeper so you can understand where it might be stuck I'll explain what is going on in the background which hopefully will help you find what is stopping it from working.
So, step 1 - you have been on the Create a Project Web Access Site page (CreatePWA.aspx) and entered all the details, and it goes back to the Manage Project Web Access Sites (ManagePWA.aspx) page and just sits there. At that point a row has been added to the MIPScheduledJob table in the SharedService1_DB (your database name may vary - this is the default). This is a pre-synchronizing job for the site, and is added to the database by the account running the Shared Services Provider application pool.
Step 2. The Shared Service Timer Job picks up the row from this database table and adds a row to the SharePoint_Config database Objects table. In the properties field of this table is some XML describing the site to be built, database names etc. This timer job will run as the account of the farm administrator (i.e. the account running the OWSTIMER service)
Step 3. The Project Server Synchronizing Job for 'SharedServices1' sees this row and actions it by creating the site, creating the database and then configuring the instance of PWA. If everything is working you see the status change on the ManagePWA page as these different stages are processed, and finally it will say Provisioned! Again, this timer service runs as the farm administrator.
Waiting for resources will be seen until the early stages of step 3.
So check all your services are running and your timer jobs are present and enabled and all should be good. One other workaround that generally gets things moving again is to create a new Shared Services Provider - which will then create new timer jobs and overcome any underlying issues. The web applications can then be associated with the new SSP, the new SSP can be made the default if you are not using the old one for anything else, and the old one could be deleted.
I mention the databases here on the condition that you can look - but don't touch!
Technorati Tags: Project Server 2007
Brian great write up, I've just ran into this issue and I'm kind of stumped as to why it would be happening. I followed your steps above and I get to the end of step 2 and verified the rows were added to the SharePoint_Config database but thats where it stops. I look under my timer jobs status and definitions and I do not see Project Server Synchronizing Job for 'SharedServices1', I think this may be my problem but I have no idea. Is there any way to create this? Thanks!
Matt
Brian
Just ran into the same issue as Matt can you tell me if there is anyway of creating the job?
Mick
I'm still trying to find out where the job gets deleted - so if you know that you have previously (and recently) created a PWA site it must have existed. If you have ULS logs going back to this point and are prepared to let me have a look at them then please use the contact link. The only current supported way is to create a new SSP and then change the associations of the current web site having the problem to the new SSP. The new SSP should have a timer job and all will work. This is generaly no great issue for Project Server but if you are also running MOSS and have configured stuff through the SSP you should seek advice from the SharePoint guys too.
Best regards,
Brian.
Hi Brian,
I managed to create a instance of Project Web Access using the second SSP and it works ok. But the first SSP is still trying to provision the instance. Is there a way to remove that.
Perhaps removing the related web application?
Your help would be greatly appreciated.
Thank you.
I've gone off and created a new SSP and a new PWA site. I then go in and Edit the Project Web Access site (http://server:18525/ssp/admin/_layouts/createpwa.aspx?task=Edit), changing the database names to connect them to restored SQL Project Server databases (that have come from a different farm on a different server).
It seems to work (it goes through all the motions), but then when you bring up the site it displays "An unexpected error has occurred."
Am I attempting to do the impossible? When I go through the Event log, it brings back such things as "Cannot start queue. SSP" and "GetLanguageInfo failed for PWA site."
Thanks!
Hi Joe,
The correct way to do this would be just to create and name the other databases. You cannot edit and change the database names without running into this problem. SO you should be able to delete (then give it a few minutes to complete the asyn tasks) and then create a new site and things should be just fine.
I am still having this issue and it has now started on another server.
I have tryed to create a new SSP but all of the provisioned sites and the one which is wating will not move.
I have even tryed deleting the site which is being provisened but then it just says "<Web Application not found>/projectserver" and still is waiting for resources.
Please tell me if you have found anything out about this.
Hi Mick,
If you can find any clues in your ULS logs on what might have happened to the shared services timer job for your SSP that will certainly help to resolve this one.
Hi Brian!
I also have the same problem with the Job. It was removed on two different farms and on one farm, happened for 2 SSPs.
I managed to capture the deletion event from the event logs. If it can help, let me know how I can send you the info.
Nic
Hi Nic,
Great news - I am keen to see the logs - you can send to brian.smith@microsoft.com.
I've run into the same issue and am still looking for a way to resolve the issue without creating a new SSP. This happened to me in to past and creating a new SSP left me in the same situation as Mick above. Have you had any luck figuring this one out?
Thanks, Todd
Nothing supportable yet Todd. I can hack the SharePoint Config database to recover the SSP - but need a better way than that...
Same problem here - the provisioning of the PWA site is well and trully stuck. Could you post details on the SharePoint Config database hack?
Regards,
AlexO.
Brian,
we are also experiencing this issue - on a large MOSS Farm - with PS added...initially I was able to create PWA sites - but now cannot.
we have added 3 WSS hot fixes and suspect these (KB 948957, 950279, 950280) per MS advice - then we had many event log errors which seem to have been resolved by KB 946517 -
however, we can no longer provision -
we had 1 stuck - then applied the last patch - then tried again with a new SSP - and it stuck -
so now I have two SSP's - both with stuck jobs -
Also - if you make a new SSP - then you will lose the association of the existing PWA sites (we have more than 1) - yes? I don't see any way to tell the new SSP that existing PWA sites should move over.
FYI still searching for a solution -
our next option is to remove all SSP's, PWA's, Web Apps - back to square one and see if that works -
Question is - will this clear out the config entries?
Hi Erik,
If you create a new SSP then you can change the associations of the web applications that are hosting PWA (and even the ones that have "stuck") and then all the PWA's should work as usual. As an example if you have an SSP on port 7777 hosting PWA on port 80 then you create a new SSP on port 8888 you can then change associations and associate port 80 t0 port 8888. Once you have done this you can make 8888 the default SSP and delete the one on 7777. The same applies if you have more site (for my sites) and more SSPs...
Hope this help - but we are still rying to find what breaks this...