Powershell DSC Cookbook for Modern Windows Servers

[carpnick]

@pburkholder suggested I opened something here, maybe put in the readme. But before opening the PR - wanted to see if you wanted the link.

https://github.com/ebsco/iisposh

We were able to make the core pieces idempotent, for any setting by using WebAdministration module from powershell. This implementation is entirely pre-DSC, and is currently in use on 2008 R2. It is not fully a drop-in, since some functionality exists here, not yet implemented in the other cookbook. But figured I would share.

@pburkholder - not sure if you wanted to add anything else.

If nothing else is added or not interested, feel free to close issue.

[EasyAsABC123]

@carpnick it looks nice, i'm not sure without chef's help to figure out how to add this without adding the requirement to all users to have powershell installed.

Other than that I like it, some duplicate effort to which the only danger I see is that some features might operate differently. Basically the DRY coding practice.

We should discuss it though since Powershell offers some more abilities using Windows Objects

[pburkholder]

READMEs should be useful, and in that spirit, it would useful to reference an alternative, if incompatible, approach. I'm for updating the README.

[carpnick]

@EasyAsABC123 - as far as I am aware Windows 7/Server 2008 and above comes with native powershell 2 or above. Unless I am mistaken. And most Windows Sys admins make it a point to install powershell for management purposes. Agreed not all, but just my opinion

Also the API for the resources, as written is incompatible. With that said, if you would like to have an IRC based discussion or anything, let me know and we can setup a date and time.

[EasyAsABC123]

@carpnick absolutely put it in the readme that doesn't bother anything. I am more curious how we can build this cookbook to allow for multiple engines and an option to change which engine to use.

appcmd/powershell/wmi

[carpnick]

Depends if we want the APIs to be compatible or not. In other words, do we want to keep the resource definitions you have set up for the current resources in this cookbook. We really have a couple options:

• Keep resource definitions the way they are - provide providers that use the different technologies. Pros - one interface for users. Cons - Have to accept least common denominator for interface, so may lose features.
• Create resources that are implementation specific - iis_posh_pool. Pros - No limitation on interface changes, can make them specific to each technology. Cons - each resource has a different interface, thus users have a harder time.
• Create a different cookbook per technology - appcmd,powershell and WMI (if desired). Pro - each technology can make its own decisions. Cons - each feature is replicated across all 3 different cookbooks. Hard for users to choose.

There is no black and white to the options above. We took the initial stance of a separate powershell cookbook because we thought it would be hard to integrate into this one. Also we over time plan on migrating to DSC. The problem with the DSC currently, is it is immature and needs more features for us to use it directly. So we came up with this cookbook as a migration path.

[EasyAsABC123]

Each provider could simply have another attribute of :engine with the options of :appcmd, :powershell, :wmi, :etc the only issue I can see is support for all features will need to be in each engine...or perhaps an if statement where it can fall back to other engines if needed and available or error with engine does not support this action.

For now we can simply add it to the readme as an alternative IIS cookbook, but i'd love to see that in the future.

[carpnick]

PR opened for alternatives for now. I think we should figure out the future of IIS.

• Do we want to support this up until pre-dsc. Then move over to CWebadministration or XWebadministration.

Just come up with a game plan. Put our automation efforts into what is in the future. Just like we created the IISposh cookbook as a point solution, I would like to get everyone's input and come up with a plan as a community. I would personally like to add a requirement, that we see more data-driven resources, so we dont have to continue updating what properties exist. I know the DSC might not be setup for that, but it would seem like a good way to add extensibility.

Same goes with getting Chef folks into this topic. Maybe @smurawski, @btm, @mwrock, @adamedx are the ones I have associated with that might want to comment on the long term plan for IIS support. After talking to @smurawski at Summit, he seemed to want to get CWeb* integrated with XWeb* module.

[EasyAsABC123]

auto-closed due to merge

[mwrock]

I do think we need to support pre dsc until 2k8r2 is EOLd in 2020. What a beautiful day that will be! I think all the 3 major iis apis are compatible with all currently supported os versions but that will change soon with nanoserver. I have not played with iis on nano but I bet appcmd is gone.

If I were starting from scratch today I'd use the web administration module which I believe is the route iisposh took.

[smurawski]

@mwrock, I don't think so. 2008R2 supports wmf5. It'd be a breaking change of course, but I'm onboard cutting over to DSC sooner rather than later.

Side note, the webadministration module is a great ball of suckatude as well and they are trying to create a new module to manage IIS, but that effort (last I checked) was still thin wrappers around xml manipulation.

[mwrock]

Yeah upgrading 2k8r2 to wmf 5 is ideal, but I remember alot of pain years ago with breaking scripts that were not ps > 3 friendly. Likely an edge case though, but it would be nice to at have a non-DSC option available.

[EasyAsABC123]

@mwrock and @smurawski can you think of an option to add multiple "engines" without having disparity in features?

I am thinking we could make the cookbook "smart" to pick the engine that is "best" for the system it is on and then run with that. Let me know if you can think of a way of keeping the code clean and practicing DRY principles

[mwrock]

Its been a while since I have done much IIS scripting but do the different engines support more features over the other? If not its hard to justify devoting many cycles toward multi engine efforts unless one proves to be so much easier to work with than the other.

Ideally, consumers of the cookbook should not need to know the underlying implementation details. So I'd try and use as few "engines" as possible and stick with the one that has the most broad functionality and platform support.

[EasyAsABC123]

