Im assuming most everyone here has SCCM in their environment, but do you use it for patch deployment? How do you use it / what is your policy? If not, why did you stick with WSUS? What is your environment like? Dont have to be super explicit with your answer, I am just curious how different everyone is. In my time as a consultant, I find that most companies and schools and government offices either dont know how to patch period, are afraid of SCCM, use it almost as a sort of novelty, or poke at it in a test bed but still continue with their WSUS practices.

Find the best Sccm Engineer resume samples to help you improve your own resume. Each resume is hand-picked from our large database of real resumes.

Never encountered a client that had it running efficiently when I joined, would say your observations are very common. I have been following this best practices guide: To summarize, patch groups software update packages are broken up by year to stay under the 1000 update per deployment rule: 2003-2010, 2011-2012, 2013, and 2014 2nd Wednesday of month ADR runs to create a new software update group package with all updates released within past 30 days. It automatically creates everything, but I have it set to come out disabled. A human can review the patches to determine if needed prior to enabling the deployment to a group of internal it testers. At end of week if all went well deployment is advertised to a 'patch tuesday test group' which contains power users from every department. The following week the updates are advertised to the entire company.

(servers excluded, as they are handled by a different group process) At the end of the year I manually roll patch tuesday groups packages into one yearly deployment (2014 in this case) • • • •. I only patch servers here and we've got 2 pre-prod environments and a single prod environment. The schedule looks like: Patch Tuesday happens. We have a meeting about the patches where everyone agrees/disagrees on the approval of patches. Corel Cocut Pro X4 Full With License Key For Google Earth Pro here. Usually runs less than an hour.

Later that week - I'll update my Update Groups. Usually it involves cleaning out superseded updates from the older groups and adding the new updates to the rollup groups. • All of 2014 (Add new updates, clean out superseded stuff) • 2003-2010 (clean out superseded stuff) • 2011-2013 (clean out superseded stuff) • All updates for Server2003 (Add new updates, clean out superseded stuff) • All updates for Server2008 (Add new updates, clean out superseded stuff) • All updates for Server2008R2 (Add new updates, clean out superseded stuff) • All updates for Server2012 (Add new updates, clean out superseded stuff) Right now we're in the middle of a 'getting systems caught up', so I've been deploying the 2 groups, 2003-2010 and 2011-2013, here and there as I can.

In a normal month I'll only be deploying the 2014 update group and the rollup as needed. Instead of using OSD and offline image servicing we've got a 'staging' collection that all new machines are added to and the rollup groups are deployed to that so they can get patched up after the OS is installed. It's a fight I've been fighting for quite a while:/ Back to schedule 8 days after Patch Tuesday: Pre-Prod environment #1 gets patched. 15 days after Patch Tuesday: Pre-Prod environment #2 gets patched.

25 days after Patch Tuesday: Prod environment gets patched. 2nd Saturday of the month after Prod systems get patched: Messaging systems get patched.

It's over-complicated and a result of managers with only the faintest understanding making decisions. That's the million dollar question - how do I do it LOL The team I work with, for intents and purposes, is me, my boss (technical lead), and another Senior Engineer. I got brought on as 'the SCCM guy' but lucky for me the other 2 guys have enough knowledge about it to help out. As far as the time consuming stuff goes, I just got a junior guy a few weeks ago and he's started working through the backlog of applications to be packaged. My best advice if you're in a position to start designing a solution - if the plan is to use SCCM fully, you'll want to make sure there are several people mostly dedicated to just that.

I've found that a pair of overworked people (this is IT afterall) can get the job done. If you want it done right, you'll need a team. 'A team of people for just one application?!'

Is usually the response, but if you call out everything - Updates/Antivirus management/Operating System Deployment/Application Deployment/Hardware Inventory/Software Inventory/Baseline Management/Client management - and evangelize SCCM not so much as just another application but more of a management layer, you'll get a better response from management when trying to staff. I was mostly asking how you would structure the update process if you had free reigns, instead of how the company does it now. You had expressed that you felt it was over complicated. I work with about 15 different SCCM environments off and on already.

Some smaller environments are managed by myself and another guy in occasional ad-hoc support haha. Then there are some bigger companies that I work with who have a whole SCCM team, which is really nice to see. Im just trying to get an idea of how everyone does things and why, and what they see wrong with it, to perhaps see if I can apply those perspectives to other environments. Usually the IT dept is either too small and way over worked, or too big, and somewhat lazy. (some skilled and some not) I prefer the lazy and smart because they seem to be happier and they work smarter rather than harder.

I usually breathe a sigh of relief when I find that the folks Im working with have requisite knowledge, otherwise it's throwing spaghetti at a wall for a week till we get moving. We're making progress to getting it my way by getting all systems caught up. Once they're caught up I'll maintain 5 Software Update Groups every month. 1 that contains this year's updates and the other 4 each will be dedicated to each server OS from 2003-2012.

