This can be done quite easily by using the following PowerShell syntax:

Next, I’ll just go and populate the hash table with a few simple values

Now, we can check the value of $HashTable, and we should return something like this

Now for the fun part.  Since we’re all used to working with arrays, and the HashTable kind of looks and feels like an array (it’s not an array), it’s pretty natural for us to think: “Hey, I’ll just go grab the first item in the array by using $HashTable[0].  This is what you’ll get if you do that

If we want to reference a specific item in a Hash Table, we have to reference the key.  How do we get the key, you might ask?  like this

So, if I want to return the value of the item in the Hash Table with the key named “GitHubProcesses”, I would do this

So, what does that have to do with for-each  for Hash Tables?  Simple.  We can get a list of keys, and we need those keys if we want to get values.  So you can simply iterate through all keys in the Hash Table and get the value of each key, like this

And that would produce an output like this

So the next question would be: what happened to that nice task list that I had before?  And that all comes down to knowing the type of data you’re working with.  In that case, we have stored an array into the value of the GitHubProcesses key, and we have stored a string into the value of the Roger key.  We can verify this pretty easily

This will produce the following output

So, knowing the type of data you are working with is also important.  In the previous case, the array was being output as an array of entries, as opposed to the value of those entries, whereas the string was cleanly being displayed as the value of the string.  We could have simply chosen not to use write-host, so that the array would be expanded, like so

This would provide the following output

Summary

Long story short, the key, literally, is the key to working with Hash Tables..  Once you’ve mastered that, you can then start implementing advanced logic, such as detecting the object type, or well, anything other than simply outputting the value to the console.

Feedback

As always, should you have any feedback, feel free to post in the comments below.

You can also reach me on twitter @RCormier_MSFT

This blog post is going to describe what I found to be a pretty confusing error message, that you might also encounter when trying to manage SharePoint Online sites with CSOM in PowerShell.

Background

I had encountered this issue while creating a script for a client that would standardize site collection audit settings across all personal sites, so that users would be able to have direct access to audit data for their OneDrive for Business libraries, without having to open a ticket so that somebody with access to the Security and Compliance center can provide them with the requested data.

Approach

The first thing I did was make sure that I had the SharePoint Online Client Component SDK installed.  This would make sure that the appropriate assemblies are installed on my system and registered in the GAC.  There are other ways to get access to the assemblies, but this is my preferred method.

The next thing I did was launch PowerShell ISE as Administrator and load the assemblies that I wanted to use in this particular script

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.Runtime")

Next, I defined all of the variables that I was going to use, such as the Site URL, and the credentials to be used, etc. before finally trying to create the necessary context

$ClientContext = New-Object Microsoft.SharePoint.Client.ClientContext($SiteURL)

This resulted in an error message that appeared very helpful at first