@mwrock absolutely, unfortunately at the moment that is appcmd, in the future it will be PS and DSC. Perhaps a new branch should be made with PS and DSC as the engine so that in the future we can just make that master...but that's just a thought any ideas are welcome

[smurawski]

@mwrock @EasyAsABC123 Maintaining multiple engines is great in theory but will quickly diverge. Creating a branch for DSC as a future breaking change (major version bump) after feature parity is a good idea. That older version would still maintain functionality for those who need it and we can press on with a newer version to support current technologies.

Side note: DSC doesn't do anything magic for IIS. At the heart is a bunch of powershell and appcmd.

[EasyAsABC123]

@smurawski good to know, so mainly you'd like to see the new technology for iis to be what?

[carpnick]

Looks like WMF5 production ready, will be coming soon

[carpnick]

As far as container support etc. Only time will tell. I would be shocked if msft released RTM containers without at least some basic DSC functionality built in.

[EasyAsABC123]

Did they fix the CPU issue with WMI that existed in win2003?

[smurawski]

@EasyAsABC123 I'd like to see things move towards DSC resources and pushing more of the feature work to xWebAdministration (eventually)

@carpnick There should be a DSC LCM in windows containers (from the 10 minutes of playing I did on TP3).

@EasyAsABC123 Windows 2003? Not supported anymore, don't care about it. :)

[EasyAsABC123]

@smurawski I think you missed the point, WMI used to have a bug where it would randomly consume 100% of the CPU. There was no fix for this bug (2 years ago) has this been resolved?

[smurawski]

@EasyAsABC123 That was a bug on Server 2003, which I haven't seen in any of the later OSes/versions of the WMF.

[EasyAsABC123]

@smurawski awesome! Thanks for the communication

[EasyAsABC123]

Closing, will create a branch with DSC code when code is written :)

[EasyAsABC123]

This is the current direction of this cookbook

[jakauppila]

What is the current status on this?

There's a few improvements I'd like to make for idempotency of some iis_config, but it may make sense to turn them into their own resources. It would also be a bit easier to use the Powershell equivalents of the appcmd commands for simplicity, but I think I'd rather focus any efforts on something that will live longer.

[EasyAsABC123]

@jakauppila Powershell is more than welcome, we also are thinking we will use the DSC PowerShell equivalents

[jakauppila]

@EasyAsABC123 Can we assume that the WebAdministration module is installed for some of those cmdlets?

[EasyAsABC123]

@jakauppila i wouldn't make that assumption, you could add a recipe to install and then verify it is installed before running it, that would probably be ideal.

[jakauppila]

Just to throw it out there for awareness, I am currently working on revamping the majority of the cookbook into pure PowerShell utilizing the WebAdministration module. I will submit a WIP PR in the coming weeks for some review. So far it is looking very promising.

I wasn't particularly happy with the current state of the XWebAdministration DSC module and it's capabilities.

[EasyAsABC123]

@tas50 @smurawski do we still want this re-written to be a dsc cookbook? I was listening to @smurawski presentations and don't know if chef still wants to have dsc cookbooks since we will likely have feature disparity pretty quickly with any changes made to the originating dsc

[smurawski]

@EasyAsABC123 I'm not sure what I would have said that would discourage building cookbooks on top of DSC resources - I think that is the correct way to go. You get the flexibility of Chef and the community tested DSC resources. Testing can be concern, but as long as there is a good CI pipeline in place - you'll get a heads up pretty quickly when there is a breaking change.

[EasyAsABC123]

Awesome! I’ll put a story on to complete this transition. Is there a preferred way to install the DSC resource? I found one download method but wanted to make sure

…

On Fri, Jul 12, 2019 at 4:02 PM Steven Murawski ***@***.***> wrote: @EasyAsABC123 <https://github.com/EasyAsABC123> I'm not sure what I would have said that would discourage building cookbooks on top of DSC resources - I think that is the correct way to go. You get the flexibility of Chef and the community tested DSC resources. Testing can be concern, but as long as there is a good CI pipeline in place - you'll get a heads up pretty quickly when there is a breaking change. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#231>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOD5YAS3Y3XO6PJ4SMI65LP7DWODANCNFSM4BV2JI6Q> .

[tas50]

I know internally there is some concern with making a core cookbooks like this use dsc since so many people don't have or want to use DSC. There was concern when we added DNS resources to Chef 15 that use DSC since a chunk of the user base can't use those resources now.

[smurawski]

I think there is a bit of difference between a cookbook (where you can pin to an older version and make a major version bump to move forward with a different backend) and core Chef resources which are tied to the version of client being run.

It is reasonable to make an assertion that future development of a cookbook is going to be based on the availability of certain API, especially given that all shipping versions of server (2008 R2 through 2019) except one (2008) can all support PowerShell 5 and DSC resources.

[EasyAsABC123]

sounds like some internal discussion might be necessary on differing opinions, let me know when the decision is made.

…

On Tue, Jul 16, 2019 at 10:49 AM Steven Murawski ***@***.***> wrote: I think there is a bit of difference between a cookbook (where you can pin to an older version and make a major version bump to move forward with a different backend) and core Chef resources which are tied to the version of client being run. It is reasonable to make an assertion that future development of a cookbook is going to be based on the availability of certain API, especially given that all shipping versions of server (2008 R2 through 2019) except one (2008) can all support PowerShell 5 and DSC resources. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#231>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOD5YEWYJXN2X66KMQYPV3P7XNWDANCNFSM4BV2JI6Q> .