Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

Project Server 2010 CU August 2013 Issues

Microsoft announced the release of the August 2013 Cumulative Update (CU) for Project and Project Server 2010 and 2013.  After installing this Cumulative Update, there were some problems though!

First of all, you can find a description and download the CU using this link. When you execute the downloaded bits, it will extract the installer to your system. Double-click on it, and it will “install” the CU to your environment. What you have to do next is running the “SharePoint 2010 Products Configuration Wizard“, which will perform the actual upgrade/patching. Just follow the steps of the wizard, and the configuration -should- complete without any errors. Although, this will happen Read More

How to setup DirSync with Project Online

Last week, the Active Directory team released a new version of a tool called “DirSync”. This is a tool who makes it possible to synchronize Active Directory accounts from your on-prem environment with Office 365. The version they release was a special one. Let me quote:

I’m happy to let you know that we’ve made it dead simple to connect AD to Azure AD, enabling users to log into Office 365, Windows Azure and any other cloud app integrated with Windows Azure AD using their on-premise username and password.  We’ve done this by updating Windows Azure Active Directory Sync Agent (a.k.a. DirSync) adding the ability to sync hashes of users’ on-premise AD passwords into Windows Azure AD.

How cool is that? Well, curious as I am, I decided to give this tool a go and synced my (playground) Active Directory to my Project Online tenant (which is nothing more than a Office 365 subscription). In this post, I’ll explain how you can achieve this.

First things first, you need an Active Directory. If you have an on-prem AD, just skip this step, at it’s just for demo purposes. As I don’t have the required hardware, but I do have an MSDN subscription, I used some Windows Azure VM’s for that part. What I did was first creating a DNS server (Networks -> Virtual Network -> Register a DNS Server). Next, a new virtual network using my DNS Server. Now  you can create your 2 Azure VM’s. I will not explain this in detail, but be sure that you use your Virtual Network when you go trough the Wizard.


You need 2 VM’s, one for the Active Directory role and one responsible for the DirSync. I’ll not go into detail about how to setup an AD role and how to join the other machine to this domain. You can find all info here: Once completed, you should have this:


Next up, we will ‘enable’ DirSync at our Office 365 subscription. Browse to and enable step 3:


Next up, we will install the “DirSync” tool. You can download the latest version here (or use the “Download” link on the page you’re currently looking at). Once the file has been downloaded (180 MB), run the installer, and follow the wizard. The installation takes about 10 minutes.


Once the installation has been completed, the configuration Wizard will start. Provide your Windows Azure Active Directory Administrator (WAAD) Credentials. This is the account that you used to create your Office 365 subscription. (if you don’t know the credentials, or you want to try, browse to: and test it)


At the next step of the wizard, enter your Active Directory Enterprise Administrator Credentials.


At the next step, be sure to enable “Enable Password Sync“. That’s this cool new feature!


Once the last step has been completed, a first “full sync” will be started:


That’s it! Nothing special. Now you have to check the “Users” in your Project Online (office 365) subscription. Browse to “Admin -> Office 365 -> Users“. There you will see the AD users! Great! Now, just “syncing” this users does not mean that they have access to your subscription. They are not assigned to a license. To manage this, click on the user, and select “Activate Synced Users


Assign the correct license to this user, and click “Next” to finish. Note that this user will get a temporary password, but you don’t need this as you have DirSync with password sync (joy!).


Still one small thing to do. “Share” my site (in this case the Project Web Access) with that new user. Just click on the “Share” button.


Now open a new (inprivate) browser window, and login using the username and password from your Active Directory. There you go:


There you have it! A sync between your AD and Project Online (Office 365). But it doesn’t stop there for this post. I just wanted to be sure that the password sync does actually work. So I changed the password and the first name of my user in my AD. But then … How can I force a sync? By default, it takes about 3 hours (password changes-only will be instantly, but changing a name for example will take some time).

So, PowerShell to the rescue! Browse  to “C:\Program Files\Windows Azure Active Directory Sync” and double-click on DirSyncConfigShell.psc1. Enter the command “Start-OnlineCoexistenceSync“:


If you open the “Event viewer” on your machine, you will see some entries from the AD sync:


Enjoy your syncing!

Using Project Online OData with Excel Web App

Project online has some great reporting features. One of the features that I really like is the OData service. This OData service is not only available for Project online, but also for on-premise deployments. To access this feed, all you have to do is browse to the following url: “/pwa/_api/ProjectData”.

