Microsoft Collaboration, CTO viewpoint, and New York

The blog for Office 365, Power Apps, Flow, SharePoint, cloud, ….. plus a little NYC

You are currently browsing the Sharepoint category.

Sharepoint Saturday NYC coming up

Ever had a problem of Office document not opening in the client app..

Ic: Word, Excel

This is the fix.

Here are the revised steps.


  1. Open the Run Window, this can be done by pressing the “Windows” and “R” Keys simultaneously on your keyboard.

  2. Type regedit in the window and click OK. This would open the Registry Editor.
  3. On the Registry Editor, expand HKEY_CURRENT_USER.

  4. Then scroll down and expand Software.

  1. Then similarly expand Microsoft->Office->16.0->Common->Identity
  2. Right Click on Identity and select New-> DWORD (32-bit) Value.



  1. Name the value as EnableADAL. Make sure you type this exactly as how it is listed, it is case sensitive.

  2. Restart your computer.

Should all work

So you want to learn Sharepoint?

I often get have conversations with people, who are looking for a collaborative technical solution to a problem, don’t know SharePoint and think SharePoint should be a good fit.

The first question they often ask is “Can you show me what SharePoint is?”

This is a problem, as it’s a large product.

But these videos help.

SharePoint in Plain English

What is SharePoint and Why We Use It

What is SharePoint |


SharePoint Professionals Must Embrace Modern APIs

An extract from an article I wrote for Redmond Magazine.

For the straight hardcore SharePoint developer who only knows SQL, ASP.NET and MVC, the rapid shift by enterprises to SaaS-based Office 365 SharePoint Online is sure to reduce your work hours at the very least and quite possibly eliminate the need for your job at some point. This transition has been going on for some time as GitHub libraries for JavaScript, HTML5, and CSS are now in the mix when it comes to building SharePoint apps.

Click here to read full article

Sharepoint branding.. No quick fix

I’ve looking at the product bindtuning for a straight forward approach to SharePoint branding.

One of the biggest complaints with customers on branding is that it’s always a science project to get anything done that makes the site pop out.  The Bindtuning approach gives the user a WordPress feel of point, click and color, ‘Without the let me get back to you in 2 days’ SharePoint consultant’s response.

Solutions like this do heavy customization and uses master to customize the look and feel of the site…. All good….  Well not quite.

The guidelines of SharePoint online branding suggested in below reference links recommends you should not customize the master page otherwise it would require more maintenance to apply upgrades

Use the SharePoint page model and composed looks, the SharePoint 2013 theming engine, and CSS to brand your SharePoint site and pages.

So it’s back to the manual approach.

  1. Use SharePoint Themes to change color throughout the sites
  2. Use JavaScript to inject UI components
  3. Use alternate CSS file to give responsive look and feel to the site

In the end there is no substitute for UI design capabilities on a team, the only question is how do you attract, and retain the talent.

One observation of Bindtuning, is that they aren’t exclusively SharePoint, which is unusual as a SharePoint vendor, so this would suggest they that SharePoint can only provide them breakfast, rather than lunch and dinner.

How to rearrange web parts around a page

“Why cannot I Drag and Drop WebParts on Home Page in SharePoint 2013, while this functionality worked in SharePoint 2007’s environment?”

The simple answer to this is – you can’t re-order or drag & drop webparts on the default Home Page of your SharePoint 2013 Team Site.

By default, in SharePoint 2013, the Home Page of a Team Site is created using a Wiki Page Layout, rather than refined web parts zones.

In 2007, the web zones looked like this:


In 2013



The only difference here is, there are no WebParts Zones on the Page, which essentially means no drag and drop on the page and no selection of Zones from any WebPart’s Properties.

One way to arrange the WebParts on the Page is by using moving HTML tags in the Edit Source of the Page.

This can be done in the following steps:


  1. Put the page in Edit mode- Top left hand corner on the ribbon:


  1. Select the content that you want to move.

In the figure above the Known Service Issues web part has been selected.

  1. Select Edit Source on the Ribbon

You will now be displayed the HTML of this web part.

This may look daunting, but it is not

  1. Press Control – x to cut the highlighted text.

This will remove the content from this web part

  1. Press Ok


  1. Move you mouse over the target web part and click it so it changes color.


  2. Click the Edit Source button again. Same as Step 3.


    An HTML dialog page will display.


  3. Press Control –V to paste the text.


  4. Press Ok


The web part has moved.



Copying files to another library in another site or site collection

One limitation of SharePoint designer, is that it can only copy files from a library to another library in the same site. This does have a purpose, but this is isn’t really an archiving solution.