The only new deployments that will occur each month will be the Current Year Software Updates group to each of the 2 pre-prod, the messaging systems, and the single prod maint window. A grand total of 8 deployments per month (we do 2 maint windows for each environment). That will significantly reduce the prep time for patching as well as simplify reporting. Then between me and my new junior guy we should be able to tackle the rest of the workload pretty regularly.

We're managing about 2,500 servers, ~50apps, and only a couple versions of Windows (no linux). Much more than that and I'd say we'd need another guy if I want to keep having any reddit time;) • • • • •. When I came in patching hadn't been done in over 2 years and I had never even touched SCCM 2007.

Currently I have one update list for all Security Patches for Servers. Patches are always 1 month behind to give a month to test on all dev/test boxes. Week 2 is Dev Boxes Week 3 is Phase 1 Week 4 is Phase 2 Week 1 is Phase 3 The phases are just a collections consisting of an equal amount of servers. Servers that need to be rebooted together I.e. A vApp or a cluster are in the same collection.

We have a manual phase which always have the patches presented and that's for specials servers, SQL, exchange, etc Workstations were updated by doing all security patches from 2010, then 2011, then 2012, then 2013, and now every two months we update workstations and they also are 1 month behind. Power users who test patches have patches applied in the months normal workstations don't get updates. We reboot about 120 servers weekly and 3500 workstations everyone other month. Required a lot of giving and very little taking but it's getting done. Can't wait for 2012 R2 which will make my life easier.

We have kind of a mixed bag. When I went to work for my company 3.5 years ago there was no patching being done period. Environment was XP, office and server 2003.

The patches regularly broke the custom GP applications when they were applied. While we still can't do XP or the few server 03 machines we have left. I started rolling out office 2010, windows 7, office 2010 from day one and applying security and critical patches to them.

Any others have to be approved. We are a 5 person IT department for 1300 people. We have a medium environment, 3800 desktops, and need to spread delivery of patches out so as to not impact all areas, or too many machines in the same area, at once. The best way I thought up to do that was to utilize maintenance windows on machine collections.

I created 5 maintenance window collections, say Monday 1AM - 4AM, and each gets a random group of machines. I used the SCCM machine guid to randomize distribution, so monday all machines with a SCCM guid ending in 0 or 9 gets updates.

I have an automatic deployment rule in SCCM that downloads and deploys the patch tuesday patches to a test group, in our case the entire IS department(they are a vocal group that run most of the applications our end users run so if problems arise i'll know). After a full week of our test group running the patches they get deployed out to all of the maintenance window collections. For this I have been using the Coretech software update manager. It makes creating the deployments quick and I know they are all always created the same way.

For System Center 2012 Configuration Manager SP1 and later: When you install more than one software update point at a primary site, use the same WSUS database for each software update point in the same Active Directory forest. Warriors Orochi 3 Keygen Mac. By sharing the same database you can significantly mitigate the client and network performance impact that can occur when clients switch to a new software update point. When a client switches to a new software update point that shares a database with the old software update point, a delta scan still occurs, but this scan is much smaller than it would be if the WSUS server had its own database. When you install WSUS 3.0, you can specify whether to use the default Internet Information Services (IIS) website or create a new custom WSUS 3.0 website. As a best practice, select Create a Windows Server Update Services 3.0 Web site so that IIS hosts the WSUS 3.0 services in a dedicated website instead of sharing the same website with other Configuration Manager site systems or other software applications. When you use a custom website for WSUS 3.0, WSUS configures port 8530 for HTTP and port 8531 for HTTPS. You must specify these port settings when you create the software update point for the site.

When you install WSUS 3.0, select the Store updates locally setting. When this setting is selected, the license terms that are associated with software updates are downloaded during the synchronization process and stored on the local hard drive for the WSUS server. When this setting is not selected, client computers might fail to scan for software updates compliance for software updates that have license terms. When you install the software update point, WSUS Synchronization Manager verifies that this setting is enabled every 60 minutes, by default. There is a limit of 1000 software updates for a software update deployment. When you create an automatic deployment rule, you specify whether to use an existing update group or create a new update group each time the rule runs.

When you specify criteria in an automatic deployment rule that results in multiple software updates and the rule runs on a recurring schedule, specify to create a new software update group each time the rule runs. This will prevent the deployment from surpassing the limit of 1000 software updates per deployment. Always use an existing software update group when you use an automatic deployment rule to deploy Endpoint Protection definition updates on a frequent basis. Otherwise, potentially hundreds of software update groups will be created over time. Typically, definition update publishers will set definition updates to expire when they are superseded by four newer updates. Therefore, the software update group that is created by the automatic deployment rule will never contain more than four definition updates for the publisher: one active and three superseded.