Checklist for Designing and Implementing SharePoint 2010 Extranets – High Level Items to Consider

I have been designing SharePoint extranets since MOSS 2007 days and it’s been amazing to see that even though on surface each extranet projects are approached same way, each and every extranet projects provides different architectural challenges. Recently I have attended Jeremy Thake’s webinar on what items needs to consider while designing extranet systems – Governing your Extranet for a better user experience and I was surprised to learn many new facet of SharePoint 2010 extranet design. His webinar motivated me to write detailed article on my experience and high level items needs to be considered while designing and implementing SharePoint 2010 extranets.

I have been working on massive, large scale SharePoint collaboration extranet project with extremely complex IT organizations with different departments for major IT operations like Security, AD, Servers, Network, Enterprise Services, SharePoint, SQL etc. for last 8 months. Having checklist like this typically would help SharePoint Architect taming SharePoint beast and prepare proactively requesting all the information needed for extranet. Hopefully this article would provide generic checklist & guidelines required to design SharePoint 2010 extranets.

Understand Extranet Type based on Business Requirements & Usage Scenarios

  • Define the User Personas – Employees, Partners, Vendors/Customers
  • Externally Available Intranets or Collaborative Sites for Employees without requiring logging into VPN or Corporate Network – Extranets for Remote Employees
  • Typically extranets are platform shared with external users such as partners, vendors, and customers
    • Shared Collaborative environment with Partners or Customers – External facing Team Sites (e.g. Customer Portal, Partner Portal)
    • Internet facing read only documents, wiki sites, or shared collaboration environment – Publishing Feature (e.g. Marketing Sites, School Portal, Blogs & Discussion Forums)

Typical Extranet Project/Implementation Team

  • Part-time involvement from IT Teams – Infrastructure Team, Security Team, Network Team
  • Ideal Full-time Project Team – Product Owner, Business Analyst/Project Manager, SharePoint Architect, SharePoint Administrator, More than 1 SharePoint Developer, SharePoint Quality Assurance, User Experience Architect

Infrastructure Considerations

  • Core SharePoint Infrastructure & Network Topology
    • Hardware, Servers, UAG, Firewalls, DMZ, Network, DNS, Databases, SAN
  • Extranet Network Topology
    • Typically decides where would be SharePoint Servers located – In corporate network or DMZ
    • Typically decides high level SharePoint Server Topology and SharePoint Architecture
    • Topologies to Consider – Edge Firewall Topology, Back-to-Back Firewall Topology, or Split Back-to-Back Firewall Topology – e.g. Configure UAG in DMG to protect extranet farm hosted in corporate farm using Edge Firewall Topology
  • Server and Farm Topology
    • Single Farm vs. Multiple Farms
      • Do you really require separate farm? – Impact on licensing, hardware, security, physical data separation etc.
      • Options are Single farm with same sites serving both intranet and extranet (e.g. Same Web Application serving both intranet/extranet in Single Farm), different sites for intranet or extranet environment (e.g. Multiple Web Applications in serving both intranet/extranet in Single Farm), or Multiple farms for physical separation (e.g. Multiple Web Applications serving intranet and extranet in different Farm)
    • SharePoint Farm Architecture – Web Front Ends, App Servers, DB Servers
      • Service Accounts, SSL Certificates, IP Addresses, Host Headers, DNS changes
      • Hardware vs. Software Load Balancer for Web Front Ends
    • Cross-Farm Infrastructure for Multiple Farm
      • Shared SharePoint Services – User Profiles Service, Search Service, Managed Metadata Service etc.
    • Virtualization, High Availability,  Backup-Restore Approach, and Disaster Recovery
    • Global Availability and Latency – WAN Acceleration with Central Farm vs. Global Farms in Multiple Locations with Data/Documents Replications

Security and Identity Management Considerations

  • Identity Management System
    • Internal and External Accounts should be in separate identity management system.
    • Understand Types of Users
      • Internal Users – in most cases, it’s AD
      • Extranet System Managed Users – AD, ADLDS, SQL, LADAP
      • Extranet System Federated Users – ADFS
      • Extranet System Open ID or Social System Users – Live ID, Google, Facebook, Twitter, LinkedIn etc.
    • Sample Configurations
      • Single AD with Same OU or Multiple OU for both Internal and External Accounts – Windows Authentication is sufficient
      • Multiple AD with Two-way Trust for both internal and External Accounts – Windows Authentication is sufficient
      • Multiple AD with Single-way Trust for both internal and External Accounts  – Requires Claims & LDAP FBA
      • AD for Internal Users and ADLDS FBA for external Accounts  –  Requires Claims based authentication
      • AD for Internal Users and SQL/ASP.NET FBA for external Accounts  – Requires Claims based authentication
      • AD for Internal Users and ADFS (Web based SSO federation) for external Accounts – Requires Claims based authentication
      • AD for Internal Users and Windows Live ID for external Accounts – Requires Claims based authentication
  • Authentication – Account/Identity Management
    • It is important to note that SharePoint doesn’t perform Authentication
    • Decide whether to use Classic (Windows – NTLM or Kerberos with Internal AD) or Claims (LDAP/SQL/FBA/ADFS/ADLDS etc.) based Authentication.
    • It is important to note that regardless of what Authentication Source or Authentication Type is, SharePoint treats all users as SPUser object. SPUser object would contain user token based on authentication type or authentication source.
    • Does Kerberos need to be  enabled to pass credentials to the internal systems? Claims are built to avoid Kerberos delegation to pass Claims without concerns of multiple-hops.
  • Login Experience
    • Classics Authentication – Mixed-Mode Authentication – MOSS 2007 way
      • When to use? Different protocols like HTTP or HTTPS for internal vs. external users, separate environments or URLs for internal and external users, Single Sign on for internal users in corporate network
    • Claims Authentication – Multi-Mode Authentication – New in SharePoint 2010, Provides option to Choose Authentication Type before Login Prompt
      • When to use? Single URL for both internal & external users (There is exception – if both internal & external users are in same AD or multiple AD with two-way trust with windows authentication can have single URL), Must be used for Live ID, Must be used to federate between two organizations,
    • Custom Login Page
      • Most customer facing application requires custom branded login page. Requires custom development for branded login page. Out of box login options may not be sufficient for externally facing portals.
      • Optionally use Third-Party SharePoint Protection & Reverse-Proxy lookup Tools like UAG as long as these tools supports authenticate logic for all configured identity management systems.
  • Authorization – Site Membership
    • Unlike Authentication, SharePoint performs Authorization by assigning SPUser object to SharePoint Security Groups
    • Two Kind of Authorizations driven by Site Taxonomy
      • Shared Sites/Pages like Yahoo and Dedicated Sites for customers
      • Driven by Customer SLA & Sites Hierarchy – Separate/Dedicated Site Collection for each Customer Site or Single/Shared Site Collection for Multiple Customers
    • Protecting Content
      • Driven by User Personas, User Types, and Site Hierarchy
      • Site Level Permissions Inheritance – Inherit Security or Break Security
      • Site Security Groups -Use Out of box Security Groups or Create New Security Groups based on Out of box Permissions
    • Site Membership
      • Consider Automated Security Group and Site Membership Provisioning and Cleanup Process
      • Either Assign Users or Groups to the SharePoint Security Groups
        • Assign AD or ADLDS Groups to the SharePoint Site Security Groups, AD Groups are recommended for account maintenance if users are in AD. Map these AD groups to SharePoint Security Group for ease of Site Membership management
        • Assign individual users to the SharePoint Site Security Groups – This may require for ADFS
      • Define process to delegate site membership, Make business users/site owners to manage site membership
      • If external users or customers are managing site membership, Use People Picker filtering mechanism to restrict external users visibility in internal directories. Use stsadm -Peoplepicker-searchadcustomquery for AD. Implement custom filtering in Find methods of FBA/ASP.NET Membership Providers
  • User Life Cycle Process
    • In most cases, extranet environments are controlled environment which doesn’t require user registration process. User registration typically requires for public facing internet sites.
    • Needs to define process for User Provisioning & Decommissioning
      • Define business process to request provisioning new users – both in bulk & individual
      • Define needs for Shared User Accounts or Dedicated User Account
      • Consider Auto User Provisioning Process  and Decommissioning Process
    • Self-Service User Management – Needs to define self-service or IT managed User management process – how user would reset their passwords, how users would request access to the sites, how users would be given access to the sites etc.
    • User Monitoring & Auditing – It’s a process challenge, external users not sneaking in from back door – Proper User Validation, Expiration, and De-Provisioning  (e.g. Verify users once a 3 months), Either build custom tools or use third-party ISV products for Identity Management

Information Architecture Considerations

  • Logical Architecture, Site Hierarchy, Site Taxonomy
    • Web Application, DNS, Host Header, and Application Pool
      • Single or Multiple  SharePoint Web Apps
      • When would you require Single SharePoint Application? – Single URL
      • When would you require Separate SharePoint Application? – different URLs or Authentication Settings
    • Site Collection vs. Sites – Extranet Sites Hierarchy and Number of Sites based on Taxonomy
      • In most cases, SLAs, Security Isolation & Data Protection drives this design. Use Site Collection if Security is boundary and users will have full control. If dedicated content database is important, use site collection as well.
      • Use Sites for Shared Access scenario where multiple customers will have read-only access to the content or contribute access to shared data. As long as customers can’t manage security, you are OK having this model.
      • Plan to use dedicated Site Collection for customer/partner centric portals. You can use SharePoint Multi-Tenancy framework as well for host named site collections. This is how Office 365 or Hosted/Cloud environments work.
    • Single Site to serve All Customers or Dedicated Sites for Each Customer
      • Review business requirements to see if there are needs for dedicated collaborative environments like document libraries, calendars, contacts, SharePoint lists etc. This will require Multiple Site Hierarchy.
      • If business requirements drive design for personalized web parts, data views, dashboards driven by user identity, it may require Single Site or Few Sites based on site types.
  • Navigation – Cross Site  Navigation and Cross Site-Collection Navigation
  • Site Life Cycle Management
    • Needs to define process for  New Site Provisioning and Site Decommissioning
      • How does site would be provisioned? IT managed; User Managed through IT defined workflow, User Managed through browser based site templates etc.
      • Define business process to request provisioning new sites – both in bulk & individual
        • Site Decommissioning Process – Consider archiving site, instead of deleting it
        • Consider Auto Site Provisioning and Decommissioning Process
    • Needs to define process of extending or maintaining existing sites with new features
    • Site Auditing – Build tools to audit site provisioning, site membership, site maintenance, and  site decommissioning
    • Multiple ways to define site templates in SharePoint – Site Definitions,  Feature Stapling, Web Templates, Coded Site Templates based on blank site templates and activating/maintaining features programmatically
      • One way to speed up initial site design – Use out of box site templates (e.g. team site or blank site) with browser based customizations to speed up initial site template design working with business owners, Save site as template, and import saved site template wsps into Visual Studio to create base Site Template. This process would work only for non-publishing sites. Publishing feature disables save as site template.

Content – Site and Page Contents Considerations

  • Page Design – Page Templates – Content Pages
    • Site Pages vs. Application Pages vs. Page Layouts
      • Site Pages – If users are expected to add/remove web parts, personalize page, or requires web parts
      • Application Pages – Administrative Pages
      • Page Layouts – If users are expected to manage contents on page or users are expected to create pages based on pre-defined formats.
    • For the publishing driven sites, needs to define content approval process, content authoring process, and content deployment strategies
  • Collaborative Content
    • Collaboration with Customers – Document Libraries, Annoucements, Calendar, Contacts, Team Sites
    • Rich Media – Audios and Videos, should define Digital Asset Management strategies
  • Rollup Views
    • Content Query Web Part – within site collection
    • Lightning Conductor Third-party web parts – cross site collection
    • Custom Search Based API – cross site collection
  • Data – Integration with other systems within organization
    • Define systems to integrate – SAP, CRM, Lotus Notes, Other SharePoint Farms (e.g. IT Intranet, Document Warehouses), and Third Party Systems
    • Each System would provide its own challenge to access data from SharePoint, May require developing custom web services interface or BCS for platform Integration
    • Does external users requires data interactivity – Reporting, KPIs, Scorecards, Dashboards etc.? Do external user’s credentials pass through to the Business intelligence systems? – This may require SSRS, Excel Services, Performance Point Services, Visio Services, BCS or other mechanisms with Kerberos or Claims enabled authentication
    • Data Security – Define process to expose internal data securely to the customers
      • Would customer credentials  pass through to the internal systems? – this would require Kerberos enabled on the SharePoint
      • Access Internal Systems based on User/Site Metadata/Personalization and Service Accounts instead of passing user credentials to the data source systems, requires proper metadata governance, metatada mapping, and metadata sync process
  • Search
    • Decide to use Fast Search vs. Enterprise Search capability vs. Custom Search Driven Components
    • Searching data from multiple internal systems may require BCS/LOB connectivity for platform integration with metadata targeted custom search API
    • Allows you to target information to customer by external user expertise and based on user profiles

