Problem: Another case of SharePoint Technologies and Configuration wizard (PSCONFIG) failing. Customer was running it via the GUI but it would fail with this message:

Troubleshooting: Of course, with this error, the first thing to check are permissions. Is the customer launching PSCONFIG as a local admin and does that account have farm rights within SharePoint? In this case, the answer was yes. I also made sure he was launching it as ‘Run as Administrator’, he was. Next, I asked him to run PSCONFIG via the command-line so that I could see more details: psconfig -cmd upgrade -force -inplace b2b –wait AND make sure to launch the SharePoint Timer service manually (because of a previous experience I had: http://blogs.technet.com/b/sharepointwarrior/archive/2012/12/07/sp-2010-psconfig-fails-with-missing-security-updates-that-are-actually-installed.aspx) but that did not work.

Resolution: Duh, ports 443 and 80 were blocked. After asking the network team to open these, PSCFONFIG completed successfully.

Fight Comparison: Holyfield vs Tyson II…I won by DQ just like Holyfield.

Problem: My customer discovered that they could not crawl any data from task list within the PWA site collection. I verified that the PWA site collection definitely was listed as a content source within the Search Service Application.

This list here:

Could not be found when searched upon because it was not being crawled:

Resolution: According to one of my colleagues, the official resolution is that this is fixed in Project Server 2013. He does, however, have a post on a workaround. WARNING: Use extreme caution when making changes to the registry!!http://blogs.msdn.com/b/maulikr/archive/2011/06/15/project-server-2010-how-to-configure-search-for-pwa-sites.aspx

Problem: The first problem was that I am not very familiar with Project Server. Even though SharePoint is required for Project Server, they are different products. After migrating some Project Server 2007 sites to Project Server 2010 a few site collections had a problem in which when users would attempt to create a risk from the Risk list and it would error out with our dreaded correlation ID error. This is what I saw in the logs: “Document Management         52od        Medium         MetadataNavigationContext Page_InitComplete: No XsltListViewWebPart was found on this page[/”

I also saw lots of references to a non-existent web application. The web application being referenced was part of the former Project Server 2007 farm. After a lot of dead-end troubleshooting I looped in my Project Server colleague Brooks White and he cracked this nut.

Solution:

“Apparently, project sites exported from Project Server 2007 and imported into Project Server 2010 can exhibit this behavior (where you can’t create new Issues or Risks and can’t properties on documents) when they do not have an associated project under Server Settings > Project Sites. This project site had no associated plan.”

• imported site using stsadm import command, with new name
• created association of the new site using same new name as above

For more good reading and tips on Project Server, check out my colleague Brooks Whites blog: http://blogs.technet.com/b/brookswhite/

Fight Comparison

The British Bulldogs vs Demolition…I was getting worked, just like the Dynamite Kid was as Ax and Smash teamed up on him. But then, he called his big bro Davey Boy Smith to help out, that changed everything…good teamwork.

Problem: Customer was trying to run SharePoint Technologies and Configuration wizard (PSCONFIG) to apply some patches to the farm. Although the binaries were already installed, PSCONFIG would fail with a message saying that the  some security patches were missing.

Troubleshooting: I looked in the PSCONFIG (Upgrade) logs and saw this: ”This upgrade session has been stopped. Possible causes include the process being terminated abruptly or the OS has rebooted. Please restart the upgrade again.” which was very strange because the server was not rebooted, PSCONFIG was failing for no reason. I had the customer run PSCONFIG via the stsadm command line: psconfig –cmd upgrade –wait –force –inplace b2b, but it still failed on that one server during the final step. Then we tried modifying the command by adding the noinstallcheck switch: PSConfig -cmd upgrade -inplace b2b -foce -cmd applicationcontent -install -cmd installfeatures -cmd installcheck –noninstallcheck, but it still failed, but this time we had the clue we needed in the PSCONFIG logs:

" syncUpgradeTimerJob: SPTIMERV4 is not running anymore. Return -1".
ERR - The exclusive inplace upgrader timer job failed

That means when during the upgrade, the SharePoint timer service was not starting when it needed to

Solution:

• run psconfig –cmd upgrade –inplace b2b –force –cmd installcheck –noinstallcheck
• as soon as stsadm says ‘upgrading sharepoint products” (step 4 of 5) open a command prompt and force start the SharePoint timer service “net start SPTimerV4”
• PSCONFIG succeeds!!!

Fight Comparison: This was a tag team effort