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 http://technet2.microsoft.com/Office/en-us/library/0845d622-95ab-4c20-b419-0dbd5aab33a51033.mspx?mfr=true
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: Project Server 2007
I thought this was one worth mentioning to a wider audience in case it catches others out. One of our customer had written some code to update data in the timesheet using the PSI. All seemed to be working OK, but no numbers changed. You could even debug in Visual Studio and use the cool data visualizer to see the dataset and watch the changes - but even though the call worked and the queue showed a successful update the timesheet didn't reflect the changes. The right dataset was also being passed to the final web service - in this case the QueueUpdateTimesheet method of the Timesheet web service.
I then noticed that the customer had an ADO.NET "AcceptChanges" call on the dataset before the call to the web service. This was breaking the update as the web service is expecting the dataset to have a delta holding the changes from the original read of the timehseet dataset. The AcceptChanges is used in ADO.NET to commit changes in the dataset - but the delta then disappears. So even though the dataset was different to that originally read from the PSI call, it didn't have the deltas - so no changes were made to the original (different) data. Simply removing this line got everything working again and the changes were then visible in the timesheet control of PWA!
One common issue we see, particularly from customers familiar with Project Server 2003 is that they will install WSS v3 before Project Server 2007. This is an unnecessary step and in some cases can then make it difficult to install Project Server 2007 in precisely the way that you want. For instance if WSS is installed then it can install a SQL Express instance for its databases. Then when you install Project Server it follows the lead of WSS and also uses SQL Express - when you really wanted to load the databases in another instance of SQL Server 2005. Just installing Project Server 2007 will also install all the bits of WSS you need and allows either a "standalone" install - which does use SQL Express, or you can choose "Advanced", followed by "Complete" and this will allow a choice of SQL Servers to connect to. Often a customer will choose standalone to mean that SQL will be on the same server - but will not intend to use SQL Express - but a full SQL Server 2005 database engine that is also running on the server. Standalone does not give you the choices - but Advanced and then Complete does.
This will be part of the SDK in the April update - for now you can find it at the Project blog at http://blogs.msdn.com/project
"The Project Server 2007 Report Pack provides usable reports for some common requests and illustrates some of the new functionality in Microsoft Office Project Server 2007. The Report Pack also provides report developers with sample queries for correctly retrieving data from the Project Server Reporting database."
I am working on some internal training at the moment on the use of alternative authentication methods for WSS and Project and am playing about with LDAP. Having shot myself in the foot by leaving a web.config open and then later saving it over a version that WSS had modified I thought I would take a look at the option within InetMgr (IIS Manager) that allows the editing of the web.config and a nice little UI. Perhaps safer than notepad? I was setting WSS to use two different LDAP providers on two different ports - but the Central Admin site needs to know about both of them. Uncharted territory for me - so when things broke my first guess was that my XML was somehow wrong for adding a second provider - although the UI in InetMgr seemed happy with my addition. Symptoms of the break for me were "File Not Found" on the Operations and Application Management tabs - and the home page went to a Server Error in '/' Application that wouldn't display anything other than the custom error no matter what I tried.
So I removed my XML and the problem stayed. As part of my training was to be comparing web.config files at various points during the training I took my own medicine and fired up windiff. And there it was - the edit configuration option had added an attribute to my <configuration> element. Instead of just <configuration> on line 2, I had <configuration xmlns="http://schema.microsoft.com/.netConfiguration/v2.0">. Removing the extra text got my Central Administration site up and running again.
This is a known issue - KB 917238 - but in case you see these symptoms - take a look at your web.config.
Let me know if anyone out there is interested in authentication of Project Server 2007 with LDAP and I will blog my findings so far.