Other Major Considerations

  • User Personalization and Preferences
    • Define User Personalization Data Store – SharePoint User Profiles vs. SQL Server Users DB vs. Custom Tools
    • Use User Metadata to target specific contents and implement personalization
    • May require tools to Sync User Metadata with Source Systems
    • May require tools to manage User Maintained Metadata and Preferences
  • Metadata
    • Application Metadata – Store in web.config, web application configuration store etc.
    • Site Metadata – Store in SharePoint site property bag properties
    • User Metadata – Store in User Profiles, SQL Servers, and AD/ADLDS properties etc.
  • Licensing
    • Work with your Microsoft reps for licencing impact, Each organization would affect different way
    • Per User CAL – Internal vs. External Facing
  • Social Integration
    • Any Social Integration – Twitter, Facebook, LinkedIn, Google+ etc.
  • Mobility Access
    • Target Platform – Blackberry, IPhone, Android, Windows Mobile
    • Any support for Mobile Device Access, HTML 5, MAC OS, iOS for cross-platforms and cross-device support.
    • Plant to integrate open standards like Jquery, Avoid Plugins like Adobe Flash or Silverlight for UI which not supported on iOS as of now
  • Cross-Browser Support
    • Define Browser Support Standards for IE, Chrome, Firefox – Checkout SharePoint 2010 Level 1 and Level 2 browser support and see if any custom tools needs to incorporated
    • Do you really need to use Silverlight or Adobe Flash? May be HTML 5, CSS 3 for industry standards
    • Target Standard Screen Resolution – 1024×768 vs. 1280×1024
  • Look and Feel – Branding
    • Custom Master Pages, CSS, Images, JavaScript, jQuery files etc.
    • UX Experience – AJAX vs. Jquery vs. Silverlight vs. HTML5 vs. JavaScript
    • Concept Design to Wireframes – Design Wireframes for pages, sub sites, and content pages
    • Style Guide – Microsoft Metro look & feel vs. Corporate Style Guide
  • Custom Development – Methodology and Environments
    • Build out Multiple Environments – Individual Developer VMs, Integration, Staging, Authoring, Production
    • Implement Coding Guidelines and Adhere Standards
    • Plan to standardize Code Organization in Visual Studio – Many Codeplex tools available to enable RAD
    • Plan to Use Source Code Control Management like TFS
    • Plan to perform Unit Testing, Automated Build Management, and Continuous Integration for Proper Release Management.
    • Plan to standardize Code Deployment using PowerShell Scripts vs. Manual PS Commands – Packaging using Features & Solutions Framework
  • Production Diagnosis – Logging and Auditing
    • Review out of box diagnostics and logging options – ULS, Event Logs, Developer Dashboards
    • Plan to build IT Support and Monitoring Framework – Error Handling, Logging
  • Performance
    • Caching – ASP.NET Caching vs. Page Output Caching vs. Custom Caching Components
    • Browser Optimizations – CSS Optimizations
    • Plan to perform Load Testing
  • Anti-Virus
    • Plan to use SharePoint specific Anti-Virus product to scan external user uploaded documents.
    • Consider blocking Infected Documents
  • Localization – Global Platform
    • Decide to use Different UI experience for different regions or  Consistent UI experience at all regions
    • Multi- Lingual Sites vs. MUI vs. Both vs. ASP.NET Custom Globalization Resource Files
      • Variations and Content Translation Tools
      • Sites in specific language and currency
  • Web Analytics
    •  SharePoint Out of box Web Analytics or Custom ISV tools
    • SharePoint Web Analytics not useful – Per Site Collection or Per Site, Instead Integrate with Web Trend or Google Analytics or ISV tools
  • End-User Training and Adoption
    • Plan to have proper documentation, online help, and system adoption plans
    • Plan to have proper communication and notifications for updates or new features rollout
    • Plan to have initial Pilot program, product roadshow, or adoption programs
  • IT Support and Monitoring
    • Plan to have feedback forums for external users to submit incidents and general system help
    • Plan to have dedicated IT support team to respond user incidents in timely manner

Hopefully this will provide great starting reference point for SharePoint Architects embarking on similar projects!!! Good Luck!!!!

Advertisements
This entry was posted in Planning, SP2010 Admin General. Bookmark the permalink.

One Response to Checklist for Designing and Implementing SharePoint 2010 Extranets – High Level Items to Consider

  1. Great overview 🙂 Thanks

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s