The "disaster" of SharePoint Server 2016 MinRole

MinRole is a new farm topology based on a set of predefined server roles introduced in SharePoint Server 2016. When configuring your SharePoint farm, you now select the role of a server when you create a new farm or join a server to an existing farm. SharePoint will automatically configure the services on each server based on the server's role. SharePoint Server 2016 has been optimized for the MinRole farm topology.

After we followed the Microsoft instructions to configure the SharePoint 2016 servers as Front-end with Distributed Cache, Application, Application with Search, we found one issue. All wsp solutions deployed to ALL the servers including WFE, search and app servers!

After looking at the server role in details, we found “Microsoft SharePoint Foundation Web Application” service enabled as default for “Application” role and “Application with Search” role. This will cause few major issues but not limited as listed below.

1. Third party license issues. Most of the third party solutions are licensed by WFEs that is defined that server is running “Microsoft SharePoint Foundation Web Application” service. You may run into license issues if all servers have the service running.

2. Deployment performance issue. The custom solution will take significant time since it will deploy to all servers. We had this issue for one small solution deployment.

3. Potential security issues. The application servers or the search servers can also accept the call event they may not intended to server the end users request. This may cause security concerns since most WFE are behind load balancer.

4. Maintainability issues. The application server and search server will have all files related to custom solution deployed. It’s difficult to manage the configurations.

We have seen people to create custom role to avoid this issue. 

It looks like a "disaster" to include the “Microsoft SharePoint Foundation Web Application” service in the “Application” MinRole.

We have discussed with Microsoft to move the following two services to WFE so we have two custom MinRoles for WFE and App servers. If you need to migrate the default MinRole to custom MinRole, you could refer following two articles.

a.      https://technet.microsoft.com/en-us/library/mt790700(v=office.16).aspx

b.      https://social.technet.microsoft.com/wiki/contents/articles/36737.sharepoint-2016-central-admin-system-settings-convert-server-role-in-this-farm.aspx

How to resolve "EPERM: operation not permitted" error when installing Yeoman SharePoint generator?

The SharePointFramework (SPFx) is a page and web part model that provides full support for client-side SharePoint development, easy integration with SharePoint data, and support for open source tooling. With the SharePoint Framework, you can use modern web technologies and tools in your preferred development environment to build productive experiences and apps that are responsive and mobile-ready from day one. The SharePoint Framework works for SharePoint Online and soon also for on-premises (SharePoint 2016 Feature Pack 2).

One step to Set up your SharePoint client-side web part development environment is to Install Yeoman SharePoint generator. We run into the issue the installation failed with the following error.

 131672 verbose stack Error: EPERM: operation not permitted, rename 'C:\Users\harryc\AppData\Roaming\npm\node_modules\@microsoft\generator-sharepoint' -> 'C:\Users\harryc\AppData\Roaming\npm\node_modules\@microsoft\.generator-sharepoint.DELETE'

Here are some steps to help you to resolve this or workaround this issue.

1. First, verify to run the script as administrator.

2. Second verify the npm and node version are in supported version.  You can use the following command to verify the versions. Install the support versions, clean up the npm cache, and try again.

npm -v

3.10.10

node -v

v6.12.0

 npm cache clean --force

3. Disable anti-virus. If you have anti-virus (Avast) software, disable it before installation as in other blog.

4. Stop Windows Defender. If you have Windows Defender running, you could as administrator to stop it during the installation.

5. Copy the Yeoman SharePoint generator files from another machine. If none of the above options are available for you, the workaround I used to work around this issue is to copy the Yeoman SharePoint generator files. Here is the details and tricks.

Install the Yeoman SharePoint generator on different machine (VM 2012 R2 for example) that has no issue. Copy all the folders and files under to the machine that failed to install.

C:\tools\node-v6.12.0-win-x64\node_modules\@microsoft\*.*

If you try to copy the everything in one copy, you might run into copy error. I would recommend to copy few folders and files under the ..\@microsoft\generator-sharepoint\node_modules folder at a time.

After you have all folders and files copied, you could use this machine to develop The SharePoint Framework (SPFx) now.

How to workaround "Sorry, we are having trouble connecting to the server" error from Chrome and Edge for SharePoint 2016

After configured SharePoint 2016 with FP2, we have seen  "Sorry, we are having trouble connecting to the server" error in many places using Chrome and Edge. This error does not happened when you are using Firefox or IE.  Here are the findings and workaround.

1. Here are some functions but not limited to you will receive this error. 

• Add users to any permission groups like administrator, the error displayed when you typing the user but could not resolve the name. (See picture #1)
• Unable to add any list item to the list (See picture #2)
• Unable to delete any list item from list view
• Unable to share documents with anyone
• Unable to add list template to list template gallery
• Unable to delete list template from list template gallery
• Constantly getting error "Sorry, we are having trouble connecting to the server".

2. Debugging error from fiddler. 

If you debug the issue through Fiddler, you will find the “403” error and the “Origin” under Security of the request Header is dropping the port number like this below.

“Origin: myprojectsite.mycompany.com”

3. Steps to reproduce the issues.

We did further debugging with Microsoft and identified this is new security “feature” implemented in SharePoint 2016 that is causing this issue. This is impacting any web applications with SSL that is not in default 443 port number. Here is the step to reproduce the issue.

In SharePoint 2016 create two web applications with root site collections and then enable for SSL

One web applications use default port number and another is something like 51000.

In central admin go to  alternate access mapping settings and add internal URL mapping to the second new web application.  Use the same name and append a port number.

Example map:

Internal URL	Zone	Public URL
https:\\myprojectsite.mycompany.com	Default	https:\\ myprojectsite.mycompany.com
https:\\myprojectsite.mycompany.com:51000	Default	https:\\ myprojectsite.mycompany.com

Go to IIS on the WFE and edit binding, change 443 to port 51000 and apply SSL cert to binding.

On load balance device configure for port redirection and SSL offload

Configure device to listen for https:\\myprojectsite.mycompany.com

Configure device to send traffic to WFE node as https:\\myprojectsite.mycompany.com:51000

Browse to the site as https:\\myprojectsite.mycompany.com

Site settings -> People and Groups ->New ->Add user, people picker should be present now. Type a user name and press to activate name resolution.

Error message "Sorry, we are having trouble connecting to the server" will be displayed

We have tied to add a Custom Rule in the fiddler like below and the issue can be resolved.

    static function OnBeforeRequest(oSession: Session) {

        if ( oSession.HostnameIs("myprojectsite.mycompany.com") && oSession.uriContains("/ProcessQuery")) {

            oSession["ui-bold"]="true";

            oSession.oRequest["Origin"]="https://myprojectsite.qualcomm.com:51000";

        }

       // …

 }

4. Multiple options to work around this issue.

Now we have few options to work around this issue. Here are the options confirmed with Microsoft.

• Option 1 - Create a rule in the Load balancer
• Option 2 - Use the same SSL certificate on all the web applications in the farm using a SAN configuration and configure all the web applications to use port 443 and a host header
• Option 3 - Configure all the VIPs in the LB to forward to the SharePoint servers on port 443 instead of the port the web applications is actually listening on
• Option 4 - Configure the SharePoint servers to have multiple IP addresses for each web applications so they all can use port 443.

We have implemented the option one by adding the following rule to the Load balancer.

IF the hostname = "myprojectsite.mycompany.com " && the URI contains "/ProcessQuery”

THEN redirect to https://myprojectsite.mycompany.com:51000

You might try other options that should also resolve the issue.