Share via

xSharePoint is now SharePointDsc - what you need to know!

  • Article

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.

What specifically is changing in SharePointDsc

The items in the module that are changing moving forward are:

  • The name will change from xSharePoint to SharePointDSC. This will mean that xSharePoint will no longer have new functionality published to the PowerShell gallery, version 0.12 will be the last version available under the old name [see note below on hotfixes]
  • All SharePoint DSC resource names will be renamed to begin with just "SP" instead of "xSP". For example, xSPCreateFarm will become SPCreateFarm. This means updating your configurations to rename the resource types to the new name format. The parameters for each resource remain the same (with the exception of changes to schemas that were made after the 0.12 release - see the release notes for a list of changes in 1.0 to understand these changes)
  • Other internal name changes will take place to ensure that all internal function names go from [verb]-xSharePoint[noun] to [verb]-SPDSC[noun]. These are not designed to be called directly though, but in the event that you have written scripts that do use these, you will need to use the new function names

Hotfixes for xSharePoint

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 release strategy for SharePointDsc

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.

How to prepare for the module rename to SharePointDsc

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.

Distribution of the module

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.

Updating configurations

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").

Republish your new configurations

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.

The future of SharePointDsc

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!

Comments

  • Anonymous
    June 14, 2016
    Good job folks! Very efficient way to deploy a SharePoint farm!