Work Management in SharePoint 2013–Slides and Links

Posted on June 13, 2013 by Alex

Thanks to all those people that attended my session on Work Management in SharePoint 2013 at the two Australian SharePoint Conferences. As I mentioned in the sessions, I have uploaded the slides to SlideShare where you can download them. I will also publish the three demonstration videos in the coming weeks to take you through each of the demo’s in the session.

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

Speaking at the Aussie SharePoint Conference Part 2 in Melbourne

Posted on May 20, 2013 by Alex

I am excited to announce that I will once again be speaking at the Australian SharePoint Conference this time in Melbourne on the new Work Management capabilities of SharePoint & Project Server 2013. Hopefully this time the demo gods will be on my side and Project’ Sync to SharePoint will work.

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

Migrating Project Server 2013 database between environments

Posted on May 8, 2013 by Alex

A common requirement when setting up a new Project Server instance, is to replicate production data back into another environment such as Development or Test. In doing so, you have an environment where you can develop, test configuration changes or even perform training against, without impacting your production Project Server instance.

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 Smile

Migrating PS 2010 to PS 2013 Walkthrough

Posted on May 2, 2013 by Alex

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:

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.

Introducing the365project.net

Posted on December 18, 2012 by Alex

With the introduction of Office 2013 and the arrival of Project Online in Office 365 I thought it would be a good time to try and bring some members of the Project and SharePoint community together to launch a new community site. So it is my great pleasure to introduce the365project.net.

What is the365project.net? Well it’s a new tips and tricks site for the Project, Project Server and SharePoint, covering the existing versions and the new 2013 wave of products. As the name suggests the content will also cover some parts of Office 365, Microsoft cloud based solution that provides SharePoint and the 2013 offering has finally been joined with a dedicated Project Server offering called Project Online.

We have been lucky enough to attract authors from all over the world including SharePoint Masters, Community Contributors, MVPs Microsoft staff and other well respected experts with tips for all audiences including End User, IT Pro, Consultants & Developers. Of course we are always looking for new authors and tips, so if there is a tip you would like to share with the community, please submit it through the submit a tip link and we’ll be in touch.

We hope to be posting 2-3 original posts a week over on the site, so make sure you add it to your favourite RSS aggregator, Twitter account (@365prj) or just plain old favourites.

Building your first Project Server App : Part 4 – Submitting to the app store

Posted on December 7, 2012 by Alex

In this fourth post, I thought it would be fun to go through the process of getting your app up into the Office app store so you can start making millions.

Before you decide to submit your app to the store, you need to do a few things:

Read the app store submission guidelines at http://msdn.microsoft.com/en-us/library/jj220035.aspx. These highlight the conditions your app must meet before it will be accepted.
Register for a Seller account. Check out http://msdn.microsoft.com/en-us/library/jj220034.aspx how an overview of what info you need to provide and the process of getting one. The Seller accounts can take a few days to come through, so plan ahead and be patient
Make sure you have a logo, screenshots and some descriptive text ready for the app submission
A version of your .app file that has been compiled for Release.
Decided how you are going to licence your app. The app store itself allows you to define how the app will be licenced, will it be free, will it be per purchase, per user, will there be a trial etc. Some of these decisions are not simple and require significant forethought and in some cases additional development work. For our app I decided to keep it simple and go for a free version. Microsoft published a couple of great blogs / articles helping with the licencing over at the Office apps blog.
Finally, make sure you have tested, tested and tested your app again, the submission process is very thorough and tests the functionality of your app across not only IE but all supported SharePoint 2013 browsers.

Once all of the above is ready, submitting your app is relatively simple. Navigate to the Seller Dashboard and follow the prompts to submit the app.

First choose a listing type, our app is for Project Server, so we need to choose an app for SharePoint, then click on next.

In the next screen you will be asked some information about your app like the name, version, category to list it under and some other bits and pieces. The most important part are the testing notes, these are your only real way of passing information through to the testers who are looking at your app.

As we are making the app available to everyone, there is no need to choose Trial support. Click on Next.

