Best Practices to do software Patching and Software Deployment for bigger environment like 300 K computers

Question

Hi Friends,
i am looking for low level suggestions and a ppt/document etc too  , The client base is 300 k users and spread globally ( major in three different regions), the requirement is
1) methodology to do software patching, can we patch all in one go or do we have to divide as per region etc
2) How many clients can be targeted for software patching in one go ( ex : can we target 20K clients in one go ?), i know there are other factors too will play key role here like band width etc , but i am looking answers out of real time experience
3) What Methodology to follow when it comes to critical/emergency updates ?
Regards
Tanoj
OSLM ENGINEER - SCCM 2007 & 2012

Answer 1

There is no single best practice to patching, if there were then SCCM would ship preconfigured :).  As an example, Microsoft internally patches 300,000 workstations with 98% success in about a week according to their own podcast:
Microsoft Podcast
That said, I do follow a few rules when building a patching plan for a client.  Maybe you'll find it helpful:
Always use a "soak tier".  I forget where I first heard the term, but the idea is to have a good cross section of users get patches one or more weeks before your general deployment.  This will help identify potential issues with a patch
before it hits general release.  Make sure said group is NOT just the IT department ... we make the worst guinea pigs (we aren't known for closing out end of the month billing or posting legal documents).
When it comes to workstations, avoid needlessly phased deployment.  99% of the time, using local time zones is enough of a phased deployment.  Unlike servers with very particular boot and patching orders, workstations can simply be patched.  You
have enough collections in your environment ... so any new collection for patching should be justified.
Keep your ADR count down.  It's tempting to build a new ADR for everything (workstations, general servers, exchange servers, etc.).  Problem is that best practice also has you building a new SUG every time each ADR runs ... so you end up getting
flooded with update groups and that much more maintenance.  When possible simply use maintenance windows to break up patching schedules instead of using mostly duplicate ADRs that simply have separate start dates.
Use Orchastrator.  To me Orchastrator is to Software Updates what MDT is to Operating System Deployments:  effectively mandatory.  Even if you don't have complicated cluster updates you need to automate with SCO integrated to SCCM (there
are great examples on the web if you do), you can at the very least create run-books to manage that monthly maintenance you otherwise have to handle manually in SCCM (which is a lot IMO).  I have monthly run-books that delete expired updates from SUGs,
consoldate SUGs older than 6 months unto a single annual group, and even create new update packages (and update all ADRs to use them) every 6 months to keep a single repository from getting too large.
I'm sure others out there can give you more advice ... but that's my two cents.