xWSManConfig Resource to manage winrm/config

[guitarrapc]

Hi, it seems very nice if there are xWSManConfig resource to manage winrm/config.

There are some circumstance that exceed max envelope size with DSC, Test-DscConfiguration or others. One possible solution is just double limitation but it should be better make it so with DSC.

Set-WSManInstance -ValueSet @{MaxEnvelopeSizekb = "1000"} -ResourceURI winrm/config

[PlagueHO]

Good idea @guitarrapc. I'll put it on the backlog and get it added for you. Thank you!

[PlagueHO]

Once I get this moved over to the DSC team I'll put some time into adding this.

[guitarrapc]

Thx!

[PlagueHO]

@guitarrapc - I haven't forgotten this one. Hopefully not too much longer till the repo gets moved over. The PR to get this repo into the resource kit isn't too far from completion (I hope).

[PlagueHO]

I had this written over a year ago, but was waiting to get this resource module into the DSC resource kit. However, this process has been cancelled. So I'm releasing this myself. Just in case you're still interested in using this!

This new resource has been released to the PS Gallery: https://www.powershellgallery.com/packages/WSManDsc/2.0.0.51

I'll close this issue now.

[fullenw1]

Sorry if I'm wrong but I couldn't find a resource to configure the MaxEnvelopeSizeKb...

PS> Get-DscResource -module WSManDsc -syntax -name wsmanserviceconfig WSManServiceConfig [String] #ResourceName { IsSingleInstance = [string]{ Yes } [AllowUnencrypted = [bool]] [AuthBasic = [bool]] [AuthCbtHardeningLevel = [string]{ None | Relaxed | Strict }] [AuthCertificate = [bool]] [AuthCredSSP = [bool]] [AuthKerberos = [bool]] [AuthNegotiate = [bool]] [DependsOn = [string[]]] [EnableCompatibilityHttpListener = [bool]] [EnableCompatibilityHttpsListener = [bool]] [EnumerationTimeoutMS = [UInt32]] [MaxConcurrentOperationsPerUser = [UInt32]] [MaxConnections = [UInt32]] [MaxPacketRetrievalTimeSeconds = [UInt32]] [PsDscRunAsCredential = [PSCredential]] [RootSDDL = [string]] }

Did I miss something?

[PlagueHO]

Hi @fullenw1 - No, you're quite right. Those particular properties (including MaxTimeoutms, MaxBatchItems and MaxProviderRequests) are actually not set in the Service container. They're set one level up. So what I'd need to do is create a new resource to deliver them. That should not be too hard to do so I'll look at implementing that. In the mean time you could set this with a script resource.

[PlagueHO]

I'll raise a new issue to track this.

[fullenw1]

Hi @fullenw1 - No, you're quite right. Those particular properties (including MaxTimeoutms, MaxBatchItems and MaxProviderRequests) are actually not set in the Service container. They're set one level up. So what I'd need to do is create a new resource to deliver them.

Ok, I though the MaxEnvelopeSizeKb setting was part of these configurations you had implemented because it was inside the original question at the top of this issue and you said you would get it implemented...

I will indeed use a custom resource meanwhile... Thanks :-)

[PlagueHO]

@fullenw1 - yeah, you are right - I ended up just implementing the service level ones and not the other ones. I should have some time this weekend to get this done. :grin: sorry about the mistake on my part.

[PlagueHO]

Actually, having a bit of a think about this: Trying to decide if I should deprecate WSManServiceConfig and replace it with a more generic WSManConfig that contains properties from:

• wsman:\localhost
• wsman:\localhost\client
• wsman:\localhost\service (what is currently contained in this resource)
• wsman:\localhost\shell

This would result in the resource containing a lot more properties. But it isn't a huge issue because the resource is data driven.

This would result in a breaking change though. But I feel it might be acceptable as long as I update the resource major version number. I'll leave this here for a bit before making a decision.

The alternative is to create new resources:

• WSManConfig
• WSManConfigClient
• WSManConfigShell
• WSManConfigService (already exists)

[PlagueHO]

@johlju, @gaelcolas - would you mind giving your thoughts on this one? E.g. which approach would be the better strategic one - I'm of two minds.

[gaelcolas]

Tough call. I'd go with having several resources, but I don't know enough about all the the settings to say if it's wise. Small atomic resources should be easier to evolve and maintain.

[PlagueHO]

Ok, small atomic resources it is. Thanks @gaelcolas :grin:

[johlju]

Sorry I so behind so haven’t been able to answer. But my thought is looks like using several resources it would be easier to see what is being configured than one large with probably have a type-property so it could be check that the correct parameters are set for what is being configured. But as @gaelcolas says, I’m not sure what the properties are.

Going with several resources isn’t a bad thing, just make sure code is reused.

[PlagueHO]

Thanks @johlju - sounds fair to me. Because the resources are data driven it should make it easy to share code.