The final bits to add before you can submit the app are screenshots and some descriptive text and links to support, EULA and Privacy policies.

Once you’ve added that text, click on Next and your ready to submit for validation.

From experience, the validation process can take around 3-5 working days. Unfortunately at the moment there is no progress indicator of where you are in the process, with the app either being in a ‘Draft’ or ‘Approved’ state.

Once the app has become approved, it takes a few hours for it to propagate down into the SharePoint app store and to become available for everyone to download and start using.

In conclusion

I hope these posts have shown you that creating an app for Project Server, or for that matter, SharePoint in general is really really simple. Through the various options for hosting apps, either in SharePoint, in Azure, or on your own infrastructure and the investments in APIs such as oData, Rest, JSOM & CSOM, there is an incredibly powerful set of tools available for you to leverage. As we saw, you don’t need expensive tools, with Microsoft making available free tools such as Napa, Visual Studio Express or even NotePad that can be used to build your first app.

Through some of the other investments, such as the corporate catalog and the Office Marketplace, Microsoft look to have provided options for both the hardened enterprise user and casual small business user to gain access to either enterprise specific software, or fully tested third party software which can be bought with the simplicity of buying an app for your mobile phone. I am certainly looking forward to seeing the richness of some of the apps being offered through the app store.

Update: The final app is now available for download in the SharePoint app store http://office.microsoft.com/en-us/store/publish-all-enterprise-projects-WA103982215.aspx?redir=0. If you find it useful, please submit a review.

Building your first Project Server app : Part 3 – Taking the app to the next level

Posted on December 1, 2012 by Alex

In this post, we will take our app that we built in Napa and successfully tested and export it out to Visual Studio to enhance the app, specifically we are going to add a ribbon button so our app can be invoked directly from the PWA ribbon.

Exporting the Napa solution out to Visual Studio

Whilst Napa is a great tool, at the moment it is not possible to add a CustomUI Action at present, so we need to use Visual Studio. Luckily Napa has a handy export to Visual Studio capability. Before we export, make sure you have Visual Studio 2012 installed and have downloaded and installed the Visual Studio Tools for Office 2013 from http://t.co/lrkaq4au (this is currently Preview 2).

To export the project, in Napa click on the ‘Open in Visual Studio’ icon

You will be prompted for which language you wish to export using, our app is all JavaScript so it doesn’t really matter, but I usually pick C#

Napa will prompt you to download a small .exe file that will open Visual Studio and the exported project.

As you can see, our app has been opened in Visual Studio 2012 with all the components you would expect to see

To add our ribbon button, we need to add a new item to our app project. To do so, right click on the project name and choose Add > New Item

From the menu, select Ribbon Custom Action, name it and click Add.

A dialog will pop up asking to configure the custom action. Make sure you choose to expose the custom action in the host web (in our case the PWA instance) and that it is scoped to None (we don’t want it on a list, but rather the ribbon). Click on Next.

Another dialog will pop up asking us to provide a target location, label text etc. Unfortunately the options it provides are a little limited for Project Server, so we will accept the defaults (by clicking Finish) and edit them later.

Visual Studio will generate the Ribbon XML automatically, including placeholder graphics which is pretty cool. But unfortunately the generated XML won’t meet our needs.

For our app, we want to add a new group to the Project ribbon in Project Center, and pop our button in there, like so…

To do this we need to define a new group, the button and a graphic in the XML, which follow the usual format for a SharePoint / Project Server ribbon customisation. However there are a couple of changes in 2013 with regards to ribbons:

We can’t have JavaScript in the ribbon – which means instead of calling our App.js from the ribbon like we would have in 2010, now we have to call the default.aspx page and get that to do the work
We need to use a special token ~appWebUrl to tell SharePoint to navigate to the app web which resides under the host web (PWA)
We will also pass through the {StandardTokens} query string that contains information about the site calling the app, including language and most importantly it’s location.

