by Martin Laukkanen | Dec 3, 2009 | Project Pro 2010
After having a couple of days to test the migration procedures to 2010 I wanted to share my experience in this blog entry for everyone to see.
Overall I would say that the migration process is quite straightforward, certainly compared with what we used to have to do from 2003 – 2007! I’ll start by detailing the options and requirements for migration as at Beta2 of Project 2010:
Upgrade Options
To upgrade to Project Server 2010 from 2007 the following options are available:
1. In-place upgrade – in which the existing 2007 servers are directly upgraded.
http://technet.microsoft.com/en-us/library/ee662104(office.14).aspx
2. DB-attach upgrade – whereby you upgrade a backup of the databases only.
http://technet.microsoft.com/en-us/library/ee662500(office.14).aspx
3. Full database migration from Project Server 2003 –
http://technet.microsoft.com/en-us/library/ee662498(office.14).aspx
Upgrade Requirements
Different circumstances require the use of different option, or options in the case of number 3. However the specific requirements for each can be summarised as:
1. In-place requirements:
a. Existing Project Server 2007 must be installed in a 64-bit environment including SQL Server 64bit.
2. DB-attach requirements:
a. Extra hardware is required on which to run 2010 separately from the 2007 version.
3. Project Server 2003 requirements:
a. This is a two step upgrade – first migrate from 2003 to 2007, then 2007 to 2010 using either method 1 or 2 above.
b. For this migration a Virtual Migration Environment (VME) is available for use, it contains a fully pre-configured 2007 instance including all required tools in a Hyper-V image format. Using this requires the use of a DB-Attach upgrade for the second step.
Other requirements:
SQL Server version required for the server which will host the 2010 databases is as follows;
- 64-bit version of SQL Server 2008 SP1 with CU2, or
- 64-bit SQL Server 2005 SP3 with CU3.
Once the upgrade is complete the restored databases will be configured in Backwards Compatibility Mode, which enables the following:
Backwards Compatibility Mode (BCM)
- Enabled by default after upgrading
- Enables connection to Project Server 2010 by Project Professional 2007 clients
- Can be disabled from Server Settings, but then can not be re-enabled
Note: When enabled the following client features are disabled:
- Manually scheduled tasks are not available on the server or client.
- Tasks cannot be set to inactive.
- Font strikethrough is not available.
- All departmental custom fields are enforced in Office Project Professional 2007.
Upgrade Procedure Summary
In-place upgrade
The in-place upgrade is similar to a typical MOSS service pack installation, once all software version pre-requisites have been met (Oct CU, SQL + CU, etc) then the process is roughly as follows:
1. Stop WWW service on all front end servers and stop Project Queue service on all application servers
2. Install SharePoint 2010 binaries on all servers in farm (do not run config wizard yet)
3. Install Project Server 2010 binaries on all servers in the farm
4. Run the SharePoint Configuration Wizard on the server hosting Central Administration
5. Run the SharePoint Configuration Wizard on the remaining servers in the farm
6. Restart all Queue and WWW services previously stopped
There you have it.
by Martin Laukkanen | Dec 1, 2009 | Project 2010
I’m doing some testing this week on migrating to 2010 so I have a few things I will be blogging about in the next day or so, but I noticed that my draft blog is getting very long so I thought I’d split one very important part of it into a separate entry altogether.
A few things have come out as obvious ‘gotchas’ in the migration requirements, and I’ll summarise them here quickly;
- In-place migration requires 64bit Project Server / MOSS in order to ‘upgrade’
This one is no surprise as 2010 is 64bit only.
- Upgraded 2007 installations need to start by running all latest patches (as of October ’09), so that means:
Project Server OctCU, MOSS OctCU, WSS OctCU, SQL 2005 SP3 + CU3 OR SQL 2008 SP1 + CU2. It’s worthwhile when doing any new installs from no onwards to START at that level.
- DB-Attach upgrades (more on the upgrade methods in my main blog), which is probably the method that will be used 90% of the time due to #1 above will need Workspaces provisioned OUTSIDE of the default content database, i.e. Not at /PWA.
Fortunately there are steps provided in the migration guide to move your workspaces to a new site collection and content db so that this is possible.
Come back later for more comments and some lessons learnt.
by Martin Laukkanen | Nov 25, 2009 | Project Pro 2007, Troubleshooting
If you have configured any client to restrict permission to save a protected baseline then you might be unlucky enough to see this one, basically restricting this permission causes the next save to completely delete any previously saved baseline!
Not exactly what you meant when you tried to ‘protect’ that baseline is it?
Anyway I just noticed while researching another issue, that this has now been fixed!
“On the Edit User page in Project Web Access (PWA), you select the Deny check box for Save Unprotected Baseline. When you try to save a existing project file to a new file, baseline 0 through 10 are removed.”
by Martin Laukkanen | Nov 3, 2009 | Project 2007, Project Pro 2007, Troubleshooting
I came across this problem while working with a customer and trying to use the very useful Budget Cost Resource feature, basically when using Budget Cost Resources and also restricting the ‘Save Protected Baseline’ permission (as many companies do) the Budget Cost values appear to be restricted with the baseline values! I.e. The values cannot be edited in the Task Usage view.
It definitely looks like a bug (ahem “code – defect”) to me, however it’s not one I have had a chance (or need) to log with MS.
Here are some reproduction notes I made while working on this one with a customer, needless to say we opted for the workaround as opposed to attempting to get a resolution.
These steps are tested with the October 2009 CU package for both Project Server and Project Professional (Build 12.0.6520.5000).
Issue:
Budget Cost entry not working when Save Protected Baseline permission restricted.
Scenario:
Our organisation process requires that in Project Server Baselines can only be saved by the PMO department and not by project managers as such we have removed the default permission to ‘Save Protected Baseline’ from the ‘Project Managers’ project server group. Additionally for our project status reporting we need to track Budget expenditure compared to baseline, unfortunately we have found that when the ‘save protected baseline’ permission is removed from the PM’s they are no longer able to enter any budget costs into a project unless they were the original creator of the project (ie not someone who the ‘Owner’ was changed to). As our PMO is responsible for creating all projects with set templates and then assigning the PM this issue results in PM’s never being able to update Budget Cost’s.
Environment:
MOSS & Project farm deployment:
– 1 x WFE with MOSS and Project Server 2007 (SERVICE PACK 2)
– 1 x Project Application Server (SP2)
– 1 x SQL 2008 database server (SP1)
All servers running Windows 2008 SP1, all clients running Project Professional 2007 SP2.
Reproduction Steps:
- As administrator in PWA open the ‘Project Managers’ group and remove the ‘Save Protected Baseline’ permission from all categories.
- As administrator create a new Project in project professional, create a local cost resource and from the resource properties, select “Budget” resource as the type.
- Assign the budget resource to the project summary task; first from Tools – options enable the option to show the project summary task, then assign the resource to that task in the normal way.
- From Task Usage view, add the ‘Budget Cost’ to the right hand side of the window, then enter some cost values.
- Save and Publish the project.
- From PWA – Project Centre, edit project properties and change the owner to a member of the Project Managers group (not an administrator).
- Open the project from Project Professional as the PM user then open the Task Usage view and add ‘Budget Cost’ (if required)
RESULT:
Unable to add further budget costs to any item, HOWEVER the PM is able to delete exiting costs!
EXPECTED RESULT:
PM is able to edit all items in the ‘Budget Cost’ line.
Workaround:
If the procedure is changed so that the PM creates the Project in step 2 above then the PM is always able to edit the Budget Costs, however this requires that internal business process be changed and does not account for future changes in the assigned PM needing to make updates.
(Hope this helps someone out there…)
PS. Ten points to anyone who recognizes where my issue subjective template comes from!
