Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

Quick PowerShell note: Get available constructors

When you’re working with PowerShell, you occasionally will be using .Net types to create objects . One thing that I noticed is that it’s quite difficult to know the correct types of the arguments that you can pass to the different constructor methods. Some piece of PowerShell that I had was:

In that (small) example, I did a reflection of the XDT DLL, and I wanted to create an “XmlTransformation” object to do some XDT transformations (which is pretty cool, and recently release to NuGet btw!). In that case, I wanted to know what the available constructors are, and what arguments you can pass. If you do this with for example C#, you can just press F12, and that’s it. But not with PowerShell. After some google’ing bing’ing I found this little function:

All you have to do now is run this:

That’s pretty cool, that was exactly what I was looking for! Now I can create an object using:

Small, but useful. 

Deploying SharePoint 2013 Apps with TFS 2012

In this third part about SharePoint 2013 Apps with TFS 2012, I will talk about how you can deploy your package to your SharePoint 2013 (or SharePoint Online) instance. (Note that I’m using the “AutoHosted” App model) First you have to complete the steps described in my previous posts:

Assuming that this was no problem, you should have a build definition based on the “OfficeToolsAppTemplate” build process template (which you can download here). This should result in a build definition who will give you the following output:

completedbuildThat’s great. Now we want to deploy this App to our SharePoint instance. Good news, the build process template has everything available to achieve this. Once  you have downloaded this build process template, you also have a folder called “DeployScripts“. Add this folder (and the content of it) to Source Control like. That’s it for now.


SharePoint requirements

Before we can deploy this App package, you need to have a “developer site“. Normally will already have this, because if you deploy your App directly from Visual Studio, you will also need this. You will have a site collection like:


A thing I can advise you is using a “custom” deployment account. There reason for that is that this account is required to be “defined” in a PowerShell script (including that password). As  you can see in the previous screenshot, I have a user called “deploy” who is also an administrator of this development Site Collection.

On-prem Build Server requirements

On the Build Server, we will also need to verify some things. First of all, if you want to deploy to “SharePoint Online,” you need to have the SharePoint Online Management Shell installed. This will allow the deployment scripts to connect to your SharePoint online instance. You can easily test it using the “Connect-SPOService” command:


Next thing that  you need to check is the account your TFS Build Service is using. If you installed the TFS Build Server using the “next-next-wizard”, your TFS Build Service account will be using “NT AUTHORITY\LocalService“. If you keep this by default, and you try to deploy your App, you will see the following error (been there!)


You need to change this account to a known user account so the deployment script can import the SharePoint module. In my case, I’m using a standard Windows Server 2012 Azure VM, and I simply use the ‘Administrator” account.


Configuring the deployment

