Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

Debugging SharePoint 2013 remote events using the Windows Azure Service Bus

In this post, I will talk about how you can debug remote events within a SharePoint 2013 App. Especially with the Autohosted App Model (I made a post about that a while ago). Let me first start with a small and really easy to understand app that I will use to highlight the topic of this post.

The App

It’s quite an easy app where you can:

  • Add a contact
  • Get a contact

The App has some logic in the Web project (to manage the button “Add Contact” and “Get Contacts“), and a “List” in the SharePoint project. You will find the sources at the bottom of this post. When running this App, you will see something like:

03

As you can see, the “FullName” contains the text “Not set!“. That’s correct, I only provided my first and last name. But I want my full name to be “managed” by a remote service. And that’s where this post is all about. Finally! What I want is a remote event receiver that will be triggered when a new contact has been added. Add one to the SharePoint project. Right-Click and select “Add – New – Remote Event Receiver”. Call it “Contact List“. You need to select the type of event on which the event receiver needs to do something. Select “An item was added“.

02

You will now see a new folder in the Web Project called “Services“‘ and a new service called “ContactList.svc“. When you open it, you should see 2 methods. The one we need is called “ProcessOneWayEvent“. You can add the following code:

What it actually will do is get the ClientContext and get my first and last name that I submitted. It will than perform a string merge and add it to the “FullName” of the ListItem. Nothing fancy. So, why don’t we just hit F5 and check it out? You will soon find out that it will not work, the service is not being called. You can try to add a breakpoint, and you will see that it will be ignored. But why?

Problem

The problem is quite easy to understand. What will happen when you press F5 is a “Publish” of your App to SharePoint online, and once you “Trust” the App will eventually loop back to your “Local IIS”  (as you can see in the URL of the screenshot at the beginning of this post). It looks like:

problem1

So our Web project is running locally, meaning that our web service is also running locally. So in our case, when we hit the button “Add Contact“, it will try to call our Remote Event Receiver. So from a  SPAppWeb (which is SharePoint Online) context, it will not be able to contact “Localhost“. It looks like:

problem2

Solution: Windows Azure Service Bus

In the final “RTM” version of Office Developer Tools for Visual Studio 2012 there is cool feature called “Enable Remote Event Debugging“, making use of the Windows Azure Service Bus. Now first of all, what’s that Azure Service bus? Let me take the description from MSDN:

The Windows Azure Service Bus provides a hosted, secure, and widely available infrastructure for widespread communication, large-scale event distribution, naming, and service publishing. The Service Bus provides connectivity options for Windows Communication Foundation (WCF) and other service endpoints – including REST endpoints — that would otherwise be difficult or impossible to reach. Endpoints can be located behind network address translation (NAT) boundaries, or bound to frequently-changing, dynamically-assigned IP addresses, or both.

In other words, the Windows Azure Service Bus allows you to expose our local WCF service to the “outside world”. And that’s exactly what we need! All you have to do is get yourself a Service Bus instance and enable this feature in the SharePoint App project properties. You can get a Windows Azure Service Bus  instance using the Windows Azure Management Portal. On the left side, click on “Service Bus” and click on the “Add” sign on the bottom of the page. Add a name, and finish the wizard.

06When your service has been created, all you have to do is click on the “Access Key” button and copy the connection string. Next, right-click on your SharePoint App project in Visual Studio and select “SharePoint“. There you can “Enable Remote Event Debugging“:

08

Now you can add a breakpoint in your service code and press F5. There you go:

09And if you look at the App itself, you will see that the “FullName” has a value:

10

Mission accomplished! You can download the sources here. Have fun! Oh, and just a small note, did you know that you can actually see which services are available/active on you Windows Azure Service Bus? Just browse to the URL of your service bus, and you should see:

04

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

Get your populated Office 365 demo environment

Did you know that, as a Microsoft Partner, you can get a free demonstration environment and some guide materials for the new Office and Office 2013 without requiring a full installation locally? Well, I didn’t until James Akrigg (@jakrigg) posted the following tweet:

tweet

Curious as I am, I wanted my own demo environment. As I have a partner login associated with my Live ID, I decided to give it a go. Point your browser to https://www.microsoftofficedemos.com/ and click on the ‘Microsoft Partner’ link. You have to provide your credentials to continue. Once you’re successfully logged in, you will see some information about this offer, but the most import things are:

  • Subscription includes an Office 365 Enterprise SKU trial tenant (note: this tenant is subject to trial restrictions, including a 30-day expiration)
  • Subscription includes an Office Enterprise Hero Demo guide which provides talking script and clicking guidelines

