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.
Technorati Tags: Project Server 2007
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.
If you have Project Server 2007 installed on a network without DNS then you may come across some of these problems:-
The problem is resolving the name of the server - and just directly entering the IP address won't work in many cases. The reason for this is that many WSS pages do some redirection - sometimes just in the background - and these redirections go to the server name. If the name cannot be resolved on the client to the correct IP address then you can expect errors like "An unexpected error has occurred" - the WSS catch-all error. However some pages work just fine - particularly the main Central Administration pages of WSS and the root sites of site collections such as http://%3cserverip%3e/default.aspx.
The resolution is to get DNS working - but if this is not possible then there are a couple of workarounds:-
The second option is useful if you have many clients (although fixing the root problem and getting DNS working would be even better) but be warned - if you have SSL configured then this will give different issues - The certificate which matches the server name will report an error as it will not match the IP address.
I suspect you would also get similar problems if your host file had an entry for the server which was not correct - which can happen if you use DHCP and the server IP address is not constant.
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!