Kategoriarkiv: spapp

Configuring VirtualBox for SharePoint-Hosted Apps

Recently I have switched from VMWare to VirtualBox for my SharePoint Development. So far it really works good. I have prepared this guide for configuring VirtualBox for SharePoint-hosted apps. That means we need a new adapter with a static ip address. All the steps done inside the virtual machine are applicable for VMWare and Hyper-V, too. This guide does not cover the full configuration of the app environment, it covers only the network and dns settings needed for SharePoint-hosted apps on Premises in a Development machine.

In VirtualBox open Preferences:


In Preferences, click on Network, then on Host-only Networks, click on “plus”


After a new host-only Network adapter has been created, click on the screwdriver image to configure the network:


Remember this ip address, you can alter it, of course. Or use this:, then you can have the same settings in your environment as I have:


Go on to the settings for your Virtual Machine. Enable Adapter 2, as shown on the picture below.


The rest are the settings in your virtual machine. Open Network Connections in the Control Panel. For the newly added Network Adapter (Ethernet 2), open Properties:


Then open Properties for “Internet Protocol Version 4 (TCP/IPv4)”


Remember the ip address for you VirtualBox host-only Network? I have Increment the last number ( and use it as the ip address for your adapter. The default gateway is as the the VirtualBox host-only Network. The DNS Server should be the same as the virtual machine, the same adapter:


Open DNS Manager, right-click on Forward Lookup Zones and start the New Zone Wizard by clicking on “New Zone…”:


Follow the steps in the wizard:


Choose “Primary Zone”:


Keep the default setting: “To all DNS Servers running on domain controllers in this domain:


Write your app domain. I use takanaapps.local:


Choose “Do not allow dynamic updates”:


Then finish the New Zone Wizard:


In the new forward lookup zone (takanaapps.local), add a new wildcard cname entry (alias):


Just add an asterisk and point it to your main domain (takana.local in my case):


After that you should be able to ping any subdomains of your app domain (xyz.takanaapps.local, abc.takanaapps.local):


When you start adding apps to your sites, you should add app sites to your local intranet zone (to be automatically signed in in apps webs). This setting in IE will affect Chrome as well. Go to the Options in the Internet Explorer:


In the Security tab -> Local Intranet, click on Sites:


Click on Advanced button:


Add your new app domain with an asterisk in front of it to the “Websites” of the Local Intranet:



What about the SharePoint app domain?

This is an open question about the domains for SharePoint apps. On Technet: Configure an environment for apps for SharePoint (SharePoint 2013) we can read the following:

You must configure a new name in Domain Name Services (DNS) to host the apps. To help improve security, the domain name should not be a subdomain of the domain that hosts the SharePoint sites. For example, if the SharePoint sites are at Contoso.com, consider ContosoApps.com instead of App.Contoso.com as the domain name.

Does it apply to SharePoint Online? Well, apparently not :) So why should we do it on premises?


As we all know, sharepoint.com is used for our Office 365 tenancies and for apps.

PowerShell: Get version and ProductId from an .app package

In my project I deploy some apps directly through the ObjectModel directly with PowerShell. The apps are built with TFS

I have a script that installs or updates apps if there is a new version of the app. Previously I used Import-SPAppPackage to compare the version and productid with an existing app instance, but often I get this error:

The provided App differs from another App with the same version and product ID.

Here you have the issue. Now the solution is to read the AppManifest.xml. But first the .app package has to be extracted like a usual zip file. This is the powershell function for that:

Apps can only call the OOB CSOM and REST endpoints

As a SharePoint architect or a SharePoint developer, you must have been thinking about the benefits/limitations of SharePoint apps a lot. I want to point out one of them today, which is very important: using custom webservices deployed to SharePoint inside apps. That is impossible and it is designed to be so due to the security architecture in the sharepoint app framework.

I have read much about SharePoint apps (books, whitepapers, blog posts) and stumbled over these two contradictive statements:

[…] app authenticatton is supported only for scenarios in which an app is calling to the SharePoint host environment by using client-side object model (CSOM) or the REST API. SharePoint 2013 does not support app authentication in any other endpoints beyond these. This means it is not possible to develop and deploy a set of custom web service entry points that support app authentication.

Microsoft SharePoint 2013 App Development, Microsoft Press, page 88.

This is really important to know, because it is exactly the opposite to what it is said in a Microsoft WhitePaper, where we are requested to “some outside-of-the-box thinking”:

The main reason why you would still use full-trust solutions is that a feature or API you want to use is not yet available through the REST endpoints or CSOM APIs. However, this doesn’t mean you can’t still use the server object model from an app that is on-premises. It just requires some outside-of-the-box thinking. Instead of writing a full-trust solution that completely covers the entire business scenario you are trying to satisfy, write a full-trust solution that exposes the functionality you are looking for as a REST endpoint and write an app that can use that endpoint. This will allow your solution to scale while reducing the overall exposure of full-trust code to the SharePoint environment.

Deciding between apps for SharePoint and SharePoint solutions, Microsoft. Keenan Newton.

Just to clearify, the first statement is correct. The second is unfortunately not correct. To be sure I created a web service which I deployed as a farm solution. And when I tried to invoke this webservice from my app I got 403 error and this message

The endpoint cannot be added within the manifest neither:


While developing SharePoint apps we are restricted to the OOB CSOM and REST endpoint only.

OOB here means out-of-the-box, not outside-of-the-box.