SharePoint (and Project Server) Shenanigans

I am a Project Server and SharePoint consultant but my main focus currently is around Project Server. I have been working with Project Server for nearly five years since 2007 for a Microsoft Gold Certified Partner in the UK, I have also been awared with the Microsoft Community Contributor Award 2011. I am also a certified Prince2 Practitioner. This article has been cross posted from pwmather.wordpress.com (original article)

I have seen this issue a few times now in Project Server 2013 where users see the error “View Failure The view failed to load. Press OK to reload this view with the default settings. Press Cancel to select another view”

Clicking OK gives another error: “You don’t have permissions to view any projects”

This isn’t the case in this example.

There are two scenarios that I know of that cause this particular issue, these are described below:

Note: My farm is in the Project Server permission mode.

For an existing user:
•    Log in as User A, access the Project Center, access “View A” – all works great
•    Change the permissions so that User A no longer has access to “View A” or delete “View A”
•    Log in as User A, access the Project Center, User A will see the View failed to load error

For a new user – never accessed the farm before:
•    Prevent access to the default Project Center “Summary” view for the Team Members Group but allow access to other Project Center views
•    Create a new user (User B) that is only in the Team Members Group
•    Log in as User B (a new user on the farm), access the Project Center, User B will see the View failed to load error

The ULS logs gives the following error:

Error is: GeneralSecurityAccessDenied. Details: User does not have permission to this view. . Standard Information: PSI Entry Point:  Project User: i:0#.w|support\userb Correlation Id: 2f5e74c7-c751-e311-9419-00155d15d154 PWA Site URL: http://vm753/PWA SA Name: ProjectServer PSError: GeneralSecurityAccessDenied (20010), LogLevelManager Warning-ulsID:0x347A6230 has no entities explicitly specified.               ea70589c-4f64-e059-ef52-a016cf63c1ed

InitViewReportInfo ViewUid:63d3499e-df27-401c-af58-ebb9607beae8 is not found.        ea70589c-4f64-e059-ef52-a016cf63c1ed

The remote command PWAProjectGetProjectCenterProjectsForGridJsonRemoteCommand encountered an unexpected exception. ea70589c-4f64-e059-ef52-a016cf63c1ed

If you have removed the default Project Center Summary view, either removed access to it or deleted it (new user scenario), or removed any other Project Center views that users may have accessed last (existing user scenario), the known workaround at this point is as follows. Click the Projects Tab, select a view from the view menu then refresh the page. At this point the view will load and the Project Center will continue to load successfully.

I am a Project Server and SharePoint consultant but my main focus currently is around Project Server. I have been working with Project Server for nearly five years since 2007 for a Microsoft Gold Certified Partner in the UK, I have also been awared with the Microsoft Community Contributor Award 2011. I am also a certified Prince2 Practitioner. This article has been cross posted from pwmather.wordpress.com (original article)

I have seen this posted quite often on the Project Server forums  so I thought I would write a quick blog post.

When upgrading from Project Server 2010 to Project Server 2013, you will need to recreate the customised Project Site templates. Project Server 2013 doesn’t recognise the Project Server 2010 project site templates. Project Server 2013 project sites now have a template name / ID of PROJECTSITE#0, Project Server 2010 project sites use PWS#0. This can be seen below:

2013:

2010:

When recreating the new site template in 2013, start with the “Project Site” template on the Collaboration tab found on the new SharePoint site page.

I am a Project Server and SharePoint consultant but my main focus currently is around Project Server. I have been working with Project Server for nearly five years since 2007 for a Microsoft Gold Certified Partner in the UK, I have also been awared with the Microsoft Community Contributor Award 2011. I am also a certified Prince2 Practitioner. This article has been cross posted from pwmather.wordpress.com (original article)

A quick blog post to detail how you can check the Project DB size in Project Online. With Project Online, each Project Web App site collection can have a 10 GB Project database:

http://office.microsoft.com/en-gb/office365-project-online-help/project-online-software-boundaries-and-limits-HA104063425.aspx

To check Project database usage for Project Online, access your SharePoint Admin page in Office 365. On the Site Collections page, select the PWA site collection, then click Settings from the Project Web App menu as shown below:

This will display the Project Database Usage:

I am a Project Server and SharePoint consultant but my main focus currently is around Project Server. I have been working with Project Server for nearly five years since 2007 for a Microsoft Gold Certified Partner in the UK, I have also been awared with the Microsoft Community Contributor Award 2011. I am also a certified Prince2 Practitioner. This article has been cross posted from pwmather.wordpress.com (original article)

The answer to this question in my opinion is no. In this blog post I will explain why using an example.

Firstly I have created a new test duration field on my test Project Server 2013 environment, this is called _duration.

For the purpose of this post, I also have a new Project Detail Page (PDP) that only displays the _duration field. A new project is created, the schedule it not important here, just the value you specify in the _duration field. As you can see below, I have entered 10 days:

Save and publish this to Project Server and take a look at the project in PWA. You can see the project in PWA as shown below:

Project Center:

Notice the _duration field correctly shows the 10 days.

PDP:

Notice the _duration field correctly shows the 10 days.

All ok at this point. Before we move on, I just want to show the project options for this project, specifically the hours per day:

Notice this is set to the default 8 hours per day. Update this to 7 hours per day. You will then notice that the _duration field correctly updates to 11.43 days:

Reset this back to 10 days then save and publish the project again.

The Project Center still display 10 days in the _duration field:

The PDP will show the incorrect duration in the _duration field:

The PDP’s assume the default 8 hours per day is used for each project. At this point the PM will probably think, lets correct the 8.75 days to 10 days. So lets do this, this is now correct in the PDP:

Great. Not quite, now take a look in the Project Center:

Notice the 11.43 days. Also check the Project Information in Project:

I was aware of this issue in Project Server 2010 but only just came across the same thing in Project Server 2013.

Hopefully that explains why I answered “no” to displaying duration fields on the Project Server PDP’s, it will save a lot of confusion with your Project Managers! As with all answers there is normally an exception to the rule and you can probably guess what that is. Displaying duration fields on PDP’s will be fine if your projects are 8 hour days

I am a Project Server and SharePoint consultant but my main focus currently is around Project Server. I have been working with Project Server for nearly five years since 2007 for a Microsoft Gold Certified Partner in the UK, I have also been awared with the Microsoft Community Contributor Award 2011. I am also a certified Prince2 Practitioner. This article has been cross posted from pwmather.wordpress.com (original article)

Just a quick post to make you aware of a design change in the Project Server 2013 project site sync when in Project Server permission mode. The only issue is that you may find project team members without assignments are granted edit access to the associated project site rather than read access – this is now by design.

In Project Server 2010 if a user / resource was added to the project team but not assigned to any tasks they were added to the Readers (Microsoft Project Server) SharePoint group on the associated project site. This is different in Project Server 2013, when the users / resources are added to the project team but not assigned to tasks they are added to the Team Members (Project Web App Synchronized) SharePoint group rather than an equivalent Readers (Microsoft Project Web App) group. This is working as designed as there are now only two SharePoint groups on the Project Sites used in the permission sync:

Project Managers (Project Web App Synchronized)
Users who have published this project or who have Save Project permission in Microsoft Project Web App.
 
Team Members (Project Web App Synchronized)
Users who have assignments in this project in Microsoft Project Web App.

This could be misleading if you used 2010 and also if you view the SharePoint permission level descriptions. The Project Server 2013 Project Site permission levels can be seen below:

The “Readers (Microsoft Project Web App)” states “Users who have been added to this project in Microsoft Project Web App, but not assigned to tasks.”

Also the “Team Members (Project Web App Synchronized)” SharePoint group permission description is not quite accurate as it should states that it also includes project team members without assignments:

“Users who have assignments in this project in Microsoft Project Web App”

Hope that helps.

I am a Project Server and SharePoint consultant but my main focus currently is around Project Server. I have been working with Project Server for nearly five years since 2007 for a Microsoft Gold Certified Partner in the UK, I have also been awared with the Microsoft Community Contributor Award 2011. I am also a certified Prince2 Practitioner. This article has been cross posted from pwmather.wordpress.com (original article)

Take care when updating the Central Admin regional settings as certain things stop working. The link to update the region settings doesn’t exist on the Site Settings menu probably for this reason but you can type the URL manually and access the page. Just add _layouts/15/regionalsetng.aspx to the URL.

Central Admin region settings were updated to English (United Kingdom), which is ID 2057.

An example of functionality that stops working is the PowerPivot Dashboard Processing Timer Job:

For the benefit of the search engines:

‘The Execute method of job definition Microsoft.AnalysisServices.SPAdding.UsageProcessingTimerJob(ID 5144359a-e86d-429f-8a5c-8c06cca109ee) threw an exception’

The following error is thrown in the URL logs:

For the benefit of the search engines:

Failed to load ‘http://sp13:15000/PowerPivot%20Management/567b4062-7a0b-4b24-a7f5-994bbed90cf1/2057/Server%20Health.xlsx’ with error: ‘The workbook does not exist at the specified location’

This error lead us to the fix. Notice the 2057 in the URL. Navigating the the PowerPivot Management library, there was no 2057 folder, only a 1033 folder.

A 2057 folder doesn’t exist, on 1033 – for English (United States):

At this point you can either create a a new folder for the correct locale in this case 2057 for English (United Kingdom), then copy the 3 documents shown below from the 1033 folder to the 2057 folder:

The timer job will now run successfully and the dashboard will update. The other option is to set the regional settings for Central Admin back to English (United States) – probably the recommended fix!

The the Dashboard will update and show data: