Archive for the ‘SharePoint 2013’ Category

This error popped up when I changed my service account for Search Service & the Search Host Controller Service as these services were using the farm admin account. Below are some of the solutions which provided were,

  • Removing the extra space at the end of ‘PSModulePath’ – This didn’t work for me
  • Adding proper permissions in the database – Which is perfectly fine already
  • Repair SharePoint under Control Panel – This is not going to be a good option

The solution was to provision the WSS usage application proxy. Use the below command to do the same.

$UP = Get-SPServiceApplicationProxy | where {$_.TypeName -like "Usage*"}

The name “apps for SharePoint” is changing to “SharePoint Add-ins” & its official ( Any references to the app with-in the SharePoint eco-system will now be termed as Add-in. This is not limited to SharePoint but also Office.

But why this change? Some reasons we get from experts,

  • Microsoft’s multi-platform support of Office client across the Windows/Mac, iOS, Android and Windows 10 environments ended terming the Office client as “apps”, and so having “apps” within “apps” was causing confusion
  • Microsoft received multiple feedback that “apps” weren’t working in the enterprise space who were building something that was valued at much more than a simple app.

The notion also needed to be consistent here with the name change across both Office & SharePoint for the Office Store perspective.

Whatever may be the reasons, we just need to update our pointers from Apps to Add-ins. Below is the table that might help you to do that.

Original name New name Applies to
apps for Office Office Add-ins Office
mail app for Outlook Outlook Add-in Office
app for Excel Excel Add-in Office
app for PowerPoint PowerPoint Add-in Office
app for Word Word Add-in Office
apps for SharePoint SharePoint Add-ins SharePoint
app part add-in part SharePoint
app web add-in web SharePoint
SharePoint App Model SharePoint Add-in Model SharePoint
SharePoint Hosted App SharePoint Hosted Add-in SharePoint
SharePoint Provider Hosted App SharePoint Provider Hosted Add-in SharePoint

​There are three types authorization policies in SharePoint 2013. This post explains what each of this means and where exactly these are used.




This was the policy which was there in 2010 too. Whenever your code gets executed, only the user permissions are considered. If the user have the rights to do what the code have to do, it executes fine. There is no other authorization required.


User + App:

As you start coding your SharePoint apps, you will come across the terms like App Manifest, App permissions etc.,  where in you mention certain permissions your app needs to execute the code it contains. Some of such permissions levels are (Read, Manage etc,). In this case, when your code gets executed, the app should have the required permissions & also the user whose context the app is getting executed should have the same level of permissions.

For example, in case your app is trying to update an item in a list in your host web, your app may have Write permissions  but if your user is having only Read permissions your code will not execute & vice-versa. So both your app and the user should have Write permissions for the app to work.

To put it simply both your user context and app context are taken in to consideration here.



If at all a timer job can be made possible for SharePoint online, then it’s using this authorization method.

This method allows you to execute code even if the current is not having the required permissions. We will not be able to elevate/provide every user the required permissions. But we need to perform an action that the user is not entitled to. People always consider this as a replacement for RunWithElevatedPrivileges in farm solutions. But it’s not. This is not same as RunWithElevatedPrivileges. RunWithElevatedPrivileges still takes the current user context in to consideration. But in this case we ask the app to totally ignore the user context.  This is done by adding the property AllowAppOnlyPolicy=”true” to your app manifest file. Below will be the permissions you will see in the manifest file.

<AppPermissionRequests AllowAppOnlyPolicy=”true”>

<AppPermissionRequest Scope=”http://sharepoint/content/tenant&#8221; Right=”Manage” />


In general, a current user is required to be present for a call to be made. In the case of app-only policy, SharePoint creates a SHAREPOINT\APP, similar to the existing SHAREPOINT\SYSTEM user. All app-only requests are made by SHAREPOINT\APP. There is no way to authenticate as SHAREPOINT\APP through user-based authentication.

Since app-only calls effectively does what a user is not meant to do , you should be conservative in creating apps that ask for permission to make them. Calls should use the app-only policy only if:

  • The app needs to elevate its permissions above the user for a specific call; for example, to approve an document under conditions evaluated by the app.
  • The app is not acting on behalf of any user; for example, an app that performs nightly maintenance tasks on a SharePoint document library.

SharePoint 2007 (MOSS) & SharePoint 2010 have an option of “Sign in as different user” in the menu at the right top corner of the page. Developers used this handy menu to test their customizations for different users by logging in with another account. But in SharePoint 2013, you will not be finding that  option. You just can sign-out from the site, re-open the browser & login again.

Not sure is it removed with a reason. But MS references say it is a problem with SharePoint 2013.

So, How do I login as different user to my SharePoint site? There are two ways you can do it:

1) IE’s “Run as different user” option

