Also as mentioned in the session, here is the link to the excellent White Paper outlining the Work Management capabilities and Synchronisation with Exchange.

http://www.microsoft.com/en-us/download/details.aspx?id=38799

A common requirement from customers is to be able to hide  / disable buttons within their Project Server instance and of course, this requirement will not go away with Project Online. I wrote a a while back about how you could disable or hide ribbon buttons using a simple sandboxed solution. Well the good news is that this approach is still valid for Project Online. Given all the focus on the app model and the flexibility and restrictions it introduces, it is sometimes forgotten that you can still deploy sandboxed solutions to your Project Online environment.

In choosing to utilise Sandboxed Solutions in Project Online, you should choose to remember that whilst the solutions are ‘sandboxed’, if you do end up having a rogue solution that causes your sandbox to suspend, then ALL your solutions in the sandbox will suspend until the resources reset. In the case of ribbon customisations, I think this is a pretty light and risk free way of deploying the customisation.

For this post I am going to take the .WSP file created in the above blog post, using the source posted here.

To deploy the solution, navigate to Site Settings and choose Solutions

Choose to upload the HideRibbonButton.wsp from the above solution

Once the file has uploaded, choose to Activate the solution.

Once activated, navigate to Site Settings > Manage Site Features, note the two additional features that have now appeared like in the original post.

In this case, activating the relevant features will either hide the EPT Change Button or Disable the EPT Change Button within your Project Online tenant.

There you have it, a simple sandboxed solution in this case from Project Server 2010, that I have simply deployed directly into Project Online with no modifications, allowing you to hide buttons. Of course, it’s not just Online, sandboxed solutions are still present in Project Server 2013, so still a valid option too

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 abstract for the session is:

If you have ever tried to track work in SharePoint, lists or even on pieces of paper, you are going to love the new Work Management capabilities of SharePoint 2013. With SharePoint 2013, your organisation has access to a task management solution that can start simply and scale up to the enterprise level at the click of a button. Come along to this session to get an understanding of these exciting new capabilities and how you can leverage them today.

Once again, the quality of this conference and knowledge of the speakers is second to none. This time the conference has an overall theme of collaboration and how to make your organisation work better, a tailor made theme for Project, Project Server and Work Management.

The conference is on the 11th – 12th June at the Pullman in Melbourne. You can find out more and register at http://www.sharethepoint.com/engage/AU2013/Melbourne/Pages/Home.aspx

In the last couple of weeks a few people have told me about issues they encountered running Project Server 2010 workflows on a farm where the web front-end service has been deactivated. Deactivating the service can make sense if you are configuring the farm for improved performance by removing the need to listen to and render pages, or when trying to reduce the attack surface (although this is a lesser concern).

Anyway, to cut a long story short, it seems that when you turn the services off, you need to tell Project Server that the service has been turned off and to update it’s workflow configuration settings.  Thanks to Sameh, one of the excellent support guys at Nintex who found the procedure hidden away in an MSDN article from August 2010  at

http://msdn.microsoft.com/en-us/library/office/ff459292(v=office.14).aspx

I haven’t had a chance to test if this on a Project Server 2013 farm using the SharePoint 2010 workflow engine, but I would imagine the same will apply.

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 we will walkthrough migrating data from our production Project Server 2013 environment which will be the source, over to a development / test environment which will be the target using the simple and fool-proof database attach method.

As with all these posts there are a few assumptions:

• All of your environments are at the same patch level for SharePoint and Project Server
• The target environment has been ‘cleaned’, removing any existing PWA and SharePoint content and associated databases prior to restoration.
• You are on the same domain

So let’s get started…

Backup your source databases

On the source environment, backup the SharePoint content database hosting PWA and site collections and the Project Service Database (as this is most likely from a production environment you could always just take a copy of your production backups that you have correct? ;) ).

Restore to your target environment

In your target environment, restore the two databases into SQL, the Project Service Database and the Content DB that contains the PWA site and Project Workspaces you wish to migrate.

Once restored, check that each of the databases has the correct permissions assigned (db_owner). In my example here, I am using a single account demo box (demo\administrator), but you will need to use the correct account for your environment.

Test and Mount the SharePoint Content Database

Before mounting the SharePoint Content database, it is a wise move to Test the Content database against the web app you intend to restore it to. In performing the test, SharePoint will check the contents of the Content DB against the target web application to see if all the features, customisations etc. are present. If they are not, this step will highlight what is missing so you can rectify the problems.

To Test the SharePoint Content DB, enter the following command in a SharePoint Management Shell running as an administrator.

Test-SPContentDatabase –Name <SP Content Database Name> –WebApplication <Web Application URL>

