Download Squad had a great article recently listing 24 open-source, free tools for admins and technicians. I'm already sold on PuTTY, DBAN, Memtest86/Memtest86+ and 7-Zip, but there are some real gems out there that I hadn't even heard of.
WCD in particular scratches an itch I've had since giving up Norton ncd many a year ago and being spoiled by locate under *nix. You do need to know how to manually set a Path variable, but otherwise it works as advertised.
They did have one recommendation that is good, but I think you can do better... Visualization tools for data are invaluable in giving you a meaningful picture (literally) of what is and is not taking up space. They recommend a product called WinDirStat.
WinDirStat looks like a re-working of the same concept that was pioneered by SequoiaView: "Cushion Treemaps" to visualize data. The strength of this method is that it can show individual files and folders easily by size and type, and groups them together, but the weakness is that it lacks a true hierarchical view. It's also a very busy interface which makes it hard to tell usage in terms of rough percentages or amounts. Unfortunately, SequoiaView lacks any type of obvious licensing. You're probably safe to use it for any purpose, but it's not OSS. It's also rapidly aging, so WinDirStat looks like a great replacement.
There are times when it is the best tool for the job, but for a first-pass on a Windows system I prefer an application called Scanner, written buy a guy named Steffan Gerlach. The licensing is also unclear, but presumed freeware with the source supplied. This app has the strength of being able to show disk usage as a pie chart, with a hierarchical view. It lacks color coding by file and doesn't show individual files at all until you drill down into that directory. It is, however, nice and portable, so you can run it from a USB drive or a network share.
Between the two, you should have pair of complementary products that'll allow you to better manage your storage.
Showing posts with label Admin Basics. Show all posts
Showing posts with label Admin Basics. Show all posts
Friday, October 3, 2008
Monday, July 7, 2008
Admin Basics: One, Some, Many
As I write this post, we're on the eve of a date Windows admins are painfully familiar with: Patch Tuesday. Microsoft releases scheduled updates on the 2nd Tuesday of each month and because of this predictable schedule, Admins can take all the actions necessary to ensure that these patches are delivered in a timely manner. I'll defer talking about patch automation until a later date, but for now I'll take this opportunity to talk about my first Admin Basics topic: One, Some, Many.
When taking any action on a computer, there's always some risk that the change you make will break something or have other unintended consequences. You can try to predict what will happen, and you can have rigorous testing, but the chances are that something may fail and that something may not be what you test for. When making larger changes, the chances of something going wrong are greater than for a trivial change.
This leads me to the concept of One, Some and Many. This ties nicely into patching, but applies to all system changes.
You know you're going to make a change. You know it might have negative consequences. You test it as best you can-- how can you limit your risk beyond that?
Simple: Push the change to a single system first and test. If it works, then the chances are reasonable that the change had no negative effects. From there, pick a representative sample of other systems and push that change to them... and wait. If none of the users report problems, you can then push out to a larger group. If you're running a very large group of systems, you may have several groups of "many" for various reasons. If you have a smaller number of systems, you can probably safely patch them all in one big group of "many." If you start to get failures, you can go back to the previous stage and test more rigorously with the new failure information.
Why do this?
1. Vendors can't test every possible scenario, and often patches, updates, and configuration changes are poorly tested.
2. While you have a responsibility to test changes, you will have a hard time testing every scenario. It's efficient to have some users test as well.
3. The risk exposure is lower: If users experience problems in the "some" phase, you've limited the number of people having problems and enhanced your ability to troubleshoot quickly. If nothing else, you can back out their updates and go back to the previous testing step.
If you execute the One, Some, Many strategy you can still make changes in a reasonable period of time but lessen the risk. It's a very bad feeling when you make a sweeping change and your users start screaming. This will help you not be that guy.
When taking any action on a computer, there's always some risk that the change you make will break something or have other unintended consequences. You can try to predict what will happen, and you can have rigorous testing, but the chances are that something may fail and that something may not be what you test for. When making larger changes, the chances of something going wrong are greater than for a trivial change.
This leads me to the concept of One, Some and Many. This ties nicely into patching, but applies to all system changes.
You know you're going to make a change. You know it might have negative consequences. You test it as best you can-- how can you limit your risk beyond that?
Simple: Push the change to a single system first and test. If it works, then the chances are reasonable that the change had no negative effects. From there, pick a representative sample of other systems and push that change to them... and wait. If none of the users report problems, you can then push out to a larger group. If you're running a very large group of systems, you may have several groups of "many" for various reasons. If you have a smaller number of systems, you can probably safely patch them all in one big group of "many." If you start to get failures, you can go back to the previous stage and test more rigorously with the new failure information.
Why do this?
1. Vendors can't test every possible scenario, and often patches, updates, and configuration changes are poorly tested.
2. While you have a responsibility to test changes, you will have a hard time testing every scenario. It's efficient to have some users test as well.
3. The risk exposure is lower: If users experience problems in the "some" phase, you've limited the number of people having problems and enhanced your ability to troubleshoot quickly. If nothing else, you can back out their updates and go back to the previous testing step.
If you execute the One, Some, Many strategy you can still make changes in a reasonable period of time but lessen the risk. It's a very bad feeling when you make a sweeping change and your users start screaming. This will help you not be that guy.
Subscribe to:
Posts (Atom)
Posts
