SharePoint 2013 issues on Internet Explorer 11

When I was doing labs during the SharePoint training, several SharePoint 2013 issues are identified accidentally against Internet Explorer 11. The most annoying one is that SharePoint pages are not in full edit mode when clicking edit page. One example is web part properties cannot be modified since the link will not displayed on the page as in the following screenshot.

 

Some other IE 11 comparability issues below also reported as this point.

• Calendar web part is extremely corrupted
• The calendar overlay button on the calendar view is disabled
• Edit Page doesn’t place the page in Edit mode (especially on custom page layouts)
• If you do happen to use a built-in page layout, any webparts added are unable to be customized
• Drag and drop files to document library seems to be disabled

There are at least two ways to resolve these issues as listed below.

1. Update IE 11 compatibility mode
2. Update master pages to IE10 Compatibility

The easy one would be the option #1 and here are the detailed steps.

• Place your Top Level Domain (ex. Contoso.com)  in Compatibility Mode  
• Place your Top Level Domain (ex. Contoso.com) in the Intranet Sites Security Zone

There might be some other issues we might need to find out.

Powershell script to report SharePoint user policies

In recent SharePoint case, we have a need to monitor SharePoint user policy changes. The first tasks is to report the current SharePoint user policies for all web applications. Here is the quick powershell to dump the information to a csv file.

# Load SharePoint.Powershell
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null) {
        Write-Host   $(Get-Date -format "dd_MM_yyyy_HH_mm_ss") '- Loading SharePoint Powershell Snapin'
        Write-Host
        Add-PSSnapin "Microsoft.SharePoint.Powershell"
}

# Output file in csv format in current folder
$reportFile = $myinvocation.mycommand.path.Replace($MyInvocation.MyCommand.name,"") + 'Policy_' + $(Get-Date -format "dd_MM_yyyy_HH_mm_ss") + '.csv';
# Add header to the output file
$line = "WebAppURL" + “,” + "DisplayName"  + “,” + "IsSystemUser" + “,” + "PolicyRoleBindings"  + “,” + "UserName"
Add-Content $reportFile $line

# Loop through all web applications and get policies
$webApps = Get-SPWebApplication
foreach($webApp in $webApps)
{

        # Get policy collection
        $policyCollection = $webApp.Policies

        # Read each policy and write to output file
        foreach ($pl in $policyCollection) {
       
            # PolicyRoleBinding is a collection and need to get all names and write to single column in format {role name, role name}
            $pr = $pl.PolicyRoleBindings
            $PolicyRoleBinding = "{"
            foreach ($p in $pr) {               
                $PolicyRoleBinding += $p.Name
                $PolicyRoleBinding += ","
            }
            #$PolicyRoleBinding = $PolicyRoleBinding.Substring(0,$PolicyRoleBinding.Length-1)
            #$PolicyRoleBinding = $PolicyRoleBinding.trimend(",")
            $PolicyRoleBinding = $PolicyRoleBinding -replace ".$"
            $PolicyRoleBinding += "}"

            # Write each role in to one line
            $line = $webApp.Url + “,” + '"' + $pl.DisplayName + '"'  + “,” + $pl.IsSystemUser + “,” + '"' + $PolicyRoleBinding + '"'  + “,” + $pl.UserName
            Add-Content $reportFile $line

        }

}

The output csv file looks like as the following screenshot. 

How to manage custom policy roles for SharePoint Web Application through Powershell?

We have identified an interesting configuration that might be done by previous SharePoint administrator. There are several custom policy roles created and assigned to many groups on MySites web application as in the screenshot.

Since this will grant permission for everyone who could view other people’s mysite, we have concern that we could need to manage the policy roles creation and policy roles assignment.  Here are some powershell scripts for you o help on the following use cases.

1. Add new custom policy roles
2. Add users/groups and bind to the custom policy roles
3. Display custom policy role details
4. Monitor any user/group blind to any custom policy role
5. Monitor any custom policy role created

#**************************************************************************************
# References and Snapins
#**************************************************************************************
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snap -eq $null) {
Add-PSSnapin Microsoft.SharePoint.Powershell
}
#**************************************************************************************

function AddPolicyRoleBuildUser ($rootsite, $PolicyRole, $user)
{
    # Add Policy roles and bind users
    #$webApp = Get-SPWebApplication -Identity "http://spsbx15:300/"
    $rootsite
    $PolicyRole
    $user
    $webApp = Get-SPWebApplication -Identity $rootsite
    $webApp

    # add the new policy role
    $policyRoles = $webApp.PolicyRoles
    $policyRoles
   
    $policyRole = $policyRoles.Add($PolicyRole, "Permissions required for user to create mysites")
    $policyRole.GrantRightsMask="Open, ViewPages, ManageSubwebs, BrowseUserInfo"

    # add the user
    $policyCollection = $webApp.Policies
    #$policyCollection
    #$policy = $policyCollection.Add("c:0(.s|true","Everyone")
    $policy = $policyCollection.Add("c:0(.s|true",$user)

    # bind the policyrole to the user
    $policy.PolicyRoleBindings.Add($policyRole);
    $webApp.Update()
}

