Fleanser – improves our productivity in migrating file shares to SharePoint Online

HuonIT excels in File Share migration projects with the introduction of custom developed cleansing and mirroring tool. Internally named Fleanser v1.0.

Our tool replaces part of the functionality provided by ShareGate solutions in migrating file share to SharePoint online environment.

Fleanser runs, various analytic operations in file paths to cleanse and shorten them intelligently when required. It also generates various analytic reports during cleanse process to back track on action applied against each file/folder members.

We tested our first version of this tool (functional edition) today for a client and we immediately saw the value we could add to our customers.

Proud to be a creator of this tool. We have already planned to add more functionalities to this tool in the subsequent releases.

Untitled-3

Simple way to set "Replicate Directory Changes" permission (via PowerShell)

$Identity = "domain\account" $RootDSE = [ADSI]"LDAP://RootDSE" $DefaultNamingContext = $RootDse.defaultNamingContext $ConfigurationNamingContext = $RootDse.configurationNamingContext $UserPrincipal = New-Object Security.Principal.NTAccount("$Identity") DSACLS "$DefaultNamingContext" /G "$($UserPrincipal):CA;Replicating Directory Changes" DSACLS "$ConfigurationNamingContext" /G "$($UserPrincipal):CA;Replicating Directory Changes"

Checking/Ensure Replication Directory Changes for account by PowerShell

 

Following script is not mine and it was copied from – http://blog.bugrapostaci.com/2011/04/27/checking-replication-directory-changes-for-account-by-powershell/

This script was really so useful to check whether a user profile synchronization account is correctly configured.

This was tested at Structural Projects Group after DirSync their on prem AD accounts with Office 365 hosted AD.

Note:  A trust need to be created between two ADs as Bi-Directional.

#Save to script a file named CheckRDC.ps1
usage syntax:
open Sharepoint PowerShell Console
PS> .\CheckRDC.ps1 “DOMAIN\username”

image

The above ensures that SP_UPS has replication permission enabled on both side of the AD. Smile

param( [string] $userName="") function Check-ADUserPermission( [System.DirectoryServices.DirectoryEntry]$entry, [string]$user, [string]$permission) { $dse = [ADSI]"LDAP://Rootdse" $ext = [ADSI]("LDAP://CN=Extended-Rights," + $dse.ConfigurationNamingContext) $right = $ext.psbase.Children | ? { $_.DisplayName -eq $permission } if($right -ne $null) { $perms = $entry.psbase.ObjectSecurity.Access | ? { $_.IdentityReference -eq $user } | ? { $_.ObjectType -eq [GUID]$right.RightsGuid.Value } return ($perms -ne $null) } else { Write-Warning "Permission '$permission' not found." return $false } } # Globals $replicationPermissionName = "Replicating Directory Changes" # Main() $dse = [ADSI]"LDAP://Rootdse" $entries = @( [ADSI]("LDAP://" + $dse.defaultNamingContext), [ADSI]("LDAP://" + $dse.configurationNamingContext)); Write-Host "User '$userName': " foreach($entry in $entries) { $result = Check-ADUserPermission $entry $userName $replicationPermissionName if($result) { Write-Host "`thas a '$replicationPermissionName' permission on '$($entry.distinguishedName)'" ` -ForegroundColor Green } else { Write-Host "`thas no a '$replicationPermissionName' permission on '$($entry.distinguishedName)'" ` -ForegroundColor Red } }

 

for more on Deploy Office 365 Directory Synchronization (DirSync) in Microsoft Azure – http://technet.microsoft.com/en-us/library/dn635310%28v=office.15%29.aspx

Manage permission policies for a Web application

image

With the above, site hierarchy (250 site collections) in place one of my colleague had a requirement of assigning all Navantis employees a read access to all the sites within a web application. since creating specific groups at each site level became a daunting task, I proposed a solution to manage the permission at Web application level.

Now lets see some theories…. 

A Web application is composed of an Internet Information Services (IIS) Web site that acts as a logical container for the site collections that you create. Before you can create a site collection, you must create a Web application.

A Web application can contain as many as 250,000 site collections. Managing permissions for so many site collections can be complicated and error-prone, especially if some users or groups need permissions other than those that apply for the entire Web application.

