Home Blog Page 6

SharePoint Useful Links


Useful Links for SharePoint folks

No hotfix for SharePoint 2010


After October 13th, 2015, There will be no hotfix for SharePoint 2010.

If you still have SharePoint farm running on SharePoint 2010, you may really read this info. SharePoint 2010 hotfix support will be ended on October 13th, 2015, more information at: https://support.microsoft.com/en-us/lifecycle?p1=14944

After October 13th 2015, Microsoft will only provides security fixes for SharePoint 2010. So it will be a big trouble if you are running into an issue after October 13th which is caused by a problem in SharePoint 2010 and which has not already been addressed before you will no longer be able to request a hotfix.
If you are using SharePoint 2010 as a business critical application, it is not the best situation.

There are still 3 months to leverage SharePoint 2013, SharePoint Online and consider to move on.

Below is some useful links:
Your SharePoint Path Forward: On Prem, Cloud, or Hybrid http://bit.ly/1or8ngE
Plan for SharePoint 2013 (TechNet): http://bit.ly/VTcuuY
Free Migration Planning Tool www.metalogix.com/products/Migration-Expert.aspx
Pre-migration Analysis & Preparation www.metalogix.com/products/ControlPoint.aspx

Clean up orphan items in SharePoint Farm


Clean up orphan items in SharePoint Farm

Here is the issue with orphan items in SharePoint site:

There are many ways to resolve this issue
Solution 1:

Solution 2: Upcoming…

Using SharePoint 2013 Folder


Using SharePoint 2013 Folder


    • Scale by partitioning a document library.
    • To apply permissions more effectively.
    • To use location based default metadata properties. You can set default metadata values for every folder. In ‘Library settings’, ‘Column Default Value settings’, you can set defaults on all of you subfolder starting from the root(inherits by default). Also check out the Location-Based Metadata defaults feature: http://msdn.microsoft.com/en-us/library/ee557925.aspx.
  • Folders are great for finding info when you know your way around the folder structure.
  • Folders improve the efficiency of data access because the creation of a folder leads to the creation of an internal index.
  • Folders work great in scenarios where file shares are used. In a file share, the only way of classifying files is through filename and folder structure. In SharePoint we have a choice, and you could consider using both folders and metadata together.
  • Folders work a lot better with Windows explorer views. In a flat structure you see everything and nothing in one view….
  • Document sets inherit from the folder content type. So, even if you resent the idea of using folders, you’re probably still a fan of using them without recognizing it (that is, unless you deny the usefulness of Document Sets).
  • You can use folders while still removing them from view. If you don’t want to use the folders all the time, create a view that does not display the folders. In ‘Library settings’ – ‘Create View’ – ‘standard view’ – under ‘Folders’ – you have a choice of ‘show all items without folders’. This will turn your folder based structure into a flat library.
  • Folders is a great way to introduce metadata to old school change-reluctant users, using default folder values will allow you to add metadata without the user noticing.
  • Folders save you time in migrations if you can copy an existing fileshare folder structure.


  • If you don’t know the folder structure, finding info is easier using metadata based navigation.
  • Folders increase URL length, which breaks when it pops above around 260 characters. See: http://www.loisandclark.eu/Pages/limitsurl.aspx
  • Folders don’t look great when you put a Library web part on a page (there’s no navigation back up to the parent folder).
  • Folders without metadata, can cause you to ‘lose’ documents.
  • It’s harder to change folder structures, while changing metadata is easy.
  • Additional comments about Security… You can have several document libraries in one site, that is also a way to separate security/permissions. There is a commercial third party tool available for SharePoint that allows you to set permissions by the use of metadata. So, if you’re interested in that, you can investigate further.

Folder vs Metadata

  • SPS 2013 search makes it easy to find worthwhile files and list items with or without any added metadata.
  • If you don’t use metadata, SharePoint automatically adds metadata anyway to your documents. The document name, document type, folder name, created by, modified by etc. SharePoint adds about 20 metadata to your documents automatically without you having to do a thing. So in fact you are always using metadata.
  • You can lose documents when placed in the wrong folder, but the same is true when you add the wrong metadata to a document. A good search engine alleviates those problems.
  • Of course it is best practice not to create too many folder levels, but metadata grouping can only give you 2 levels of “folder like” structure. Sometimes you just need 3 levels to make the document structure logic for everyone.
  • When you add a library web part view on a page, there is no way to tell in which folder you are at any given time, there is also no way to navigate to the parent folder. However, it’s possible to invest in custom work to give library web part views that do show a breadcrumb and that has taken away the biggest disadvantage of using folders for my end-users.

So finally, try and keep the folder hierarchy as flat and minimal as you can, but don’t limit yourself to metadata views exclusively. Mix the opportunities for the best results!  If you choose to depend on metadata only, you should separate sets of documents by putting them in its own websites and set the permissions on this level. If you need a more granular rights management, folders/libraries are the easier way to do it.

Sharepoint Default Groups and Permission Levels


Sharepoint Default Groups and Permission Levels

SharePoint Team Site Template Other SharePoint Site Template (i.e. publishing site template)
Available default groups
Visitors Restricted Readers
Members Style Resource Readers
Owners Designers
Viewers Approvers
Hierarchy Managers
Available default permission levels
View Only View Only
Limited Access Limited Access
Read Read
Edit Edit
Contribute Contribute
Design Design
Full Control Full Control
Manage Hierarchy
Restricted Read

Details description of default group:

Group name Default permission level Description
Visitors Read Use this group to grant people Read permissions to the SharePoint site.
Members Edit Use this group to grant people Edit permissions to the SharePoint site.
Owners Full Control Use this group to grant people Full Control permissions to the SharePoint site.
Viewers View Only Use this group to grant people View Only permissions to the SharePoint site.

