Following on from the last few upgrade and migration posts, I thought I would pull together a simple reference sheet that takes you through the migration process from Project Server 2010 to Project Server 2013.
The sheet takes you through the key steps and commands required to migrate between Project Server 2010 and Project Server 2013.
The reference sheet can be downloaded from http://sdrv.ms/12qUa8M or by clicking on the picture above.
The process of upgrading from Project Server 2010 to Project Server 2013, or migrating between environments can be quite complex, requiring a number of steps to be completed in the correct order. In this post, I am going to document some of the common and uncommon errors that you may run into. I also intend to update this post as I uncover more.
Unmounted Project Service Database
Unlike SharePoint Content databases, Project Service databases need to be mounted before you can run a Test against them. If you do not mount them, you will see the following error.
Test-SPProjectDatabase : Could not find the ProjectDatabase instance (looking for database name: ‘ProjectWebApp’, service name: ‘demo2013’)
To rectify this issue, make sure you mount the Project Database prior using
Mount-SPProjectDatabase –Name <ProjectServiceDatabaseName> –WebApplication <WebApplicationURL>
ConvertTo-SPProjectDatabase returns a ‘There are no addresses available for this application’ error.
The ConvertTo-SPProjectDatabase is used during an upgrade to convert the four Project Server 2010 databases (Draft, Published, Archive and Reporting) into one consolidated Project Service database with the different schemas.
You will see the ‘There are no addresses available for this application’ error if you try and run this command and the Project Service App is not started. To rectify this, navigate to Central Administration and ensure the Project Service App is started and recycle the box, then try again.
Compilation Error – Microsoft.Office.Project.PWA.IDS does not contain a definition for ‘Licence_Copyright_Text’
You may run across this error message when navigating to a PWA instance that originated in Project Server 2010.
This error occurs when a 2010 PWA site has been mounted but the PWA site wasn’t upgraded using the following command:
Upgrade-SPSite -Identity <PWA URL> -VersionUpgrade
The PWA Settings option is missing from the Site Settings Menu
In Project Server 2013, the Server Settings menu item has been replaced by a PWA Settings option on the Site Settings menu. When performing an upgrade from Project Server 2010, this menu option is not automatically added when using the DB Attach method via PowerShell.
In the screenshot below you can see that the upgrade has been completed successfully, but the PWA Settings option is missing.
To fix this error, ensure you enter the following PowerShell command:
Enable-SPFeature –Identity pwasite –URL <URL of PWA site>
This will enable the pwasite feature which provides the PWA Setting menu link.
In this post I am going to take you through the process of migrating Project Server 2010 into Project Server 2013.
Usually there are two ways of doing a migration, either an in place upgrade, where if you were particularly brave, you would take your production system and then run the installer for the new binaries on it to upgrade. I say ‘Brave’ because frequently this method of upgrade would be fraught with danger, not giving you sufficient options for dry runs or rolling back.
The other option was a database attach method, where you would build up your target environment on the new version, then migrate the databases from the old version and ‘do the upgrade’. With Project Server 2013 and SharePoint 2013, Microsoft have finally stopped supporting the in place upgrade, which in my opinion was one of the best moves ever. So for this post, we will be walking through the DB attach migration method, where we will take the four Project Server databases and the associated SharePoint content database and migrating that into Project Server 2013.
Now for the purposes of this walkthrough, I am going to assume the following:
Oh and most importantly, this walkthrough is for instructional purposes only, I accept no responsibility if this doesn’t work and corrupts your data. Backups and snapshots are your friends but no replacement for testing this time and time again before doing it for real.
Backup the Project Server 2010 source environment
To start with we need to back up your PS 2010 environment, ready to migrate it over to the target 2013 environment.
In SQL Server, choose to backup the four Project Server databases and the content database that holds the PWA site collection and Project workspaces. To do this, right click on the database name, choose Tasks and then Backup.
Now in a real production migration scenario there are a number of other options you may need to consider, including outage notices, restricting users from accessing the system during the migration etc etc. I am not going to cover those here. This is just to give you a broad walk through of the process.
Restore the databases to the Project Server 2013 target environment
Restore the five databases backed up previously to the Project Server 2013 database server using the following method:
Right Click on the Database node and click on Restore Database…
Choose Device (1), select the location where the database backup files are located (2), add the backup device (3), click ok (4) and ok (5) again to commence the restore.
Repeat the above for each of the databases to be restored.
Once the files have been restored, ensure the databases have the correct permissions to allow the upgrade process to be performed, in my case this was granting my setup account access db_owner access.
On the target farm, open up a SharePoint Management Shell in Administrator mode (ensure you have logged onto an account with sufficient privileges to perform the upgrade).
Test and Mount the SharePoint content database
The first step in the migration process is to mount the SharePoint content which includes the PWA site content, the Project Detail Pages, and Project Workspaces that were created under the PWA site and any custom lists or libraries you may have added.
Before doing the actual migration, 2013 provides a couple of handy PowerShell commands to ‘test’ the databases against the target environment before performing the migration. In this case, the test command will analyse the SharePoint content database and highlight any items referenced in the database that may not be present in the target environment, like missing web parts, features etc.
To run the test command, enter the following in the Management Shell prompt:
Test-SPContentDatabase -Name <databasename> –WebApplication <web application name>
(of course replacing the items in the ’s with your values). In my example I entered the following:
Test-SPContentDatabase -Name PWA_WSS_Content_80 –WebApplication http://demo2013
and received the following results:
Here the test command has identified a number of issues in the content database including missing assemblies and in this case that the content database is a Classic mode (the default for 2010) and the target web application is in Claims mode (the new default in 2013) and provides some steps to rectify it.
Notice at the top you can also see whether the problem found would block the upgrade or is an error. The goal of this step is to test, identify and then rectify any conditions that may impact the upgrade process as you can see below, the test command can be pretty comprehensive in the info it provides.
Once you are happy that all the potential upgrade blockers have been addressed then the content database can be mounted for real with the following command:
Mount-SPContentDatabase <databasename> –WebApplication <web application name> -NoB2BSiteUpgrade
The final flag is quite important, it signifies that you are upgrading a SharePoint 2010 database to SharePoint 2013.
In my example I entered the following
Mount-SPContentDatabase PWA_WSS_Content_80 –WebApplication http://demo2013 –NoB2BSiteUpgrade
The mount process can take some time to complete depending on the amount of content in the database. Once its completed, all that is required is to make sure your account has access to the PWA site collection you’re upgrading using the following command:
Set–SPSite -Identity <SiteCollectionName> -SecondaryOwnerAlias <account>
You can check if this command was successful by viewing the Site Collection Administrators through Central Administration.
In this migration the test command identified that we were attaching the classic database to a claims based database, so it is also necessary to migrate the users in the content db to their claims equivalent. To do so, enter the following Powershell command:
(Get-SPWebApplication <web application url>).migrateUsers($true)
Test and Upgrade the PWA Site
Before we attach the Project databases, we need to perform the actual upgrade of the PWA site, this is not performed as part of the SharePoint content database mount above. Once again there is a handy test PowerShell command that can be leveraged:
Test-SPSite –Identity <url of the PWA Site to test>
In my case this would be:
Test-SPSite –Identity http://demo2013/pwa
which will return any errors or warning that may cause the upgrade to fail:
Again, the goal here is to identify any errors or conditions that may cause your upgrade to fail. In this case, I only have two warnings, so I am happy to continue and upgrade the site using the following command:
Upgrade-SPSite –Identity <url of the PWA Site> –VersionUpgrade
So in my case this would be
Upgrade-SPSite -Identity http://demo2013/pwa –VersionUpgrade
The important piece here is the –VersionUpgrade flag, this ensures the PWA site will be upgraded from Project Server 2010 to Project Server 2013 and is ready for the Project databases to be attached.
Convert the Project Server Databases
With Project Server 2013, there were a number of massive changes in the infrastructure and plumbing designed improve performance and maintainability. One of these key changes was the consolidation of the number of Project Server databases, from four down to one, making it much easier to maintain multiple PWA instances and stopping the proliferation of databases that you would get with Project Server 2010.
As part of the migration, it is necessary to perform a consolidation of the Project Server 2010 databases, again using a new PowerShell command:
ConvertTo-SPProjectDatabase -WebApplication <WebApplicationName> -dbserver <DatabaseServerName> -ArchiveDBName <ArchiveDBName> -DraftDBName <DraftDBName> -PublishedDBName <PublishedDBName> -ReportingDBName <ReportingDBName> -ProjectServiceDBName <ProjectServiceDBName>
On pressing enter, you will be asked if you want to convert the databases, choose yes.
Once completed, checking the SQL Server will show the consolidated database, in this example the ProjectServiceDB has been created.
Under the covers, the concept of separating the various draft, published, reporting and archive data is still present, but instead of four separate databases, there is now just one database with four schemas (dbo for reporting, draft, published and ver).
Mount, Test and Upgrade the Project Service Database
Next we need to mount and test the freshly created Project Service Database to ensure there are no issues which may impact the database being upgraded. To do so, enter the following command:
Mount-SPProjectDatabase –Name <ProjectServiceDBName> –WebApplication <webapplicationname>
in my case this will be:
Mount-SPProjectDatabase –Name ProjectServiceDB –WebApplication http://demo2013
Once mounted, the database can be tested as follows:
Test-SPProjectDatabase -Name <ProjectServiceDBName>
in my case this will be
Test-SPProjectDatabase –Name ProjectServiceDB
This will check various aspects of the newly consolidated database, including the schema version and things like the security roles.
Once you are happy there are no UpgradeBlocking errors, you can then proceed to upgrade the Project Service Database to the new 2013 schema using the following command:
Upgrade-SPProjectDatabase -Name <ProjectServiceDBName> -WebApplication <webapplication to mount against>
in my example this would be:
Upgrade-SPProjectDatabase -Name ProjectServiceDB -WebApplication http://demo2013
Again, this PowerShell command will modify the database, so you need to answer the confirmation prompt in the PowerShell window.
Mount, Test and Upgrade the ProjectWebInstance
Now that the PWA site collection has been upgraded, the Project Server databases consolidated and had their schemas updated (if required), the next step is to mount, test and upgrade the ProjectWebInstance. This is effectively the wiring up of PWA site collection to the Project data.
As with the other steps in the upgrade, there are three components, mounting the database so Project Server and SharePoint know about it, Testing it for potential issues and then performing the upgrade of the Project data itself.
To mount the ProjectServiceDB, enter the following PowerShell command:
Mount-SPProjectWebInstance –DatabaseName <ProjectServiceDBName> -SiteCollection <url of the PWA site>
so in my example this will be:
Mount-SPProjectWebInstance –DatabaseName ProjectServiceDB -SiteCollection http://demo2013/pwa
The mount process shouldn’t take very long at all to complete.
To test the ProjectWebInstance, use the following PowerShell command:
Test-SPProjectWebInstance –Identity <url of the PWA site>
In my example, this would be:
Test-SPProjectWebInstance –Identity http://demo2013/pwa
Like the other test commands, the output of this command will show if there are any potential issues that would stop the ProjectWebInstance being upgraded
As you can see in the screenshot above, the default output is not so useful, but it does show if there is likely to be an issue. If you want to see a little more detail and stop the unhelpful ‘…’ truncation, modify the command a little to output to a text file where you can see all the info:
Test-SPProjectWebInstance –Identity http://demo2013/pwa | Format-Table -Wrap -AutoSize | Out-File -FilePath c:\output.txt
This will result in:
Once you are happy with the results of the test command, we can perform the actual upgrade using the following:
Upgrade-SPProjectWebInstance -Identity <Url of the PWA site>
in my example this would be:
Upgrade-SPProjectWebInstance -Identity http://demo2013/pwa
You will be prompted if you want to perform the upgrade, answer yes. When the prompt comes back you are nearly there.
Finally, now that all of the various databases have been successfully upgraded and wired up, all that is required to do is to make sure the PWA features have been activated in the PWA site (things like . To do so, enter the following command:
Enable-SPFeature -Identity pwasite –URL <url of the PWA site>
in my example this would be:
Enable-SPFeature -Identity pwasite –URL http://demo2013/pwa
And that’s the primary content migration completed.
But we’re not there just yet….
Now that all of the various databases have been migrated, tested, upgraded and wired up, just like in Project Server 2010, there are a few post migration tasks you will need to perform.
In all the migrations I have done from 2010, the first task post migration is to ensure the administrator account of the PWA site we have just migrated is correct. To check this, in Central Administration go to the Manage Service Apps and choose your Project Server Service App. In my case I saw something like the following showing that the Provisioning had yet to be completed successfully, even though I had completed all the steps above.
Open the context menu and choose edit, the properties for the PWA instance will be shown.
Here you can see the administrator account is incorrect and still showing the admin account of the source 2010 environment. The fix is really simple, enter your target administrator account details and press Edit. After a little churning and ‘Waiting for Resources’ you should see the following and can now get into your PWA instance.
The last thing you will need to do is to perform a bulk update of the Project Sites to reassociate with the target server name and to set up the various content types.
To access the Bulk Update Connected Project Sites feature (as it has been renamed in 2013), choose to Manage the Project Web App we just migrated in the Manage Project Web Apps screen above, this will bring up the instance settings for configuration.
Click on Bulk Update Connected SharePoint Sites and select the site paths and most importantly the ‘Update Content Types’ and ‘Synchronize site Permissions’ options and click on Update.
And that’s it…
All being well you will now have a fully working migrated Project Server 2013 instance, with all the data you had in 2010 successfully migrated over into 2013.
Of course, in the real world it won’t be this plain sailing, there will be missing features and web parts that you will either have to deactivate or remove, there may be multiple content db’s for your SharePoint content or you may run into errors because you missed or skipped a step. My advice, as always is to test your migration, test it several times and then test it again.
In the next few posts, I will look at some other common migration scenarios, including porting your data between a Production and Dev/Test 2013 environment, migrating data between environments of different patch levels and taking a look at some common errors you may run into during all of these, and how you can fix them.
I thought I would post this for those of you that are upgrading to Windows 8 and wanted to create a simple way of accessing Project Server. In this particular case I am going to show how to pin Project Online, but the same is possible with your on premise Project Server 2013 and 2010 instances.
To start, navigate to your Project Server instance in either Internet Explorer 10 on the desktop.
Click on the Cog icon on Internet Explorer to open up the settings menu.
Click on ‘Add site to Start Screen’, a dialog will be shown to confirm creating the shortcut.
And that’s it for the desktop version. The shortcut is created.
The process is slightly different for the Metro / Modern / Windows Store UI version of IE.
1. Navigate to the PWA site in IE
In the bottom right hand corner, click on the Pin icon.
Choose Pin to Start, a dialog will be displayed giving you the option to Pin to Start.
Click on Pin to Start and there you have it.
As you can see the output from pinning is slightly different depending on the source of pinning.
Personally I prefer the Metro / Modern / Windows UI pinning, it looks much more in place in my start screen.
Happy Pinning 
Project Server 2013 introduced a number of changes to where key settings are located throughout the product. Andrew Lavinsky wrote about it earlier this week and stole some of my thunder for this little tool I was putting together.. introducing the Project Server 2010 / 2013 Preview Setting Comparison spread sheet.
The tool maps the various server settings for Project Server 2010, Project Server 2013 On Premise and Project Online all in a handy filtered Excel spread sheet.
To use the spread sheet, pick the column for the relevant Project Server version and choose to filter.
In this example, choosing Database Administration for the PS 2010 Setting Area will show that Database Administration is no longer in Server Settings, but has moved into Central Administration on PS2013 On Premise.
The spread sheet is based on the currently available Project Server 2013 On Premise and Online Preview versions and may change between now and RTM. It’s also a work in progress as there are some areas I have not quite tracked down yet, but stay tuned.
The comparison spread sheet can be downloaded from here.
A question came up in the Project forums recently around how it was possible to filter the available projects for a portfolio analysis, so I thought I would post a little tip here, which from a majority of the Project Server 2010 implementations I have seen is usually forgotten or managed by business process.
When you create a portfolio analysis, Project Server allows you to choose which projects you want to use as part of the analysis, out of the box, this shows you all the projects currently within the PWA instance, irrespective of their status. This is fine, but can be confusing for end users who need to go in and manually pick out the projects they wish to include and can be prone to errors (you don’t want to include a project already selected in a project selection analysis again do you?).
Luckily the project selection component supports views. It’s tucked away in the top right hand corner but it’s there. Through the views we can choose to restrict the default view of the project selection dialog to show just those projects that are at a certain stage in the project lifecycle, for instance, ready for selection.
To configure the view, navigate to Server Settings > Manage Views and look for the Portfolio Analysis Project Selection views. By default Project Server creates a single Summary View. I would suggest leaving that view intact and create a new view that we will place a filter on, in this example I will call it the Projects for Select view. Within the view, choose the project custom fields you wish to have visible.
In order to only show those projects at a certain stage, we need to add a filter to the view, to do this click on Filter and configure it as follows:
In this example, the view will now filter for those projects that are in the workflow stage of 3. Select Checkpoint
Finally, assign the view security category as you would with other views and click on Save.
The new Portfolio Analysis Project Select view is now available to be used, ensuring only those projects that should be considered in the portfolio analysis are available.
At SharePoint Saturday Toronto, I presented one of my favourite sessions on SharePoint Governance and Lifecycle Management using Project Server 2010, based on Christophe Fiessinger’s and Scott Jamison’s session from TechEd NA 2011. I’ve delivered this session three or four times now, showing how organisations can benefit from using Project Server to collect business requests and guiding them through a process to successfully collect information, objectively determine which project to implement and then assist in the implementation.
Each time I have delivered the session, I have been asked if there were ways to collect the initial business requests outside of Project Server, in a SharePoint list for instance, reducing the need to licence and more importantly train all users within an organisation that may wish to lodge a business request. So, for SharePoint Saturday Toronto I decided to implement an interface that allows the business requests to be created initially in a SharePoint list and then via a workflow pumped into Project Server for the Project Server governance process to be applied.
This post shows you how you can implement it too. For this example, I will be using Nintex for the workflow component (disclosure, I work for Nintex), but you could also use a SharePoint Designer built workflow with the Christian Glessner’s iLSP SharePoint Designer Add-ons and a little elbow grease.
At a high level the solution has three components:
The list
Configure a SharePoint list to capture the information you want to capture. In this example, I have only captured two fields, as the rest will be captured within Project Server.
Both fields are set to be mandatory and the title field has been set to enforce unique values.
The EPT
The Governance and Lifecycle Management white paper and databases guide you through the process of configuring a demand management workflow and EPT. For the list workflow to create a project automatically, it is essential to make sure this EPT is set as the ‘default’ and that a Project schedule template has been uploaded and associated with the EPT.
Before building the workflow, we need to know some information about the project schedule template, this will be used by the workflow to create the project. Each project template is stored within the DRAFT Project Server database and can be extracted with the following query:
SELECT PROJ_NAME, PROJ_UID FROM MSP_PROJECTS WHERE PROJ_TYPE = 1
Write down the PROJ_UID of the relevant record for the Project Template you associated with the default EPT.
The Workflow
The key component of the process is the workflow that will take the list item and create a project in Project Server. As I mentioned above, in this example I will use Nintex Workflow & Nintex Workflow for Project Server as it has Project Server specific actions, but you can achieve a similar outcome in SPD with a little more effort.
The workflow itself consists of only three actions, the first action ‘Call Web Service’ is used to call Project Server’s PSI and specifically the Project web service and the CreateProjectFromTemplate web method. This method creates a project within Project Server based on a specific project schedule template.
The action should be configured as below, ensuring you change the URL of the web service, credentials and Template GUID to match your environment.
The projectName field above is using the Title variable. A great thing about Nintex is that you have access to the list context information by clicking on the lookup icon as below:
The final part of the configuration is to capture the UID of the project that is created. When CreateProjectFromTemplate is called, if the method is successful it will return the UID of the created project in an XML envelope.
The Call Web Service action can listen for the response and parse it. To do so, click on Specify Elements and then Select Element.
A XML browser dialog will be displayed allowing you to select which item in the response to read, in this case we are interested in the CreateProjectFromTemplateResult, so select it and click on Apply.
Choose to save the returned value into a variable called ProjectUID, this will be used later.
The second action is also a Call Web Service action, this time used to Publish the Project in Project Server, up until now our project has resided in the Draft database, performing this publish will make sure it is published and therefore visible in PWA.
Like the previous action, configure the web service to call the Project PSI server with the relevant URL and credentials.
For this action, choose the QueuePublish method. This method has different parameter requirements:
Once these two actions are run, a project will be created in Project Server using the default EPT and schedule template, all that is needed to do is to copy the other fields from the list into the project custom field using the last action ‘Update Project Properties’ from Nintex Workflow for Project Server that provides a simple wrapper for updating project custom fields. If you decide to use SPD, you would need to perform a raw PSI call to update the property making sure you have created a valid XML message (Fiddler will be your friend here, but a word of warning, it is not simple).
Configure the action as shown below, ensuring you select Title from the lookup field for the Project Name and then choosing to update the WPROJ_DESCRIPTION field with a list lookup against our SharePoint list, the item we are starting the workflow against (our project idea) and relevant field (in this case the Project Description field).
If there were other fields you wished to push into Project Server, they can be chosen in the Project Property drop down.
Finally, configure the action to ‘Publish after update’ and to ‘Wait for job completion’.
The completed workflow should look like this:
All that is needed to complete the workflow is to modify the workflow settings to allow it to be manually started, and to add it to the list item context menu as follows:
Then publish the workflow and you’re ready to start pushing your project ideas from a SharePoint list into Project Server 
Of course, what I have shown you above is the tip of the iceberg, with a little more work you could:
Last week Microsoft released the latest preview of Windows 8, the release preview which you can grab from preview.windows.com. Being a fan of the bleeding edge, I downloaded and installed it onto my slate and have been loving it. However, a number of my colleagues reported that they were having issues using Project Server 2010 with the inbuilt desktop version of IE 10, running into ‘This Project Server 2010 feature requires at least Microsoft Internet Explorer 7.0’ error messages in parts of PWA including Server Settings and Manage Timesheets.
Luckily the fix for this is pretty simple and requires you to set the browser mode of IE 10 to run in compatibility mode. To do so, either click on Tools > F12 developer tools in the toolbar, or click on the settings icon and choose F12 developer tools
This will bring up the developer tools where you can set the compatibility mode of the browser. By default this is set to IE10 mode which is causing the problem.
To change, click on the Browser Mode and change it to be IE10 Compatibility View and instantly you should see the error message disappear and the page render.
Happy Windows 8’ing!!
In this second post looking at some of the new capabilities of SQL Server 2012 and how they can be leveraged in your Project Server farm, we are going to look at PowerView.
PowerView was originally announced as Project Crescent and has wowed pretty much anyone that has seen it. In essence, PowerView allows you to build visualisations of your data using a simple drag and drop interface that are ‘Presentation Ready’ meaning there is no nasty wiring up of data, simply drag your data onto the surface and being analyzing it.
PowerView can leverage data from two types of source, a Tabular model in SQL Server 2012, or a PowerPivot workbook stored in Excel. Of the two, the latter is by far the easiest to get up and running.
To start with I am going to assume you have set up your farm to leverage PowerPivot, this requires adding a special ‘PowerPivot’ analysis services instance to your farm and then configuring the farm to use it. The whole set up experience has gotten better in SQL Server 2012, but it’s still fiddly requiring a wizard to be run and a number of content types to be manually added to the relevant reporting library. There is a great video taking you through the whole process here , including how to set up the server side and the Excel client PowerPivot add-on.
In my case, I was keen to try out PowerView against Timesheet data mainly because I worked at an organization that used timesheets extensively and was familiar with the data model and some particular reporting use cases I wanted to try.
To start with we need to import the Project Server data into PowerPivot. To do this, open up the PowerPivot for Excel add-on and choose to import from a SQL Server Database.
A table import wizard will be shown, configure it to point at your Project Server Reporting database and click next twice, you will then be presented with a list of all the tables and views available in the database to use for reporting. As I am interested in timesheet info, I am going to pull in some timesheet only tables and a couple of the generic _userview tables.
PowerPivot will then proceed to import the tables and this is where the really clever stuff will start, in most cases PowerPivot will be able to automatically infer the relationship between the tables, but as I have chosen to pull in the EPMProject_UserView and EPMResource_UserView tables I need to help it with the relationships.
Creating a relationship is pretty easy, simply choose ‘Create Relationship’ from the design ribbon and select the relevant tables and joins.
The final step before building the PowerView was to save the PowerPivot back into the gallery in SharePoint.
Once the PowerPivot Excel spreadsheet is in SharePoint we can start to build the PowerView by clicking on the PowerView icon which will open the designer.
The designer will show a design surface on the left and a list of entities on the right hand side. To start building the PowerView simply select the relevant information on the entities and drag it onto the design surface.
PowerView will automatically highlight the entities that are related from the relationships either detected automatically or manually set.
Once the entities have been dragged onto the design surface, PowerView allows the user to select the best way to visualize the data, allowing the user to change the layout and visualization method (table, graph or tiles). The PowerView can also be further refined through the use of slicers and filters.
So in about 15 minutes I put the above timesheet analysis PowerView together, showing all resources in the organisation, and a breakdown of Planned & Billable work across the month, week and projects all with a few drag and drops.
The real power of course comes from interacting with the PowerView, so clicking on a resource name will change the data, clicking on the projects of hours breakdown will automatically cause other parts of the PowerView to filter as can be seen below.
There are a number of other parts to PowerView that I haven’t explored in this post, specifically things like Play Axis that allows you to see data sets changing over time, which would be interesting to wire up to some of Project Server timephased data, the ability to embed the visualisation into a PowerPoint slide, card and tile visualiations to name but a few. Luckily Microsoft have released an excellent tutorial over at TechNet that takes you through the process of building PowerView from start to finish. If you have SQL Server 2012 installed and are using Project Server 2010, I challenge you to get cracking to wire up some Project data and amaze your executives and PMO !!
Project Server has a fantastic reporting story, with a dedicated reporting database containing pretty much every piece of data you put in, and a myriad of ways to retrieve, tabulate and visualize that data for the end user. With a little customization or configuration it is possible to build reports that will show the status of the project portfolio, risk and issues and just about anything you want to see. With such powerful reporting it can quickly become difficult for a Project or Portfolio manager to identify the projects or information they are interested in seeing.
Enter Reporting Services Data Alerts, a new capability in SQL Server 2012 that allow users to create specific alerts when a data condition in a report occurs. For example, an organization could have a specific report that highlights all risks across the project portfolio, however the portfolio manager may only be interested when one of their projects is on the report with risks of high or critical. With a SQL Server Reporting Services Data Alert, the portfolio manager could create a data alert on the report that will would automatically send a copy of the report to them when the conditions are met.
Setting up a data alert is incredibly simple. To start with, run the report that you wish to set up the data alert on. In this example I have a very simple report that shows the number of extreme risks across all projects in the portfolio.
On the actions menu, select new data alert (If you are trying this yourself and the New Data Alert option is disabled, then you may need to set modify the report dataset to use a shared data source with stored credentials).
A dialog will pop up showing the different components of the report and allowing the user to define the different conditions that will cause the alert to fire.
Finally, the user can configure how often the data alert will poll, ranging from minutes up to months, and where to send the alert.
The output from the alert is a nicely formatted email containing the report, details of the rules used to generate the alert and links back to the underlying report.
Reporting Services also provides a mechanism for a user to view all the data alerts they have
configured as well as to modify, delete and run data alerts outside of the schedule.
All in all this is a pretty handy capability to provide your users should you be running SQL Server 2012.
