SharePointDSC Updates

For those who have been using previous versions of SharePointDSC to install / configure SharePoint 2013 and/or 2016 environments, there are a couple changes which you have to understand when moving to SharePointDSC to either support installing SharePoint 2019 or to continue installing SharePoint 2013 and SharePoint 2016. This information is outlined in the as part of the GitHub project (

IsSingleInstance Parameter

This parameter is required and has been added to numerous resources within the SharePointDSC module. If you are using any of these resources you will have to add in the parameter for IsSingleInstance = “Yes” to your configuration.

  • SPAntivirusSettings
  • SPConfigWizard
  • SPDiagnosticLoggingSettings
  • SPFarm
  • SPFarmAdministrators
  • SPInfoPathFormsServiceConfig
  • SPInstall
  • SPInstallPrereqs
  • SPIrmSettings
  • SPMinRoleCompliance
  • SPPasswordChangeSettings
  • SPProjectServerLicense
  • SPSecurityTokenServiceConfig
  • SPShellAdmins

Standardized Web Application URL Parameter

This change takes the parameter called “Url” and replaces it with the parameter “WebAppUrl”. The following resources are affected, which means if you are using any of these resources you will need to rename the “Url” parameter to “WebAppUrl” or your configuration will not compile.

  • SPDesignerSettings
  • SPFarmSolution
  • SPSelfServiceSiteCreation
  • SPWebAppBlockedFileTypes
  • SPWebAppClientCallableSettings
  • SPWebAppGeneralSettings
  • SPWebApplication
  • SPWebApplicationAppDomain
  • SPWebAppSiteUseAndDeletion
  • SPWebAppThrottlingSettings
  • SPWebAppWorkflowSettings

New Parameters

This change introduces new required parameters for the following resources. If you are using these resources in your configuration, you will need to make sure the associated parameters are specified or else your configuration will fail to compile.

  • SPSearchResultSource
    • Added Parameter for “ScopeName”, where your options are “SSA”, “SPSite” or “SPWeb”
    • Updated Parameter for “ScopeUrl” to make the parameter required
  • SPUserProfileProperty
    • Added Parameter for “PropertyMappings”, which looks to replace “MappingConnectionName”, “MappingPropertyName” and “MappingDirection”

MaxDOP SQL Server Setting

This is a new check of the SQL Server settings for Max Degree Of Parallelism on the SQL Instance in which the SharePoint farm is going to be created. This check is located in the SPFarm resource and checks to see if the value is “1” as per the guidance for Best Practices for SQL Server in a SharePoint Server Farm.

This will not keep your configuration from compiling, but it will stop and fail the configuration of the SPFarm resource if this setting is not configured in your environment.

If you are installing and configuring SQL Server as part of your configuration you can use SQLServerMaxDop resource as part of the SQLServerDSC module to configure this setting. For example:

            SqlServerMaxDop SQLConfigMaxDoP
                InstanceName = "MSSQLSERVER"
                Ensure = "Present"
                MaxDop = 1
                DependsOn = "[SQLSetup]SQLSetup"

You can see more information for SQLServerMaxDop by visiting The SQLServerDSC GitHub project.

These are just the changes which I have seen in the change log and exceptions I have run into and had to update my configuration. More information can be found at

Thank you!

Posted in 1 | Leave a comment

SharePoint 2013 eDiscovery – Programmatically creating a Case, Discovery Set and Sources

I have looked around for examples on how to use the eDiscovery APIs and have found the object model information, but could not locate any source code to help guide me on what I needed to do in order to create a new case, new discovery set or a new source. Below I have provided some code I have used in a sample console app to do these activities.

First, create a new site collection using the eDiscovery Center Site Template. I assume you know how to create a site collection and select a template using central admin and/or PowerShell, so I will not get into that here in this post. If you need help creating a site collection, please refer to

You will want to get a reference to the Microsoft.Office.Policy.dll which is located in 15\ISAPI folder. Add a Using reference for Microsoft.Office.Server.Discovery as well.

In code you will need to gain reference to the site collection which was created above. This is done as I provided below.


Technically you can create the site collection in code as well if you prefer, just as long as you get a reference to the site in order to create the case which is what we will do next.

In order to put something on hold in an eDiscovery Center site, you have to create a case. A case is sub-site created under the eDiscovery Center site with the eDiscovery Case site template (EDISC#1). In code this is pretty straight forward as creating any other SPWeb in code as you can see below.


Once you have created and/or gained reference to a case (which is an SPWeb object), you will need to create a Case object from it.


Next is creating a Source object. A Source object is the information and data you will be putting on hold. This could be a SharePoint source location, which is considered a type of “Location” or a mailbox which is considered a type of “Mailbox”. You have to create the source from the Case object using either the CreateLocation() or CreateMailbox() methods. You can see the code below in which the Source object is created.





As you can see there are some additional properties being set as well. I will explain them here…

The Name property is just setting the name of the source as you will see it in SharePoint. The source is entered into a SharePoint list as a SharePoint list item and the name is what you will see as the source when looking at the case in the SharePoint site.

The WebId and SiteId properties are what tells the source which SharePoint location is the target. You can further refine the source using specific search query, however this code is putting an entire site on hold and I don’t have any additional search queries defined.

The FederationId is the GUID for the search result source where the content of this source is stored. If the location which is being put on hold is in another Result Source, you will have to specify that result source ID. For PowerShell code to get this Id, you can run the following to get the list of examples which will get you the Local SharePoint Results.

get-help Get-SPEnterpriseSearchResultSource -example

When you have set all the properties for the Source object, you must call Update() to save those changes.

Once you have a Source object created, you have to create a Source Group. In the browser this is referred to as a Discovery Set. The Discovery Set (or Source Group) contains the Source or Sources which are to be put on hold for that particular discovery. The following code creates the SourceGroup object and adds the Source from above to it, then starts the process to place them in a hold.



As you can see in the code the Source Group is created from the Case object and the Source created earlier is added to the Source Group. The Name property represents how you will see it displayed in the browser when looking at the site.

The Preserve property is what will set the content on hold. When setting this to true and calling the Update() method, it will start the process to gather the information provided by the sources and process them to put them on-hold. This process takes a few minutes to process depending on the number of items being placed on hold.

I hope this helps provide insight into using the eDiscovery API to create and manage cases in SharePoint programmatically.

Microsoft.Office.Server.Discovery namespace:

Posted in 1 | Tagged , | 2 Comments

SharePoint 2013 – Site Collection Upgrade with Site and Web Scoped Feature Upgrading Events

In recent weeks I have been working on explaining Feature Masking and Feature Upgrading and ran into something I would like to share.

When I was testing feature upgrading with setting a master page when a site collection is upgraded from SP2010 mode to a SP2013 site collection I was doing so based on a feature which is scoped at the web level. The one thing I noticed is that when I did the same test regarding the master page but using a site collection scoped feature it behaved differently.

What happens is that during the process of a site collection upgrade, the site collection features are upgraded, then SharePoint provisions and applies the OOTB seattle.master, then the web features are upgraded.

If your master page in SP2010 was deployed via a site collection scoped feature and you are trying to use the process to update the master page to a SharePoint 2013 version upon site collection upgrade as I explained in a previous post you will notice when the upgrade is complete you will be set back to seattle.master.

Right now the workaround is either to deactivate and reactivate the master page feature to reset your custom master page on the site or move your site collection scoped feature to a web scoped feature prior to upgrade.

Posted in 1 | Leave a comment

Automatically Update 2013 Master Page during Site Collection Upgrade using Feature Upgrading Event

Most if not all of us in SharePoint 2010 created custom master pages and designs for portals, team sites, etc. Now all that work not only has to be re-done to fit the new SharePoint 2013 look and feel and new functionality, but has to be reset once you do a site collection migration.

When you do a site collection migration from a SharePoint 2010 mode site collection to a SharePoint 2013 mode site collection in SharePoint 2013, the process will reset the master page of the site collection to the default master page. Imagine if you have 1,000’s of site collections, now you have to write scripts to update all these.. now imagine you are on a SharePoint Online Dedicated environment, where you do not have access to run scripts to update them in bulk.. It would be very difficult to do this manually.

This is where we go back to SharePoint 2010 and Microsoft introduced Feature Upgrading. Although at the time this new process was not widely adopted as people still never versioned their features no matter how many updates they applied to them… BUT this is the perfect process for handling the application of a SharePoint 2013 master page when a site collection is upgraded from SharePoint 2010 mode to SharePoint 2013 mode. This is because as part of this site collection upgrade process, it will also trigger a feature upgrade of every feature which is activated on the site or web.

Since you have to redevelop a SharePoint 2013 version of your master page and should be using feature masking to support that “Branding” feature which is activated in SharePoint 2010 to also be activated as a SharePoint 2013 feature. More information about Feature Masking can be found in my previous blog post:

From this point I will assume you know how to migrate / mount a SP2010 content database (mount-spcontentdatabase 🙂 ).

The first thing is feature masking.. you have a farm solution for SharePoint 2010. In my case it is called MasterPage-SP2010.wsp. This solution has a web scope feature which deploys the master page and sets it as the current master page using the feature activation event receiver. This is nothing new, so I expect you know how to do this as well.

The second part of this is to support feature masking I created a SharePoint 2013 version of the solution called (you guessed it!) MasterPage-SP2013.wsp. In order to support feature masking I followed all the same rules defined in the previous blog post regarding the feature folder structure, feature name and feature ID needs to be the same as the feature in which I am masking from SharePoint 2010. See screen shot below (MasterPage-SP2013 on the left and MasterPage-SP2010 on the right).


Now that feature masking is configured the site collection will have a feature of ID “b3add9ff-ee85-453b-80e3-2699b7da4e5d” in the “Activated” collection associated with the 14 hive (SP2010), when upgraded it will still associate with that same feature ID but now be linked to the 15 hive (SP2013). The difference is there is a different assembly which is associated with the SharePoint 2013 solution, which has additional logic to set the master page.

First in the SharePoint 2013 solution, you must include an <UpgradeActions> element. This element defines the event receiver class to run in order to execute the event of FeatureUpgrading. Within this Upgrade Actions element, you define a <VersionRange>. Since most of us never put a version on our SP2010 features, it is assumed to be a version number of So we would need to define a version for our SharePoint 2013 feature and set the range from to that version (in my case I set it to You can see the example below from my test projects where I defined the upgrade actions in my feature.xml file. You will have to do this manually as this is not part of the GUI.


I have included the FeatureUpgrading event code within the feature receiver file I used for activating and deactivating. In order for the upgrade event to fire, you need to specify the “<CustomUpgradeAction Name=”MasterPage2013Upgrade”>” Element in my upgrade action. Since I was just doing this one thing, I originally left this out since it is not required, however I realized my code was not being executed unless I had this defined in the XML. I also added a check in the code to make sure the upgrade action I am executing was indeed the “MasterPage2013Upgrade”, which you can see below.


The one thing which you have to watch out for when creating a module to deploy the master page to the site is where you plan on putting it in the master page gallery. For the most part up until now, we all put our custom master pages in the root of the master page gallery. Now in SharePoint 2013, you have to put it in a sub-folder. If you try to put it in the root of the master page gallery the code or the execution won’t break, however you will not see the master page in the gallery from the browser window. You can however see it if you look at the gallery through SharePoint Designer. This is not ideal as the file is not versioned or has a content type applied to it.

You will need to also add in the Type=”GhostableInLibrary” attribute as well if you want the document to show up in the library.

You can see how I defined my modules folder below…


After all this the key things to remember are to specify a CustomUpgradeAction Name and make sure you push the master page file to a sub folder of the master page gallery.

After all is said and done you should have 2 WSP’s.. One for SP2010 and one for SP2013. You must deploy these via PowerShell and when deploying these WSP’s you must remember to use the “-CompatibilityLevel” Parameter when using both Install-SPSolution and Uninstall-SPSolution.

Hope this helps.

Posted in 1 | 1 Comment

Upgrading Custom List Definitions when migrating from SharePoint 2010 to SharePoint 2013

I have run into this a couple times and have not seen much information posted regarding upgrading custom list definitions when migrating from SP2010 to SP2013, so I wanted to share my experience in a test I did.

The process I define below is using “Scenario #3 – Feature Masking” in the MSDN article I posted about earlier:

I had a SP2010 Farm Solution which had a site feature which “deployed” my custom list definition to my team site, which I then can create list instances from. I did this while in SP2010 as you can see here in the following screen shot.


I am not including the steps to backup/move/restore/mount databases for a migration. This is more about how a list definition is upgraded.

At this point I just deploy my SP2010 customization to my SP2013 environment to support the mounting of my content database so it doesn’t spew errors and warnings saying I am missing a solution / feature. I have my SP2010 solution deployed using the command…

Install-SPSolution -Identity splistdefinition-lib.wsp -CompatibilityLevel 14 -GACDeployment

“-CompatibilityLevel 14” is the important part of that command and details as to why is outlined in Scenario #3 in the MSDN article (see link above).

As you can see the solution has deployed the feature to the 14 hive on SP2013 and not the 15 hive because it is a SP2010 WSP Farm Solution


This will allow me to mount my database and open the site and basically see the same thing in SP2013 as I did in the previous screen shot since the site is running in SP2010 mode.


To explain my point as to SP2010 custom list definitions not upgrading to the SP2013 list functionality upon upgrade of a site collection, I will upgrade my site collection prior to installing my SP2013 version of the WSP Farm Solution. Below is the screen shot of how the site has been upgraded to SP2013 and the lists still look like SP2010 lists. This is because of the “Fall back” compatibility. Since it cannot locate the feature in the 15 hive, it falls back to the 14 hive feature, giving you the same SP2010 look and feel.


Since SP2013 changed the look and functionality of SharePoint list and library views, the SP2010 views really stand out when they are not upgraded. In order to get these lists updated, you will have to create a SP2013 version of those list templates. The rules as to how the solutions have to be different in Solution Name and Solution ID, but the same as in Feature Names and Feature ID’s can be found in the MSDN article (see beginning of this post).

Once I have the SP2013 version of my solution, I deploy it the same as I did my SP2010 version however when I install the solution I use -CompatibilityLevel 15 (you guessed it, because this is a SP2013 solution … 🙂 ) Here is the command…

Install-SPSolution -Identity splistdefinition_13.wsp -CompatibiltiyLevel 15 -GACDeployment

After this is deployed you can see the same feature is defined in the 15 hive now. This means the site feature will find it in the 15 hive and not have to “Fall Back” to the 14 hive.


After this is installed, going back to my SP2013 site I can see my lists now look like they belong in SP2013.


The biggest thing is to make sure you follow the instructions outlined for feature masking in the MSDN article I posted above. You have to make sure certain things like feature name, Feature ID and Solution structure are the same between the two solutions. If they are not you will get errors when you try to deploy them side by side. If the solutions are built properly you will not have an issue deploying them as long as you use the -CompatibilityLevel parameter to define which mode the solution is targeting.

I hope this helps someone. Thanks.



Posted in 1 | Tagged | 1 Comment

SharePoint 2010 Customizations Upgrade Guidance to SharePoint 2013

I had the pleasure of getting involved in the review process for this documentation. Please check out the following MSDN article which outlines 3 scenarios to support the upgrade of full trust code (farm solutions) customizations / SharePoint solutions from SharePoint 2010 to SharePoint 2013.

This link also leads to a discussion about using the feature upgrade framework to assist in re-application of SharePoint 2013 master pages since after a site collection upgrade the site will be transferred back to the SharePoint 2013 OOTB master page. The feature upgrade framework can be used in conjunction with feature masking (see scenario #3 in the link provided above) to trigger code to re-apply SharePoint 2013 master page assets to the site.

Posted in 1 | Leave a comment