Intranet, Extranet and Internet best practices. (Steve Smith, Spence Harbar)

• If you need an extranet, VPN could be an option.
• If you have 2 Web Front End servers, one for Intranet and one for Internet, keep both web applications on both servers, it’s easier to update.
• Web Application Best Practices:
  • Don’t allow servers to access the internet.
  • 64 bit hardware.
  • Use Network Intrusion Detection (Host based detection causes extra server load).
  • Consider Transport Layer Security(SSL, IPSEC) between servers carefully, it’s complex.
• SSL Best Practices:
  • Offload from SharePoint.
  • Sticky session on NLB (see white-paper on combined knowledge site).
  • Use port 443.
  • Use A Records in DNS.
  • Use fixed IP Addresses.
  • Use SSL for Central Administration (password sent over the network).
  • ForeFront Anti-Virus for SharePoint.

SharePoint as an SOA platform. (Brad Smith)

• Service boundaries are explicit.
• Services share schema and contract not class.
• Service compatibility is determined based on policy.
• Services are autonomous.
• SOA is a system design strategy, not a technology.
• Use it when there are environmental boundaries.
• When?
  • Geographical distributed locations.
  • Multiple pre-existing applications or data stores.
  • Continuity of operations.
  • Maintenance cost reduction.
  • Interoperability.
• Why not?
  • SOA strategies can be expensive.
  • You need architects.
  • Lots of code.
  • Do you need distributed computing?
  • Other option is Enterprise Application Integration.
• SharePoint SOA:
  • Federated search, records center.
• What is need to make the SharePoint platform an SOA?
  • Node Topology Service.
  • Service Discovery Service (UDDI).
  • Content Definition Service (format).

Deploying SharePoint sites through multiple environments. (Chris O’Brien)

• http://sharepointnutsandbolts.com
• A site is a mix of .NET and SharePoint artifacts:
  • Files / assemblies.
  • SharePoint schema (content type, site columns, …).
  • Content.
  • Configuration.
• Goals:
  • Repeatable (should be able to rebuild from scratch).
  • Predictable.
  • Acceptable packaging efforts – automation scale.
  • Documentation is critical.
• Features:
  • Pro:
    • Classic approach.
    • Fairly rich framework.
    • Provision files as ‘uncustomized’.
  • Con:
    • Deals with schema only, not data.
    • Steep learning curve.
    • Code often required for updates (featureActivationReceiver).
• STSADM export:
  • Pro:
    • Very simple to use.
    • Site collection/web schema and data.
    • Can be scripted.
  • Con:
    • Doesn’t allow setting of certain switches.
    • All objects given new ID’s (listview web part and infopath problems).
    • Bi-directional can cause problems.
    • Is not a backup/restore solution (alert, audit trail, log, recycle bin, workflow tasks/state are not copied).
• Content deployment wizard:
  • Pro:
    • Same as STSADM + more switches e.g. retain ID’s.
  • Con:
    • Files are deployed as customized.
    • Bi-directional can cause problems.
    • Need to understand capabilities.
• Kivati Studio
  • Pro:
    • Package updates into .exe.
    • Nice structure for e.g. content type updates.
    • Workflow designer type op editor, allowing reuse.
    • Can write custom code if no built-in task is available.
  • Con:
    • Fairly steep learning curve.
    • Potential lock-in.
    • Doesn’t move data.
• Choosing a method:
  • Features are generally the best option.
  • Type of solution:
    • Single site = wizard.
    • Multiple sites = feature.
  • Packaging experience, timeframe.
  • Frequency/type of update, more code for updates.
  • If multiple developers consider team development model:
    • Isolated developers.
    • Development farm.
• Best Practice:
  • Always use .WSP.
  • Document how to deploy/rebuild site.
  • Identify how updates will be rolled out.
• Avoid:
  • STSADM backup/restore.
  • Use ‘save as site template’ to move a site.
  • Modify live features or site definition filtes.

High performance programming (Eric Shupps)

• All list data is stored in a single table for each content database.
• Looping operations in the Object Model are resource intensive.
• Use CAML queries for targeted item selection.
• Maintain SQL indexes for optimal query execution.
• Manipulate item data using in memory objects.
• NO 2000 item limit, only for displaying.
• Beware of caching in ViewState, use PageCache.
• Use SPListItemCollection instead of iterating.
• Use CAML when there are more selection criteria.
• Use Search API to query data.

Related posts:

1. SharePoint Best Practices Conference Notes (London 2009) – Day 1
2. SharePoint Best Practices Conference Notes (London 2009) – Day 2