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. 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. 

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 https://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 .

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 .

A bit of fun for Friday afternoon.  A question came via the forums on the subject of Portfolio Analysis in Project Server 2010 and how a decision would be made on the allocation of resources if the projects had exactly the same priority.  Firstly there is no real optimization logic in the resourcing part of the analysis – most of the heavy lifting happens in the cost analysis – where other metrics can also be taken into account.  In terms of the resourcing this just happens in order of priority – so the top project gets resourced, then the next, and so on.  For any project where there is insufficient of any type of resource then that gets forced out.  But what if you have equal priority projects?  In truth the Portfolio Manager would probably make the call and force in or out appropriately – but it is still technically interesting to know how it happens (well I wanted to know anyway…) I had a play around with this today. So in my scenario I was also interested in seeing how equal cost choices were differentiated as well as equal priority ones chosen to get resourced. And the interesting result is that each appears to make the choice in the totally opposite way! If I have 4 projects of equal cost and equal priority then the order of selection if the budget is not available to do all of them is carried out in the order of their GUIDs (PROJ_UID from the SQL Server database table MSP_PROJECT) – but not in the strict order that SQL might use – that sorts by the lowest order grouping of the last 6 bytes, but in the more straightforward left to right order of the hexadecimal characters. As an example – SQL Server would put D741FE6E-D426-4A41-8BCC-370FDE23A3E4 before 6EDBF314-BFAE-4838-8CBC-6B95E91EC0C5 based on the last group (37.. before 6B..) but the order the Portfolio Analysis uses would take 6E… before D7… So almost random, unless you happen to know (and care) what your GUIDs are. Now on to the resourcing. This happens in entirely the opposite order. So the ‘highest’ value of GUID (still using the full left to right logic) will get resourced first and the lowest gets resourced last. Again – it is really irrelevant how this happens and I’d guess you’d be forcing things in and out based on other criteria rather than some random 32 character hexadecimal string. If you are keeping up – or slightly ahead of me – this opens up an interesting paradox. If I have 4 projects that have equal cost ($20,000 each) and equal priority – and I have a budget of $80,000 – but they each require a resource that I only have one of – then the project with the highest GUID will get selected for resourcing! However, if my budget is just $79,000 then that very same project would be the one that was rejected at the cost analysis stage – leaving the next highest to get resourced!

Quick note to flag two important reading material we have just released. The first one is a free ebook that provides an overview of Office 365 (you should really try it out!): Free eBook: Microsoft Office 365: Connect and Collaborate Virtually Anywhere, Anytime . The second reading is a recurring topic: how do I integrate Project Server with SAP (wrote this already: Microsoft Project Server 2010 Integration with SAP ) and it discusses using Biztalk to bridge SAP with another application: Unleash SAP using the Microsoft Platform: Using BizTalk Server to Bring Two Worlds Together This document describes how to integrate, automate, and simplify business processes using Microsoft BizTalk Server and SAP. Business scenarios are presented involving SAP interoperability and technical patterns for how their solutions can be implemented with an integration platform like Microsoft BizTalk Server. Happy reading!

I’m happy to announce the release of the following white paper PerformancePoint Services for Project Server 2010 written by Emmanuel Fadullon, Delivery Architect Microsoft Consulting Services. This document provides a detailed guide for Microsoft Project Server 2010 users who want to avail themselves of the Business Intelligence (BI) features and functionality provided in the host platform of Project Server, Microsoft SharePoint Server 2010 Enterprise Edition. Specifically, this document covers PerformancePoint Services, which is an inherent service on SharePoint Server 2010. It is important to note that this document is about the mechanics specific to PerformancePoint Services in the context of Project Server data and not about providing sample EPM reports that are written in related BI tools like SQL Server Reporting Services and Excel Services. The use of reports in the document is entirely incidental and used simply to illustrate a PerformancePoint feature or functionality. A peek into Microsoft Project Server 2010’s powerful visualization capabilities discussed in the report below.  For additional information on Microsoft Project Server 2010 business intelligence & reporting please check out Business Intelligence in Project Server 2010 . Overall Scorecard Page with KPI Details Work Forecast by Month Page with Decomposition Tree

