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.

deploy01

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:

deploy02

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:

deploy03

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!)

deploy04

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.

deploy05

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 portal.microsoftonline.com login (user@account.onmicrosoft.com). 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

deploy06

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:

deploy08

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“.

deploy09

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

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 o365apps.net 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.

Iis7

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.