New-Object : A constructor was not found. Cannot find an appropriate constructor for type Microsoft.SharePoint.Client.ClientContext.
At line:1 char:18
+ ... ntContext = New-Object Microsoft.SharePoint.Client.ClientContext($Sit ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [New-Object], PSArgumentException
    + FullyQualifiedErrorId : CannotFindAppropriateCtor,Microsoft.PowerShell.Commands.NewObjectCommand

 

I was very certain that I had loaded all of the necessary assemblies.  First I checked over some of my previous similar scripts –  they had no problem creating the context when only these two assemblies were loaded.

Solution

This was actually the result of a typo.  Not in the object namespace, but in the name of my variable name (not the value) when it was defined.  So basically, it was because I was passing in a null value where a string was expected.  See ClientContext members for more details.  If it had actually been because the assembly was not loaded, the message would have been more like this

New-Object : Cannot find type [Microsoft.SharePoint.Client.BigClientContext]: verify that the assembly containing this type is
loaded.
At line:1 char:18
+ ... ntContext = New-Object Microsoft.SharePoint.Client.BigClientContext($ ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidType: (:) [New-Object], PSArgumentException
    + FullyQualifiedErrorId : TypeNotFound,Microsoft.PowerShell.Commands.NewObjectCommand

 

Feedback

As always, if you do have any feedback or suggestions, I’d love to hear from you.

You can also follow me on twitter @RCormier_MSFT

Background

I was recently working with a customer who had an abnormally large number of [OrphanApp] entries in their health analyzer rule.  This produced a very large number of instances of a message similar to the following – so much so that manually reading through and validating each of these entries became a very cumbersome task

[OrphanApp] App [af6f2dd4-c702-406d-a792-11c2355749db] is orphaned in the database [O365Hybrid_ContentDB1] on site collection [9c64e5d0-aaac-4037-867e-0b77c334529f]. Orphaned Apps are not accessible, cause unnecessary resource and license consumption and may fail upgrade. Try to uninstall this App. App [af6f2dd4-c702-406d-a792-11c2355749db] is orphaned in the database [O365Hybrid_ContentDB1] on site collection [9c64e5d0-aaac-4037-867e-0b77c334529f]. Try to uninstall this App. If the App uninstallation is failing, it needs to be unblocked before the orphan App can be removed.

This was further complicated by the fact that any of the site collections that we verified (Get-SPSite –Identity 9c64e5d0-aaac-4037-867e-0b77c334529f) confirmed that the site did not exist in the environment

Approach

The overall approach in this case was pretty straightforward

1. Get the contents of the list item that contains all of the [OrphanApp] entries
2. Parse the message to isolate the site collection ID, the app ID and the content database name
3. Verify that the site collection exists by using Get-SPSite
4. Export the results to a human-readable format using Export-CSV

Solution

Part 1

Let’s start with getting the contents of the list item that contains all of the [OrphanApp] entries.  These live within a list called ‘Review Problems and Solutions’, which exists in the root web of your central administration site collection, so we can retrieve that pretty easily with the following PowerShell:

$HealthList = (get-spweb https://CentralAdminURL).Lists["Review Problems and Solutions"]

Next we would want to target the individual list item that contains our [OrphanApp] entries, in this case, the title will be ‘Missing server side dependencies.’.  We can retrieve this item pretty easily by using the following PowerShell

$HealthListItem = $HealthList.getitems() | ? {($_['Severity'] -ne "4 - Success") -and ($_['Title'] -eq "Missing server side dependencies.")}

This will return the entire list item, but in this case we are only interested in the ‘Explanation’ field.  Again, this is easily accessible using the following PowerShell:

$HealthExplanation = $HealthListItem[‘Explanation’]

Part 2

Now we have the entire string of data that we need to parse, which will include multiple entries.  These are separated with hard carriage returns, so we can actually split the ‘Explanation’ into all of the individual messages in this case by using Split as shown the following PowerShell:

$Messages = $HealthExplanation.Split(“`r`n”)

This will then result in a collection of messages, which we can iterate through by using a foreach loop

Once we are in our foreach loop, we’re going to use regular expression (or RegEx) to extract the information that we need.  Let’s start with the database name.  If we refer to the message above, we can see that the content database name is the only instance where we see words enclosed in square brackets after the [OrphanApp] entry, so we would use the following regular expression in PowerShell to extract that information from the string:

$DatabaseName = ([Regex]"\`[\w*\`]").Matches($Message)[1].Value.replace("[","").Replace("]","")

What this is doing is finding the [1] (or second) position in the array of objects (strings) that are returned when we look for a pattern that matches ‘[some words]’.  This accounts for the [OrphanApp] entry at the start of the array, which would be position [0].  The two instances of ‘.replace’ are used to strip the leading and trailing square brackets so that we return only the string.

Next we will extract the app ID and the site collection ID from the message using two very similar Powershell examples.  Again we will use regular expression.  Let’s take a look at how we extract the app ID in the first example.  The format of these messages is pretty standard and uniform.  The first GUID that we see in the message is going to be the app ID.  So we’re going to use the following PowerShell example to extract the first GUID from the message:

$AppGUID = ([Regex]"\`[[a-fA-F0-9]{8}`-([a-fA-F0-9]{4}`-){3}[a-fA-F0-9]{12}\`]").Matches($Message)[0].Value.Replace("[","").Replace("]","")

Let’s look at the RegEx formula that we’re using and break it down into its components quickly before moving on.  Each of these patterns must be matched in succession:

1. \`[  : We need to escape the ‘[‘ character, because this has special meaning in regular expression
2. [a-fA-F0-9]{8} : This includes all characters that could be used in a GUID, upper and lower case.  We’re looking specifically for 8 characters that match this pattern
3. `- : We need to escape the ‘-‘ character, because this has special meaning in a regular expression
4. ([a-fA-F0-9]{4}`-){3} : Again, this includes all characters that could be used in a GUID, we are looking for 3 successive instances of 4 acceptable characters, each followed by a ‘-‘
5. [a-fA-F0-9]{12} : Again, this includes all acceptable characters that could be used in a GUID.  We are looking specifically for 12 characters that match this pattern
6. \`] : We need to escape the ‘]’ character, because this has special meaning in regular expression

All put together, this regular expression (‘\`[[a-fA-F0-9]{8}`-([a-fA-F0-9]{4}`-){3}[a-fA-F0-9]{12}\`]’) will match any GUID which is enclosed in square brackets.

In this case, as we mentioned, the app ID will be the first GUID extracted from the message that is provided by the health analyzer, this is denoted by .Matches($Message)[0] in the example above.

The site collection ID will be the second GUID extracted from the message, so in that case the RegEx we use doesn’t change dramatically:

$SCGUID = ([Regex]"\`[[a-fA-F0-9]{8}`-([a-fA-F0-9]{4}`-){3}[a-fA-F0-9]{12}\`]").Matches($Message)[1].Value.Replace("[","").Replace("]","")

The only difference in this case is that we target the second match returned, as denoted by .Matches($Message)[1].

Part 3

Now that we have extracted the site collection ID, it’s pretty straightforward for us to use that information in a simple Get-SPSite script

Get-SPSite $SCGUID -ErrorAction 0

I use the –ErrorAction 0 (silently continue) in this case because I know that many of the site collection IDs that are referenced do not correspond to actual sites in the environment.  It’s not really error handling, but it’s preventing a flood of red from being output to the screen.  If this returns a site collection object, the site exists. If it returns nothing, then the site collection does not exist in the environment.

Part 4

Now that we have all of the information we need to collect, outputting the information to a CSV is a pretty simple way to make it human readable and portable.  We can do this by putting all of the information we need into a PSCustomObject.  We do this by using the following PowerShell script:

$LoggingInformation = [PSCustomObject] @{
        DatabaseName = $DatabaseName
        AppGUID = $AppGUID
        SiteCollectionGUID = $SCGUID
        SiteExists = $SiteExists
        }

This will effectively declare a new variable (PSCustomObject class) named LoggingInformation and set various properties (DatabaseName, AppGUID, SiteCollectionGUID, SiteExists) to values that were previously retrieved.  We can then export this object to a CSV using the following PowerShell script:

$LoggingInformation | Export-Csv –Path “c:\sharepoint\output.csv -Append –NoTypeInformation

In this case, the LogingInformation variable is considered the input object.  I’m using the ‘Append’ switch to ensure that the information is added to the end of the CSV and the ‘NoTypeInformation’ switch just so that we don’t export type information for every object exported

Download the Script

I’ve created a script that puts all of this together for you, and you can download it from the TechNet script gallery.  There you will be able to find usage details that will help you execute the script.

Download Get-OrphanedApps.ps1

Feedback

As usual, if you do happen to have any feedback or suggestions regarding how I could improve this script, feel free to reach out to me.

You can also follow me on twitter:

@Rcormier_MSFT

Background

I had been working with a customer on some health reporting scripts, and one of the validation steps was to run Test-SPContentDatabase against databases that were identified to contain orphaned apps.  While manually running Test-SPContentDatabase, under the context of the SharePoint Farm Administrator account the SharePoint administrator received a very confusing message.  The message was: ‘Cannot open database [DatabaseName] requested by the login. The login failed.’

Approach

As we were very sure that the farm account had sufficient rights to access this database (everything else appeared to be working normally and we had run other PowerShell cmdlets against this database in the past) we were suspicious that the error message returned may have been erroneous.

We just took a quick look at the available parameters for this cmdlet using Get-Help

Solution

A quick look through the parameters, and we knew that we had simply forgotten to specify the ServerInstance parameter.  This was necessary because the database we were testing was not located on the default database server (I would love to link to an official Microsoft article that explains where and how to do this, but the latest article I can find on this topic is for SharePoint 2007 – nonetheless, it is a pretty straightforward process)

As suspected, the error message was incorrect.  This was not a logon issue, SharePoint was looking for a database on an instance where it did not exist.  In the end, we simply added the –ServerInstance parameter, and Test-SPContentDatabase completed successfully

Feedback

As always, if you do have any feedback or suggestions, I’d love to hear from you.

You can also follow me on twitter @RCormier_MSFT

Approach

Solution

Download the Script

Usage

Feedback

This post is going to discuss how to perform a bulk file copy from a SharePoint library to a folder on the file system. Along with this blog post, I will also provide a downloadable script, which can be modified to work in your environment. As we are copying files from SharePoint to the file system, all metadata will be stripped. Additional work could be performed in order to export the metadata to an xml file. This functionality is currently not available in the version of the script provided.

Background

I was recently working with a customer who needed to export files from one SharePoint environment and import them into another SharePoint environment. Though SharePoint does have this functionality built-in using Export-SPWeb and Import-SPWeb, in this case an export resulted in no files being exported from the desired directory. This was later determined to be corruption of the files after the export was unsuccessful on the desired directories.

Approach

In this case, the approach was simple enough. Read the folder and file structure from the specified list and replicate that structure on the file system.

Solution

This solution is tricky enough because of the way files are accessed in SharePoint lists. Enumerating all files in the list can be performed, however folder structure would not be maintained by calling $List.Items. In this case, what we have to do is perform two separate actions. One action to retrieve the root folder of the list and enumerate the items, and one action to enumerate each folder and each file in each folder. In order to do this, we call $List.rootfolder.files

We also need to enumerate all folder, and enumerate all of the files in each folder. This can be done by using $List.folders. This will list all folders (including subfolders) for the list.

$Folder.folder.files allows you to enumerate all files in a specific folder

Now that we have a collection of all of the files and their directories, we can export the files to the file system. This can be performed by accessing the binary steam of the SharePoint file, and assigning it to the binary stream of a file system object. This is performed by using the following snippet of code.

Once the script has been exported, the structure of the files and folders will be maintained on the file system as they were in the SharePoint site.

Download the Script

The script can be downloaded from the following location:
BulkFileExport.ps1 (compressed)

Usage

This script does require some edits. All edits are explained at the top of the script. Each child directory must be specified in the script. Each library which is to be exported will need to be added to the script using the three lines of PowerShell which are included. Here is a brief explanation.

This next line will create a directory at the specified location. In this example, a directory will be made beneath the root directory and will be named StyleLibrary
New-Item -Path ($Directory + "\StyleLibrary") -ItemType Directory

This next line will retrieve a list with the specified title, and assign it to a variable. The variable name is not important, as long as the correct variable is passed to the ExportFiles Function in the next line
$StyleLibrary = $Site.RootWeb.Lists | ? {$_.title -eq "Style Library"}

This next line will export files from the list specified via the first variable and to the subdirectory specified in the second variable.
ExportFiles $StyleLibrary "StyleLibrary"

Feedback

As always, feedback and suggestions are always welcome. If you do have any ideas on how to improve the script, I'd love to hear them.

You can also follow me on Twitter:

 RCormier_MSFT

Background

I was working with a customer recently who needed to move a subset of their data from one site collection to another in order to provide representative data to a group of developers. The data provided had to be portable, but also had to be dynamically collected using values provided by certain business units. What we had decided on in the end was a site collection which contained the necessary data. This site collection would be stored in its own content database, and that content database could be packaged with the images used to create developer environments.

Approach

The approach that we had decided on was simple in theory. Determine which items we wished to include in the new site collection, and duplicate the data as needed. If we hadn't had complicated filters, we could use content deployment to get the job done. If we weren't moving the data into a remote site collection, we could use the MoveTo method that each file has, etc. But for our specific requirements, things would have been a lot easier.

Solution

As I mentioned, the first thing we had to do was determine which files we wanted to include in our representative data. This is pretty straightforward. First get the web that contains the list, then get the list, then get the items you want. In this example, we use Get-SPWeb to get the web, then we use the SPWeb.Lists property to return the lists we want, and then we can use the SPList.Items property to retrieve the items we want. Of course, each of these can accept filters via a piped statement, such as:
$MyList = $MyWeb.Lists | ? {$_.title –eq "Shared Documents"}

In this example, I'm pulling all items from a library with only two items

Here is a screenshot of the original list in the browser

Now that I have a collection of files, I need to loop through my files and send them to my desired destination. This process is a little more complicated than I had envisioned it to be originally. I'm going to summarize in this blog post, however you can refer to the comments in my script for more detail as to what steps and decisions are being made along the way.

One of the first things that I do in my loop is pull out the binary stream from the file, using the SPFile.OpenBinary method, and assign that to a variable. I'll be using this later to populate the contents of the destination file. Next I'll be creating a new file by calling the SPFileCollection.Add method in the destination library. After the file is created, I then retrieve a list of all SPListItem.Fields objects that are not read-only and compare those to SPFile.Properties of the source file and the destination file. For each property, if the property does not exist for the destination file, I create the field using SPFile.AddProperty. Finally I set the value of the property using SPFile.Properties on the destination file, passing the same value that exists on the source document.

Again, there are a lot of little things happening here, and instead of posting a screenshot for each step, it's probably easier to refer to the comments in the example script I provide.

The result should be that your destination library will have exactly the same files in exactly the same folder structure as source library, as shown in the following screenshot:

Download The Script

This script can be downloaded from the following location:
Download CopyFilesAndFolders.ps1 (zipped)

Usage

The script requires four parameters to be set. These correspond to the source web, the source library title, the destination web, and the destination library title.  Edit these four parameters to suit your environment and then execute the script.

Feedback

As always, feedback and suggestions are always welcome. If you do have any ideas on how to improve the script, I'd love to hear them.

You can also follow me on Twitter:

 RCormier_MSFT

Background

One of the greatest things about SharePoint, is that even after years of using the product, it will continue to find new ways to break that you've never seen before. And this is what happened to me. I had just built a new SharePoint 2010 farm in order to test some scripts that I had been working on. One of my customers was setting up PDF search in their SharePoint 2010 environment and was having an issue getting PDF documents to return in their search results. My first instinct was to send over this document:

How to install and configure Adobe PDF iFilter 9 for SharePoint 2010

In response they indicated that they had been following this documentation and that it had in fact not worked. This documentation has always been solid for me, and has always done the trick – so I had to do some testing to make sure nothing changed, and that my guidance was still valid.

Issue

I had just created my new Search Service Application a few days prior, and I hadn't even performed a full crawl of the index yet. I followed the documentation, made my PDF icon appear and everything, uploaded some sample PDF documents and then kicked off a full crawl of my SharePoint sites content source. Everything looked great, and I had over 300 items in my index. Everything looked great until I did a search. Once I performed a search, I was greeted with an "Object reference not set to an instance of an object" message, and a correlation ID. Using Merge-SPLogFile, I passed in the correlation ID and got the following output (cleaned it up a little so that it's somewhat readable):

Videntityinfo::isFreshToken reported failure.

CoreResultsWebPart::OnInit: Exception initializing: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.SetPropertiesOnQueryReader() at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnInit(EventArgs e)

Internal server error exception: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.SetPropertiesOnQueryReader() at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnInit(EventArgs e) System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.SetPropertiesOnQueryReader() at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnInit(EventArgs e)

Watson bucket parameters: SharePoint Server 2010, ULSException14, 06175311 "sharepoint server search", 0e00178d "14.0.6029.0", 17853a8f "microsoft.office.server.search", 0e0017ee "14.0.6126.0", 5021bda3 "tue aug 07 18:15:15 2012", 000032a1 "000032a1", 0000002d "0000002d", 4a6d3421 "nullreferenceexception", 67316a39 "g1j9"    ff503ece-c286-454b-a5f2-998ca970808f

What does this mean?

So here's what I understood from this: My Core Results Web Part needed access to something, and it wasn't available or did not exist. I just had no idea what could have been missing. I've set SharePoint search up hundreds of times. I walked through my configuration, made sure that all of the services were started, and made sure that everything looked like it was properly configured.

That Eureka moment

Looking at my configuration, and then mentally walking through the process, it had sort of donned on me. I had two servers in my farm. One for all web functions, and one for all application functions. My Search query and site setting service, and my SharePoint Enterprise Search Service Application Proxy both existed on the application server AND I was using my app server as my browser. I had forgotten to follow this document on my application server:

You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version

For anyone who is not familiar with this document – this is the famous 'DisableLoopbackCheck' document. Whenever my query web part tried to access the proxy (hosted on the same server the request was coming from), it was being denied access and couldn't determine where the query component was even hosted.

The solution

After figuring this much out, all I had to do was run through the documentation create the DisableLoopbackCheck registry key on my application server. Once I created this key and rebooted the server, the problem went away. This allowed me to validate that the documentation for configuring PDF indexing in SharePoint 2010 was still valid and worked perfectly.

Feedback

As always, any feedback is always welcome.

You can also follow me on Twitter:

 RCormier_MSFT

What's new in authentication for SharePoint 2013

Background

As I said, I ran into this issue when I was configuring my own lab environment. I was using some existing scripts I had for SharePoint 2010, since most of them work, in order to create several web applications. If you haven't seen the documentation on TechNet, don't worry. SharePoint is pretty good about telling you that classic mode authentication has been deprecated in SharePoint 2013. This is a screenshot of what you will see if you configure a Windows classic mode authentication web application:

This is the text contained in the informational message, in case you're encounter the issue:

WARNING: The Windows Classic authentication method is deprecated in this release and the default behavior of this cmdlet, which creates Windows Classic based web application, is obsolete. It is recommended to use Claims authentication methods. You can create a web application that uses Claims authentication method by specifying the AuthenticationProvider parameter set in this cmdlet. Refer to the https://go.microsoft.com/fwlink/?LinkId=234549 site for more information. Please note that the default behavior of this cmdlet is expected to change in the future release to create a Claims authentication based web application instead of a Windows Classic based web application.

The good news is, we won't have to think about this forever – and it will end up being automatic eventually.

Issue

I ran into a few issues with this. The first issue I ran into with this was that using my SharePoint 2010 scripts and simply passing the AuthenticationProvider parameter my web applications were not consistently being deployed using windows claims authentication. The first web application would get created with windows claims authentication, every subsequent web application would ignore the AuthenticationProvider parameter and the web application would be created using windows classic authentication.

When this occurred, this would set off a chain of failures in my scripts, particularly when creating web application policies and assigning object cache accounts. The error message that you when this happens is also pretty helpful, and shouldn't set you back too far. Here's a screenshot:

This is the text contained in the error message, in case you encounter the issue:

The specified principal does not correspond to the authentication mode of this collection

Resolution

I never did find out why I was having inconsistent AuthenticationProvider behavior. It was however resolved by rewriting my PowerShell script, and breaking everything out into functions created using claims authentication. I've made the script that I'm using available in the TechNet Gallery. The script itself does have a significant amount of conflict and error detection, and should make deploying claims authentication web applications in SharePoint Server 2013 pretty simple.

Download

The script can be downloaded from the following location:
Download CreateSP2013ClaimsWebApplication.ps1 (zipped)

Feedback

As always, if you have any questions or feedback, let me know. If you have any ideas to optimize the script, I'd like to hear that too. Thanks for reading!

You can also follow me on Twitter:

 RCormier_MSFT

Background

Microsoft has been telling customers for years to set their Maximum Degree of Parallelism (MAXDOP) to 1 for SQL instances which host SharePoint database. For the most part, this guidance has been widely ignored with very little consequence, with the exception perhaps of sub-optimal performance.

For those of you who are unfamiliar with what this setting actually does, you can refer to the following documents:
max degree of parallelism Option
Recommendations and Guidelines for 'max degree of parallelism' configuration option

The second link actually does a pretty good job of explaining in detail what this option does – and here's the short summary: The SQL Server configuration option 'max degree of parallelism' controls the number of processors used for the execution of a query with a parallel plan.

A higher MAXDOP value would typically be used when you have a very small number of concurrently executing queries relative to the number of processors. A lower MAXDOP value would typically be used when you have a very large number of concurrently executing queries relative to the number of processors. The default value of '0' will effectively limit the MAXDOP value to the number of processors.

SharePoint is a system in which there will be a very high number of concurrently executing queries; therefore this system favors a lower MAXDOP value. As indicated in the following documents, the optimal MAXDOP value for SharePoint environments is 1.
Storage and SQL Server capacity planning and configuration (SharePoint Server 2010)
Enterprise intranet collaboration environment technical case study (SharePoint Server 2010)

Historically, Microsoft has been making this recommendation, and adding query hints in order to limit MAXDOP for each query to 1 in order to limit the impact of setting MAXDOP to any value other than 1, or leaving it at 0. This does not appear to be necessary going forward, and I'll do my best to explain why.

What Happens If I Haven't Set MAXDOP to 1?

The answer here is pretty simple. If your MAXDOP value has not been set to 1 on the SQL server instance on which you're attempting to host your databases, you will not be able to create databases on the instance. The error message you will encounter is the following:

New-SPConfigurationDatabase : This SQL Server instance does not have the required "max degree of parallelism" setting of 1. Database provisioning operations will continue to fail if "max degree of parallelism" is not set 1 or the current account does not have permissions to change the setting. See documentation for details on manually changing the setting

Also seen in this screenshot:

How Do I Work Around This Problem?

There are basically two ways to remediate this issue. The first one (not recommended) is to grant the account running the PowerShell cmdlets, or executing the Configuration Wizard, sysadmin access to your SQL instance. The second, more desirable approach, is to set the MAXDOP value to 1 in the SQL instance.

The MAXDOP option is an advanced option. The documentation above does provide the SQL statements to change this option. I'll briefly explain how to do this using SQL Management Studio. My screenshot is from SQL Server 2012, the process will be the same for SQL Server 2008 R2, and SharePoint 2013 does not support older versions of SQL:

1. Open SQL Management Studio and connect to the instance which will host SharePoint databases
2. Right-click the Instance you wish to manage
3. Select 'Properties'
4. Select the 'Advanced' Node
5. The Second option from the bottom will be 'Maximum Degree of Parallelism'. Change this value to 1
6. Click 'OK'

Your value should appear as in the screenshot below:

After having set the MAXDOP value to 1, you should be able to proceed and create your farm and/or additional databases, all the while following at least one best practice.

What Does This Mean In The Enterprise?

This should mean that enterprises will start to be a little more mindful of what kind of applications, if any, are going to share database instances with SharePoint. People in the enterprise need to consider what type of query patterns are going to be used in their applications, and whether or not the performance of these applications will be negatively impacted by having a MAXDOP value of 1. What I anticipate will happen is that we're going to see more SQL instances that are dedicated to hosting SharePoint databases, possibly for multiple farms, and overall I see this as a good move.

Feedback

As always, if you have any questions or feedback, let me know. I'd be interested in finding out what your thoughts are regarding this change in SharePoint 2013

You can also follow me on Twitter:

 RCormier_MSFT