One of the tools to “explore” this Odata feed is Excel. You can open one of the existing Project Online reports with Excel. Go to “Reports – English – Project Overview Dashboard” and click on the 3 dots, select “Edit“.


The report will open in Excel, and you can now select the ‘DATA‘ tab, and press ‘Refresh All‘. This should load all your data and show you a list of all projects with some additional information. This is pretty cool, but can we also use this within the Excel Web App? Well, let’s try it straight. Go back to the “Reports” folder, and instead of clicking on the 3 dots, just click on the name of the file. Excel Web App should open, and you will see an empty list of projects. Now click on the Data tab and select “Refresh All Connections“.


So, that’s not what we were expecting. It looks like Excel Web App cannot access the Odata feed. The explanation is quite simple:

When Excel workbooks are refreshed in Office 365, the BI Azure Service retrieves updated data from Project Online and recalculates the internal workbook model. If the workbook has data connections pointing to Project Online OData feeds, the BI Azure Service must have permission to the SharePoint Online tenant to retrieve that data.

What we have to do is giving the BI Azure service the required permissions to access our Project Online tenant. Browse to your PWA instance, and add “/_layouts/15/appinv.aspx” to the URL. For example ““. You will now see the application permission screen. In the App ID field, add 00000009-0000-0000-c000-000000000000 and click Lookup. The title and App domain should tell you we’re working with the Azure AnalyisisServices. Copy and paste the following in the Permission Request XML Field


Click create and Trust the App.


To be sure that the App has been granted with the correct permissions, go to “Admin (on top) – SharePoint – Apps – Permissions“. There you should see the App “Microsoft.Azure.AnalysisServices


That’s it. Now we can open the report using Excel Web App, and click on “Data – Refresh All Connections“. Have fun!


Note: Be sure that you first refresh and save your report using the Excel (desktop) application. This will update the internal model of the workbook so it is supported by Excel Web App.

A single Project Site for both TFS and Project Server

I got a question from a friend of mine (Pieter Turcq) today, who asked me if it’s possible to use one single Project Site (in SharePoint) for both TFS and Project Server? Well, actually you can. In this post, I will show you what the requirements are and how you can easily achieve this. But first let me start with a brief ‘overview’ of how it looks like out of the box.

One of the nice things about Team Foundation Server is that it creates a SharePoint “Project Site or Portal” when you create a new Team Project. This is a place where you can add project documents, view some dashboards and whatever SharePoint magic you want to use. On the other hand, you have Project Server. In some cases, you can have a nice integration between both systems using the Team Foundation Server Extensions for Project Server. This way, you can manage the data flow between TFS and Project Server (but this is not the scope of this blog post). The thing is, if you create a new Project in Project Server, it also creates a Project Site. The total picture will look like this:

01Note that this is a situation where the Project Portals from TFS are hosted on another SharePoint environment as the Project Sites of Project Server. (If they are hosted on the same environment, it will of course use a different Site Collection, but you will have less work to get to the end solution. I’ll explain this a bit later). Now, how can we get one Project Site for both systems? We have 2 options: A quick-and-dirty solution, or a decent solution.

The quick-and-dirty solution

The first solution is really simple. What you do is pointing the Project Site from your TFS Team Project to the URL of your Project site of Project Server. You can do this using Visual Studio using Team Explorer. If you go to “Settings -> Portal Settings“. There you can set an option “Use a website“.


It will now redirect to your Project Server’s Project Site. That’s all. Nothing more, nothing less. It will have no interactivity with TFS or what-so-ever, you will not see the Project Site documents in your Visual Studio, you will not have any dashboards on your Project site,.. So this is not an option. Let’s move on.

The better solution

A better solution is to make it possible to let the Project Server’s Project Site behave like it would have been a “standard” TFS Project Portal.

If your are in the same situation like the one I’ve illustrated, you must install and configure the Team Foundation Server extensions for SharePoint Products on the remote portal. If not, you can skip this step, and no actions related to this need to be executed! This is a step that has to be executed for ALL SharePoint application servers. It contains the necessary Web Parts and some dashboards. You have some excellent guides for this, but it really is a straight forward process. Just make sure that you have the right permissions, and especially that the TFSService account that needs to a Farm Administrator.

Great, now our SharePoint instance who’s hosting the Project Server’s Project sites is able to do “TFS related” things. Next, assigning this SharePoint instance to TFS. Open the administration console and click on “SharePoint Web Applications -> Add


