I’m a huge fan of the e-mail brevity challenge. The idea is simple: keep your e-mails short. 140 characters short. What this limits you to do is huge. Do you think you can have technical design discussions with 140 characters? What about researching technical support problems? How about product feature ideas? Clarifying how your team came to the conclusion to disable a feature due to security constraints? You might be able to do this in a bunch of 140 character e-mails, but that’s hardly a good use of time.

The Problem

For those examples I listed above, how important is it to your team to find that information now or three years from now? Let’s face it - most teams undergo turnover at some point and with some degree of variability. Those whom are left find themselves struggling to find the context - the why - beind a particular decision. This becomes more evident the longer time passes since a decision was made.

We have this problem now. I am considering simplifying a system we have currently. Yet, I can’t find any context to understand why the system is currently so complex. Everyone agrees there should be a reason, but nobody knows why that reason is. The how of the system was perfectly documented, but the why was not. If current (and former) history are any sign, it’s likely the conversation of why has been lost somewhere along the way.

The Solution

As previously indicated, expressing yourself via e-mail in 140 characters or less is hard. You want to know what isn’t hard to express under that constraint? A URL.

The solution to this problem is easy. If you shift your conversation online, its longevity or persistance is no longer tied to the life of someone’s inbox. We have what we call a “posting” culture at the firm - a process to keep as many people who are directly involved or may be involved informed about the progress of our work. However, doing so via e-mail is laborious, especially if you leave out a stakeholder. However, if the conversation is non-private, having that conversation on an online social platform enables those stakeholders to opt-in to your updates. They can sit on the sidelines watching the activity, or if they see something that requires their intervention, they can take charge and engage in the conversation.

But what about private conversations? Most social platforms have the capability for engaging in private conversation. Whether this be through closed collaboration/team rooms or direct messages between you and another user. However, once decisions have been made, it becomes easy to promote the relevant pieces of those conversations from private to public - it’s already online.

Additional Benefits

The problems of traditional e-mail go beyond simply lack of context. Many corporate e-mail platforms still don’t provide metadata tagging. Searching for e-mail means you search conversations only you were directly involved. Being able to keep track of the conversation thread is dismal with our tools - only a few e-mail clients (and only very recently) are able to present conversations in threaded views. Most people still don’t know those features exist! Finally, collboration on documents still happens by shipping them via e-mail. Which is the authoritative final version? Finally, what was the final decision of that chain of e-mails about how to proceed on our design?

Moving the conversation online to social platforms opens up many other benefits. Tagging (primarily #tags, pronounced as hashtags) are in most platforms. For those not familiar, tagging content with certain keywords enables easier discoverability. When you search for relevant conversations using those keywords, the search engine considers tagged posts more relevant than posts having those words somewhere in the document. A human made the decision that keyword pertains to this conversation, rather than that word being used in a conversation about something completely different. Search is also enhanced as you’re now searching all open and public conversations, broadening your search potential.

Being able to follow conversations is much easier. Threaded views enable clear visibility and understanding of the flow of conversations. Furthermore, most social platforms (especially in the Q&A space) have options for marking something as a “correct” or “most helpful” answer. Leveraging these same features, even for team discussions accomplishes two things:

• You know exactly which decision was made, even when the content indicating that a decision had been made was unclear.
• You have all of the conversation surrounding why that decision was made.

Finally, when it comes to sharing and collaborating on content, like Word/Excel/PowerPoint documents, moving that online and providing a single authoritative source for the document reduces confusion on which is the final version and the final copy.

Give it a Try

Don’t wait. Force yourself into this model. It will be hard - you’ll want to revert back to your old ways of typing lengthy e-mails and using distribution lists. When you find yourself writing even just two sentences in an e-mail: stop. Immediately move to your online space and continue. Don’t be tempted to reply in e-mail to someone sending you the link to the topic thread they started online - keep the conversation where it originated! But move it online if it started in e-mail!

While your team starts adopting this pattern of communication, you’ll see some short-term gains (like discoverability, transparency, clarity of decisions, inclusion, etc.). However, this is all about the long-term gains your team will have. The more content you push online, the better it will be for your team when it comes to retaining critical information. It will be worth it!

• My Site Instantiation Interactive Request Queue
• My Site Instantiation Non-Interactive Request Queue
• My Site Second Instantiation Interactive Request Queue

The problem is, those timer jobs were missing from my server!

I checked for the timer jobs first through Central Administration, and then subsequently thru PowerShell. The following are the results I found:

Get-SPTimerJob | sort Name | ft Name

{% img center /images/posts/2013-08-02-sharepoint-2013-my-site-timer-jobs-missing/01-missing-timerjobs.png Timer Jobs Missing %}

I decided to check for the My Site timer jobs on a know working SharePoint 2013 farm. Sure enough, they were there:

{% img center /images/posts/2013-08-02-sharepoint-2013-my-site-timer-jobs-missing/02-present-timerjobs.png Timer Jobs Present on Farm %}

I wanted to look for a way to re-register timer jobs. There should be no reason for me to do something drastic like uninstall/reinstall the User Profile Service just to get the timer job re-registered. This timer job, as expected, was in the Microsoft.Office.Server.UserProfiles assembly:

{% img center /images/posts/2013-08-02-sharepoint-2013-my-site-timer-jobs-missing/03-timerjob-definition.png Timer Jobs Definition %}

So, I cracked open dotPeek and decided to hunt for that timer job definition and find who was using it. It turns out, there’s a web application-level feature (MySiteInstantiationQueuesFeatureReceiver) which registers these timer jobs:

{% img center /images/posts/2013-08-02-sharepoint-2013-my-site-timer-jobs-missing/04-featurereceiver.png Timer Job Feature %}

There is a public static method inside that feature receiver used for registering the timer jobs.

{% img center /images/posts/2013-08-02-sharepoint-2013-my-site-timer-jobs-missing/05-methodtoregistertimerjobs.png Method to Register Timer Jobs %}

So, I had one of two options: invoke the static method directly, or simply toggle the feature. I opted to toggle the feature:

$feat = Get-SPFeature 65B53AAF-4754-46D7-BB5B-7ED4CF5564E1
Disable-SPFeature $feat -Url http://webapp
Enable-SPFeature $feat -Url http://webapp

{% img center /images/posts/2013-08-02-sharepoint-2013-my-site-timer-jobs-missing/06-toggle-feature.png Toggle Feature %}

Finally, I double checked and verified the timer jobs were now present!

{% img center /images/posts/2013-08-02-sharepoint-2013-my-site-timer-jobs-missing/07-timerjobspresent.png Timer Jobs Present %}

I then went to the My Site host URL and got into the queue for provisioning. Within 5 minutes, my personal my site was provisioned!

{% img center /images/posts/2013-08-02-sharepoint-2013-my-site-timer-jobs-missing/08-mysite-provisioned.png My Site Provisioned %}

The recommended path to upgrade from 2010 to 2013 is a content and service-application database migration. This works great for us since we have to do this piecemeal. However, many of the general approaches for converting to claims-based authentication is to do so at the web-application level, rather than the content-database level (source: TechNet).

In SharePoint 2013, there’s actually an SPWebApplication method dubbed MigrateUsersToClaims that takes 3 arguments:

• NTAccount
• removePermissionsAfter
• SPWebApplication.SPMigrateUserParameters

There was no guidance on the NTAccount, other than the user “performing” the operation. I opted to use the farm account to ensure it had the appropriate level of permissions. The true power of the content database migration comes in with the third parameter. We can add individual content databases to migrate with this parameter rather than worrying about the entire web application.

Props go to Steve Peschka who originally pointed this out. However, in his post, the PowerShell to do this upgrade was the following:

{% codeblock %} – SNIP – $wa.MigrateUsersToClaims($acc, $true, $arguments) {% endcodeblock %}

For me, that throws the error Exception calling "MigrateUsersToClaims" with "3" argument(s): "Operation is not valid due to the current state of the object." This was strange, and I couldn’t figure it out. So, I cracked open the Microsoft.SharePoint.Administration dll and took a look at the MigrateUsersToClaims method:

{% codeblock lang:csharp %} public bool MigrateUsersToClaims(NTAccount account, bool removePermissionsAfter, SPWebApplication.SPMigrateUserParameters parameters) { if ((NTAccount) null == account) throw new ArgumentNullException(“account”); if (removePermissionsAfter && parameters != null && (parameters.HasDatabaseToMigrate || parameters.OnlyMigratePolicyUsers)) throw new InvalidOperationException(); // The rest } {% endcodeblock %}

That second one was the one that I questioned. I know the conditions matched for the first two checks. The question was how my parameters looked. Sure enough:

{% codeblock %} PS > $arguments

DatabasesToMigrate HasDatabaseToMigrate OnlyMigratePolicyUsers

{WSS_MigrationTest_…} True False {% endcodeblock %}

With that, if I changed the middle parameter from $true to $false, the migration finally ran (and completed) succesfully.

Why did this happen? This was because my $acc user is my farm account. I’m also running my PowerShell session as my farm account. This is to ensure that I have full, unfettered access to the SharePoint Object Model and the Content Database. The middle parameter states (from MSDN):

{% blockquote %} The account will be given the correct permissions to perform the operation. Should this permission be removed when the operation is complete. {% endblockquote %}

We definitely don’t want this for the farm account. So, my updated code, for reference:

{% codeblock %} $wa = Get-SPWebApplication http://my-app-url $acc = “domain\farm-account” $arguments = New-Object Microsoft.SharePoint.Administration.SPWebApplication+SPMigrateUserParameters

$contentDb = $wa.ContentDatabase[“Content Database Name”] $arguments.AddDatabaseToMigrate($contentDb) $wa.MigrateUsersToClaims($acc, $false, $arguments) {% endcodeblock %}

Cheers. Once again, thanks go to Steve Peschka for figuring this out.

{% img center /images/posts/2013-04-30-sorry-only-tenant-administrators-can-add-this-app/error.png Error Message %}

The application required Tenant Read permissions as I’m accessing the User Profile through the JavaScript object model. The purpose of using the User Profile JSOM is to get the suggestions of sites and people to follow that SharePoint presents.

Now, the concept of a “Tenant” makes sense for Office 365 or SharePoint Online. As a hosting provider, there are multiple tenants you want to support in a single environment. However, for an on-premise deployment, this error message didn’t make much sense. I started poking around and came across spinning up a tenant administration site, being able to set multiple app tenants through the App Management Service cmdlets, but none of those really seemed like the right solution for my on-premise deployment. I found an MDSN Forum Question which seemed closer to the solution. That post recommends splitting the service accounts used to host the App Management and Site Settings services from the farm account. This was critical as the Farm Account is not allowed to add apps under its identity whatsoever. You will get an error message when trying to provision, and the ULS logs will indicate that an assertion failed checking that the current account was not the system account.

{% img right /images/posts/2013-04-30-sorry-only-tenant-administrators-can-add-this-app/success.png Provision %}

What did it turn out to be? I just needed to make sure my user account was directly added as a member of the Farm Administrators group. We have traditionally deployed farm administrators via an Active Directory and local (Administrators) group. However, it appears that the App Management service dislikes this approach and wants users explicitly permissioned to the Farm Administrators group. Additionally, after granting your user direct permissions, you need to issue an iisreset so those changes take effect. Then, you can provision your app successfully.

{% img right /images/posts/2013-04-25-editing-the-sharepoint-my-sites-web-part-pages/site-edit-page.png Edit Page in Ribbon %}

I’m used to having the ribbon to edit pages in SharePoint, regardless if they are standard publishing pages or web part pages. However, in the “My Site Host”, there is no ribbon for the standard pages, even when you are a farm administrator. I jumped to the conclusion that I could add the App Part via SharePoint Designer. Sadly, this wasn’t the case. SharePoint Designer does not list any app parts.

I tried to go through the rigarmarole of adding the app to a separate site through the web editor, then copying the code from within SharePoint Designer and pasting it into the Newsfeed page, only for that to fail. The identifiers for the apps are completely different.

{% img left /images/posts/2013-04-25-editing-the-sharepoint-my-sites-web-part-pages/gear-edit-page.png Edit Page in Settings Menu %}

This is when I stepped back and though that the solution should be simpler than this. It turns out, it was. Click the gear icon (settings menu) in the upper-right corner of SharePoint and you’ll find the Edit Page link. I felt liberated and frustrated at myself for not checking there earlier. From there, you have complete control to edit the Newsfeed web part page (or any page in the “My Site Host”).

{% img center /images/posts/2013-04-25-editing-the-sharepoint-my-sites-web-part-pages/newsfeed-web-part.png Newsfeed Web Part Page %}