On my test server, while attempting to upload about ten .odc files to the Trusted Data Connection library in Project Server 2013's business intelligence center, I came across this message:

I quickly found the explanation of the behavior here:  http://blogs.technet.com/b/seanearp/archive/2010/07/08/your-client-does-not-support-opening-this-list-with-windows-explorer.aspx

And the fix here: http://technet.microsoft.com/en-us/library/cc772567.aspx

This DOES require a reboot.

My favorite ULS logging PowerShell command is described here:  http://technet.microsoft.com/en-us/library/ff607721.aspx.  The Merge-SPLOgFile cmdlet pulls trace log entries from all farm computers into a single log file on the local computer and it works in Project Server 2010 and 2013, too. 

I can hand this link to customers and they can run the Merge-SPLogFile command from PowerShell.  The result is a single output file they can easily upload for me to review.  The real benefit to this command, as someone who does troubleshooting remotely, is that I get all ULS entries from all the servers combined.  Pretty neat.

Merge-SPLogFile -Path "c:\mergelog\log.txt" -Overwrite -level High -StartTime "03/25/2014 12:00" -EndTime "03/25/2014 12:59"

Edit: You can also use this command to pull just the entries related to a particular correlation ID, which is very useful, because the command will pull only those ULS log entries related to the error you are seeing.  Just replace the Correlation below with your own from whatever error message you see.

Merge-SPLogFile -Path C:\mergelog\log.txt -Correlation 29b5c483-c48b-4ef2-b4b3-f5e29f635d31

This creates a much smaller output file to search through and you know that ALL of the entries in the log file are related to the particular problem.

I ran into a problem with a customer late last week that I had never encountered before.  That's not really saying much, but the solution surprised me!

The timesheet queue was filled with “waiting to be processed” jobs that had begun to pile up on Friday morning.  There were more than 7,000 jobs waiting to be processed and this was causing anxiety among the users and admins because Friday is “submit your timesheet” day.

I screen shared with an administrator and we saw four Timesheet Queue related jobs were sitting at a State of "Processing" with a completion of 100%; they were just sitting there and not going away. I cancelled the jobs thinking they were hung somehow and knowing it would only affect four users’ timesheets.  That seemed to resolve the problem as the queue began to show fewer jobs on every refresh, so we ended the call.  But... I checked in with the customer later in the day and the queue was still at 1500 jobs and they were processing “very slowly”.

You can see in the screenshot above that two jobs were interfering with each other; the same stored procedure, projectserver_published.dbo.msp_timesheetq_lock_next_available_group, being run from either app server were blocking each other and couldn’t run simultaneously.  CPU time and disk I/O were off the charts.  A different SQL query showed that each procedure was taking almost a second each.  The customer's SQL DBA ran the query below to clear the process cache in the SQL Server, which caused SQL to refresh/recompile the stored procedure’s execution plans.  This caused the queue to start running smoothly again and to process jobs very quickly.  When we finally ended the call, there were 7 active jobs in the queue and they were all project save/publish related.

Here’s a link to the free process cache command the DBA used; DBCC FREEPROCCACHE (Transact-SQL) - http://technet.microsoft.com/en-us/library/ms174283.aspx

Researching the problem further, I found this blog article from Brian Smith sums up what we were seeing and provides precisely the fix the customer DBA used - http://blogs.msdn.com/b/brismith/archive/2012/09/19/when-your-project-server-queue-slows-down.aspx

You can see from Brian’s example that the execution time for the stored procedure is 21 seconds:

     08/09/2012 16:10:25.10 Microsoft.Office.Project.Server (0x36D0) 0x2E58 SharePoint Foundation Monitoring b4ly Verbose Leaving Monitored Scope (FillTypedDataSet -- MSP_ProjQ_Lock_Next_Available_Group). Execution Time=21102.179988219601 <correlation ID>

In the customer's logs, the execution times for this procedure were around 30 seconds:

     01/10/2014 02:33:38.50  Microsoft.Office.Project.Server (APP123:0x1384)   0x023C  SharePoint Foundation         Monitoring         b4ly        High       Leaving Monitored Scope (FillTypedDataSet -- MSP_TimesheetQ_Lock_Next_Available_Group). Execution Time=31384.190169421      16aab2dd-88e0-4ea5-b686-6baedd1882e8

I believe we ended up in this situation because the SQL Server has been up and running for a long period of time.  Clearing the process cache on the SQL Server was precisely the correct action.

Now if I see this behavior again, I will recognize it quickly from the queue behavior and the ULS logs and take the corrective action.  As proactive actions, you can schedule a FREEPROCCACHE job or restart your SQL Server at a regular interval.

I have a customer who wanted to be able to assign project plan tasks to a team resource, then have the actual users self assign those tasks from My Tasks in PWA.  What she was asking for is called team assignment pooling.

You can use teams to pool assignments under a single resource where they can be later reassigned to other resources. For example, you could create a team resource named "Development" to which you assign software development tasks. By assigning this resource to the Development team and selecting the Team Assignment Pool check box, you enable other users on the Development team to see any tasks assigned to the Development resource and to accept the assignments in PWA. You could also select Team Assignment Pool for a team lead and have all assignments go through that person for distribution to team members.

Here's how you go about setting this up...

Setup the lookup table and custom field.
1. As an administrator, go to PWA > Server Settings > Enterprise Custom Fields. 
2. Create a custom lookup table called Team Name and populate it with the team names that you want to use.  In this example, I used “Team 1 DEV”.  You might use DEV Team 1, DEV Team 2, etc.  Try to avoid using managers' names in the team names because they will change every so often.
3. Edit the Team Name custom field to use the new Team Name lookup table.  You will be asked if you want to make the association permanent; you do.

Configure users.
4. As an administrator, go to PWA > Server Settings > Manager Users.
5. Edit user account.
6. In Team Details section, check the Team Assignment Pool box and select "Team 1 DEV". 
7. Repeat for any other users on Team 1 DEV.  Additionally, you can make these edits from Resource Center by multi-selecting and choosing to Edit Resource or clicking Open in the Editing group of the Resources ribbon.

Create team assignment pool resource.
8. While in Manage Users, create a Work resource called "Team 1 DEV Resource" and set its Team Details field to Team 1 DEV in the same manner.

Create project plan
9. Create project plan in Project Pro.
10. Build Team from Enterprise and add Team 1 DEV and the resource who are part of Team 1 DEV.
11. Assign appropriate tasks to Team 1 DEV Resource user.
12. Save and publish.

User Actions
13. Log into PWA as a regular user.
14. Go to Tasks.
15. From the Tasks ribbon, click Insert Team Tasks.
16. Select the checkbox for the task you will assign yourself to.
17. Click Assign to Me from the Tasks group on the Tasks ribbon.
18. Click Tasks in Quick Launch.
19. The new task is self assigned to the user.

Reference:

http://office.microsoft.com/en-us/project-server-help/add-a-user-account-in-project-server-2010-HA101827971.aspx,
Team Details section.

I learned today that there is a Project Server 2013 reporting database schema tool that can be downloaded.  Here's the link to more information and the download itself:  http://blogs.msdn.com/b/project_programmability/archive/2013/01/28/project-server-2013-reporting-database-rdb-schema-reference.aspx.  There are differences in reporting of on-premises vs. Project Online.  For Project Online, you can use REST queries of the ProjectData OData service. See the links for info.

The Project Server 2013 reporting schema includes three new tables, 27 new views, and a total of 33 tables and views that include new fields.

For those invested in reporting, this is your field day!