Configuring Alternate Access Mappings and IIS Host Headers in Extranet Collaboration Manager (ExCM) 2010

by Matthew McBride

“Allow myself to introduce…myself.” – Austin Powers

I think of the above quote every time I run across this error supporting Extranet Collaboration Manager 2010:

 

(click on images to enlarge)

“Object reference not set to an instance of an object.”  What does that even mean?  Could there be a less intuitive error message?  Actually, don’t answer that….

This is one of the most common ExCM 2010 support tickets I see on a weekly basis.  In almost all cases it is caused by an incorrect Alternate Access Mapping for a zone and/or errors in the IIS Host Headers.

In the SharePoint 2007 world, you were forced to extend an existing Web Application in order to use Forms Based Authentication (FBA).  The original one was configured to use Windows Authentication and the extended one used FBA.  However, in SharePoint 2010 and the introduction of Claims Based Authentication, this is no longer the case.  So almost all installations of ExCM 2010 will look like this in Central Administration:

 

Notice that I only have one “default” zone that can use both Windows and FBA.

If you came from the 2007 world, or if you are just creating a new Web Application for test purposes, you probably just entered something very simple for a host header like this:

http://myserver

In my case I used:

http://demo

There’s nothing wrong with this approach until you decide to open your Web Application to the outside world and create an Extranet.  The intuitive approach to solving this would be to just add a new Alternate Access Mapping (AAM) such as this:

Seems straightforward enough until you actually try to access the URL:

 

Argh!

So what’s the problem and how do we fix it?  The first thing to understand is that each “Public URL for Zone” that appears under AAM MUST correspond to an existing zone for your Web Application.  In the case above, since no “Extranet” zone exists, SharePoint does not know where to direct requests for the “extranet.demo.com” URL.

To work around this, we can do a few things.  The simple solution is to select “Edit Public URLs” and configure the AAM to look like this:

Now if I try the URL again, I get my expected result:

But what if my environment required users or applications to still be able to access the “http://demo” URL?  How can we configure that correctly?  By adding an “Internal URL” like this:

Notice the “Default” zone highlight above.  This is another place I’ve seen administrators get tripped up because the intuitive selection might be something like “Intranet”:

 

 

But we must remember that we still only have the single “Default” zone for our Web Application.  After making the changes, our AAM screen now looks like this:

Observe the “Public URL for Zone” column.  They are identical for both entries.  However, the “Internal URL” values are different.  Any internal request using either Internal URL in that column will be sent to the Public URL.  So, entering either of the URLs below will send us to our site:

http://demo

http://extranet.demo.com

OK…so now we’re getting somewhere.  However, there is one last piece to consider in a real world scenario if we are going to open our site to the outside world…implementing SSL.

For the purposes of this post, I just created a self-signed certificate in IIS and then added a new binding to my site in IIS Manager:

Seems straightforward enough, right?  So let’s try to access our newly secure site:

What the Smurf?  Again, the error message is mostly useless because we know:

a)      That we have a Web Application using the “extranet.demo.com” URL

b)      That we typed the URL correctly

c)      That we just successfully applied an SSL Certificate in IIS

However, the last part offers a subtle clue:

“…the system administrator may need to add a new request URL mapping to the intended application.”

Aha!  It looks like we still need to tweak our AAMs one more time.  In the case of adding SSL, SharePoint still doesn’t know what IIS does…that the “https://” and the “http://” URLs both point to the same place.  So we need to use the AAMs to help it along.  To achieve this, we need to do two things:

-        Change the Public URL
-        Add another Internal URL

First, I will change the Public URL to reflect the secure URL and then add the unsecure URL as an additional Internal URL:

Now, our AAM page looks like this:

So we have three different Internal URLs all pointing to the newly secured site.  Entering any of them will basically do a SSL-redirect to the site:

 

Woohoo!

Hopefully, this will help you understand the mysterious “object reference” error should you run across it in the future.  The two most important things to keep in mind are:

-        Any Public URL entered in the AAM settings MUST correspond to an existing zone for your Web Application

-        SharePoint doesn’t always know what IIS knows, so AAM settings must be used to “teach” it

Good luck! 

Enhancing Site Collection Navigation with Color

by TL Ferrell

