Microsoft

Microsoft Endpoint Configuration Manager Feedback

Suggestion box powered by UserVoice

Jeff

My feedback

  1. 411 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  18 comments  ·  Ideas » Client Deployment  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Jeff commented  · 

    I added my vote on here last week, but then I found a way to do this that worked REALLY well for me, and it seems its basically a Microsoft supported feature(how new I am unsure) that I had never heard of, and indeed it seems Microsoft should have communicated it better.

    So I'm just hoping this info is as useful to you guys as it was to me. I found this article:
    https://enterinit.com/sccm-client-package-for-osd-deployment/

    It defines a really short and sweet process:
    1. Create a package based on definition.
    2. Publisher Microsoft and Client Upgrade type, source folder pointed to a folder that's got a copy of the SCCM client installation bits.
    3. This creates a new custom package based on both the client installation bits and the silent installation program Microsoft uses for upgrade. When you deploy the program you will see your new deployment name is auto-appended with 'Configuration Manager Agent Silent Upgrade' signifying its got some built in mojo of its own.
    4. As you will see the program does NOT do /autoupgrade the standard way in the command line(which will check for and fail if there is not a maintenance window, even though you deployed it with 'Ignore Maintenance Window'), instead it's kicking autoupgrade mode on by means of the policy the client gets when these targets are in the Pre-Prod Client Upgrade collection - more on that below.
    5.One thing I need to add here - the targets need to be in your Pre-Prod Client Upgrade collection - the one defined in client upgrade tab of Hierarchy settings. If not, they will run this CCMSetup custom package, but without upgrade policy being 'allowed to upgrade', the ccmsetup wont upgrade them - they will reinstall at the same version, not the upgraded version.
    6. I deployed this package with Allow software installed outside the Maintenance Window, that let the package kick off without one, and the secret sauce of Client Upgrade Policy(via the Pre-Prod Client Upgrade collection) did the upgrade without checking for a maintenance window itself.
    7. Whole thing was very quick and easy. 5 minutes later, my first test machine with no maintenance window was upgraded to the latest SCCM version.
    8. I've since upgraded about 50 this way so far, and all successful. It works very well.

    Happy :)

    Microsoft, we still need this feature, and preferably, at least 2 more maintenance window types: Client Upgrade, and Application Deployment maintenance windows.

    Thanks.

  2. 379 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    35 comments  ·  Ideas » Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Jeff commented  · 

    There's really two issues to address here, if Microsoft is indeed a newer, better Microsoft under Satya.

    1. Yes please stop artificially limiting this feature. And that's really what needs to be done here. No one is asking for you for new code - this feature is available in other areas of the same product. It was simply a choice by MS to not allow for the use of this feature here.
    2. Which leads to the second issue. A 'Better Microsoft' is a Microsoft that gets off its ego driven high horse, and stops forcing certain options, or enforcing the limitation or removal of options, based on someone at Microsoft deciding how things should be done in some environment they do not understand. And environments outside of Microsoft offices are CLEARLY environments Microsoft does not understand. Stop trying to ENFORCE your idea of how work should be done, because it just harms your reputation every single time you do that. Make your products feature - rich, not feature - poor. Make them FLEXIBLE, not rigid. If you have a feature, make it widely available - instead of using it as a medium to tell people how things ought to work in some environment you clearly do not understand.

    Jeff supported this idea  · 
  3. 63 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Ideas » Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
    Jeff supported this idea  · 
  4. 75 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Ideas » Software Updates  ·  Flag idea as inappropriate…  ·  Admin →
    Jeff supported this idea  · 
  5. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Noted  ·  0 comments  ·  Ideas » PowerShell  ·  Flag idea as inappropriate…  ·  Admin →
    Jeff supported this idea  · 
  6. 416 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Noted  ·  15 comments  ·  Ideas » Documentation  ·  Flag idea as inappropriate…  ·  Admin →
    Jeff supported this idea  · 

Feedback and Knowledge Base