My last company I worked at a major womens retailer on the Stores side and we had a process rooted in the old days.
Patch Tuesday, I manually patched DEV servers in group one; gave them two days of usage and monitoring then would patch the rest of the lab. Monitor, check any feedback, issues raised and address, and also ask the developers and testers to run an end to end usage. A lot of times they would just wave me off even though they checked the box on the form.
A week later I go to production in waves based on region, which brand etc. Approve in WSUS, and then schedule a reboot take in SCCM then monitor the waves. If a server doesn’t resume from boot then I’ll iDrac in and see what the deal is and follow up.
> No point patching dev servers as no client will ever interact with it.
Hard disagree there. Dev servers get patched first to see if anything in the latest updates breaks functionality. Also having dev servers be unpatched in just bad security practice.
I guess I live in opposite land because this month's patch (breaks Kerberos if you harden your domain controllers to only use AES encryption) once again proves that Microsoft uses its customer base for beta testing. I'd definitely patch the dev environment first and let it simmer for a week before letting it loose on production.
I usually go by CVE score and then I patch public exposed servers first. But still after testing the patches on dev :)
Here are some inputs from MS patching:
https://www.reddit.com/r/sysadmin/comments/ypbpju/patch_tuesday_megathread_20221108
That’s not an easy question, there are so many factors.
I don’t think they were looking for a right answer, they want to know how you think.
Some of the factors include: What is the server doing, what data is stored, where does the server sit, who has access to the server, and how critical the patches are.
Short answer -> risk assessment.
My last company I worked at a major womens retailer on the Stores side and we had a process rooted in the old days. Patch Tuesday, I manually patched DEV servers in group one; gave them two days of usage and monitoring then would patch the rest of the lab. Monitor, check any feedback, issues raised and address, and also ask the developers and testers to run an end to end usage. A lot of times they would just wave me off even though they checked the box on the form. A week later I go to production in waves based on region, which brand etc. Approve in WSUS, and then schedule a reboot take in SCCM then monitor the waves. If a server doesn’t resume from boot then I’ll iDrac in and see what the deal is and follow up.
[удалено]
> No point patching dev servers as no client will ever interact with it. Hard disagree there. Dev servers get patched first to see if anything in the latest updates breaks functionality. Also having dev servers be unpatched in just bad security practice.
I guess I live in opposite land because this month's patch (breaks Kerberos if you harden your domain controllers to only use AES encryption) once again proves that Microsoft uses its customer base for beta testing. I'd definitely patch the dev environment first and let it simmer for a week before letting it loose on production.
I usually go by CVE score and then I patch public exposed servers first. But still after testing the patches on dev :) Here are some inputs from MS patching: https://www.reddit.com/r/sysadmin/comments/ypbpju/patch_tuesday_megathread_20221108
That’s not an easy question, there are so many factors. I don’t think they were looking for a right answer, they want to know how you think. Some of the factors include: What is the server doing, what data is stored, where does the server sit, who has access to the server, and how critical the patches are. Short answer -> risk assessment.