In Visual Studio, replace the contents of the Elements.xml file for the custom action with the following:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomAction Id="cb1834f2-06ed-4b4e-9531-71bdc4539fcb.HostWebCustomAction"
  Location="CommandUI.Ribbon">
  <CommandUIExtension>
    <CommandUIDefinitions>
      <CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.Groups._children">
        <Group Id="Ribbon.ContextualTabs.ProjectCenter.Home.Publish"
        Sequence="110"
        Description="Publish Custom Group"
        Title="Publish App"
        Template="Ribbon.Templates.Flexible2">
          <Controls Id="Ribbon.ContextualTabs.ProjectCenter.Home.Publish.Controls">
            <Button Id="Ribbon.ContextualTabs.ProjectCenter.Home.Publish.PublishAllProjects"
            Sequence="10"
            Command="Invoke_CustomAction"
            Alt="Publish"
            LabelText="Publish all projects"
            TemplateAlias="o1"
            Image16by16="_layouts/15/1033/images/ps16x16.png?rev=23"
            Image16by16Left="0"
            Image16by16Top="-112"
            Image32by32="_layouts/15/1033/images/ps32x32.png?rev=23"
            Image32by32Left="0"
            Image32by32Top="-224"/>
          </Controls>
        </Group>
      </CommandUIDefinition>
      <CommandUIDefinition Location="Ribbon.ContextualTabs.ProjectCenter.Home.Scaling._children">
        <MaxSize
        Id="Ribbon.ContextualTabs.ProjectCenter.Home.Publish"
        Sequence="140"
        GroupId="Ribbon.ContextualTabs.ProjectCenter.Home.Publish"
        Size="LargeLarge"/>
      </CommandUIDefinition>
    </CommandUIDefinitions>
    <CommandUIHandlers>
      <CommandUIHandler
      Command="Invoke_CustomAction"
      CommandAction="~appWebUrl/Pages/Default.aspx?{StandardTokens}"/>
    </CommandUIHandlers>
  </CommandUIExtension>
  </CustomAction>
</Elements>

In the XML above, I have cheated and used one of the out of the box buttons for Project Server, but you could add your own in the Images folder of the solution and reference it.

Next, we need to make some minor changes to the to the App.js file to ensure return the page back out of the app when it’s completed. To do this replace the QueueJobSent() function as per below.

function QueueJobSent(response) {

    // Whilst the call is status = 0, i.e happening, then show the publishing message
    if (response == 0) {
        $('#spanMessage').text('Publishing projects...');
    } else
        // When the call has come back successfully, show the published message and then navigate back
        if (response == 4) {

            // Navigate back to the calling page
            var spHostUrl = decodeURIComponent(getQueryStringParameter('SPHostUrl'));
            // We're in an iFrame, so make sure you use the top
            window.top.location.href = spHostUrl;
        }
}