Note: It is import to know that when creating a new Team Project in TFS, we will NOT allow the wizard to create a Project Portal. Because if you don’t watch out, it will create one on your PWA instance directly. This is not the behavior that we want. We want Project Server to create Project site, and link our TFS Team Project to that site manually. So be careful!

Alright, so now that the SharePoint instance of Project Server is known by TFS, we can configure our Team Project to use an existing Project Site from Project Server. Open Visual Studio, go to Team Explorer and select “Settings -> Portal Settings”. Enter the correct settings:


In this example, I use the TailspinToys Project Site from Project Server, to be used as TFS Project Portal from TFS. Be sure to select the check box “Reports and dashboards refer to data for this team project“. Click Ok. If you now go back to Team Explorer and select the “Documents” node, you will see the content of the documents library from you Project Server’s Project site.


Mission accomplished.. or not? Well, it’s great to have the documents library available from your Project Site. But wouldn’t it be cool if you could also use this Project Site to add your TFS Dashboards, and some TFS Related Web Parts? Well, actually you can! If you open your project’s Project Site (in Project Server), and go to “Site Settings -> Site Features“. And activate the dashboard you need. In my case, it’s a TFS Team Project based on the Agile Process Template, so I selected “Agile Dashboard“. If you click activate, you will see some new items in the menu on the left side. That’s exactly what we need. This way, we can also change whatever we want, and we can even add the TFS specific Web Parts like a Work Item Query list.


That’s pretty cool! So there you have it, one single Project Site/Project portal for both TFS and Project Server. Have fun!

Note, when Project Server was not on the same SharePoint instance as TFS, and you followed the previous steps using the TFS Administration Console, and you don’t see the dashboards listed in the features list, be sure that it’s enabled in the Web Application of your PWA! You can check this using the “Central Administration -> Application Management -> Web Applications -> Web Application -> Manage Features“. It should be enabled by default, but you never know! Next to that, if you don’t see any web parts related to TFS, look at the Site Collection Features, and be sure that “Visual Studio Team Foundation Server Web Part Collection” is activated. That’s all!


Microsoft Project Server 2010 Certified Professional

Since last week, I am a Microsoft Project Server 2010 Certified professional. I took the 70-177 exam (Microsoft Project Server 2010, Configuring) and passed it with a score of 892/1000.

About the exam, well firstly, there is not that many study material. The company I’m working for (RealDolmen) was able to get me a copy of the book “Implementing and Administering Microsoft Project Server 2010” by Chefetz and Howard. It’s a big one with about 900 pages to read, but it’s really worth it! If you study the book and have some experience with a few implementations/setups, you will definitely pass.

The Exam structure

There were 75 questions in the exam and you have about 4 hours to complete it. The exam results are broken down into four sections.

  1. Installing Project Server 2010
  2. Managing Resources and Security
  3. Configuring Project Server 2010
  4. Administering Project Server 2010

Focus points

All questions were spread across the 4 sections.

  • Be sure that you know what the prerequisites are for a project server environment and the various upgrade options from both Project Server 2007 and Project Server 2003 to 2010.
  • One important thing is that you need to understand the difference between Categories and Groups in project server and how these are used to control the permissions of your users. It’s all about who can do what and who can access what. Also important is the part about controlling the access to project sites for users through project server and for users that you don’t have access to project server.
  • Also be sure that you have some basic SharePoint Server 2010 knowledge. As Project Server 2010 is built on top of SharePoint, it uses lots of SharePoint features

Take your time!

If you take the exam, just be sure that you read the question for what it says. Nothing more, nothing less. For example if there is a question with something like “A Project Manager saves his project” don’t assume he has saved AND published the project. Just take the time to read the question, reread it and then refer back to it when looking at the answers.

Good luck!

Project Server 2013 On-premises Workflow

I’ve already spent a lot of time using Project Online. You can find some information on my previous blog posts here and here. As Project Online is really awesome, there are off course some cases where you need to install Project Server on-premises. The installation process is quite easy to do (even with PowerShell).

If you want to use Workflows with your Project Server instance (in fact with SharePoint 2013 in general), you need an additional component called “Workflow Manager 1.0“. Let me quote the definition of this:

