- Windows OS
- SCCM
How to Deploy a Software Update to a Computer instead of a Collection.
How to Deploy a Software Update to a Computer instead of a Collection.
I would like to know if there is a way in SCCM to deploy an update directly to a computer instead of a collection.
In our environment , we have 3rd Party Patch Management, that will be replaced by SCCM for Budget reason.
with 3rd part product, the Analyst will select the Updates relevant to a specific computer and deploy the updates and select "Restart" the computer after Updates are done installing, even if they do not require restart..
So everything is manual as we have an Analyst who works out of business hours.
In SCCM, I can not find something similar to that...it seems like the Analyst will have to create a collection for every single computer (Since each computer maintenance window has different time) and deploy the updates, and if the Update does not require the reboot, then the computer will not be rebooted...which is not what the IT Dept policy says....
At work, they require Reboot of every computer after it is updated , even when it does not have any update Required, Analyst should reboot the computer.
How can I shape up this task , so that it can be the same as the task done with 3rd Party product.
Thank you
I would like to know if there is a way in SCCM to deploy an update directly to a computer instead of a collection.
In our environment , we have 3rd Party Patch Management, that will be replaced by SCCM for Budget reason.
with 3rd part product, the Analyst will select the Updates relevant to a specific computer and deploy the updates and select "Restart" the computer after Updates are done installing, even if they do not require restart..
So everything is manual as we have an Analyst who works out of business hours.
In SCCM, I can not find something similar to that...it seems like the Analyst will have to create a collection for every single computer (Since each computer maintenance window has different time) and deploy the updates, and if the Update does not require the reboot, then the computer will not be rebooted...which is not what the IT Dept policy says....
At work, they require Reboot of every computer after it is updated , even when it does not have any update Required, Analyst should reboot the computer.
How can I shape up this task , so that it can be the same as the task done with 3rd Party product.
Thank you
Make a single computer collection and deploy to that collection. Surely each computer is not that unique that you need one collection for each one.
You can deploy multiple updates to the computer and it will take only the ones needed. Rebooting is fairly simple too.
What is the current product used for patching? 100% functionality may not be available in SCCM.
You can deploy multiple updates to the computer and it will take only the ones needed. Rebooting is fairly simple too.
What is the current product used for patching? 100% functionality may not be available in SCCM.
Probably, it is better to create Collections by Maintenance window.
for instance if you have Server1, to Server10 that can be rebooted between 1am and 3 am on the same day, then put them in the same collection
do the same for all other servers, create collections based on Maintenance window... we'll have to create a lot of collections that way, but that 's the only way to do it in SCCM as it does not allow user to select Updates and deploy them directly to a computer.
I was referring to IBM patch Mgmt... Tivoli
Not sure if there is any SCCM Expert in EE who has experienced that in real world.. I would like to know if there is best practice on how to organize patching tasks in SCCM
for instance if you have Server1, to Server10 that can be rebooted between 1am and 3 am on the same day, then put them in the same collection
do the same for all other servers, create collections based on Maintenance window... we'll have to create a lot of collections that way, but that 's the only way to do it in SCCM as it does not allow user to select Updates and deploy them directly to a computer.
I was referring to IBM patch Mgmt... Tivoli
Not sure if there is any SCCM Expert in EE who has experienced that in real world.. I would like to know if there is best practice on how to organize patching tasks in SCCM
I can help make you one collection per each machine. In a single stroke.
The way you have described makes a single collection for 10 servers, not ten collections.
In all the places I have worked and supported (More than 100), people never told SCCM to reboot servers. Server owners rebooted servers and did the sanity check themselves.
Patching practices are pretty much similar for unix, Linux, Windows 2008, GMX, LNX etc etc.
This is a fairly detailed guide here. The website is highly regarded as well
http://www.systemcentercentral.com/patching-windows-servers-with-configmgr-2012/
The way you have described makes a single collection for 10 servers, not ten collections.
In all the places I have worked and supported (More than 100), people never told SCCM to reboot servers. Server owners rebooted servers and did the sanity check themselves.
Patching practices are pretty much similar for unix, Linux, Windows 2008, GMX, LNX etc etc.
This is a fairly detailed guide here. The website is highly regarded as well
http://www.systemcentercentral.com/patching-windows-servers-with-configmgr-2012/
Hi,
The whole point of CM is to group machines into bunches of similar types: email, SQL, Office workers etc.
MS call them collections for that reason. You cannot right-click a single machine and deploy an update because it's not the best way to behave. It's labour intensive and honestly, a bit silly. The tool is there to help you do things faster and easier and automatically.
The "old way" you did things with Tivoli was not a good way. Not at all.
You need to sit down and think how to do things better with the new tool - CM. Part of this is figuring out which Servers can reboot any time, and which must never reboot. Then you create collections to suite them. Use DIRECT membership if you have a known set that never change.
The link provided is a pretty good example and they have made the same journey - from one poor soul sat there patching by hand on a Friday night, to autmated setup and freeing Friday night for life in the outside!
Final word: With regards the edict "thou shalt always reboot" - that's plain wrong. On your home machine you can get patches quite often that install and update Office and will happily not need a reboot. Patch reboots need to be controlled by MS and the patch itself!
The place to block reboots (which I forgot in a previous reply) is in the deploy wizard - the "Suppress reboot on Servers or workstations" tick boxes.
Bottom line: stop doing mandatory reboots just because that's the way the previous product did it; That's like getting a new TV with a remote and getting up to change the channel every time.
Embrace the lazy IT guy inside - let the CM tool do the work.
M
The whole point of CM is to group machines into bunches of similar types: email, SQL, Office workers etc.
MS call them collections for that reason. You cannot right-click a single machine and deploy an update because it's not the best way to behave. It's labour intensive and honestly, a bit silly. The tool is there to help you do things faster and easier and automatically.
The "old way" you did things with Tivoli was not a good way. Not at all.
You need to sit down and think how to do things better with the new tool - CM. Part of this is figuring out which Servers can reboot any time, and which must never reboot. Then you create collections to suite them. Use DIRECT membership if you have a known set that never change.
The link provided is a pretty good example and they have made the same journey - from one poor soul sat there patching by hand on a Friday night, to autmated setup and freeing Friday night for life in the outside!
Final word: With regards the edict "thou shalt always reboot" - that's plain wrong. On your home machine you can get patches quite often that install and update Office and will happily not need a reboot. Patch reboots need to be controlled by MS and the patch itself!
The place to block reboots (which I forgot in a previous reply) is in the deploy wizard - the "Suppress reboot on Servers or workstations" tick boxes.
Bottom line: stop doing mandatory reboots just because that's the way the previous product did it; That's like getting a new TV with a remote and getting up to change the channel every time.
Embrace the lazy IT guy inside - let the CM tool do the work.
M
I agree with you about Collections when it comes to end users computers.
However for Servers, each server is different from the other.. it depends on the application they run
some servers, they require to stop gracefully some processes, and in order ... some have dependencies.. Reboot one server wait till it is back online then verify some processes are started then reboot the other server...
I hope you got the point ...
You would think Server owner should do that ...but since it is something that happens at 2am or 4 am in the morning, they assign this task to the Analyst that work during that time to do the patch and reboot...
With Tivoli, it is doable as you do one server at a time...
However for Servers, each server is different from the other.. it depends on the application they run
some servers, they require to stop gracefully some processes, and in order ... some have dependencies.. Reboot one server wait till it is back online then verify some processes are started then reboot the other server...
I hope you got the point ...
You would think Server owner should do that ...but since it is something that happens at 2am or 4 am in the morning, they assign this task to the Analyst that work during that time to do the patch and reboot...
With Tivoli, it is doable as you do one server at a time...
Hi,
Yes I see your point. Some servers (and even some workstations) need special handling. That's absoluletely fine if that's the case. Therefore you create a single collection and create a Direct member, even for one server. You can then treat it as a special case by:
a) creating unique Client settings, b) Create a collection variable c) Create a maintenance window
What I forgot to say above is that almost everything you do with CM revolves around your collections. If your collections are not well designed and efficient you face an up-hill battle and actually end up fighting both the product and yourself, clicking "update" expecting it to refresh faster. It won't. You speed CM up by following the rules, not by clicking more often!
Tivoli is not following modern management if you have to update servers one at a time. The new idea is to do things in parallel - run once, touch many.
The cases you mention are unique and require special handling. That's fine but they are not the norm. For the normal servers (95%) you deploy automated style. And definitely do not require some soul to be stood at 2am looking at a progress bar.
Yes I see your point. Some servers (and even some workstations) need special handling. That's absoluletely fine if that's the case. Therefore you create a single collection and create a Direct member, even for one server. You can then treat it as a special case by:
a) creating unique Client settings, b) Create a collection variable c) Create a maintenance window
What I forgot to say above is that almost everything you do with CM revolves around your collections. If your collections are not well designed and efficient you face an up-hill battle and actually end up fighting both the product and yourself, clicking "update" expecting it to refresh faster. It won't. You speed CM up by following the rules, not by clicking more often!
Tivoli is not following modern management if you have to update servers one at a time. The new idea is to do things in parallel - run once, touch many.
The cases you mention are unique and require special handling. That's fine but they are not the norm. For the normal servers (95%) you deploy automated style. And definitely do not require some soul to be stood at 2am looking at a progress bar.
If you can document and script the proper way to shutdown each server then you can place the script on the server itself in a fixed place
gracefulshutdown.bat
==================
net stop service1
net stop mssql
etc etc
shutdown -r -f -t 0
==============
And gracefully reboot by running the batch file.
If you don't know the steps and if the server owner does not know then there is a problem.
gracefulshutdown.bat
==================
net stop service1
net stop mssql
etc etc
shutdown -r -f -t 0
==============
And gracefully reboot by running the batch file.
If you don't know the steps and if the server owner does not know then there is a problem.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial