[Upgrading to System Center Configuration Manager (Current Branch) version 1802]

Hi,

What's everyone doing for the MDT & ADK versions ?  Will be have new ones that need installing at the same time as the SCCM 1802 upgrade ?  Or will we have to wait for Win10 1803 to be released before we see MDT/ADK updates..

-Rumpole

[How can I upgrade to System Center Configuration Manager Current Branch version 1702]

12 hours ago, anyweb said:

use the current version of MDT until the next release is released, as regards ADK 1703 don't use it with Server 2016 until it is fixed for the secure boot driver signing issue that occurs when you install it on Server 2016

Thanks, upgraded everything in a test environment and that combination of SCCM+ADK+MDT are all working fine.

 

[How can I upgrade to System Center Configuration Manager Current Branch version 1702]

What version of ADK & MDT are people using with this ?  I can see ADK v1703 looks suitable, but what about the MDT ?  MDT v8443 is the newest which came out in November 2016 but it was aligned with Windows 10 1607 and ConfigMgr 1606... Shouldn't we get a new MDT ?  Anyone know if there's compatibility issues with the latest ADK+SCCM+MDT version 8443 ?

-Rumpole

[Windows Updates - Advise on pre-prod / testing]

Thanks pembertj,

I've read a number of other posts on the topic & the key thing I've learned is that there can be more than one perfectly valid solution & that it really depends on the specific needs/wants of the business..

For us, we will do a variation of what I listed as 'option 3'. I will combine that with maintenance windows set on specific collections to control when the updates get installed.

[Windows Updates - Advise on pre-prod / testing]

Hi people,

 

I'm going through the process of setting up monthly windows updates in a new environment & I want to ensure that we have the capability to deploy updates to test collections before distributing to the production systems (both client OS's & server OS's). For background info, AnyWeb's step-by-step monthly updates guide has been followed (for the most part) for the configuration of the ADR's.

 

Essentially I want to be able to use ADR's to deploy updates to my 'test' collections, then allow a week or so for testing, then when I'm happy they haven't caused any issues, deploy them to the production machine collections.

 

I've given it some thought and have come up with 3 approaches. I've listed these below:

 

Option 1) Create 2 x ADR's for each product. Both ADR's will run once a month at more-or-less the same time. One ADR will target the 'test' collection and will have the deployment schedule availability set to 'ASAP'. The second ADR will target production, and will have the deployment schedule availability set to 7 days. Both will have deadlines of 14 days... This should allow me 7 days to test the updates with members of the test collection. If I don't like any of them for any reason, I can remove the production deployment or edit the updates in the group to remove any bad ones.

 

Option 2) Just use a single ADR for each product. The deployment will be targeted at production machines and the installation deadline will be 14 days. For this option to work, I would need to ensure full testing is done before the 14day auto-install kicks in. Any bad updates would have to be determined and removed before the 14days were up. It would also rely on users not being 'proactive' & going into the software centre & installing the updates themselves in advance of the deadline.

 

Option 3) Just use a single ADR for each product. The deployment will be targeted at a test machine collection and the installation deadline will be 14 days. I would then test the updates and ensure they all worked, removing any bad ones from the update group if they are found. Once happy with the testing, I would then manually change the target collection of the software update group that was created by the ADR to the production machine collection.

 

Thoughts anyone ? I'm hoping some people here can share what has worked for them in their production environments.

 

Cheers!

Rumpole

[using System Center 2012 Configuration Manager - Part 9. Deploying Monthly Updates]

Hi Anyweb,

 

Thanks for the great tutorials. They have been very helpful for me when planning (and now implementing) my SCCM 2012 deployment.

 

I had one question regarding this tutorial. In your post, you say we need to disable the original ADR after creating it. That's fine, and is what I've done, but I'm curious as to why we can't just delete the original ADR instead of disabling it ? Being a new install, I'm trying to keep the console as clean & clutter free as possible, so if I can delete the ADR instead of disabling it without any negative effect, it would be the preferred option.

 

I have read here someone asking the same question, however I would like to hear your opinion on the matter, if you have time

 

Thanks,

Rumpole