The following code copying files (and metadata) from view in a library to another library in another site or site collection.

$web = Get-SPWeb “http://sp10/





$ver = $host | select version

if ($ver.Version.Major -gt 1) {$host.Runspace.ThreadOptions = “ReuseThread”}


if ((Get-PSSnapin “Microsoft.SharePoint.PowerShell” -ErrorAction SilentlyContinue) -eq $null)


Add-PSSnapin “Microsoft.SharePoint.PowerShell”



$web = Get-SPWeb “http://sp10/”




$list = $web.Lists[$listnamefrom]

$view = $list.Views[$viewName]

$columns=New-Object System.Collections.ArrayList

$dlist = $web.Lists[$listnameTo]

foreach ($col in $view.ViewFields)


if($col -ne “DocIcon” -and $col -ne “LinkFilename” -and $col -ne “Modified” -and

$col -ne “Editor”)






$items = $list.GetItems($view)

#$AllFolders = $sList.Folders

$RootFolder = $list.RootFolder

$RootItems = $RootFolder.files

foreach($RootItem in $RootItems)


write-host $RootItem.Name

$sBytes = $RootItem.OpenBinary()

$dFile = $dList.RootFolder.Files.Add($RootItem.Name, $sBytes, $true)

#$AllFields = $RootItem.Item.Fields | ? {!($_.sealed)}


foreach($Field in $columns)


$dFile.AddProperty($Field, $RootItem.Properties[$Field])



write-host “Updated”



write-host “Done”




Often forgotten SharePoint functionality


You don’t read about this functionally much, but the sitemanager in SharePoint is a little germ if you want to do the following:

-Copy files to a different site, by view or library, something that the explorer view can’t do.

-Move files, by view or library, something that the explorer view can’t do.

-Mark favorites

-Quickly navigate around not just a site but an entire site collection



1.    Go to http://your site path/_layouts/sitemanager.aspx

2. Click on the library from which you would like to move the documents and this should provide you the list of the all documents

3. Select all/documents you would like to move

4. From the menu, under “Actions” there is option to Move/Copy.

5. Select the destination document Lib

This feature has been in SP since 2003, is never discussed.  The really cool part is the Content and Structure reports.  They’re a little contrived but you can do a fair amount of datamining.






SharePoint 2013 Disaster Recovery- Creating, Testing and Maintaining the DR Plan- Part 4

This article is the fourth and final article that cover creating, testing and maintaining a SharePoint DR plan. These articles are from a chapter extract from the book: Microsoft SharePoint 2013 Disaster Recovery Guide.

Testing your Disaster Recovery Plan

After taking the time to create a SharePoint DR plan, the last thing you want to do is file it away (outside of your SharePoint environment) and hope you never have to use it. You need to establish the plan works as expected so if or when the time comes that you need to activate the plan you and the stakeholders have confidence that the plan, if executed properly, will deliver the expected results.

As a best practice you should test your DR plan on an on-going basis. It is recommended that larger organizations test their DR plan at least twice a year. Smaller organizations should test their DR plan annually.

Planning your Test

Testing your SharePoint DR plan will help identify any missing steps, potential problems with existing steps, missing dependencies, and potential bottlenecks. Testing will also help you determine the timings associated with each step of the recovery plan so you know whether the plan will meet your RTO and RPO goals.

It is important to determine when and where your tests will be conducted. You should try to conduct your tests in an environment that resembles your normal production environment so you can get a realistic feel for the plan and how it will work if your production environment went down.

Determine your Test Scopes

In order to test your SharePoint DR plan you need to define the scope of the tests you will be conducting. Begin by identifying the types of outages your SharePoint environment may experience. Some examples of common types of outages include:

  • Configuration Database Corruption
  • Content Database Corruption
  • Server Failure
    • Application Server
    • Database Server
    • Web Front End
  • Virtual Host Failure
  • Datacenter Failure

For each test, the appropriate resources will be needed to help conduct the test and determine if the test was a success. For example if testing the scenario of a failed application server your plan calls for the relevant services that were running on the failed server to be moved to a server that is still up and running in the farm. Once the services have been moved and configured the appropriate resources would validate the services are up and running and the SharePoint farm is behaving as expected.

Performing the Test

Once you have finished planning your test and your test scopes have been defined, you need to perform a full test of your SharePoint DR plan.

Your tests should be conducted in the context of the overall BCP so you get a feel for how the plan fits in and works with your company’s BCP. Involve your key stakeholders from both IT and the business and be sure to include the communications plan.