A very common problem people have when building their schedules is they have more work to do than they have budget for. We hit this problem all the time on the Project team when we are doing feature work (we just have so many good ideas for features thanks to all of your feedback). In the past when building budgets, we’d create multiple plans or even, aak, use Excel. Thanks to Inactive Tasks in Project 2010 Professional, we can now easily do this in Project. Before I get into the details, let me give you a little background. When we are doing budgeting, we don’t look at dates, we just look at how many dev hours are required for a feature and then work to get the rollup number to match our budget. So our initial schedules will often look like this: We’ll schedule all the tasks, once we’ve decided which features and tasks we’re going to do for the coding milestone. Yes, the feature and task names were changed to protect the innocent. Step 1 – Turn on the Project Summary Task. This allows you to see the rollups for your project. You can do this by going to the Format tab and checking Show Project Summary Task. Step 2 – Insert the Work field since this is really what I care about. After doing this, I can see it would take 1,793 hours to complete all of these features. Unfortunately I don’t have that much time. I only have 1,370 hours so I need to do some cutting. Step 3 – Working with my co-workers, I determine the priority of each feature. We track this in a text custom field, Feature Priority. I’ve collapsed the view to Outline Level 1 since right now we only care about features. Step 4 – Inactivate the lowest priority features by clicking Inactivate on the Task Tab – Schedule group. Before:   After: Notice how Work is now reduced to 1,385hrs. The original values are preserved for the inactivated tasks, they just don’t affect the rollups anymore. Step 5 – more cutting since I’m still over my budget of 1,370hrs by 15 hours. I could ask for an exception but I want to see if anything else stands out at this point. I’m going to expand the Medium priority features to get more details. Under feature 2, I see some pri 2 UI work that we could ship without so I’ll cut that. And we are now 1 hour under our budget – yay. At this point, our next steps would be to get the correct devs assigned to the tasks and the work scheduled out. Now clearly I simplified this from the real world experience to make the example fit the blog article but I hope this article shows that you can easily use Project when you are trying to hit an hour or cost budget. If your project is more date driven, you can still use inactive tasks, you’ll just have to adjust your predecessors along the way. From experience the hard part is not using Project, it is getting everyone to agree on the priorities of the various features and agreeing to the cuts. Click here for more info on Inactive Tasks.

This posting follows on from the one yesterday concerning how Project Server makes use of SharePoint permissions and features – but concentrates on some potential issues you can run into if you have a very large user base and also have projects that have very large teams.  We are also authoring a TechNet article explaining this in more depth – I will add a link once it is published.  This isn’t going in to the usage of the RBS or the other internal feature – but concentrates more on the technical issues of large user populations.  If you fit in this category then read on… As mentioned in the previous post Project Server 2010 uses the normal SharePoint permissions infrastructure to set access control both to the Project Web App (PWA) site and also any Project sites that are created for the individual project plans held in Project Server.  At the PWA site level the users are added to certain groups depending on their permissions levels within Project Server, so you will generally see SharePoint groups for Project Managers, Readers, Team members, Web Administrators and finally Workflow and Project Detail Pages Administrators.  Each of these groups will show the individual PWA users as appropriate.  This is a change from 2007 where individuals were added to the PWA site with specific permission levels.  You may have seen issues in 2007 if you had large numbers of users as whenever changes were needed in the member permissions the users would be removed and then added back – so some users would get “Access Denied” until they were added back after a change.  We had some workarounds for this scenario involving turning off the user synchronization.  In 2010 we made a couple of changes to avoid this problem – firstly the change to using groups at the PWA site level, and secondly we now remove then add back each individual as opposed to removing everyone and then adding back everyone.  So getting an Access Denied in the same scenario in 2010 is very unlikely. At the Project site level however we do not use the group approach and manage the users on an individual basis.  In most scenarios this is not an issue as the number of resources assigned to a project, and hence added to a site, is generally low compared to the total number of users in the system.  However there could be some scenarios where customers wish to have many or all of their users accessing many or all of their project sites.  This could either be achieved by adding many users to a project – or by giving the “View Project Site” permission at the team member level in a category that included many or all projects.  Either way this would then add very many individual users with permissions to the project sites.  And why is this a problem?  If the numbers of users is large then it is possible for the recommended software boundaries and limits of SharePoint Server to be exceeded – and this can lead to performance issues.  Each user added individually to a site would be considered a security scope – and the recommended maximum number of unique security scopes per list is 1,000 (SharePoint Server 2010 capacity management – Software boundaries and limits – https://technet.microsoft.com/en-us/library/cc262787.aspx ).  So each list and library in the site would be inheriting from the parent site permissions – and would exceed this limit if more than 1,000 user had access to the site (as they are individually added). In our experience the performance issues would then relate to any change in the site membership caused by changes in the categories or groups – or following such actions as adding a user or inactivating a user.  For example this last action of inactivating a user will actually remove that user from all sites they have access to – and the reason the limit is imposed is that when it is exceeded the process of removing a user can become very slow – particularly if this same user is also being removed from very many sites each of which is also way over the limit.  In extreme cases with multiple user inactivations it is possible that the server will become unresponsive and unable to authenticate users. I will include some of the error messages you might see, and the corresponding ULS entries at the end of this posting so that this aids finding this potential cause. If you are following along (and I’m sure some of my readers are way ahead of me…) you will realize there is a Catch-22 here.  Your server could become unresponsive whenever you need to manage users because you have too many users with permissions on the sites.  So remove some users… which will then make the server unresponsive…  How to escape from this loop?  There are some quick ways to get this resolved – but before rushing in to that it is better to review what it is you are really trying to achieve.  If the desire is that most people can access most projects then managing the permissions outside of Project Server using groups and inheritance from PWA is the way to go.  If however the fact that many users had access to many sites was really a mistake then you need to correct that issue – and either remove the “View Project Sites” from the offending category or reduce the number of resources assigned to the plans – but first of course you need to stop the synchronization of users to the sites otherwise any action may make your server very slow.  As mentioned in the previous post this can be achieved by us of the UserSyncSettings method – and just repeating that here to save you having to open that post up: The setting can be changed using the PSI and the Admin Web Service and the UserSyncSettings method. The enumeration of values that can be set are detailed at https://msdn.microsoft.com/en-us/library/websvcadmin.usersyncsettings_di_pj14mref.aspx , and the method described at https://msdn.microsoft.com/en-us/library/gg229480.aspx . Turning off the Project Site sync is achieved by the enumeration DisablePWS.   Member name Description Enabled Value=1. Enable all synchronizations. DisablePWA Value=2. Disable synchronization with Project Web App. DisablePWS Value=4. Disable synchronization with project sites for the user. DisableEmailSync Value=8. Disable email synchronization. DisableAll Value=16. Disable all synchronizations. This relates to settings in the MSP_WEB_ADMIN table of the Published database in the WADMIN_USER_SYNC_SETTING column. So for example a query such as: Update [ProjectServer_Published].[dbo].[msp_web_admin] set [WADMIN_USER_SYNC_SETTING] =4 would do the same as using the method to set the enumeration: int syncSettings = (int)SvcAdmin.UserSyncSettings.DisablePWS; We’d certainly prefer you to not touch the DB correctly – but I’m guessing that many of you would find it much easier to execute a SQL query to update the value than to write the code necessary to do the same (I certainly would!). Once that is turned off then you can safely do user management without causing further performance problems – but of course it would still be possible to trigger the same issues if you tried removing the users directly from the project site, using the out of the box SharePoint functionality. One way to remove the users very quickly without triggering the individual deletion that causes the problem is to inherit permissions from the parent.  This can be done via the UI on the Site Actions, Site Permissions page of the individual sites: This will lose any custom permissions.  If your end goal is to give most users access to most sites then this may be how you want to keep things long term – so before taking this action you would probably want to be sure that the PWA site has the right permissions for all the users who need access – as that will be where this site will start inheriting from once you click the button.  Obviously if you have thousands of sites (and you probably have if this is causing you problems) then PowerShell can automate the change for you. Run the following PowerShell command in the SharePoint 2010 Management Shell $site = Get-SPSite “ ” Foreach ($web in $site.AllWebs) {
        $web.Update()         $web.ResetRoleInheritance()         $web.Update()         } $site.Dispose() This (or the UI method) would also need to be run for any new sites created to avoid the problem coming back – but if you had ‘corrected’ your categories and team memberships then all would be ok going forward. If you do decide that leaving everything inheriting is right for most projects then you may also want to have certain projects that are more ‘secret’ and for these you will need to continue to manage the permissions and user on an individual level.  One thought I had was to set a property on these ‘special’ sites via PowerShell and then you could use this property to filter out in a modified version of the above PowerShell command and ensure you didn’t reset the role inheritance accidentally.  I should also point out that if you use the Synchronize option on the Project Sites page then this would re-break the inheritance – so should be avoided. As a guide we have seen the issue with a customer with around 3000 users where they are nearly all added to each of their 1500 sites.  And as promised, here are the error messages and ULS entries.  Different users may see different symptoms – but the user who initiates the issue, perhaps by inactivating a couple of resources, will see the ‘Save’ button on the page apparently stick on the ‘clicked’ position and eventually get a “An unexpected error has occurred.” message.  The correlation ID will be found in the ULS logs and will have several rows all relating to a SQL deadlock and the Critical level one will look like: 08/10/2011 12:17:02.85    w3wp.exe (0x2178)    0x314C    SharePoint Foundation    Database    5586    Critical    Unknown SQL Exception 1205 occurred. Additional error information from SQL Server is included below.  Transaction (Process ID 80) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.    886d9cdd-5c0c-4f3a-8f89-f4e8c92acde3 Another High level one that gives more information on the query causing the issue will be something like: 08/10/2011 12:17:06.97    w3wp.exe (0x2178)    0x314C    SharePoint Foundation    Database    tzkv    High    SqlCommand: ‘SET NOCOUNT ON; DECLARE @DN nvarchar(256),@LN nvarchar(128),@@DocUIVersion int,@@S uniqueidentifier,@@Level tinyint; DECLARE @ItemId int; DECLARE @@iRet int; DECLARE @ExtraItemSize int; SET @@Level = 1; SET @@S=@wssp0;  EXEC @@iRet = proc_SecRemoveUserFromSite @@S, @wssp1, @wssp2  SELECT @ItemId = @wssp3  IF @@iRet 0 BEGIN  GOTO DONE; END  ;BEGIN TRAN IF NOT EXISTS( SELECT tp_ID FROM UserData WHERE tp_ListId = ’06C8C9BB-B10B-4042-8859-9F9985E73E76’ AND tp_ID = @ItemId  AND tp_Level = 1 AND tp_RowOrdinal =0) BEGIN  SELECT @ExtraItemSize = 0  EXEC @@iRet = proc_AddListItem @SiteId…. I have shortened it considerably – but the key piece is the proc_SecRemoveUserFromSite.  Finally the ‘Unexpected’ one: 08/10/2011 12:17:06.97    w3wp.exe (0x2178)    0x314C    SharePoint Foundation    Runtime    tkau    Unexpected    System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80131904    at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateMembers(String bstrUrl, UInt32 dwObjectType, String bstrObjId, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bRemoveFromCurrentScopeOnly, Boolean bSendEmail)     at Microsoft.SharePoint.Library.SPRequest.UpdateMembers(String bstrUrl, UInt32 dwObjectType, String bstrObjId, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bRemoveFromCurrentScopeOnly, Boolean bSendEmail)    886d9cdd-5c0c-4f3a-8f89-f4e8c92acde3 Once the sever is in the condition – which could last 15-30 minutes, then other users will get timeouts on their pages and the ULS logs may show the following: 08/10/2011 12:20:22.30    w3wp.exe (0x1228)    0x1454    SharePoint Foundation    Monitoring    b4ly    High    Leaving Monitored Scope (ExecuteStoredProcedureDataReader — MSP_AUTH_GETUSERBYNAME). Execution Time=120002.728838442    2be0491a-a64b-4237-8cfc-40342a374d49 08/10/2011 12:20:22.30    w3wp.exe (0x1228)    0x1454    Project Server    General    8ym5    Monitorable    PWA:https:// /PWA, ServiceApp:Project Web App Service Application, User:, PSI: SqlException occurred in DAL:  0 0 -2     System.Data.SqlClient.SqlError: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.         at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)     at … I should also point out that use of the Project Site Provisioning Settings page option to not automatically synchronize users may avoid you getting in to this situation – but you still need some process to control access – and if most sites are unrestricted then the inheritance option from PWA may be worth a try.  Just as a reminder – the option on the Project Site Provisioning Settings page looks like this: and un-checking will stop the automatic addition of Project Server users to sites (but will not remove ones who are already there). Hopefully the workarounds given will assist in avoiding these types of issues if you really need to have very large numbers of users accessing each of a large number of project sites. As promised – once we have a TechNet article out in the wild I will link to it.

