SharePoint Intranet: How We Did It, Part 2: Home Page

This week, I begin diving into details about what we did to build the SharePoint-based intranet and collaboration environment for NBC Olympics. Last week, I described the environment, the desired outcomes, and the constraints (together, the “requirements”). If you missed that article, catch up with it here.

Among those requirements were an environment that could be immediately usable by hundreds or thousands of employees, with no real opportunity to train, evangelize, or drive adoption. It just had to “work.” Today, I’ll share some of the steps we took to achieve the most fundamental of goals: make the intranet home page easy to get to.

Just for fun, a screenshot of our intranet home page is below. I’ll go into much more detail about the content of the intranet in a later article.

SharePoint Intranet Screen Shot

Before I share these bits with you, I want to point out that nothing we did is difficult, let alone rocket science. We didn’t crack open Visual Studio a single time. So while all of these bits are “easy,” the magic, in my opinion, is that if you put the right easy pieces together, it all works really well.

So let’s start at the beginning: the intranet and the home page. The home page is one of several pages, documents, lists, and libraries that must be visible to all users. It must provide very quick access to all of the other resources users need to get their jobs done.

The rest of the intranet provided access to content that needed to be highly or universally visible (at the “read” level). I emphasize this point only because in some organizations, the term “intranet” is more broadly used to include departmental team sites and other workloads that I consider to be “collaboration,” not “intranet.” So, for me, “intranet” is equivalent to “internal published content site,” as distinct from team sites, business process automation, business intelligence, search, social, extranet, and “apps.”

Intranet Web Application and Site Collection