All tests should be thoroughly documented by creating a checklist to record the following information for each test and each step within a test:

  • Test ID (sequentially numbered, e.g. 001, 002, 003, etc.)
  • Test Name
  • Test Description
  • DR Plan Reference
    • Step ID
    • Step Description
    • Expected Results
    • Actual Results
    • Expected Duration
    • Actual Duration
    • Pass/Fail
    • Comments

Analyzing the results

Once you have completed all of the tests in your test scope, it is time to go back and analyse the test results. In all cases, you will be measuring the results of the test against the defined success criteria including the RTO and RPO goals.

Regardless of whether the test passed or failed, all test results should be well documented and shared with the key stakeholders so everyone has an understanding of what worked and what did not.

Maintaining your Disaster Recovery Plan

Your SharePoint DR plan should be considered a living document, meaning it will continue to evolve over time as your farm continues to grow and new technologies are introduced into the environment.

Over time you may find that budget constraints that at one point limited your RTO and RPO goals may no longer be a concern and your RTO and RPO goals can be adjusted according as new funding is made available for things such as a standby datacenter.

You should schedule periodic reviews of the plan and adjust the plan as necessary. It is important to continue to test your SharePoint DR plan as it continues to evolve over time.

For example, you should plan to review your SharePoint DR plan at least once a quarter. You should review all aspects of the SharePoint DR plan including your recovery targets, RTO, and RPO.

You should plan on performing a full test of your SharePoint DR plan at least once or twice a year depending upon the size of your organization, number of systems to be tested, amount of data to be recovered and the complexity of your SharePoint DR plan.

After each test, you will need to update your SharePoint DR plan according to the results of your test. This will assure your SharePoint DR plan is properly maintained and will be ready in the event of a disaster.


This article and the previous related ones has defined what it takes to create, test, and maintain a SharePoint DR plan. As the reader can see, it is not a 30-minute exercise where one person creates, test and maintains the DR plan alone, but an on-going activity that has a number of stakeholders and key individuals that will responsible for ensuring your organization is continually working to have the best plan in place in case of a SharePoint disaster.

SharePoint 2013 Disaster Recovery- Creating, Testing and Maintaining the DR Plan- Part 3


This article is 3 of 4 articles that cover creating, testing and maintaining a SharePoint DR plan. These articles are from a chapter extract from the book: Microsoft SharePoint 2013 Disaster Recovery Guide.

Creating an Effective Disaster Recovery Plan

Now that you have an inventory of each of the components of your SharePoint environment identified threats to the key components of your environment, the next step is to develop your SharePoint DR plan.

One thing you should never do is create your SharePoint DR plan in a vacuum. This means you should not develop your SharePoint DR plan without input and feedback from other key stakeholders whether they are IT stakeholders or business stakeholders.

Your SharePoint DR plan should be part of a larger business continuity plan (BCP) which is typically driven by business stakeholders. The BCP will identify what sites and components within the SharePoint environment are most critical and what the acceptable levels of downtime are for these items. The BCP should also contain the plan for communicating any downtime to the end users.

Identifying Key Stakeholders

The first step in creating an effective SharePoint DR plan is to define the overall scope of the plan and to define the key components that must be restored in the event of a disaster. Having a well-defined scope and knowing the key components will allow for a more productive process of developing your SharePoint DR plan. You begin by working with the key stakeholders within your organization that would be affected if your SharePoint environment were to become unavailable as a result of a disaster. In addition to the individuals responsible for administering and maintaining SharePoint itself, other key stakeholders will play a key role in developing the SharePoint DR plan.


From an IT perspective the key stakeholders are typically represented by individuals from the three key components of the physical architecture described earlier; Servers, Database and Network. In addition, there may be stakeholders from Messaging and Development depending upon the configuration of your SharePoint environment and if there is any custom developed code running in your SharePoint environment.


The server support team will typically consist of individuals that are responsible for installing and maintaining the servers in your SharePoint environment from an operating system and hardware perspective. This holds true for both physical and virtual servers however there may be other individuals responsible for installing and maintaining the virtual hosts if you have virtual servers in your SharePoint environment.


The database support team will typically consist of DBAs who are responsible for installing, configuring, and maintaining the SQL Server databases in your SharePoint environment. The DBAs are often responsible for monitoring the health of the SQL Servers as well as creating and maintaining database level backup schedules.


The network support team consists of individuals responsible for the connectivity between the systems and services that make up your SharePoint environment. Included in this group are the individuals responsible for configuring and maintaining DNS, hardware load balancers and associated virtual IP (VIP) addresses.