We also need to add another function called getQueryStringParameter which reads the query string from the SPHostURL (part of the {StandardTokens}.In this case here I am borrowed some code to read the query string used in a couple of Microsoft app examples.

// Function from MS examples to read the query strings
function getQueryStringParameter(urlParameterKey) {
    var params = document.URL.split('?')[1].split('&amp;');
    for (var i = 0; i < params.length; i = i + 1) {
        var singleParam = params[i].split('=');
        if (singleParam[0] == urlParameterKey)
            return decodeURIComponent(singleParam[1]);
    }
}

With that all the development is complete, all we need to do is come up with a graphic that will be seen in SharePoint, the app should have a transparent background if you want it to fit in with Project Server 2013’s new look and feel themes. Once you have built an icon, add it into the Images folder of the solution and configure the Icon in the App Manifest.

Now all we need to do is build the app, deploy it to the corporate catalog and add it back to our PWA instance.

Installing our new improved app will now show a button on the ribbon in the Project Center that when clicked will navigate out to our Publish Projects page and then once complete, navigate back to the calling site.

So you can see how simple and easy it was include a new button on the ribbon that calls our app directly, publishes the projects and then returns the user to the source site.

In the final post in this series, I will take you through the submission process to make your app available in the SharePoint app store to start making millions Smile

Retrieving the ProjectUID of a workspace using _api REST interface

Posted on November 11, 2012 by Alex

Project workspaces are awesome. There I have said it. But one thing that has always frustrated me and other users is how hard it is to determine what project the workspace is linked to. The only reliable way of determining the ProjectUID is to look in the Property Bag of the site where Project Server stores the association. There are a couple of tricks that will let you find out the ProjectUID, one of them being developing a custom web part like I did a while back, or using the CSOM in 2013 as Giles Hamson posted a while ago,

But there is an easier way, thanks to the new _api REST interface.

With this new interface you can expose all aspects of the SharePoint site including all the web, site and lists. However the coolest thing is that you can expose values from the Property Bag directly, meaning we can get the ProjectUID of the site with a simple URL call which you can either use in your JavaScript code, or call it directly from a workflow.

The URL looks like this…

https://mytenant.sharepoint.com/sites/pwa/New%20Project/_api/web/AllProperties?$select=mspwaprojuid

if you break down there are three components…

The first component is the URL of the site we want to get the ProjectUID from.

The second component is the _api call we wish to make, in this case we are retrieving the AllProperties of the web object.

The third component filters the AllProperties to only retrieve the MSPWAPROJUID property, which is where the ProjectUID is stored.

When you open that url in the browser, you receive the following XML back from SharePoint containing the ProjectUID.

Of course you are not limited to just the ProjectUID, removing the filter component from the URL will retrieve all the properties of the Project site including the URL of the PWA site it is associated with (PWAURL).

SharePoint Saturday Sydney is coming – Saturday October 27th

Posted on October 2, 2012 by Alex

SharePoint Saturday Sydney has come around again and I am pleased to announce that I have been given the opportunity to present on one of my favourite new features of 2013, Work Management.

The session title and abstract are as follows:

Work Management in SharePoint 2013: What it is and why you will love it

If you have ever tried to track tasks in SharePoint, lists or pieces of paper, you are going to love the new Work Management capabilities of SharePoint 2013. Come along to this session to get an understanding of these exciting new capabilities and how quickly you can start using them in your organisation for project and work management

Registration for SharePoint Saturday is free and includes top notch sessions from local and international experts on SharePoint including MCM’s, MVPs and Microsoft themselves. You can see the full agenda and speakers at http://sharepointsaturday.org/sydney/default.aspx

If you are in Sydney on the 27th and interested in SharePoint, especially the new version, come on down, the details are:

When: Saturday 27^th October 2012

Where: Cliftons, 190 George Street, Sydney, NSW

Cost: Free – register at http://spssyd12.eventbrite.com/

I look forward to seeing you there Smile

SharePoint Saturday Melbourne–4th August 2012–with 2013 content!!

Posted on July 22, 2012 by Alex

With all the excitement of the Office 2013 announcement this week, its hard to think how it can be topped, well it can. Saturday 4th August, just two weeks away is SharePoint Saturday Melbourne, the first Australian SharePoint Saturday since the Office 2013 preview was announced and therefore the first to include SharePoint 2013 content.

This year in a departure from the norm, I will be taking part in the keynote giving an insight into some of the killer new features and capabilities of the platform. Also stay tuned for a technical deep dive on SharePoint 2013 from Aaron Saikovski at the end of the day and the always fun Ask the Experts panel.

Tickets are still available for SharePoint Saturday Melbourne at http://www.sharepointsaturday.org/melbourne/default.aspx

epmsource

Alex's blog on all things Microsoft Project & Project Server

Tag Archives: SharePoint 2013

Work Management in SharePoint 2013–Slides and Links

Speaking at the Aussie SharePoint Conference Part 2 in Melbourne

Migrating Project Server 2013 database between environments

Migrating PS 2010 to PS 2013 Walkthrough

Introducing the365project.net

Building your first Project Server App : Part 4 – Submitting to the app store

In conclusion

Building your first Project Server app : Part 3 – Taking the app to the next level

Exporting the Napa solution out to Visual Studio

Retrieving the ProjectUID of a workspace using _api REST interface

SharePoint Saturday Sydney is coming – Saturday October 27th

SharePoint Saturday Melbourne–4th August 2012–with 2013 content!!

Follow “epmsource”