Workflow Manager 1.0 allows you to host and manage long-running Windows Workflow Foundation (WF) applications.  Workflow Manager was designed to meet the scale and multi-tenant needs of your modern enterprise applications while also increasing developer and administrator productivity.  Workflow Manager is the backing technology for SharePoint Workflows in SharePoint Server 2013 and the next version of Office 365, and SharePoint support has been a key focus for this first release of Workflow Manager.

The goal of this blog post is to guide you trough the process of installing the Workflow Manager 1.0. The process is quite straight forward, but there are some things that you need to know.

First step is to download the bits. You can download “WorkflowManager.exe” here. After the download, simply run the installer, and you should see Web Platform Installer popping up. Be sure that you log in with an Administrator account, otherwise, you will get some nice errors!

Note: You can install this on the SharePoint server, or you could use a separate server to host your workflows. In this example, I used my SharePoint 2013 server. Click next to install and follow the wizard:

Click “Continue” to start the configuration

Enter your SQL Server instance and a service account. I created a “WF_Service” account on my AD. Be sure that you also enter a Certificate Generation Key. You also may not forget to select “Allow Workflow management over HTTP on this computer“.

That’s it for the installation. Next step is the “Configuration“. In my case, I want to be able to create workflows on my Project Server 2013 instance, which is a Site Collection located at the url “http://ps2013lab/PWA“. I need to link this to the Workflow Host (which I’ve just installed). In my case, I want to use it with HTTP (instead of HTTPS), so the port of my workflow host is located at 12291 (you can see this on the summary screen of the installation).

You can also open the Workflow (or SharePoint) PowerShell console and type “Get-WFFarm“. This will show you all settings, including the ports that are being used.

So, we have all our settings. We now need to execute a PowerShell command “Register-SPWorkflowService” on the SharePoint server. You need to add the argument “SPSite” and “WorkflowHostUri“. In my case:

Note 1: This command will return nothing. It’s a silent command meaning that you have no process of whether the command worked, or when the process has been finished.
Note 2: If you installed the workflow manager on another server than the SharePoint server, you need to download and install the Workflow Client on the SharePoint server. You can download this here.

To check if your “Register” action is completed, you can go to the “Central Administration -> Service applications -> Workflow Service Application Proxy“. You should see:

Now the final test, just open SharePoint designer, connect to your Site Collection, and you should be able to create a new Workflow (Project Server 2013 in my case)

That’s it! Good luck with your Workflows!

Debugging Apps for SharePoint Online on a non-development site collection

In a previous post, I was talking about how you can use Project Server Online data in a SharePoint 2013 App using CSOM. One thing I was talking about was the fact that you cannot debug an application when you’re not using a development site collection. You will see this nice error:

Eli Sheldon (Program Manager at Microsoft) gave me this explanation (Thanks!):

SharePoint added a site collection level feature near RTM that, once enabled, will allow you to F5 deploy from VisualStudio, no matter what type of site collection you are targeting. Until the new bits roll online and this is documented, your best option here is to F5 debug on-prem and publish an app package and use the corporate catalog to test online.

Well, good news, SharePoint (online) is RTM (since a few weeks). Let’s find out how we can debug our SharePoint app on a non-development site. The reason why I really want to this, is because I have a Project Online App which requires a site collection where PWA (Project Web Access) is activated. Development sites cannot be created with an Active PWA.
I was hoping to see an option in the O365 SharePoint admin center where I could activate this ‘feature’. But unfortunately, there isn’t, or at least I couldn’t find it. So, the next thing I did was opening the solution of my previously created app, and hit F5 debug it. Note: be sure to install the latest version of the Office tools for Visual Studio 2012. As a result F5’ing my solution, I had this error:
So that’s a no-go, because “sideloading of apps is not enabled on this site“. After some research on the MSDN forums, I found a PowerShell script allowing you to enable Sideloading.  Because it’s not available in the interface, the only option you have is to run the PowerShell script to enable this feature. (There is not quite much information about this Sideloading thing yet though).
The first thing you have to do is download the SharePoint Online management Shell (link). The PowerShell script you can use is:
All you need to do is enter you site name, your username and your password. You will get:
That’s it. Now you can F5 your App, and it will be deployed and will also be debuggable on a non-development site, or in my case a PWA site collection. A small app that will load all Projects from my Project Site collection. Nothing fancy, just an example. Have fun!

How to use Project Server Online data in a SharePoint 2013 App using CSOM

This week I was attending the 3 day Project Ignite training. This is a technical training offered directly from Microsoft and was presented by Christophe Fiessinger and Jan Kalis at Warsaw (but I followed the training on Lync, which was really cool using the 360-video). I learned lots of new and interesting things about Project Server 2013 and Project Online. Thanks Christophe and Jan!

