Skip to main content
  • EN

Do you guys treat Veeam like the rest of your servers do do things differently?

I know a good portion of us have our Veeam servers Non Domain joined, which will require treating it a bit different.  I also have extremely long jobs run to tape sometimes so a manual process to reboot and patch is needed for myself. 

For most of my servers I use  a WSUS deployment I have scripted all of my servers to check in weekly and to download the updates at a specified time. I use flags so they won’t download the updates if a reboot is currently pending incase a previous month is missed. I then use VMware to scheduled reboot the hosts as It’s much more consistent this way and easy to disable. I can also generate reports for people to know when their apps will be down.

 

I was thinking about creating a script to preform the staged download of updates for my Veeam infrastructure, but we will see how time permitting my next while is. 

 

 

The script I use writes to a log file as well so I can see what updates were completed etc.  Because of that, I created another script to go scrape all of the log files from a specified group of servers.  This way after “patch Tuesday” I come to work, run my script to verify, and get one file that contains info on all the servers. For a while they had me manually logging into all the servers to verify so I shut that down pretty quick lol. 

 

We use a patch management system for our patching on all servers which can stage and prepare them.  Once ready then you say install and it installs them.  Once done you can reboot right away or schedule that with the system too.

The Veeam services we treat like all other systems because we send mass notifications to customers 10 days in advance of our patching window for the month (second Thursday of the month for patch Tuesday).

And, of course, take snapshots of the servers before patching...because...MS...

Great Advise, especially when you do not test these updates before installing them. We once had a terrible situation(s) on AWS. This was why we utilised WSUS in an upstream and downstream deployment because of the various regions involved. Afterward, we never had this issue as updates where being tested. 

The script I use writes to a log file as well so I can see what updates were completed etc.  Because of that, I created another script to go scrape all of the log files from a specified group of servers.  This way after “patch Tuesday” I come to work, run my script to verify, and get one file that contains info on all the servers. For a while they had me manually logging into all the servers to verify so I shut that down pretty quick lol. 

 

Looking forward to this script in the Automation Desk! Thank you 😊

Do you guys treat Veeam like the rest of your servers do do things differently?

I know a good portion of us have our Veeam servers Non Domain joined, which will require treating it a bit different.  I also have extremely long jobs run to tape sometimes so a manual process to reboot and patch is needed for myself. 

For most of my servers I use  a WSUS deployment I have scripted all of my servers to check in weekly and to download the updates at a specified time. I use flags so they won’t download the updates if a reboot is currently pending incase a previous month is missed. I then use VMware to scheduled reboot the hosts as It’s much more consistent this way and easy to disable. I can also generate reports for people to know when their apps will be down.

 

I was thinking about creating a script to preform the staged download of updates for my Veeam infrastructure, but we will see how time permitting my next while is. 

 

 

I tend to treat mine like I would any other part of my infrastructure! If anything, I am little slower to roll out updates to the backup servers since Microsoft, as of late, has a propensity to break things any time they update the OS.

Comment


Terms & Conditions