In this case you can see there is a missing setup file and web part that I should correct before proceeding, but as the test output shows, they are not Upgrade blocking problems, so I can continue if I wish.

Once the test is complete, the next step is to mount the database using this command:

Mount-SPContentDB –Name <SP Content Database Name>  –WebApplication <Web Application URL>

Again, just like the upgrade you need to make sure you have access to the PWA site collection, to do so, either enter the following command:

Set-SPSite –Identity <URL of PWA Site Collection> –SecondaryOwnerAlias <Domain Account>

Mount and Test Project Service Database

Next we need to Mount then Test the Project Service Database. This step is slightly different than with the SharePoint Content databases in that you need to mount the database before testing it, however SharePoint will let you test a content database whilst the database is not mounted.

Mount-SPProjectDatabase –Name <Name of Project Service DB>  –WebApplication <Web Application URL>

Once mounted, enter the following command to test the Project Service Database:

Test-SPProjectDatabase –Name <Name of Project Service DB>

Here you can see we have a clean bill of health and are fine to proceed to the next stage and wire up the Project Web Instance.

Mount and Test Project Web Instance

Finally, now that the Content database and Project Service database have been mounted into SharePoint, all that is needed is to wire them up together by using the Mount-SPProjectWebInstance command:

Mount-SPProjectWebInstance –DatabaseName <Name of Project Service DB> –SiteCollection <URL of PWA Site>

Once mounted, run the test command to check that all is wired up correctly:

Test-SPProjectWebInstance  <URL of PWA site>

From my testing, this will return that one of the tests, the check for the Queue status will return a FailedWarning initially as the queue is starting up, then a few minutes later it will show that the status is Passed.

There should be no need to enable any features as we are moving from one 2013 environment to another.

Post Migration Tasks

If you development / test environment is running under a different administrator account, then make sure you navigate to Central Administration > Manage Service Apps > Project Server Service App and choose to Edit your Project Server Instance, modifying the Administrator account to be the correct account for your environment.

Next, choose to Manage the PWA instance and use the Bulk Update Connected Project Sites to ensure the workspaces are relinked and reassociated with the correct development / test instance and not still linked to Production. Finally if you have Reports or OLAP cubes, you will need to reconfigure those to work with the restored databases.

And that’s it, all that is outstanding is to test your migration, checking you have access to all the capabilities and data before releasing the environment back to your dev’s or testers.

Oh and one last thing, I would highly recommend once you have migrated your environments that you do something to differentiate the environment from production, either by changing the look and feel / colour scheme, or by editing the main PWA page to but a ‘Welcome to the DEV site’.  You only have to do something in the wrong environment once to realise what a good idea this is

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:

• You have already built a SharePoint 2013 and Project Server 2013 On Premises solution and performed the base configuration (accounts, binaries, install accounts and run the config wizard)
• You have created a Project Server 2013 Service App in Central Administration
• You have started the Project Service on the various servers.
• We are only migrating the Project Server data and associated content (PWA site and project workspaces), we will not be migrating any additional SharePoint content you have in your source farm
• You are not changing domains as you migrate the data.

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.

But there was one gem that the team didn’t share, which a little poking around with a hex editor and procmon has highlighted. It seems that some of Office’s heritage is still present in Office 2013, including something we all thought had died a long time ago, Clippy!

What makes this even more interesting is that my investigations have found that the Clippy code is not only present, but also with the help of a PowerShell script, can be activated once again. Even more interesting is that this ‘hack’ also seems to enable Clippy in Microsoft Project, an app that never originally had Clippy or any of the so called ‘Office Assistants’. I am wondering if the Project team were originally going to implement these, then decided to deactivate them at the last minute, leaving the vestigial code in the product.

Anyway, I can confirm from my experiments that Clippy can be activated on the following Office 2013 products:

• Project 2013
• Word 2013
• Excel 2013
• PowerPoint 2013
• Publisher 2013
• InfoPath 2013
• Access 2013

As you would expect, the hack doesn’t seem to do anything on the newer Office products like SharePoint Designer, Lync & OneNote, which makes sense as the Office Assistants were never in those products. I didn’t have any luck getting it to show up in Visio 2013 either.

The PowerShell script is somewhat involved, so I have taken the liberty of uploading it to my site, and providing a bit.ly link to it, for simplicity sake, entering the following command from PowerShell will contact the site, download the script and activate the hack, all that is required then is to open up the relevant Office 2013 app and wait for an appearance.

iex (New-Object Net.WebClient).DownloadString("http://bit.ly/e0Mw9w")

Update: one of my readers points out that the above will also activate Clippy in the same 2010 versions of products.

Update 2 That’s right, this is an April Fools, well the second part at least :) Thanks to leeholmes.com for providing the powershell I so shamelessly pointed to.