Of Course, that’s not the topic of this blog post. During the last day of the training, we got some information about the extensibility options for Project Server 2013. One of the topics was about CSOM, which is an abbreviation for Client-Side Object Model, and also about JSOM, which stands for Javascript Object Model. Let me use the slide from Project Ignite explaining what it is all about:

As you can see, an interesting topic to do some deep diving and (as Christophe told us to) doing our homework. I’ll guide you through the process of creating:

  1. A console application, connecting to my local Project Server 2013 lab machine and create a project.
  2. A SharePoint Autohosted app (based on my previous blogpost: Windows Azure auto-provisioned apps for SharePoint 2013), connecting my Project Online PWA instance using OAuth 2.0 and retrieving a list of projects.

1. Local Console Application

To start, I will create a small piece of code to create a project on my local Project Server 2013 lab machine. So no SharePoint app, no authentication, just creating a project using CSOM. To start, open your Visual Studio 2012 and create a new Console Application. The first thing you have to do with this empty console project is referencing 3 DLL’s. If you’re developing on a machine with Project Server 2013 installed, you can add a reference directly, otherwise you need to copy the 3 DLL’s to your development machine (create an ‘Assemblies’ folder in your project) and reference them this way. The 3 DLL’s you need can be found in the folder “%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\ “. Copy those items:
  1. Microsoft.ProjectServer.Client.dll
  2. Microsoft.SharePoint.Client.dll
  3. Microsoft.SharePoint.Client.Runtime.dll

Reference them in your project and open ‘Program.cs’. Add the code, listed here, to your application. I’m not going to repeat every piece of code, as it’s explained very well on that link. But what I want to mention is ‘security’. If you run your SharePoint/Project Server 2013 dev environment, and you develop your application on another machine, you need to provide credentials to connect to SharePoint/Project Server, in fact, you need to initialize the ProjectContext with those credentials. The ProjectContext contains the client-side context for development with a Project Web App instance, and contains the enterprise-wide collections of Project Server objects that exist in Project Web App. You can get the ProjectContext using your credentials with the following quick and dirty solution:

If you run the application (after you added the following command to the start-options of your project: -n “Test Project using CSOM 01” -t 20) , you should see:
In general, it’s all about the ProjectContext. Using this context, you can do/get whatever information you want. In this case, a new Project is created using the object ‘ProjectCreationInformation’, this object is added to the ‘projContext.Projects‘ and finally you tell the context to update with this new project. This will create a queue job and will perform the required action. That was easy to do!


2. SharePoint Autohosted App

In this part, I will create a SharePoint Autohosted App where I will use the CSOM to retrieve a list of all projects. You can find a step-by-step guide in one of my previous posts. What you will need  is a subscription of Project Online Preview  (of course). If you haven’t got a  subscription yet, you should really try it out (more info can be found in this post). The first step is to create a new “App for SharePoint 2013” project using Visual Studio:
On the next screen, you should enter the URL of development site (note: when you want to debug Apps on SharePoint Online, you need to have a site collection created as ‘Development site’ type. Otherwise, you will receive an error while publishing in debug mode). This option does have an impact when you want to try debug apps for Project Server (using PWA), but more about that later.
No you have an empty SharePoint App. In our case, we want to use this app to get a list of projects stored on our online PWA. If you look at the files in your project, you will see a file called ‘TokenHelper.cs‘. This is a file responsible for the OAuth 2.0 authentication of your application with SharePoint. It includes the code to handle OAuth 2.0 authentication and how to perform callbacks to SharePoint using CSOM. More information about SharePoint 2013 authentication can be found here.
This TokenHelper class is used to get a SharePoint ClientContext, like you can see in the code below. The TokenHelper returns an authenticated instance of the ClientContext, which is the CSOM you can use to create some cool things.
This is great for SharePoint, but we need something different, we need a ProjectContext. This ProjectContext object inherits from ClientContext in SharePoint,  so you can also access the SharePoint CSOM through this ProjectContext object. To get this context, we need to change some small things to the TokenHelper class. Create the following 2 new functions in TokenHelper.cs
Now we have can get our ProjectContext using the “GetProjectContextWithContextToken” function. We can use the following code just to output the list of Projects:
What it basically does is loading the Projects into the ProjectContext and execute the query to get the results. Ok, now that you have the code, you should manage the permissions of the App. Because will we ‘read’ data from Project Server, we will need this permission to be able to actually read the data. The permission configuration settings can be found in the AppManifest.XML. You can find this file in your Solution Explorer. When you open this file, Visual Studio will show you an editor where one of the option is about permissions. Add the permission ‘Projects Read’ to this list and save the file:
Allright, we have the code and the permissions for our App are set. The next thing is, how can we debug this app? Well, remember when you created the project. We’ve added the URL to our Development site on SharePoint online environment. This development site is a seperate Site Collection. The first problem with that is the fact that this Site Collection does not contain a PWA instance. So if we debug our current application, we will never get data. The second problem is about the permissions. When you try to debug the application, it will check the permission settings. Because we created a permission ‘Projects Read’, we will always get an access denied error, simply because there is no PWA there. So, debugging the application on a Development Site Collection will give you:
You could also try to debug it directly on the PWA site (by changing the debug URL), but then you get this error when debugging:
I passed the question about this to Christophe, and he forwared my question to Eli Sheldon (Program Manager at Microsoft). He gave me this explanation (Thanks!):