This is the way old method we used to start any application with a different credentials. That is by using the Run as different user option that will be visible if you hold the Shift key when you right-click a program icon.

Start Internet Explorer by using the Run as different user option, where you can provide the different credentials and then go to the SharePoint site.

2) Navigating to the close connection page

More simple way is to browse the close connection page. Hit the below URL in your browser where you have opened your site.


You will be getting a pop up to enter the new credentials where you can sign in as different user.

Note : This option uses an unsupported browser feature which is unreliable and may causes other issues. Currently this option does not work in IE 10 and Safari.


Hope it helps.


With the experience of working on webparts in SharePoint 2007 & 2010, I started creating a new SharePoint hosted app as soon as I set up my 2013 developer machine & VS 2012. With a little bit knowledge on the solution structure that every script we write should go in to the  App.js file, I quickly opened it. Visual Studio, pre-loads the file with a piece of code to display a welcome message with the current logged in user. In an urge to see my app working on the site, I deployed the app.

BANGGG!!  Visual studio threw its first error “Apps are disabled on this site“. Digging more in to it, found lot more goes at the configuration before an app can be deployed. Below are the various issues/errors I have faced and the solutions I have found to resolve them to get my app deployed & work successfully.

<<<GOLDEN RULE : Make sure you deploy your app only with an account which is not part of the farm administrators group>>>

“Apps are disabled on this site”

To resolve this issue, you need to configure App URLs in the central Administration. Open Central Administration -> Apps ->Configure App URLs

By opening this page you may end up with the below error.

“The Subscription Settings service and corresponding application and proxy needs to be running in order to make changes to these settings”

Reason being that app requires below two service application to be created & running.

  1. App Management Service
  2. Microsoft SharePoint Foundation Subscription Settings Service

Going to the System Setting -> Manage services on server, I saw both of these services Started & running without any issues.


Further debugging, when I checked the service applications list, I could see only the App Management Service application & not the Microsoft SharePoint Foundation Subscription Settings Service application.

Though App Management Service is created as part of the set-up, you need to create the later one manually. And the trick here is that you need to create it through PowerShell. Below is the commands..

>> $managedAccount = Get-SPManagedAccount “domain\accountname”
>> $appPool = New-SPServiceApplicationPool -Name SubscriptionServiceAppPool -Account $managedAccount
>> $serviceApp = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPool -name “Subscription Settings Service Application” -DatabaseName “SubscriptionSettingsDB”
>> $serviceAppProxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $serviceApp

Make sure you are using a managed account in the above snippet to avoid the object reference error. You can register your account as a SharePoint Managed account at Security -> Configure Managed Accounts in Central Administration (Being a dev environment we attempt to use our own domain account for installation/run services applications & app pools/farm administration. But remember the golden rule, don’t deploy app using the farm admin account. I would suggest, use your account only for developing & deploying but another service account to run the service applications & app pools). 

Now going back to where we started, Configure App URLs page, I got the below error.

“Settings or services required to complete this request are not currently available.  Try this operation again later.  If the problem persists, contact your administrator”

An IIS reset solved this issue. Once the page loads successfully, provide your app domain and the prefix details.


The App domain, in the production environment is the one that will be a registered domain with an entry made in to DNS. As of now your deployment adds a host entry like the ones below to enable viewing the app in your local farm.


These steps made sure that my app gets deployed successfully!!

Before you browse your app, some browser level settings needs to be done.

  1. Add your app domain site to the Local Intranet Sites list. To do this go to IE -> Tools -> Internet Options -> Security -> Local intranet -> Sites & add http://* (In my case it would be http://* ).
  2. If you are in a corporate network and using a Proxy, add your address in exceptions list. To do this go to IE -> Tools -> Internet Options -> Connections -> Lan Settings -> Advanced & under Exceptions add *


Now you should be able to browse your app from the site you have deployed. In case your app prompts continuously for credentials, the last step you need to do is to disable the loopback check.

To disable loopback, open the registry and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA and create a new DWORD (32-bit) Value with a name of DisableLoopbackCheck and set the value to 1.  Restart the server after the change to ensure it takes effect.

And finally, you should be seeing your app loaded & the welcome message in the page.  Now you can start coding your app and just go on pressing the way old F5 to see the changes reflecting in your app 🙂

Do post if you face any other errors you come across in the comments section & Happy APPing 🙂