Recently I was asked to take a look at a SharePoint 2010 system that was having a few problems. Looking at the patching status it was still running SPS2010 RTM, so the 1st job was to at least get SP1 installed, then the latest CUs on top, and so the fun started…
I downloaded the appropriate service packs, and kicked off the foundation SP1 install and got the following.
The error appeared straight away, no upgrade log was written, nothing in the ULS logs and nothing in the Windows logs.
I used /? switch on the end on the Service Pack file to get the usage options.
Next I used the log option to have a look at the output of the Service Pack install
There is quite a lot of information written to the log file, but nothing that pointed to the reason of the failure, next was to extract the patch and see which patch file was causing a problem.
the c:\patches\sp folder now contains the extracted patch files and the EULA text file
Running the patch wsssp1-x-none.msp was giving the following error.
So the Service Pack wouldn’t install because one of the patches inside it didn’t realise that SharePoint was installed, interesting as the error I would have expected to if SharePoint wasn’t installed would have been this one…
I tried running the Config Wizard, but that didn’t help either, after checking with one of colleagues who knows all about packaging software he thought that the failing msp was probably looking for a specific registry key or value.
So I decided to try running a repair from Control Panel, to reset all the original Server settings while not effecting the content or configuration databases (this process ran for quite a long while)
Then I re-ran the Config Wizard, (which now asked about removing the server from the farm).
Finally, after all this the Service Pack would finally install.
Another day done in the world of SharePoint.Follow @NeilKing41
I recently had an issue at a client where the Project Center was failing to load and returning “An unknown error has occurred” on the page. We have seen this behaviour before and it’s usually some corrupt Project data that causes it, but I’ve never had the time to get to the bottom of the problem. Fortunately, today I had a bit more free time to investigate.
This particular issue is caused by custom fields that are linked single value (read: not multi-select) lookup tables erroneously getting multiple values assigned to them. How this occurs is as-yet unclear, but it appears to be symptomatic only in the published database – the draft and reporting databases are unaffected.
So, what’s the fix?
There are a couple of things that can be done, depending on your level of access and technical capability. Firstly, we need to identify the plans that are causing the issue. The fastest way of doing this is with a little piece of SQL code (change <Published_DB_name> to your actual Project Server published database name):
USE <Published_DB_name> SELECT (SELECT proj.PROJ_NAME FROM dbo.MSP_PROJECTS proj WHERE pcf.PROJ_UID = proj.PROJ_UID) as ProjectName ,(SELECT pcfv.[MD_PROP_NAME] FROM [dbo].[MSP_CUSTOM_FIELDS] pcfv WHERE pcfv.[MD_PROP_UID] = pcf.MD_PROP_UID) as CustomFieldName ,count(*) FROM [dbo].[MSP_PROJ_CUSTOM_FIELD_VALUES] pcf GROUP BY PROJ_UID, MD_PROP_UID HAVING COUNT(*) > 1 ORBER BY ProjectName, CustomFieldName
(credit to Jan @ Piet Remen’s blog for the above query – http://pietremen.blogspot.co.uk/2012/01/project-centre-unknown-error-has.html)
This will return a list of projects, custom fields and the number of times that the custom field has been populated. If any project appears as an output of this script, you can view view the issue by taking a look at the Project Information through PWA. Affected custom fields will appear comma separated – e.g. Project Priority: Low, Low, Low, Low – where they should only appear as a single value.
The fix is quite a simple one – republish the project. This pushes the values from the draft database back to the published database and overwrites the broken custom field values. Check in PWA > Project Information, or re-run the above query to check that the plan is now fixed in the published database. I have seen a couple of instances where this did not fix the problem, and we had to delete the published version of the plan, and re-publish from the draft version.
It is still unclear how long the project will remain “fixed”, we have had a couple of plans reproduce the issue after being republished.
Microsoft have identified the issue, and released a fix, which can be found here: http://support.microsoft.com/kb/2598251
This KB is also included in the roll-up package (http://support.microsoft.com/kb/2597152) though it’s not documented.
These KB’s will prevent the issue occurring in the future, but will not fix existing problems – be sure to follow the above steps to ensure that the plans are fixed. As always – be sure you have database backups before applying updates!
Office 2010 / #MSProject 2010 SP1 + June 2011 Cumulative Update links #ProjectServer #SharePoint #SP2010 #PS2010
As ever, now that my server environment is starting to stabilise after installing SP1 + June 2011 CU (Security Validation issues aside of course), we are now looking at updating the clients to reflect the update.
This is especially important in a Project Server / Microsoft Project 2010 environment.
As a result, here are some useful links that took me a while to dig out for the Office / Project 2010 client updates:
Project 2010 Service Pack 1 x86:
Project 2010 Service Pack 1 x64:
Project 2010 – June Cumulative Update 2011 x86 & x64:
NB: only update binary available for Project 2010 in the June 2011 CU
Office 2010 Service Pack 1 x86:
Office 2010 Service Pack 1 x64:
Office 2010 – June Cumulative Update 2011 x86 & x64:
NB: no single update binary available, update client applications as required.
Other Useful Links:
On my travels I also found this other link which lists all the updates for the SharePoint and Office Systems:
A quick post to say that the InfoPath / Form Service 2010 issue I was having at one of my clients has now been fixed and is included as part of the SharePoint 2010 – April 2011 Cumulative Update.
My description of the issue can be found here: http://ghamson.wordpress.com/2010/10/17/form-services-infopath-2010-bug-found-in-multi-line-plain-text-boxes/
Microsoft KB Articles
- InfoPath Hotfix: http://support.microsoft.com/kb/2516485
- Project Server 2010 – April 2011 CU: http://support.microsoft.com/kb/2512801
- SharePoint Server 2010 – April 2011 CU: http://support.microsoft.com/kb/2516485
- SharePoint Foundation 2010 – April 2011 CU: http://support.microsoft.com/kb/2512804
I would also like to take this opportunity to thank the Microsoft support and product teams in working with us to detail the issue and come to a resolution. We are testing the go live environment with April CU 2011 as I write this and the fix will dramatically improve the UI for the custom forms that we have developed.