Point 1: maintenance windows - that should be part of any management framework you want to implement (ITIL or otherwise) - otherwise how can you report what availability you're able to provide to the business? And if you can't do that, it becomes hard to make a business case to get money to solve problems Point 2: do not use your servers for functions that a workstation should be doing (like browsing the web). Why do your servers even have access to the web in the first place? Shouldn't that be blocked at your firewall? Point 3: the above applies to small as well as large environments. I have thousands of servers, but even at home where I only have a half-dozen, it's the same
-----Original Message----- From: Matthew W. Ross [mailto:[email protected]] Sent: Saturday, 10 December 2011 6:28 AM To: NT System Admin Issues Subject: Re: things to include in a vm template? > Yes, that is a bad habit. Browser exploits are a huge threat vector> right > now. And yes, "big name" sites get hit all the time, too --> often through > ad networks or other outsourced content providers.> Especially if you're > downloading updates, which implies you're not> current on patches. The implication is correct. Updates usually require reboots, and administrators want reboots to be scheduled. I once did updates/reboots during the weekend, thinking nobody would care... but a Journalism class complained that they had a midnight deadline that I interrupted. It's like I can't reboot _ever_. Forsake any real outage. See: http://dilbert.com/strips/comic/1997-01-28/ > Also, if you find yourself going to the server room on a regular > basis[1], you're doing something wrong. Even when my desk was in the > same room as the server, I almost never touched the physical server > console. Remote management tools and RDP are the way to go. I'll run up the server room if something goes down and won't come back up. Otherwise, it's the same here. Happily, that's a rare occasion. > If that's your only option, then yes, that is absolutely what you > should do. You're moving the threat off your mission-critical server > and on to an ordinary workstation. I see where you are all coming from. It's probably different when you have a large number of servers, even more so when they are all running/balancing virtual machines. I have only a few, each doing different jobs. > [1] With the possible exception of changing backup media. Hurray for Disk to Disk to Offsite Disk backups! Sm:)e. --Matt Ross Ephrata School District ----- Original Message ----- From: Ben Scott [mailto:[email protected]] To: NT System Admin Issues [mailto:[email protected]] Sent: Fri, 09 Dec 2011 12:44:59 -0800 Subject: Re: things to include in a vm template? > On Fri, Dec 9, 2011 at 2:43 PM, Matthew W. Ross > <[email protected]> wrote: > > I have the bad habit of running to my server room, and using the > > server to download some update that is needed. > > Yes, that is a bad habit. Browser exploits are a huge threat vector > right now. And yes, "big name" sites get hit all the time, too -- > often through ad networks or other outsourced content providers. > Especially if you're downloading updates, which implies you're not > current on patches. > > Also, if you find yourself going to the server room on a regular > basis[1], you're doing something wrong. Even when my desk was in the > same room as the server, I almost never touched the physical server > console. Remote management tools and RDP are the way to go. > > > So, should I RDP back to my desktop, download the file, then move it > > back to the server? If this is the suggested practice, it is a little... > odd. Sm:)e. > > If that's your only option, then yes, that is absolutely what you > should do. You're moving the threat off your mission-critical server > and on to an ordinary workstation. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
