Microsoft's first approach was the DSC resource Kit. This harkens back to the Windows resource kits of old that first started coming out in the Windows NT days. The Windows resource kit was a bundle of several utilities that may not have had the same support guarantees as the built-in tools of Windows but provided needed functionality that system administrators came to rely on nonetheless.

The DSC resource Kit is similar in approach in that it contains several DSC resources bundled together into one ZIP file that you download from the Microsoft Script Center. However, they do not come with any support guarantees and are very much a use at your own risk type of option. This sounds like a dangerous idea and not something you would expect from Microsoft. You're used to getting production quality tools ready to use in your environment from Microsoft on day 1 of their release. This was a good approach for Microsoft in the past, but in today's world, delivering this kind of quality means months to even years of development and testing. Instead, Microsoft is following an agile cadence in releasing these DSC resources and producing a new release every month or so. By releasing these DSC resource Kits earlier in the development cycle, Microsoft delivers the tools faster to end users and also gets feedback earlier (when it can actually be acted upon and not months down the line when decisions are immovable). The users get the DSC resources they need sooner but have to balance that with testing these DSC resources themselves.

However convenient they are these, resource kits are hard to deploy in your environments. They were released in waves over the course of a year, each release happening every month or so. Users received a human typed list of changes and features added but no real way to see the differences between releases. Extensive testing had to be employed to ensure the new DSC resource at least behaved as well or better than the last release. These waves frequently had missing DSC resources that were present in the previous release, or they deprecated a DSC resource without telling the end user in the release notes, causing a surprise when the time came to use it. This made it quite evident that the process of releasing a resource kit wave involved a human zipping a folder by hand and writing up release notes after the fact, rather than an automated process that executed in tandem with development.

The largest negative aspect for this approach (as if the previous observations weren't enough), and most likely the reason Microsoft has de-emphasized this approach, is that it still took a long time for these resource kits to get to end users. It was a month or more between waves, and then the only way an end user knew there was a new release was to see it on the Windows PowerShell blog or through social media. While the PowerShell community is great at disseminating information quickly, this informal approach is not something to rely on as an update notification measure, and not one Microsoft really expected to stay as is. At the time of writing this, these kits are still available on the Script Center website but are not kept up to date.