Investing in logical architecture design samples
Greetings, my name is Brenda Carter. I am a technical writer who writes content for the IT Pro audience about Office SharePoint Server and Windows SharePoint Services. The purpose of this blog entry is to tell you about the investment that the content team is making into logical architecture samples to help you design solutions based on Microsoft Office SharePoint Server.
The first completed sample is for a typical corporate deployment. This sample design includes:
§ Intranet sites (My Sites, team sites, and published intranet content)
§ Partner Web site
§ Customer Web site (including content deployment across server farms)
You can download the architecture design sample and read the corresponding article online.
In this blog entry, I’m going to discuss the philosophy behind the design sample and discuss a few of the tricky design questions you’ll need to solve for your own designs. I’ll also invite you to let us know what other types of design samples you’d like to see.
First, I’d like to acknowledge the members of the product and marketing teams who contributed to this design, including Keith Bankston, Steve Tullis, Mark Grossbard, Troy Starr, Joel Oleson, Vijay Krishna, Ambrose Treacy, Greg Mattox, Jeff Wierer, Robert Silver, and Samantha Robertson. I’d also like to thank the folks from the field who provided input, including Larry Kuhn, Steve Peschka, James Petrosky, Ferla Geckin, John Nisi, and Harikumar H. As you can see, the sample design was produced as a collaborative effort across teams and feature specialists.
Office SharePoint Server 2007 introduces many new capabilities and is much more flexible than Office SharePoint Portal Server 2003. In other words, you’ll have plenty of opportunities to develop your complexity skills. The purpose of investing in logical architecture content is to tackle some of the complex and interrelated design questions that are most common. Hopefully, this will reduce the number of complex design questions you need to answer on your own. The design sample is provided as an editable Visio file to give you a jump start on your own design.
The included (attached) diagram is an abbreviated version of the completed design sample.
Philosophy and Design Goals
On the content team, we spend a lot of time writing about the individual features and components of software. The philosophy behind this design exercise is to do the opposite: to combine the logical architecture components into a configuration that produces a workable model, then talk about how the features and components work together. The accompanying article discusses the design goals and tradeoffs of various interrelated decisions, including contrasting some of the alternative choices.
Another big part of our design philosophy is to create a pluggable design. The design incorporates the most common types of sites and allows access to the most common classes of users. By following a similar design, you can plug in the pieces that are important for your organization without changing the overall design. If you decide to add additional pieces later on, you’ve already created a framework for these pieces. For example, your initial design might only include My Sites and team sites. By starting with a design that is similar to our sample design, you can efficiently deploy these pieces and still leave the door open to plug in the rest of the pieces down the road.
Finally, we went to great lengths to produce a design that is Internet ready. You can plug the design into a perimeter network or simply make sites available through an edge firewall. You can start by allowing only internal employee access to sites initially and then enable access to remote employees, partners, and customers later. The security and isolation for accommodating these different classes of users is built into the model. By starting with a design that is similar to the sample design, you create the opportunity to invite each of the classes of users to participate in sites without having to re-architect the design.
Design Questions that Deserve Extra Consideration
The sample design illustrates design choices for each of the logical architecture components: users, zones, authentication, Shared Service Providers (SSPs), administration sites, application pools, Web applications, site collections, content databases, URLs, and policies for Web applications. Although the article discusses planning considerations for each of these components, I’ll use this blog entry to alert you to a few of the trickier components to pay attention to.
Planning for user access
The greatest challenge of the design was planning for the various classes of users. Fortunately, I discovered some friendly clip art on Office Online to represent our users and this helped us to visualize our task. Planning for user access involves coordinating zones across the server farm and planning for authentication.
A key design choice is to configure remote employee access through the Default zone. In fact, the Default zone requires the greatest amount of consideration. Office SharePoint Server 2007 places the following requirements on how the Default zone is configured:
§ When a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied. Consequently, the Default zone must be the most secure zone.
§ The index component requires access to content through at least one zone to crawl content. By default, the index component uses NTLM authentication and attempts to index content through the default zone first. There are ways to work around this behavior. You can find more information in the supporting article. Also see Plan authentication methods.
§ Administrative e-mail is sent with links from the Default zone. These include e-mail to owners of sites that are approaching quota limits. Consequently, users who receive these types of e-mails and alerts must be able to access links through the Default zone. This is especially important for site owners.
§ Host-named site collections are only available through the Default zone. All users who are intended to access host-named site collections must have access through the Default zone.
In the model, the Default zone is used for remote employee access for the following reasons:
§ Employees can access links in administrative e-mail regardless of where they are located.
§ Internal server names and URLs are protected from being exposed when the zone associated with a user request cannot be determined. Because the Default zone is already configured for remote employees, URLs do not expose sensitive data when this zone is applied.
Another key design choice is the configuration of authentication for remote employees. The article contrasts two choices:
§ Forms authentication using an LDAP provider to authenticate against the internal Active Directory domain controller. The caveat to this choice is this: if users connect to sites both internally and remotely, two different user accounts are created in Office SharePoint Server 2007. That is, one account represents the user when using Windows authentication and a second account represents the user when using forms authentication. Consequently, both accounts require permissions to sites and documents.
§ Integrated Windows authentication using NTLM. This method relies on using ISA Server 2006 to authenticate users and then to send the user credentials to Office SharePoint Server 2007. ISA Server uses forms authentication to authenticate users against the Active Directory environment. ISA then forwards the Windows credentials to Office SharePoint Server. This approach does not result in two different accounts for users who work both internally and remotely, greatly simplifying permissions management. This method also simplifies the management of crawl rules as the default crawl behavior works with this configuration.
After planning for the Default zone and remote employee authentication, planning for the rest of the zones and authentication methods is straightforward. In the sample design, partners access sites using forms authentication. This requires a separate directory and provider, such as a Microsoft SQL Server database and provider, to store partner accounts in the perimeter network. The advantages of this approach are that you can manage partner accounts separately, and you do not need to add partner accounts to the internal employee directory. Authentication for the remaining classes of users is predictable.
The final design point to emphasize when planning for user access is to ensure that your zones and authentication are mirrored across the Web applications in your environment. This is especially critical for Internet-facing sites where user requests are initiated from different networks and where each class of user might be participating in sites across multiple Web applications. The configuration of authentication and the intended users should be the same. However, the policies associated with zones can differ across Web applications. In the model, the Default zone for each of the Web applications is configured identically for remote employee access. Additionally, the Intranet zone is configured identically across all Web applications for internal employee access. The Extranet zone and the Internet zone are each configured for only one Web application.
For more information about planning for Internet-facing sites, see the following TechNet articles:
§ Design extranet farm topology — Illustrates and describes the supported topologies for Internet-facing server farms.
§ Plan security hardening for extranet environments — Details the hardening requirements for an extranet environment in which a server farm is placed inside a perimeter network and content is available from the Internet or from the corporate network.
Planning for Partner Collaboration
The design sample incorporates the use of two farms: one for intranet content and one for customer-facing content. This is necessary to satisfy licensing requirements. Given the licensing options, the design choice to pay attention to is deciding which farm hosts content for partners. In the model, Server Farm A hosts the intranet content and Server Farm B hosts the Company Internet site. According to licensing terms, either farm can host Partner Web.
Given a choice of the two farms, general design guidance for determining which farm should host content for partners includes the following:
§ Nature of collaboration — If the primary purpose of a partner extranet site is to securely communicate information to many partners, an Internet server farm is the most economical choice. On the other hand, if the primary purpose is to work collaboratively with a small number of partner employees, an intranet server farm might be a better choice. Choose the option that enables you to optimize the farm for its intended role (that is, collaboration vs. read-only content).
§ Number of partner employees — If you collaborate with many partner employees and minimizing cost is important, you can securely host both collaborative and anonymous content on an Internet-facing farm with the Internet sites license.
In the model, Partner Web is intended for intensive collaboration with partner companies, including developing and staging the company Internet site. Placing Partner Web on Farm A allows the organization to optimize each of the two farms for their intended use (collaboration vs. read-only content).
For more information about choosing the appropriate number of farms for your organization, including more information about licensing requirements and options for hosting partner sites, see Plan for server farms.
Planning for SSPs
SSPs are used to isolate content based on audiences. For example, if your server farm hosts sites for more than one class of users, separate SSPs can help create isolation between these classes of users. The design article additionally recommends configuring SSPs to either enhance information sharing across multiple Web applications or to further isolate content within a single Web application. The two different approaches are discussed in the article.
Briefly, the design uses the first approach to unify the three intranet Web applications under one SSP. This provides for personalization and enterprise-wide search across all of the applications. This choice provides an example of balancing process isolation (separate Web applications and application pools) with the business need to share information and leverage profile data across the applications.
The second approach is used for the Partner Web site. Using a dedicated SSP for the Partner Web ensures that partner users cannot search on or access sensitive information within your intranet environment. The SSP can be configured to further isolate content between site collections in the following ways:
§ Limit search scopes to the individual site collections.
§ Use audiences to target content to certain groups of users.
§ Use the Stsadm command-line tool to configure the People Picker to display only users that are members of the site collection.
When you design your SSP strategy, consider the ways in which you can configure the individual services within an SSP to enhance your overall content sharing or isolation goals.
Site Taxonomies and URLs
When you plan for sites and URLs you’ll need to make a series of decisions. Each decision can increase or limit design choices in other areas. The first decision to make is whether to use path-based sites or host-named site collections.
Path-based sites are the traditional sites that you create using Central Administration. If you choose to use path-based sites, you are limited to a single root-level site collection within a Web application. However, you can use managed paths to create “top-level” sites beneath the initial root-level site collection. The primary advantage to using path-based sites is that these sites can be accessed from any zone that you configure. Also, the alternate access mappings feature works with all path-based sites. The alternate access mapping feature provides support for off-box termination of Secure Sockets Layer (SSL), which enables the remote employee access and partner access scenarios to use SSL (https).
Host-named site collections are popular among hosters. These sites are created using the Stsadm command-line tool. You can create many root-level host-named sites within a single Web application. Host-named site collections give you more control over URLs. However, there are tradeoffs. First, host-named sites are only available through the default zone. Users who are configured to authenticate through alternate zones cannot access host-named sites. Second, the alternate access mappings feature does not work with host-named sites.
The design sample incorporates the use of path-based sites. Given the requirement for a root-level site collection, the design decisions for these Web applications revolve around the second tier of site collections. Managed paths are used to incorporate a second tier of top-level site collections. When you create a managed path, you can choose to implement either an explicit inclusion (allows you to assign an explicit URL that is appended to the path) or a wildcard inclusion (automatically assigns a path name). The model incorporates both options based on the nature of each Web application. Generally, use an explicit inclusion when you want to control the URL name (for example, to incorporate team or department names into URLs). Use a wildcard inclusion when you want to provide Self-Service Site Management (allow users to create sites) and the URLs are not important or when you want to scale to hundreds of site collections in a Web application.
In a corporate environment where you are providing access to multiple classes of users to content in multiple Web applications, it is important to coordinate URLs across the sites. The following goals for the design sample influence design decisions for URLs:
§ URL conventions do not limit the zones through which content can be accessed.
§ The standard HTTP and HTTPS ports (80 and 443) can be used across all applications in the model.
§ Port numbers are not included in URLs. In practice, port numbers are typically not used in production environments.
The design sample and corresponding article both articulate URLs across the environment to meet these goals.
As you plan for your site taxonomies and URLs, prioritize your design goals and then evaluate the tradeoffs of each option. Use the guidance in the article to get started with your plan.
Additional Logical Architecture Content
In the spirit of constructing a pluggable design sample, we have published a couple of articles to help you design the pluggable pieces:
§ Design My Sites architecture
§ Design logical architecture for collaboration sites
§ Design Records Center architecture
The purpose of each of these articles is to walk you through the specific logical architecture design decisions that apply to each of these types of sites. Take a look and let us know what you think.
What’s Next?
What’s next? You tell us. First, let us know if you like this approach. If you find it helpful, let us know what additional design samples and guidance you would like to see. Here are some ideas for sample designs:
§ Academic institution such as a university or school district
§ ISP or corporate hosting
§ Centralized state government hosting multiple government agencies
Also, let us know if you’d like to see additional articles for pluggable pieces.
