AppWebUrl is undefined in Provider-Hosted App

By default the Autohosted or Provider-hosted template have an empty app web. If the app web is empty SharePoint doesn’t create the app web for you.

That’s how simply adding an empty element fixes the issue, and it will add Feature and Package folders to your project.


Add Site Setting and Site Action from CSOM

Cited: FTC to CAM – Custom actions and property bag entries from SP App

// Add site settings link
UserCustomAction siteSettingLink = clientContext.Web.UserCustomActions.Add();
siteSettingLink.Group = "SiteTasks";
siteSettingLink.Location = "Microsoft.SharePoint.SiteSettings";
siteSettingLink.Name = "Sample_CustomSiteSetting";
siteSettingLink.Sequence = 1000;
siteSettingLink.Url = string.Format(DeployManager.appUrl, clientContext.Url);
siteSettingLink.Title = "Modify Site Metadata";

// Add site actions link
UserCustomAction siteAction = clientContext.Web.UserCustomActions.Add();
siteAction.Group = "SiteActions";
siteAction.Location = "Microsoft.SharePoint.StandardMenu";
siteAction.Name = "Sample_CustomAction";
siteAction.Sequence = 1000;
siteAction.Url = string.Format(DeployManager.appUrl, clientContext.Url); ;
siteAction.Title = "Modify Site Metadata";

Make Property Bags Searchable in SharePoint 2013

A new cool thing in SharePoint 2013 is adding properties to a property bag and getting them indexed and searchable. SharePoint 2013 makes this possible, not only for webs, but even all the way down to an SPList.

Here is the PowerShell you can use to create an “Searchable” property in an SPWeb property bag:

$web = Get-SPWeb
$web.AllProperties["Searchable"] = "Yes"

Here is another exmample for adding an indexable property to a list:

$list = $web.Lists["Announcements"]
$folder = $list.RootFolder
$folder.Properties["ListSearchable"] = "Cool"

Then, you just need a Full or incremental crawl.  Make sure the crawled property is created in the search service application. Create Managed Property that maps to the crawled property.

Note:  The IndexedPropertyKey value is also saved in AllProperties using key (vti_indexedpropertykeys).  The value is base 64 encoded so if you want to update it, you’ll need to decode from and encode to base 64 string. However, this SPWeb.IndexedPropertyKeys property is not available for CSOM. Vesa provides an alternative solution in his post FTC to CAM – Setting indexed property bag keys using CSOM

// Used to convert the list of property keys is required format for listing keys to be index
public static string GetEncodedValueForSearchIndexProperty(List keys)
    StringBuilder stringBuilder = new StringBuilder();
    foreach (string current in keys)
    return stringBuilder.ToString();
// Decode the IndexedPropertyKeys value so it's readable
public static List GetDecodeValueForSearchIndexProperty(string encodedValue)
     List decodedKeys = new List();
     string[] keys = encodedValue.Split(new char[] { '|' }, StringSplitOptions.RemoveEmptyEntries);
     foreach (string current in keys)

     return decodedKeys;

Update Property Bag – Add / Remove

string indexedPropertyKeys = web.AllProperties["vti_indexedpropertykeys"].ToString();

List decodedKeys = GetDecodeValueForSearchIndexProperty(indexedPropertyKeys);
decodedKeys.Add(key);     //decodedKeys.Remove(key);

web.AllProperties["vti_indexedpropertykeys"] = GetEncodedValueForSearchIndexProperty(decodedKeys);

SharePoint 2013 App Details Page Error


use the following Powershell command to create new database for Usage and Health Logging Application Service

Get-SPUsageApplication | Set-SPUsageApplication -DatabaseServer “********” -DatabaseName “WSS_UsageApplication2″

Configure continuous crawl interval using Powershell in SharePoint 2013

A continuous crawl crawls content that was added, changed, or deleted since the last crawl. Unlike an incremental crawl, which starts at a particular time and repeats regularly at specified times after that, a continuous crawl automatically starts at predefined time intervals. The default interval for continuous crawls is every 15 minutes.
Update: Continuous Crawl doesn’t work for People search (users update their profile values). The workaround is to create a separate content source for People and set up Incremental Crawl every 15 – 30 minutes.
To Enable Continuous Crawls:
$ssa = Get-SPEnterpriseSearchServiceApplication
$contentsource = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $ssa -Identity "Local SharePoint sites"
Set-SPEnterpriseSearchCrawlContentSource -Identity $contentsource -EnableContinuousCrawls $True
To Disable Continuous Crawls:
$ssa = Get-SPEnterpriseSearchServiceApplication
$contentsource = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $ssa -Identity "Local SharePoint sites"
Set-SPEnterpriseSearchCrawlContentSource -Identity $contentsource -EnableContinuousCrawls $False
To get the continuous crawl interval:
############# Get the Continuous Crawl Interval in SharePoint 2013 ############# 
$ssa = Get-SPEnterpriseSearchServiceApplication

