February, 2009

*** Update *** Fixed in April CU - http://blogs.msdn.com/brismith/archive/2009/05/01/project-server-2007-check-in-pending-laid-to-rest.aspx  

My colleague Aik has been looking in to scenarios where the fix released in December’s cumulative update doesn’t appear to have resolved things and we have a series of steps you can try to see if this alleviates the problem for you.  Based on previous postings on this topic I am sure I will soon hear what works and what does not!  Keep the comments coming please!

Here are Aik’s steps:

a) Since the fix is on the client, check to make sure that Project Professional is patched to at least 6335.5000. You can find this in the Help | About section in Project.

 

b) If a file shows up as being in a checkin pending state, and you’ve verified that the project plan is no longer checked out  on the server, there are 2 things you can try to sync the cache status:

1. Try toggling Project Professional to an Offline state and then back Online. This will help re-sync the local cache status with the project status on the server. E.g. Right click on the bottom status bar  where it says Connected in Project and select Work Offline and do the same again and select Connect to Server. Note there is a built in delay of 15 seconds – so wait for about 15-20 seconds and then try the file open operation and see if the status reflects the correct state.
2. Close and relaunch project – Note there is a built in delay of 30 seconds – so wait for about 30 seconds and then try the file open operation and see if the project status reflects the correct state. E.g. is it still showing up as checkin pending?

Thanks for this Aik – readers, please let us know what works and what doesn’t.

So third posting of the day, and it had to be OLAP.  Thanks to Jon for this one, and also to my readers Kresimir, Tom and Pete.  Pete posted these steps which worked for him in overcoming build issues:

1. Setup DSO9 directory in \Program Files\Microsoft SQL Server\MSSQL.x\OLAP

2. Share the folder as MSOLAPRepository$

3. Give your SSP account full control of this share

4. Edit \Program Files\Microsoft SQL Server\MSSQL.x\OLAP\Config\MSMdsrv.ini - add the following in the DSO section near the end:

<RemoteLocksDirectory>\\SERVERNAME\MSOLAPRepository$</RemoteLocksDirectory>

<LocksDirectory>C:\Program Files\Microsoft SQL Server\MSSQL.x\OLAP\DSO9</LocksDirectory>

(where MSSQL.x is the directory that contains the OLAP folder)

5. Restart Analysis Services.

Similarly both Jon and Kresimir noticed through Process Monitor that the cube generator was trying to access the C:\ drive of the server.   Perhaps certain permissions hide the fact that this is happening, and it looks like the correct fix is to follow the steps outlined above.

In Pete’s case this was to overcome an error:

"Your permissions on the server computer do not allow you to administer this Analysis server."

and for Jon we were seeing every other cube build fail (Matt in the UK had this same symptom too).  It appears that the cube build works, but the subsequent build cannot delete the repository settings to re-write the new ones.  The same workaround as described above resolve this too.  The full error in this case had a specific sentance in front:

"Analysis Services session failed with the following error: Failed to delete the Olap database: xxxx. Error: Your permissions on the server computer do not allow you to administer this Analysis server.”

I am assuming I have always avoided this error by having the SSP admin also as a box admin – but I appreciate this isn’t always desirable outside of a test system.

Been slow on the blog the last week or two, and now two posts come along at once.  And a third may arrive later today!  Just like buses.  Just the way it happens sometimes, with topical issues coming in via support calls and e-mail.  I’ll hope to catch up and podcast these soon – so if you want to listen and not read you can wait, and stop reading here…

This problem came in as an issue creating timesheet periods – with the error:

 "Project Server timesheet periods cannot have duplicate names, or gaps or overlaps between adjoining period start and end dates. Period "xxx" does not conform to this standard. Correct the periods, and then save your data again." 

Very strange?  How could you get bad data in as it is checked via the data entry page?  After checking the database we knew the data was correct – yet in PWA you could see the overlap mentioned in the error.  Timesheet periods existed with the end date the same as the start date of the next period – instead of being the day before.  When I see things like this I initially think of time zones, date formats – basically anything that might make one day look like another.  It turned out that the Web Front End was running an hour different from the rest of the farm, so 23:59:59 (default end time of a timesheet period in 24h format) looked like 00:59:59 the following morning!  Thanks to Maulik and Tim for the great work on this case.

We have also seen (and I have blogged) how different time settings can slow down the queue – so please make sure all your servers are running sync’d to the same time.

***Update*** April CU contains the fix - http://blogs.msdn.com/brismith/archive/2009/05/01/project-server-2007-check-in-pending-laid-to-rest.aspx  Thanks for all your help! 

Thank you all for your continued feedback saying we still haven’t nailed this – and the offers of copies of caches and repro steps.  Fortunately we had an internal Microsoft user who read my blog and offered his repro and cache which gave us the benefit of a local repro where we could get at both his cache and his server (Thanks Ken!).

The result of this is a better understanding of where we need to look to resolve this issue and also, with all your feedback, confirmation that even deleting the cache folder (which is now accepted as the best quick fix – as long as your project is REALLY saved and checked in on the server) does not mean the problem will not come back.  The problem would appear to be some sort of corruption in the cache that can be re-introduced from a suspect project.  Aik now has the smoking gun, and the issue is making its way into our hotfix process (See EPMConnect for other on-demand and Live webcasts).

Stay tuned!

Quick webcast today on overallocation, and looking at the calendar and fine level time phasing to see why Project thinks the way it does.

Shortly after recording this I also discovered that if you have actual work equal to the planned work in the scenario described then it does not show in red as overallocated.  I guess if you managed to work 2 hours in 1 hour then not worth re-planning :).