Provisioing Site Collections using CSOM - Tenant Admin API

Overview:  This post looks at provisioning site collections using CSOM.  You can also provision site collections for SharePoint using PowerShell or any Server side object model. 

Points to Note:
Programmatically you can provisioning new site collections using CSOM using 2 approached namely:

1. Tenant Admin API
2. Http Post method (mimic the SharePoint UI for creating a site collection)

Note: Neither approach allows you to specify the Content Database to connect to, you shall need to manage the CDB you site collection goes into using the round robin site collection OOTB method for on-prem SP. 
Note: Tenant Admin API does not allow the Quota template to be specified.  See the FAQ section in this post.
Note: Tenant Admin API requires the April 2014 SP CU or later
Note: the Search Service Application needs to be configured to handle multi-tenancy to work correctly.  As do other the Service Applications using partitions to support multi-tenancy.  If you already have existing running farm, the change is a considerable effort.  The SA need to be created in partition mode and cannot be amended after creation (you will need to re-create the service Application).
Note: Using the Tenant Admin API for SC creation - you don't get the usual SP groups such as owner, contributor and visitor - you need to manually create them.
Note: I don't believe you can use the Publishing Site Template using the Tenant Admin API.
The Tenant Admin Site Collection can reside on the same or another Web Application where the site collections shall be provisioned.  Each Tenant Admin Site Collection (has it's own site template 'tenantadmin#0') has a SubscriptionId (Subscription Group) and when using the Tenant Site collection to create a new site collection, the new site collection is given the SubscriptionId for the group i.e. you can't specify the SubscriptionId declaratively).

Outline of steps to setup the Tenant Admin API:

1. Service Application need to be configured in partition mode (important SSA are: search, UPA, MMS, BCS, SSS, there are more).
2. Enabling remote site collection creation using CSOM on the Web Application
3. Enable AdministrationSiteType property from a site collection to "TenantAdministration"
4. Enable SelfServiceSiteCreationEnabled on the Web Application
5. Set Up Tenant Admin for Multi Tenancy/setup subscription

More Information:

Multi-tenancy/Site subscriber explained by Bill Baer
Spencer Harbar's Rational Guide to Multi-tenancy is a useful resource
General guidance for hosters in SharePoint Server 2013 provides insight into Multi-Tenancy
https://technet.microsoft.com/en-us/library/dn659286.aspx

Scenarios where multi-tenancy potentially shall be used:

1. O365/SharePoint Online
2. SPO-D
3. Hosting companies
4. Government implementations such as G-Cloud
5. Large Enterprise (only with extreme requirements)

Notes on HNSC using Tenant Admin API:

• When creating a host name site collection with managed paths e.g. http://acme.com/sites/daffy, you need to create the corresponding root hnsc for the routing to work i.e. http://acme.com.
• Creating a hnsc with a path is consider creating a hnsc not a path based site collection or a combination of the naming.
• The manage path /sites/ which is already created works as it is already setup.  If you want another managed path you need to configure this separately.

Quota Limits:
Quota max storage size and code points are parameters in the CSOM Tenant Admin API, they don't set these values and you cannot set the quota templates using CSOM.  You only 2 options at this point in time is to use the UI and apply a template, not really an option for customers with hundreds, thousands or tens of thousands of site collections or you use PowerShell/ the Server side object model.

Permissions:
To be able to provision a new site collection, the account used to provision shall need to have contribute rights (it feels low and simple to me but that is the min) or higher on the Tenant Admin Site Collection.

Troubleshooting Tenant Admin Site Collection Provisioning:  Update 2017-06-28
I had tremendous problems with site collections not being completely created using CSOM and the tenant admin API on a new server that was provisioned by our engineering department.  There are a couple of IIS and farm setting you will want to review should you get this issue and our amazing team figured this out so it is not my credit.  Gonzalo, Uzzey and Anthony with thanks!

Change IIS timeouts on the WFE's and SP farm configs, this made the site collections provision completely correctly.

Remote Event Receivers Basics

Overview:  Historically we use Full Trust Code (FTC) within SharePoint 2010 and MOSS to have the ability to handle events in SharePoint such as an item being added to a list.  Since SP 2013 and going forward, full trust code is not the preferred approach and Microsoft of Remote Event Receivers (RER).

Notes:

1. RER are web services that implement the iRemoteEventReceiver interface and a remote web server (WS). RER's WS can be hosted on an IIS application server (including Azure).
2. Asynchronous events supported with different code approaches: 1. Synchronously call on the before and after events i.e. ItemUpdating, ItemUpdated 2. Asynchronous on past event/-ed events i.e. ItemUpdating only.
3. RER's can be fired on SP events such as list item changes, BCS events, 

Complete and publish!!

SharePoint 2016 Points from the Ignite Conference

6 May 2015


SharePoint 2016 new features (from the Ignite conference 06 May 2015)
http://www.learningsharepoint.com/2015/05/07/sharepoint-2016-new-features-and-enhancements/

 

Notes:

1. Office Graph and Delve are important in SP2016.
2. MS are releasing a search add-on for SP2013 later in 2016, this will be part of SP2016 (vNext). The add-on stores the index on o365. allows seemless indexing of on-prem and O365 using AD to AAD sync.

Download all the Ignite Videos and Slides:
https://gallery.technet.microsoft.com/all-the-Ignite-Videos-and-b952f5ac

SWAY for SharePoint

Check out: https://sway.com/

My simple SWAY example:
https://sway.com/D7pmu7ot105S6SKs

More Info:
http://www.citeworld.com/article/2690333/consumerization/microsoft-sway-powerpoint-on-steroids.html
http://blogs.office.com/2014/10/01/announcing-office-sway-reimagine-ideas-come-life/
 

Code Reviews for SharePoint

Overview:  Customisation in SharePoint takes different forms and having suitable environments to test code in before setting it free in production is essential.  This post looks at various types of customization and how to code review.  As a solutions architect and when I was running the Application Development CoE for a large multinational having standards and a code review checklist help immensely.  Improving code quality and finding issues early reduces the cost of building applications so code reviews are a good idea.

There are several automated tools for performing code review that target different application platforms (think FTC in SP2010 vs App Model in SP2013).  When automating the tools, it is good to select the templates/rules that match your organisation and maturity.  Ensure you customise the rules so they not reporting issues when in fact these are your standards (an example is naming in FxCop differs from the SharePoint code naming conventions used by different businesses).

Note: The code review requires depends on CSOM, FTC or JavaScript.  Depending on what is being created/built will require different code review.

There are several automation tools that can help identify poor quality code early within the development process.  Like peer reviews, these tools can help developers implement their code in the correct manner.

Note:  Define your coding standards, have up to date architecture diagrams for architects and have the rules when and what features your developers can use.  It's fairly common for outsourcing companies to build a solution to find out you don't allow the technology they have built with.  I remember an InfoPath based solution coming into my app development center a few years ago and they could not understand that the organisation would not merely turn on InfoPath.

Note: A lot of the tools we previously used in SP 2010 for FTC solutions are not relevant to SP 2013, namely SPDisposeCheck.

Code Review Tooling Options:

1. Visual Studio
2. FxCop (Config in VS so it runs with the same rule set as SPCAF)
3. StyleCop (Config in VS so it runs with the same rule set as SPCAF - forces enforcement of code style at design time)
4. SPDisposeCheck (SP 2010 only, don't use in SP2013 even for FTC solutions)
5. MSOCAF
6. SPCAF (SharePoint Code Analysis Framework)
7. Black Duck - Build into CI/CD pipeline checks for open source software and identifies potential security issues and highlights licencing concerns.

The 3 areas where code reviews can be performed are:

1. Developer at run time (think Visual Studio)
2. Continuous delivery (think gated check-ins)
3. Formal Code reviews (think solutions architect and quality manager) 

Manually reviewing code is better than nothing (automate where possible) and some basic rules and guidance is provided below.

Summary:
Code reviews improve maintainability, pick up bugs, ensure efficient code, code that shall run in production, improve security, performance and reduce the total cost of ownership.  Automated tools are worth considering and the top tool for me is SPCAF.  Do code review early, often and automate.

JavaScript Code Review Checklist:

1.> Project Structure - js into script folder in the solution file (group images, css, js and file types so the projects are easy to understand and consistent in layout)

2.> use strict directive on all pages "use strict";

3.> Always use Javascript namespaces - avoid conflicts

4.> Move hard coding to constants at the top of the file, not single use meaningful info like undefined in.  Move declarations to the top.

5.> Only used approved frameworks like jquery, notify if any other frameworks are used.

6.> Commenting.  Ensure method names tell coders what the method is performing.  Add comments that explain the method.  Don't be afraid to add value by adding inline comments. 

7.> Display friendly messages to the users if something goes wrong and add error handling to tracking /logging such as console.log() or log to ULS from an app using the provide JS api or log to a common logging mechanism.

8.> Single spacing  (no flower potting)

9.> Remove commented out code/unused comment out calls etc.

10.> Always end your switch statements with a default statement.

11.> Ensure coding standard are consistent consider using http://www.jslint.com/

12.> Code adheres to your agreed coding standards and example is http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

C# Coding Standards for SharePoint

This is a checklist, the recommendations need to be matched to your business and some scenarios such as complied C# for PowerShell plugin won’t use all the items in this checklist.

1. Have you followed the Enterprise design guidelines, branding guidelines and coding standards.
2. Have you used the Commenting standards e.g. http://msdn.microsoft.com/en-us/library/b2s063f7.aspx
3. Avoid declaring inline literal strings
4. Check empty string using length e.g. if (email.Length()=0) don't use if (email.Empty || email = "")
5. Use StringBuilder for concatenation don’t keep appending strings
6. Return Empty array rather than null
7. Methods must be short and focused.  Method names must be meaningful
8. Use method Overloading, not different names for the same method.  Try keep Classes small i..e under 500 lines.  If larger use #Regions to split up the code.  Pass objects into Methods rather than multiple variables if more than 6 parameters.
9. Enumerators should be used where possible, code is more understandable and options are easy to reuse.
10. Only import namespaces you need and dlls.  Split code into separate assemblies and use company standard naming with appropriate namespaces naming.
11. Make helper functions i.e. don't rewrite code several times - refactor
12. Open connections (SQL and SharePoint) as late as possible and ensure you wrap in error handling and dispose of connections in the finally statement
13. Reuse core code libraries (ensure commonly re-used functionality is add into core libraries cross-cutting concerns/logging/ email)
14. Use exception Management/Try catch.  Try catch must try catch specific errors and lastly catch all errors.  No business logic must rely on using catch statements.  Don't throw exceptions within exceptions.  Catch errors as specifically as possible, die gracefully and appropriately, log the errors using the CoE code core block that puts exceptions in the farms ULS and event viewer.   And potentiall the enterprise logging platform.
15. Dispose of SPSite and SPWeb Server site objects where appropriate. Run http://code.msdn.microsoft.com/SPDisposeCheck before deployment
16. Run stylecop and code analysis on code regularly and before deployment
17. Your code is x64 bit compiled. 

Have a common code/core code library that deals with cross cutting concerns, logging, caching etc.

using Microsoft.Practices.ServiceLocation;

using Microsoft.Practices.SharePoint.Common.ServiceLocation;

using Microsoft.Practices.SharePoint.Common.Logging;

ILogger _logger = SharePointServiceLocator.GetCurrent().GetInstance<ILogger>();

Exception ex = new ApplicationException("This is my test exception");

_logger.LogToOperations(ex); 

Security in C# and SP

1. Plain text passwords are not in stored Web.config, Machine.config, or any files that contain configuration settings. 
2. Input surfaces such as application pages, site pages, web parts and other customizations perform client and server side validation to protect from cross-site scripting (XSS) and SQL injection. 
3. Minimal use of elevated privileges to interact with SharePoint objects. 
4. Sensitive data is not stored in URLs, unencrypted cookies in hidden form fields, query strings or with code. 

HTML/CSS

Section 508 US Standard to ensure federal agencies 

WCAG 2.1 compliant standard should be adhered to and will cover: Jaws/Browser testing, screen zooms and brail readers.  WCAG 2.2 is due out in 2021.

RWD testing e.g. Mobile/Phone testing

SEO

SQL Standards (Establish SQL standards), a small example is:

1. No spacing in naming objects
2. Do not use reserves words in SQL
3. Name tables in sigular e.g. "Patient" not "Patients"
4. No Underscore in table naming and use Camel case e.g. "PatientResult", underscores are fine in column and Store proc naming.  
5. Do not prefix tables e.g. "tbl_Patient" or "tblPatient" 
6. Prefix view with "vw" e.g. vwPatientHistory
7. Boolean columns prefixed with "Is" e.g. IsActive
8. Stored Procs prefix with "usp" not "sp".  E.g. uspDeletePatient, use the format usp_Verb_Noun
9. Prefix functions with ufn 
10. label foreign key using the prefix fk and follow the format fkTableColumn e.g. fkPatientId 
11. Make your -SQL readable not on 1 line.  Use line-breaks, no empty lines and indent spacing to make the code readable.
12. How to comment must be standardised

This list goes on but as a starting point...  Pls post if you feel anything else is relevant.

DevOps Tooling

DevOps Tooling Notes

DevOps Tooling is broken down into the following areas, note the tools often overlap in function.  The list is not exhaustive but these are the more common tools I have come across.

1. Version Control: TFS, Git, SVN, ...
2. Bug Tracking: ServiceNow, Jira, ZenDesk
3. Continuous Testing: Selenium, Jasmin or Mocha or Unit.js (JavaScript testing), NUnit, Web Tests (Visual Studio), SpecFlow
4. Continuous Integration (CI): TeamCity, Jenkins, Azure DevOps (bigger) 
5. Configuration Management and Deployment:  Puppet, Chef, ANSIBLE, SALT  (all installed on Linux, obviously work on Windows environments)
6. Containers: Docker, Kubernetes, Microsoft Containers. I think the Azure AKS is pretty much containers for Azure now.
7. Other:  PowerShell, VMWare, HyperV

RESTful API Tooling

1. Swagger - awesome.  Swagger is a set of tools that help document, build and test your API  (Your API conforms to the OpenAPI specification or Swagger specification).  Great way to get a contract for users of the API early on.  Updated 2019/11/25:  Link to Swagger post
2. Swagger UI, Swagger Integrator,...
3. Apiary - UI to create an API and publish with mocks.  I prefer Swagger or on simple projects APIM.
4. API Management (APIM) - flexible Azure service for bring together multiple API securely.  Same as MuleSoft.  Can import OpenAPI's v2 or v3 to create a hosted API.  Can mock and built in test tool.
5. RAML is an alternative to Swagger and Apiary (never used)
6. Blueprint - API documentation tool.  Pretty simple and nice results.
7. Postman - send http requests to the API.  Postman is a REST client useful to check your API.  This is my main tool for testing, exploring REST based API's.  
8. SoapUI - if working with SOAP/XML.
9. Slate - API documentation - I always use OAS/OpenAPI/Swagger.
10. Fiddler - I'm old school and still love Fiddler and it's capabilities.  Fiddler is a great HTTP debugger.  
11. BURP - an HTTP debugger to review traffic.  I've used BURP for security testing and it is great for API debugging.  
12. Charles is another HTTP debugger (never used).
13. cURL - Cmd line to test API's using HTTP, separate exe to run on Windows, Windows 10 has cURL built in.
14. Visual Studio
15. Wireshark - Over the years I have needed packet sniffing to fix issues and always go to Wireshark, I used the tool in the 90's but it had a different name.  Extremely useful for issues relating to firewalls, especially when an environment reacts differently to another working DTAP environment.
16. Tcpdump is another packet sniffer

Testing:
http://www.incyclesoftware.com/2014/02/executing-selenium-ui-tests-release-management/

More Info:
http://blog.sharepointsite.co.uk/2014/02/devops-and-sharepoint.html
http://www.networkworld.com/article/2172097/virtualization/puppet-vs--chef-vs--ansible-vs--salt.html
http://blog.sharepointsite.co.uk/2013/11/iac-presentation-for-sharepoint.html

PhoneGap and SharePoint

For Mobile Start HTML5 Mobile web App, then PhoneGap (wrapper to interact with devices),
Xamarin, recompiles to each platform, lastly write for each native platform thin iOS/objective C for Apple. PhoneGap and Xamarin are comparable with respect to performance and have trade-offs based on code reuse, developer skill set, and integration into standard developer tool sets

Idea: Start by building HTML5 sites with a responsive design then leverage these HTML5, CSS and JS assets hooking into SharePoint and extend with device capabilities using Hybrid framework (PhoneGap)

Feature	HTML5	PhoneGap
Web view	Yes	Yes
Audio/Video files	Yes	Yes
Location	Yes	Yes
Local storage Yes	Yes
Camera	No	Yes
Accelerometer	No	Yes
	Yes
Notifications (local, alert, push)	No	Yes
Compass	No	Yes
Native UI	No	No
Access to full API/SDK	No	No

Also see:
https://xamarin.com/