SharePoint supports both incoming and outgoing e-mails therefore if your SharePoint environment is using either or both then there should be a stakeholder from the messaging support team to make sure all matters regarding SharePoint and messaging are covered.


The features and functionality of SharePoint can be enhanced and extended through custom developed features, solutions and apps. If your SharePoint environment makes use of custom developed code then your stakeholders should include representation from the development support team.


From a business perspective, the number of key stakeholders can range from just one or two individuals in a small company to a significant number of individuals in a very large company. Regardless of the number of key business stakeholders, they will play the biggest role in defining the scope of your SharePoint DR plan. The key business stakeholders will identify the individual SharePoint sites and services that will need to be available and how soon they will need to be available in the event of a disaster. The results of this Business Impact Analysis (BIA) will be the foundation upon which your SharePoint DR plan will be developed.

The above examples of key stakeholders are typical of very large and large organizations. If you are a small or medium size organization these key stakeholders will most often be roles filled by the same person or may not even be filled by anyone. For example in a small organization there may not be a DBA. SQL Servers may have been set up by an outside consulting organization that is no longer engaged with your organization.

Regardless of whether your organization has these key stakeholders or not this section provides an example of the types of individuals and roles that will play a part in developing your SharePoint DR plan.

Developing the Plan

The BIA will have a direct impact on the RTO and RPO goals of your SharePoint DR plan as it will define the recovery targets of the individual components of your SharePoint environment.

Defining Recovery Targets

Recovery targets are defined as the key pieces of functionality and data identified in the Business Impact Analysis (BIA) that need to be restored in the event of a disaster in relation to the components of your SharePoint environment identified earlier in this article. You will need to work with the key stakeholders to establish the recovery targets for each component of your SharePoint environment in order to build your SharePoint DR plan.

In some cases, such as when you have a large SharePoint farm, your recovery targets may only represent a subset of the total functionality of your SharePoint farm. This will certainly be the case if the RTO is very aggressive and a full recovery will take more time that what the RTO will allow.

Understanding Costs

It is important to remember that each decision made during the development of your SharePoint DR plan will have an associated cost. One must understand the cost of downtime in order to understand the cost impact of how you handle a SharePoint disaster. If your SharePoint farm contains mission or business critical data or applications then the cost of downtime should be considered high. This means that the investment in developing a SharePoint DR plan that includes investments in additional hardware can be offset by the impact of downtime.

If you have a high RPO then you might need additional space for more frequent backups. This might mean an additional investment is storage space, third party backup/restore software or a SQL Server with failover clustering, database mirroring or AlwaysOn Availability Groups.

AlwaysOn Availability Groups is a feature of SQL Server 2012. It is a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring that maximizes the availability of a set of user databases for an enterprise.

The following diagram shows a SharePoint farm configured for high availability. The diagram shows how complex a SharePoint farm can get if you are building for high availability. Looking at the number of servers and components involved in a high availability farm shows just how costly this kind of solution could be.:

Insert 5108EN_02_02.png


Planning for high availability (HA) requires redundancy in your physical architecture such as failover SQL clusters and redundant application servers. It is important to know that HA could have some significant costs associated with it depending upon which components of your physical architecture you will build for HA.

The following diagram shows a SharePoint farm with a redundant farm in a secondary datacenter. The diagram shows the redundant farm and how it is physically and potentially geographically separated from your primary farm. The advantage if this kind of redundancy comes in to play in the event of a disaster in which you lose your primary datacenter. An example of this would be in the event of a natural disaster such as a hurricane or flood where you could lose your primary datacenter and your physically and geographically separated datacenter is unaffected so it would then become your primary datacenter until your primary datacenter is back up and running.

Insert 5108EN_02_03.png


Virtualization provides a workable cost effective option for a recovery solution. You can use virtualization technology such as Hyper-V or VMware as an on-premise solution or tools such as Windows Azure or Amazon Web Services (AWS) as a hosted solution to provide necessary infrastructure for recovery.

You can create virtual images of the production servers and ship these images to a secondary datacenter. By using the virtual standby solution, you have to make sure that the virtual images are created often enough to provide the level of farm configuration and content freshness that you must have for recovering the farm in order to meet your recovery targets and RTO and RPO goals.

A Virtual Standby Solution maintains up-to-date standby virtual machines for fast push button disaster recovery. The bootable virtual machine is an exact clone of the production server as of the last snapshot or backup.

Service Level Agreements

A Service Level Agreement (SLA) is a written agreement that specifies the requirements for server or application uptime and the penalties for not meeting those requirements. Two of the most specific and important components within an SLA are RPO and RTO. Both components are extremely important in developing your SharePoint DR plan