SharePoint added a site collection level feature near RTM that, once enabled, will allow you to F5 deploy from VisualStudio, no matter what type of site collection you are targeting. Until the new bits roll online and this is documented, your best option here is to F5 debug on-prem and publish an app package and use the corporate catalog to test online.

So as you can see, currently no F5 debug with this release. But the RTM is coming really soon! (Should be there around mid November for MSDN subscribers). So for now, just publish the App and install it on our Project Server Online environment.  Right-click on your project containing the AppManifest file and select ‘Publish‘. You will get this dialog:
Click finish, and the output folder of your .APP file should open. Now we should ‘upload‘ it to our SharePoint Online environment, and make it available for the users. The place where App’s are managed is called the “App Catalog“. This app catalog is a separate Site Collection, and can be created using the SharePoint Administration Center. There you can click on ‘Apps – App Catalog‘. If you haven’t created one yet, it will create one for your, and otherwise, you will be redirected to the App Catalog itself. On your App Catalog site, click on ‘Apps for SharePoint‘ (on the left side). You will see an overview of all installed apps, including an indication of the licenses you still have available. To add your App, click ‘New Item‘ or drag and drop your .app file to the top area of this page.

Now you have your new Application available in the App Catalog. To use it, just go to Project Server Online PWA. Go to ‘Site Contents‘ on the left side, and click on ‘Add an App‘. There you should see the application we’ve just uploaded. Click the App, and you should get a question to confirm the required permissions. In our case, reading Project data. Trust this and continue. When the process is ready, your application is installed on your site, and you’re ready to use it. Click on the App, and you should see:

That’s a list of your projects, retrieved by the ProjectContext (CSOM). Nothing fancy, no HTML, just plain text. Cool! Now it’s up to you to use the CSOM and create some great apps! I’m really excited about this way creating apps, the way CSOM works, the flexibility, the (future) debugging.


3. The things we learned 

  1. You can do lots of things with the ProjectContext
  2. Don’t forget to setup your Permissions in the AppManifest file
  3. You can’t debug until RTM

Thanks to my colleague Koen Callens for the fun experience of creating our first App together! Thanks for reading, and enjoy creating your Project Server apps!

Upgrading the TFS 2010 and Project Server 2010 Integration Virtual Machine to TFS 2012

For a demo I’ll be presenting at a customer, It should be awesome if I could show the integration between Project Server and TFS with a brand new TFS 2012 installation. For the reason of that, I decided to upgrade my existing demo Virtual Machine provided by Microsoft (download). In this blog post, I would like to show you how the upgrade process looks like. Be aware, it’s a screenshot-intensive post today!

Ok, let’s go. The demo Virtual Machine from Microsoft has TFS 2010 and Project 2010 installed, combined with the integration pack to synchronize data between Project Server and Team Foundation Server. So the first thing we have to do is get rid of TFS 2010. On your Control Panel, uninstall TFS 2010.

When the uninstall is ready, you have to uninstall the TFS and Project Server integration pack.

That was an easy job! What we have to do now is an upgrade of SQL Server 2008 R2. TFS 2012 requires at least SQL Server 2008 R2 SP1 CU1. But let’s install the latest bits: SQL Server 2008 R2 SP2, which you can download here. Start and complete the upgrade process. (This step will take some time, especially on a VM)