SharePoint provides many tools for providing navigation throughout a site collection. Typically, the Top Link Bar near the top of each content page provides links to subsites, and this can be set to persist down through the hierarchy. (This bar is referred to as Global Navigation in SharePoint Standard and Enterprise.) The Quick Launch Bar on the left (called Current Navigation in Standard and Enterprise) typically provides links to lists, libraries, and other content within the subsite.

A Tree View is also available in addition or instead of the Quick Launch Bar. Finally, links may be placed manually on the Top Link Bar or Quick Launch Bar, or may be placed anywhere on a page via a Links list.

In addition, SharePoint provides navigational aids through the Browse menu and the breadcrumb navigation path found on every page.



 

These tools can help you understand where you are in a hierarchy. However, the Top Link Bar on a subsite might not inherit from the parent site, and in that case the breadcrumb and Browse menu won’t provide a complete drill-down trail. In addition, in large site collections it can be easy to get lost in the hierarchy when you start clicking around.

One technique that can help users stay oriented is to use site colors as visual cues. While we teach look and feel customization in our courses Introduction to SharePoint 2010 – Using SharePoint Foundation 2010 and Introduction to SharePoint 2010 - Using SharePoint Server 2010, this post will show how these features can be used not just for their own sake or general branding purposes, but to enhance the user experience.

In SharePoint Foundation, you are limited to the built-in themes for color (and font) schemes; SharePoint Standard and Enterprise allow customization of themes on an element-by-element basis. Of course, in any of these editions, custom themes or CSS code can be developed to accomplish even greater customizations.

In the site collection example, there is one top-level site and six subsites; many of the subsites have additional subsites, some for several levels. The goal is to make each branch of the hierarchy visually distinct, to help users understand when they are in the HR branch versus the Marketing branch, for example. Users rarely start at the top level and drill down. So, this technique may be especially helpful when users follow a link posted somewhere or sent to them in email, or even when using a bookmark they’ve made.

The first two examples below use only the built-in browser-based tools to apply strongly contrasting schemes.

The first option, available to all editions of SharePoint, is to simply choose a different Theme for each branch. The top-level site of this site collection retains the Default theme. The Administration branch also retains that theme.

Here’s an example of what the other branches might look like after applying different built-in themes.

The problem, though, with using the different out-of-the-box themes is that the site collection gets a higgledy-piggeldy look, with no unifying look and feel. In addition, the site collection may have more branches than can comfortably be differentiated by themes, given that some themes may not be suitable for a number of reasons. Also, themes include font choices, and it may not be desirable to have different fonts in various areas of the site collection. Environments which have SharePoint Foundation only may need to turn to custom solutions in those cases. Environments with SharePoint Standard or Enterprise have another option.

By applying one of the built-in themes throughout the site collection, and then tweaking the dominant colors for each branch, it is easy to create unique, but unified looks for the entire site collection. Once a color palette has been chosen (or borrowed from one of the many color scheme sites on the Internet), it’s a simple matter to change the individual color elements that make up a theme to create a custom theme. To make the examples below, I started with the SharePoint Default theme. (For step-by-step directions for this process, stay tuned for a future blog post in the SharePoint Solutions Help Community Blog.)

(Note that these color schemes are not meant to be examples of excellent web design, but just to illustrate the point of visually differentiating branches of the site collection.)

Many of these subsites have subsites themselves, and the custom scheme for that subsite is inherited throughout the hierarchy. So, the color scheme for the entire site collection looks something like this:

On corporate web sites, the color schemes might already be mandated and set up for the entire site collection (or site collections), but even then there may be room for variation that can help users. In the case of a site which adheres to corporate branding standards, such customization would be simple to tweak to provide the types of variations that would provide visual cues. For example, if the dominant corporate color is dark green with accent colors of gold and black, different combinations of those three colors, including shades and tints based on those colors, could be used as dominant and accent colors.

Another option is to simply change the site icon in the upper left corner. Again, there may be corporate standards regarding the logo, but usually certain variations can be allowed or developed. In our example, a simple two-color line drawing is an accepted variant of the logo. Using the same color schemes described above, alternate versions of the logo can be created and used to replace the default SharePoint icon at the top of each page while retaining a single theme throughout the site collection.

Configuring Global Registration Fields in Extranet Collaboration Manager (ExCM) 2010

by Matthew McBride

