Cascade Skyline - with Microsoft Logo and Project Support header - author Brian Smith

August, 2011

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Timesheets - Where do Personal Tasks come from?

    • 3 Comments

    If you have the setting to allow personal tasks to be added to the timesheet then they of course could come from the user.  But what about the ones that haven’t been entered by the user and appear to have the same name as tasks that were in projects that they had already started work on?  We have had a few questions on this behavior so thought it worth a blog posting.

    So here is my timesheet – and I have 5 tasks in the “Project BriSmith TS Blog” project, and I’ve spent an hour on each – so I’ve entered the time and saved my timesheet. (Status is “In Progress”)

    image

    Later on I go back to my timesheet and things have changed!

    image

    So what happened?  The task names give you the clue, and the Project Manager (me) has followed through on his action for each of the tasks.  Basically if a task gets deleted while a timesheet is in progress then we do not delete the time that is already entered but instead the task gets changed to a Personal Task.  A couple of interesting things to note though – the task name is actually cached as part of the timesheet (in case it gets deleted!) so the spelling mistake was actually corrected in the plan for the “Correcttting the spellling” task – but the cached version is still shown.  This would be the case for any re-named task – as long as the resource was still assigned.  If I click through to the task I see the current name published from the plan – correcting the spelling:

     image

    The next thing to note is that if I delete and re-create a task then as far as project is concerned this is a new task (with a new unique GUID) so it shows up as a Personal Task (keeping the original entered time) and also as the new task.

    The 4th task is interesting – I unassigned myself from this task and then re-assigned – so this is actually a new assignment – but as far as the timesheet is concerned it still shows it related to the project.  Also if I had published after de-assigning I would have seen a Personal Task and then after re-assigning and publishing this personal task would be gone and the project task back again (along with the entered time).   This surprised me a little - so I had to take a look behind the scenes.  It appears that as long as you don’t assign this task to anyone else, then you will get the same GUID for the re-assignment – but if you re-assigned to someone else, and then added back the original resource then the GUID would change and the timesheet would show the same behavior as the deleted and re-created task – both a Personal Task with the already entered time and the ‘new’ project task.

    The 5th task just got deleted so no longer exists so my recorded time now shows against Personal Tasks.  And finally the untouched task is still there as expected.

    So if the Personal Task does really relate to a task that has been re-created in some way then the resource should copy the time entered across the the project task and delete the personal task (Remove Task in the ribbon).  If it has been removed for good then the personal task is a record of the time spent – and should remain (depending on your time recording processes).

    This is the behavior when the timesheet is “In Progress”. If it is approved then the Project name and Task name are persisted even if the task is deleted.

    Other actions can lead to this behavior – if the project is saved back to the server (save as) over the top of an existing plan then all tasks and assignments will be replaced by identical ones – and any tasks in progress will change to Personal Tasks in the timesheets.  Also before we fixed the bug with Save for Sharing in the June CU this would change the GUIDs too – and have the same effect.

    All the above behavior assumes that Single Entry Mode is turned off.  With Single Entry Mode turned on then the Personal Tasks do not appear – the tasks just go (along with the time entered into them) – and also any task name changes reflect immediately in the timesheet (it is a direct link to the task, rather than a placeholder in the timesheet).  The re-assignment to the same task, even though it maintains the same GUID does not keep the entered time.  Single Entry Mode keeps the My Tasks and Timesheet view in Sync and Personal Tasks are never seen on the My Tasks view.

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: SharePoint Permissions in upgraded PWA instances

    • 1 Comments

    I was reviewing a case yesterday and just checking the behavior of SharePoint permissions in Project Web App after an upgrade from 2007 to 2010 – either in place or a 5 database  – thought this might be useful information to blog about. 

    In 2007 in the Project Web Access site the users would be added directly to the site with SharePoint permissions based on their roles.  These permission levels were identifiable by their names which would be like Project Managers (Microsoft Office Project Server).  In the Project workspaces these same permission levels would be used, and the users again added directly based on their roles within the project.  So this generally be a small subset of the overall user population – just those added as resources on the plan, and potentially others depending on the use of the View Project Workspace permission within categories. Here is the start of the list of permissions on the PWA site – Project workspaces will be similar although the permission levels may be different.

    image

    In 2010 in Project Web App we now use groups within the /PWA site and the users are added in to these groups rather than directly to the site.  The groups are named Project Managers Group (Microsoft Project Server), Team members group (Microsoft Project Server) etc.   Some individual user accounts will be present in PWA as shown below (blanked out) – these will be site collection administrators and other farm admins.

    image

    For the Project sites (formerly called workspaces) we still add the users directly, but we have new SharePoint permission levels which are named similarly to 2007, but we have dropped ‘Office’ from the product name – so they are now like Readers (Microsoft Project Server), Web Administrators (Microsoft Project Server).

    If you upgraded from 2007 to 2010, either in place or 5 DB then you will retain the old permission structure – but also get the new ones too.  So for example you would see all your users individually in the Project Web App permissions, as well as them belonging to the respective groups.  At the Project Site level you would see the users but with both Permission Levels applied – so they might have Web Administrators )Microsoft Office Project Server), Web Administrators (Microsoft Project Server).

    image

    All of this is the expected behavior and none of this will break anything, although I admit it may look unusual having the two sets of permission levels.  Also it does not leave any security issues as in 2010 if I remove someone from a Project plan then they get taken off the site with both sets of permission levels – and if I inactivate a user they are removed both at the individual level from PWA and also removed from the group that 2010 would have put them in – so all is good.  If you really wanted to then you could delete the permission levels with (Microsoft Office Project Server) in the names, and also remove the individual user permissions on PWA (apart from the site collection admins of course).  Worth checking that the groups contain the members you expect first just in case for some reason the sync hasn’t populated the groups yet.

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Can I delay running the SharePoint Configuration Wizard?

    • 3 Comments

    In SharePoint 2010 when you upgrade to a new Cumulative Update or Service Pack this involves two main steps – first is loading the binaries, and the second is running the SharePoint Server 2010 configuration wizard (psconfig or psconfigui).  SharePoint supports delaying the running of the configuration wizard or even detaching content databases while running the wizard, so that these perhaps slow parts of the process can be managed in a more timely fashion.  If you look at a SharePoint farm that is in this condition you will see in Central Administration, Upgrade and Migration, Review database status, that it says against many of the databases (Content, Config, and Admin Content) – Database is in compatibility range and upgrade is recommended.  However, if you have Project Server installed then you will see against all of its databases (certainly for SP1/June CU) – Database is too old and upgrade is required.  Some other databases such as BDC or PPS ones may just say No action is required if there were no updates for schema in the particular release.  For some CUs you might see this for Project and the SharePoint content databases too.

    If you ignore this message and try and go to PWA then you will get an error message: Error, Project Web App cannot connect to Project Server. For more information, contact your system administrator. – along with a GUID for tracking the full error in the logs.

    image

    Looking in the logs you will find the following exception and unexpected level records – which are pretty self explanatory.

    08/23/2011 09:46:41.85    w3wp.exe (0x1724)    0x0FC0    Project Server    General    g7ls    Exception    System.ServiceModel.FaultException`1[Microsoft.Office.Project.Server.Interfaces.DefaultServerFault]: The databases are out of the range of compatibility, upgrade your databases. (Fault Detail is equal to Microsoft.Office.Project.Server.Interfaces.DefaultServerFault).    fe5f9380-1f54-4021-a6a2-5fe7d3e321e8

    08/23/2011 09:46:41.85    w3wp.exe (0x1724)    0x0FC0    SharePoint Foundation    Runtime    tkau    Unexpected    System.ServiceModel.FaultException`1[[Microsoft.Office.Project.Server.Interfaces.DefaultServerFault, Microsoft.Office.Project.Server.Communications, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]]: The databases are out of the range of compatibility, upgrade your databases.   Server stack trace:      at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) …

    So to answer the question in the title – No, you cannot delay the running of the configuration wizard if you are using Project Server if there are database updates required in the particular patch you have loaded.  Not every CU will require database changes – but rememeber these are cumulative, so the need for the database update will also depend at what level your server is when applying the patch. 

    *** Update based on feedback from one of my favorite customers - if you really cannot run the config wizard for a while then it will only be PWA that won't work.  The Project sites will still work (apart perhaps from issues/risks/deliverables lists) and of course all the other SharePoint features and Central Administration will be just fine. ***

  • Brian Smith's Microsoft Project Support Blog

    Microsoft Project 2010: Cumulative Update Version Blog Updated

    • 2 Comments

    Just for reference – I have added the April and June CU information, and some notes around SP1 versions, to the on-going blog post at http://blogs.msdn.com/b/brismith/archive/2010/09/23/how-to-tell-which-cumulative-update-hotfix-or-service-pack-version-of-project-server-2010-and-project-2010-you-are-running.aspx.

  • Brian Smith's Microsoft Project Support Blog

    Microsoft Project Server and SharePoint 2007 and 2010 June CU 2011 announcement over on the Project Administration Blog

    • 0 Comments

    Better late than never.  We realized (with a nudge from Treb) that we hadn’t posted the normal announcement – so now we have – over at Microsoft Project Server and SharePoint 2007 and 2010 June CU 2011 announcement.

Page 1 of 2 (9 items) 12