This is the final installment of a four part series on common workflow administration tasks associated with Project Server 2010. 

Installation and setup of Project Server 2010 is covered in the overall setup guide, and these articles will make the assumption that the user has already read and completed the setup of Project Server 2010.

These articles also will not cover the topic of creating Project Server 2010 workflows. Please refer to our SDK articles to find out more information on how to create our workflows.

How to Restart/Change Workflows

Restarting a workflow may become necessary for any number of reasons. By restarting a workflow, you will cause the workflow engine to execute the workflow from the very beginning. No project related data will be lost or reset. This action simply tells the workflow to “Go to Stage 1” and execute everything again. Similarly, changing a project to another Enterprise Project Type that has a workflow, will cause the project to execute the new workflow from the very beginning.

How to restart/skip to stage within a workflow

1. Within Project Web Access go to Server Settings
   • 
2. Under “Workflow and Project Detail Pages” Click on “Change or Restart Workflows”
3. Select the Enterprise Project Type that the project in question belongs to.
   • Note: A project with a damaged workflow instance might be under the “None” category.
4. 4) Under Choose Projects, select the projects you wish to restart/Skip to stage and press the “>” button.
   • 
5. Under: “Choose new Enterprise Project Type or restart current workflow:”
   • To restart the workflow select “Restart current workflow for the selected projects”
   • To change the Enterprise Project Type the selected projects are currently associated with, select “Associate projects with a new Enterprise Project Type:”
6. Under: “Choose Workflow Stage to Skip to” if you are restarting a workflow or moving to an Enterprise Project Type which has a workflow associated with it, the below options will be enabled
   • “Skip until the current workflow stage” will cause the workflow to execute from the beginning and attempt to continue to execute until it reaches the last stage that it was at before it was restarted
   • “Skip to a particular workflow stage:” will allow you to select a stage you would like the workflow to attempt to execute to.
     • The workflow will begin executing from the very beginning and if it finds the stage which you selected it will stop.
     • The drop down does not filter the stages to just the stages within the target Enterprise Project Type. As such, if you select a stage which does not exist within the workflow, the workflow will simply continue to execute until it reaches a natural stop point.

Skip to Stage Support

The skip to stage functionality is something that will only work if the workflow is correctly designed to allow for stage skipping. All project server workflows will always stop whenever natural stop points are reached. These include

1. Stages where required fields are not filled out
2. Approval points
3. “Wait” activities (such as “Wait for Submit” or “Wait for Commit” activities)
4. And others.

As such, to get the skip to stage functionality working fully, you will need to incorporate “if” branches that will bypass “stop points” like approval points and portfolio selection points when developing the workflows.

This is the third of a four part series on common workflow administration tasks associated with Project Server 2010. 

Installation and setup of Project Server 2010 is covered in the overall setup guide, and these articles will make the assumption that the user has already read and completed the setup of Project Server 2010.

These articles also will not cover the topic of creating Project Server 2010 workflows. Please refer to our SDK articles to find out more information on how to create our workflows.

How to Troubleshoot Your Workflows

Check the workflow status page

1. There are two different ways to do this based on your need
   1. Check from within the project
      • Open a project with a failing workflow
      • Go to the Stage Status Page (This is the very first page from within a workflow stage)
      • From within the workflow Status page expand the “All Workflow Stages” section
        • 
      • Click on the “Additional Workflow Data” link, which is round at the bottom right.
        • 
   2. If your project cannot be opened, you can also get to this page by:
      • Site Actions, View All Site Content
        • 
      • Click on “Site Workflows”
        • 
      • Click on “Show All Workflows” link
      • Find the workflow which you are concerned about.
      • Once you have opened the workflow status page you can investigate the workflow history to see what the workflow was doing before it began to error.
        • 

View the ULS logs

1. ULS logs can be found in: “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS” 
   • Suggestion:  Create a desktop shortcut on the server to this location.
2. Logs will be broken up into pieces. Find the log with a time stamp as close to the time you are most concerned about, and open it.
3. Some key words to look for when going through the logs are:
   • Sharepoint foundation
   • Startworkflow
   • Winwf
   • entering...activity
   • leaving... activity

This is the second of a four part series on common workflow administration tasks associated with Project Server 2010. 

Installation and setup of Project Server 2010 is covered in the overall setup guide, and these articles will make the assumption that the user has already read and completed the setup of Project Server 2010.

These articles also will not cover the topic of creating Project Server 2010 workflows. Please refer to our SDK articles to find out more information on how to create our workflows.

How to Setup the Workflow Proxy Account

Project Server Workflows need to run under the context of a user.  However, they do not run under context of the user that started the project, instead, the workflows are run under the “Workflow Proxy Account”. This means that the user account which you specify as the workflow proxy account must have the proper rights to execute all of the commands a project server workflow will need to do.

It is recommended that you setup a service user to serve as this function.  The steps below show how to define and setup a workflow proxy account.

1. Within Project Web Access, go to Server Settings
   • 
2. Under “Workflow and Project Detail Pages” Click on “Project Workflow Settings”
3. Workflow Proxy User: type in the user name of the account you wish to have all workflows run under.
   • 
4. The minimum rights needed for the Workflow Proxy User account Project Server security are:
   • Global permissions:
     • Log On
     • Manage Users And Groups
     • Manage Workflow
   • Category permissions:
     • Open Project
     • Save Project
     • View Enterprise Resource Data
     • Edit Project Properties
     • View Enterprise Resource Data

This is the first of a four part series on common workflow administration tasks associated with Project Server 2010. 

Installation and setup of Project Server 2010 is covered in the overall setup guide, and these articles will make the assumption that the user has already read and completed the setup of Project Server 2010.

These articles also will not cover the topic of creating Project Server 2010 workflows. Please refer to our SDK articles to find out more information on how to create our workflows.

How to associate a workflow with an Enterprise Project Type(EPT)

Once a workflow has been created within Visual Studio and activated on the server farm (covered in SDK articles) the administrator will need to correctly associate the workflow with an EPT.

1. If you have already created a Workflow Association skip to step 11
2. Once the workflow has been activated on the server, the administrator will need to go to Site Actions, Site Settings
3. 
4. Select Site Administration, Workflow Settings
5. 
6. Click on Add a workflow
7. Fill in the correct information for your workflow
• Workflow: Select the workflow you installed on the farm
• Name: Type in a name for the workflow association
• Task List: Select the “Project Server Workflow Tasks” item from the drop down
• This list is where all of the approvals (if you have any) will go, so long as you coded your workflow to follow the same logic as the Out of the box Project Server Workflow approval process.
• History List: Select “Project Server Workflow History” item from the drop down
• This is the history list for the workflows
• Start Options: Leave it the “Allow this workflow to be manually started by an authenticated user with Edit Item permissions” option checked
8. Assuming you have no workflow association page, press the OK button.
9. You should now see your new workflow association
10. 
11. Within Project Web Access go to Server Settings
12. 
13. Under “Workflow and Project Detail Pages” Click on “Enterprise Project Types”
14. Either select on an existing Enterprise Project Type or press the “New Enterprise Project Type” button
15. Fill in the required information, and under Site Workflow Association select the new workflow association you created
16. 
17. Click Save and you’re done!
• All new instances of this Project Type will use this workflow association.
• If you modified an existing Enterprise Project Type which already had a different Workflow Association, any existing instances of this Project Type will continue to use the old workflow association. Only new workflows will use the new association that you just indicated.
• If you require all workflows to use this new workflow association, you will need to restart the existing workflows (covered below)

All will be recorded and available afterward as podcasts in case you miss them.