Now I have been advocating using Skip to Stage in workflows forever, if your building a long running workflow, which demand management workflows always tend to be, you would be foolish not to think that the workflow will be perfect from day one and not need updating and restarting at some point. Obviously the more complex your process (and thus the number of tasks, approvals etc. that need to be reapproved / declined) the more painful it becomes to restart a workflow and then progress through to the point you were at before the restart. This is where skip to stage comes in, when the workflow is restarted using Project Server’s inbuilt ‘Change or Restart Workflow’ function and a stage to skip to is selected, the workflow is passed some special settings letting it know that it needs to restart and skip through to the stage the user chose. However, Skip to Stage only works if you build your workflow to take it into account, it doesn’t ‘just work’.

I should note, this post comes as the result of a question in the Project forums on MSDN / Technet. Specifically, the original poster was having trouble understanding what was happening when using the Skip to Stage functionality of a SPD Project Server 2013 workflow.

So how do you build a workflow to take into account Skip to Stage logic?

Assume the following SPD workflow, it consists of three simple stages, each sequentially transitioning to one another. For each stage, there is a simple Log to workflow history list action, so we can see what the workflow is doing, and a Wait for the Project to be Submitted action (this stop the workflow executing and zooming through to the end).

In normal operation, when this workflow runs it will enter stage one, log ‘Stage 1’ to the workflow history list, and then pause waiting for the project to be submitted via PWA. Once submitted, it will move into the next stage, and so on, until it gets to the last stage, when on the final submit the workflow will complete.

If you try and restart this workflow via the Change / Restart Workflow feature, and choose to Skip the workflow on to Stage 3, you would logically expect the workflow to just kick off in Stage 3. However this is not the case, even though the new Workflow Manager workflows allow you to build workflows that jump back and forth, they are still sequential behind the scenes, meaning your workflow needs to start on Stage 1 and move through the various stages to get to Stage 3, including any logic that is defined.

In order to skip the logic, the secret is to use a new action in SharePoint Designer called ‘Include Stage’. When you add the ‘Include Stage’ action, you will see a step entitled ‘If Project Web App starts the workflow normally or restarts the workflow and includes this stage’ added to the designer. This step is the key for ensuring when a workflow is restarted using Change / Restart workflow.

So what you will see:

• If a workflow is stated normally, i.e. when creating a project, then the actions within will be run (in the example, the Wait for Event: When a project is submitted action)
• If the workflow is restarted using Change / Restart Workflow and the stage being evaluated is the one being skipped to, or follows it, then the actions within the step will be run.
• If the workflow is restarted using Change / Restart Workflow and the stage being evaluated is prior to the stage being skipped to, then the actions within the step will NOT be run.

It is important to remember that any other actions outside of the ‘Include Stage’ step will continue to be run, irrespective of whether the workflow was started normally or restarted.

So there you have it, if you’re going to be building demand management workflows using SPD, then best practice has to be to wrap all your business logic / approvals in one of these ‘Include Stage’ steps.

One final bit of info, the ‘Include Stage’ action also is available for use in the Transition section of the stages, meaning you can change the logic and flow of your workflows depending if the workflow was restarted or not. I am not going to dig into this too much now, but it is there.

Many thanks to John from the Project Product Team for his assistance with the above.

For a while I have been thinking about how powerful one of these carousels would be within your own organisation, perhaps providing a direct link to view the queue, a link to that report everyone uses, a central lessons learned register, a PMO site, or even your favourite EPM / PPM blog. Whilst recently catching up on the Project blog, I noticed this post talking about how how the carousels were based on SharePoint’s promoted links app, so thought I would see how easily I could create my own customised carousel.

Creating the Promoted Link app.

In your PWA site (In this post, I have used Project Online, but you could also do this in your on premises Project Server 2013) , click on the Settings (Cog) icon and choose ‘Add an App’

In the ‘Your Apps’ screen, you can either scroll through the available apps, or do as I did and choose to search for ‘Promoted’.

Click on the Promoted Links app, you will then be prompted to give it a name. In this case I am going to call it ‘EPMSource Links’  and click on Create.

The app will then be added and ready for you to start customising.

Adding content to your app

Click on the EPMSource Links app to open it, you will see an empty screen advising that you can add new links from the ‘All Promoted Links’ view.

Click on the ‘All Promoted Links’ view to open up the correct view, then click on the ‘Add Item ‘ to add your first piece of content.

A new item screen will be displayed where links themselves can be configured.

My Queued Jobs Link

To start with I am going to create a link through to the My Queued Jobs page (MyJobs.apsx). As the carousel is visual, I also need to create a 150 x 150 image to show up, in this case I have artistically created a large white Q on a green square and uploaded it to the Site Collection Images.