Registration is one of the core concepts in Extranet Collaboration Manager 2010.  It represents the main advantage of ExCM over other SharePoint Extranet Management tools.  There are two types of Registration -- Anonymous and Invitation.  The most common, by far, are the Invitation Registrations.  You send an e-mail to a potential new user, the click on the Registration link provided and then are taken to the custom Registration Page on your site.  Here is an example:

 

(click on images to enlarge)

 

This page can be completely customized to capture the data you want from your users.  In the example above, we are capturing the following (field type in parentheses):

·        First Name (Text)

·        Last Name (Text)

·        Company Name (Text)

·        Job Title (Text)

·        Phone Number (Text)

·        Zip Code (Text)

·        Captcha (Captcha)

·        Site Policy (Policy)

In addition to the field types above, you can also implement the following field types:

·        Description – Provides a way to enter lines of text for descriptive or informational purposes

·        Choice – Presents selections as either a drop down, radio button, or checkbox

There are two ways you can edit the fields that appear on the Registration Page: by Site Collection via the User Interface (UI) and globally via the web.config file.  In most cases, you will want to capture certain fields on every site (First Name, Last Name, Company Name, etc.), so it makes sense to configure those globally and add the more specialized fields (Captcha and Policy) via the UI.  However, what if you were running ExCM on hundreds of sites?  It would be very time consuming to go into each site and configure the additional fields.  In that case, you would want to choose the common fields for ALL your sites and configure them globally.  In this blog, we will look at how to configure all the field types globally via the web.config file.

First, let’s take a look at the area in the web.config file for the content site where the global Registration fields are declared.  Here is the provided tag example from our help site:

This example includes First Name, Last Name, Company Name, Job Title, and Phone Number by default, and all are both of the type “text” marked as “required” with the following elements:

fieldType="Text"

isRequired="true" 

The “name” of the field (how it will appear on the Registration Page) is declared in this way:

add fieldName="First Name"

Now, let’s take a look at how to add the additional field types here in the web.config file so that they are available globally.  First, here are examples of the remaining three types:

Description

<add fieldName="Description" fieldType="Description" description="Enter the characters you see." />

Captcha

<add fieldName="Captcha" fieldType="Captcha" isRequired="true" imageStyle="Basic" />

where imageStyle="Basic\GreenDiagonals\PurplePlaid"

Choice

<add fieldName="State" fieldType="Choice" isRequired="true" displayType="DropDown" options="AL,AK,AS,AZ,AR,CA,CO,CT,DE,DC,FM,FL,GA,GU,HI,ID,IL,IN,IA,KS,KY,LA,ME,MH,MD,MA,MI,MN,MS,MO,MT,NE,NV,NH,NJ,NM,NY,NC,ND,MP,OH,OK,OR,PW,PA,PR,RI,SC,SD,TN,TX,UT,VT,VI,VA,WA,WV,WI,WY" />

Policy

The Policy field is a little more complex because it typically contains HTML content, which is invalid in an XML attribute.  As a result you, we will need to add the policy message content to a resource file (.RESX) and place it in the App_GlobalResources directory of the IIS site.

<add fieldName="Policy" fieldType="Policy" policyLabel="Resources:mycompany,RegistrationField_PolicyLabel" policyMessage="Resources:mycompany,RegistrationField_PolicyMessage" />

We have provided a zipped collection of files for use with Global Policy Fields that can be downloaded from here:

In it, you will find the following files:

Note that I have also used “ACME” in the sample config files to remain consistent with the blog post.  In your case, you will basically want to replace all instances of “ACME” with your company name.

The first is the resource file itself.  This is where we will enter the HTML changes we want to make for the Policy Field. The next is a sample anonymous master page that I will use for this blog.  In my environment, I have Anonymous Access turned off on both my Web App and IIS for this site, so I will need to reference this anonymous master page to allow the users to see the Policy Field.

The third is a text file that simply contains the HTML portion of the resource file to make editing easier.  Decoded, it looks like this:

The “policy_web_config” file is the Policy Field tag that will need to be added to the content site web.config file for the Registration Field as mentioned earlier:

<add fieldName="Policy" fieldType="Policy" policyLabel="Resources:ACME,RegistrationField_PolicyLabel" policyMessage="Resources:ACME,RegistrationField_PolicyMessage" />