Details descriptions of default permission levels:

Default permission level Description
View Only Includes permissions that enable users to view pages, list items, and documents.
Limited Access Includes permissions that enable users to view specific lists, document libraries, list items, folders, or documents, without giving access to all the elements of a site. You cannot edit this permission level directly.
Read Includes permissions that enable users to view items on the site pages.
Edit Includes permissions that enable users to add, edit and delete lists; can view, add, update and delete list items and documents.
Contribute Includes permissions that enable users to add or change items on the site pages or in lists and document libraries.
Design Includes permissions that enable users to view, add, update, delete, approve, and customize the layout of site pages by using the browser or SharePoint Designer 2013.
Full Control Includes all permissions.
Approve Includes permissions to edit and approve pages, list items, and documents.
Manage Hierarchy Includes permissions to sites and edit pages, list items, and documents.
Restricted Read Includes permissions to view pages and documents, but not historical versions or permissions information.

Azure Learning Path

A path to learning the essentials of Azure …
If you don’t know where is the start point for learning Azure. You come to the right place. Below is a path to learn the essentials of Azure …

SharePoint Online Limitations


SharePoint Online’s Limitations

Know your limits!

Migrations to SharePoint Online (SPO) have some significant limitations when compared to migrations from on-premises environments to on-prem, or to dedicated offerings such as Office 365-D (Microsoft’s dedicated service), Azure, AWS, Rackspace and other environments.

These limitations have a significant impact not only on what is possible with migrations of on-premises SharePoint and other content to SPO, but also on performance of migrations to SPO.
Microsoft continues to expand these APIs, and it is likely that many but not all of these limitations will be removed over time

Limitation and Impact

Limited APIs. Migrations to on-premises and private cloud (e.g. Azure/Amazon/O365-D) implementations of SharePoint support the use of the full SharePoint Server Object Model, the richest API available for SharePoint, or a thin web services layer that exposes the SharePoint Server Object Model (Metalogix Extensions Web Services/MEWS), for both reading, and writing SharePoint Content.
Due to the multi-tenant nature of SPO, Microsoft cannot expose the full SharePoint Object Model in SPO.
Limited automation and controls around migration and provisioning.
Microsoft currently expose three, relatively limited API’s that are useful for migrations:
The Client Side Object Model (CSOM)
The Native Web Services (NWS) API
The REST based interfaces to the CSOM
Inability to connect at the Farm/Tenant level (CSOM) – With the full SharePoint Object Model or MEWS, users can connect at the Web Application or Farm level. With the CSOM adapter users cannot connect at the closest equivalent, which is the Tenant level Users have to create Site Collections in the SPO admin page prior to connecting to them.
Using 3rd party migration tools, users may have to create a separate connection for each Site collection in SPO. Users are unable to browse/search for all root level Site Collections, and may require more steps to promote Sites to Site Collections.
Inability to preserve Item IDs in lists Lists with dependencies on other lists such as Lookup columns rely on Item IDs in the Lookup lists.
Because the CSOM does not support retaining the Item ID of list items, some 3rd party tools have created workarounds that may impact performance.
Copying MySites can only be done one MySite at a time, and does not include User Profile information. Unlike on-prem to on-prem migrations where MySites can be moved in a single operation, in SPO admins must first create each MySite.
Admins then need to connect to each MySite Site Collection separatey, and then copy the content from the source, pasting it into the target MySite.
Admins cannot copy MySite profile information.
Versioning limitations in the CSOM API. No support for migration of minor versions of documents
Authorship information for rejected versions in a document library with approval is lost.
Nintex workflows cannot yet be migrated to Office 365 due to these same CSOM limitations. Nintex workflows must be recreated using the Nintex SPO offering to the best extent as possible.
Most on premises 3rd party solutions are either not available in SPO, or their functionality is greatly reduced Work with vendor to understand product roadmap and capabilities. Other options are to build using out of the box capability.
Inability to troubleshoot issues Required to work through Microsoft support and SLAs. Retrieving a correlation ID for a error could take days/weeks


So let summary. Before you do the migration, make sure you understand the limits of the platform, and map these limitations against your SharePoint inventory. Also, prioritize the impacts to each site and team, and develop a mitigation plan for each.

Clean up IIS log in SharePoint Server

Sometimes you may experience an issue with Disk storage exceeding due to IIS log files on your servers. This is the good time to clear the log file of IIS. I have done a scheduled job for my all servers by using the Task Scheduler.
Follow the following steps to schedule a cleanup job for IIS log files.
Open notepad, copy and paste following command.
get-childitem -Path C:inetpublogsLogFiles -recurse | where-object {$_.lastwritetime -lt (get-date).addDays(-15)} | Foreach-Object { del $_.FullName }
Then save file with extension .ps1 (Ex: Remove-IISLogfiles.ps1) to your server so it can be referred to run later. In my case, I place it at C:inetpublogsScriptRemove-IISLogfiles.ps1
From the server, open Task Manager. And follow following pictures to complete the task.

From Edit Action, use following command and argument
Program/script: %SystemRoot%system32WindowsPowerShellv1.0powershell.exe
And arguments (optional): C:inetpublogsScriptRemove-IISLogfiles.ps1 -noprofile – Noninteractive
Note: you can force run above command without stuck in console windows (sometime it happen when power-shell command travels to child folders) by using the following argument in  And arguments (optional) text-box: powershell.exe -executionpolicy unrestricted C:inetpublogsScriptRemove-IISLogfiles.ps1 -noprofile – Noninteractive

You are done!