Justin King

My feedback

  1. 35 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Justin King supported this idea  · 
  2. 59 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  PowerShell » Desired State Configuration (DSC)  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King supported this idea  · 
  3. 96 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    survey  ·  Mark Gray responded

    Justin,

    We totally understand that a robust Pull server / central management solution is something that is critical to your success with DSC. We have invested quite heavily in Azure Automation DSC (AA DSC) to fill many of these needs. With that said, I would be very interested to understand if the AA DSC solution does not work for you (and other customers) and why? Vote and comment if this is important to you.

    Also interesting feedback on our ‘bad ideas’. Thanks!

    MarkG

    Justin King supported this idea  · 
    Justin King commented  · 

    Separate post on "bad ideas".

    This may be possible frustration talking, but from what I can tell, the idea that a node would gather multiple MOFs from multiple sources is asking for trouble. Basically it makes test automation much more difficult, and practically relies on the various coders for the various MOFs to be in tight coordination so nothing "collides" when it hits the node .... because the node does the final compilation of the various Mofs... which seems like it's the _last_ place you should be doing that kind of testing.

    It also makes certificate management much more difficult.

    In contrast, I could very easily, instead of making multiple partial configurations, make a composite configuration, with multiple configuration resources in it's place. This gives me all the advantages of a partial configuration (separate files to edit/checkin/manage), but the final mof generation is complete so I get the results of any possible conflicts BEFORE I upload it to the pull server. I honestly don't see why I'd ever want to compile things on node when I can pre-compile and see problems up front before it ever gets there.

    So in summary: it introduces lots of potential problems with the final config being handled at the node, adds complexity with multiple configuration points, plus complicates and multiplies the certificate story, and for what advantage? I'm guessing it makes it more compatible with some 3rd party product .... because otherwise it's a solution looking for a problem.

    Justin King commented  · 

    It's a fair question on AA DSC, but there are a lot of reasons it may not fit.

    1. AA charges by runtime, even if a hyrbid worker is on-premise to reduce the amount of direct calls made into Azure form on-premise resources. In a proper Dev-Ops model with constant code updates and modifications, this makes a lot of clients nervous about hosting code changes in cloud as there's is basically the possibility of 100% runtime and charge.

    2. Some modern AD Forest security models make internet based update engines impracticable/impossible, for example admin forests with strict security monitoring/regulation requirements.

    3. AA DSC can't rotate certificates yet. When your machine cert is about to expire you have to manually renew it. On-premise, I was able to solve this in a weekend with a single custom function and DSC resource which I then uploaded to the powershellgallery. If the pullserver were open source I could fork and propose to merge this functionality. for now, download dschelperfunctions and clcmcertificatemanager... dont know if it works in AA DSC honestly.

    4. Finally, there's the idea that AA DSC should even be in the discussion. This is about WMF5, PowerShell ... a fundamental cornerstone of the new Windows designed for a Dev-Ops world. This shouldn't be an extra add-on service. This should be part of the new windows, just like we can expect a functioning WSUS or PKI service.

    Justin King shared this idea  · 
  4. 36 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Justin King supported this idea  · 
  5. 36 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  PowerShell » Other PowerShell  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King commented  · 

    while the suggestions are varied, I simply want to add my support that "get" should not be a request and should instead return installed/available certificates.

    Justin King supported this idea  · 
  6. 5 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    6 comments  ·  PowerShell » Desired State Configuration (DSC)  ·  Flag idea as inappropriate…  ·  Admin →

    What would you describe as “official”? We are moving forward with some of the x-named DSC resources in the Gallery, with the intent of removing the x and fully supporting them once they hit a certain level of quality. Is that sufficient?

    Justin King commented  · 

    Thomas: It's not pre-packaged software. It's standardized PS1 scripts accessing WMI. Anyone, right now, can open xNetworking in notepad and hack away at it (use ISE please). Thinking of modules as "when will they officially supported" is like asking some random poster of a blog to support his script he used to get some work done.

    Right now, this moment, I have posted three separate modules on PSGalllery. Anyone can post to it, you're just misinformed if you think psgallery modules are _ever_ going to be supported by Microsoft. It's a centralized repo, nothing more.

    But honestly I'm just echoing what a Microsoft rep has said on GIthub around the modules/resources: the "x/c/whatever" is being deprecated.

    https://github.com/PowerShell/DscResources/issues/101#issuecomment-186472024

    Don't hold your breath for anything beyond critical/core resources. What you're asking for is currently contrary to their entire marching direction.

    Justin King commented  · 

    DSC resources are being shipped/updated via the power-shell gallery and maintained via GitHub completely separate as they've been made open source.

    On the powershell github I was told all "x" and "c" where soon going to be dropped because it's community supported now.

    Put the two together and modules are becoming 100% community driven ... I don't think "official" has any context anymore.

  7. 6 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    planned  ·  3 comments  ·  PowerShell » Desired State Configuration (DSC)  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King commented  · 

    Thank you for the update! I figured out later that it's not used for encryption after deeper testing, sorry about that part being false and I"m glad to hear it's an official bug to be only 1024.

    I would like to clarify, however, that while it IS only for authentication, it's non-configurable when using configurationnames. If I use a ConfigurationID, I can then specify the CertificateID in the Configurationserverweb block and authenticate with whatever certificate I desire. As soon as I go to configurationnames .... I have to use the self-generated certificate "DSC-OaaS" and that property becomes illegal to specify.

    I find the lack of options a bug as well, as my ability to control this behavior changes.

    I have more details posted in a blog:
    https://transformingintoaservice.wordpress.com/2016/03/09/wmf5-dsc-and-dsc-oaas-certificates/

    Justin King commented  · 

    Thank you for the update! I figured out later that it's not used for encryption after deeper testing, sorry about that part being false and I"m glad to hear it's an official bug to be only 2014.

    I would like to clarify, however, that while it IS only for authentication, it's non-configurable when using configurationnames. If I use a ConfigurationID, I can then specify the CertificateID in the Configurationserverweb block and authenticate with whatever certificate I desire. As soon as I go to configurationnames .... I have to use the self-generated certificate "DSC-OaaS".

    I find the lack of options a bug as well, as my abilty to control this behavior changes.

    Justin King shared this idea  · 
  8. 12 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  PowerShell » Desired State Configuration (DSC)  ·  Flag idea as inappropriate…  ·  Admin →
    survey  ·  Mark Gray responded

    Justin,

    Thanks for you feedback! I What types of things do you find yourself needing to manage in the meta-config after initial deployment? This is not to take away from the need for this, I want to better understand how you and other customers are / want to use it.

    Regards,

    MarkG

    Justin King commented  · 

    Sorry to double respond, but let me throw an ideal scenario your way (at least to me):

    I would love to be able to declare a meta-config just like I do other configs with ConfigurationNames. As simple as:

    ConfigurationNames = @('meta.LA','BaseOS','SQLServer')

    With that meta-config I could control all of Los Angeles so that when my boss says "rather than splitting out a dedicated reporting server or setting up a cluster, lets just drop the update frequency to every 4 hours" all I have to do is update that one configuration and I know all 200 servers will adjust. Or that annual "hey you know that DSC certificate we use to encrypt data? It's expiring, can you update all the servers ASAP?" .... yeah that's still just one edit of one file.

    Justin King commented  · 

    There are a couple ways I'd like to use it. Ill try to list the most relevant:

    1. Updating Pull Server information. Let's say, for whatever reason, I want to split the reportserverweb or want to add an additional configurationrepositoryweb. This could be for any reason from new dev-ops projects being spun up that want to push their own configurations to me deciding that a site has gotten big enough that I want to introduce a localized pull server.

    2. Standardizing configurations. Right now with the metaconfig being "push only", there's no real way to enforce 15 minute refresh times, continueonreboot, debug mode ... anything. Instead the best I can do is create a custom script to "push" a new metaconfig out which seems silly in the face of the existing pull architecture. While "set locally" may make sense for settings like configurationnames, the general delivery infrastructure seems like something we should retain control of.

    3. Certificate management. This last one is a bit more selfish example, but relevant. Right now I've written a custom module that uploads public certificate chains that meet a pre-defined criteria to a central file share. in WMF 4 I could then run a function that would dynamically read the thumbprint/filename and use that when encrypting the mof. Basically, as certs refreshed on a node, they got published ot a share ... so the next time I build a mof the "latest" cert was used and meta-config made along with it. Both would pull form the pull server and things functioned .. auto-renewing certificates completely hands-free. With meta-config downloads "broken" I now have to either manually manage all these certificates, or write _another_ custom module that kicks off a set-dsclocalconfiguration when it sees a change .... both of which are a lot of excess work considering it all "just worked" before.

    Justin King shared this idea  · 
  9. 17 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Justin King supported this idea  · 
  10. 49 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  PowerShell » ISE and tooling  ·  Flag idea as inappropriate…  ·  Admin →

    Thank you for the suggestion. Given the number of requests, we cannot field all recommendations, so for now we’ll be monitoring this to see if there is broad support.

    Justin King shared this idea  · 
  11. 55 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    8 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    survey  ·  Zachary Alexander responded

    Thank you for your input. Based on its current ranking compared to other feedback items and product schedule, work on this item is pending (and will be driven by) further customer input.

    Justin King commented  · 

    I personally think dynamic verbs are a bad idea. We don't even have to look that far back, during PS2.0 the cmdlets were so non-standard in their verbs it gave PS a needlessly complex learning curve. I'm all for expanding the list, but this is one area I think MS needs to regulate a bit more so the cmdlets continue to feel intuitive.

    I mean, nothing is technically stopping me from writing a custom function right now that follows completely arbitrary guidelines ... but I like that I get a "Warning" to keep things to a standard.

    Justin King supported this idea  · 
  12. 53 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    In Queue  ·  3 comments  ·  PowerShell » ISE and tooling  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King supported this idea  · 
  13. 119 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    10 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →

    Hi everyone,

    With PowerShell 6.0, we’ve already begun updating our versioning system to be more descriptive. Right now, PSVersion returns 6.0.0-alpha as a System.Management.Automation.SemanticVersion object (with Major, Minor, Patch, and Label properties), and we’ve also added a GitCommitId property to PSVersionTable that matches perfectly with tags on GitHub: https://github.com/powershell/powershell/tags

    Still, we can definitely continue to improve the semantic version implementation. You can track (and contribute to!) the discussion on these improvements here: https://github.com/PowerShell/PowerShell/issues/2354

    Thanks,
    Joey

    Justin King supported this idea  · 
  14. 222 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    22 comments  ·  PowerShell » Documentation  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King supported this idea  · 
  15. 4 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » Desired State Configuration (DSC)  ·  Flag idea as inappropriate…  ·  Admin →
    survey  ·  Mark Gray responded

    Justin,

    Thank you for your feedback! We recognize that this adds confusion to the deployment of the WMF 5.0 pull server and are looking into a solution.

    MarkG

    Justin King shared this idea  · 
  16. 24 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  PowerShell » Package Management  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King supported this idea  · 
  17. 12 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  PowerShell » Desired State Configuration (DSC)  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King commented  · 

    If you installed WMF5 over the top of preview edition (actually from what I've noticed even if you haven't) You need to manually update a package with:

    mofcomp $env:windir\\system32\\wbem\\DscCoreConfProv.mof

    This gets rid of the MI:12 error and makes everything quiet.

  18. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PowerShell » Desired State Configuration (DSC)  ·  Flag idea as inappropriate…  ·  Admin →
    investigating  ·  Mark Gray responded

    Justin,

    This behavior is common to all DSC resources, if I understand your issue correctly. If there are multiple versions of a module installed on your authoring system, you must specify the version that you intend to use in your configuration.

    What behavior are you expecting?

    MarkG

    Justin King shared this idea  · 
  19. 24 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  PowerShell » Desired State Configuration (DSC)  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King supported this idea  · 
  20. 4 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  PowerShell » PowerShell Engine  ·  Flag idea as inappropriate…  ·  Admin →
    Justin King commented  · 

    To me, at least, that's the point of a splat: "Get the variables you need".

    If a splat has to include only the explicit parameters in a function being called then it has no value beyond visual appeal. It doesn't "do" anything more:

    $splat - @{first = "1"
    second = "2"}

    function @splat

    vs

    function -first "1" -second "2"

    the ONLY thing you gain is something easier on the eyes so you aren't scrolling over when lines get really long.

    I'd like splatting to have a functional advantage.

    Heck maybe add a character to switch splatting from "explicit" so we both get what we want.

    Justin King commented  · 

    I apologize, this is poorly explained as I tangled a few ideas up.

    The problem is that there is no reason that a module should try to "force feed" undefined parameters from a splat and then end up in error.

    Allow it to simply pull matched parameters to it's defined parameters and move on. By allowing this I can make much more robust scripts that could potentially call multiple modules/functions all form a single common splat much like a scripting version of an .ini file. Yes, there is a "ValueFromRemainingArguments" parameter, but I can't guarantee anyone else's functions/cmdlets will use that setting which makes splatting unreliable for anything I don't write myself.

    There's no _reason_ to bomb out because it didn't recognize 100% of the variables. "Splatting" should be like splatting spaghetti on a wall .... you keep what sticks and let the rest fall off.

    Justin King commented  · 
    Justin King shared this idea  · 

Feedback and Knowledge Base