Ask Learn
Preview
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
For just over 12 months now we have been working hard to grow the xSharePoint DSC module to let SharePoint 2013 and 2016 administrators use PowerShell Desired State Configuration to manage their SharePoint deployments. We've come a long way in the last year, and now with the help of my core team we are making an important transition - we are renaming from "xSharePoint" to "SharePointDsc".
This is important for a number of reasons for this - the most important of which is removing the "x" element. If you have ever had a read of the home page on GitHub for xSharePoint (and other "x" resources as well) we describe this as being a flag that the resource is "experimental". This was something that made sense when we first created the resources were first built - we needed to test and refine them, collect feedback from sources both internal and external to Microsoft, and add more functionality to make the module something much more than just an experiment. Now the time has come to move forward with a new name that indicates the "Production ready" state of our resources, and that is the main driver behind the change. There is an open RFC from the PowerShell team that touches on some of these issues in terms of how we approach versioning going forward with the PowerShell modules that is also worth a read for more information on what is happening in this space.
The items in the module that are changing moving forward are:
As version 0.12 of xSharePoint is the last version that will be published with that name, we wanted to ensure that we had an approach that would mean we could provide support and hotfixes to customers who are using xSharePoint currently who are unable (for whatever reason) to move to SharePointDsc. For that reason, a separate branch will be maintained with the code from the 0.12 release that we will be able to push specific hotfixes to in the event that a customer requires it. These will be published at increments to 0.12 (so from 0.12.1.0 to 0.12.2.0, 0.12.3.0 and so on). No new functionality will be added to this branch, SharePointDSC will be the module that receives all the new development effort - so customers should begin planning now for how to transition to the new module.
The next steps forward on how SharePointDsc is released are pretty simple. The next release (which is already available on the PowerShell gallery) will be numbered 1.0. Moving forward we will be doing releases every month and will be following the final version number strategy that is decided upon when the RFC from the PowerShell team is closed and formalised. Releases will usually be done at the start of the month, with the next scheduled release to be 1.1 in early July.
There are a number of steps to be taken when the updated module becomes available. The below list is a high level walkthrough of the primary considerations.
Firstly you need to consider how you will deploy the module to your servers. The good news here is that because the names of all of the DSC resources and cmdlets have been changed, there is no reason that you can't have xSharePoint and SharePointDsc on the same server as you transition. So the usual options for deploying these modules are available - such as deploying through PowerShellGet, adding them to a pull server (or Azure Automation if you are using it as your pull server), or through manually deploying the module to nodes you are pushing configurations to.
Once you have the module available you can begin to update your configurations to use the new resource names. This will firstly mean changing the "Import-DscResource" cmdlet at the top of your config to use the "SharePointDsc" module and not "xSharePoint". After this begin to change the names of each resource from the module to remove the x off the front (so as described above, "xSPCreateFarm" becomes "SPCreateFarm").
Once you have updated the configurations you can republish them to your existing SharePoint servers. The new resources behave exactly the same as the old resources, so this should not trigger any changes as the same test and set methods will be used - its just the names that have changed. So a configuration element that was in a compliant state before the change will continue to be compliant with the new name.
We aren't finished with SharePointDsc yet, not by a long shot. We keep our backlog of features, fixes and enhancements on GitHub - here you can see what we are working on, expected timelines for releases and you can even raise new issues for us to make any changes to the module here as well. We will be continuing to release updates with changes once a month and we will be constantly listening to feedback from the wider community. So raise an issue on GitHub, or post a comment here, and go out and do great things with SharePointDsc!
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign in