1. Deploy Office Web Apps Server (https://technet.microsoft.com/en-us/library/jj219455(v=office.15).aspx)
2. Configure SharePoint 2013 to use Office Web Apps (https://technet.microsoft.com/en-us/library/ff431687(v=office.15).aspx)

According to them, the configuration looks like very straight forward. However, the devil is in the details. Here, I am trying to list some issues that I experienced recently with the RTM version of SharePoint 2013 and Office Web Apps so I don’t forget them soon.

1. .NET Framework 3.5

When you install Office Web Apps on Windows Server 2012, you usually run the PowerShell script in the above articles to prepare the roles and features of Windows. That script doesn’t install .NET Framework 3.5 Core. However, at some points it looks like the Office Web Apps still needs the .NET Framework 3.5 Core. Without it, you may see the event error below.

Server Error in ‘/m’ Application

Warning: ASP.NET 4.0 – Event code: 3008 – Event ID: 1310

Could not load file or assembly ‘Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified. (C:\Program Files\Microsoft Office Web Apps\BroadcastServices_Host\web.config line 44)

To avoid it, you can add the .NET Framework 3.5 Core feature, or run the following PowerShell script:

Add-WindowsFeature NET-Framework-Features, NET-Framework-Core

The only thing to notice is that Windows Server 2012 wasn’t shipped with .NET Framework 3.5. So you must have an Internet connection on the server so the core can be added successfully with the above method.

2. Office Web Apps Host

In case Office Web Apps don’t work after you finish the configuration and verified everything including the WOPI zone, you have to check the error log of the Office Web Apps. The default location of the log is C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS.

At some points, if you see the following error:

WOPI - CreateWopiHttpRequest failing due to invalid host

It means the domain name or the host name of the SharePoint site is not trusted by Office Web Apps. You have to use the following PowerShell script to add the name into the host list.

New-OfficeWebAppsHost -Domain <String>

The name of the parameter may lead to some confusing. You may think it is the name of the domain which your SharePoint server belongs to, but it is not. For example, the name of your domain may be contoso.com, but the url of the SharePoint site may be https://sharepoint. In this case, you should put “sharepoint” instead of “contoso.com”.

Based on my testing, when configuring Office Web Apps over HTTP, you have to configure the host list. When configuring over HTTPS, the host list can be empty.

3. AllowOAuthOverHttp

Again, the TechNet article may lead to some misunderstanding to this option. According to the article, it looks like this option should be True when Office Web Apps are configured to use HTTP, and False when they are configured to use HTTPS. However, it is not true based on my testing. This option is more like depending on the configuration of the SharePoint site. If the SharePoint site is using HTTP, this option should be True no matter if HTTP or HTTPS is used by Office Web Apps.

If you see the “HTTPResponseCode forbidden” error in the Office Web Apps log, in most of case it is because of the incorrect setting of this option.

4. Word Doc Corrupted

At some points, you may see the following error in the Office Web Apps log.

[AppServerHost.exe] Word failed to open the document (Error Code = 0x80040266)

It is very like the Word document you are trying to open with Office Web Apps has been corrupted. You can upload a good document to test and confirm it.

One scenarios which may create such a corrupted Word doc is that you choose to create a new Word doc in SharePoint site with Office Web Apps. However, for some reason Office Web Apps don’t work normally. In this case, you get a corrupted Word doc in SharePoint document library.

Here is a good start point: SharePoint 2013 for IT pros

If you ask any SQL DBA a question like, “should I turn on Auto Update Statistics and Auto Create Statistics on databases?” You’ll get an answer like, “Yes, definitely!” or probably “It depends”. But if we are talking about SharePoint 2010 databases, the answer is “It really depends”.

In the official document, it suggests to turn off these options and explains why they should be turned off. But what it didn’t tell is how SharePoint will maintain the statistics if the options are turned off. Therefore, it could lead to some confusions like should we turn them off on all databases or just on some databases? should we manually maintain the statistics if we turn them off? etc.

So let me try to explain how SharePoint maintains the statistics first.

Health Analyzer Rule: Databases used by SharePoint have outdated index statistics

As explained in this whitepaper, SharePoint uses this Health Analyzer rule to maintain the statistics (unfortunately the whitepaper didn’t mention the name of this rule). By default, this rule is scheduled to run everyday and it is a repairable rule, meaning it has a repair action. What this rule does is very simple. It will enumerate all SharePoint databases in the farm and check if the database implements a store procedure, proc_UpdateStatistics. If so, it will call this store procedure directly. Otherwise, it will do nothing. 

So now the problem become simple. To find out on which databases we should turn on the options and on which we should turn them off, we just need to check if the database implements the store procedure. If it implements the store procedure, means it has its own way to maintain the statistics and doesn’t rely on SQL server. So the options can be turned off. Otherwise, the options should be on.

Based on my checking, the following databases implement the store procedure, and the two options are turned off by default, meaning SharePoint has its own way to maintain the statistics of these databases. These two options should be left OFF on these databases in most cases. The list is quite similar to the databases mentioned at the beginning of the above whitepaper. (I hope I’ve exhausted the SharePoint dbs.)

• Configuration databases
• Content databases
• User Profile Service Application Profile databases
• User Profile Service Application Social databases
• Web Analytics Service Application Reporting databases
• Web Analytics Service Application Staging databases
• Word Automation Services databases
• WSS_Logging

The only exception is the crawl db of the SharePoint search service. It implements the store procedure but the two options are turn on as well. I am not sure if it was intended to be set like that or what.

So let us go back to our original question, should we turn on or off the two options on a SharePoint 2010 database? My answer would be it depends on which database you are talking about. If the database knows how to maintain its own statistics, the options should be turned off and SharePoint will take care of it. Otherwise, the options should be turned on.

The reason why this feature works like that is related to how it is activated. Basically, when we activate this feature, it will check if the current site collection is a big site or not. If the site collection is not big, it will just enable the DocId on the site collection and register a work item for the Document ID Assignment timer job (DocIdAssignment). But if the site collection is too big, it will just register a DocIdEnableWorkItem for the Document ID Enable/Disable timer job (DocIdEnable). So to big site, it relies on the DocIdEnable timer job to enable the DocId. But you may find even if you run this timer job immediately after the feature is activated, the DocId is not enabled. It is because when the DocIdEnableWorkItem is added to the site by the feature activation, it has been specified to be executed 30 minutes later to avoid the potential conflict. You can check the real scheduled delivery time by querying ScheduledWorkItems table in the content db. So the DocId will only be enabled when you run DocIdEnable timer job after the scheduled delivery time. For example, suppose you activated DocId feature on a publishing portal at 8:00am, the DocIdEnableWorkItem was scheduled to be delivered at 8:30am. If you ran DocIdEnable timer job before 8:30am, nothing really happened. Only when you ran it after 8:30am say 8:35am, DocId was enabled then.

The final question is how big a site collection is big? The boundaries are maximum 1 web/site, 40 lists/web and 20 doclibs/web. A publishing portal is too big because by default it has 3 webs. The OOTB document center is OK because by default it has 1 web, ~30 lists and ~15 document libraries. The numbers are hard coded and, so far as I know, there is no way to change them. 

According to the SharePoint team blog, SP1 should be installed in the following order:

1. Service Pack 1 for SharePoint Foundation 2010

2. Service Pack 1 for SharePoint Foundation 2010 Language Pack (if applicable)

3. Service Pack 1 for SharePoint Server 2010

4. Service Pack 1 for SharePoint Server 2010 Language Pack (if applicable)

This align to the best practice published here:

Best practice

We recommend that you always install SharePoint Foundation 2010 patches before you install SharePoint Server 2010 patches. This best practice ensures that you will be successful when installing updates.

The software update system is designed to be flexible enough to allow you to install updates in any order. However, the only time you should diverge from the best practice is if you have a specific reason to do so (for example, if you are directed to by Microsoft support).

But the fact is that you don’t have to install the SP1 for Foundation first. The SP1 for SharePoint Server can be installed directly, because it is a Full (“Uber”) package. Installing the SP1 for Foundation would just waste your time.

In the same blog, there is another suggestion about June CU:

It is strongly recommended to install the June 2011 Cumulative Update immediately after the installation of Service Pack 1.

If you check the version of June CU, you will find it is 14.0.6106.5000, while the version of SP1 is 14.0.6029.1000. Does that mean June CU has included SP1? The answer is NO. The June CU does not include all of the files included in SP1. That is why you have to install it after the SP1.

Would that be a matter if someone installs the June CU before the SP1? Well, from the information I got, the installation order of the June CU and the SP1 doesn’t really matter. You can install the June CU first and then SP1. The files with higher version won’t be overwritten, while the missing part in June CU will be installed.

Conclusion?

Well, before patching, verify if the Server patch is a Full package. If so, no need to waste your time patching the Foundation first. Go patching Server directly. If it is not a Full package ( the chance is small but still possible), follow the best practice.

Interesting enough? Check out Jie Li’s new post The Mystery Behind SharePoint 2010 Patching. I am sure you’ll get more fun there.

The following is the definition of my custom field. I’ve highlighted the attributes and values which you may pay attention to. In this field, I want it to have the same value of Title so I add a reference to Title. Note in SharePoint 2010 now we use _EditMenuTableStart2 instead of _EditMenuTableStart. To make things simple, I also create a content type to use this custom field.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="https://schemas.microsoft.com/sharepoint/">
    <Field ID="{566F83FF-CCFE-4f7a-BE3C-332169E040B8}"
        Group="Morpheus Columns"
        ReadOnly="TRUE"
        Type="Computed"
        Name="TitleEx"
        StaticName="TitleEx"
        DisplayName="TitleEx"
        DisplayNameSrcField="Title"
        ClassInfo="Menu"
        AuthoringInfo="(with edit menu)"
        SourceID="https://schemas.microsoft.com/sharepoint/v3">
        <FieldRefs>
            <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" 
                      Name="Title" />
            <FieldRef ID="{1344423c-c7f9-4134-88e4-ad842e2d723c}" 
                      Name="_EditMenuTableStart2" />
            <FieldRef ID="{2ea78cef-1bf9-4019-960a-02c41636cb47}" 
                      Name="_EditMenuTableEnd" />
        </FieldRefs>
        <DisplayPattern>
            <FieldSwitch>
                <Expr>
                    <GetVar Name="FreeForm"/>
                </Expr>
                <Case Value="TRUE">
                    <Field Name="Title"/>
                </Case>
                <Default>
                    <Field Name="_EditMenuTableStart2"/>
                    <Field Name="Title"/>
                    <Field Name="_EditMenuTableEnd"/>
                </Default>
            </FieldSwitch>
        </DisplayPattern>
    </Field>
  <!-- Parent ContentType: Document (0x0101) -->
  <ContentType ID="0x010100922fc480f3ae4beba09c8eb3aec9530a"
               Name="TitleEx"
               Group="Morpheus CTypes"
               Description="A content type with an ECB menu enabled field. "
               Inherits="TRUE"
               Version="0">
    <FieldRefs>
        <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" 
                  Name="Title" Required="TRUE" />
        <FieldRef ID="{566F83FF-CCFE-4f7a-BE3C-332169E040B8}" 
                  Name="TitleEx" Required="TRUE" />
    </FieldRefs>
  </ContentType>
</Elements>

Now if we deploy and use the content type in a document library, my field, TitleEx, is actually displayed as below. There is no value displayed, although there is a value in the Title field.

The reason why there is nothing in this field is the same as what I mentioned in my previous post: SharePoint 2010 now is using XSLT instead of <DisplayPattern> to render the field on the list view. Although I defined <DisplayPattern> for my field, it will never be used. We have to create a custom XSLT to render it.

The following is the XSLT stylesheet I used for my field.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:x="https://www.w3.org/2001/XMLSchema"
                xmlns:d="https://schemas.microsoft.com/sharepoint/dsp"
                version="1.0"
                exclude-result-prefixes="xsl msxsl ddwrt"
                xmlns:ddwrt="https://schemas.microsoft.com/WebParts/v2/DataView/runtime"
                xmlns:asp="https://schemas.microsoft.com/ASPNET/20"
                xmlns:__designer="https://schemas.microsoft.com/WebParts/v2/DataView/designer"
                xmlns:xsl="https://www.w3.org/1999/XSL/Transform"
                xmlns:msxsl="urn:schemas-microsoft-com:xslt"
                xmlns:SharePoint="Microsoft.SharePoint.WebControls"
                xmlns:ddwrt2="urn:frontpage:internal">

    <xsl:template match="FieldRef[@Name='TitleEx']" mode="Computed_body">
        <xsl:param name="thisNode" select="." />
        <xsl:param name="ShowAccessibleIcon" select="0"/>
        <a onfocus="OnLink(this)" href="{$FORM_DISPLAY}&amp;ID={$thisNode/@ID}" 
           onclick="GoToHistoryLink(this, {$thisNode/@_UIVersion});return false;" 
           target="_self">
            <xsl:call-template name="LinkTitleValue">
                <xsl:with-param name="thisNode" select="$thisNode"/>
                <xsl:with-param name="ShowAccessibleIcon" select="$ShowAccessibleIcon"/>
            </xsl:call-template>
        </a>
        <xsl:if test="$thisNode/@Created_x0020_Date.ifnew='1'">
            <xsl:call-template name="NewGif">
                <xsl:with-param name="thisNode" select="$thisNode"/>
            </xsl:call-template>
        </xsl:if>
    </xsl:template>
</xsl:stylesheet>

Now there is a value shown in my field, and it is the same as the value of Title.

The final step is to edit TitleEx in SharePoint Design and enable Show List Item Menu on it. After that, we will be able to see the ECB menu on this field. The result is below. It shows the “Edit in Microsoft Word” correctly.

CTypeTitleEx.zip

In SharePoint Designer, if we select this option and save our changes, the ECB menu will be enabled on this column.

It works very well on the columns in lists. However, there is a little problem when we use this feature on a column in the document library. For example, when I enable the ECB menu on Title of a document library, the ECB menu is displayed as below. ( I also put a screenshot for the ECB on Name column for the contrast. )

It shows “Edit in undefined” instead of “Edit in Microsoft Word” which is expected to be shown. And if I click on this menu item, I got the following error with no surprise, although Microsoft Word has been installed on this machine. 

Why this problem happens is because in SharePoint 2010 the ECB menu is generated and rendered by a set of JavaScript calls dynamically. When in document library, those calls will try to determine the document type with the current column and add a menu item displayed as “Edit in Microsoft Word” or “Edit in Microsoft Excel” etc according to the type returned. For Name column whose field type is LinkFilename, the JavaScript calls can retrieve the file type because this column has a reference to the field FileLeafRef. But for Title column here, since it does not have the reference to FileLeafRef, the calls simply return an undefined.  For some reason, these JavaScript calls work fine with the Name column whose field type is LinkFilename. The document type can be retrieved. But for the Title column, the calls simply return an undefined. Looks like the code does not check whether the returned value is undefined or not, therefore we see “Edit in undefined” in the menu.

This might be a bug of the code. At least an error checking here is necessary. If the returned value is undefined, the ugly “Edit in undefined” should not be shown. But before there is an official fix, actually I have no idea whether it will be fixed or not, is there any way to enable an ECB menu with “Edit in Microsoft Word” on Title column? Well, I am going to answer this question in the part 2 of this topic.

Preparation

In this demo, I am dealing with the following scenario. Say in my org every user has his/her own Personal Identity Number (PIN). When they login to the SharePoint site, in addition to the user credential of AD, I also want them to use their PIN as a double check. I don’t want them input anything except PIN. Here comes how I do it by customizing the login page of the Windows Authentication.

In a Claims-mode web app, the Windows Authentication is handled by /_windows/default.aspx. If we check the path of the virtual folder /_windows, it points to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IDENTITYMODEL\WINDOWS. Obviously, modifying the files in this folder directly is not a good idea. So what I did first is to create another folder, copy all files (default.aspx and web.config) in the above folder to the folder I created, and modify the path of the virtual folder to point to the new folder. I tested the site with the new folder. Everything works fine.

Creating a Customer Login Page

All the same as what I did for the login page for FBA, I created a page using simple.master. Since there is no need for users to input user name and password, a login control is not necessary. Instead, I just put a textbox, a button and several labels on the page. The layout looks like the following.

Creating a Code Behind Class to Handle the Request

I then created a class named as WindowsSignInPage and make it derive from IdentityModelSignInPageBase just like the forms sign in page. Again, I added all necessary assembly references.

Now it is time to write the logic to handle the real authentication. Different from the Forms authentication, in Windows authentication in Claims mode users are not authenticated by /_windows/default.aspx directly. Instead, they are authenticated by an HttpModule, SPWindowsClaimsAuthenticationHttpModule. When a user browse the web site and reaches /_windows/default.aspx, he/she has already passed the Windows authentication performed by that HttpModule. So to force users to input their PIN on the page, we must sign them out first. The following is the code I added in Page_Load.

IClaimsIdentity claimsIdentity =
    HttpContext.Current.User.Identity as IClaimsIdentity;
if (claimsIdentity != null)
{
    CurrentUserLit.Text = claimsIdentity.GetDisplayName();
}
else
{
    CurrentUserLit.Text = HttpContext.Current.User.Identity.Name;
}

SecurityToken token = SPSecurityContext.SecurityTokenForContext(Context.Request.Url);
HttpCookie signInCookie = Context.Request.Cookies["Morpheus_WindowsSignedIn"];
if (signInCookie != null && signInCookie.Value.Equals("true"))
{
    RedirectToSuccessUrl();
}
else
{
    RemoveCookiesAndSignOut();
}

Since the user has passed the authentication of the HttpModule, the identity we get has been an IClaimsIdentity already. Here I check my custom cookie first. If the cookie exists, means the user has input the correct PIN. Otherwise, the user is signed out so he/she must input the PIN first.

The code of RemoveCookieAndSignOut is as below. If you examine the code of Signout.aspx with Reflector, you will see that I am using almost the same logic with it.

private void RemoveCookiesAndSignOut()
{
    // Clear session state. 
    if (Context.Session != null)
    {
        Context.Session.Clear();
    }

    string cookieValue = string.Empty;
    if (Context.Request.Browser["supportsEmptyStringInCookieValue"] == "false")
        cookieValue = "NoCookie";

    // Clear my own cookie.
    HttpCookie cookieWinSignIn = Context.Request.Cookies["Morpheus_WindowsSignedIn"];
    if (cookieWinSignIn != null)
    {
        cookieWinSignIn.Value = cookieValue;
        Context.Response.Cookies.Remove("Morpheus_WindowsSignedIn");
        Context.Response.Cookies.Add(cookieWinSignIn);
    }

    // Remove cookies for authentication. 
    HttpCookie cookieSession = Context.Request.Cookies["WSS_KeepSessionAuthenticated"];
    if (cookieSession != null)
    {
        cookieSession.Value = cookieValue;
        Context.Response.Cookies.Remove("WSS_KeepSessionAuthenticated");
        Context.Response.Cookies.Add(cookieSession);
    }

    HttpCookie cookiePersist = Context.Request.Cookies["MSOWebPartPage_AnonymousAccessCookie"];
    if (cookiePersist != null)
    {
        cookiePersist.Value = cookieValue;
        cookiePersist.Expires = new DateTime(1970, 1, 1);
        Context.Response.Cookies.Remove("MSOWebPartPage_AnonymousAccessCookie");
        Context.Response.Cookies.Add(cookiePersist);
    }

    // Sign out.
    Microsoft.IdentityModel.Web.FederatedAuthentication.SessionAuthenticationModule.SignOut();
}

The final part is very simple. When the user clicks the submit button, I check his/her PIN first. If the PIN is correct, I set the cookie and redirect him/her to this page again so that the HttpModule authenticates the user again.

protected void LoginBtn_Click(object sender, EventArgs e)
{
    // Check whether the PIN is correct.
    if (!string.Equals(pinCode.Text.ToLower(), pinLit.Text.ToLower()))
    {
        ClaimsFormsPageMessage.Text = "The PIN is incorrect.";
        return;
    }

    // Set cookie and redirect to the sign in page
    // so the SPWindowsClaimsAuthenticationHttpModule can sign us in again.
    HttpCookie cookie = Context.Request.Cookies["Morpheus_WindowsSignedIn"];
    if (cookie == null)
    {
        cookie = new HttpCookie("Morpheus_WindowsSignedIn");
    }
    else
    {
        Context.Response.Cookies.Remove("Morpheus_WindowsSignedIn");
    }
    cookie.Value = "true";
    cookie.Expires = DateTime.Now.AddMinutes(1); // 1 minute for testing purpose.
    Context.Response.Cookies.Add(cookie);
    SPUtility.Redirect("/_windows/default.aspx", SPRedirectFlags.Default, Context);
}

Deploying and Testing

To deploy the page, connect the default.aspx and the assembly by adding a <%@ Page %> indicator, put default.aspx in /_windows and the assembly in GAC, and reset the app pool. Then browse the site to see the result.

The attachment is the source code of the demo.

WindowsSignInPage.zip