TE2008 Session Notes: Planning and Implementing Global MOSS 2007 Deployments

The next session I attended was given by Doron Bar-Caspi, Mike Watson, and Joel Oleson. It gave a great overview of things that need to be considered when implementing SharePoint across a WAN. The session covered the various deployment options, suggested information architecture, and gave tips and best practices to handle LAN performance testing.

Geographically-Dispersed Portal Challenges

• Cost vs Usability
• Bandwidth can be bought but latency is bound to the laws of physics
• User experience when accessing information across the WAN

General Options

1. Central Model
2. Central with Regional Portals Model
3. Distributed Model

Global Scale Search

Search Options:

1. Index centrally for everything. Impacts the WAN due to indexing but this can be throttled on the index server.
2. Index regionally for regional users. Each region hosts its own SSP. Results in two crawls but can be optimized for search

Federated Search:

New option, part of Microsoft's new Search Engine (which uses the SharePoint Search engine).

MOSS can now get results from remote search servers

My Sites

Usually SharePoint services are centralized

TIP: Consider synchronizing user profiles using custom solutions

Distributed model

Local portals handle everything including their own searching

Legal requirements can force this due to restrictions on data storage and use

TIP: WAN accelerators can help improve perceived performance when accessing information from other portals

Optimizing Authentication

NTLM is faster for smaller sessions, but Kerberos is faster for longer sessions.

Kerberos packets are larger, NTLM is easier to support and troubleshoot.

Which Topology to use?

• Know your usage profile
• Know your network
• Test from remote offices

TIP: Be aware that most work is done in My Site or project sites.

Best Practice: Evaluate bandwidth and latency before choosing a global deployment model. Also look at network maps first to decide whether hub and spoke model already exists.

TIP: Bandwidth and latency data was added to the Capacity Planning tool BEFORE the SharePoint model was added; therefore the calculations may not be fully representative of real world scenarios

Best Practice: Use ping to test latencies – using scripts to test at various times to develop a realistic understanding of network performance.

Consider end to end perceived network performance. Don’t assume anything: issues can be browser, computer, router, or network related

TIP: Use Fiddler to help assess network activity from SharePoint.

TIP: If you use the Business Data Catalogue it can be problematic because it makes big calls to SQL – no batching currently

Codeplex has a data population tool and whitepapers on managing geographically-dispersed SharePoint farms.