SharePoint 2013 Architecture my notes

SharePoint 2013 Architecture my notes

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:

• 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.

• 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.

Hardware requirements—web servers, application servers, and single server installations

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

Hardware requirements—database servers

Component	Minimum requirement
Processor	64-bit, 4 cores for small deployments (fewer than 1,000 users) 64-bit, 8 cores for medium deployments (between 1,000 to 10,000 users)
RAM	8 GB for small deployments (fewer than 1,000 users) 16 GB for medium deployments (between 1,000 to 10,000 users) 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.

Information management policies and policy features

Policies can be implemented to help an organization comply with legally mandated requirements, such as the need to retain records. For example, a Human Resources policy, used in an organization to ensure that employee records are handled in compliance with legally recommended guidelines, could include the following policy features:

• Auditing, to record the editing and viewing history of each employee-related document.
• Retention, to ensure that work-in-progress content is not kept for an unnecessarily long time.
• Print restrictions, to ensure that sensitive employee-related documents are printed only on secure printers. Note that this is an example of a custom policy feature that must be implemented by using the SharePoint Server 2013 object model or obtained from a third-party software vendor.

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.