Question: How far shall we enforce "supporting WMF 4.0" for DSC resources?

[johlju]

I have not read this anywhere, but might have missed it.

My question is primarily for xSQLServer, but this might be interesting for other resources as well.
We have a lot of technical debt over at xSQLServer. Keeping support both for WMF 4.0 and WMF 5.x will add more code and test coverage when we now are starting to resolve that.
Moving to support only WMF 5.x and beyond would of course make life easier for the contributors. But we might be leaving users behind who still aren't allowed to use WMF 5.x (for different reasons).

So... Must we code resource to support WMF 4.0 and up (as far as it can be done, issues might prevent it)?
Or can we start to leave WMF 4.0 behind and new contributions are allowed to leave out support for WMF 4.0 and, more importantly, remove existing WMF 4.0 code?

[PlagueHO]

@johlju - that's a pretty good question.

I have had a few issues raised where people have asked if they can add Class based DSC resources and I've generally suggested against it because of not being WMF4.0 compatible and at the time there wasn't the support for it in the DSCResource.Tests module (there is now of course).

I can't actually recall a situation I ran into where dropping support for WMF 4.0 was going to reduce a lot of tech debt for a resource, but then again I might not have been aware of a particular new feature or method that I could have used to save it. Do you have a specific example you can point at?

My personal feeling is that there are still a lot of enterprises out there on WMF 4.0 so we should still try and support it as much as possible where it makes sense. But that is just because we only just moved to WMF 5.0 for new servers and still have many thousands of WMF 4.0 servers. So I'm more thinking of this question from a DSC consumer perspective rather than a DSC Resource maintainer perspective.

But that is all just my 2c.

[johlju]

Updated 2017-01-05 13:56

Many resources in xSQLServer expect you to use PsDscRunAsCredential to set the credentials to use to login to the SQL Server instance, there is not another credential parameter. If you do not use PsDscRunAsCredential, then you need to give SYSTEM account the role System Administrator.

Currently the xSQLServerSetup does not work with the PsDscRunAsCredential parameter (issues around that being discussed) so it is used in a way that it is installed using SYSTEM (this is due to a bug). Doing so gives the SYSTEM account automatically System Administrator privileges. In a normal installation, it does not have close to that much rights. Giving SYSTEM that power should only be done if the user expressively set it (which you normally never do).
But since this bug in xSQLServerSetup exists, and the resource is installed with SYSTEM, then all resources works without the PsDscRunAsCredential.

When we fix the bug in xSQLServerSetup, all other resources need Credential parameter to be able to work with WMF 4.0. Or we again need to give SYSTEM account too high of rights. But if we choose to do so the resource that should set the permission, xSQLServerPermission, does only support PsDscRunAsCredential. So catch 22.

Update: When I wrote this I thought it was strange that SYSTEM account got this high permission on install. That was not entirely true. After verifying this thru different installations and clusters it is actually only SQL Server 2008 R2 that installs and sets SYSTEM account as 'sysadmin' role by default (regardless of DSC or manual install). SQL Server 2012 (and beyond) does not do this. This means that SQL Server 2008 R2 is the only major version that will work with the resource using with WMF 4.0 when SYSTEM account is sysadmin.

So to support WMF 4.0 and WMF 5.0, and keep the permission at the right level, we need to fix a Credential parameter in each resource, and as well make sure it still can use PsDscRunAsCredential. And for those resource that does not work with PsDscRunAsCredential parameter we need to add that support.
It would be less work to make sure that just the parameter PsDscRunAsCredential is supported in each resource.

On top of that, if we get a class based resources then that will make WMF 4.0 obsolete.
Now there is SQL Server on Linux that I guess we need to support soon. That makes WMF 4.0 obsolete as well.

To be honest, if we are going to support WMF 4.0 fully, with the current lead time, I would say we won't be there until a couple of years. During that time frame the users will have moved to WMF 5.0 (hopefully), and probably have PowerShell xNext1 and vNext2 been released, and then maybe we got even new functionality that start to make WMF 5.x obsolete 😉

There are a lot of issues in the back log and a lot of new functionality that must be added to the resource as well. We have just scratched the surface of the functionality that need to be created.
As a maintainer I would rather focus on that, giving users more functionality, than adding WMF 4.0 support. But at the same time I don't like the idea of leaving users behind (thus this issue).

But with all that said. If this discussion concludes in that we must support WMF 4.0. Then we focus on that.

[PlagueHO]

@johlju - ah I see! I completely understand. I can see why supporting both models would require a whole lot of extra codes and tests.

The xDFS resource module would have the same problem - it requires PsDscRunAsCredential. But I chose to never even implement WMF4.0 support (I don't actually know if I could have made it support WMF 4.0 anyway).

Could resource modules where this sort of problem have a milestone defined - say the next major version (v5.0.0.0 in the case of xSQLServer) - have WMF4.0 dropped. Anyone who is still on WMF 4.0 can still use the v4.0.0.0 version but if they want new features or fixes beyond that point they should be upgrading.

Perhaps we could put together a list of resource modules that are having this issue and then determine if it is worth dropping WMF4.0 support in a future version release - and specify which release. Perhaps the list could be published in this repo and then community feedback requested.

But this does sound like a good topic to be discussed on the next Resource Kit call - @kwirkykat?

[johlju]

Closing this since we now have removed support for WMF 4.0 in xSQLServer a few releases back. If there is need for WMF 4.0 an older version must be used (without new functionality and bug fixes). Basically there is to much technical debt and work that needs to be done to keep a fully working WMF 4.0 support. I'd rather look ahead than back.

[BrianFarnhill]

So I don't think supporting both models needs a whole lot of extra work at all - in fact, we have been doing it in SharePointDsc since day one. The approach is pretty simple - firstly go and have a look at our "Invoke-SPDscCommand" cmdlet - this is the brains of the whole operation. Basically, it will detect if the code is running as the local system account, or as a specific account (which means PsDscCredential was called). If it's running as the system account we use a supplied credential and use a CredSSP local session to run code as the specified user.

What this means is that we have a parameter called "InstallAccount" on each of our resources, which is the WMF 4 compatible version of how to do this. You can see it in action in most of our resources, but have a look at SPFeature for a simple look. Basically, we pass the $InstallAccount parameter in to the invoke call every time, but in all WMF5 scenarios this will be null and we'll just execute the code block in place and it's all fine - but if someone uses InstallAccount they will get that local CredSSP session and it'll work just the same.

The drawbacks to this approach - logging goes out the window when you do the CredSSP approach. None of the Write-Verbose calls in the code blocks work if you do it that way (but when we run with PsDscRunAsCredential it works fine as we just invoke the block directly). The second is the performance overhead - I did some initial testing when PS5 released to the new approach and we saw a 30-50% performance increase for not doing the CredSSP sessions, so configs ran a lot faster.

The pluses though - this is insanely simple to support and implement in our resources, just wrap the code you need to ensure runs as a specific user in the Invoke command we have there and you're good to go. From a testing perspective things get pretty easy as well. We wrote some tests to validate the behaviour of the Invoke command so that we knew that worked in isolation, then for each individual resource test we just need to mock that Invoke-SPDscCommand to just run the code without the CredSSP bit (which we do in a helper module that we include in all of our tests so there is no additional work for devs to do when writing tests).

Anyway, long story short - we've found that supporting both versions was honestly not that difficult, and I think you could probably take some of the approaches we have here to simplify doing the same for xSqlServer as well.

P.S. Sorry for being late to the party on this one - I didnt see the original post, I only saw the update when @johlju closed this!