A customer pain point brought to my attention this week is related to linking tasks to risks from PWA vs linking risks to tasks via the project site’s Risks list.
The customer noticed that, in Project Server 2010, linking a task to risk from PWA’s drill down view of the project schedule does not make that link show up in the Reporting database so he could report on it using SSRS (SQL Server Reporting Services). However, he noticed that if he links the risk to the task from the Risks list, he was able to report on the link immediately.
I dusted off my Project Server 2010 test server (just kidding, it gets such frequent and heavy testing that I never turn the VM off) and created a project plan with a project site.
I opened the project site, and then clicked on the Risks list. I created a new risk and added a link to a task from the plan. The queue presented this Reporting (Project Sync) job:
Next, I opened the schedule in PWA and drilled into the plan, then linked the risk there, but no reporting job materialized in the queue. Nothing queue related happened at all, in fact, unless I saved the plan, but still there was no Reporting job (notice that I did not publish here, which definitely would have fired a reporting job). Then, I published the plan and the Reporting (Project Sync) job fired.
So, when the user creates the link between task and risk from PWA, the user must publish the plan in order to make the Reporting (Project Sync) job run. After that job runs, the information related to the link will be in the Reporting database. When the user creates the link between risk and task from the Risks list, the user doesn’t need to do anything else because the Reporting (Project Sync) job runs immediately.
This is because changes to Project Server Risks list on the site writes directly to published db so the reporting database has be to be updated. I ran a profiler trace and found a stored procedure that writes to the published DB when a risk to task link is made. When you edit a plan in PWA, your changes do not impact the published db until you publish, so absent any changes, the published and reporting data still match. Another way of looking at this behavior is to see that project managers may not want changes made to the plan published until they are ready for the changes to be publicly available. Changes to the site are publicly available without a project publish so the sync job fires when a task/risk is linked.
There real problem to my mind is that there is no way for users to know there is a difference in the behavior based on where you link the task/risk. That’s because there is no warning/dialog pop-up saying if you edit the plan in PWA, you won’t be able to report on the new link until you publish. The result is that a user links a task/risk via PWA and doesn’t know he can’t report on that link until he publishes while at the same time, the user can create the risk/task link from the Risk list and report right away.
From a database and code perspective, linking a risk to a task and linking a task to a risk are actually very different. Strictly speaking, linking a risk to a task from the Risks list writes to the Published DB, which then requires a corresponding update to the Reporting DB. Linking a task to a risk from the Project Center drill down view writes to the Draft database – and remember, you can make changes all day to the Draft and never see those changes until you publish the plan. While the actions the user takes appear to be roughly the same whether you link from a task to a risk or vice versa, the command being sent to the databases differ behind the veil of the user interface. The behavior editing a plan and not seeing those changes until a publish occurs is perfectly in line with a project’s not being made public until a project manager wants them to be by publishing.
Because the project site is already public, linking a risk to a task causes an update to occur against the reporting database. This behavior is unlikely to change in Project Server 2010, but the fact of the behavior should be relayed to project managers so they can determine the best choice for linking tasks and risks.
Naturally, this line of investigation led to testing on Project Server 2013. Does the same thing happen there?
For testing, I created a plan called 0000 Linking Risks and published it with a project site on an out of the box instance of PWA.
In PWA, I drill into the project plan schedule and you see the URL below:
http://ps2013c:8080/PWAoob/Project%20Detail%20Pages/Schedule.aspx?ProjUid=807c7051-7881-e411-9433-001dd8b73e9d&ret=0
I selected a task, then clicked on the Options tab, and then on the Related Items button. At this point, the URL changes to the project site URL, where I can create the association.
This means I’m in the project site when I make the association, so the Reporting job fires when I save. This DID NOT HAPPEN in Project Server 2010.
http://ps2013c:8080/PWAoob/0000%20Linking%20Risks/Lists/Tasks/DispForm.aspx?ID=2&ContentTypeId=0x010800AAD67843BFB5C64E81A19F453581A719&ShowRelatedItems=1
The fact I’m in the project site when I create the association means the behavior is different in Project Server 2013 and the Reporting (Project Sync) job fires because there is only one way to link a task to a risk. I thought this was worth pointing out and it will make my customer happy to know.
Brian Smith has posted a very interesting blog article about synchronizing users in Project Server 2010 versus Project Server 2013. He says there are behavior differences between Project Server 2010 and Project Server 2013 regarding user synchronization to project sites. I quote, "One key part of this change should be taken into account when migrating – as there is one 2010 setting that no longer has UI to change it – and if it is disabled before migration it cannot be turned on again in 2013."
Brian goes into details of that setting and provides a workaround after describing how the settings and behavior have evolved.
For anyone migrating from Project Server 2010 to Project Server 2013, this is a must read.
The highest rule of permissions best practice is to keep your permissions scheme simple.
If you can use the default categories, groups, and permissions with only minor changes, or none at all, do so!
Avoid creating unnecessary groups and categories. Having a large number of groups and categories within an instance of PWA can stress the authorization system, which can affect performance.
Use the default permissions set.
The default permissions in combination with the RBS (resource breakdown structure) checkboxes on Categories is sufficient to efficiently manage permissions in most customer situations with as little overhead as possible.
Always test permissions changes in a test environment on a copy of production data.
Avoid making changes to production permissions without thorough testing.
Use Act as Delegate feature in your test environment to determine if your permissions changes have the impact you desire.
If you must change permissions directly in production, only check Allow checkboxes and avoid directly selecting Deny for anything.
Utilize the RBS checkboxes available on Categories and configure the RBS lookup table to mimic your org structure, then…Update the resources’ RBS values on a regular schedule.
A permissions scheme that relies on the RBS allows you to use the default permissions and allows resources to see only things based on their org structure or other breakdown structure as defined by the customer.
Utilizing the RBS mean you must frequently update the RBS for new resources or resources whose org structure changes. Typically, this update should happen at least weekly.
Avoid creating separate security groups for team members and project managers for each project plan.
This creates an administrative workload every time a project is created and then every time the project membership changes.
Imagine having 700 projects in flight and each has two security groups, one for project managers and the other for team members.
The more cases where users have rights that differ from the groups they are in, the more trouble you will have figuring out why the permissions are broken for certain users.
Avoid utilizing Deny.
It is important to consider when you are configuring a permission to Deny that the Deny setting supersedes any Allow settings that apply to the user for that permission by means of other group memberships. Limiting your use of the Deny setting can simplify permissions management for large groups of users.
Configure the category and group permissions, then leave it alone.
Changes to the permission scheme should be infrequent.
Once you have settled on a permissions scheme, leave it alone unless there is a clear business need and a formal request has been received.
I've always maintained a list of my own links to updates, but I learned of these two links today. You can find and manage updates for SharePoint and Project Server with these two links. I hope you find this useful; they both hold a coveted spot in my favorites for CUs now.
Find and manage updates for SharePoint 2013 and SharePoint 2010 in one place. Use the links on this page to get more information about updates and download the updates themselves.
SharePoint Updates: http://technet.microsoft.com/en-us/library/dn789211(v=office.14).aspx
Find and manage updates for Project Server 2013 and Project Server 2010 in one place. Use the links on this page to get more information about updates and to download the updates themselves.
Project Server Updates: http://technet.microsoft.com/en-us/library/dn789214(v=office.14).aspx
This link has been making the rounds lately and I wanted to share it.
SharePoint patching demystified by Stefan Gossner: http://blogs.technet.com/b/stefan_gossner/archive/2014/08/19/sharepoint-patching-demystified.aspx
A customer asked me today if he could make changes to the Reporting database in his Project Server 2010 environment. The short answer is, yes, you can create entities in the Reporting database. Below is a scrubbed version of the conversation.
Customer: I have a request from the business to create one or more custom tables in the Project Server Reporting Database and run reports against those tables using <Big Reporting Application> from <Big Application> Company. Do you have any information about best practices for making changes or what is allowed to be changed in the Project Server 2010 Reporting database?
Me: Add, but don’t modify or delete any entities already present and thoroughly test your additions in a test environment. Beyond that, the only best practices I would forward would be related to designing SQL tables and other entities and I would reach out to a SQL PFE for those.
Customer: Will Microsoft still support us if we create a custom SQL Table in the Project Server Reporting Database?
Me: Yes. Ideally, we are talking about only a few tables or less. If we are talking about using <Big Reporting Application> with many, many tables, I would recommend you consider a separate database (with all of its attendant overhead), but less exposure to upgrade risks.
Customer: Can Cumulative Updates or SP2 Updates impact the custom tables in the database?
Me: The risk of an impact on custom tables always exists and can be mitigated by thorough testing of any CUs or SPs in a test environment with the same configuration as the production tables. Also, good backups prior to an upgrade can alleviate concerns. Please see this link for information on what you can add tables/entities/etc. to the Reporting database: http://technet.microsoft.com/en-us/library/ff686786.aspx#section5. I also found this link: http://msdn.microsoft.com/en-US/library/ms504195(v=office.14).aspx#pj14_Programmability_Databases.
The following MPUG article by Kenneth Steiness is a good introduction to the basics of baselining. A baseline is a snapshot of your project at a point in time and you can create up to 11 of them. Baselines provide a benchmark to compare against and also provide variances. The variance helps show how far you were or are off of the original estimate, so you can take corrective actions. This can help avoid delays, cost overruns, resource issues, and much, much more.
Here's the article: http://www.mpug.com/articles/baselining-best-practices/
As you go through the article, under the Maintaining the Baseline section, look at how he uses inactive tasks.
Until I can figure out who to cross post between the Project Server PFE Team Blog and my own blog, I will double post.
My customer wanted to be able to provide his Portfolio Managers with read only access to all project sites in PWA. Because an AD group for Portfolio Managers already exists, we can use that AD group in the script and add it to all project sites under PWA with Read Only permission. Credit to Gerald Parish for helping me with the code.
As always, test this code in your test environment.
<################## Disclaimer################# This software (or sample code or query) is not supported under any Microsoft standard support program or service. The software, sample code, or query is provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the software and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the software be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the software or documentation, even if Microsoft has been advised of the possibility of such damages."#>Exit
<# #################Instructions#################Review the disclaimer above. Remove or comment out the "Exit" in order to be able to run the script.Go to the last line of this PowerShell script file. In that line, change the -site value to the PWA URL. Also, change the -newuser value to be the AD username or group that you want to provide Read Only permissions for.
For example,... AddReadOnlyUsers -site http://projects.contoso.com/pwa -newuser "contoso\Financial Applications Group"becomes AddReadOnlyUsers -site http://projects.yourdomain.com/pwa -newuser "yourdomain\Financial Applications Group"
Run this entire script from the SharePoint 2010 Management Shell. The log file will be created in the same directory you run the .ps1 from.#>
Function Local:AddReadOnlyUsers{
[CmdletBinding()]Param( [parameter(Mandatory=$true)][string]$Site, [parameter(Mandatory=$true)][string]$NewUser )
$global:Logfile = ".\" +[Datetime]::Now.ToString("MMddyyyy_hhmmss_tt") + "_User_log.txt"try {Start-Transcript -Path $Logfile -ErrorAction Stop } Catch { $Error[0] }
$permLevel = "Read"$SiteCollection = get-spsite $Site$AllWebs = $SiteCollection.AllWebsforeach ($webSite in $AllWebs) { Write-Host -NoNewline "($webSite.url) Adding $($NewUser)..." $oNewuser = $webSite.EnsureUser($NewUser) if ($oNewuser -ne $null) { Write-Host -ForegroundColor Green "Complete" Write-Host -NoNewline "Granting $($permLevel) to $($NewUser)... " $roleDef = $webSite.RoleDefinitions[$permLevel] $RoleAss = New-Object Microsoft.SharePoint.SPRoleAssignment($oNewuser) $RoleAss.RoleDefinitionBindings.Add($roleDef) $webSite.RoleAssignments.Add($RoleAss) $webSite.Update() Write-Host "Complete" } else { Write-Host -ForegroundColor red "Error"; exit}}
Stop-Transcript}
AddReadOnlyUsers -site http://projects.contoso.com/pwa -newuser "contoso\Financial Applications Group"
Today, I learned about a PowerShell script that is already part of some of the diagnostic tools I use in my day to day work and I just didn't know it was in there. It's freely available online so I wanted to share.
You can go to http://spsfarmreport.codeplex.com/ and download the package to get a full report on your SharePoint farm.
The ReadMe.txt has important information about what will be needed to successfully run the tool. Because I'm using SharePoint 2013 as a base for my Project Server 2013 installation, I used the PowerShell cmdlet Get-ExecutionPolicy to learn the execution policy was already set to Unrestricted on my test farm.
I downloaded the package, then moved the o15 files to a specially created folder on my Project Server 2013 test server called spsfarmreport. The really neat thing about this tool is you can run it on only 1 server in the farm and it will grab results from all of them.
So, I ran .\2013SPSFarmReport.ps1 from a PowerShell command prompt window and this was the output...
PS C:\spsfarmreport> .\2013SPSFarmReport.ps1o15WriteInitialXMLo15farmConfigo15WriteFarmGenSettingso15enumServerso15writeServerso15enumProdVersionso15writeProdVersions2o15enumFeatureso15writeFeatureso15enumSolutionso15writeSolutionso15enumSvcAppso15enumSPSearchServiceAppso15enumSPSearchServiceo15enumHostControllerso15enumSearchActiveTopologieso15enumSearchConfigAdminComponentso15enumSearchConfigLinkStoreso15enumSearchConfigCrawlDatabaseso15enumSearchConfigCrawlRuleso15enumSearchConfigQuerySiteSettingso15enumSearchConfigContentSourceso15writeServiceAppso15enumSPServiceApplicationPoolso15writeSPServiceApplicationPoolso15enumSPServiceApplicationProxieso15writeSPServiceApplicationProxieso15enumSPServiceApplicationProxyGroupso15writeSPServiceApplicationProxyGroupso15enumWebAppso15writeWebAppso15writeAAMsnAPso15enumContentDBso15writeContentDBso15enumCDConfigo15writeCDConfigo15enumHealthReporto15writeHealthReporto15enumTimerJobso15writeTimerJobso15WriteEndXMLPS C:\spsfarmreport>
So where did the output file actually go? It's not in my special spsfarmreport folder.
The readme file has the answer: Run the "[Environment]::CurrentDirectory" command to know where the output XML is written to.
I did this and found my output was being dropped here in the system32 directory.
PS C:\spsfarmreport> [Environment]::CurrentDirectoryC:\windows\system32
I copied these files to my spsfarmreport folder where the SPSFarmReport.xslt is and was able to open the .xml file using IE.
My report is pretty boring because I only have one SharePoint Server in this farm, but you get the idea.
Here's a screenshot of the output I see.
Happy hunting!
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.
Problem:
Team member with My Tasks set by Team Members template and the same for Global Permissions.
Team member user goes to PWA > Project Center and clicks on a project name to open the Project Detail Pages.
Receives message:
Workflow Status
Access Denied
Basic Info
Details
To work around:
Go to PWA > Server Settings > Manage Groups.
Click Team Members group.
Click My Tasks in Selected Categories.
Add "Open Project" to My Tasks for Team Members as in the screenshot below.
(If you save now and attempt to reproduce the Access Denied message as a team member, you will see this message: This Web Part was unable to load, as below.)
Back in Team Member permissions, scroll down to Global Permissions.
Add New Project under Project.
Save and close Team Member permissions.
Have the team member user access the project in Project Center by clicking the project name. The Project Details will now appear as below
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.
If you are wondering what the differences are between Project Online and Project Server 2013, here's a useful link. Project Online and Project Server 2013 on-premises are based on the same set of features and functionality, but there are differences between the two. The following table provides an overview of the differences between Project Online and a Project Server 2013 on-premises environment.
http://technet.microsoft.com/en-us/library/dn268595.aspx
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.
Today, I learned that Alerts and Reminders isn't available in Project (2013) Online.
http://social.technet.microsoft.com/Forums/projectserver/en-US/a3d80d76-7d9c-4011-8a41-e7e0ff7a8bd8/alerts-and-reminders-in-project-2013-online
Edited 2014-01-15:
But wait, there's more...
http://blogs.technet.com/b/projectsupport/archive/2014/01/14/project-online-notifications-and-reminders.aspx
The August 2013 CU for Microsoft Project and Project Server 2010 and 2013 were released today.
http://blogs.technet.com/b/projectsupport/archive/2013/08/13/microsoft-project-server-2010-and-2013-august-2013-cu-announcement.aspx
Please thoroughly test the CUs on a test environment before rolling out into production! This link is an excellent place to start with functionality validation test plans: http://technet.microsoft.com/en-us/library/gg502592(v=office.14).aspx.
Download them into Word docs and store for repeatable test procedures you can modify to suit your business needs.
I ran into this problem again with a Project Server 2007 customer today. The project plan had more than 2000 lines and the % Complete at the Project Summary Task level did not make sense to the project manager; it seemed much lower than it should have considering the work already done on the plan. This is because of how the % Complete is calculated for summary tasks. The apparent discrepancy is compounded when you have many summary and sub- tasks.
Here’s the article you will need to explain to anyone how the % Complete field is calculated. It’s old, but pertinent even for the most recent version of Project, and was provided by Microsoft Customer Technical Support.
“How Percent Complete Is Calculated for Nested Summary Tasks” http://support.microsoft.com/kb/101495/EN-US.
You may also consider setting calculations to be automatic in Project 2007 using the instructions below. This won’t change how the % Complete field is calculated but will show how changes to the plan affect the plan automatically. Also ensure there are no resources assigned to summary tasks at any level and no tasks are successors to the project summary task.
To set the calculation mode in Project Pro 2007 to automatic using below steps.
1. Open Project Professional 2. Select Tools > Options> 3. Select Calculation Tab. 4. Set the Calculation Mode to Automatic.
Editing an enterprise custom field lookup table, I received an unexpected error with no other information in the PWA page. The following error appeared in the ULS log.
Application error when access/_vti_bin/PSI/LookupTable.asmx, Error='gzip' is not a supported encodingname. Parameter name: name
at System.Globalization.EncodingTable.internalGetCodePageFromName(Stringname)
at System.Globalization.EncodingTable.GetCodePageFromName(Stringname)
at System.Text.Encoding.GetEncoding(Stringname)
at Microsoft.Office.Project.Server.PSIForwarderHandler.ProcessRequest(HttpContextcontext)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&completedSynchronously)
I clicked on Start > Administrative Tools and launched Internet Information Services (IIS) Manager.
I clicked the root node of the server.
Then, I double-clicked Compression.
I unchecked "Enable dynamic content compression" and clicked Apply.
I reset IIS from a command prompt using the command iisreset.
I was then able to open the custom field lookup table successfully without error.
Service Pack 2 (SP2) for Project 2010 and Project Server 2010 has been released.
http://blogs.technet.com/b/projectsupport/archive/2013/07/23/project-2010-and-project-server-2010-service-pack-2-sp2-released.aspx
As with any service pack (SP) or cumulative update (CU), please run the installation and perform functionality validation testing in a test environment using the link below before installing in production.
http://technet.microsoft.com/en-us/library/gg502592(v=office.14).aspx
"Responding to government legal demands for customer data" by Brad Smith, General Counsel & Executive Vice President, Legal & Corporate Affairs, Microsoft
http://blogs.technet.com/b/microsoft_on_the_issues/archive/2013/07/16/responding-to-government-legal-demands-for-customer-data.aspx
What you will learn in the webinar
http://blogs.office.com/b/project/archive/2013/06/17/office-15-minute-webinar-get-started-with-project.aspx
Microsoft Project Server 2007, 2010 and 2013 April 2013 CU Announcement - http://blogs.technet.com/b/projectsupport/archive/2013/04/11/microsoft-project-server-2007-2010-and-2013-april-2013-cu-announcement.aspx
These things don't appear connected, but I was unable to run the SharePoint Products and Technologies Configuration Wizard while setting up Project Server 2007 on a test server.
The configuration failed with this message:
04/05/2013 11:37:29 8 INF Creating a new farm with config db SharePoint_Config content db SharePoint_AdminContent_4e3513ab-b81e-4ec6-a369-f2d357b550a6 server brwhite4 for farm mode04/05/2013 11:37:57 8 ERR Task configdb has failed with an unknown exception04/05/2013 11:37:57 8 ERR Exception: Microsoft.SharePoint.Upgrade.SPUpgradeException: One or more types failed to load. Please refer to the upgrade log for more details.at Microsoft.SharePoint.Upgrade.SPDelegateManager.RegisterAssembly(Assembly asm, UInt32 nOrder) at Microsoft.SharePoint.Upgrade.SPDelegateManager.get_InitialTypeDictionary() at Microsoft.SharePoint.Upgrade.SPDelegateManager.GetDelegateTypes(TypetpObject) at Microsoft.SharePoint.Upgrade.SPDelegateManager.GetDelegates(Object o)at Microsoft.SharePoint.Upgrade.SPDelegateManager.GetUpgraders(Object o)at Microsoft.SharePoint.Upgrade.SPManager.NeedsUpgradeFalse(Object o)at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.set_NeedsUpgrade(Booleanvalue) at Microsoft.SharePoint.Administration.SPPersistedObject.Update()at Microsoft.SharePoint.Administration.SPFarm.Update()at Microsoft.SharePoint.Administration.SPConfigurationDatabase.RegisterDefaultDatabaseServices(SqlConnectionStringBuilderconnectionString) at Microsoft.SharePoint.Administration.SPConfigurationDatabase.Provision(SqlConnectionStringBuilderconnectionString) at Microsoft.SharePoint.Administration.SPFarm.Create(SqlConnectionStringBuilderconfigurationDatabase, SqlConnectionStringBuilder administrationContentDatabase, IdentityType identityType, String farmUser, SecureString farmPassword)at Microsoft.SharePoint.Administration.SPFarm.Create(SqlConnectionStringBuilderconfigurationDatabase, SqlConnectionStringBuilderadministrationContentDatabase, String farmUser, SecureString farmPassword) at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()
The fix was to uninstall Microsoft Office Professional Plus 2010, which I had from previous testing. Who knew?
I've seen a few of these problems lately where a user clicks on a link in PWA that should open a timesheet, a resource, etc., and instead, the user is rewarded with an "Error on page" in the lower left hand corner of IE.
In one case, we deleted temporary internet files using Tools > Internet options and that had no effect. So we deleted the contents of this folder on the file system in C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files and that prevented the problem.
In the other case, we ran a repair on Microsoft Office Professional 2010. Below are my notes from the call:
On user's workstation, User accesses PWA > Server Settings > Manager Users.He searches on a single user and attempts to click on the user's name to open the resource for editing.Nothing happens except an Error on page in the lower lefthand corner.'g_oFormPOst' is null or not an objectLogged into different workstation.Signed into PWA, did same steps to repro and was unable to, so problem is on user's workstation.Research indicates a repair of Microsoft Office will correct this issue; also clearing IE cache is an option.Deleted IE cache via Tools > Internet Options.Closed IE, reopened. Repro is still possible.Opened Control Panel > Programs and Features.Right clicked Microsoft Office Professional 2010 > Change > Repair.Allowed repair to complete.User restarted workstation.Repair fixed the issue; unable to repro the problem.
Microsoft Project Server 2007, 2010 and 2013 February 2013 CU Announcement here http://blogs.technet.com/b/projectsupport/archive/2013/02/14/microsoft-project-server-2007-2010-and-2013-february-2013-cu-announcement.aspx
You can also get the downloads from here: Update center for Office, Office servers, and related products http://technet.microsoft.com/en-us/office/ee748587.aspx