Like many Project Server folks, I have been heavily using the Playbooks tool to move settings hither and thither in multiple Project Server environments.  A couple scenarios where I might use the tool would be:


1) Restore system settings to a VPC for security testing, planning, or just to help develop screenshots for documentation.

2) Move system settings from Production to Training.

3) Restore system settings from my DEV environment to TEST or PROD.

4) Quickly standup an extra environment for training or mocked up simulations.


There’s already excellent documentation on how to use the tool – which admittedly is relatively easy to use:


Marc Soester’s Blog:

…and a number of posts on the Microsoft Project Server newsgroup.


This blog represents my attempt to capture some of the quirky behavior of Playbooks that I’ve seen over the last couple of years since it came out.  Note that some of this content was prompted by discussions (and testing) by Ijaz Rasheed.  Thanks Ijaz!


The Scenario

Today’s scenario is that we have a source environment and want to deploy all of the settings to a target environment.  We will need three things to accomplish this:

1) A table listing all of the custom fields configured in the source environment (with formulas)

2) The Playbooks XML file from the source environment

3) A blank .mpp file that was created in the source environment and then saved offline

Now, I would point out that it’s always advisable to work from exhaustive documentation and configuration specifications.  But if those are not available, or still in development, then these three items will be perfectly adequate (with potentially some caveats around restoring resources).

It is assumed that PWA is running and not configured in the target environment.


The Process


1) Take a Playbooks of the source environment.  Playbooks will choke if you inadvertently select to take a backup of the wrong item.  For instance if timesheets or the cube functionality are turned off at the server level, Playbooks will stop working when it gets to those settings.  Typically, I deselect any item that we’re not actually using.  Note also that I’ve had issues with the cube building service, where Playbooks will restore the same settings to the target environment, and thus prompt the target environment to overwrite the source cubes on the next rebuild cycle.  So typically, I don’t include cube build settings in my Playbooks.

2) Open Microsoft Project Professional while connected to the source environment.  Select Save As, and then save the project as a file to your desktop.  When the server prompts you to save “All enterprise elements” or “Some enterprise elements,” select “All.”  This will create a file with all of your custom Enterprise Global views, filters, groups, and enterprise calendars – which can then be easily transferred to your target environment.

3) Restore Playbooks to the target environment.

The easy part is now done.  About 90% of your settings probably moved over successfully.  The open question is how do we check, and what is remaining to do…?


Custom Fields


When Playbooks restores the custom fields to the target environment, it typically will change many of the internal unique ID’s that Project Server uses to reference those fields.  Thus, we need to go through all of the custom fields and clean them up.  Luckily, I have a spreadsheet with all of the custom formulas.  The fields that will not transfer successfully are the ones that reference other fields.  For instance, I create a flag field called “Major Milestones.”  I then create a number field that counts the number of Major Milestones.  The number field will lose the formula on restore from Playbooks.

If you are planning to use Playbooks at some point in your deployment then, it behooves you to follow these two simple principles:

1) Avoid referencing other custom fields as much as possible.  Try to make sure that each formula can stand alone and only refers back to built in fields.

2) Flag every formula that references another custom field on your spreadsheet.  These are the fields you will need to review after restoring from Playbooks to the target environment.  Make sure to check the rollup for the summary tasks to ensure that got transferred.

Restoring the correct formulas is a simple matter of clicking on the custom field, and pasting the correct formula from the spreadsheet.  Occasionally, you may have a corrupted field, in which case you will need to delete it, and simply create it anew – noting of course to correct the formulas of any other field using the one you deleted as a reference.

If you do delete and recreate any fields, you will need to go into the Enterprise Views that utilize these fields and add them back to any view and/or filter that got wiped out when you deleted the original field.



Security settings seem to work pretty smoothly using the Playbooks tool.  I would note however that there are a couple of caveats to this operation.

First, when using Playbooks in Replace mode, it will actually delete the existing groups in the target environment, and then create new ones.  If you already have those groups populated in the target environment, you will have to go in manually and add the right people to the right groups – unless you’re using AD Sync to populate these groups.  If you’re using AD Sync, it’s a simple matter of running the synchronization command, and everything is working just fine.

Second, the default security groups seem to act like kryptonite to Playbooks.  As far as I can tell, this is for the simple reason that Playbooks cannot delete the default security groups to reinstate them with the revised security.  This becomes especially relevant when working in a migrated environment, where you are trying to overlay security settings from your DEV environment on top of TEST, which actually consists of a number of the default groups that were originally created in a MOPS 2003 environment.

