While working on the InfoPath Forms Service DSC Resource for SharePoint DSC, I ran into an issue where I couldn’t get access to the InfoPath Forms Service configuration page in Central Administration (General Application Settings > Configure InfoPath Forms Services). Every time I would click that link, I would get presented with a SharePoint error page with the message InfoPath Forms Services is not turned on. (see screenshot below). This was happening for both SharePoint 2013 and 2016.
The issue was caused by me having set a name on the InfoPath Forms Service instance while playing around with PowerShell. In order to obtain a reference to the InfoPath Forms Service in SharePoint, you need to run the following PowerShell cmdlet:
The picture above shows what you should get by default with a clean SharePoint installation after you run the cmdlet. In my case, I had written the DSc resource so that it can also modify the name of the instance. Note how in the picture above, we can see that the name property is empty by default. After playing with the service instance, running the same cmdlet would give me the following result:
We can see from the picture above, that I had renamed my InfoPath Forms Service to have the name “My InfoPath Forms Service“, which is what was causing my issue. Luckily for me, I still had a variable reference to my service instance in the current PowerShell session (in my case, a variable named $is). Running the following PowerShell lines emptied back the Name property of the service instance, and the InfoPath Forms Service automatically went back online.
Last month I had the privilege of being interviewed by Richard Campbell on the RunAs Radio podcast. Richard and I talked about the ReverseDSC project I am working on. If you are interested in the tools I am building within Microsoft, it is a great introduction to what ReverseDSC is all about. The interview goes on for about 32 minutes, and covers everything from the concept of what ReverseDSC is, to some of the new cool tools I am working on including VisualDSC which lets you visualize a DSC configuration within Visio.
In this article we will cover the process of automating the configuration of an Office Online Server 2016 (OOS) using PowerShell Desired State Configuration. The end result will be a fully working OOS environment that has the French Language Pack installed on. Language pack support is something new I recently added to the OfficeOnlineServerDSC module and which will be available starting with version 220.127.116.11 scheduled to be released on December 20th of 2017.
In my case, I will be starting with a brand new Windows Server 2016 virtual machine on which I downloaded the installation binaries for OOS, as well as the French language pack. The installation media will be stored in a folder right at the root of my c:\ drive at C:\OOSInstall\:
The Language Packs executables need to be extracted in order for the new OfficeOnlineServerInstallLanguagePack resource to be able to do its job. In my case, I downloaded the French Language Pack from MSDN and stored it into C:\OOSLP\:
Office Online Server Language Pack Binaries
In order to extract the content of the Language Packs, we need to call the .exe file with /extract:. In my case I will be calling the following:
While I already have an article that covers the details of how you can use PowerShell Desired State Configuration (DSC) to patch a SharePoint Farm, I wanted to write a second article that covers the process of patching a multi-server farm, while respecting a sequential upgrade logic. Starting with PowerShell 5.0 we can now specify cross-node dependencies, which mean a node can wait for a specific resource to be in the desired state on another server before proceeding with the configuration of a given resource on the local node. By combining this new feature with the SharePointDSC module, we can fully automate our sequential upgrade sequence.
The scenario is the following: the client has a 4 servers SharePoint 2013 Farm and wishes to upgrade it to the November 2017 Cumulative Update (CU). The client’s maintenance window is on Saturdays and Sundays, between 2AM and 8AM Eastern time. The SharePoint farm had 2 Web Front-End servers (SPWFE1 & SPWFE2), and 2 Application servers (SPAPP1 & SPAPP2). The upgrade sequence should be as follow:
SharePoint Upgrade Sequence
If we were to put this into words, we should be able to install the binaries on all servers in parallel. The installation process may take longer to complete on some servers compared to the others. Once that is completed on all servers, then we should be running PSConfig on one server in the farm, and whenever the process finishes on that first server, then we can go an run it on all other servers in parallel. The orange dotted lines on the diagram represent “logic gates”. The first one, indicates that you should not be running PSConfig on the first server until the binaries installation process has completed on every server in the farm. The second one, specifies that we need to wait for the PSConfig process to finish on the first server before attempting to run it on the another server. These dotted lines will be represented by the Cross-Node Dependency resources WaitForAll in our DSC script.
We will start off by defining our Node structure in our configuration script. Since SPWFE2, SPAPP1 & SPApp2 all follow the same “logic”, we will put them all 3 in the same basket. The other server, SPWFE1 has unique logic and therefore needs to have its own Node definition. The skeleton for this will look like the following:
Since we can go ahead and install the binaries on all 4 servers at the same time, we can put the same logic block in both Node sections. The DSC resource used to install binaries update is SPProductUpdate. Because my client’s maintenance window is on Saturdays and Sundays between 2 and 8 AM, I will make sure to specify that window in my resource block.I will also specify that I wish to shutdown all services on my server to speed up the installation process. This will cause and outage of the SharePoint server. Just to keep things clear however, I will give them different names:
Once the binaries have been installed on the servers, we need to use the SPConfigWizard DSC resource to execute PSConfig and actually apply the update to the servers and databases. Once again, I will be specifying my maintenance window to ensure DSC doesn’t trigger an upgrade during business hours, and I will give the two DSC resource block different names to better illustrate the components involved. Our script now looks like the following at this stage:
Since by default, everything in DSC is executed sequentially at the node level, there is a risk that whatever server finishes installing its binaries automatically calls PSConfig even if the other servers are still in the middle of installing their binaries, or that multiple servers try calling PSConfig at the same time. To prevent this from happening, we will use the WaitForAll DSC resource which allows us to tell a node to wait for something else to complete on another node. In our case, we will tell the First server to wait for the binaries to be done installing on all servers in the farm and we will also tell the Secondary servers not to start their PSConfig process until it is first completed on the first node. In order for us to tell a DSC resource not to execute until something else on a different server has completed, we will use the DependsOn clause, and will “point” it to the associated WaitForAll instance. I will also tell the cross-node dependency to retry and check every minutes, for a maximum of 30 minutes to see if the dependency on the other server has completed. By doing so, we now have a complete script that looks like the following:
While working at a client site this week, we encountered an issue where they had duplicate entries for the same Document ID, meaning that when they tried to access that document via its DocId Url, they were presented with a search page showing the two items instead. Without going into the details as to what was actually causing this issue to surface, the easy fix for this was to go and remove one of the duplicate from the Search Index. Through this interface, this can be done as follow:
1 – Navigate to the Search Service Application Page in Central Administration.
Search Service Application page in Central Administration
2 – Click on Crawl Log in the left navigation.
SharePoint Search Crawl Log
3 – In the top navigation, click on URL View.
URL View in Search Crawl Log
4 – Search for the URL (or pattern) you want to remove.
Search Crawl Log for URL
5 – Find the item in the list and click on it to expand the contextual menu.
Crawl Log Entry Options
6 – From the list of options, select Remove the item from the Index.
The PowerShell Equivalent
In order for my clients to automate this process for the URLs they want to remove from the Search Index, I created a quick cmdlet called Remove-SPEnterpriseSearchURLFromIndex which simply takes in a URL pattern. Upon detecting URL entries in the Crawl Log that match the provided URL, the cmdlet will prompt the user to remove the item from the index or not.
$Url = "Default"
$ssas = Get-SPEnterpriseSearchServiceApplication
foreach($ssa in $ssas)
$cl = New-Object Microsoft.Office.Server.Search.Administration.CrawlLog $ssa
$logEntries = $cl.GetCrawledUrls($false,100,$Url,$true,-1,-1,-1,[System.DateTime]::MinValue, [System.DateTime]::MaxValue)
foreach($logEntry in $logEntries.Rows)
Write-Host "You are about to remove " -NoNewline
Write-Host $logEntry.FullUrl -ForegroundColor Green
$deletionAnswer = Read-Host "Do you confirm the deletion (y/n)"
}while($deletionAnswer.ToLower() -ne 'n' -and $deletionAnswer.ToLower() -ne 'y')
$catch = $cl.RemoveDocumentFromSearchResults($logEntry.FullUrl)
Write-Host "Deleted" -ForegroundColor Yellow
Write-Host "Could not delete the item" -ForegroundColor Red
This is going to be a very short Blog Post, not to say a brain dump, but if you ever need to retrieve the credentials used in a Specific ApplicationPool in IIS, you can use the following snippet of PowerShell code to do so:
This will output something similar to the following:
Now, I am sure some of you are probably freaking out by now, realizing that people with access to the server can easily retrieve the credentials from IIS app pools that are running as a specific user. Let me assure you that there is nothing magic about the PowerShell code above. When you specify credentials for an IIS application pool, after verifying against Active Directory that the provided credentials are valid, IIS will go and actually encrypt and store those credentials locally. Using the Get-WebConfiguration cmdlet allows you to retrieve and decrypt those.
So yes, the moment a user has access to run the PowerShell cmdlet on the server, he is also able to retrieved stored credentials for users running the app pool.
The latest version of the SharePoint DSC module has been released this last Wednesday, October 5th. You can now obtain the latest bits of the module by running:
If you wish to update the configurations on a given SharePoint farm to run these latest bits, make sure each .MOF file is first recompiled using the latest package and that the new module bits are copied to every server in the farm.
Here are some of the major changes that were introduced in this version:
SPServiceIdentity: A new DSC Resource has been introduced in the module to represent the managed account that is assigned to a service instance.
SPWebAppSiteUseAndDeletion: Fixed an issue with the scheduling where is was incorrectly setting the delays in weeks instead of in days.
SPWebAppGeneralSettings: Fixed an issue where web applications that weren’t assigned a TimeZone were incorrectly returning -1 instead of $null.
SPProductUpdate: Fixed an issue for updating a SharePoint 2013 farm were the resource was always complaining that the farm was missing the OSearch16 (SharePoint 2016 version).
Several other fixes related to the Get-TargetResource methods not properly returning values.
Along with the SharePointDSC 18.104.22.168 release, the SharePoint Orchestrator script for ReverseDSC, which allows you to extract the configuration out of an existing SharePoint 2013 or 2016 farm, has also been updated. To leanr more about what is new in the ReverseDSC Orchestrator Script, take a look at my previous blog post What’s New With SharePointDSC.Reverse 22.214.171.124
Patching a SharePoint 2013/2016 farm with the help of PowerShell Desired State Configuration (DSC) is a common ask I get from customers almost every single time I deliver a DSC engagement. As part of the SharePointDSC module, we offer two main resources to help you automate the patching process for your farm: SPProductUpdate and SPConfigWizard.
SPProductUpdate resource is responsible for installing the patch’s bits onto a server in the farm. It is the equivalent of manually running the installer for a Cummulative/Public update onto the given server. It is very important to note that declaring a resource block of this type in your DSC configuration ONLY installs it on the given node. You need to make sure that this resource block gets defined on every server in your farm to make sure all servers have the bits installed on them. This resource allows you to speed up the installation process on the various nodes by automatically shutting down the various Search Services that normally slow down the installation process. In order to shutdown those services during the installation, you need to specify the ShutdownServices parameter to $true
SPConfigWizard on the other hand, is the equivalent of running PSConfig on a given server. It is responsible for committing the installed bits into the configuration database to finalize the farm’s upgrade process. Just like the SPProductUpdate resource, this one needs to be defined against every server in the farm.
In this article, I will demo the process of patching a SharePoint 2016 farm, however the process is the same if you wish to patch a SharePoint 2013 farm. To properly demonstrate the patching process, I will be using a SharePoint 2016 RTM farm, and will be patching it to the September 2017 Public Update, which includes the Feature Pack 2 bits.
The first step is to go an download the SharePoint 2016 – September 2017 Public Update from the web. Decide where you wish to save it. My recommendation is to put it on a Shared Network Location that all servers will be able to access. However, you need to understand the implications of running the Update installer from a Network location using DSC, because your installation process may get stuck due to the User Account Control protection. I’ve put together a short article that lists the most common gotchas for when using DSC and solutions to them. In my case, the file will be put under \\DSC-Share\SP16-Sept16PU\sts2016-kb4011127-fullfile-x64-glb.exe
The second step is to add the DSC Resource blocks into your PowerShell configuration script. The recommendation here is for you to put them right after the SharePoint binaries have been installed via SPInstall, and right before your are actually attempting to have the server join the farm via SPFarm. This would also be the recommendation as far as location within the script for where to install the Language Packs. That is if you are using DSC to install your farm from the ground up.
For this article however, I am going to demonstrate the case where you already have a SharePoint 2016 Farm built and all you are trying to do in apply a Public Update on it via DSC. The following is the complete script I will be using to achieve this:
Initiate the Start-DSCConfiguration SP2016September2017PU -Wait -Verbose -Force cmdlet to initiate the configuration of the servers in the farm.
That was easy enough wasn’t it? Now, whenever a new update comes in that you wish to apply to your farm, simply update the SetupFile parameter’s value to the new PU file. DO NOT ever include more than one SPProduct update block for a given server in your DSC configuration. Updates in SharePoint are cumulative, meaning that if your goal is to update a farm to the October 2017 PU, you don’t need to install the September 2017 PU first.
In the Microsoft Virtual Academy on SharePoint Automation with DSC my colleague Brian Farnhill and I recorded in June of 2017, we dedicated an entire module to SharePointDSC best practices. I thought I’d take a few minutes to put the items we discussed during that session on paper. This article will act as a list of the most frequent issues and problem encountered by people using SharePoint DSC. It will be updated as the tool evolves.
Installation of Prerequisites, Binaries or Language Pack is Stuck
This is one of the most frequent issue people encountered when starting off with SharePoint DSC. When running the configuration using Start-DSCConfiguration, or when in Pull mode, the installation seems to get stuck when trying to install components (prerequisites, binaries, or language pack). No errors are being thrown.
Most Likely Reason:
There is some level of User Account Control set on the installation file. In most cases this issues will happen when the installation is done from a Network Drive. Upon executing the installation of the component, windows triggers a prompt for the user to confirm the execution of an executable that was launched from an untrusted location, but because this was initiates from a background thread, it is impossible to ever approve that prompt and the installation gets stuck.
In order to test if this is your issue, launch a new PowerShell session, running as the user defined in the PsDscRunAsCredential parameter of the execution block. From there, run the following line of PowerShell. If there are any prompts that appear, that means that the installation is most likely stuck because of the User Account Control.
Start-Process -FilePath <Path to the Installer file> -Wait -PassThru
The solution here is two fold. First off, we recommend you turn off the User Account Control feature for the user running the PsDscRunAsCredential installation block in your script. As a second step, launch Internet Explorer and go to Internet Explorer Settings. From there, go to the Security tab, click on the Local Intranet Zone, then click on the Sites button. In the prompt, click on the Advanced button, this will open the window that let’s you specify addresses to identify as being part of the Local Intranet Zone. In that window, type in the location of the Network share (or other common location) where the installer file is located, and click on Add.
Using a completely DSC based solution, you could use the xSystemSecurity module to disable the User Account Control prompt as follow:
# Make sure you import the module
Import-DSCResource -ModuleName "MSFT_xSystemSecurity"
# Put this in the node's configuration;
Setting = "NeverNotifyAndDisableAll"
SharePoint is a distributed system, meaning that not all components run on the same server, and that most of the content and configuration is actually stored in a SQL Server database, that all servers in the farm can access at any time. When you define a DSC configuration file, you should identify one of the servers in your farm to be what I refer to has your Master Node. this is the node on which you will define most of the components in the Farm. All other nodes, referred to as secondary nodes in this scenario, should only define resources that allow them to install the required binaries and updates, to join the farm, and the service instances to run on that server. All other components should ONLY be defined on the Master Node.For example, don’t go and define an SPSite entry on multiple node, it is not necessary. SPSite objects are defined in the Content Databases anyway, so you don’t need every server in the farm to attempt to create them.
Take another example where you wish to update the DSC definition of a certain feature on a Site Collection to be disabled instead of enabled. If you properly defined your configuration, you only have to update the DSC definition for that feature within a single node (Master Node) in the DSC configuration file, but let’s imagine you have it defined within every node instead. You now have to go and modify it multiple times within your configuration, and that opens the door to mistakes. Let’s say our farm has 3 servers, that you updated the feature’s definition for Server #1 and #2, but forgot to update the definition in server #3. To make things worst, you’ve set all 3 servers’ Local Configuration Manager (LCM) to be set to ApplyAndAutocorrect. We all know that by default, the ConfigurationMode for the LCM will check every 15 minutes to make sure it is in its desired state, but that 15 minutes may not happen exactly at the same time on each of the servers in the farm. Imagine that at 10h a.m., server one has its LCM kick in, and realize that the feature has to be turned on based on the new definition. It will go and disable the feature. Now, let’s pretend that server #3’s LCM kicks in at 10h05 a.m., but since that server doesn’t have the proper definition, it re-disables the feature that was just turned on 5 minutes ago by Server #1. You can see where this is going, and that can cause a lot of headaches for your admin team. DO NOT DECLARE components (other than SPFarm, SPIntall, SPInstallPrereqs, and SPServiceInstance) on more than one server in the configuration.
Use ApplyAndAutocorrect with Caution
We took a decision a few years back not to let SharePointDSC deal with content such as SPList, SPContentTypes, etc. However, we do deal with items such as SPSite and SPWeb that are stored in the Content Database. The real beauty behind SharePoint is that it lets users deal with their content as they see fit. Users can easily go and create a new list, play with it for a few days, and then decide to delete it after because their tests are done.
PowerShell Desired State Configuration is very powerful. When you set the Local Configuration Manager of a server to ApplyAndAutocorrect, the server will automatically attempt to bring itself back into its defined Desired State Configuration whenever it detects that it drifted away from that configuration. While this feature is very powerful, my recommendation is not to set the LCM in ApplyAndAutocorrect the moment your configuration includes either and SPWeb or SPSite resource declaration, unless you are absolutely certain and aware of what this will do to your environment.
Imagine the following scenario where you have an environment which declares 3 SPWeb (say Web1, Web2, and Web3), and for which the LCM is set to ApplyAndAutocorrect. Come spring, the Information Management (IM) team at your organization undertakes a major cleanup project where they want to get rid of sites that have not been active in the past 6 months. There 3 SPWeb sites defined in the configuration, have been identified by the IM team to be deleted. The IM manager goes in and deletes the 3 sites, then sends an email to the IM director to let him know that the cleanup has been done. Two weeks after the IM director stumbles upon SPWeb2, which the IM Manager claimed to have deleted 14 days ago. Well, the moment the site was originally deleted by the IM Manager, 15 minutes after, the LCM detected that it was no longer in its desired state, and since its LCM is set to ApplyAndAutocorrect, it automatically recreated the site. Imagine the confusion this can cause.
this article will be updated on an on-going basis.
The DSC Resource Kit Wave that includes the 126.96.36.199 release of SharePointDSC has not yet been published to the PowerShell Gallery. In order to try out the 188.8.131.52 version of the ReverseDSC Orchestrator Script for SharePoint, you will need to manually download the following modules:
As well as grab the latest version of the Orchestrator script from its official GitHub Repository.
The latest release of the ReverseDSC Orchestrator Script for SharePoint is the biggest release we’ve had so far and it is packed with new features that will make it even easier for users to migrate their on-premises SharePoint 2013 or 2016 Farms from their on-premises data centers to the cloud. This release drastically changes the way the orchestrator script does its extraction. The following is a complete list of all improvements that have been included in the latest release.
Configuration Data: A new ConfigurationData.psd1 file will be generated with all extractions. This external .psd1 file exposes all parameters that are specific to the source SharePoint environment. If you are planning on deploying a copy of the extracted SharePoint Farm into a new environment (Azure, on-premises, etc.), all you need to do is update the values contained in that file to reflect the destination environment. For more information regarding what parameters are now exposed in the Configuration Data, please refer to the Configuration Data wiki Page.
Extraction Modes: Previous versions of the Orchestrator Script would expose a -Lite switch, which allow the extraction process to skip certain DSC Resources such as the Timer Job States, Features, SPWeb, etc. In version 184.108.40.206, we introduce the concept of Extraction Modes, where each mode will capture a different set of DSC resources. to learn more about what set of DSC Resource will be extracted in each mode, please refer to Extraction Mode wiki page.
Full Installation: Previous versions of the Orchestrator Script extracted resources starting at the SPFarm level, meaning that the machines you were trying to replicate your environment on had to have the SharePoint bits installed on them already for the configuration to get applied. With the new version, the SPInstallPrereqs and SPInstall resources are automatically included in the configuration file. The Configuration Data files drives whether or not these are included in the compiled MOF file using the FullInstallation. parameter. If this parameter is set to $True in the configuration data, then the compiled MOF instances will attempt to install the SharePoint Prerequisites (using the Online Mode) and the binaries on the servers being configured.
New Resources Supported
SharePointDSC.Reverse 220.127.116.11 introduces support for the following Resources:
the following switches have been deprecated with the 18.104.22.168 Release. The equivalent result can now be achieved 9in most part) by using the -Mode Lite parameter.
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.