The Puppet IIS module was crafted with performance in mind. Instead of running PowerShell multiple times, we've taken advantage of performance improvements to the Puppet PowerShell module, applying them to the IIS module. We now open PowerShell just once per Puppet run instead of once per resource, vastly reducing the time taken and memory usage, compared to other approaches.
We've made API improvements that will make it easier to declare your configurations. Look for differences and improvements in managing things like web site
bindings, and when associating IIS applications, application pools, and sites.
We created a type that manages IIS features, allowing you to bring a newly provisioned target node from zero to working, and without using additional modules.
We have also started work on integrating the new IIS module
IISAdministration cmdlets into the Puppet IIS module. The plumbing code is present in this release, and future releases will have support for
IISAdministration cmdlets as we add them. This lights up Windows 2016 and Nano, allowing us to manage those operating systems.
Puppet is nothing without you, and we recognize that Puppet community members have already created some great IIS modules. Vox Pupuli and OpenTable have created just a couple of the many good modules out there. While we recognize the hard work done by the community (thank you!), we also want to help bring Windows automation forward and make things easier for everyone. We decided it would work well if we made a direct migration path from existing modules to our own, working with the community to create a Supported module. Vox Pupuli graciously agreed to transfer the puppet\iis module to Puppet, and we appreciate their collaboration.
If you are currently using puppet\iis, we have written a migration guide to make the process as painless as possible. We made every effort to make as few API changes as possible, but some instances were unavoidable, and we made the best decision as we could in choosing the right path forward. We used a few guidelines in our decision making process:
- Be as explicit as possible in naming types. For example, favor
'iis_pool. While this makes for more typing, it keeps the intent clear and avoids name collisions for similar concepts.
- Collate similar concepts into as few types as possible. For example, we moved parameters that were previously managed in catch-all classes into their relevant types. This makes types more verbose, but keeps your configurations more organized.
- Be opinionated in implementation, but let the user decide what's best. For example, include the
iis_featuretype to ensure IIS is installed correctly, but allow the user to decide which features to install, instead of providing catch-all lists of features we think should be in a base IIS install.
If you want to talk to our Windows experts in person, we’d love to meet you at PuppetConf, where we’ll have a bunch of great Windows talks. Also, feel free to come talk to us in Slack: https://slack.puppet.com/
James Pogran is a software engineer at Puppet.
- See how Puppet and Microsoft are working together.
- Register now for PuppetConf 2017 to see James Pogran’s talk, Using Puppet and DSC to Report on Environment Change and other great Windows talks.
- Take a look at the Windows module pack, which bundles all of the Puppet Supported and Approved Windows modules for your convenience.
- Read the Quick Start Guide for Windows.
- Sign up for Puppet Essentials for Windows training.