Architecturally, I configured the intranet as its own web application (http://oly2012.nbcuni.ge.com).  That allowed us to set information management policies for the intranet (versus the team sites, for example) that are scoped at the web app level, such as Anonymous Access (which we allowed for the intranet), and inline PDF viewing.

Anonymous Access: Read
Anonymous Access was a setting I configured in order to ensure that anyone who was on our network could get to the home page, at least. The home page was in a site collection that permitted anonymous access, and all other content in that site collection was appropriate for anonymous “Read” permission. In a later article, I’ll describe some of the “lessons learned” about Anonymous Access, which was the single most common cause of support issues, in fact.

Content Editing: Limited
Like many organizations, we decided to strictly limit who could add, modify, or delete content on the intranet.

In-Browser PDF Viewing
For the intranet web application inline PDF viewing, which I described in a previous article.

Alternate Access Mapping for the Flat DNS Name http://OLY2012

I want users to be able to be told the name of the intranet in a simple, easy-to-remember way. I want to tell users, “Open Internet Explorer and go to OLY2012.”

So, to facilitate easy access, I proceeded to intentionally break “best practices” and configure an alternate access mapping, directly, for the flat URL, http://oly2012.

With my background in Active Directory, networking, and DNS, I will retire still “spanking” people (IT professionals, particularly) who configure anything with a flat DNS name. URLs must be fully qualified domain names (FQDNs) like http://oly2012.nbcuni.ge.com and UNCs must likewise be FQDNs (\server.company.comshare not \servershare).

The reason? The way clients resolve DNS is to use FQDNs. Clients never send a flat name to the DNS server. They send the FQDN. So, if the client is looking for a flat name, they make “guesses” as to what a suffix should be. They add a suffix, send it to DNS, and if DNS can’t resolve the name, they try another suffix.

You can see the configuration of this behavior on the DNS tab of your IPv4 Properties dialog box for your network connection. You can either use the NIC’s DNS suffix or use a pre-defined list of suffices to try; and then you can add what’s called “DNS suffix devolution” to the mix.

In the end, name resolution becomes a total lottery, and can lead to significant performance penalties, as well as downright failures. Only if you tightly manage DNS suffix search order and/or use brand new features like Windows Server 2008 R2’s “flat name” DNS zone can you even begin to hope it all works well, and it’s still no guarantee, because you probably have non-Windows or non-domain-joined systems, or systems that are not under the same scope of management.

So it’s just too risky and problematic, especially in larger, more complex enterprise networks, which NBC certainly qualifies as. And I don’t care that Microsoft uses flat names internally. It’s still not a good practice. Just don’t do it. ALWAYS use FQDNs.

However, FQDNs are painful for users. Telling a user to “type http://oly2012.nbcuni.ge.com” is a pain for support personnel. There’s something elegant about being able to type http://oly2012 instead.

I know organizations (Microsoft seems to be one) that configure SharePoint web apps with flat names. Don’t do it!

The alternative is to do a little magic on the server side. This is my preferred approach, because managing a few servers is much easier than managing hundreds or thousands of client systems, which may or may not be under my scope of management.

The magic entails Alternate Access Mappings (AAMs) and Host Headers. And now time for another caveat: BE CAREFUL. AAMs are one of the single nastiest little configurations in all of SharePoint ville. They are notoriously difficult to understand, to really understand, and to configure correctly.

To make matters worse, the UI makes it very easy to do them incorrectly. Under the hood, in the SharePoint object model, they’re just as bad (or worse). I know some of my esteemed SharePoint colleagues have some great and expert rants about AAMs, and some of the best known folks in the SharePoint field have run into problems with AAMs.

The best practice is not to use them, in my opinion. If they’re absolutely necessary (and there are some technical and information management scenarios that mandate AAMs), create new AAMs only by extending a web application into a new zone (which introduces its own caveats and considerations).

If you need help with AAMs, check out this blog entry and my SharePoint 2010 Training Kit (from Amazon and other retailers). BE CAREFUL.

So now I’m going to break my own guidance. I can do that, because it’s my guidance and I understand the risks. In this case, I want to allow users to type http://oly2012 and get to the home page of the intranet. That’s all.

In this scenario, I added an internal URL to the existing (default) zone, http://oly2012.nbcuni.ge.com. In order to support that direct change, I also had to add a host header to the IIS site, so that IIS would respond to requests for http://oly2012.

No DNS server/zone change is necessary, because clients query for the FQDN, not the flat name, regardless of what the user types. The local DNS client goes through the suffix-adding process mentioned above. I used Group Policy to specify the DNS suffix search order for clients, and I put “nbcuni.ge.com” as the first-listed suffix, ensuring that clients would try to resolve any flat name with the “guess” that the FQDN was flatname.nbcuni.ge.com—a “guess” that was accurate in our environment.

For non-domain clients, the default for Windows is to use the NIC DNS suffix, which is received from DCHP by default. Our DHCP servers were using the scope option for suffix as nbcuni.ge.com, so non-domain clients were “covered” for name resolution as well. But I still used Group Policy for domain-joined clients to ensure that things worked the way I wanted, and to support secondary and tertiary suffices we might want to add to the flat-name-guess list.

The result is that users can use the flat name to get to the intranet—assuming (big assumption) that we’ve managed DNS Suffix Search Order correctly. In our environment, with users and machines coming from all corners of NBC and Comcast, that was a bit of a risk, and most of the time it worked.

Only a few clients could not query correctly for http://oly2012 to http://oly2012.nbcuni.ge.com. Once the DNS client was working, the home page appeared no problem.

Now because I had added an internal URL to the default zone, and did not add a new zone with a new public URL, the address bar immediately changed to http://oly2012.nbcuni.ge.com [the FQDN], and all links were rendered with the FQDN. That’s what I wanted.

As soon as the user had “entered” the intranet with a flat name—a feat I consider lucky—I want all other URLs to use FQDNs. Any emailed links, any bookmarks will therefore use FQDNs.

We had two web front ends in our environment. When you do non-best-practice manual tweaking of AAMs and host headers, you have to manually tweak the IIS site on each server [or script it]. In our case, I added the host header to the IIS site on both servers. I documented the fact that, if one of our servers died, one of the recovery steps would be to check that our recovery software (DocAve by AvePoint) successfully restored the custom host headers.

This configuration took only a few minutes, and only bears a slight risk. However, that’s all the risk I wanted to bear in the area of name resolution and AAMs and host headers. So I did not add similar flat-name first-access capability to our team sites (http://olyteams.nbcuni.ge.com), to our apps sites (http://olyapps.nbcuni.ge.com) or to any other web application.

For those, users would (in theory) have to type the FQDN. But guess what? With thousands of users, I don’t believe a single user typed a URL to anything other than the home page—ever.

People started on the home page, navigated to where they needed to go (which might very well have tossed them transparently into another web application), and then bookmarked the site or (I think more commonly) just used the same one- or two-click navigation every time. I never heard anyone “telling” someone to go to a URL other than “OLY2012,” and perhaps a short description of the navigation from there: “Click the XYZ link under the DEPARTMENTS menu.”

Configure the Home Page as the Internet Explorer Start Page

The final step was to set the intranet as the default home page (Start Page) for our users’ browsers. Unfortunately, doing so led to problems when users were not connected to our network. When a user was on the road or at a venue or in their hotel room, our intranet home page wasn’t available.

So we couldn’t actually push the start page to laptops. However, pushing the start page is something a lot of organizations want to do so let me give you a summary of what I’ve learned about doing so.

First, configuring the start page in Internet Explorer is one of the most “obvious” examples of a policy that organizations want to implement. It’s something almost everyone wants to do.

Second, and most importantly, it’s excruciatingly painful to configure the IE start page. The way Microsoft implemented Group Policies and Preferences for IE over the various iterations of both IE and Group Policy is tragic. Trying to do this across IE versions is awful. And if you ever have to change the start page, it gets worse.

Third, users often rebel. They don’t want the company deciding that every time they open IE it should start at the intranet. They have work to do, and they close that tab without looking at it—only getting more frustrated—or they find some workaround.

So after doing this in a variety of environments, here’s my recommendation for best practice regarding the IE start page: Set it as a default but allow users to change it if they want to. And to actually deploy the configuration, use a REGISTRY PREFERENCE in the USER PREFERENCES component of a Group Policy Object.

Registry Preferences are one of the coolest things ever in Group Policy, in my opinion. They allow you to push a registry entry into one or more users or machines, and you can decide whether you “reapply” the preference over and over (“resetting” a change a user might make back to the desired value) or just apply it once and allow users to make changes thereafter.

So to set a default start page, create or edit a Group Policy Object scoped to the users to whom you want the change to apply. Navigate to User Preferences and then to Registry Preferences. Create a new Registry Item that uses the Update action (which creates or updates the registry value). The registry value you want to configure is this:

Path: HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMain
Value Name: Start Page
Value Type: REG_SZ
Value Data: http://startpageURL

On the options tab, you can configure the preference to apply only once, which means that users will get the setting as the “Default Default” but users can then change it and it won’t get reverted back.

You can also use other configuration methods to drive the start page. If, in the end, you’re poking that registry value, it’s one that users can change.

To lock down the home page (which again, I don’t recommend for normal users and systems), you can use Group Policy. Good luck with that if you have a lot of versions of IE.

What’s Next

So now, our users can get to the intranet home page easily—by typing a simple name (OLY2012) or perhaps through a pushed default start page. They don’t have to be “signed in”—anonymous access is enabled—and they can open important, globally-needed PDFs in browser.

The home page is, as you can see in the screenshot, quite simple and plain. It’s a landing page.

We don’t expect users to spend more than a split second there. It’s the doorway—the portal in the purest sense of the word—to what users really need to get to.

In upcoming blog posts, we’ll look at how we used SharePoint to consolidate numerous resources and apps into a single presentation interface; and how we made it easy for users to find what they needed (navigation). And there’s so much more ahead as we dive into the functional components and architecture of our intranet.

Ready for Part 3 of "How we did it"? Let's go!  And note that you might also want to check out "A SharePoint Intranet in 48 Hours" by Dan Holme.