Finally, “PrivacyStatement.aspx” and “ServiceAgreement.aspx” are sample files we can edit to suit our needs.  For the purpose of this blog, we will only configure the Service Agreement.  The configuration of the global Privacy Statement would follow the exact same steps.

The first thing we need to do is create a folder in the 14 hive to store our custom Policy.  By default we would create it here:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS

In this case, I will create a folder named “ACME”:

Once it’s created, we need to copy the following files from the zip file into our new directory:

Now we need to edit the “ServiceAgreement.aspx” file to reflect our customizations.  I have highlighted the areas I changed below:

The first change I made was to reference the “anonymous.master” master page due to my environment configuration.  Next, I gave the header the name “ACME Service Agreement,” and did the same for the PageTitle and PageTitleInTitleArea tags.  Finally, I put a very brief custom agreement in the “descriptiontext” tag.

Next, let’s make the necessary edits to the included resource file.  The area we are looking for is at the bottom of the file:

The full text as it appears there is as follows:

<data name="RegistrationField_PolicyLabel" xml:space="preserve">

    <value>I accept</value>

  </data>

  <data name="RegistrationField_PolicyMessage" xml:space="preserve">

    <value>Clicking &lt;STRONG&gt;I accept&lt;/STRONG&gt; means that you agree to the &lt;A href=&quot;javascript:ShowPopupDialog(&#39;/_layouts/ACME/ServiceAgreement.aspx&#39;)&quot;&gt;service agreement&lt;/A&gt; and &lt;A href=&quot;javascript:ShowPopupDialog(&#39;/_layouts/ACME/PrivacyStatement.aspx&#39;)&quot;&gt;privacy statement&lt;/A&gt;. </value>

  </data>

Notice I have simply changed the path from “/SPSolutions/ExCM” to reflect our newly created folder “/ACME.”  Once the changes have been saved, we just need to copy the resource file to the “App_GlobalResources” directory under our content site:

The final step is to add the Policy Registration Field in our web.config file using the “policy_web_config” example from the zip file.  This will make it globally available to all Site Collections in our Web App:

In addition, I will also go ahead and add the rest of the global field types we mentioned at the beginning of this post:

Now we’re ready to take a look at the update Registration Page with our Global Fields:

And here is how our customized Service Agreement now appears:

As mentioned earlier, you can follow the same steps to also customize the Privacy Agreement.

Prove You're Not a Robot

By Randy Moody

Okay.  So I went to my favorite URL shortener site to trade in a long Internet address for a short one.  And they did it to me again!

Before they would surrender my short URL, they stipulated that I must first enter a string of characters to prove that I am a human being and not a robot.

First of all, is this really a problem?  Have I been missing something in the news?

Are Internet robots now randomly shortening URLs willy-nilly with malicious intent all over the Internet? 

Is it causing people difficulty to the point that hard-ball defensive tactics must now be employed?

INTERNATIONAL GANG OF INTERNET ROBOTS APPREHENDED –
THOUGHT RESPONSIBLE FOR THOUSANDS OF SHORT URLs!
Anti-terrorist ties suspected.  Congressional investigation pending…

What, exactly, would be the downside to lots of shorter URLs? 
Our fingertip typing callouses might begin to soften? 
Broken finger nails might grow back?

Second, my URL shortener site always presents me with a string of characters that no human being could possibly identify – to prove that I am human.  Is anybody else seeing the irony here?
(By the way, these ARE real unaltered screen shots.)

That shorter URL could simplify things a lot for me and our customers. 
But first, I have to overcome the obstacle of deciphering something I don’t understand.

SharePoint is like that. 

If you know how to use it effectively, it can streamline your work and make your productivity soar! But if you “can’t figure it out,” SharePoint becomes an obstacle to productivity – a hindrance instead of a help.

Nobody is ever going to come along to help me decipher that string of characters.  I’m just going to have to keep pushing that “Different Text” button until they show me one that looks like real letters. And with every click I’m losing daylight.

But WE can certainly help you with SharePoint.  We’ve been demystifying this very complex but very powerful product for office professionals for nine years.  We can have you proficient and confident in just 2 to 4 days. And we promise to always treat you like a human being.

Reduce Administrator Workload Using Extranet Collaboration Manager for SharePoint 2010's (ExCM) "Site Sponsors" Feature

by Matthew McBride

Extranet Collaboration Manager (ExCM) 2010 has the ability to greatly reduce the workload on your IT Department by implementing what we call “Site Sponsors.”  Site Sponsors can be either Windows or Forms Based Authentication (FBA) users, and are basically users with some elevated privileges who are capable of managing the Extranet Users for a given site.  Let’s take a closer look at Sponsorship and how it’s configured.

We access the Site Sponsors options under the “Extranet Management” menu located in Site Settings:

From that screen we can see any existing Site Sponsors as well as the options for managing them:

For this blog, we will create a new Site Sponsor.  Let's assume that the AMCE Corporation is a client of ours who uses our extranet to access information important to them.  We will create a new Site Sponsor, a user from the ACME Corporation, and make him responsible for managing all the ACME users who access our extranet.  This is an “extreme” example of Sponsorship (since this sponsor is outside the company), but I believe it illustrates the feature nicely. Now, let’s take a closer look at how Sponsorship is configured.  After “New Site Sponsor” from the ribbon, the screen below is presented:

First, I will select a user to be the Site Sponsor.  I will stick to using Extranet Users for the purpose of this illustration:

Next, we need to configure our Security Settings.  This is probably the least understood topic when using Sponsorship, so let’s take a close look at each area.  The first area is the “Associative Security Definition.”  These are the SharePoint Groups and/or Extranet Roles to which every user this Sponsor invites to the site will automatically be added.  In this example, I have created a role name “ACME Members” and added that Role to this site’s “Visitors” SharePoint Group.  By entering “ACME Members” in this area, every user that Timmy invites will automatically be added to the “ACME Members” Role and will therefore have basic read-only access since the Role has been added to the site’s “Visitors” group.

The next area is the “Optional Associative Security Definition.”  Any SharePoint Group and/or Extranet Role entered here will be presented as checkboxes to the Sponsor when he invites users to the site.  In this example, I have entered another Role I created named “ACME Managers” that has greater privileges than the “Members” Role because I have added it to the site’s “Owners” SharePoint Group:

Finally, we have the “Administrative Security Definition.”  This includes the Groups and/or Roles that the Site Sponsor can manage.  When we say “manage” in this situation, we are referring to specific permissions the Sponsor has been granted.  Here are the possible permissions that can be assigned:

All of these are checked by default, but you can customize them to your specific needs.  The best practice for the “Administrative Security Definition” is to add any Groups and/or Roles that appear in the first two Security Definition boxes.  This ensures that any user the Sponsor Invites, he can also manage:

Finally, we have the “Include Site Groups” option.  When this is set to “Yes,” any SharePoint Groups the Sponsor is currently associated with for the site will be included in both the Optional and Administrative Security Definitions.  For this example, I will select “No” in this area:

Now that we have successfully created a Site Sponsor, let’s log into our site as that Sponsor and invite a new user from the ACME Corporation.  Here are the new options that the new Sponsor sees when clicking “Site Actions:”

From here, they can both invite new users and manage existing users that they sponsor.  After clicking on “Invite Users,” we see this:

Notice the “Site Access” area.  As you can see, the “Optional” Security Definition appears here to allow the Sponsor to optionally add the new user to the Groups and/or Roles specified…along with the “Associative” Security Definition to which they will be added automatically (ACME Members in this case).

After clicking “Save,” the invitation is sent to the new user.  When they open it, here’s what they see:

After completing the registration, we can review it under the “Invitations” area of the Extranet Management menu.  Notice the “Sent By” and “Security Definition” areas:

So we can see that this invitation was sent by our new Site Sponsor, and that Jeremy was also added to the appropriate Security Definitions.

The last area we’ll review here is the “Manage Users” screen for the Site Sponsor.  After logging back in as my new Sponsor and clicking “Site Settings – Manage Users,” we see this:

From here, the Sponsor can do things like create new user (via invitation or manually), grant and remove access, change a user’s password, etc.  Notice that we see an additional user than the one we just invited.  This is due to the “Administrative Security Definition.”  The other user (Tony) is also a member of the ACME Members and ACME Managers Roles, so our new Sponsor can also manage him.

Site Sponsorship gives IT administrators the ability to offload basic extranet administration tasks to capable, responsible users, freeing up their time for important IT work, and reducing IT labor costs.