Then fill in the following items:

• Title, this is what will show up on the individual item in the carousel
• Background Image, this is what will show up as the contents of the tile
• Description, this is info that will be showed when the mouse hovers on the tile
• Link Location, this is the location the browser will go to when the tile is clicked
• Launch behaviour, this determines if the link opens in the browser, a new browser or a dialog box
• Order, used to order the tiles when there are more than one.

When your happy, click Save.

Adding a link to external content

Following the above steps, add a second item with the following settings:

This time the tile will be the second one and link out to this blog.

If you’ve done everything right, you should see something like this

Adding the Promoted links to the PWA page.

The final step to use our links is to add it to the front page, thankfully that’s pretty easy.

On the PWA home page, click on the Settings (Cog) and choose Edit Page.

Click on the ‘Add a Web Part’ link for the zone where you want to add the links. The Add Web Part UI will be displayed, allowing you to choose a web part, or in our case, an ‘App part’ to add to the page.

Make sure you select the Apps category, then the EPMSource Links, then click on Add.

The app part will then be added to the PWA homepage, click on Stop Editing and you should see something like this.

As you can see, it’s pretty easy to customise and add new links to Project related content via the Promoted Links app. Of course you are not just limited to doing this in PWA, the Promoted Links app is also available in SharePoint, so you can add a similar customisations to your Project workspaces and SharePoint sites.

I am pleased to announce that we have shipped Nintex Workflow for Project Server 2013 (NW4PS), an update to the popular workflow product for Project Server 2013.

NW4PS 2013 provides all the capabilities of the 2010 version for use within Project Server 2013, including:

• Demand Management workflows- implement workflows that support your full project lifecycle, from creation, through selection, planning, execution and to closure, leveraging an array of actions, including Query Project Server (PSI data), Project Publish and Change EPT;
• Event Driven workflows – associated workflows to over 115 different Project Server event handlers;
• Collaboration workflows – build workflows to support project collaboration scenarios that can talk back directly into Project Server.

NW4PS 2013 provides a seamless upgrade experience from Nintex Workflow for Project Server 2010, allowing organisations to leverage the new Project Server 2013 capabilities and features without having to worry about rebuilding & refactoring workflows.

As you would expect, Nintex Workflow for Project Server 2013 is fully Project Server 2013 aware, supporting items such as the new security modes, claims and 2010 look and feel in project workspaces.

You can read more on Nintex Workflow for Project Server 2013 over at nintex.com/project

The abstract for the session is:

If you have ever tried to track work in SharePoint, lists or even on pieces of paper, you are going to love the new Work Management capabilities of SharePoint 2013. With SharePoint 2013, your organisation has access to a task management solution that can start simply and scale up to the enterprise level at the click of a button. Come along to this session to get an understanding of these exciting new capabilities and how you can leverage them today.

This is the 4th time the conference has been run. I was lucky enough to speak at it back in 2010 and the quality of speakers, sessions and organisation is unparalleled.

The conference is on the 10th – 11th April at the Hilton in Sydney. You can find out more and register at http://www.sharethepoint.com/engage/AU2013/Sydney/Pages/Home.aspx.

This is particularly important for organisations that may be upgrading from Project Server 2010 and have invested in demand management workflows and do not want to redevelop or significantly refactor their workflows for Project Server 2013 and the new Workflow Manager.

However, in setting up my Project Server 2013 instance I ran into an issue where I couldn’t register the workflow proxy account details for my PWA instance in Central Administration with what seemed like the correct credentials, resulting in the following error:

The specified Workflow Proxy User Account does not exist

Why is this the case? Well, under the covers, SharePoint 2013 (and Project Server 2013) the default authentication mode has changed from classic to claims. In fact it’s no longer possible to create a claims web app via the GUI any more, only PowerShell. If you have a claims based web application hosting PWA, you need to enter the workflow proxy in claims format. So instead of a domain\username format credential, enter the account in the correct claims format i.e. i:0#.w|domain\username.

One other thing I wanted to share when looking at 2010 legacy workflows in Project Server 2013, they will log to the ULS as Legacy Workflow Infrastructure, instead of the usual Workflow Infrastructure, so make sure you are looking in the right place

The guides themselves are pretty comprehensive and cover not only the feature areas of Project, but also Project Online and the new Reporting and Task path capabilities.

You can grab the the Office 2013 Quick Starts at Download other Office 2013 Quick Start Guides and the Project 2013 specifically at http://office.microsoft.com/en-us/support/project-2013-quick-start-guide-HA103673696.aspx?CTT=5&origin=HA103673669