#ProjectOnline / #ProjectServer #Project site provisioning using #Office365 PnP remote provisioning #SharePoint #PowerShellMay 4, 2016 at 4:20 pm | Posted in .Net, Add-on, Administration, App, Configuration, Customisation, Functionality, Information, Installation | 1 Comment
Tags: Office365, Project Online, Project Server 2013, Project Server 2016, SharePoint 2013, SharePoint 2016, SharePoint Online
For many years now Project Server deployments have used Project Sites or known as Project Workspaces before Project Server 2010. Typically most deployments have custom requirements for the sites so custom site templates were created from a site created using the default Project Site template. The updated custom site template was then linked to the Enterprise Project Type so that new projects created used the new site template. The biggest issue with this approach was that if you wanted to update the site template later on down the line all of the existing project sites would either need manually updating or writing code to traverse through all the existing sites and make the changes. With the new online world in Office 365 there are other things to think about too. If you create a new custom site template based on the default Project Site template then Microsoft roll out a new feature in the base Project Site template – your new project sites wont get that change either. This is where the PnP remote provisioning engine is great. For a while now – at least a year or 2 I think, the best practise is to stick with the default site templates Microsoft provide, so the Project Site template for example. The Enterprise Project Types should use the default Project Site template so each new project gets a site created using the default site template. But what about my custom lists, or columns or views I hear you ask – deploy the custom artefacts once the site is created from the default site template. In this post I will give you a very quick introduction to the Office 355 PnP Remote Provisioning engine which is part of the PnP core component. PnP, known as Patterns and Practices – details can be seen here: http://dev.office.com/patterns-and-practices. This will enable you to deploy your custom site artefacts.
For this example we will look at the PowerShell variant: https://github.com/OfficeDev/PnP-PowerShell but is also available with managed code. To get started with the PowerShell version follow the steps in the GitHub link to get the components installed. I have created a project / project site using the default Project Site template and added a new list called Change Requests that is linked to a Site Collection Content type in my root PWA site collection:
This list has two views:
I have also updated the default Risks list to use custom content type and included one new column:
I have added my new column to the All Items view:
This is the new site template I want to use. Typically this is where you would save as a template but not for this example.
Once the PnP components are installed on your machine, connect to the source project site using this command – update the Url for your site:
Connect-SPOnline –Url <source site URL>
Enter credentials if prompted to do so.
Now use the following command to extract the site:
Get-SPOProvisioningTemplate -Out C:\Temp\PnP\NewTemplate.xml
This process will extract the site definition and create an XML file in the specified location:
At this point the XML should be modified to remove unneeded properties. For example, as this project site is linked to a project already the property bag will contain certain properties referenced to the source site – I don’t want to overwrite these settings on my target sites so I removed the property bag entries highlighted below.
I have also removed properties for configuration I don’t need to update, other lists etc. See an example below, I have only left the two lists I have added / updated:
I don’t cover this here but I used Visual Studio – really one for the devs out there.
Once you are happy with the source XML file you are ready to deploy this to the existing project site/s. In this example I have a test project site created by the default Project Site template that has not been modified:
In PowerShell I now connect to the test target site using the command below – update the Url for your site:
Connect-SPOnline –Url <target site URL>
Then run the following command to apply the changes:
Apply-SPOProvisioningTemplate -Path C:\Temp\PnP\NewTemplate.xml
Once completed the test target site should be updated, in this example, with a new list and updated risk list. Once you are happy with the test target project site you could repeat the process on other project sites. I have found some settings are not set correctly and some do generate errors in PowerShell but there are usually monthly updates the PnP code so always ensure you regularly update the modules using the Update-Module command.
This is a very simple example using PowerShell, in production you might have a full script that has a list of Project Sites you want to update and get the script to update them all etc. Or better still, go down the manage code route and create an event driven SharePoint provider hosted add-in to do it. Either way, fully test this process on test project sites / projects first before any production projects / project sites!
Tags: Office365, Project Online, Project Server 2013
Just a quick post to highlight a new code sample that has been added to the Project Online code samples on GitHub found here: https://github.com/OfficeDev/O365-Project-Online-.Net-Samples
The projTool tool has been created / updated to use CSOM instead of the PSI, Brian Smith has a great walkthrough for getting started with this tool on the link below:
On the GitHub samples you will find other examples for JSOM, CSOM and REST. A great place to start with Project Online development. You will also find some simple code samples / solution starters on the link below for Project Online / Project Server:
Tags: Project Online
Quick post to highlight that the Project Online CSOM DLL ‘Microsoft.ProjectServer.Client.dll’ is now available via the NuGet package for SharePoint, see the blog post below for details:
Direct link to the package: https://www.nuget.org/packages/Microsoft.SharePointOnline.CSOM
Update multiple #ProjectOnline PWA Instances using c# .Net console app #Office365 #csharpe #PPM #PMOTDecember 23, 2015 at 4:12 pm | Posted in .Net, Add-on, Administration, App, Configuration, Customisation, Functionality, Information | Leave a comment
Tags: .Net, CSOM, Office365, PPM, Project Online, Project Server 2013
Following on from a post I wrote over a month ago regarding checking entities from multiple Project Online PWA instances, this post covers updating multiple Project Online PWA instances. The first post can be found below:
In this post I demonstrate a way in which you can manage configuration across multiple PWA instances, for example you might want to create a new custom field on more than one instance. This is a simple example just to show you the idea. As this is very much an example, I haven’t released any code or solution but you can see the core code further on in the post.
For the purpose of this blog post I created a C# .Net console application. Once you have a new visual studio console app project you will need to add the references to the following DLLs:
I used the v15 SharePoint and Project Server dlls here.
In the program add these dlls:
The first part of the code is to capture the custom field name and description plus the number of PWA instances to update:
It then goes into a loop to create the custom field on the specified PWA site:
The code below is used to secure the password in the console input:
That is it. This example will create a Project level custom field but you could easily update the code to get the user to enter the entity type (task / resource etc.)
To see this in action see below:
Enter the custom field name:
Enter the custom field description:
Enter the number of PWA instances to update:
Enter the first PWA site URL:
Enter the username for an account that has access to create custom fields:
Enter the password for that account:
After pressing enter it will go off and create the custom field on the first PWA instance:
Press any key and it will go back to ask for the 2nd PWA instance:
It will then prompt for the username and password as before. It will keep looping through depending on how many PWA sites needed to be updated.
On one of those PWA instances we can see the field was created:
Nice and easy, saves navigating around multiple PWA site collections for a simple change you might want to roll out across multiple instances.