Tag Archives: Best Practices

SharePoint 2010–Best Practices for Alternate Access Mappings (AAM)

Have I done a soap-box post recently?  Yup, this one. 

There is an awful lot of misunderstanding about the concept of Alternate Access Mappings (AAM) in the SharePoint world.  It seems like every SharePoint consultant I talk to has a different opinion on why and how the AAM setting should be used, with a lot of it boiling down to the old stand-by of “it depends”.  So, this is how I’ve set up my standards so that I always have a certain level of consistency across the farm.

At its most basic level, AAMs are configuration settings set in SharePoint Central Admin that tells SharePoint how to map a web request to the correct web application so that SharePoint can respond with the correct content.  It then tells the SharePoint content engine what zone and URL to use in relative links as users continue to surf that SharePoint site.

The major reason we need this is that there are very common Internet and load balancing scenarios where the URL of a web request received by IIS is not the same URL that the end user entered in their web browser.  There are also various health monitoring tools that will need to try to access the individual WFE to verify that each server is up and responding correctly.  Additionally, we see situations where search driven applications accessed internally and externally will need to work within the same zone in order to return result URLs that make sense in the context of where the site is being accessed from.

Because we can also host multiple web applications within our SharePoint farm, we need to make sure the nomenclature and zones are correctly set up so that when performing a global enterprise search, if a user has accessed the site from the “Intranet” zone, all search result URLs will utilize the other web application “Intranet” zones as well.

When it comes to Public URLs and Internal URLs, what’s the difference?

Public URLs: what the user types into the browser address bar to access the site.

Internal URLs: what load balancers, reverse proxy, NAT and port forwarding devices use to forward a user request to the farm.  This is where you may see individual WFE IP addresses and non-standard ports.

If I change an AAM, why don’t the IIS bindings change to match them?

That would be a cool feature, I’m not really sure why something like that isn’t implemented yet.  For the time being, if you add additional AAMs you’ll need to remote into the WFEs and add the additional bindings to the web applications of your choice.  Don’t forget that if you’re using FQDNs (and you should always have a FQDN for your farm) you’ll need the appropriate DNS entries as well.

Great, I totally understand AAMs.  Now what is best practice standards for how they are set up?

While I can’t speak to every situation, this is generally how I define my zones and set up my Alternate Access Mappings (AAMs).  Default and Intranet should always be used, the rest are of course optional, but whatever naming convention you use, be consistent!

Default: always the FQDN in the form of “http://WEBAPP.Company.com” (or “http://WEBAPP.domain.local” – whatever your FQDN format happens to be )

Intranet: Just the name of the webapp itself in the form of “http://WEBAPP”  It is important to use a single name, without any “.”s in the name, as some windows applications will see “.” in the address and will assume “Internet” zone for the address, which can lead to some interesting authentication issues with Microsoft Office applications.  Resources accessed internally work best with a single name address.

Internet: Almost always prefixed with "WWW” in the form of “http://www.WEBAPP.Company.com” – this identifies the access URL as a public facing or externally accessible site.  Remember there is no magic to using www, it is just a naming convention and you still need to do all the leg work to set up your firewall/NAT/port forwarding.  Seems obvious to some, but you’d be surprised what some non-technical people will assume.

Custom: In all honesty I have never used this field for anything more than specialized one-off URL testing and sometimes for SSL cert verification (which generally should go on the load balancer anyways) or when I’m looking to rename a site for business reasons and want to test out the site using the new URL.  I have never actually seen this field in use for normal production applications.

Extranet: Every company will be different, but I like to use the “PARTNERS” prefix, in the form of "http://partners.WEBAPP.Company.com”, you can use CLIENTS or CUSTOMERS as well, just be consistent in your naming convention, if you do have variations for business reasons make sure the rules are clearly documented.

Great, so I’m all set?

NO!  Whatever you decide to use as standards you absolutely must document them somewhere accessible (like say, SharePoint?) and then get agreement on these standards going forward.  You may have it clear in your head and totally understand how things should be set up, but when you win the lottery or move on to your next gig, if the company doesn’t have a documented standard to refer to going forward all your hard work will go down the tubes.  Entropy sets in and the standards will be diluted by those who come after you unless you leave behind some sort of guiding principles.

SharePoint 2010 Folder Design Best Practices

This is probably one of the biggest banes of a SharePoint Admin’s existence – Folder structure.  It’s important to really lay out a structure that makes sense and is flexible enough for the future.  There are several design considerations when using SharePoint 2010 folders when designing the information architecture.

  1. Importantly and obviously, plan for the number of items that will be organized in each folder. Those items can be moved either manually or it can be automated.
  2. Incorporate features to include the metadata navigation so that the amounts of items in folders don’t have such strict limits.
  3. Use metadata navigation and folder navigation so that the folders are able to be used for policies and retention. This is in addition to the folders being used for organization. Organization of content in folders so that they can be easily navigated as well as combined with other available options for the simplification of navigation.
  4. The content organizer will automatically move the documents into folders base on the metadata. They can also be enabled with the option for creating various sub folders after the limit in a given folder has been reached.
  5. Organize items into folder so that only the list view threshold at the root of the folder is there when you use the Open with Explorer. In order to retrieve content in list views there is metadata navigation and indexing that you can use in addition to the folders.

Organizing the content into folders needs to be done carefully. There are three main methods used for achieving this:

Organize logically – This can be based on month, year, or other types of data like responsible division. Or other stuff. Whatever’s clever.
Metadata – this allows for documents to be routed to the correct folder. This allows for the ability to limit the amount of items in a single folder. Then sub folders are also used when more space needs to be added.
Topic or category – Many users like the idea of being able to find things by topic or category. They are used to such navigation so it seems natural. This is sort of like the first point.

Various improvements for SharePoint Server 2010 allow you to have a flexible use of the folders. You will be less dependent on various performance considerations as well. When you have managed metadata and navigation you can easily filter the data through the folders. This makes it possible for you to organize your information for administrative control. This includes your permissions and policies. You won’t be relying only on the end user navigation.

When the content organizer feature is automatically moved into the folders by content, the metadata users don’t need to decide where to place the content. The content organizer also allows for the creation of new folders after a limit of one has been reached. When you use “Open with Explorer” you have to remember that it doesn’t work with large lists of items if they aren’t organized in folders with fewer items than the list view threshold.

When it comes to folder based view and metadata based views, keep in mind that they are very similar when it comes to how they perform. With a logical user experience then it is sensible to rely on folders to divide your content. With metadata navigation though there are queries that allow for all of the items to be returned outside of the folders.

* Folders do have better performance at smaller sizes of lists.*

Developing SharePoint 2007 – Application Guidance

This guidance helps architects and developers design, build, and test intranet and enterprise-scale SharePoint applications. Two reference implementations demonstrate solutions to common issues, and a library provides reusable components that can help you with your own development projects.

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=13284