Next step of the process is to install Team Foundation Server 2012 (which you can get from your MSDN subscription, or a Trial version). Launch the installer and run the installation.

When the installation is done (after a reboot, caused by the .NET 4.5 Framework), the Team Foundation Server Configuration Center will pop up. Select the ‘Upgrade‘ option:

On the welcome screen, click ‘next‘ to go to the ‘Databases‘ section. Click on the blue link ‘List Available Databases‘. This should list your TFS 2010 configuration database. Select the check box on the bottom, and click ‘Next’.

Continue the wizard, and configure SharePoint for use with TFS and use the current settings:

Run the ‘Readiness Checks’ and perform the upgrade. The outcome should be a list of green checks.

Now we have our TFS 2012 instance up and running. The next step is to install the new TFS 2012 – Project Server 2010 integration pack. You can install this using the same installation media from TFS 2012, as the integration pack is now delivered together with TFS 2012. So no extra package to download (which required an MSDN subscription). You can find the installer in the folder ‘Project Server Extensions‘.

The installation will only take a small amount of time.

The last thing you can do now is perform an installation of Visual Studio 2012, so you can make use of all the new and great functionality from TFS 2012.

Voila.. That’s it, nothing more, nothing less. It was quite an easy job to perform this upgrade. If you open your Visual Studio 2012 instance, you can connect to TFS 2012, and you should see the ‘Project Server’ section on each Work Item form. Have fun!


Install Project Server 2013 with PowerShell

Last week, I was working on my demo environment to be used for some future presentations. When I was looking around on the great MSDN world to get some best practices related to a Project Server 2013 Preview installation, I came across a link called: “Install Project Server 2013 with Powershell” by Jime Cox. That sounds really cool, although is easy to memorize the steps to install Project Server through Central Admin after you have done it a few times, it’s more fun to automate this process and adjust it to your own needs. And that’s where the PowerShell part is rocking!

In this post, I want to provide my experience about the installation of Project Server 2013 Preview using the PowerShell script.

First thing you have to do is to perform the installation of Project Server 2013 on a SharePoint 2013 server. You have to perform this step on each application server of your SharePoint farm. You can download Project Server 2013 preview from this link. Once the download has completed, run the setup. First thing you have to do is provide your key (which is available from the link):

Next step is to click ‘Install Now’. This will start the actual installation.

When the installation is ready, it will ask to ‘Run the SharePoint Products Configuration Wizard’. Leave the check box active, and click ‘Close‘.

On the SharePoint Products Configuration Wizard, follow the steps of the wizard, and use the default settings:

Connect to your existing SharePoint Farm, and continue the configuration:

Ok, now that we have installed Project Server 2013. It’s time to ‘activate’ and ‘configure’ it. We will use PowerShell to help us with this task. You can download the script from this link. This is how the script is constructed:

Personally, I really love PowerShell when you execute it with the PowerShell ISE (Integrated Scripting Environment). This way, you can debug and re-factor your scripts very quickly. First part of the script is required if you run the script directly from the PowerShell ISE. What it does is loading the required SharePoint functions into your PowerShell session. If you run the script directly from the SharePoint PowerShell command line tool, you don’t need to do this.

NOTE: You need to execute the scripts with your Farm Admin account. This way, you will never get permission errors!

Next part is the definition of the variables. They contain the URL’s, accounts, your SQL server,..

Next part checks of the SharePoint 2013 timer service is running. If not, it starts this service

In this next part, the Project Server Application Service is checked. If you did not install Project Server on your SharePoint Application server(s), this should result in an error. If the Service Instance is not online yet, the script will try to start it.

Now the fun part. In this step, we will create an Application Pool and a Web App. The FarmAdmin account is used as Application Pool Account. The second part of this piece will create a web application, using the application pool we’ve just create. It will also create a Content Database.

Now we will create the Project Service Application. It will use the Project Application Pool from the last step.

Next step is to create the actual Project Server Database. Note that in Project Server 2013, there is only one database, related to Project Server 2010 who has multiple databases.

In this step, we will create a new Site Collection for PWA, and enable the Project Web App site collection features

To create a Project Web App in an existing site collection, you run the  Windows PowerShell cmdlet to create the web and then run the Upgrade-SPProjectWebInstance to perform post-provisioning actions, including creating a Business Intelligence Center.

When you executed all those steps, you should have your PWA up and running.

Have fun!