Permission policies provide a centralized way to configure and manage a set of permissions that applies to only a subset of users or groups in a Web application.

The differences between specifying user permissions for a Web application and creating a permission policy for a Web application are the users and groups to which the permissions apply and the scope at which the permissions apply. There is also a difference in the permissions lists where individual permissions are selected.

Manage user permission policy

You can add users to a permission policy, edit the policy settings, and delete users from a permission policy. The following settings can be specified or changed:

  • Zone: If a Web site has multiple zones, you can choose the zone that you want the permission policy to apply to. The default is all zones, which can be specified for Windows users only.
  • Permissions: You can specify Full Control, Full Read, Deny Write, and Deny All permissions, or you can specify a custom permission level.
  • System: This setting enables SharePoint to display SHAREPOINT\System for system-related activity regardless of the Windows user accounts that have been configured for the hosting application pool and the SharePoint farm service account. You might want to specify this setting to prevent unnecessary information disclosure to end users and potential hackers who would be interested in knowing more about the SharePoint deployment in the enterprise.
Add users to a permission policy

You might want to add users to a permission policy to ensure that all users are accessing content with the same set of permissions.

To add users to a permission policy
  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.
  2. On the Central Administration Web site, in the Application Management section, click Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to manage.

  4. In the Policy group of the ribbon, click User Policy.

  5. In the Policy for Web Application dialog box, select the check box next to the user or group that you want to manage, and then click Add Users.

  6. In the Add Users dialog box, in the Zone list, click the zone to which you want the permission policy to apply.

  7. In the Choose Users section, type the user names, group names, or e-mail addresses that you want to add to the permission policy. You can also click the applicable icon to check a name or browse for names.

  8. In the Choose Permissions section, select the permissions that you want the users to have.

  9. In the Choose System Settings section, check Account operates as System if you want to specify whether a user account should be displayed as SHAREPOINT\System instead of the actual accounts that perform specific tasks within the SharePoint environment.

  10. Click Finish.

Manage permission policy for anonymous users

You can enable or disable anonymous access for a Web application. If you enable anonymous access for a Web application, site administrators can then grant or deny anonymous access at the site collection, site, or item level. If anonymous access is disabled for a Web application, no sites within that Web application can be accessed by anonymous users.

The following permission policies can be specified for anonymous users:

  1. None: No policy is specified. This setting gives anonymous users the same default permissions available to NT AUTHORITY\Authenticated Users and All Authenticated Users.
  2. Deny Write: This setting permits anonymous users to read all content within the site collections in a Web application. You can then restrict the Read access by site collection, site, or item.
  3. Deny All: Anonymous users have no access to any part of the Web application.
To manage permission policy for anonymous users
  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.
  2. On the Central Administration Web site, in the Application Management section, click Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to manage.

  4. In the Policy group of the ribbon, click Anonymous Policy.

  5. In the Anonymous Access Restrictions dialog box, in the Zone list, click the zone for which you want the policy to apply.

  6. In the Permissions section, select the permission policy that you want anonymous users to have, and then click Save.

  7. Manage permission policy levels

    Permission policy levels contain permissions that apply to specific users or groups. You can specify a combination of List, Site, or Personal permissions. You can also specify one of the following levels of site collection permissions:

    • Site Collection Administrator: Has Full Control permission on the entire site collection and can perform any action on any object.
    • Site Collection Auditor: Has Full Read permission on the entire site collection and associated data, such as permissions and configuration information.

    If you specify either or both of these permission levels, you cannot specify individual permissions.

    Add a permission policy level

    You can create a permission policy level to customize a set of permissions for a specific group or organization.

    To add a permission policy level
    1. Verify that you have the following administrative credentials:

      • You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.
    2. On the Central Administration Web site, in the Application Management section, click Manage web applications.

    3. Click to highlight the line for the Web application whose permission policy you want to manage.

    4. In the Policy group of the ribbon, click Permission Policy.

    5. In the Manage Permission Policy Levels dialog box, click Add Permission Policy Level.

    6. In the Add Permission Policy Level dialog box, in the Name and Description section, type the name and description for the policy that you want to create.

    7. In the Site Collection Permissions section, select the site collection permissions for this policy.

    8. In the Permissions section, select the permissions to grant or deny for this permission level.

      • Select the Grant All check box to include all available permissions in this policy.
      • Select the Deny All check box to deny all available permissions in this policy.
      • Select either the Grant or Deny check boxes to include or exclude individual List, Site, and Personal permissions from this policy.
        Do not click either Grant or Deny if you want to allow site collection or site owners to configure this permission.
    9. Click Save.

      Example:
      Step-1
      image

    Step-2

