No updates ran for a month don't tell our fed regulators I just cannot say enough about ensuring that systems are fully and properly patched as the first step in troubleshooting any issue. Lawrence Garvin, M. What I said was before trying to diagnose something perceived to be a "bug", make sure the "perceived bug" hasn't already been fixed by an update that has not been installed yet.
Or, let me put this another way: It's a total and absolute waste of time to try to diagnose a defect on a system that's not been fully patched. Install the patches THEN diagnose if still needed. But it is a somewhat sad state of affairs that patch administrators are oblivious to the fact that their patch management systems require an update -- even 20 months after the release of that update.
Tried what? Given that this thread is a year old, perhaps you should start a new one and properly describe your situation.
How to ask a question efficiently in a TechNet forum. Office Office Exchange Server. Not an IT pro? Internet Explorer TechCenter. Sign in. United States English. Ask a question. Quick access. Search related threads. The affect of this is of course any workstation on you network will have the patches scheduled install within 24 hours of you approve a patch.
The exact scheduled time is up to you, however the default time of am has served me well over the years and I have never come across any reason to change this time for the bulk of the workstations being patched.
I am not sure of the exact reason why 3am has been selected by Microsoft but I am sure they have there reasons…. Obvious question however is What happens if the computer is off at 3am? Good question… and i will talk about that more later. One of the problems scheduling all your workstations to automatically install patches at 3am is that sometimes computers are deliberately left on overnight to perform some automated task like batch processing.
If this applies to you then you need to create a separate GPO that you can apply to the non-reboot workstations. This of course means you have to manually kick off the patch process for these computers but this number should be at least manageable.
This no-reboot Group Policy will be targeted the same way the test group see above using a security group to control what computers get this setting.
For maximum control over when your servers are restarted as necessitated by an update installation, set Group Policy to Download the updates automatically and notify when they are ready to be installed, and then create a script that enables to you accept and install the updates and then restart the computer on demand.
Unlike your workstations you usually want to carefully plan and schedule the install of patches for servers in your environment.
Doing this will ensure that by default none of your server will automatically install patches and reboot allow the server admins to install the patches at a time of their choosing.
So you have been patching you servers manually for a while and now you wish there was some way to schedule the patching of them out of hours at a time of your choosing… the good new is that this is possible. To do this will will stager the patching of these server with Round 1 to Round N computer groups. Servers in the same round will be patches at the same time and therefore will generally not be dependant on other servers in the same round.
Breaking up the number of server into different rounds also means that if there was an issue with a patch then you will have not applied them to all your servers in your environment. Before we begin…. A Warning… You may remember that Group Policy refresh can take up to 2 hours approx. After this point if you decide to abort the scheduled update you might not have enough time to allow for AD propagation and Group Policy refresh for all your servers to stand down from the auto reboot that was scheduled.
The opposite is also true which means if you have not enabled these policies before 3 hours you want them to patch then they might not get scheduled in time…. In the example below the servers will be split into three rounds that will all patch at different times see table below. The table above shows that each round will have its own Group Policy Object that will be security filtered using a security groups.
They are also scheduled far enough apart that if something goes wrong with one round then you have enough time to un-schedule the next round of patch deployments see warning above. The reason you do this is that you only want to have these policies enabled when you want to schedule the update to your servers perhaps once a month.
Generally speaking automatic server patch can be scary, however if you know your environment well and you have successfully refined the manual patch process for your servers then stepping it up to automatic deployment. That being said I would still start small with only a few servers and work your way up before you start to push out patches to all your servers and you should always monitor the progress of the reboot of these servers to confirm there was no issues in applying the patches….
Note: If you think that the patch rollout will take multiple reboots note that you will need to manually initiate the second patch update and reboot to install any remaining patches… Generally you should know if this is required after you have deployed you test patches. Of course not all your computers in your environment are the same and as such you probably have different patching requirements for your computers based on their role. Therefore I have generally found that all computers fall under 3 main categories, Workstations, Terminal Servers and Servers.
Until Microsoft figures outs a way to mitigate this security risk you are just going to have to ensure that as many security holes on the software on the computers as possible Not to mention apply the recommend security template from Security Compliance Manager.
Therefore I recommend that you approve any required update to this group of computers on an aggressive timeline…. Terminal Servers a.
Citrix Servers… a. Remote Desktop Servers… a. Therefore you need to treat the Terminal Servers in your environment very similar to how you patch your other workstations and deploy any detected security updates. The time you take to approve test patches to your workstations and terminal servers is also is a major difference to your servers as often you need to get these patches out due a zero day vulnerability. In this case I recommend that you have a standing change control approval or understanding that all new patches will be automatically to the test computers as soon as they come in to start the testing process as quickly as possible.
This means when you get to the point to make a decision about when you are going to deploy an update you already have a really good idea what impact this is going to make on your environment when you deploy it to the rest of your computers.
Therefore you normally can take more time to test the patches to these servers. Having a separate top level WSUS target groups allows you to independently approve any patches that you might want to deploy to your servers. So after read the above section about patch approval groups you might not consider that you have to approve Microsoft Office patches to your servers and vice versa approve Exchange or SQL patches to your workstations… But you would be wrong.
The problem is that many times you will find that certain components of products may indeed be installed where you never expected them. A good example is the Exchange Management tools are sometimes installed on Workstations to allow IT Admins manage the exchange server. Another example would be having the a word or excel document viewer installed on a server as it was installed as part of another program installed on the server to view documentation.
Therefore you should regularly review what updates are being detected as needed and plan to also approve these patches during your next patch cycle….
Note: This setting is a configuration per client so if you configure workstations with 1mbit network speed they will try to all download at 1mbit at the same time. This allows the clients on the same network segment to share the parts of files they have already downloaded locally with other peers. This effectively means you only need to transfer the file once to a site but have it used many time thus saving a whole heap of WAN bandwidth. One of the interesting things about WSUS is that it requires no authentication for the client.
Therefore pretty much any server domain or non-domain joined can successfully register it self against any WSUS server. One advantage of this method of allowing any client to connect is that clients in a DMZ can be configured to report into a DMZ server that is hosted on the internal network. To enable this to happen however you do a few things:. Below is a collection of random other Group Policy Setting you should consider in your environment:.
However if it work as advertised then this will go a long way to ensure that computers that are patched even when turned off, largely negating the need to send a Wake On LAN to patch clients afterhours. It might tempt you to change the this setting to 1 hour. You will quickly find out that this may have the affect of bring the WSUS server to a grinding halt, as you would be loading the server with 22 time more the number of request.
If 10, clients report into the server every 22 hours and you set this policy to 1 hour that will increasing the load to be equivalent of , clients. But if you do make this update happen faster ensure you only apply it to a select number of clients. Allow Automatic Updates immediate installation — What you might not realise is that some patches that are released from Microsoft do not require the computer to be rebooted.
Typically Microsoft Office patches fall under this category. Therefore the Automatic Update agent has the option to install these non-reboot patches straight away without interrupting the user if they are not actually using the relevant program at the time. Obviously this speeds up greatly the deployment of these non-reboot patches and it also means that you will have fewer patches to install on reboot and thus make the whole patch process go all the more quicker….
No auto-restart for scheduled Automatic Updates installations — Loss of productivity is a bad thing, and while enabling this may lengthen the time it take for a patch to be deployed it is most often preferable to just let the install of the patch being delayed then to reboot the computer with the user logged in resulting it lost work.
Therefore if you apply a 3am reboot to all your clients in the world it will take 24 hours before all the clients have installed the update. This means it would reboot every computer in the world at exactly the same time at 3am local time to the server… Clearly this could be bad as someone on the other side of the world could be force rebooted in the middle of the day.
Many thanks to all involved. This looks to be exactly what I need. Putting that function in your PS profile on the central WSUS server — what does that do by putting that function in there? Wonder if I can have the script reference psexec.
How do I add to your profile. I get the same error as :. Even installed amps but it obviously did nothing :'.
Did you figure this out? I am not a power shell expert, I wish I was. The call operator executes in a child scope. Although running it with just the amp still causes errors. Notify me of new posts by email. This site uses Akismet to reduce spam. Learn how your comment data is processed. Email Address. Made with by Graphene Themes. Toggle navigation Please Work. Updates Running this command will "prime" the Windows Update engine to submit its most recent status on the next poll. Mats on February 7, at pm Reply I was just about to give up.
Thanks a lot! Renzo F. The script is correct, but it may cause confusion. Rudy on April 8, at pm Reply Is there a way to do this for machines without having to log in to each one? Jonathan B on April 30, at pm Reply How long does it take you to run that command.. For me, it seems to be timing out.. Hope that points you in the right direction. Lord Glacius on July 10, at am Reply Thank you for the suggestions. Do you have any suggestions further to help? Many thanks in advance.
Jason on May 14, at pm Reply I ran into this issue. Roman on May 3, at am Reply Awesome, that works! Ruhel on June 27, at am Reply typo — missing the c wuault….
IdolR on July 4, at pm Reply Finally! Worked a treat. Neil on August 16, at pm Reply Thanks you for the fix Robbie. Dave on September 12, at pm Reply This worked great! Thank you. Have been looking for this fix for many months.
JOE-B on September 27, at pm Reply This works for some but i wrote this batch file a couple years ago that works great too. Shuey on November 22, at pm Reply Thanks so much Robbie! Daniel on December 17, at pm Reply Thank you!! PhilipM on January 7, at pm Reply Great work, thank you for researching and posting! Dinusha on January 14, at pm Reply Hi Robbie and Others, Could you please give some advice or more information to edits profile. Ondrej on January 30, at pm Reply I just love this!!!
Finally something which works! David on February 12, at pm Reply Very good solution, thank you so much! Great job Man!!! Ha on April 15, at am Reply Thank a lot! Mat on April 22, at pm Reply slight amendment, so I didnt have to use psexec. Bhuvanjeet on June 3, at am Reply Thanks a lot! I was struggling for months over this. Really can help if you are managing big networks. Ubba on September 23, at am Reply Use batchpatch.
Thank you so much!!!! Steve Mason on September 3, at pm Reply This has been frustrating me for a while. Russ on November 17, at pm Reply Unfortunately, this joins the other , results in not working. Breno Carvalho on November 26, at pm Reply Great job man!!!!
0コメント