function DeletePolicyRole([string]$rootsite, [string]$PolicyRole)
{
    # Delete role
    $webApp = Get-SPWebApplication -Identity $rootsite
    $policyRoles = $webApp.PolicyRoles
    $policyRoles.Delete($PolicyRole)
    $webApp.Update()
}

function DisplayPolicyRole([string]$rootsite, [string]$PolicyRole)
{
    #Verify the permission content
    $wapp = Get-SPWebApplication $rootsite
    $pr = $wapp.PolicyRoles | ? {$_.Name -eq $PolicyRole}
    $pr.Xml
}

# Main

# Add Policy Role and blind to user/group
AddPolicyRoleBuildUser "http://spsbx15:300/" "MySitePolicy2" "Everyone"

# Display Policy Role
DisplayPolicyRole "http://spsbx15:300/" "MySitePolicy2"

# Delete Policy Role
DeletePolicyRole "http://spsbx15:300/" "MySitePolicy2"

I have also provide the following script to monitor if any user/group blind to any custom policy role. You could modify to monitor whether there is any custom policy role.

# Load SharePoint.Powershell
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null) {
        Write-Host   $(Get-Date -format "dd_MM_yyyy_HH_mm_ss") '- Loading SharePoint Powershell Snapin'
        Write-Host
        Add-PSSnapin "Microsoft.SharePoint.Powershell"
}

# Get my site web application
$webApp  = Get-SPWebApplication -Identity "http://spsbx15:300/"

# Get policy roles
$policyRoles = $webApp.PolicyRoles

# $policyRoles.Count should be 4
If ($policyRoles.Count -gt 4){

    $message = "There might be custom policy roles. "
}

# OoB Policy Types are DenyAll, DenyWrite, FullRead, and FullControl, The "None" means "No role type assigned".
$pr = $webApp.PolicyRoles | ?{$_.Type -eq "None"}
If (!($pr –eq $null)){
    # This is monitor to report custom PolicyRoles - disabled now
    #$pr  
}

# Get policy collection
$policyCollection = $webApp.Policies

# Verify each policy and identify any policy is assigned with custom policy role
foreach ($pl in $policyCollection) {

    #$pl.PolicyRoleBindings
    $pl1 = $pl.PolicyRoleBindings | ?{$_.Type -eq "None"}

    If (!($pl1 –eq $null)){
        #$pl
        $name += "'"
        $name += $pl.DisplayName
        $name += "'; "

    #$pr
    }

}

# If any users/groups have custom policy role assigned, send notification
If (!($name –eq $null)){

    $message = $message + $name + "have custom policy role on "  + [System.DateTime]::Now.ToLocalTime()
    #$message
    $emailFrom = "PermissionMonitor@mycompany.com"
    $emailTo = "admin@mycompany.com"
    $subject="SharePoint permission monirotor "  + [System.DateTime]::Now.ToLocalTime()    
    $smtpserver="smtphost.qualcomm.com"
    $smtp=new-object Net.Mail.SmtpClient($smtpServer)
    $smtp.Send($emailFrom, $emailTo, $subject, $message)
   
}

NextLabs SharePoint policy automation architecture design

SharePoint is a widely adopted platform for internal and external collaboration. After SharePoint 2013 introduced social feature, cloud integration, and easy sharing capability, enterprises using SharePoint find that SharePoint sites have a tendency to grow at an uncontrolled pace, in part due to the ad-hoc collaboration and discretionary access control model native to SharePoint. This can catch data owners off-guard, especially when it comes to ensuring that sensitive information is protected. In our case, we company has major acquisitions and spin offs. As a result IT security team requested to block certain users to access some identified confidential SharePoint site collections regardless of the SharePoint native access control. In other words, we would need to block the certain users to access those identified SharePoint site collections even they have been granted the access.

NextLabs’ Entitlement Manager for SharePoint is a content aware Entitlement Management solution that provides the capability to authorize, classify, enforce and audit enterprise resources across Microsoft SharePoint. NextLabs Entitlement Manager for SharePoint is designed to enforce policies that control whether and how users can access, download, and use the data stored on a SharePoint server. Compliant Enterprise policy is composed of policy components like site URLs. Policy components are logical constructs that are created in the Policy Author and reused across policies. SharePoint policy can be defined with User (like block User Group), Action (like deny), and Portal components (like list of site URLs), along with conditions as illustrated in the following example for our company, highlighted respectively: 

