Posted by Shane Corellian on Wed, Jun 30, 2010
To continue from my last article...
The difference between an entry level computer support technician and a seasoned, trained and efficient Systems Administrator can be summed up with three simple words:
Understanding vs. Memorizing
In 1995 my boss (and technical mentor), Tom Mann, asked me to network the office computers (running Windows 3.11 for Workgroups). He purchased Novell NetWare 3.12 and told me get the network up within two weeks. I had never done such a thing and I asked him, "Um, how do I do that?" His response will be forever etched in my mind.
"Figure it out."
I went right out to Barnes and Noble and purchased Using Netware 3.12. I started reading at work. Remember that episode of The Simpsons where Homer wants to keep his job at the bowling alley so he decided to come up with a brilliant marketing scheme? You see him reading a book called Advanced Marketing which then fades into him reading another book called "Beginning Marketing" which then fades into him reading the dictionary and looking up the word "Marketing". Well, that was how I felt. I didn't understand a lot of the concepts so I had to read and re-read. I ended up buying several books to answer new questions that I had. I built the 3.12 server at least 6 times before going into production with our small office. I began to understand via simple cause and effect. I was eventually able to correctly predict behavior if I changed configuration settings on the server or clients.
By building that little network I began to truly understand the "problems" that would eventually pop up. When Beth complained that the printer wasn't "working" I was able to quickly deduce if the problem was caused by the server, the network, the local computer configuration or, in this case, the user Beth.
Your "Beth" doesn't have to understand how a document on her computer gets successfully sent to a printer. She just knows that if she hits the Print button then her document will print. That is fine. But if it is your job to make sure the users can print and access important files on the network then you had damn well better understand what's going on under the hood.
Remember, Google is your friend. It is inevitable that many Sys Admins have encountered your same computer problems and very likely that some of them have documented what went wrong, why, and what can be done to fix it.
Also, whatever you do, don't say you won't "fix" something just because you don't understand it. I think we often fall into this trap. About 8 years ago I remember data calls would come down from my corporate office. These calls were usually accompanied by some SQL code that we (the local administrators) would run against our respective databases. I started realizing that I was simply memorizing the queries but that I truly didn't have an understanding how they worked. I didn't know a Union from Join. Normalization? I could spell it but that was as deep as my understanding went.
Figure it out.
It's OK to not know the answer. Just figure it out. So, I began studying and using SQL. I frequently picked Adam's brain. I googled and bought some books. Once I jumped on it I realized how easy it actually was to understand. I was hooked.
The best way to understand how something works is simply to USE it.
Posted by Adam Ruth on Mon, Jun 28, 2010
One of the many tasks that system administrators deal with is managing one or more web sites. Over the course of a web site's life it will be moved, reconfigured, or have its structure changed. These changes can easily break links and the nature of the web is that there isn't a way to know a link is broken other than trying it. Not to mention any links to external pages that can break or decay over time, there isn't a way to be notified that a page no longer exists.
Enter Xenu Link Sleuth which is a fast no-frills link checker for Windows generously provided for free by German programmer Tilman Hausherr. I find it to be extremely helpful to periodically run on the web sites that I manage to make sure that nothing has broken. It's even more helpful to run after there have been some changes to the site, such as moving to a new host.
When you run it you will be presented with the starting point dialog.
Here you enter the URL you want to check. Xenu will check all files from this root down, so you can only check a subset if your site if you wish. You can also exclude some URLs from the check and set other options (how many threads to run, types of links to check, and even e-mail yourself a report when it's finished.)
That's it, once you run it you'll get a report back showing what's broken, if anything. Here's the report from the documentation for our new product PDQ Deploy.
The documentation contains some links to external resources, so I can know right away if any of them have broken and need to be repaired. If you've never run a link checker against one of your web sites you might be surprised at how much is broken. It's entropy at work, the system administrators ever-present friend.
I really like Xenu because it's both very fast and very thorough. It's got a very simple interface that doesn't get in your way so you can see what's important very quickly. The only thing that would be nice is if it had a command-line interface for running it as part of a script. But that's a small gripe for such a great tool.
Posted by Shawn Anderson on Fri, Jun 25, 2010
Slashdot reports on a Slate article discussing the massive two year drop in the desktop computer purchases.
Flight of Desktops, from Slates Farhad Manjoopulls numbers from Forrester research which show 48% of consumer households used desktops only two years ago (2008), while 2010 numbers are at 32%. Projections are currently at a 2015 desktop number of around 18%.
I am not surprised at the consumer numbers, but I do wonder what the corporate side looks like. Mr. Manjoo does hit on cloud computing, which while infant is still a viable solution.
I am very curious to see where systems management is heading for mobile computing. Managing desktops and laptops used to be the core of systems management, but that's not the case today.
It's exciting to see the number of businesses that are starting to jump into mobile computing by replacing blackberry's with iPhones or Androids.
Integrating these mobile computing devices is going to be fun from a systems management point of view.
As iPhones and other smart devices start to utilize corporate infrastructure such as file shares, printers, email, etc., we'll see a huge jump in managing these systems along with other servers, workstations, and peripheral devices. Common tasks, such as updating patches, reporting on which apps are used, and overall security will be a huge challenge.
Thanks to Mr. Manjoo (and Forrester Research). The next few years promise to be filled with challenges as these mobile devices are introduced into our business infrastructres.
Follow me on Twitter @ShawnAnderson
Posted by Adam Ruth on Wed, Jun 23, 2010
In a recent post entitled Security Administration - Tradeoffs I discussed the dangers of making things worse in an attempt to make them better. All changes have a downside, however small, and if you can't see a downside it means you haven't analyzed the change sufficiently.
This was brought into stark contract when I read this post on Eric Raymond's blog. The essentials are that some people are agitating to make AIS ship information encrypted and secure (AIS is information that ships broadcast about their position to other ships and shore receivers for collision avoidance.) The idea is that this information can be exploited by pirates and terrorists. While this is technically true, it doesn't take a very deep analysis to see what the downsides of this would be.
The biggest hole that I can see, and Eric points it out clearly, is that any system would need to have a way so that ships could still read the transmissions of surrounding transponders. What is to prevent this technology getting into the hands of pirates? A technology that by necessity must be installed on thousands of vessels, and access given to any number of individuals of varying degrees of trustworthiness? It doesn't seem like a huge problem for pirates to pose as normal ship operators who need the equipment, or failing that, to take control of a small vessel and torture the captain for his encryption keys. This change might thwart the casual, weekend pirating teens but not professionals.
It's a case seeing a problem (pirates using AIS information to track down targets) and posing a solution (prevent pirates from getting AIS information with encryption) without fully considering the real world weaknesses of encryption technology or the costs, not just in implementing the solution but in the fragility this would introduce to collision avoidance. I'm reminded of password complexity requirements which see a problem (easy to break passwords) and posing a solution (require really complex passwords) without fully considering how those complexity requirements will just cause people to store unmemorable passwords on paper or in files on computers.
Consider the following two passwords I just made up off the top of my head 7sne02mnw6slie$a and .@Flyingfoxes001. Both have the same length and one is very obviously easier to remember without much strain. The second password wouldn't fly in a lot of places, and may even drive a security officer to an early grave. In fact, I'm almost certain that even the first password isn't complex enough for a couple of places that I've worked. So which password is more secure? Let's see what my computer thinks.
Hmmmm, okay. Maybe my computer is stupid. Let me see what GMail has to say.
(first)
(second)
I know which password I'd rather use, and which I'd rather have my users go with (the password reset cost savings alone would be huge.) Still, some people's guts will tell them that the first password is clearly superior.
Another example. I recently got a new phone and I had to select a 4 digit PIN for customer service. As we should all know, 4 digits provide for 10,000 possible PINs. However there was a requirement that no two digits next to each other could be identical or consecutive, so 1274 is not a valid PIN. That simple requirement actually reduces the number of possible PINs by nearly two-thirds to 3,430. This may still be sufficient, but I'd be willing to bet that whomever created the requirement didn't consider this consequence.
No security system is ever fool-proof, particularly when the fool is the one designing the system.
Posted by Adam Ruth on Mon, Jun 21, 2010
Photo by Richard-G
Infoworld has a great article entitled 10 Tips for Boosting Network Performance that I found fascinating. Two tips in particular struck me, numbers 7 and 8. These address a problem that we ran into recently when setting up a virtual lab, that is disk speed. It was a real surprise to me just how much disk speed (RPM and bus throughput) affects the performance of virtual machines. It makes sense, once you understand the reasons behind it, but it was still quite shocking to have it bite me in the butt. It's tempting to try to save money with cheaper SATA drives and while there are times that's appropriate, a virtual server isn't one of those times.
The whole article, though, is full of some great ideas. Some of which you may be aware of, and some probably not as much. There should be something there for everyone to learn from.
While you're reading about network performance you may want to learn how to use software deployment to Unplug the Sneakernet.
Posted by Shawn Anderson on Fri, Jun 18, 2010
Adobe has patched Flash and in the coming weeks will also release a patch for its Reader product.
While deploying these patches to all your computers is relatively simple, obtaining the patch first requires you to enter into a distribution agreement with Adobe. It's fairly easy to do but sometimes a step-by-step is helpful.
First things first - the Adobe website is designed for those who wish to patch the system that they are using at the moment - something that you don't want to do if you are looking to install the patch to every one of your dozens, hundreds, or thousands of computers.
Go to www.adobe.com and select the Adobe Flash button. (If you want to deploy more than just Flash you can do so in a later step).
The next screen is the most important. It's here that you tell Adobe that your time is far too important to sneaker-net this deployment. Select the Distribute Flash Player link.
The next screen allows us to accept the Adobe distribution agreement. Every organization needs to fill this out. Even though Flash and Reader are no-cost products, each organization needs to have an agreement to obtain the products and patches.
The last screen for today's post allows you to select the product(s) that you wish to obtain. If you also need to grab the Adobe Reader patches then this is a good time to do so.
Fill out the form and submit it for Adobe approval. They advertise acceptance within a few business days but my experience is that they are much faster.
Fill out the rest of the form and submit. The ball is now in Adobe's court. You'll receive an acceptance email from them shortly (a couple of days at most).
It may be a crimp in your style to stop midstream, but that's how the game is played. Not to worry, Adobe is pretty fast at approving these requests. The email that you receive will provide your download link for the .exe and .msi files.
We invite you to use our free software deployment tool to deploy Adobe Flash. PDQ Deploy is in beta now and we hope to have the first full release in July 2010.
Follow me on Twitter
@ShawnAnderson
Posted by Shane Corellian on Wed, Jun 16, 2010
Photo by Jean-Michel Folon
It still amazes me how many system administrators don't feel the need to understand the under-pinnings of Systems Management. I push a button and software gets installed on a remote computer. I run an inventory scan and suddenly I have a list of installed software.
I'm constantly reminded of the Sidney Harris cartoon "Then a miracle occurs". How did that software get installed? Where does SCCM extract the list of installed software on each machine? How does Admin Arsenal know if a laptop has a smart-card reader?
If I have a prayer of performing any meaningful troubleshooting when problems occur, then it is essential to understand the How, Where, and What of the my environment.
You can, very quickly, determine if a person troubleshooting a problem has a good understanding of their environment. If they don't understand what's going on under the hood, then their troubleshooting amounts to little more than memorization. If "problem A" occurs, then "solution A" is the answer. "See, it's clearly written in this KB article." But what happens when the correct answer isn't, in fact, "solution A" ? What happens when the problem doesn't even have a description in the knowledge base?
I know, for example, that Tivoli retrieves its Installed Software list from two sources: A) Data stored in the "Uninstall" key of the registry; and B) Signature data where software names, publishers and versions are mapped using a file name and its corresponding file size.
If some software that I am expecting to see listed as being installed doesn't show up in an inventory report, then I should know exactly WHERE (on the target computer) that data is supposed to be found. I will be able, therefore, to troubleshoot more effectively. If I know HOW the scanned data is expected to move from the registry of the target computer to its ultimate entry in a database, then I can more effectively determine when and where any errors are occurring during transit.
My next few blog posts will be about some of the under-workings of common systems management tools.
Follow me on Twitter @ShaneCorellian
Posted by Adam Ruth on Mon, Jun 14, 2010
Photo by DraconianRain
Infoworld has an interesting piece talking about how IT infrastructure can become a house of cards. Most of the article is about applications that aren't being kept up-to-date with newer technologies such as Windows Vista and Windows 7. The ending paragraph sums up the author's opinion:
So what's the fix? Anyone involved in IT products or processes needs to stop tying ancient code and frameworks together with bailing wire and duct tape and take the time to do it right. Software vendors must bite the bullet and rewrite that 15-year-old application from scratch using modern platforms. It will require a sea change in Windows, with Microsoft jettisoning a wide range of internal hooks that exist solely to support Jurassic-era apps.
No, I don't expect it to happen either. But I can dream.
I think that the author makes some good points about how all of these older applications can cause havoc for system administrators, but I also think he's only got part of the picture. I've been on both sides of the fence and I can understand where the application vendors are coming from (most of the time, sometimes vendors are idiotic.)
Like it or not, the real world is an exercise in compromise. Whenever a vendor decides to change something in an application, whether it's adding a new feature or adding support for a new platform, it must come at the expense of something else. Either another feature is bypassed, the price of licensing or support goes up, or new bugs are introduced.
Why would a vendor choose not to add support for Windows 7 in a product? There are a number of reasons, and one of the factors to be considered is what kind of requirements can be pushed to the IT staffs of customers. If IT can use some bailing wire and glue to make it work then that gets factored into the cost/benefit analysis. It doesn't seem all that fair if you're in that IT staff, but then that's why you get paid the big bucks. A staff that has the ability to make these various applications work together has a great deal of value, since it opens up the organization to more possible vendors than they would have had.
It's like automatic vs. manual transmissions in a car. A manufacturer can choose to put in a manual transmission, which pushes the requirement for shifting down to the driver. There are plenty of reasons why a car may only come with a stick, and it's not unfair that you need to do your own shifting but rather a trade-off that you may not understand or agree with. It's usually easy to see the trade-off, though, because the performance and cost differences between manual and automatic transmissions are pretty well known.
A vendor's decision to not yet (or ever) support Windows 7 may seem stupid to us, but that's just because we don't get to see all of the myriad choices in the past that led up to that trade-off being taken. It still may be a stupid decision, but we can never be sure what we would be missing out on if the decision had gone the other way. Perhaps the time needed to support Windows 7 would have been so much due to poor architecture decisions in the past that it would have killed the product entirely, or at least some mission critical feature that you need. Is it better to deal without Windows 7 or the entire product?
Regardless of all of this, though, is the fact that administrators who can patch together the house of cards and keep it up will always be in high demand. There will always be the need for spit and bandages in any high-tech infrastructure, so we should be glad for the experience.
Need to deploy software to Windows 7 computers? Try Admin Arsenal for free.
Posted by Shane Corellian on Fri, Jun 11, 2010
In the course of our duties as Sys Admins I'm sure we've all "pushed the wrong button" a few times. If you haven't yet, you probably haven't been a Sys Admin very long.
About 10 years ago while working on a project which was wrought with political and technical paranoia I decided to prepare my own "Lysine Contingency" in the event that the political hailstorm became too much for me to handle. I first heard the term Lysine Contingency (LC) from Jurassic Park. I was always intrigued by the idea that Samuel L.'s character introduced. Certain destruction to the park's dinosaurs if a problem occurred that was simply unmanageable.
A Lysine Contingency is not your normal Change Management Rollback plan. It is basically you screaming "MISSION COMPROMISED! ABORT ABORT".
So, I want to offer some things I have learned about Lysine Contingency plans.
Points to consider:
- How was the change implemented?
- Were there multiple execution points such as Group Policy, Software Deployment, Login Scripts, Manual Installations, cron jobs or other local schedulers?
- Which execution point can be used to produce the greatest yield on your rollback? If you can hit 80% of your computers in 20 minutes with Software Deployment vs. 1 day with Group Policies then it's obvious where you should place your focus.
- Can the change be rolled back or otherwise mitigated without affecting other production systems, users or applications?
- Does your change require a reboot of the target system or application?
- What, if any, are the dependent services or applications?
- Will any data be lost? Are there other methods of removing the change that may take longer but save the data?
- Do you need the cooperation of any external entity?
- Are you allowed to deploy software but you're not allowed to modify GPOs? Are the GPOs part of your LC?
- The best Lysine solutions are the solutions that don't require anyone else but you. In a serious do-or-die situation you don't want to rely on the guy who's always on a smoking break or the lady who has more drama in her life than the evening lineup on Lifetime.
I want to stress: I'm not talking about proper Change Management procedures here. You should always have a rollback plan for major changes in your computing environment. I have had to rollback many changes to my various environments over the years, however, I have only had to enact a Lysine Contingency once and this came over two years AFTER the changes were introduced! Remember, the issues that often require your Lysine Contingency are just as easily going to be political as they are technical.
In the case I mentioned earlier I had my entire LC whittled down to one script. When the alarm sounded I knew that I had prepared for this scenario and there was no need to script some uninstallation routine or quickly write a new GPO or even to hold a meeting. This script set one flag which my verification utility read as "get the hell out of here!". With this flag, no more new verifications or installations would take place via GPO. The next section of my script deployed a Tivoli Software Package which immediately uninstalled the utility on all Windows computers. The next section added some log files to a central server. These files detailed the actions taken and would, ultimately, record the success rate of the Lysine Contingency.
Within 30 minutes the only traces of the original changes were contained in logs which I promptly gave to my manager. The Lysine Contingency went off without a hitch so that when the musical chairs music stopped I wasn't the one left standing.
Follow me on Twitter @ShaneCorellian
Posted by Adam Ruth on Wed, Jun 09, 2010
Photo by Lara604
I've just finished writing a new White Paper dealing with Source Control. As a software developer I've come to live and die by the quality of my source code control software and practices. I find, though, that system administrators don't use source control nearly as much, even though they deal with scads of text files that can be very effectively managed.
Source control is a very large topic, and it can get especially complex when dealing with various branching versions of a code base and many developers. However, this complexity just isn't necessary for system administrators. Most source control systems can be brought to bear in a single user, single brach scenario allowing typical system administrators to reap a large number of benefits quite easily. Hopefully this white paper will help people to disentangle the unnecessary complexity from the valuable bits so that they can get some value from their own source control set up.
If it's something of interest, please give it a read and please let me know if you think there's something that could be added or changed. I'd love to make it as relevant to the sysadmin community as possible.
Follow me on Twitter @AdamRuth
Posted by Shawn Anderson on Mon, Jun 07, 2010
We are pleased to announce the beta test for our newest product, PDQ Deploy. An advanced companion product, PDQ Deploy Pro, is tentatively scheduled to start beta in July 2010.
As we've learned over the past three years, most of our customers use Admin Arsenal to remotely install software to all of their computers. By far and away the most common enhancement requests center around software deployment. We've listened and we are excited about the results.
PDQ Deploy
PDQ Deploy provides a fast, easy way to meet your basic software deployment needs. And it's FREE! With PDQ Deploy you can:
Deploy MSI, MSP, MSU, EXE and Batch installers
- Use with or without Active Directory
Deploy to multiple computers at the same time
Use different authentication for different deployments
Save installations for future use
- Troubleshoot failed deployments
PDQ Deploy Pro
A more advanced and complete software deployment tool, PDQ Deploy Pro includes everything above, plus it allows you to:
Let's wrap up with a little more info.
Q: What's going to happen with Admin Arsenal, the product?
A: It's still here. It's supported and is a great way to enhance your IT toolset. For those who need software and hardware reporting, monitoring, and remote commands, Admin Arsenal is still here for you.
Q: What's different about software deployment in Admin Arsenal vs. PDQ Deploy?
A: A lot, actually. PDQ Deploy does not require Active Directory, and it's soley a tool for deploying software remotely. Since it only does deployment you will see future releases coming in shorter intervals.
Q: Why will PDQ Deploy be free?
A: A no-cost product allows us to get it into the hands of more people, faster.
Q: Why use PDQ Deploy Pro?
A: Some adminsitrators will be happy with the basic free version (PDQ Deploy), while others will see the benefit of scheduled deployments, multi-user ability, and more control over the configuration that PDQ Deploy Pro provides.
Q: When will these products be available?
A: We plan on starting beta testing of PDQ Deploy in June, 2010, and PDQ Deploy Pro in July.
Q: How can I participate in the beta?
A: You may request to become a PDQ Deploy beta tester here.
Follow me on Twitter
@ShawnAndersonJoin our
LinkedIn Software Deployment Group.
Posted by Shawn Anderson on Wed, Jun 02, 2010
About a month ago we wrote about using IEAK (Internet Explorer Administration Kit) to customize an IE 8 deployment file.
We wanted to be sure to include a post on deploying that customized file using Admin Arsenal.
We've included a step-by-step video to walk you through this deployment. IE8 ranks among the most commonly requested deployments by Admin Arsenal users. While the deployment is fairly straight forward, the customization of using IEAK is a bit more involved, and that perhaps has made some admins shy away.
So, as a companion post to the IEAK we deliver this post; Quickly Deploy Internet Explorer 8.
Note: We produce our videos at High Definition (720p). We suggest viewing at full screen.
Follow me on Twitter
@ShawnAndersonTry Admin Arsensel
free for 30-days.