Showing Birthdays and Job Anniversaries in the Newsfeed

anniversary-001

In our project we have a requirement to show birthdays and job anniversaries in the Newsfeed. The solution is simple (when you know it) but there has not been any information about it online, until today. I want to share a few lines of PowerShell code to enable Anniversary notifications in the Newsfeed. This desired piece of code was written by my colleague Emma Degerman. Enjoy:

The code retrieves the Timer Job that changes User Profiles, sets “GenerateAnniversaries” to true, then it updates the schedule to run it before the Activity Feed Timer Job and updates it. By the way, it is only applicable for SharePoint On Premises.

This is it, a quick tip for a great Intranet.

Load git into PowerShell

Just a little productivity tip. If you use git on Windows, you probably already have the Github for Windows application. This application adds the Git Shell:

006-gitshell

The Git Shell will open a PowerShell window and execute shell.ps1 from the Github directory:

007-gitshell

What it won’t do is to load your personal PowerShell profile. I want to use my PowerShell profile that creates some links and adjust the look-and-feel and the promt of the shell. By the way I have published my profile.ps1 as a gist:

I also want to have git in PowerShell available directly. The answer is in the shell.ps1 in the Github folder:

008-gitshell

So add this line to your profile.ps1 as I did:

That’s it. If you haven’t seen the “DOT” in PowerShell scripts, it is called dot sourcing, it will execute the script and keep all the variables and references within the script.

An alternative

If you do not have Github for Windows, there is another way to load git functionality into PowerShell:

AppLoader Concept for SharePoint apps

In this post I want to share an unusual, nevertheless interesting conceptual idea of loading content from SharePoint 2013 apps on many pages. The original awesome concept was proposed and developed by my colleague Martin Villysson at Bool.

The problem we are trying to solve

SharePoint apps are great to extend functionality in SharePoint and integrate other systems (full page apps available through Site Contents), they also provide tools to enrich the default SharePoint experience by App Parts (Client Web Parts) and Custom Actions (additional menus).

One of the biggest shortcomings of that model is the need to add app parts on all pages where it is needed. Let’s say, we want to have some app parts present on every single page in our whole SharePoint tenancy, to provide a consistent look and feel (e.g. navigation, notifications). Traditionally, on premises, we have added user controls in our customized master page. In SharePoint Online that is impossible. The complicated workaround is to add those client web parts (app parts) on every page, be it manually or by automating it (powershell or app). It will require updating all pages. Nevertheless, it will not work on Out-of-the-box application pages (pages from layouts folder). It becomes even more unacceptable when you realize that your app must be added as an app instance on every single site (SPWeb) in your tenancy. 

Towards a solution

Allright, we don’t want to have thousands of app instances of the same app. What we can do is to use Tenant scoped apps (Tenant Apps). Then we’ll need only one app instance. But wait, app parts from a tenant app are only available in the parent site (HostWeb), meaning – App Catalog. That’s not good. So what Martin found in the SharePoint internal javascript code is using of _layouts/15/TenantAppInfo.ashx, a http handler that provides information about all Tenant Apps and their custom actions.That’s how the idea of the AppLoader was born.

Vesa Juvonen

After we had created a working Proof-of-Concept of the AppLoader concept, I met Vesa Juvonen at the SharePoint Conference in Las Vegas and introduced this idea to him (although I didn’t call it AppLoader). He liked it although he pointed out that this TenantAppInfo.ashx is an internal utility only in SharePoint and it is not supported by Microsoft. That’s correct. There is even almost no information about it on the Internet. But I got a feeling of Microsoft that they are willing to hear feedback and improve the product. Vesa encouraged me also to blog about it. So now I am telling about this idea. I hope to hear feedback about it. Unfortunately I cannot share the source code of the working Proof-of-Concept solution.

AppLoader Concept in colors

The AppLoader Concept is quite simple. Look at this picture:

apploader-concept

 

The solution contains a custom Master Page (blue) that references a javascript file called apploader.js (red). This file initializes the whole process. Tenant Apps (green) are the apps that an administrator has installed in the App Catalog and deployed to the whole tenancy. TenantAppInfo.ashx (black) is a handy but officially unsupported OOB service utility (http handler) that returns a json-formatted list of all Tenant Apps (green). AppLoader (red) receives the app list (black) and renders it on the Page (blue) inside new iframes (red). The page a user has navigated to can be any page (wiki page, publishing page, application page, really any page).

To summarize the colors in the diagram: red is our javascript code, green are all the tenant apps and their content, black is the utility and its output, blue is a sharepoint page and its underlying component (master page).

The steps in the AppLoader process:

  1. Make an ajax request to TenantAppInfo.ashx using XHR (XmlHttpRequest)
  2. Receive the app list
  3. For every app information, render app part, or inject css and javascript references. 

 

Reading what to render on the page

You probably have already have tried to navigate to _layouts/15/TenanAppInfo.ashx while reading this post, I know you are curious. Then you’ve noticed that there is no information about app parts. So you may ask: how do we know what app parts to render and where to put them in the page, and how do we know what resources (css and javascript files) to inject on the page. Well there is no information about it in the apps list. But if you have an app with custom actions you’ll see that they are listed in this json-formatted list we receive from the TenantAppInfo.ashx. So the solution is the brilliant idea of my colleage Martin to define custom actions in the app. CustomActions contain a ActionUrl. The ActionUrl points to the url to render (app part page) or to inject (javascript or css file). The apploader.js reads the ActionUrl in the Custom Actions for every app information and takes action upon it (rendering an app part iframe, or injecting a javascript or css file). That’s it. 

Usage and Limitations

This bright idea takes advantages from a huge SharePoint API (that contains a lot of good but not supported parts) to make using of apps in Client Application Model solutions more pragmatic and still provide a consistent design and behavior. By consistent design I mean same parts like additional navigation, notifications etc in the whole Intranet. The AppLoader renders and injects whatever you have rolled out to your whole tenancy (Tenant Scoped Apps) and that on every page (!). It also improves the perceived performance of the page load, because it renders app parts (iframes) after the main page has been loaded preventing freezing of the page. 

There are of course some limitations in the AppLoader Concept. Today we cannot rely on the TenanAppInfo.ashx API (because it is not supported and future updates can break solutions). We have to define our own custom actions in the apps. That means we can only use our own apps, it will hardly work with the apps installed from the Office Store. On the other hand, your customer will not want to have generic apps from the Office Store to be a part of every page on their intranet.

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:

002-vbox

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

003-vbox

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

004-vbox

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

005-vbox

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

006-vbox

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:

007-vbox

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

008-vbox

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

009-vbox

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

010-vbox

Follow the steps in the wizard:

011-vbox

Choose “Primary Zone”:

012-vbox

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

to-all-servers-vbox

Write your app domain. I use takanaapps.local:

014-vbox

Choose “Do not allow dynamic updates”:

015-vbox

Then finish the New Zone Wizard:

016-png

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

017-vbox

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

018-vbox

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

019-vbox

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:

020-vbox

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

021-vbox

Click on Advanced button:

022-vbox

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

023-vbox

Sources