Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

Offline SharePoint 2013 Prerequisites installation on Windows Server 2012

When I was at a customer recently, I had that nice situation of a Windows Server 2012 without an active internet connection. Before you can install SharePoint 2013, you need to execute the “prerequisiteinstaller.exe”. The only problem with this is the fact that you do need to have an internet connection. A while ago, I made a similar post like this one about “Installing SharePoint 2010 prerequisites offline“. In this post, I will guide you trough a very easy way to get your SharePoint 2013 prerequisites installed on a Windows Server 2012. First of all, the problem you will have is:

02

To solution is quite easy. All you have to download are the PowerShell files provided by Craig Lussier, which you can download from TechNet (where you also have a detailed description of the PowerShell files).

Download the files

First step is to download all the required files from a machine with an active internet connection. Create folder on your machine like “C:\SP2013Prerequisites”. Next, open a PowerShell prompt, and execute the file “Download-SP2013PreReqFiles.ps1“. The script will now ask you where to save the downloads. Provide the folder you just created. When the downloads are ready, you should see:

01

Install the files

Second part is to install the files. First, you need to get the SharePoint 2013 installation media files on a local directory. When you have the SharePoint 2013 Server IMG file, you can double-click to mount it to your machine. Once mounted, you can copy this to a local folder like “C:\SP2013”. When you have a SharePoint Foundation 2013 installation file (in the form of an exe), you can also unpack it using the command:

Next:

  1. Copy the downloaded Prerequisite files into the “c:\SP2013\prerequisiteinstallerfiles” directory of your Windows Server 2012 server.
  2. Run PowerShell as Administrator (right click on the PowerShell Tile and select “Run as Administrator“)
  3. Run the script “Install-SP2013PreReqFiles.ps1“. When you run this on a fresh Windows Server 2012, you will receive the following error. You can fix this by changing the “Execution Policy” to “RemoteSigned

03

Try again, and you should now get a question where the SharePoint 2013 installation files are stored. Provide the path and press enter. the SharePoint 2013 Product Preparation Tool will now popup. (in fact, the PowerShell script did a call to “prerequisiteinstaller.exe” including the path to the downloaded components). Click next until the server needs a reboot. This reboot is required because the installer will change/add some Windows Server 2012 features.

04

When your server is up and running again, it will pop-up the Product Preparation tool again. Just cancel it! You need to execute the previous Powershell script again. So run the script “Install-SP2013PreReqFiles.ps1” and provide the path to the installation media. It will now install the other prerequisites and finally require one last restart.

05

That’s it! Ready for the SharePoint 2013 installation, but just one more thing:

You can of course download the components individually, and install them manually by executing each installer one by one. This will work just find, except one component: Windows Server AppFabric. You really need to get it installed using the Product Preparation tool (via PowerShell), otherwise you will get a nice error that AppFabric is not installed correctly to be used with sharePoint. Been there! If you want to install AppFabric manually, you can use : “prerequisiteinstaller.exe /AppFabric:prerequisiteinstallerfiles\WindowsServerAppFabricSetup_x64”. This way, it will install correctly

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

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.

20

  • 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:

packagetarget

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

package01

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!

denied

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.

workflow

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

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

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!

Solved: SkyDrive Pro does not sync anymore

In July, Sharepoint 2013 was announce together with some other great things like Office 2013, Project Server 2013, Lync 2013, … But there was also a (beta) release of a small tool called ‘SkyDrive Pro’. Let me first introduce you to this tool.

SkyDrive Pro is a document storage service that organizations provision and manage for their users. It will be available as a service together with many Office 365 plans, and on-premises with the new version of SharePoint.

Like its consumer counterpart, SkyDrive Pro enables people to synchronize their work documents from SharePoint to the cloud, and also take documents offline when they’re on the go. People can access or edit their documents across devices; files are automatically synchronized with SkyDrive Pro when connected online.

After SkyDrive Pro is set up, you can save documents directly to SkyDrive Pro from Office desktop applications, or synchronize them directly from SharePoint.

In fact, SkyDrive pro is the replacement of the SharePoint 2010 ‘Workspace’ and it also integrates very well with Windows Explorer. That being said, SkyDrive Pro should also be able to sync SharePoint 2010 Document Libraries.  But for one or another reason, the current build of SkyDrive Pro had some problems to keep my SharePoint 2010 content synced.

I did a rename of my SharePoint folder located in my user directory, but that’s something SkyDrive Pro doesn’t really like (at least on my machine). The error I got was “An error occurred while attempting to synchronize this tool.”

I did some bing’ing and found some similar issues like mine. It seems like it is indeed a bug with the current build of SkyDrive Pro. As for now, the only solution is to clear the SkyDrive Pro cache, and re-sync your library. So you will lose all settings. To clear your cache, close all your Office processes like groove.exe (which is SkyDrive Pro), msouc.exe,  msosync.exe, office library sync,…

Browse to “C:\Users\%username%\AppData\Local\Microsoft\Office\Spw” and delete all the content. (you will see that this is all related to groove and spw = SharePoint Workspace). Next, go to “C:\Users\%username%\AppData\Local\Microsoft\Office\15.0\OfficeFileCache” and also delete all content from this folder. This is where all the caching from your files are stored.

After you deleted everything,  you should be able to start SkyDrive Pro again (using “C:\Program Files\Microsoft Office\Office15\GROOVE.EXE“). You can now start configuring your clean environment. Good luck!

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!