In Project Server 2010, and in 2007 too for that matter, Project Server manages the setting of permissions on the various SharePoint sites used for Project Server.  So for example when you add a user to Project Web App (PWA) they will also be added with the right permissions to the PWA site itself.  If you then add them to a project then depending on your settings they would also get added to the SharePoint site for that specific project plan – enabling them to use the Issues, Risks and document features. This can lead to potential issues depending on how you have configured Project Server, how many users you have and also which features of SharePoint you are using.  This post deals with the last point, but I will be publishing another post shortly that deals with the other issues you can come across – particularly what can happen if you have very many users with access to very many projects, and hence access to very many sites. But first – alerts and notifications.  We had a customer who found that they could set notifications on a list on a project site through a subscription, so that they could get notified of any additions, changes etc.  However, they noticed that they were not getting the notifications they expected and when they examined the list again the subscription was gone!  It transpired that the method Project Server uses to keep the user list in sync (the various settings within groups and categories – and team changes within a plan) was breaking this feature.  Basically we remove and then add back the users ensuring they have the correct permissions – but unfortunately in the process we lose any subscriptions they may have to be notified of changes in the list! So if this is a feature you are using and wondering why it keeps breaking – or perhaps it is a feature you would like to use – then it may be best to disable the synchronization with the project sites to avoid this problem.  This would of course mean that you would then need to manually keep control of the user permissions on the sites.  If you go this route then I would also suggest that adding users to groups rather than individually is the best way to go.  More on that in a future post… The setting can be changed using the PSI and the Admin Web Service and the UserSyncSettings method.  The enumeration of values that can be set are detailed at https://msdn.microsoft.com/en-us/library/websvcadmin.usersyncsettings_di_pj14mref.aspx , and the method described at https://msdn.microsoft.com/en-us/library/gg229480.aspx . Turning off the Project Site sync is achieved by the enumeration DisablePWS. Member name Description Enabled Value=1. Enable all synchronizations. DisablePWA Value=2. Disable synchronization with Project Web App. DisablePWS Value=4. Disable synchronization with project sites for the user. DisableEmailSync Value=8. Disable email synchronization. DisableAll Value=16. Disable all synchronizations. This relates to settings in the MSP_WEB_ADMIN table of the Published database in the WADMIN_USER_SYNC_SETTING column.  So for example a query such as: Update [ProjectServer_Published].[dbo].[msp_web_admin] set [WADMIN_USER_SYNC_SETTING] =4 would do the same as using the method to set the enumeration: int syncSettings =  (int)SvcAdmin.UserSyncSettings.DisablePWS; We’d certainly prefer you to not touch the DB correctly – but I’m guessing that many of you would find it much easier to execute a SQL query to update the value than to write the code necessary to do the same (I certainly would!).  Wouldn’t it be nice if we could do it via PowerShell?  That is something I am looking into – and the Admin web service is an ideal candidate to be wrapped up like the Project and Security web services have been at https://archive.msdn.microsoft.com/pj14PowershellPSI by Mike Shughrue. As mentioned I will be following this up with another post with some other considerations around turning off the automatic sync particularly if you have large numbers of users who each have access to large numbers of sites.

As announced by Jan last week, we will have a dedicated Project/Project Server pre-event ahead of SharePoint Conference 2011 on Sunday October, 2nd, 2011 : SharePoint Partners – Interested in growing your business with Project 2010? A great opportunity for SharePoint/non Project Portfolio Managers to learn about our stack. More info here . There will also be plenty of Project sessions during SPC11 so don’t wait and register, looking forward to see you in California in early October: