Azure Infrastructure as a Service (IaaS) is a great option for SharePoint Server deployments for those use cases and/or organizations where SharePoint Online is not appropriate or sufficient.  IaaS can be used for dev/test scenarios or a part of a production, cloud-based infrastructure.
With SharePoint Server 2016, deployment without Active Directory is no longer supported;  Active Directory is mandatory for any scalable version of SharePoint Server.  Until now, the requirement for an Active Directory Domain was satisfied by provisioning a Windows Server Virtual Machine (VM) and configuring the server as a Domain Controller.
The Azure Active Directory Domain Services (currently in preview) offers an alternative. Rather than deploying and configuring a VM, the Domain Service could be enabled within an Azure Active Directory instance and associated with a new or pre-existing Virtual Network. Once the initial setup is complete, virtual machines deployed into the virtual network can be joined to the Active Directory domain. Once the machines are joined to the domain, the domain can be utilized as if it was being provided by an On-Prem or IaaS Windows Server.
The advantage? Simpler, more cost-effective Active Directory Domain management without the need to configure and run an additional server.
Since the Azure AD Domain Service is in preview, I decided to test the service within the context of a SharePoint IaaS-based deployment. In my testing, I chose to use the SharePoint Server 2016 Beta 2 image (see SharePoint 2016 Install ), but the results are applicable to any SharePoint version (e.g. 2007, 2010, 2013, 2016) using an Active Directory based deployment
The end result – a domain that can be used to support SharePoint Active Directory users and groups! For example, a domain name of sp2016ad.onmicrosoft.com can provide a SharePoint setup login of sp2016ad\sp_setup.  (As of this writing, the service is only supported in “classic” mode, with support of Azure Resource Management forthcoming.)
The detailed instructions can be found below.
This document Azure AD Domain Services (Preview) – Getting started provides a step-by-step process for the setup.
Here is an outline of the steps for SharePoint

• Create Azure Active Directory
  • Or use an existing Azure Active Directory
  • NOTE: Each Azure Active Directory only supports a single Active Directory Servic

• Create the ‘AAD DC Administrators’ group in Azure Active Directory (see Figure 1)
  • Create a dedicated account
  • Give this account Azure Admin Rights (NOTE: it will be used to create users)
  • Add the account to the AAD DC Administrator group

• Enable Azure AD Domain Services (see Figure 2)
  • Option is found in lower portion (scroll down) of directory “Configure” tab
  • Naming Rules
    • Pay attention to Domain Name format rules
  • Wait for Redundant IPs to appear for DNS
  • Update DNS settings for the Azure virtual network

• Create Domain Users (see Figure 3)
  • Use Windows Azure Active Directory PowerShell
    • $msolcred = Get-Credential ## NOTE: This must be a Azure Active Directory Account, not a Microsoft Account
    • Connect-MsolService -Credential $msolcred
    • $setpass = “Pass@ABCD”
    • New-MsolUser -UserPrincipalName sp_setup@rjg916testad.onmicrosoft.com -DisplayName sp_setup -ForceChangePassword $false -PasswordNeverExpires $true -Password $setpass

Figure 1: Azure Active Directory and Group

Figure2: Azure AD Domain Service

Figure 3: Active Directory Users

The report of my death was an exaggeration – Mark Twain & SharePoint Server On-Premises
SharePoint Server On-Premises was, in the recent past, presumed obsolete. While Office 365 and Cloud Computing are juggernauts, compelling use cases continue to exists for On-Premises deployment. Realizing this need, Microsoft is working toward a Q1 2016 release of SharePoint Server 2016. As of this post, the Beta 2 bits have been released.  This post focuses on the architecture, installation and configuration of SharePoint Server 2016.
What’s Different?
By design, SharePoint Server 2016 is highly compatible with and consistent with SharePoint Server 2013. Notable differences are as follows:

• More granular/supportable deployment model including Single Node Farm and Min Role Deployment
• SharePoint Foundation install obsoleted
• Microsoft Identity Manager replaces Forefront Identity Management

As for previous posts for SharePoint 2010 and 2013, I was interested in validating techniques for automated installation of SharePoint Server. The good news – automated installations continue to be well supported with familiar tools and infrastructure.
Near-Term Approach
In order to quickly build a development/test/proof-of-concept SharePoint Server 2016 Farm, a combination of Azure Infrastructure as a Service (IaaS) and AutoSPInstaller works well.  To utilize the Auzre infrastructure, the architecture described in Microsoft Azure Architectures for SharePoint 2013 is still applicable as is  the AutoSPInstaller (which has been updated to support SharePoint Server 2016). The specific steps to configure a SharePoint Server 2016 Farm are as follows:

1. Azure Virtual Network – provision a simple Virtual Network (VNet)
2. Active Directory DNS Server Host – provision a Windows 2012 Server VM into the VNet; configure the server to server as an  Active Directory Domain Controller and DNS Server
3. SQL Server 2014 – provision a SQL Server 2104 VM into the VNet to host SharePoint Server databases using SQL Server 2014
4. SharePoint Server Farm Host – provision a Windows 2012 Server VM into the VNet to host SharePoint Applications and Services
5. Execute AutoSPSourceBuilder – used to assemble both the pre-requisite files and SharePoint executable required by AutoSPInstaller
6. Execute AutoSPInstaller – used to configure the virtual servers into a working single node farm including web applications and services

Notes

• After provisioning of the Active Directory DNS Server (step 2 above), the server must be configured as DNS server for the VNet
• Prior to the execution of AutoSPInstaller (step 6 above), the required domain accounts can be created via a PowerShell Script

Next Steps

• Hybrid Configuration – Hybrid (Office 365 and On-Premises) configurations support the most compelling use cases for SharePoint Server 2016 .  These configuration involve additional services and setup that could be easily automated
• Desired State Configuration (DSC) – the AutoSPInstaller logic could be re-factored to take advantage of the Windows Server PowerShell DSC approach to server configuration specification
• Azure Resource Manager (ARM) – within the current Azure environment, ARM templates exists that provide  “macros” which allows easy creation of both a High Availability and non-High Availability SharePoint 2013 Server Farm.  ARM could be used to provide a similar “turn-key” approach for SharePoint Server 2106, using the components mentioned above

This week, Microsoft announced the release of an Office 365 Video Portal (see Office 365 Video ).
This is an exciting first step into an area of great demand and large potential. In the past, many larger enterprises purchased dedicated 3rd party solutions for the management of video content. Smaller organizations typically leverage You Tube.  SharePoint deployments at small and mid-size companies sometimes use native Video content types and/or custom solutions.
The Office 365 Video portal goes above and beyond SharePoint video content type in many important ways:

• The Video Portal is somewhat akin to the “old school” SharePoint Document Center.  The Video Portal is a dedicated “home” Site Collection with support for securable “channels”.  Each channel can have completely independent permissions and administrators and is mapped to a unique site collection.
• Uploaded videos are converted for playback on a variety of formats/media/qualities.  At playback time, the video portal dynamically adjusts the playback (every 2 seconds) to use the most appropriate format for the device/bandwidth conditions.
• The original upload is managed in a SharePoint site collection (and incurs storage cost); the converted files are managed via Azure Media Services and do NOT result in additional storage charges
• Videos will appear in Enterprise Search results and views are tracked in analytic reports.

Its important to note that this is a v1 product with the following areas for future improvement:

• Playback is via Flash, not HTML 5.  This represents a large roadblock for Mobile device use.  Microsoft acknowledges this and HTML 5 support is clearly on the roadmap
• Uploaded videos are limited to 2GB with larger limits (aka OneDrive consumer version) undoubtedly in the works
• Videos live in their “host” site collection and are not  integrated across all tenant site collections via apps; simpler link sharing/embedding is possible
• Extranet and/or Intranet use cases are not currently supported

 
Even with the v1 caveats, this will be a great value added for many Office 365 customers.  The feature can be enabled/disabled at the tenant level, so organizations will have time to evaluate the ROI and launch when appropriate.
 
 

Given the central role that Office 365 occupies for more and more businesses, integration of the resources managed by Office 365 with other services is a challenge that Perficient often addresses for clients. The good news is that the Office 365 platform and the architecture of many other, key platforms provide countless integration possibilities, many of which can be leveraged without the need for custom coding.
Recently, I was asked to tackle an integration of Office 365 and Salesforce that serves as a good illustration of the possibilities.  I described the problem and solution in an earlier post . In that post, I described how to expose Office 365 information within Salesforce.  In this post, I would like to look at the problem from the opposite direction – how to expose Salesforce information within Office 365.
The Problem
In this case, the goal is to expose core Salesforce information within an Office 365 site.  Ideally, the information would behave as if it was “native” to the site.  In this case, “native” means web parts, lists, columns, etc. could all behave as expected.  This integration could, of course, be accomplished via creation of an appropriate SharePoint application.  As in the previous case, we are looking for a “no code” solution.
The Solution
Fortunately, Office 365 supports a technology designed to solve such external data integration scenarios – Business Connectivity Services (BCS) .  This technology was originally developed as a component/service for On-Premises SharePoint but is also supported within Office 365.
BCS supports the notion of an external content type, which can be used to describe Salesforce entities in a manner which will allow SharePoint to present the data as if it were internal.  Some of the information contained in a external content type for Salesforce includes the following:

• Connection / Authentication information for the source Salesforce Organization.
• A definition of the Entities, Fields, and data types (aka metadata).
• Allowed data operations, such as Create, Read, Update, Delete, and Query (also called CRUDQ).
• The identity field and display columns for an external content picker used to retrieve external data throughout the user interface.

As in SharePoint On-Premises, the BCS in Office 365 provides a means for importing the external content types definitions (see Import BDC Models):

With the external content type in place, all the Salesforce-specifics can be ignored by users.
Creating a BDC Model
In addition to the external content type definition, the BDC Model for Salesforce must contain information about how to connect to the Salesforce data. BCS can consume data sources that are exposed as WCF services, SQL Azure data services, OData endpoints, and web services; Salesforce provides Web Service API for external data access. So, the question is “how do we match the requirements of the BCS client and the Salesforce service?”
In the case of Salesforce data, Visual Studio and SharePoint Designer tools do not provide a straightforward integration.  The good news is there are a number of 3rd party tool providers who solve this problem – e.g. RSSBus Salesforce Connector, BCS Meta Man .  These tools provide an GUI-based tool for the generation of the BDC Models and External Content Types. Under the covers, these tools provide an OData proxy for Salesforce web services.
 
Dealing with Security
Another important consideration of a Salesforce  integration is respecting security of the underlying sources system.  What is needed is some mechanism of associating the Office 365 authenticated user with an appropriate Salesforce user.  Fortunately, such mapping is supported by the Office 365 Secure Store service.  After determining the best authentication/identity mode for Salesforce, a target Secure Store application is created containing desired credentials mapping (see below).  Finally, the Secure Store application is associated with the Salesforce BDC Model.


The Payoff
Once the Salesforce external content types are defined, a wide variety of SharePoint  elements can be used to create lists, columns, web parts, etc.  using Salesforce data.  See Salesforce demo for a quick example.
 
 

 
 
Given the central role that Office 365 occupies for more and more businesses, integration of the resources managed by Office 365 with other services is a challenge that Perficient often addresses for clients. The good news is that the Office 365 platform and the architecture of many other, key platforms provide countless integration possibilities, many of which can be leveraged without the need for custom coding.
Recently, I was asked to tackle an integration of Office 365 and Salesforce that serves as a good illustration of the possibilities.
 
The Problem
In this particular case, the client wished to make SharePoint Online files available within Salesforce without the need to manually copy/download/upload files.

 
 
 
 
 
 
 
 
 
 
 
 
Solution Elements

• SharePoint Online File – SharePoint native files and metadata
• Salesforce File – the Salesforce system both provides a native file store and, via an “External Data Source”, allows other file stores to emulate native file stores
• External Data Source – Salesforce provides for connections to files stored in Office 365 (“Files Connect – SharePoint Office 365”). The  “External Data Source” is how the existence of an Office 365 tenant and appropriate properties are made known to Salesforce
• Authentication Providers  – provide a mechanism for mapping a Salesforce user to an Office 365 user with appropriate access. OAuth 2.0 is leveraged via a SharePoint Remote Hosted Application which supports the External Data Source
• SharePoint Remote Hosted Application – from the SharePoint perspective, the “External Data Source” service application IS a remote, hosted application. Remote hosted applications are one of the mechanisms which allows external services to be accessed in SharePoint while remaining independent of SharePoint. A key component of the remote hosted application is support for setup of the Authentication Provider via OAuth 2.0

Listed below are the steps you can follow to expose SharePoint Online files within Salesforce
 
From Set Up Salesforce Files Connect, follow these steps:

• Enable Salesforce Files Connect for Your Organization
• Let Users Access Files Connect Data Sources
• Create a SharePoint Online Authentication Provider
• Define a SharePoint Online External Data Source for Files Connect

and from Provide Data Source Credentials, complete this step:

• Provide Your Data Source Credentials

 
Authentication Provider


 
 
 
 
 
 
 
 
 
 
SharePoint Remote Application Registration


 
 
 

One of the many advantages of using Office 365 is freedom from a myriad of worries at the data center (watch this video for an interesting glimpse at Microsoft data centers), server, and application levels.

 One of the most important concerns for any enterprise is that of “business continuity” – making sure a service is both available and, in the event of trouble, restorable with minimum information loss. Two metrics are traditionally used to help define business continuity goals — Recovery Point Objective (“How much data can I afford to lose?”) and Recovery Time Objective (“How long can I wait for the service to be available?”). While Microsoft publishes “financially backed SLAs for up-time” (see   Office 365 Trust Center), it does not provide specific RPO and RTO guarantees. RPO and RTO are, however, published for related services (see SharePoint Online Dedicated and Exchange Online Dedicated service descriptions.)

For most organizations, these ranges of RPOs and RTOs are likely to be acceptable. If they are NOT, the organization will need to design processes to meet the more stringent objectives. It is important to keep in mind that scenarios other than outright Office 365 failure may result in information loss (e.g. accidental document deletion). Some of these scenarios are well supported by the application (e.g. SharePoint recycle bin, versioning, etc.), but others are not (historical file deletions, file corruption, version overwrite, etc.)
For on-premises deployment, a number of 3rd party vendors have developed tools to support a wide variety of information loss and recovery scenarios. For Office 365, tools and technologies are beginning to appear — some of these tools are extension of on-premises technology while others are cloud-only implementation. Here are a few available options:

• AvePoint – DocAve 6 Backup and Restore
• Cloudally
• Cloudfinder
• Leap
• MetaVis Technologies – Backup for SharePoint

When looking at these products and services, consider your specific use cases as well as the following:

• Full platform support – Does the product/service support Exchange, One Drive for Business, Lync, Yammer, AND SharePoint?
• Integrated tool suite – some of these tools support other Office 365 needs (e.g. governance, data migration). For a larger and/or more complex implementation, a suite will likely prove more valuable than a singular solution
• Archiving  – does the tool provide support for removal of data meeting certain requirements, or only recovery of missing/corrupt information?
• On-Premises AND Office 365 – if your organization is transitioning from an on-premises implementation, a solution that seamlessly supports both platforms is ideal
• Backup Location – some of these solutions use cloud storage exclusively while others provide a variety of targets
• Target User – some of the solutions are targeted toward business users, while most are for IT professionals

As always, a well formulated set of requirements based upon business needs will make the decision making process easier. Technology in this area is rapidly changing, so always check for new developments.

Microsoft has just announced general availability of “Infrastructure as a Service” for Windows Azure (see  Windows Azure and IaaS), including support for Virtual Machines and Virtual Networking.  With this offering, Microsoft is attempting to provide a compelling alternative to options such as Amazon Web Services, Rackspace Cloud Servers, etc.  As competition heats up, pricing is becoming one of the bases of competition, with Microsoft announcing discounts from previously published costs.
Within the general availability announcement and accompanying blog posts, the ability to deploy a SharePoint Server 2013 farm on Windows Azure is highlighted (see infrastructure as a service – IaaS ).  Anyone considering the use of a cloud-based infrastructure for SharePoint Server farms should review the details of the updated offering as it relates to SharePoint Server.
Some of the highlights include:

• The Virtual Machines are based upon the VHDs used by Hyper-V.  This means that the VMs are portable across any virtual machine hosting environment based upon Windows Server 2012 including on-premises physical hosting and externally hosted environments.
• Pre-configured SharePoint Server 2013 images (with trial licensing) are available, as is the ability to create customized, reusable images.
• A range of server footprints with increasing memory and CPU cores that matches typical SharePoint server requirements are available.  In addition, the server footprints can be changed on-the-fly.
• The server C: drive contains the Operating System, the D: drive is reserved for temporary storage — additional data disks can be added (the number depends upon server footprint).
• RDP and Remote Power Shell are both available for server management, with additional Power Shell utilities for Windows Azure provided.
• The infrastructure including a number of features to support high availability scenarios including availability set, fault domains, and update domains.  This insures that no single point of failure is introduced and that host server maintenance does NOT result in the unavailability of services.
• Round Robin load balancing for external traffic is provided as an option as part of the infrastructure.  This provides another alternative for SharePoint Web Front End load balancing.

 
The Deployment Guide (see SharePoint Server Deployment Guide) is useful, as it contains a good overview of the new features of Windows Azure and a recommended process for SharePoint Server 2013 farm planning.  The majority of the farm planning advice is as relevant for on-premises and for cloud-based deployment and provides a useful process outline/overview.

A while back, I blogged about both the driving factors and a recommended process for automated installation of SharePoint 2010 (see Automating Sharepoint 2010 Installs). As more and more of our clients are deploying SharePoint 2013, I’ve had a chance to revisit and revise the process for SharePoint 2013.
The good news for those of you who followed my advice and/or created your own installation process, the basics remain the same.   Here are a few observations:

• My tool of choice for automated installation, AutoSPInstaller,  has been updated to support both SharePoint 2013 and SharePoint 2010.   While the SharePoint 2013 functionality is marked as “beta”, I’ve successfully tested the latest versions on multi-server SharePoint 2013 farms.
• A new companion program to AutoSPInstaller is now available — AutoSPSourceBulder.  This utility provides automated support for gathering all the pre-requisite programs/patches required for a SharePoint 2013 installation.  This program is especially useful in cases where internet access from target servers is prohibited.
• In order to document and validate a SharePoint farm setup, the following SharePoint 2013 enabled tools can be used: Document farm configuration settings in SharePoint 2013 and Documentation Toolkit for SharePoint

Here are a few new and/or unique items for SharePoint 2013 installations:

• For anything other than a simple “quick and dirty” demonstration, the self-contained “SharePoint + SQL + AD environment in box” (aka single server/domain) is no longer viable.  In my testing, I have confirmed issues and limitations that arise when an attempt is made to host a domain controller and SharePoint on the same box; the domain controller node must be provisioned (or made available) separately from the SharePoint 2013 nodes.  (Note that SQL Server can be installed either on the SharePoint server box or on a separate box.)
• Supporting the SharePoint 2013 Application model requires additional configuration steps
  • Creating an Application Domain
  • Setup Application Subscription and Management Services
  • For On-Premises, Provider Hosted Application Support, the Farm must be configured for “Server to Server High Trust” with the application server(s) (see Create high-trust apps for SharePoint 2013 using the server-to-server protocol )
  • By default, SharePoint 2013 includes the SharePoint 2010 Workflow Engine.  In order to use the new SharePoint 2013 workflow service a separate setup must be completed (see Installing and Configuring Workflow Manager 1.0 ) which is not within the current scope of AutoSPInstaller.
  • There are many other more minor differences in the installation/configuration.  Thankfully, many of them are transparent to users of AutoSPInstaller.  Review of the AutoSPInstallerInput.XML sample file will make many of these details clear.

Its reassuring to know that SharePoint 2013 installations can start with a solid installation for development, test, or production.

As the excitement surrounding SharePoint 2013 increases, those of us who make a living helping companies deploy SharePoint are beginning to consider the Governance implications of the latest release.
The need for SharePoint Governance has, of course, not gone away with the new version (there is still no Governance “check box”).  Quite the contrary, the wealth of new services and features will trigger new and different discussions.  As one example, the significant broadening of Social functionality (community sites, activity streams, etc.) will increase the time and energy spent by organizations in formulating governance policy.   If you thought past discussions about “My Sites” were sometime heated, just wait!
What we need, of course, is a Framework for SharePoint Governance that neatly categorizes all of the Governance-related aspects of the product, presents a process for understanding the possibilities, provides decision trees for feature deployment analysis, and extends the analysis through to proper configuration and monitoring of the system.
Unfortunately, such a resource doesn’t exist, even for SharePoint 2010.  There are, of course, many governance resources available.  Microsoft created a governance sites and supporting collateral for both MOSS and SharePoint 2010.  While valuable, these approach governance from a distinctly IT perspective and don’t consistently incorporate the larger organizational view.  If history is a guide, Microsoft will create a 2013 instance of governance tools that will be useful, but will reflect the same IT-centric view.
Those looking for a more general, vendor-neutral framework can turn to ISACA, an independent, organization that provides resources for information systems assurance, control/security, and enterprise governance of IT.  Noteworthy in their offerings is the Certified in the Governance of Enterprise IT (CGEIT) designation and COBIT, a business framework for the governance and management of enterprise IT.

COBIT provides an enterprise-level view of governance that needs to be modified to deal with the use case of ONE particular system such as SharePoint.  Such a mapping is no trivial task, but the outcome is useful.  For SharePoint, one such mapping has been published (see Chennault and Strain).

This mapping is, of course, a great starting point for SharePoint 2013, with one caveat.  The COBIT framework has recently undergone a significant overhaul/expansion/simplification.  The latest version (COBIT 5) should prove to be an even better governance foundation for the following reasons:

• Clearer separation of management and governance processes
• Inclusion of many new processes; substantial revision of processes
• Explicit inclusion of more “soft” factors, including culture, ethics, and organizational structure
• Definitive process for mapping from business/stakeholder goals to governance processes
• Integration of risk management and compliance within a unified framework

Perhaps Chennault and Strain are, at this moment, working on a new version of their SharePoint/COBIT process.  Regardless, it would be well worth the time of anyone with responsibility for SharePoint Governance to review COBIT 5 along with SharePoint 2013 and incorporate the framework into their processes and deliverables.

One of the more basic “value-adds” of SharePoint is the abstraction of IIS web sites and data stores as “web applications” and “site collections”.  Because this abstraction has worked well, there has been no fundamental change to these concepts in SharePoint 2013.
In cases where there is a need for a larger number of site collection within a web application, SharePoint 2013 provides a new option known as “host named” site collections.  In SharePoint 2010, site collections can be configured to reside in locations/URL via paths (either explicit or wild-card inclusion).  While setting up site collections via paths is easy, path-based site collection come with certain limitations including number of site collections and URL format.  Host named site collection allow a more flexible mapping of site collections to URLs, web applications, and zones. This mapping is accomplished via Windows Power Shell.  (Click here for details and limitations)
 
One of the on-going challenges of the site collection model is the handling of content-intensive applications. Since site collections can only, as a practical matter, hold 200GB, multiple site collections sometimes must be created when there is no functional or business need.  Unfortunately, each site collection has unique site permissions, groups, web part gallery, master pages, and page layouts, which must then be individually managed.  Multiple site collections also present other challenges including UI/navigation usability and inability to use key web parts (e.g. content query) across all the content in the web application.
 
Since SharePoint 2013 does not provide a means to allocate storage independently of site collections, the following options can be pursued:
 
 

• Partition collaboration and portal sites into separate web application. This is, in the great majority of cases, a best practice and will provide more flexibility for both types of sites.

• Insure multiple site collections are REALLY needed for your portal application.  The majority of available guidance presumes multiple site collections are need or, at the least, does not consider the feasibility of a single site collection.  If multiple site collections can be avoided, deployment and maintenance of applications is much easier.

 
 
In cases where multiple site collections ARE needed the site content should be organized into a small number of stable site collections. Some options include:
 

• Collaboration Applications – rather than creating a site collection for each team, allocate a site collection for each department.  Then, departments can manage creation of sites/sub-sites within the site collection.

• Portal Applications – allocate site collections based upon a functional, content oriented site map (not an organization-based site map).  This will avoid the problem with re-factoring department-based site collections after every company re-organization and goes hand-in-hand with Information Architecture best practices.

• “Hot Spots” – site collection can be allocated for active, large volume content areas such as corporate-wide document sharing sites.