Only block users that is in AD Group1 to Access highly restrictive list of site collections that any owner in certain departments during any hour.

Since site collection could be provisioning anytime and users could be transferred from one depart to a different one. It would be impossible to manually update the site collection list as policy components. The challenge is how can we automatically build the policy components to accomplish this “dynamic” policy? Let us review the NextLabs’ Entitlement Manager first to design the automation architect.

The Entitlement Manager for SharePoint has the following components.

• Policy Author (Java application): Defines, manages and deploys SharePoint policy.
• Control Center (J2EE server): Stores policy in a central repository and deploys policy sets to distributed Entitlement Managers for SharePoint across the enterprise.
• Administrator (Web application): Monitors system health and checks that policies are up-to-date for each Entitlement Manager.
• Entitlement Manager for SharePoint (Windows service): Detects user actions and enforces policy.
• Reporter (Web application) – Monitors real-time activities and queries the Entitlement Manager for SharePoint logs to analyze and audit trends and patterns.

The two primary components are the Adapter and the Policy Controller. The Adapter runs inside IIS and the Policy Controller as a Windows Service as indicated in the below graph.

   

Adapter

The Adapter functions as the Policy Enforcement Point (PEP) by detecting user actions on SharePoint, obtaining a policy decision from the Policy Controller, and enforcing policy. It is tightly integrated with ASP.NET and SharePoint with the following event monitoring and blocking interfaces:

• Event Receiver – SharePoint provides synchronized event receivers that expose a limited number of events that can be controlled through this high level interface.

• HTTP Module – ASP.NET provides a low level interface to pre-process HTTP requests. This interface provides added event controls that are not supported by the Event Receiver.

When a monitored event occurs, the Adapter sends a policy evaluation request to the Policy Controller through the .NET Adapter SDK. The Adapter uses the same public interfaces in the SDK that can be used to extend the Compliant Enterprise policy enforcement platform to any .NET application.

The Entitlement Manager for SharePoint not only enforces policies but also notifies end-users with customizable notifications to alert and educate users. The notification message can be customized for each policy using the Policy Author.

When the Policy Controller returns a denial decision, it includes a notification obligation for that policy. The Adapter blocks the action and triggers a SharePoint error to display the customized message.

Policy Controller

The Policy Controller is an independent run time that provides the following policy management and evaluation services:

• Police Engine – functions as the Policy Decision Point (PDP) for fast policy evaluation across multiple dimensions.

• IceNet Client – communicates with the Control Center to download policies, upload activity logs, and provide the Adapter health status.

• Obligation Manager – dispatches notification obligations to the Adapter, executes email notification and logging obligations internally, and launches any executable to perform custom obligations.

Now the key part for the automation is how we could automate to push the policy to Policy Controller. We would need to look at the policy components. SharePoint policy can be defined with the following three major components.

• User - AD group with specific attributes
• Action - deny, allow, or report
• Portal components - list of the site collection URLs as example

These three components is indicated in the following Policy Stdio. The three components are highlighted.

Since the user for the specific groups can be identified dynamically from claims SID, it will not require any change. The only  change required is the site collection list for the portal components as in the below screenshot.

At this point, it is cleat the the automation goal should update the policy site collection URLs automatically. Here is the architect design for the automation.

We have two scheduled jobs. 

One schedule job is on SharePoint server to run query against SharePoint using SharePoint server API and generate the site collection list. The site collection list will be written as portal component xml format on NextLabs Control Center (CC) server. 

The second schedule job is on NextLabs Control Center (CC) server. This job will pick up the portal component xml, import, submit, and deploy the policy. Then the deployed policy will be pushed to Policy Control on SharePoint side. As a result, the policy will be applied to SharePoint. The automation architect is described as the following picture.

Here is the detailed design for the automation process. We create the policy through Policy Studio and configure the following automation to update the site URLs in portal component.

1. SharePoint scheduled job - window console app to read SharePoint configuration as query criteria and policy template for xml format. 
2. SharePoint scheduled job - window console app to query SharePoint through server API and generate SharePoint site collection list as NextLabs portal component xml input file.
3. Import tool to read portal component xml and submit to Control Center.
4. Import tool to send portal component Control Center to approve.
5. Entity Deploy tool to deploy the portal component.
6. Control Center ICENET server to ready administration configuration like push setting.
7. Control Center ICENET server push policy to Policy Controller server on SharePoint server

At this point, SharePoint will have the updated new policy and the policy will be enforced. We will publish the detailed automation scripts in different blog.