image

Step-3

image

Step-4

image

 

Step-5

image

 

Example – To add a permission policy level

Step-1

image

 

Step-2

image

 

END.

Creating a Feature for the Site Actions Menu in SharePoint 2010

Overview

You can add a custom menu item to the default Site Actions menu in Microsoft Windows SharePoint Services by creating a Feature with a CustomAction element. In this way, you can add custom commands to the default SharePoint user interface. These commands are available to users as they move between pages on a SharePoint site. When you create a Site Actions menu item, you can configure it to redirect the user to any URL. For example, you can redirect the user to another Web site. You can also redirect users to a custom application page that allows them either to see a custom display of data, or to perform custom operations on the content within the current site.

Code It

  1. Create a new Project in VS 2010 and under SharePoint (left) select Empty Project.
  2. Now enter the url of your SharePoint site for debugging and select deploy as a farm solution.
  3. Now, once you have the project open, right click on the Feature folder and Add a new feature.
  4. SharePoint automatically adds a feature and names it as Feature1. You can however change the feature name to something like CustomActionFetaure.
  5. With this you will have a feature designer opened in front of you set the Title description and scope of the feature.
  6. Now right click on the Project and add a new Item. In the Add New Item dialog, select Empty Element to create a blank element file.
  7. Add the below Code to the element.xml file.

    <?xml version="1.0" encoding="utf-8"?>
    <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <CustomAction
    Id="viewSiteManager"
    GroupId="SiteActions"
    Location="Microsoft.SharePoint.StandardMenu"
    Sequence="1000"
    Rights="ViewListItems,ManageAlerts" Title="Manage Content and Structure" Description="Reorganize content and structure in this site collection.">
    <UrlAction Url="~site/_layouts/sitemanager.aspx"/>
    </CustomAction>
    </Elements>

  8. Build the Project. Open the feature.xml file and verify that if contains the reference to the element.xml file.
  9. Now Deploy the wsp and activate the feature in your site.

Read It

When you create a CustomAction element, you must add an inner UrlAction element that contains a Url attribute. When you redirect the user to an application page, such as SiteManager.aspx, you must consider whether you want the application page to run inside the context of the current site or the current site collection. In the following example, the dynamic token ~site is added to the beginning of the URL. When Windows SharePoint Services parses this CustomAction element and creates the menu item, it replaces ~site with the actual URL of the current site.

"~site/_layouts/sitemanager.aspx"

The key to security trimming your custom action is the Rights attribute. This attribute allows you to specify SharePoint permissions that the user must have for the action to be visible. This can be a comma delimited list. For example:

Rights="ViewListItems,ManageAlerts"

When more than one value is specified, the set of rights are treated with an AND. This means the user must have all of the specified rights for it to be visible. Here is a list of the valid Microsoft.SharePoint.SPBasePermissions you could use:

http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.spbasepermissions

Also, When you create the element for a custom menu item in the Site Actions menu, you have the option to configure it so that it is shown only to users who have administrative permissions. Note in the following example the addition of a new attribute named RequireSiteAdministrator.

RequireSiteAdministrator="TRUE"

When you add the RequireSiteAdministrator attribute, Windows SharePoint Services does not show the menu item to users who do not have administrative permissions. For a CustomAction element in a Feature that is scoped at the site-collection level, the menu item appears only for the site collection owner or administrator. For a CustomAction element in a Feature that is scoped at the site level, the menu item appears only to those who have administrative permissions within the current site.

Finally

siteaction

Related Link: http://blogs.msdn.com/b/edhild/archive/2008/01/16/how-to-add-security-trimming-info-to-custom-actions-in-sharepoint.aspx