• Live with multiple site collection and keep site collections consistent vis manual processes – this, of course, is the first and last resort.  If you can stabilize you site collection architecture to a small number, this can become a practical.  Out of the box capabilities, such as Content Type Hub, can be used to ease management burden

• Acquire a 3^rd party product to keep site collection framework in-synch across multiple site collection. Multiple vendors offer such solutions, at a cost.

Note that this advice applies equally well to SharePoint 2010 as 2013.
 

As part of the release of the SharePoint 2013 Preview, Microsoft has provided a series of diagrams covering a variety of infrastructure areas.  One of the more interesting can be regarded a synopsis of farm topology best practices.  Even though this diagram can be rendered on a single page (click here to review an interactive version), it is filled with a variety of useful examples and best practices.

Some of the noteworthy highlights specific to SharePoint 2013 are as follows:

• Virtualization – diagrams illustrating both host and virtual machines are provided as are specific heuristics for the use of Windows Server 2008 R2 and Windows Server 2012 hosts.
• “Stretched” Farms – distribution of servers across more than one datacenter is no longer supported
• Request Management – the ability to control the routing of specific requests to specific servers (new to SharePoint 2013) via a variety of criteria is illustrated.
• Query Management – a query processing “component” replaces the query “role”.  The query processing role is more resource intensive and cannot, in most cases, be instantiated on a web front end.
• Office Web Application – even though Office Web Applications are no longer provided as “service applications”, examples of their configuration are shown.

What makes this diagram even more interesting is its relevancy for SharePoint 2010.  Some of the generally useful content includes:

• minimum fault tolerance configurations
• service application scale out examples
• search scale out examples
• small, medium, and large farm deployments
• physical and virtual topologies
• database placement heuristics

Since the diagram is also provided in  Visio format , it can serve as a starting point for documenting any farm topology.

Configuring a SharePoint 2010 Farm is a non-trivial undertaking. Each of the servers in the farm must have the correct software installed. In addition, a myriad of accounts, databases, applications, and services must be correctly installed, created, and configured on each server. Typically, a project team requires three or four different farms (development, integration, validation/test, production). In the case of issues, one or more of these farms must be re-created to match the initial configuration. And, of course, each environment in which a Farm is created is unique – Active Directory, account rules, network configuration, server configuration all tend to vary from vanilla.

Getting all of this right, however, is critically important to the success of a deployment. Mistakes in the configuration and setup of SharePoint 2010 can lead to subtle, hard to detect issues long after an installation is complete.

Most useful for production deployment is SharePoint 2010 full support for Windows PowerShell. PowerShell can be used as the basis for fully automated and repeatable installations. The companion tool to PowerShell is virtualization (cloud or otherwise).

In recent projects, I’ve had great results proceeding as follows:

• Work with the client to clearly define the architecture for development, integration, validation/testing and production SharePoint 2010 farms
• Translate these architectures into XML files including servers, applications, accounts, databases, etc.
• Provision a cloud-based server to emulate the client’s Active Directory and Database environment
• Provision the required cloud-based servers into the test Active Directory domain
• Execute Power Shell scripts on each of the servers (to read the XML files and build the SharePoint farm using the collection of cloud-based virtual servers)
• Test the configuration via both automated and manual means
• Adjust the specification and configuration until desired results are achieved
• Build the servers/farm within the clients environment via the XML configuration/scripts
• Delete and/or archive the cloud based servers

Key enablers to the above:

• Virtual Servers – easy-to-configure and snapshot virtual servers are necessary to allow the repeated execution of the scripts required to ensure that the configuration is correct. There are a number of vendors providing this service in the cloud including Amazon and Rackspace.
• PowerShell scripts – I’ve found SPAutoInstall on CodePlex  to be an excellent tool supporting both the XML specification and PowerShell scripts required for a successful install.
• Verification Tool – in addition to manual verification, use of an automated tool such as SP Doc Gen  to report the farm configuration is quite valuable

I’ve found this approach allows for rapid and high-quality SharePoint 2010 farm deployment. The virtual servers enable iterative testing and verification of the configuration. The scripting makes execution of the installation both rapid and repeatable. The use of a verification tool provides a formal means for insuring the end result is what is expected.