That’s great, let’s create one. Click on the “Create Demo” link on top of the page. You will now see the options of the demo environment like the type of Office 365 Tenant, the demo content and the demo language. As for now, it looks like you cannot change the options. I guess that there will be some more options available in the future.

02Click on “Create Your Demo”. You can now enter a tenant name and type the correct robot number.

03Once you click on “Create My Account”, you will see the provision status of your tenant. Something like:

01

That’s all you have to do. If you read the questions from the FAQ section, you will see that the process will take 8 to 36 hours, depending on service availability. You will receive a completion email when the content provisioning process has been completed. You can easily check the status of your tenant by entering your tenant name in the ‘Domain’ box. (Or use the link in the email did receive after you registered your demo instance.

Having a demo environment is one thing, showing the new goodies are another thing. That’s where the demo guides and documents come in. You can find an impressive list of guidance documents by clicking on the “Resources” link on top of the page.

Small note: You can login using the following two credentials: KatieJ@tenant.onmicrosoft.com and RobinC@tenant.onmicrosoft.com

Thanks to the Office team for making this available!

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!

Building SharePoint 2013 Apps with TFS 2012

In this post, I want to talk a little bit more about how you can build those shiny new SharePoint 2013 Apps using a TFS 2012 build server, but especially: without installing Visual Studio! To start, I will shortly guide you trough the process of setting up a TFS Build Server (with 1 controller and 1 agent).

You might be wondering, why do you setup a separate TFS Build Server? Why don’t you just use the Hosted TFS Build Server? Well, that was also my intake, but it just doesn’t work (yet). The Hosted Build Server does not have the “Office 2013 and SharePoint 2013 Developer Tools” on it, so it’s not able to build SharePoint 2013 apps. So for now, a separate server will do the trick.

TFS 2012 Build Server

Let me start with a quick overview of how to setup a TFS 2012 build server. In my scenario, I’m using a fresh Azure-hosted Windows Server 2012 VM. Fast and easy setup. Download the TFS 2012.1 installer and start the ‘Build Service Configuration Wizard’:

01The next step is connecting to your TFS Team Project Collection, which is a TFS Service (VisualStudio.com) instance.

02The next few steps are just a ‘next-next-next‘ experience, use the default settings as they are provided. Once you’re ready, you should see that it has one controller and one agent connected to your TFS Server.

08

CI Build Definition

Now comes the tricky part, how can be build SharePoint 2013 Apps without installing a full-blown Visual Studio 2013? Which components do you need? Well, we’ll start by creating a Windows Azure Auto Provisioned App like I’ve described in another post. Once you have this app, add it to Source Control, and perform a check-in.

Next step is to create a build definition which will perform a continuous integration build of our app. Using Visual Studio, go the the ‘Builds‘ section of Team Explorer, and click ‘Create New Build Definition‘. Give it a name and select ‘Continuous Integration‘ as trigger.

ci1

On the ‘Build Defaults‘ section, select the Build Controller we’ve just created, and define where you want the drop output  to be stored. I will just use a drop folder in Source Control (which is a new feature in TFS 2012).

ci2On the process section, select the solution file, and leave the other settings by default. That’s it for the build. To try, just queue the build manually, and you should see a nice failing build. That’s completely normal of course, as we didn’t install any build-related things on the build server yet:

error

Required components

Now that we have the build, we need to make the necessary changes on the build server (where the actual Build Agent service is running). Install the following components in the right order:

That’s a tricky one. It will start the web platform installer, and it will give you this error:

10

That’s correct, we don’t have Visual Studio installed, and that’s exactly what I don’t want! But when you click OK two times, you will a nice overview of all components required:

11

We can now use the Direct Download links provided to install the required components:

When installing this, you’ll get another nice warning about the ‘Microsoft Web Developer Tools’. Just click ‘Continue

13

There we go, another nice screen telling me that I need the Windows Identity Foundation Runtime.

16

My build server is a Windows Server 2012 machine, and there you can ‘enable’ the WIF runtime as a feature on that machine. When you enabled this, just retry the setup of the WIF SDK.

17

Almost there! If you queue a build now, you will see the following nice error:

error2Correct, that piece is missing on the build server. To solve this, all you can do is ‘copy‘ the folder ‘C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications‘ from your development machine to the Build Server (on the exact same location). That should do the trick! If you now queue your build, you will get:

buildokThat’s it, you have your SharePoint 2013 building on clean, fresh Build Server without installing a full-blown Visual Studio 2012. It was quite a challenge, but thanks to Xavier Decoster and some research I managed to get this thing working!

In a next post, I will explain you how to build an APP package with the TFS Build Server. It’s not that simple as just adding “/p:IsPackaging=True” as extra ms build argument unfortunately.

Thanks!

Some extra information: In case you are wondering why I install the Windows Identity Foundation SDK (Dependency)? You can just use the .NET 4.5 Framework, and WIF is already in there. But you need to have the WIF SDK 4.0 to be able to install the WIF extensions. So… You just have to know..

Adding a custom domain to Office365 using WAAD

I’m playing with my Office 365 Plan E3 Technical Preview subscription for a quite a while now, and I think it’s just great! In this post, I want to guide you through the process of adding a custom domain to your subscription. The way I will show it is by using the Windows Azure Active Directory portal, which I will explain right away.

WAAD

Did you know that when subscribe to an Office 365 Plan, Microsoft automatically creates a new Windows Azure Active Directory (WAAD) that is associated with your Office 365 account? Well, at first, I didn’t! This is really great! For the people that do not know WAAD, let me quote:

Windows Azure Active Directory (Windows Azure AD) is a modern, REST-based service that provides identity management and access control capabilities for your cloud applications. Windows Azure Active Directory provides a cloud-based identity provider that easily integrates with your on-premises AD deployments and full support of third party identity providers.

When you login at https://activedirectory.windowsazure.com using your Office 365 administration credentials, you see that it’s linked to your subscription like:

01

Activate your custom domain

Alright, that being said, let’s move on and add a custom domain to our subscription. By default, your subscription domain will be something like yourname.onmicrosoft.com. That’s great, but using your personal domain is a much more professional way of working of course.  Let’s do that now.

First, click on the ‘domains’ link on the left side. You will see that the  *.onmicrosoft.com is already listed there by default. Click on the ‘Add a domain’ button.

02

In general, the process consists out of 2 mayor steps. First you need to ‘activate’ your domain, meaning that you need to prove that you actually own it. Secondly, you need to ‘manage your DNS settings’ to manage the correct usage of the Office 365 settings. The first wizard you see is the ‘activation’ part. Enter your domain and click ‘next

03

Now you need to verify that you are the owner of the domain. Out of the box, there are some pre-defined domain registrars listed. My domain is registered somewhere in the Netherlands, so no one of the listed option, so I selected ‘General Instructions

04

On the next screen, I used the TXT record option. On the DNS management page of my domain registrar, I added the TXT record like:

05

If you click ‘next’, the service will check the TXT record and you will be able you continue the process. In my case, it only took a few seconds for the TXT record to be applied. In other cases, it can take bit longer. The next step is to select the domain services. In other words, which services will be used with your domain? I selected ‘Exchange’ and ‘Lync’.

Don’t select SharePoint, because the DNS record that you create to enable SharePoint Online for this domain by default restricts all other DNS records from working. What you can do is create a CNAME record with the WWW prefix, and point it to yourname.sharepoint.com. Or even better, yourname-public.sharepoint.com, so it will link to the public website. You can then create another CNAME record with the PORTAL prefix, and point it to the SharePoint sites root.

06

That’s it, your domain is ready to be used, meaning that it’s added to your WAAD account (and thus can be used with your Office 365 subscription).

07

Configure your custom domain

Now that our domain is active, we can start using it. Click on the ‘Finish’ button (or if you already closed the previous wizard, just click on your Domain and click ‘DNS Settings’.) You will see a nice overview of the DNS entries you need to make on the DNS settings page of your domain registrar. For example:

09

On the wizard screen, you don’t have the option to ‘validate’ if you entered the correct DNS entries, but there’s an option to validate. Just go back to the screen where you see your domain name listed, click on the domain and select the ‘Troubleshoot domain’ button. It will ask you when you changed the DNS entries. For this quick check, just select ‘more than 72 hours ago’ so it will check it right away. In my case, this was a green result for Exchange (I didn’t configure Lync):

12

That’s it. Now we can use our custom domain with our Office 365 subscription. Let’s take Exchange for example. To be able to send an email to ‘abc@mycustomdomain.com’, you will need to add the email (alias) to the list of email addresses of the person ‘abc@something.onmicrosoft.com’. Go to the Exchange admin center – Recipients and edit the mailbox you want. On this new popup, select the ‘email address’ section, and add an SMTP alias like:

11

That should do the trick, you can now send an email to ‘abc@mycustomdomain.com’, and it should arrive in the mailbox of the user you just configured.

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!

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!

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!

Pages:12