SharePoint 2016 Preview (Public Beta 1) on-prem Notes

Disclaimer:  This notes I made from workshops, what I have heard and the Unity Conference in Amsterdam 12-14 Oct 2015.  A lot of this information is from the workshop with Neil Hodgkinson and Spencer Harare), this is my takeaway summary.

Notes for Sp2016:

• Same HW req as 2013.  Farm servers min still Mem 12-16 CPU x64 1x4 Disk, Disk 80GB
• Pre-reqs: Win 2012 R2, Win Mgmt Framework 3.0 gives us DSC, .NET 4.5.2 ..., DSC can be used to pre-bake the VM image.
• Same DB rules as recommended by MS, loosing dbs from 2013;  No new DBs, need SQL 2012 or 2014 (except project Server DB which is not part of SP).
• Need Win 2012 standard or higher, not web edition, also dev can support windows 10
• Still no support for VMWare dynamic memory
• End-point encryption for SMTP

 - Upgrades and Patching

• No Foundation edition, SP2013 found to Sp2016 Server
• Path SP2013 > SP2016
• SC must be in 15 mode to upgrade
• Service Apps need to go SP2010 > SP2013 > SP2016
• SP2010 to SP2016 need to go to 2013 RTM baseline
• Changed patching, smaller packages and fewer restarts
• PSConfig not locking farm, can run multiple psconfigs and lower/zero down time patching (with HA farms)

 - Roles & Services

• Consider moving low impact services onto the traditional WFE role, keep the long running/batch processing (Crawl, search, MTS,  et al) on the app servers.
• WFE (Access services, SSS, Subscription Services, UPS)
• Distributed Cache has a quorum so need 3 not 2 for NA.
• Health Analyser rule for min role enforcement:  Puts min role in the correct state.
• Min Role does not manage the search topology
• Watch, switching min roles as index would be lost unless it is replicates (2 instances of each index)
• Services in Farm overrides the starting of services in the Min Roles,  so can never start "Request Management" in the "Services in Farm" but still use "Distributed Cache" min role.
• Can always switch min roles "Convert server role" or create custom roles (watch as needs multiple instances to keep running and index could disappear).

 - Key Thresholds for 2016:

• CDB sizing
• 100K SC per CDB
• Max file size 10GB
• Search index up to 50 million items

  - User Profile Sync:

• UPS Sync (FIM) is not Microsoft Identitiy Management (MIM)
• 2 modes: Active Directory Import (light weight, not useful for most large enterprise clients, e.g. Can't import pics or use BCS) or MIM 2016
• AD Import: faster than 2013, can only use AD, no profile picture. 
• MIM 2016 was FIM - Standalone product, only using the sync engine part for SharePoint (free if only use this service, does need Win 2012 and SQL Server licence)
• Using MIM management agent map AD properties to SP user Profile properties
• Syncing is driven by MIM not by SharePoint (UPS sync)

- What's New:

• Post to yammer from SP2016 doc library
• Improved integration
• Image and Video Preview (changed)
• Doc Lib accessibility (improved keyboard short cuts, VI user experience improved)
• SC creation faster on SP Site template using SPSite.Copy
• Project Server is part of the SP binaries/install, project server using it's own project db and adds 4/5 tables to the content database.  Project Server affects 3 DB (Project db, content db and config db)
• Save and share email attachments in SP2016

- Release Dates

• Preview = Beta 1 Aug 2015
• Beta 2 RC  = +- Nov/Dec 2015
• RTM Q1/Q2 2016

Hybrid Search 2016 Notes

Hybrid Search SP2016 (Also applies to SP2013):  Mixing on-prem and SPO results

• Search can add all crawls into a single index within SharePoint online (historically we have had to use Search Federation to try combine result sets).  So historically we use search federation whereby there are multiple indexes that are the shown on a single page this approach for search result federation is refereed to as "Search-time merging".

Federated Search provide by MOSS, SP 2010 and SP 2013

• The Index is held on SPO.  The new model is refereed to as "Index-time merging".

Single result set from multiple farms (joined the indexes into an SPO index). vNext hybrid search.

• Crawls done on SP2016, 2013 and maybe 2010 are pushed into an Azure queue which in turn is combined onto the SPO index (I believe the Index is encrypted as rest in SPO)
• Dir Sync is required between on prem AD and Azure AD 

UnityConnect Conference 2015 Amsterdam Search session - Architecture of Hybrid Search

User Profile Service Application Notes

The People Picker Control in SharePoint 2013 & 2016

• The People Picker control is used to find user, groups and claims.  You'll notice the people picker UI has 2 queries (you can normally see the lag), firstly the people picker looks at the UserInfo list in the local site collection and then it also looks at Active Directory (this is where the custom claims providers need to be written if you don't use AD).  A common misconception is thinking the people picker users the UPA to look for users, it does not use the UPA directly.  Indirectly, if the UserInfo is populated the People Picker gets the user from the 1st lookup.
• The UserInfo table is populated with the initial stub when a user is added to the security or the 1st time the login to the site collection.  
• The UserInfo list is not updated if you add the user via an AD group or if you pick the user in a list within a people picker column.
• The UserInfo on each site collection gets an initial stub of information in the list and a timer job at the web application level looks for a list of users to perform a sync (update more into for the user in the userinfo table), this runs every 5 minutes by default.  Job is: User Profile to SharePoint Quick Sync.

