Cascade Skyline - with Microsoft Logo and Project Support header - author Brian Smith

September, 2011

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Installing Project Server to an existing SharePoint Server farm


    I know that unless you load all the bits before running the Configuration Wizard then you will always add Project Server to an existing SharePoint Server farm – but in this blog I am specifically talking about adding Project Server to a farm that has been up and running for a while – and potentially has Service Packs and Cumulative updates loaded.

    The best way to do this is to create a slipstream installation – and there are plenty of resources out there that explain this process – but basically you extract your various updates and put them in the Updates folder under your install source and these will get applied as the installation proceeds.  However, in researching this topic I learned that this isn’t the only way so thought it was worth sharing.  You can load the original release version of Project Server (RTM – release to manufacture) even if your farm is at the SP1 level plus cumulative updates.  In reality I only tested to August CU, and I am sure there will come a point where this will not be practical (SP2 would block an RTM install) – but for now it certainly works and would be supported.  That said – it would be good practice to bring the farm up to a level where all the components were at the same release level.  For information on the release level of each component you can go to Central Administration, Upgrade and Migration and Check Product and Patch Installation Status.  I have a ton of language packs loaded so I won’t give you a full screen shot(s) but the foot of mine looks like this:


    So you can see the version installed for each component (usually matching the RTM or last Service Pack, as in this case) as well as the Cumulative Updates (June superseded by August) along with useful links to the KB articles.  In my case I do have Project already loaded and updated to August CU.

    At the top of the page there is also a link to the latest updates - Click here for the latest information on available updates for SharePoint 2010 Products 


    Going to that page also has the link for Project updates – which is Updates for Project Server 2010.  You will also see on this screenshot that the Galician/Galego language pack is still at the original release version of 14.0.4763.1028.  This language pack (and Basque) does not yet have the language pack service pack released – but it is still possible to update to SP1 for the farm without having to update all the language packs.

    That was just an aside on versions and where to find them – but the main point is that you can load RTM Project Server to a farm and use Project Server.  It will get loaded at the original release version even if you had already loaded the rollup Service Pack (SP) and/or Cumulative Updates (CU) that included Project Server – the Project files will not have been applied.  Once you are ready to load the SP/CU you will need to re-load it and run the configuration wizard.  You will not get any warnings or errors even though you feel are re-installing something you already applied – it correctly recognizes that there is new stuff to update.  The only slight exception are the language pack service packs – which you do not need to reload – and Project Server will benefit from any language packs (and language pack service packs) loaded before it was installed – so no need to re-install those either.

    Another good thing to check is the database status – once you have run the config wizard all should be good – but if you forget then you will see messages Database is too old and upgrade is required as mentioned in my previous blog posting - Project Server 2010- Can I delay running the SharePoint Configuration Wizard-.

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Are your prints from PWA blank? Try turning off IE compatibility.


    Quick posting today – we had a customer seeing issues when printing from the Project Web App schedule web part where if they went over a certain number of rows (around 42 – spooky!)  the printed page was blank (although the pop-up with just the grid displayed for printing looked just fine).  This was after seeing this warning – which is expected – when you are printing a grid of more than 30 rows: Print Warning - There are more than 30 records in the current grid.  Preparing the print page for this many records may cause the browser to alert that the page is running slowly.


    In my testing internally I saw the same, I clicked OK on the warning, the new page opened with everything looking good and I could choose my printer – but the print was blank (I did try a large plan and in this case the final 40 or so tasks printed…) 

    However, if I turned off the compatibility setting under Tools, Compatibility View Settings, so that these were not applied to Intranet sites then all worked as expected and I got a good print.  If you have explicitly set your PWA sites in compatibility you may see the same issue.  If you really need prints though you may find Project Professional more flexible in giving you a good printed page.

    *** Update 9/12/2011  I should point out this is based on IE 8/9 - it does appear that IE 7 has some issues with the PWA printing that changing settings cannot fix  ***.

  • Brian Smith's Microsoft Project Support Blog

    Project Server: Post SP1 Cumulative Update Webcast Series


    In a little over an hour, at 8:00 AM PST, the first of the post SP1 webcasts will start – presented by Adrian Jenkins and me.  The SP1 webcast delivered in July also included coverage of the June Cumulative Update.  We will be talking about both Project Professional and Project Server, and the 2007 and 2010 releases.

    Here is the link for the August 2011 Cumulative Update TechNet webcast titled Information about Microsoft Project and Project Server August 2011 Software Update  -

    And the rest of the series can be found at the following links.

    Here’s the URL for the  11/8/2011 8:00:00 AM - Information about Microsoft Project and Project Server October 2011 Software Update

    Here’s the URL for the  1/10/2012 8:00:00 AM - Information about Microsoft Project and Project Server December 2011 Software Update

    Here’s the URL for the  3/13/2012 8:00:00 AM - Information about Microsoft Project and Project Server February 2012 Software Update

    Here’s the URL for the  5/8/2012 8:00:00 AM - Information about Microsoft Project and Project Server April 2012 Software Update

    Join us if you can – or listen to the recording if you can’t make it – available later on the same URL.

  • Brian Smith's Microsoft Project Support Blog

    Project Server: SharePoint Installation issues when using FIPS


    Most days I learn something new, and yesterday was no exception.  I was working with one of our Senior Consultants, Rob Bowers, on an installation problem.  The SharePoint Configuration Wizard was failing during the initial configuration of the farm on step 3.  The error that came up was:

    Configuration Failed.  One or more configuration settings failed.  Completed configuration settings will not be rolled back.  Resolve the problem and run this configuration wizard again.  The following contains detailed information about the failure:

    Failed to create the configuration database.

    An exception of type System.InvalidOperationException was thrown.  Additional exception information:  This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

    In the PSCDiagnostics log created during the execution of the wizard the same errors could be seen – the first was:

    Task configdb has failed with an unknown exception , followed by

    Exception: System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
       at System.Security.Cryptography.SHA256Managed..ctor()
       at Microsoft.SharePoint.UserCode.SPSolutionValidatorCollection.ComputeHash()
       at Microsoft.SharePoint.Administration.SPUserCodeService.UpdateValidatorsHash()
       at Microsoft.SharePoint.Administration.SPPersistedChildCollection`1.Add(T newObj, Boolean ensure)…

    A quick search (Bing of course) found that FIPS was referring to the Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules.  An article on TechNet has a security note that mentions some potential issues with workflows – but not the failure in the configuration wizard.  Another great link from Mahesh Srinivasan at helped move things in the right direction.  Even with FIPS not enabled through group policy settings there can still be registry keys set that are enabling some of the features.  In Rob’s case, like Mahesh, he found that the two keys were set to 1 – enabled, and a third key was set to 0 – disabled.  The keys were:

      • HKLM\SYSTEM\ControlSet001\Control\LSA\FipsAlgorithm
      • HKLM\SYSTEM\ControlSet002\Control\LSA\FipsAlgorithm
      • HKLM\SYSTEM\CurrentControlSet\Control\LSA\FipsAlgorithm

    Until each of these was set to 0 the error above blocked running of the configuration wizard.  Remember, any time you are changing registry keys you should take back-ups.  Obviously this change is something you should to talk to your platform security team about too – as if you are changing these values you may need to get an exception to your company’s hardening policy for your SharePoint servers.

    FIBS 104-2 is intended to ensure that only only validated cryptographic modules are used in software when securing data.  SharePoint uses cryptographic modules, for example MD5,  that are not validated – but it is in fact not using them to secure data but to create hash values that are used as unique identifiers.  It is this action that FIPS is blocking that causes the failure in the configuration wizard.

    For more information on FIPS 104-2 see, and for general FIPS information see

  • Brian Smith's Microsoft Project Support Blog

    Project Server: Why do my date selections lose a day?


    *** Update - should probably have mentioned this more prominently - but this DOES NOT affect schedule dates - just the display date ranges in Resource Plans. When I re-read it after posting I realised this might look quite alarming***

    This was an interesting issue that Adrian Jenkins finally cracked – and I had seen postings on the forums and we had some internal customer cases.  It appeared to be related to time zones as the problem had only occurred in Europe and Eastward.  So if your time zone is left of Greenwich (Sorry – UTC) you probably don’t need to read any further.  But as this may work in reverse also – might just be worth seeing why this happened.

    In my example below, I have my server and SharePoint farm running at UTC+2 – Athens, Bucharest and Istanbul (and others of course).  I’ve also set the regional settings to Greek (but don’t have the language pack) – just so the date format is the same format as most people this affects are using.   If you are in the Resource Plan and want to change the date range and say you select 1/12/2011 to 31/12/2011:


    you will find when clicking OK that the actual dates are set to 30/11/2011 and 30/12/2011


    Looking behind the scenes we can see that the actual date (and time!) saved is midnight.  This is persisted in the User Properties table – as it isn’t setting the resource plan start and end date – just the current window of dates that you wish to review.  Worth remembering that there can be stuff before and after these dates… but back to the plot.  These dates are stored in a numeric string representing the number of milliseconds since 1/1/1970.  Between selecting, saving and recalling there is a conversion according to the current time zone and basically it thinks that at midnight on whatever day you choose (assuming you are UTC+X)  – it was still yesterday at UTC! In reality the time stored is the UTC time taking in to account the time zone difference – so in my example I set 1/12/2011 (it assumes time of 0:00) but what was saved was actually 2 hours earlier 30/11/2011 22:00.

    Easy workarounds – either put in the day after you really want – or add a time value to the string.  So I could enter:


    and this would then give me the right dates.


    This shouldn’t affect anyone West of Greenwich – however, if I put in a time here in the Pacific Time Zone that was after midnight UTC – such as 5pm, then my date would go forward to the next day!

    Sorry for any confusion this has caused.  I should also point out that although I am specifically talking about the date range for the resource plan view this could also affect other pages too – but generally only dates persisted as part of a view.  Rest assured that in my testing it does not affect dates entered in the schedule grid.

Page 1 of 2 (6 items) 12