Archive
Issue Downloading SharePoint 2010 Prerequisite Installer Files
Strictly speaking this quick article doesn’t really have anything to with SharePoint, but hopefully it might help-out someone out there in SharePoint land.
One of the projects I’m currently working on is a 2010 Farm build, we are just getting the media set ready to install SharePoint with AutoSPInstaller, and of course need to download the Pre-Requisite Installer Files. For this particular project I have no local access to the servers so everything is being done by RDP on the server. So to download the Pre-Requisite Installer Files I’m was using this script from codeplex, but it was failing with a really wierd error
I tried it on a few different servers, but they all had the same problem.
I could of course simply open the script, grab the URL’s and paste them into a browser, but where is the fun in that.
This KB article talks about foreground / background transfers, and this being a problem when using background transfers and that foreground should be okay.
This article describes the cmdlet references for BITS and the –Priority switch that controls the foreground / background transfer setting
So the fix was to change this line
Start-BitsTransfer -Source $Url -Destination $DestFolder\$DestFileName -DisplayName "Downloading `’$DestFileName`’ to $DestFolder" -Priority High -Description "From $Url…" -ErrorVariable err
to this line
Start-BitsTransfer -Source $Url -Destination $DestFolder\$DestFileName -DisplayName "Downloading `’$DestFileName`’ to $DestFolder" -Priority Foreground -Description "From $Url…" -ErrorVariable err
and Voilá, pre-reqs downloaded . 
Project Server – "An unknown error has occurred"
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!
SharePoint Patching and “Action Required”
The last 2 SharePoint 2010 systems I have looked at have displayed the “Action Required” status for one or more servers in the farm in the “Manage Servers in this Farm” page, which is normally caused by incorrect server patching.
When you apply a Service Pack or CU to your SP2010 farm, you are normally looking at performing a quite straight forward 3 stage process.
Stage 1: Obtain patch:
Download the latest Service Pack or CU from here:
http://technet.microsoft.com/en-us/sharepoint/ff800847#LatestUpdates or use the “Use this page to view the latest patch status for products installed on servers in the farm” link on the CA site in Central Administration > Manage Patch Status
Stage 2: Install Patch
Once you have your Service Pack or CU, you will need to run it on each of the servers in your SharePoint Farm that has the SharePoint binaries installed, there is no special order to do this, but personally I like to run the patch on each WFE in turn, then on the application servers.
Once the patch has installed you will normally be prompted to run the Config wizard, if you are working on a single server farm, run the Config Wizard at this point, if you are working with a multi server farm cancel the Config Wizard and run the patch on each server on your farm.
Stage 3: Config Wizard
If you are running a single server system and have followed the instructions in stage 2, you should be finished. If you are running a multi-server farm you now need to run the Config Wizard to finalize the patch install. I like to run the wizard on the 1st server I patched and let it run to completion, then run the wizard on the rest of the servers in the farm, again there is no particular order to this but personally I like to run the wizard in the same order as I patched the servers, Once finished a quick reboot all round and we are done, and your status should be “No Action Required”
Why a picture is worth 1000 words
I have recently been working with a colleague on a new client implementation, putting together some options for a farm design. We came up with three different options, all with differing server layouts and SQL configurations. Trying to articulate these designs to a non technical audience can be almost as challenging as building the final solution, if you are with the client you can always sketch out your ideas on a whiteboard or flipchart, but documenting your design for a distributed audience is always a problem.
This is when Visio comes to your aid, Microsoft have some specific Visio shapes available for SharePoint and Project Server.
You can download the shapes from here http://www.microsoft.com/download/en/details.aspx?id=21480
These allow you to create your own TechNet style diagrams for SharePoint, below is an example I made earlier…
#ProjectServer 2010 / 2007 high-level Audit Export via #PowerShell #MSProject #PS2010 #EPM
Quite often there is a request for audit information from Project Server but unfortunately there is nothing available out of the box. This post covers a very high-level solution to this using the Project Server PSI and PowerShell.
Most actions in Project Server are processed via the Project Server queue, one simple way to get high-level audit information is to extract the queue information. The following PowerShell script uses the ReadAllJobStatusSimple method from the Queue System web service to export yesterdays processed jobs into a txt file with yesterday date appended to the filename:
$Today = Get-Date
$Yesterday = $Today.AddDays(-1).ToString("yyyy-MM-d")
$Filename = "C:\PSAuditExport\QueueExport-"
$filetype = ".txt"
$svcPSProxy = New-WebServiceProxy -uri "http://vm353/pwa/_vti_bin/PSI/QueueSystem.asmx?wsdl" -useDefaultCredential
$svcPSProxy.ReadAllJobStatusSimple("$Yesterday 00:00:01", "$Yesterday 23:59:59", "200", "0", "QueueCompletedTime" ,"Ascending").Status | Export-CSV $Filename$Yesterday$filetype -Delimiter "|"
For the full post please see:
#ProjectServer 2010 PSI data to a text file using #PowerShell #PS2010 #Project
I recently looked into accessing the Project Server PSI via PowerShell, luckily I came across this MSDN article that helped: http://msdn.microsoft.com/en-us/library/gg607685.aspx#pj14_GettingStartedTa_PowerShell. I needed to get the data into a pipe delimited text file without using compiled code (I’m not a developer!). I have done this before with T-SQL and SSIS but I wanted to try something different. For the purpose of this blog article of have edited the example shown in the MSDN article. The PowerShell script is below:
$pwaUrl = "http://vm353/pwa"
$svcProjectUrl = $pwaUrl + "/_vti_bin/PSI/Project.asmx?wsdl"
$c = Get-Credential
$svcProjectProxy = New-WebServiceProxy -uri $svcProjectUrl -credential $c
$svcProjectProxy.ReadProjectList().Project | Select Proj_name, Proj_UID, Proj_Type `
| Export-CSV C:\projects.txt -Delimiter "|"
This script will export out a list of Project names, Proj UIDs and the Project Types to the C drive in a text file called projects.txt using the pipe delimiter. Screen shots below show the script and the output.
Script:
Output:
This is a very simple example but provides a no code solution to access Project Server data via the PSI.
Project Server 2010 Database Maintenance Plans #EPM #PS2010 #ProjectServer
Just a quick post to mention that Microsoft have now released documentation on the recommended SQL server database maintenance plans for Project Server 2010. SQL Server database plans are very important in keeping Project Server performing reliably and smoothly. Please see the link below for more information:
