SharePoint 2013 Architecture my notes
Note: This content is extract from different sites for my reference
Multi-Tenant
(Public)
Dedicated
(Private) VNext
Hybrid
Minimum software requirements
Minimum requirements for client computers
Minimum recommended services for development environments
The elements of a document management system
The planning process
Content type overview
Plan workflows
About versioning, content approval, and check-outs
Note: This content is extract from different sites for my reference
Microsoft breaks down Office 365 into two
plans; P Plans and E Plans. Choose wisely as you cannot swap between the P and
E plans once they are setup.
The P plan is geared towards small businesses
that have no plans on implementing Single Sign-On (ADFS). Microsoft recommends
no more than 50 users on this plan. You will get Exchange, Lync, and
SharePoint, but these are limited in their capabilities. Keep in mind that this
is geared for the small business. The draw back for this plan is that there is
no support offered by Microsoft.
The E plan is built for the Enterprise
clients. Depending on the sub-plan that you choose, the sky is the limit for
services offered. This includes the ability to enable Active Directory
integration (with ADFS and Directory Sync); single sign-on with local Active
Directory credentials to services in Office 365 cloud. It also allows for
hybrid configurations of Exchange, Lync and SharePoint. This allows your
company to have some services in the cloud and some services on-premise.
Multi-Tenant
(Public)
A public cloud is based on the popular definition of cloud
computing – it provides services, applications and computing resources
off-site. Multi-tenancy is synonymous with the term “public cloud”, as the
resources used are shared by multiple organizations. This leads to greater
efficiency, amazing scalability and lower costs, all of which are huge draws of
public cloud computing. Businesses typically use a pay-as-you-go model, truly
purchasing the cloud “as a service”. The cloud provider is responsible for the
infrastructure costs, allowing businesses to see costs based only on need.
Opposite of these benefits are a few of the downsides: less customization and
greater restrictions Because the infrastructure is managed by the cloud
provider, the individual businesses have very little control over the way it
operates. There are also many security concerns with a public cloud
environment. While it doesn’t provide an ideal situation for tailor-made
security policies, cloud providers have ensured a focus on top-tier security.
The reliability of the public cloud depends on the provider, and that’s why
it’s important to conduct research before making the switch. A
multi-tenant environment is typically best suited for small or medium
businesses that need to bring their services to market quickly, heavily rely on
Software as a Service, and have fewer compliance obstacles.
Dedicated
(Private) VNext
Private cloud, on the other hand, is one that maintains the
services, applications and computing resources within a private network. These
resources are dedicated solely to one organization but can be hosted
either on-site or off-site with the help of a third party provider. This
single-tenancy is where the word “private” comes from, though many believe it
refers to security. While greater control over security is definitely boosted
in a private cloud environment, it still always depends on the quality of the
specific situation. A dedicated cloud offers the benefits of advanced
security and control, more flexibility and easier compliance with regulations.
This cloud model is beneficial to larger organizations, but it also has
its downsides: reduced cost savings and increased management and
responsibility. With a private cloud, the company is typically more involved in
the management and maintenance of the ecosystem as a whole,
although RapidScale offers to completely manage their systems if
they so choose. A private cloud environment is also very
beneficial for large companies that need to conform to strict industry
regulations and standards and regularly uses business-critical data and
applications that require high levels of security. This includes healthcare
providers, government organizations, and financial institutions.
Hybrid
The cloud model that is significantly increasing in popularity
is hybrid, which fittingly combines both public and private clouds. This method
allows organizations to decide which aspects of their business they want in
each environment, allowing them to take advantage of all the benefits. Hybrid
cloud computing accommodates the need for scalability as well as security. It
is viewed as the best of both worlds because companies can complete
non-sensitive operations and collaboration in the public environment while
ensuring that critical data and applications remain controlled in the
private cloud. But, like the other models, the hybrid cloud isn’t all perks.
Its cons include greater complexity and increased management requirements. It
requires organizations to keep track of various platforms and ensure that all
facets of the business can communicate with each other. The hybrid environment
is best suited for organizations that experience business fluctuation but still
deal with confidential information. This includes e-commerce businesses, which
see constant traffic shifts but also deal with personal and payment
information. The hybrid cloud allows these types of businesses to complete
processing and basic operations up-front, while keeping the private
information, well, private.
SharePoint 2013 topologies
There are two type of approaches available for the topology as in the following:
There are two type of approaches available for the topology as in the following:
- Streamlined topologies: the distribution of services and other components in a farm is intended to maximize system resources of server hardware. Streamlined architectures include front-end servers, batch-processing servers, and database servers
- Traditional topologies: Topologies are based on traditional approaches to building architectures with Web servers, application servers, and database servers.
The traditional three-tier roles of a Microsoft SharePoint® 2013 farm can be deployed on a single server for evaluation or development, or on many servers. The three-tier roles include the following
Web server roleFast, light-weight server that responds to user requests for web pages. All web servers in a farm are mirrors of each other and are load balanced
- Hosts web pages, Web services, and Web Parts that are necessary to process requests served by the farm.
- Directs requests to the appropriate application servers.
- In dedicated services farms, this role is not necessary because web servers at remote farms contact application servers directly.
Application server roleProvides the service features of SharePoint products and technologies. An application server often provides all or a subset of service features. Multiple redundant application servers can be load balanced.
- In many farms, all services will run on two identically configured application servers for redundancy.
- The Search service application automatically configures the necessary services on application servers. Using the Services on Server page is not necessary.
- After deployment, look for services that consume a disproportionate amount of resources and consider placing these services on dedicated hardware.
Database server roleStores content and service data. All databases can be assigned to one database server. Or databases can be spread across multiple servers. All databases can be clustered or mirrored for failover protection. In a small farm, server roles can be combined on one or two servers. For example, web server and application server roles can be combined on a single server or on two or more servers to provide redundancy.
Service Applications
Service applications are services that are shared across sites within a farm. Some service applications can be shared across multiple farms. Service applications are deployed to the application server tier. Some services include multiple components, and deployment of these components require planning.
Service applications are services that are shared across sites within a farm. Some service applications can be shared across multiple farms. Service applications are deployed to the application server tier. Some services include multiple components, and deployment of these components require planning.
- Traditional web tier is redefined as Caching and Request Processing tier which would group similar web front end servers for end user request processing along with new service applications like Request Management and Distributed Cache which would require very low latency but very high throughout. Request Management is disabled by default and Distributed Cache is enabled by default. Since Request Manager is CPU intensive and Distributed Cache is memory intensive, both of these services can share same server without any major performance hit.
- Traditional Application tier is divided into two optimized tiers – Front End Servers and Batch Processing Servers.
- Front-End Servers would group similar service applications which would serve user requests with low latency, low resource utilization, and optimized for faster performance and response time. Services like Central Administration, Managed Metadata, User Profile, App Management, Search Query Role, and Business Data Connectivity are ideal for Front End Servers.
- Batch Processing Servers would group similar service applications which would typically require long running back ground processes, high latency, and high resource utilization, and optimized for higher workload by maximizing system resources. Services like User Profile Sync, Work Management, Search Crawl and Index Role, Workflow, Machine Translation etc. are ideal for Batch Processing Servers. For large scale farms, Batch processing tier can be divided further into specialized load servers for services like Search, PerformancePoint, or Excel Services which can cause high spikes in performance during peak time.
- Database tier stays same in both traditional and streamlined model. These servers can be either clustered, mirrored, or configured with Always On.
Installation Scenario | Deployment type and scale | RAM | Processor | Hard disk space |
---|---|---|---|---|
Single server with a built-in database or single server that uses SQL Server
|
Development or evaluation installation of SharePoint Server 2013 or SharePoint Foundation 2013 with the minimum recommended services for development environments. For information, see Minimum recommended services for development environments.
|
8 GB
|
64-bit, 4 cores
|
80 GB for system drive
|
Single server with a built-in database or single server that uses SQL Server
|
Development or evaluation installation of SharePoint Server 2013 or SharePoint Foundation 2013 running Visual Studio 2012 and the minimum recommended services for development environments. For information, see Minimum recommended services for development environments.
|
10 GB
|
64-bit, 4 cores
|
80 GB for system drive
|
Single server with a built-in database or single server that uses SQL Server
|
Development or evaluation installation of SharePoint Server 2013 running all available services.
|
24 GB
|
64-bit, 4 cores
|
80 GB for system drive
|
Web server or application server in a three-tier farm
|
Pilot, user acceptance test, or production deployment of SharePoint Server 2013 or SharePoint Foundation 2013.
|
12 GB
|
64-bit, 4 cores
|
80 GB for system drive
|
Component | Minimum requirement |
---|---|
Processor
|
|
RAM
|
For large deployments over 10,000 users, see the "Estimate memory requirements" section in Storage and SQL Server capacity planning and configuration (SharePoint Server 2010). This document does not apply to search in SharePoint 2013.
These values are larger than those recommended as the minimum values for SQL Server because of the distribution of data that is required for a SharePoint 2013 environment. For more information about SQL Server system requirements, see Hardware and Software Requirements for Installing SQL Server 2008 R2.
|
Hard disk
|
80 GB for system drive
Hard disk space depends on how much content that you have in your deployment. For information about how to estimate the amount of content and other databases for your deployment, see Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).
|
Minimum software requirements
This section provides minimum software requirements for each server in the farm.
Minimum requirements for a database server in a farm:
- One of the following:
- The 64-bit edition of Microsoft SQL Server 2012.
- The 64-bit edition of SQL Server 2008 R2 Service Pack 1
- The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter
- The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
- FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
- Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:
- Windows Server 2008 R2 SP1 (KB 2759112)
- Windows Server 2012 (KB 2765317)
- Microsoft .NET Framework version 4.5
Minimum requirements for a single server with built-in database:
Note: |
---|
At this time, Windows Server 2016 RTM is not supported. |
- The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 R2 Standard or Datacenter
Note: Windows Server 2012 R2 is only supported on a SharePoint Server 2013 Service Pack 1 environment. For additional information about Windows Server 2012 R2 support, see SharePoint 2013 SP1 support in Windows Server 2012 R2. - The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
- FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
- Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:
- Windows Server 2008 R2 SP1 (KB 2759112)
- Windows Server 2012 (KB 2765317)
- The Setup program installs the following prerequisite for a single server with built-in database:
- Microsoft SQL Server 2008 R2 SP1 - Express Edition
- The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for a single server with built-in database:
- Web Server (IIS) role
- Application Server role
- Microsoft .NET Framework version 4.5
- SQL Server 2008 R2 SP1 Native Client
- Microsoft WCF Data Services 5.0
- Microsoft Information Protection and Control Client (MSIPC)
- Microsoft Sync Framework Runtime v1.0 SP1 (x64)
- Windows Management Framework 3.0 which includes Windows PowerShell 3.0
- Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
- Windows Server AppFabric
- Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)
Minimum requirements for front-end web servers and application servers in a farm:
Note: |
---|
At this time, Windows Server 2016 RTM is not supported. |
- The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 R2 Standard or Datacenter.
Note: Windows Server 2012 R2 is only supported on a SharePoint Server 2013 Service Pack 1 environment. For additional information about Windows Server 2012 R2 support, see SharePoint 2013 SP1 support in Windows Server 2012 R2. - The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
- FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
- Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:
- Windows Server 2008 R2 SP1 (KB 2759112)
- Windows Server 2012 (KB 2765317)
- The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for front-end web servers and application servers in a farm:
- Web Server (IIS) role
- Application Server role
- Microsoft .NET Framework version 4.5
- SQL Server 2008 R2 SP1 Native Client
- Microsoft WCF Data Services 5.0
- Microsoft Information Protection and Control Client (MSIPC)
- Microsoft Sync Framework Runtime v1.0 SP1 (x64)
- Windows Management Framework 3.0 which includes Windows PowerShell 3.0
- Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
- Windows Server AppFabric
- Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)
Minimum requirements for client computers
- A supported browser. For more information, see Plan browser support in SharePoint 2013. For information on browsers supported on mobile devices, see Mobile device browsers supported in SharePoint 2013.
Minimum recommended services for development environments
The following are the minimum SharePoint 2013 services and service applications that are recommended for development environments:
- App Management service application
- Central Administration web site
- Claims to Windows Token service (C2WTS)
- Distributed cache service
- Microsoft SharePoint Foundation 2013 Site and Subscription Settings service
- Secure Store Service
- User Profile service application (SharePoint Server 2013 only)
Profile synchronization, also known as "profile sync," in SharePoint Server 2013.
A user profile is a collection of properties that describes a SharePoint user. Features such as My Sites and People Search use user profiles to provide a rich, personalized experience for the users in your organization. You can create user profiles by importing data from directory services, such as Active Directory Domain Services (AD DS). You can augment user profiles by importing data from business systems, such as SAP or SQL Server. The process of importing profile data from external systems and writing data back to these systems is called profile synchronization.
Get an overview of People Picker and links to topics about how to plan for People Picker in SharePoint 2013.
People Picker is a web control that is used to find and select users, groups, and claims to grant permission to items such as lists, libraries, or sites in SharePoint 2013. For web applications that use claims-based authentication, the People Picker control uses claims providers to list, resolve, search, and determine the "friendly" display of users, groups, and claims. A claims provider in SharePoint 2013 issues claims, which SharePoint 2013 then packages into security tokens for users.
Document management in SharePoint 2013
The elements of a document management system
An effective document management solution specifies the following:
- What kinds of documents and other content can be created in an organization.
- What template to use for each kind of document.
- What metadata to provide for each kind of document.
- Where to store a document at each stage of its life cycle.
- How to control access to a document at each stage of its life cycle.
- How to move documents within the organization as team members contribute to the documents' creation, review, approval, publication, and disposition.
The planning process
The document management planning process consists of the following major steps:
- Identify document management roles Ensure that your plans incorporate the feedback of your organization's key stakeholders, you have the best team to implement the solution, and you know who will participate in document management processes.
- Analyze document usage After you identify who works on documents, determine the kinds of documents that they work on and how they use them. For more information, see Identify users and analyze document usage in SharePoint 2013.
- Plan the organization of documents You can organize documents in site collections, sites, and libraries. SharePoint 2013 offers a range of features to help organize and store documents, from specialized sites to loosely structured document libraries for quick document creation and collaboration. Within a library, you can additionally organize content into folders and subfolders. For more information, see Plan document libraries in SharePoint 2013.
- Plan how content moves between locations It might be necessary to move or copy a document from one site or library to another at different stages of its life cycle. For more information, see "Plan the flow of content" in Plan document libraries in SharePoint 2013.
- Plan content types Use content types to organize information about documents, such as metadata, document templates, and workflow processes. This is an important step to help you organize your documents and enforce consistency across your organization. For more information, see Plan content types and workflows in SharePoint 2013.
- Plan workflows When you plan workflows for your organization, you can control and track how documents move from one team member to another as each participant collaborates in a document's life cycle. SharePoint Server 2013 includes workflows for common team tasks such as reviewing and approving documents. SharePoint 2013 also supports creating and installing custom workflows. For more information, see Plan content types and workflows in SharePoint 2013.
- Plan content governance You can plan the appropriate degree of control that is based on content type or storage location. For example, you might require that documents in a particular library be checked out before they can be edited. For more information, see Plan document versioning, content approval, and check-out controls in SharePoint 2013.
- Plan policies For each content type, plan information management policies to make sure that documents are audited, retained, and otherwise handled according to your organization's institutional and legal requirements. SharePoint Server 2013 includes policies that implement auditing, document retention, and bar codes (to make sure that printed content can be correlated with corresponding electronic versions). For more information, see Plan for information management policy in SharePoint Server 2013.
able: How document libraries are used
Library | Purpose |
---|---|
Library in a team site
|
Collaboration; easy sharing of content among peers; content control, such as versioning; SharePoint 2013 search.
|
Library in a portal area
|
Content that is intended for a wider audience in the organization; similar to a library in a team site, but typically implemented by using a stricter review and approval process.
|
Library in a Document Center site (SharePoint Server 2013 only.)
|
A large-scale library useful as an enterprise knowledge base or historical archive; includes features to help users navigate, search, and manage lots of documents in a deep hierarchy by using a set of specialized Web Parts.
|
Library in a Records Center (SharePoint Server 2013 only.)
|
Specialized records management; each library corresponds to a record type, such as contract, that the organization must retain for legal compliance purposes; libraries retain documents, metadata, and associated audits and are meant to be read-only.
|
Library in an Internet site (HTML) (SharePoint Server 2013 only.)
|
Content in web pages to incorporate into an Internet or intranet website; SharePoint Server 2013 supports editing web pages directly and manages the underlying document libraries for each page automatically.
|
Library in an Internet site (hybrid) (SharePoint Server 2013 only.)
|
Content available for downloading from a website; you can present content from document libraries on an Internet site.
|
Content type overview
A content type defines the attributes of a list item, a document, or a folder. Each content type can specify the following:
- Properties to associate with items of its type.
- Metadata to associate with items of its type.
- Workflows that can be started from items of its type.
- Information management policies to associate with items of its type.
- Document templates (for document content types).
- Custom features.
Plan workflows
Workflows implement business processes on documents, web pages, forms, and list items in SharePoint 2013. They can be associated with libraries, lists, or content types.
In document management, use workflows to route documents from person to person so that they can each complete their document management tasks, such as reviewing documents, approving their publication, or managing their disposition. Also, use custom workflows to move documents from one site or library to another. For example, you can design a workflow to copy a document from one site to another when the document is scheduled to be archived.
SharePoint 2013 includes the Three-state workflow, which you can use to manage business processes that track the status of an item through three states or phases. SharePoint Server 2013 also includes the following workflows that address document management needs:
- Collect Feedback Sends a document for review.
- Approval Sends a document for approval, often as a prerequisite to publishing it.
- Disposition Manages document expiration and disposition.
- Collect Signatures Routes a document for signatures.
Document Sets are a feature in SharePoint Server 2013 that enables an organization to manage a single deliverable, or work product, which can include multiple documents or files. A Document Set is a special kind of folder that combines unique Document Set attributes, the attributes and behavior of folders and documents, and provides a user interface (UI), metadata, and object model elements to help manage all aspects of the work product.
About versioning, content approval, and check-outs
SharePoint 2013 includes the following features that can help you control documents in a document library:
- Versioning is the method by which successive iterations of a document are numbered and saved.
- Content approval is the method by which site members who have approver permissions control the publication of content.
- Check-out and Check-in are the methods by which users can better control when a new version of a document is created and also comment on changes that they made when they check a document in
co-authoring feature in SharePoint Server 2013 or SharePoint Online to enable multiple users to work on a document, at any time, without interfering with each other's changes. Co-authoring removes barriers to server-based document collaboration and helps organizations to reduce the overhead associated with traditional document sharing through attachments
How would you a set up SharePoint farm for our 800 active users?
What would the network topography look like?
·
What most people say: “We can stand up a server
for SharePoint itself that should handle all tasks and keep implementation
simple. We can rely upon an existing SQL server to house our SharePoint
databases.”
·
What you should say: “At a minimum, the farm
should consist of a couple of load-balanced Web front-end servers to handle the
network traffic and serve up pages, one application/central admin server for
SharePoint services and management, and an SQL cluster for the SharePoint
databases. This should handle traffic load and keep performance high for this
mid-size SharePoint farm. These servers should likely all be within the
company’s perimeter network (DMZ) and have access to a Domain controller. An
additional SharePoint farm should be considered for development, QA, and
staging purposes.”
·
Why you should say it: SharePoint quickly becomes
a business critical platform to any companies that implement it. Uptime is
critical. Setting up a farm that handles server failures and keeps going is key
to assuring success.
Load balancing the front-end will provide performance gains and
keep SharePoint running even if a Web server goes down. These web servers can
also be tasked to take over SharePoint services and admin in the case of a
failure of the application/central admin server.
The database servers should also be protected against failure,
an SQL cluster or a similar configuration that assures no single point of
failure. Additionally, SharePoint databases should never be housed on the same
server as other databases.
The two primary reasons for this are that SharePoint databases
require a lot of resources, and because the other databases can pose a risk to the
environment when they cause errors or drain too many resources.
When setting up a SharePoint farm, security of the data that it
will house is critical but sometimes overlooked. Whenever possible, the
SharePoint farm should be protected within a company’s DMZ. Additional risk to
a SharePoint farm comes from software updates, patches, hotfixes, custom code,
third party tools and applications… the list goes on. To protect against these
types of risks, it’s worthwhile to develop custom code in a separate environment
and test all planned software and configuration-level changes in a controlled
“staging” environment before they’re moved to the business critical SharePoint
farm.
What should SharePoint governance look like at our company?
·
What most people say (Version 1): “Our
biggest concern has got to be user adoption with SharePoint. Governance needs
to open the door for user adoption. If we over-govern SharePoint, it will turn
people away.”
·
What most people say (Version 2): “Governance
is crucial to any and every change made to SharePoint. We need to develop out
clear and concise rules on how any kind of change should be made.”
·
What you should say: “Governance is key to
success with SharePoint, however I cannot yet say exactly what form SharePoint
governance should take for your organization. We’ll need to look at the
environment and have discussions with its users before we can draft out what
governance should look like for this company (or this SharePoint farm).”
·
Why you should say it: SharePoint governance is
the way in which SharePoint is managed and administered. SharePoint itself is
just a platform and every company uses it in unique ways. What’s good for one
company could be disastrous for another. At any given company there can be
different policies for different SharePoint farms. The way a portal is
administered is vastly different from how a collaboration or team space should
be administered.
We need to organize and tag information with a shared company
vernacular, like product or department names. This information needs to be
stored consistently across SharePoint. How would you implement this?
·
What most people say: “We either can provide
lists of acceptable values and train our administrators to enforce these naming
conventions, or we can setup Managed Metadata and Content Types to enforce
these conventions.”
·
What you should say: “We should plan out and
define an information taxonomy alongside a governance plan for SharePoint. By
doing that, we can assess and implement the best solution for managing the
information in our SharePoint farms.”
·
Why you should say it: There are many ways to
manage information within SharePoint. Some are federated, some are centralized.
It’s not enough to know that you can setup Managed Metadata or create Content
Types. Without a plan on how to manage information, these forms easily can
become overwhelming and difficult to manage. This quickly leads to disuse and
the abandonment of whatever information architecture that was intended.
By assessing and defining how information should be organized,
via a clear and understandable information taxonomy outline, you can develop an
information architecture. By developing a good governance plan, you can assure
that this architecture will be maintained correctly. Without both the taxonomy
and the governance, you end up with a Jenga tower of competing information
architectures.