Updated 2018-02-22: Useful post of AD, UPA and UserInfo table:
https://blogs.technet.microsoft.com/marj/2016/03/14/what-is-hidden-user-information-userinfo-list-in-sharepoint-20102013-and-how-to-fix-when-it-causes-a-site-collection-to-show-old-user-metadata-properties-in-people-picker-control-or-in-a-person-or/

This explanation feels hard to follow but to me this makes sense - hope it helps!

Performance Testing Check List

Rough Notes

Performance Factors Checklist:

1. Geography and networking - Australia and Africa users always tend to have issues regardless of the centralized SharePoint farms they are accessing.  Poor networking especially in remote satellite offices is not a SharePoint issue but as enterprise grow these are the pains they need to work out.
2. Security and network design
3. Usage patterns (Working with documents in the UK after noon when the US comes online may have a peak usage rate 5 times higher than when Australia starts in the morning)
4. Functionality (Search is heavier than displaying a static web page)
5. Application design (too many web services calls when 1 can do all the calls) and application implementation.  The application needs to meet the functional and non-functional requirements.  Coding error creep in, implementation needs to meet the design and unnecessary code improved.
6. Platform (2 server VM farm will only get a set load no matter how well it is tweeked)

Figure out where the bottlenecks are and how big the impact is:

• SQL is a common performance bottle neck, check you have optimized SQL
• Monitor all server in your farm, the random, throw more RAM at the solution is pointless most of the time.
• Size of lists in SP
• Size of Content
• Physical architecture
• Search - design, how many items are crawled are they all needed, multiple search farms, what is going on, AD groups preferential to individual users
• WAN latency Testing
• Baseline SP testing
• Peak loads and what is affected (Monitor and prove where the issues are).  Concurrency and usage patterns.
• Archiving, document retention, document versioning, unwanted general storage area, recycle bin, can we clean up
• Optimize highly used page - for example if your home page leverages search and the search service and farm is therefore under load, more the search component into a cached solution or pull off the home page.
• Auditing logs - Do you log enough, do you log too much can you pull them out of the Content DB and store them elsewhere.
• Encryption (TDE, SSL, Devices)
• Web page basics: image size, CDNs, JavaScript optimisation, sprites

SharePoint 2013 Workflow options - notes

Overview:  There are a lot of workflow options and each of the solutions lend themselves favorably to different circumstances.  In this post I look at the more common options around workflow for SharePoint.  The 3 options I'm exploring are: K2 blackperl, Nintex and SP2013 WorkFlow Manager.  Also note that existing SP2010 workflow still exists and is an option if your business has workflows on the platform already or you have this skill set available.  There are other products but these are the main stream options.

So each of these products has their place and suit different organisations.  This post is my opinion and I am not a workflow expert and show my thoughts on when I would favor 1 of the approaches.

Licencing:  Workflow Manager does not have the licencing costs.  Nintex has a server and CAL licencing model and K2 has a server licencing model.

Skills:  what are your existing in-house skills.  If you already have K2 or Nintex expertise it makes these products far more attractive.

Size:  How big is your organisation, how complex are the workflows, how many workflows and how often do they change shall influence the workflow option to select.

SharePoint 2013 Workflow Manager
SharePoint 2013 introduces an new standalone workflow engine based on Windows Workflow Manager 1.0 using .NET 4.5.  In the SP 2013 world, Office Web Apps (OWA) and Workflow Manager runs as a service separate from SharePoint 2013.

• SharePoint Designer 2013
• Ideal for simple or medium complexity workflow processes
• Limited to a pre-defined set of activities and actions
• Relatively quick and easy to configure
• Custom workflow development through Visual Studio
• Can implement state-machine workflows
• Supports custom actions/activities
• Supports debugging
• Ideal for modelling complex processes
• Requires a developer
• Workflow Manager
• High Density and Multi-Tenancy
• Elastic Scale
• Fully Declarative Authoring
• REST and Service Bus Messaging

Nintex

• On-premise and cloud workflows – but cloud workflows do not allow custom actions
• Nintex uses the SharePoint workflow engine
• Easy to create Nintex workflows (good tooling) but not so easy to upgrade and maintain if complex – they require a proper dev environment if workflows require changing
• Tight coupling with SharePoint – so upgrades need to be planned. Some workflows have broken after upgrade.
• Can create custom activities but these are limited to constraints imposed by Nintex design surface
• More suited to State machine workflows using reusable custom modules and user defined actions.
• Nintex uses its own database which you will need intimate knowledge of when it comes to performance issues.

K2

K2 – technology agnostic – best suited if SharePoint is only a part of your technology snapshot, some folks consider K2 a BPM product.

Pros:

• Off box WF hosting:  Allows for increasing the number of blackperl servers and no resource overlap, flexible licencing model as it is server based
• Well tried and tested workflow engine
• Good reporting and troubleshooting
• Excellent SOA layer (SmartObjects) with multiple products.  This is more an EA feature as it can be a great way to create an SOA.  Allows API to connect to custom SQL, CRM, SAP, Web Services.
• Proven advanced tooling, good visual tooling (not as good as Nintex IMHO)

Cons:

• Cost is relatively high, support costs are extensive, need to pay for dev and pre-prod licence
• Not based on the latest MS workflow engine
• Not easy for end users to build WF (despite marketing noise)
• Setup and monitoring is specialised and will require advanced K2 expertise
  Difficult to back out of product
• Tooling requires training and breaking out of OOTB features requires a high level of expertise and dependency on K2
• Support tended to be patchy with technical knowledge

Updated: 2017-11-03.  Possible Extranet facing blackpearl Infrastructure design

Summary:
K2 is a good product if you need to build an SOA layer for integration, are prepared to install correctly (cost) and maintain.  You shall need dedicated workflow people to create the workflows.  So in the right circumstances it has it’s place.

Updated 11 December 2019:
Microsoft Power Automation (formerly Microsoft Flow) is the default workflow option when working with the Microsoft Power Platform (Power Apps, Power Automation and Power BI).  O365, SPO and D365 can also use Microsoft Power Automation.  Azures Logic Apps is also a good option especially if your application is C#/Azure based and not within one of the SaaS Azure offerings.

Content Type Hub and MMS Notes

This topic has been well covered and this post merely calls out items I feel are worth knowing.

Notes:

You can configure more than 1 MMS assigned to a Web Application. 
You can have multiple CTHub that your sites can subscribe to.  Think it is up to 4.

After publishing, new SC will get the CT's pretty quick whereas the updates to existing CT in the downstream SC take some time to permeate out.  Timer job on the subscriber Web Application goes thru SC and gets the latest CT (it will over write any local changes).  No Granular push out (check with JJ).

Terminology for MMS (Term Group, Term Sets and Terms):

Non Functional Testing for SharePoint

Overview:  Functional Requirements are the business requirements that the business define for the application being built.  Non-functional testing is concerned with performance, reliability, scalability, recovery, load,  security and usability testing.  For SharePoint it is a good idea to test this at a platform level and then verify the individual application non functional testing is appropriate.

SharePoint Non Functional Testing:
All of these test should be performed against your various SharePoint platforms and will dictate the SLA's offered to the business using SharePoint as a service.  Baseline testing is a good idea as the differences can be used to determine the efficiency of the individual application being created.

Proxies:
Fiddler is my favourite (other tools for capturing web traffic Charles, BurpSuite, WireShark and you can use the developer tools shipped with the browsers). tcpdump, goPacket are awesome for network monitoring.

Use Fiddler to:

• Observe traffic (http/https requests, headers,..)
• Replay sessions, 
• Evaluate performance,
• Set break point

A common misconception is the function of performance vs load testing.  

Performance is primarily concerns with looking at typical user usage scenarios and see how long each page takes to load.  So a recorded script with wait time between recorded calls is useful  It's also worth looking at the same page with minimal data and also with large amounts of data.  

Load Test involves recording the standard users interaction (ensure some users query heavy and some light amounts of data), there are no wait times.  The norm is to multiple this concurrent number of users by 100 to know the amount of users the farm business application can support.  e.g. a concurrent user load of 100 users where the performance is acceptable means the farm should handle 10,000 users (100 users times 100).  You run the 100 users in a steady state for a few hours.

Stress testing is similar to load testing but you keep stepping up the number of concurrent users until the SharePoint farm starts running out of resources and throttling requests.  Once the system degrades and performance is not acceptable is pretty much how many users the application on the SharePoint farm are supported.  So if the performance throttles at 170 users, the farm can handle 17, 000 normal usage users.

References:
http://www.guru99.com/non-functional-testing.html