Almost there. If you look into the folder “DeployScripts”, you will find a PowerShell file called “Parameters.ps1“. In this file, you need to supply your credentials (like my “Deploy” user) and the site URL where you want your application to be deployed. If you’re deploying to SharePoint online, you do not need enter the “$SpDeployUserDomain“, just enter the login ( Save the changes, and check-in to Source Control.

Now we have to change the Build Definition so that it will execute a PowerShell Deployment script. Edit your Build Definition, and select the “Process” section. On the bottom section, there is a field where you can provide the deployment script. In our case, this is something like “$../DeployScripts/SharePointApp/SharePointAppDeploy.ps1


There you are. Save this Build Definition, and queue a new build. After a wile, you should see a nice green build, meaning that your App is deployed!

deploy07If you go to your developer site, you will see your App listed. Just click on it, and you will see this nice error:


Bummer! But no worries, that’s normal. Maybe you know, but if you deploy directly from within Visual Studio, you will be redirected to a page asking you “Do you trust this app?“. In the case of a Build Server deployment, there is no such a question, resulting in the error from above (note: by default, you will not see a detailed error, but I added “<customErrors mode=”Off” /> to my Web.Config”). To solve this error, you need to click on the “…” of your listed App, and select “Manage Permissions“.


If you now trust your App, you can enjoy playing with it! So if you change the Build Definition to “Continuous Integration”, you will have a “Continuous Deployment” system up and running! Have fun

Packaging SharePoint 2013 Apps with TFS 2012

In a previous post, I was talking about how you can build SharePoint 2013 apps using TFS 2012. In this post, I will guide you through the process of creating App packages using a TFS 2012 build. There are some small things that you need to know.

Required Components on your on-prem TFS build server

To start, you need two extra components on your build server, to be able to create App packages on the one hand, and Web Deploy packages on the other hand (if you’re creating an “Auto Hosted” or a “Provider Hosted App”).

  • The first component you need is Web Deploy V3, which you can download here.


  • Next, you need to copy paste the following folder from your local machine to your Build Server. “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web”. Otherwise you will get this nice error:


Hosted TFS Build Server, you can use it, now!

In my previous post, I mentioned that the Hosted TFS Build Server could not yet be used because the “Office 2013 and SharePoint 2013 Developer Tools” were not installed. Well, good news, now they are! You can make use of the Hosted TFS Build Server. This is an overview of the installed component on the hosted Build Server.

Creating App Packages

Previous versions of SharePoint have the notion of SharePoint Solution Packages (wsp). It was also possible to use TFS (2010) for creating these packages. You can find a nice how-to on this link. It all comes down to that one parameter called “/p:IsPackaging=true”. You need to pass this parameter to MSBuild.

Now with the new App model of SharePoint 2013, this behavior is identically. You also need to pass this parameter to MSBuild. To do this, create a new TFS Build Definition (like described in my previous post). On the “Process” part, check the “Build process parameters” and find the “MSBuild Arguments” on section “3.Advanced”. Add the parameter “/p:IsPackaging=true”.


Save the build definition and queue a new build (right-click on the definition, and select “Queue New Build…”. After a while, you will see that you have a nice red build. Yes indeed, build failed!


The problem is in fact a (small) bug on the TFS part of the build process. To create an App package, the AppManifest.xml my not be marked as ‘read-only’. Because we’re using TFS, files are marked as ‘read-only’ once they are downloaded to the Workspace. The reason for that is because the TFS 2012 build server uses ‘Server’ workspaces. Meaning that every file gets this annoying ‘read-only’ file attribute. Local workspaces, on the other hand do not behave like that, but a Build Server always use the server workspace.  (You can find a nice overview about the difference between Local and Server workspaces here). There are also reports that you can have the same behavior when you want to create an App package using Visual Studio. (Right-click on your project, and select ‘Deploy’). You will not have this issue when you’re using a local TFS workspace, as files will not be marked as “read-only” than.

Possible Solution

Unfortunately, there is no easy solution to fix this error, except a small modification to the Build Process Template. (There is an awesome guide available by the ALM Rangers to get you started, get it here). What you could do is make a copy of the ‘DefaultTemplate.11.1.xaml‘ file, and add an extra workflow activity to this template who will remove to ‘read-only‘ attribute from the AppManifest file.


The Real Solution

Now I see you thinking: nah, I really don’t like editing WF 4.5 XAML files. Well, good news, someone already created a Build Process Template with this modification. There is a nice Codeplex project called “Office / SharePoint 2013 Continuous Integration with TFS 2012“. There you can download a customized Build Process Template that can be used. All you have to do is adding this XAML file to the (for example) “BuildProcessTemplates” folder in Source Control, and change your Build Definition that it will use the new Build Process Template. So it looks like:

templateThat’s it. Just queue a build, and it should be green. (You also don’t really need to add the parameter “/p:IsPackaging=true” anymore, because this great Build Process Template will take care of this. But it’s also that smart that it will detect if you did pass the parameters, so no problem).

So for now, I talked about how you can actually build you SharePoint 2013 App project using TFS. In this post I described how you can produce an .APP package. In my next post, I will talk about how you can deploy your App. I will also make use of this Build Process Template from CodePlex,  because it’s already all in there!

Have fun!

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!

Windows Azure auto-provisioned apps for SharePoint 2013

I suppose you all heard about the “App” concept in SharePoint 2013? If not, you have a nice overview about this new concept on msdn. An app for SharePoint is a great way to surface a remote web application in SharePoint. In this post, I want to tell you a little bit more about Windows Azure auto-provisioned apps for SharePoint 2013.

Imagine this: Wouldn’t it be cool if you can deploy whatever custom web application with whatever server-code behind it, directly to your Office 365 instance? Well, using the Windows Azure auto-provisioned apps you can. First question you can ask yourself, what’s Windows Azure doing in this story and how does it link to your Office 365? Well, to get this working internally each Office 365 gets automatically an Azure account associated. That’s nice, and really powerful. Because you now have both Azure and Office 365 together, you don’t have any reasons or whatever to stick with your on-premise installation.

An auto-provisioned app contains at least one Windows Azure Web Site that can be launched from a SharePoint 2013 Preview host web, and may also include SharePoint components on an app web and a SQL Server database (based on SSDT and .dacpac packages).

Let’s take a look what the development and deployment process looks like:

  1. The developer builds a SharePoint application into in .APP file
  2. Deploy to SharePoint
  3. SharePoint installs the application for you
  4. SharePoint provisions all Azure components
  5. SharePoint provisions the SQL Azure database and initializes everything included in the .dacpac (Data-tier Application Component Package)

So in general, you create an application, publish it to SharePoint, and SharePoint will do everything for you. So creating an Azure Website, manage your database on SQL Azure and initialize everything.

Let’s try it out. First you have to create a new SharePoint project in Visual Studio 2012. Open Visual Studio and click ‘File –  New Project‘. In the ‘new project‘ window, select ‘Visual C# – Office/SharePoint – Apps‘ and select the ‘App for SharePoint 2013‘ template. Give your project a name and click ‘Ok

Note: If you have never created a SharePoint/Office 2013 app before, you will not find the Project Template in Visual Studio 2012. You need to install the Microsoft Office Developer Tools for Visual Studio 2012. You can download this here. It will start WebMatrix and download all the required components you need.

On the next screen, enter the name of the application, and the URL of your development site. I used my SharePoint Online subscription for this. Be sure to use a ‘Development Site‘, otherwise you will get an error when you try to test your application. (been there, done that!). If you don’t have a development site, create a new one and use the ‘Development’ template when creating. That will do the trick. Ok, in the current window, also be sure to select  and choose “Autohosted”.

When you click ‘Finish’, your project will be created. Basically, it will create a solution with 2 projects. The first project contains an AppManifest file, and the second project is a simple ASP.NET application.

The AppManiFest file is the definition of your SharePoint application. It contains a title, a name, which (tile) icon it uses, what the start page is, which permission requests it need to run (for example accessing  User Profile information),… The ASP.NET application itself is really basic, but one thing to notice is the file ‘TokenHelper.cs‘. This is a file who is responsible for the OAuth 2.0 authentication of your application with SharePoint. This helper class is used in Default.aspx. It includes sample code about how to handle OAuth 2.0 authentication and how to perform callbacks to SharePoint using CSOM.

In this example, we won’t change anything and just continue and get our application up and running. All you have to do is click on ‘Debug‘, or just press ‘F5‘.

In the output console of Visual Studio, you will see that the SharePoint application will be uploaded to SharePoint, and that SharePoint will do the necessary things to install it. Note that your App is NOT provisioned on Azure yet. If the installation was successful, your browser will be opened and will ask you to do a login and it will now ask you: “Do you trust your application”? Click ‘Trust it

You will now have your application listed as an item in the ‘Site Contents‘.  Click on your application and you will get a certificate error. If you look good to the URL of your application you will see ‘http://localhost:xxxx’. What SharePoint did was an installation, and during the installation, the application URL was set to your localhost environment. Indeed, if you look on that taskbar of your machine, Visual Studio started an IISExpress with the same port as the one SharePoint redirects you to. Just ignore the certification error and continue.

What you see now is not quite much. What this example basically does is using the ‘SPHostUrl‘ parameter that is added to the URL when SharePoint opens your application. Using this parameter, the application will get an access token (using OAuth 2.0) and use this token to get a client context object. This object can load the title of the SharePoint site you’re using. Because your app is hosted locally using IISExpress, you can easily debug it.

Ok, let’s assume that our application is ready to be deployed. We can use Visual Studio to deploy our application. Right-click on your project containing the AppManifest file and select ‘Deploy‘. It will now execute the same process as before (as you can see in the Visual Studio Output window). When your application is installed, trust it, and click on the Application icon to open it.

As you can see now, the URL is not on localhost anymore, but it got a unique URL. So our application has been deployed to Windows Azure, awesome!

Of course, we’re still in development. But let’s say that everything is good, tests are written and the application is ready to go live, how can you do this? Well, we first need to create an ‘APP’ package of our application. In Visual Studio, 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. In fact, an APP file is nothing more that a zip file (you can open it with 7Zip for example), containing all your artifacts. A bit like the WSP files.

Ok, so we have our APP file. Now we should ‘upload‘ it to our SharePoint farm, and make it possible for users to select this application on their site. The place where App’s can be 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.

Adding an App to the catalog is really simple. 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

It will open a new dialog where you can select your .App file and give it a version comment. Click ‘OK‘ to continue. The next dialog gives you an overview of everything related to your application. Complete this as you want, and click ‘Save

Now you have your new Application available in the App Catalog. To use it, just go to a site where you want to use the application. On this site, go to ‘Site Contents‘ on the left side, and click on ‘Add an App‘. Look what you see there, the application we’ve just uploaded:

Click the App, trust it, and your application will be provisioned by SharePoint. When this 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:

The text displayed is the name of my site, which is ‘Ideation’, and you also see a unique ID in the URL = a unique Windows Azure website. (Note the ‘Website’ part of the name).

So that’s it. We have our SharePoint app up and running on Windows Azure. Great! One thing that’s really important to know: each ‘installation’ of our App will provision a new Windows Azure Website. So this will be a part of your billing/account, don’t forget that.

To finish this post, I’ll give you 2 reasons to use this approach:

  1. When you deploy an autohosted app for SharePoint, all Windows Azure and SQL Azure components are provisioned for you when the app for SharePoint is installed.
  2. The Windows Azure Web Sites infrastructure handles load balancing, multi-tenancy, and other important maintenance tasks for you.

Thanks for reading!

Automatic IIS7 Deployment using MSDeploy and AppCmd

In this blogpost, I will tell you a little bit more about how to deploy your web application to IIS using MSDeploy and AppCmd. I’ll give you some information about how to create a .bat file with all the parameters you will need create a new IIS entry for your application and sync your files using MSDeploy.


First of all, what is MSDeploy.exe aka WebDeploy? Well, MSDeploy is a server technology that enables a publishing and deployment mechanism. It enables you to not only publish files, but also create database schemas, run database change scripts, set security and much more. If you want to know more about how to install webdeploy on IIS, just take a look at the great blogpost of Scott Guthrie. 

The other tool we use is AppCmd.exe. This is the single command line tool for managing IIS 7. It exposes all key server management functionality through a set of intuitive management objects that can be manipulated from the command line or from scripts. AppCmd.exe enables you to easily control the server without using a graphical administration tool and to quickly automate server management tasks without writing code. More information can be found here.


Allright, What we gonna do?

  • Create new IIS site
  • Assign an application pool
  • Add HTTP binding
  • Add HTTPS binding
  • Set require SSL
  • Enable custom error mode
  • Set HTTP to HTTPS redirect
  • Sync the files from the source to the new site using msdeploy
  • Set ACL on a specifc folder


Step 1: Create a new batch file called f.ex. ‘NewSite.bat’. On top of it, define your application variables which will be passed trough the commandline to the batch file


Step 2: Create a new batch file called f.ex. “PreSync.bat” where you define the AppCmd commands to perform the first 7 steps from the list above


Step 3: Continue in the ‘NewSite.bat’ file – As we want the ‘PreSync.bat’ have the correct parameters, we generate a new .bat file called ‘PreSyncGenerated.bat’. First we remove any existing files called like that, and create a new one with the correct parameters.


Step 4: Still in the ‘NewSite.bat’, find the MSDeploy.exe location and check if MSDeploy.exe exists


Step 5: Sync your application sources using MSDeply.exe. We use MSDeploy.exe to execute the AppCmd commands in the generated .bat file. Note that we skip some files and directories that we don’t want to be affected


Step 6: Add modify rights to a folder (in our case ‘AppData’) using MSDeploy.exe. The permission will be assigned to the ‘networkservice’


That’s it.. What we’ve done now is create three batch files. One called ‘NewSite.bat’ which handles the MSDeploy.exe, the second one is PreSync.bat which handles the AppCmd.exe command and a latest one which is generated from the previous file and contains the correct parameters.

Now you can just run the ‘NewSite.bat’ file using commandline with the correct parameters, and your site should be deployed on IIS. Also all files are synced from the source to the destination.


I hope you enjoyed this post! If you have any questions, just post a comment and I’ll be in touch.