The RPO is retroactive from the moment of actual failure. It can be set in seconds, minutes, hours, or days but must correspond to the amount of tolerable lost data.

The RTO is typically based on lost revenue or productivity measured in seconds, minutes, hours, or days and corresponds to the measurable uptime (99.99%, 99.999% etc.) within an SLA.

The following table shows a very basic sample SharePoint SLA.

Availability 99.9%
Recovery Time Objective (RTO) < 5 Hours
Recovery Point Objective (RPO) 30 Minute Data Loss Window

Although a SharePoint SLA contains many more service items, the above sample shows the availability components only.

Planning for Recovery

Now that you have set the RPO and RTO for your SharePoint environment, established the recovery targets and understand the costs associated with these recovery targets it’s time to begin planning for recovery. Recovery is defined as the steps that must be taken in order to get the SharePoint environment back to an acceptable level of functionality as defined in the BIA.

Be sure your plan for recovery includes a communications plan. It will be important to keep the key stakeholders as well as end users up to date on the recovery process especially if there are mission critical applications that have been affected by the disaster.

Recovery Resources

In order to begin planning for recovery you must begin by identifying the resources, such as people, hardware and software, that will be needed to start the recovery process.


Your SharePoint DR plan should include a list of key individuals and stakeholders that will be part of the recovery process. This list should include the following:

  • Name
  • Department
  • Role
  • Primary Phone Number
  • Backup Phone Number
  • E-Mail Address
  • Recovery Responsibilities


Once you have established what additional hardware will be needed for recovery you should begin the process of acquiring the hardware so it is on hand as soon as possible. Whether the hardware is dedicated hardware or shared hardware make sure it is clearly identified as hardware associated with the SharePoint recover process.


If any additional software is required for a secondary datacenter or failover farm then you must acquire and maintain a sufficient amount of licenses to support the secondary datacenter or failover farm in accordance with the software vendor’s licensing policy.

You also need to ensure that you maintain a copy of each Service Pack, patch, hotfix, and Cumulative Update (CU) installed on your farm. Sometimes hotfixes are superseded later by other hotfixes or even retracted and can no longer be downloaded in the original form so maintaining copies will ensure you can return back to the exact patch level you had before you had the disaster if you find yourself in a DR scenario.

Dependent Services

SharePoint depends on a number of services that may not be covered by the SharePoint DR plan. Services such as SQL Server, Active Directory (AD), DNS, SMTP might have their own individual DR plans. It is important to make sure the RTO and RPO values for these services are in line those of the SharePoint environment. If they are not in line with each other then you must look at what needs to be done to get them in line even if it means adjusting the RTO and RPO of the SharePoint environment or increasing the budget set aside for the SharePoint DR plan.

Establishing and Documenting your Recovery Procedures

The next step in developing your SharePoint DR plan is to establish and document the procedures required for recovery. It is important to document these procedures as clearly and concisely as possible with the understanding that individual or individuals executing these procedures may not have been a part of developing the SharePoint DR plan. They are also most likely to be under a great deal of pressure during the execution of the plan so the more clearly the procedures are written, the better the chance for success within the expected timelines.

It is important to socialize your SharePoint DR plan so those that have a stake in the plan or will be a part of the testing or execution of the plan are aware of it and know where to go to see the latest copy as you SharePoint DR plan will be an ever evolving and changing document.

Define Success Criteria

How do you know your recovery is a success without defining success criteria? The criteria for determining whether your recovery was a success or not should be clearly defined in your SharePoint DR plan. Typically success criteria are derived from the recovery targets established during the development of the plan. For example if you have a recovery target for the corporate Intranet defined as one business day, when executing or testing your SharePoint DR plan you are able to have your corporate Intranet up and running in one business day or less the recovery is considered a success.

Success criteria can vary for different applications and sites that are part your SharePoint farm. As you are defining your recovery targets when developing your DR plan you will identify the various components of your SharePoint farm including individual application and sites and what will define a successful recovery in the event of a disaster.

Reviewing the Plan

Once you have completed your SharePoint DR plan it is important that the plan is thoroughly reviewed for accuracy and clarity. This review should be completed by a third party, or if that’s not possible, a qualified person or group that was not involved with creating the plan.

You should never consider your SharePoint DR plan complete until it has been checked and verified by parties that were not involved with creating the plan.

For more information please refer to:” Plan for high availability and disaster recovery for SharePoint 2013″ us/library/cc263031.aspx.