To set the continuous crawl interval:
############# Set the Continuous Crawl Interval in SharePoint 2013 ############# 
$ssa = Get-SPEnterpriseSearchServiceApplication

SharePoint 2013 Presence Indicator not working

Currently, we encountered an issue, which the presence indicator doesn’t work as expected.


  1. Verify if “Person Name Actions and Presence Settings” has been enabled
    • Go to Central Admin -> Manage Web Applications -> Select your web app -> General Settings
  2. Verify if the users have SIP Address imported from AD
  3. Verify if you have install Office in your testing computer, and the name.dll is in place.

It might take a while to reflect the changes. Also, if you are using Office 2003, you might have to reinstall the Office Web Components. Furthermore, disable / enable the “Person Name Actions and Presence Settings” may be required.


Cited: SharePoint 2013 – Office Communicator 2007 R2 Presence Indicator

How SharePoint Presence works:

SharePoint presence status is displayed through a client-side setting by using a dynamic link library called name.dll. This file is installed with Microsoft Office 2010, Office 2007 and Office 2003 and is located within the Office installation directory for e.g., (C:\Program Files\Microsoft Office\Office 14). The name.dll file is an ActiveX® control which gets loaded within the Internet Explorer that calls the Lync \ Office Communicator API directly to request and display presence status within SharePoint site collections.

Presence is enabled in SharePoint by default; there are no configuration steps for the SharePoint administrator to perform. Each SharePoint page includes Microsoft JScript® code, which enables presence for that site. JScript uses name.dll to call the Lync \ Office Communicator API and pull presence for users names who appear on the site. JScript uses the users’ SIP URI to pull presence for names that are listed on the site.

SharePoint 2013 – Make My Sites Public

We encountered an issue on SharePoint 2013 and found something interesting.

There is a “People” page on SharePoint 2013 MySite Host, which replaces the colleagues in SharePoint 2007. It’s auto created by User Profile Sync Service depends on a few things:

  • The users all have managers listed in Active Directory and the managers are being imported.
  • The “<UPA-Name> – User Profile Change Job” timer job is running successfully. — The profile sync imports the users and the fact that they have managers, but it’s this timer job that builds the colleague / following list.  By default this timer job runs hourly.
  • The “Auto-follow people from team” profile policy is enabled (by default it is).

We confirm this on our environment, but users are still not able to see the “Followed People” on others’ profile.

After couple hours of investigation, we found the root cause.


We found that the colleagues were in fact getting auto-created successfully.  The problem was that the privacy settings on the profiles did not allow other users to see a given users colleagues.

  • This is controlled by the check box for the “People I follow” property on each profile.
  • We found that all your profiles had this check box unselected by default, along with all of the “Activities I want to share in my newsfeed” check boxes.


I found that the default setting per-profile is controlled by the “Make My Sites Public” check box in Central Admin | User Profile Service Application | Set up my sites.

If this is selected, all of the above-mentioned check boxes for each profile will be selected by default.  If it is not selected, they won’t.  Also, “Make My Sites Public” only applies to new profiles.  Changing this setting will not affect existing profiles.


Step 1: Go to Central Admin | User Profile Service Application | Set up my sites.  Select the check box for “Make My Sites Public”.

Note: This will change the default behavior, but it will only take effect for new profiles when they are imported / created.  We need step 2 to update the existing profiles.

Step 2: Run PowerShell script to go through each profile and select the check boxes for “People I follow” and all of the “Activities I want to share in my newsfeed” check boxes.

$site = Get-SPSite #enter URL of mysite host

$serviceContext = Get-SPServiceContext($site)

$upm = new-object Microsoft.Office.Server.UserProfiles.UserProfileManager($serviceContext)

foreach ($item in ($upm.GetEnumerator()))
    $profile = $upm.GetProfile($item.recordid)

    $profile["SPS-PrivacyActivity"].value = 4095

    $profile["SPS-PrivacyPeople"].value = $true



Change Newsfeed setting of all User profiles in SharePoint 2010 – Part 1
Change Newsfeed setting of all User profiles in SharePoint 2010 – Part 2