For these reasons, there’re a couple of design considerations you want to make when using Playbooks:

1) Consider using AD Sync to quickly populate security groups on an as needed basis whenever restoring the environment.

2) Do not use the default security groups, but create new ones for use in your deployment.  This is generally what i would consider a best practice anyway.  Note that we don’t seem to have the same issue with Categories.


Enterprise Global

I’ve never been able to restore eGlobal successfully using Playbooks.  I am not sure if that is something I am doing wrong, and would love to hear about, or if it’s just an inherent bug in the tool.  Never fail, there’s an easy workaround, which is what I typically use.

It helps to have the MPP file you saved originally located on two different environments.  One should be stand alone, or at least have Microsoft Project open in Computer mode.  The other one should have Microsoft Project open and connected to the target environment.

Open the source MPP file in both environments.

In the target environment, open the Enterprise Global template using the Tools > Enterprise Options > Open Enterprise Global command.  Then open the Organizer (Tools > Organizer), ensure that you have the source file open on one side, and the eGlobal template on the other, then copy all of your custom elements from the source file to eGlobal.

Make sure to include filters, groups, views, tables – for both Resources and Tasks.

Review all of the custom elements in the open eGlobal file.  There is a good chance that anything which references a custom field will have gotten mixed up as the UID’s have all been changed.  This is a relatively simple matter to clean up though, as you just have to hid the “Unavailable” fields in the custom views, then insert the new custom fields.  Take the same approach to all of your custom filters and groups.

If you have any questions on how the target environment should look, or what fields should be in a specific view, refer back to the source file open on the stand alone environment.  All of your custom views and filters will show up accurately in that file.

Because of the above, you should always consider the following when configuring eGlobal:

1) Always use a standard naming convention for all custom elements.  Prefix them with asterisks as in “**Custom Filter,” or use an underscore and the enterprise abbreviation, “_ENT.”  Whatever you use, make it easy to go into the Organizer and identify the custom elements.


Enterprise Calendars

Calendars are another thing which I have never been able to restore using Playbooks.  This gives us the chance to use another workaround.  Gary Chefetz reminded me of this functionality with his post: which was aimed at a slightly different purpose.  Thanks Gary! 

With your source file still open on the environment connected to the target server, go to Tools > Change Working Time.  Select the custom calendars in the drop-down list, and then click on the button to “Add Calendar to the Enterprise.”  Done.




Resources may be a bit trickier, due to open questions as to whether or not you’re populating them with AD Sync, or just loading them – and what kind of custom fields you have associated with them.

At it’s simplest, I typically configure a Resource Center view in the source environment with all of the resource configuration data – things like names, Windows ID, custom fields, RBS.

Right click on the view in the source environment to get the “Export to Excel” command, and drop the resources into an Excel sheet.

In the target environment, open the Resource Pool using the Microsoft Project client, and simply paste your data into a custom view created for this purpose.  Then you need to restore the appropriate security settings, as per the instructions above – either manually or using the AD Sync command.

So from a resource management perspective, here’s a couple of considerations for using Playbooks effectively:

1) Create a custom PWA Resource Center view with all of the configuration data for the resources.

2) Create a custom eGlobal view that matches the custom PWA Resource Center view that will then allow you to paste the resources back into the Resource Pool.

3) Don’t forget that if you are moving from TEST to PROD, you may have to swap out some of your AD groups for synchronization if you have test groups and production groups.


Custom Settings

Go into the Cube Build Settings and Workspace Provisioning Settings, and restore those settings by hand.  Note that you should be careful that the target and source environments are pointing at different cubes and different workspace provisioning locations.

Edit the Reminders Webpart on the main page and the My Tasks webpart on the My Tasks page to ensure they have the same settings as your source environment.

Don’t forget to go into PWA and ratchet down the PWA security as needed.  These settings are not captured in the Playbooks tool.


More Playbooks Fun

Try opening the Playbooks XML file in Excel.  With some practice, you will find that you can actually manipulate and review all of the server settings quite easily from within the document.  I’ve used this to review Lookup Table data and assess what is still incomplete from a configuration standpoint.


And there you are…you now have a new environment with all of the correct MOPS configurations.  Typically, with some practice, depending on how complex your environment is, this entire process can be done in about a half an hour.