It's time for the bleeding edge to prepare to install IE 9 to all their company computers.
You need to decide if you want to push Internet Explorer 9 as-is (with no modifications) or if you want to push out a customized version (more on the customized version below).
To push as-is, which is the quickest method, download IE 9 here and save the file. Now locate and right-click on the downloaded file and select "Deploy with PDQ".
After giving a name to your installer click in the parameters field and enter the following:
Select "Create Installer" and the IE 9 as-is installer will be created. You can now use this installer to remotely deploy IE 9 to any or all of your computers.
Microsoft has provided the IEAK (Internet Explorer Administration Kit) which describes the process of creating a customized deployment.
I'll discuss in a later post a way to customize your deployment of IE 9. This is a great way to brand IE 9 to your company as well as providing a standard way of maintaining some structure to mulitple deployments.
One last note on this deployment; Microsoft is providing a new /update-no parameter. This allows you to push IE without each target attempting to run IE updates. It's a great idea, unfortunately my testing showed that this parameter failed. The installation wouldn't even begin. So I'm omitting it here. If I can't get it to work I'll open a partner ticket with Microsoft.
Last week I wrote about the Peter Blunt Approach to Systems Management Documentation. I would be remiss in my obligations as a certified Gen Xer and child of the 80's if I didn't call out Randy Quaid's greatest role: Cousin Eddie. So here you go: The 10 signs that Cousin Eddie runs the your company's network:
- Central backups stored on AOL 1.0a Trial floppy disks
- Outlook auto-archive action includes the sound: "Shitter was full!"
- Intel Inside sticker replaced with Fueled by Meister Bräu
- Server room doubles as fridge
- Two page UAT finally finished for software deployment of Office 6.0
- Clothes line strategically placed behind rack mounted servers
- HR cancels all Casual Fridays
- White elephant gift swap always includes hand-written coupon for "Somethin' Really Nice"
- Still waiting for network equipment from Sysco
- The best damn laptops Walgreens has to offer
Photo by thetechbuzz
Just about anyone can throw together a crappy top 10 list. But it takes a special level of uncreativeness to create a bottom 10 list. So, for that reason, I present the bottom 10 iPhone Apps.
3,235,168. Vuvuzela Mix-In
3,235,169. iEyeAIAyeArr (Artificially intelligent assistive device for the visually impaired pirate)
3,235,170. Spinning Beach Ball
3,235,171. Nuthin' But Ads
3,235,172. Broken Digital Clock (right only once a day, stuck in 24-hour display mode)
3,235,173. Arianne 5 Calculator
3,235,174. Playboy Text-Only Edition
3,235,175. The Fart App Catalog and Search Engine
3,235,176. Thelma and Louise turn-by-turn GPS
"Documentation for the sake of documentation" is another way of saying "documentation that no one will ever read".
Still, more organizations are stepping up to get docs written on their engineering, roll-outs, and standard operating procedures.
It's all about dotting the i's, j's and umlauts (¨), as Dwight Shrute would say.
I'll admit it; documentation is my weakest link as a Sys Admin. It is often thrown together at the last possible moment, and sorely lacks appropriate formatting and flow. Any ITIL or COBIT devotees who stumble upon my documentation usually react as though they are undergoing 6 simultaneous Myocardial Infarctions though, in reality, they are really closer to the aristocratic woman who faints when she hears Eliza shout "C'mon! Move your bloomin' arse!" in My Fair Lady.
That being said, my documentation is getting better the older I get. It's kinda moved from writing instructions on the back of my lunch napkin to "Go that way really fast. If something gets in your way, move". Hey, progress is progress.
There are some projects, however, where writing the documentation is more time intensive than actually engineering the solution being documented. This is only anecdotal, but it seems to me that the higher the doc word count the crappier the feature being documented. There has to be a happy medium.
So here is my take. IF your organization actually has people of interest who read and regularly reference the documentation, then it's worth it make the docs readable and understandable. If the opposite is true and your organization writes docs for the sheer pleasure of uploading them to some maze-hidden Sharepoint directory, then you may want to save your time and use an alternate form of documenting.
Try adopting the Peter Blunt System to documenation. For those of you (which will likely be everyone) who never saw Caddyshack II, let me give you the skinny. Peter Blunt (portrayed by Randy Quaid) is an attorney for Jack Hartounian. Jack wants to build low income housing close to the Country Club. The Country Club lawyers come in to flex their legal muscles to prevent the project. Enter, Peter Blunt.
(Here's a link, but be warned, there is some graphic language so it may not be work friendly - http://www.youtube.com/watch?v=4lURHNLrwtc )
Basically, get the job done. Don't try and bury me in paperwork. Don't make me write a free-trade deal. Expect documentaion and then get some Doc nerd who dreams in ITIL to come along and do the formatting and ask a few follow up questions. In fact, limit the number of questions your Doc guy can ask your Sys Admin or Developer. "You can ask Todd 8 questions. That's it." I guarantee you the questions asked will be very important vs. the cacophany of shrieks, wailings and gasps that WILL come if you don't put a ceiling on it.
Don't make me hire Peter Blunt to do it for you.
Photo by .reid.
The impending exhaustion of IPv4 addresses just got a step closer as APNIC (the Asia/Pacific organization in charge of IP address allocation) has issued their last addresses. Technically, they still have some addresses in reserve but these are for use only for organizations that need them within their IPv6 infrastructure and will only be doled out in very small chunks (/22 size chunks, or 1024 addresses).
I mentioned this back in February, how the top level manager of all things IP (ARIN) allocated their last blocks to APNIC. It was expected that APNIC would last until at least summer but they got used up much quicker than expected. It doesn't look good for the other regional registries, they will probably all be exhausted by the end of 2011.
So, what's a sys admin to do? Well, you can read through the excellent tutorial from Michael Pietroforte at 4sysops. It's pretty short and to the point and should put you at ease about the complexity of IPv6 (as it did for me).
The other thing you can do is wait. Not necessarily the most prudent thing to do in the world, but not the worst either. The programmer's procrastination mantra is "Why do today what you may not have to do tomorrow?" The truth of the matter, and the reason that IPv6 uptake has been slow, is very simple. It's an economic reality that people aren't going to move until the cost of not switching is higher than the cost of switching. An IPv6 migration costs time and money and that comes at the expense of other things that need to be done within a network. Future costs are still a bit nebulous at this time and so are hard to factor into ones decision making process.
It's not like Y2K where there was a set-in-stone drop-dead date and the non-tech world was fully aware of it and putting on pressure. Also, as has been shown in the past, there are technical solutions that will probably keep IPv4 alive (on life support) for a considerable time. As the costs of those solutions continue to climb, they will eventually meet the slowly dropping cost if IPv6. When they meet there may be a tipping point and some will be left scrambling. Even then, it may still be cheaper to wait and scramble. That's just one of the risks in living in a dynamic tech world.
So, from the trenches, where do you stand? What have you already done and what are you planning to do about IPv6?
This is a true story. When I was in 2nd grade, my teacher Ms. Westinskow. She asked all the students one day to tell the class what we each thought the defintion of "being rich" was. When it was my turn I said "Being able to eat all the Reese's Peanut Butter Cups that I want."
That truly was my definition of "Rich"
Well, welcome to the Systems Management realization of my dream.
Our customers are asking "Hey, what's the difference between PDQ Deploy Pro and AA Console?"
Answer: A LOT.
No? You aren't going to take my word for it. OK. I understand. Here's the deal. When we released AA Console (under the original name Admin Arsenal) back in 2007 we were stoked. We released the BASIC functionality that we had sought for Systems Management in the Windows workspace. Simple software deployment, inventory, basic monitoring and tie-ins to other Remote Control tools. Throw in a teaspoon of Remote Commands and we had ourselves a fantastic Sys Mgmt product at a great price.
Still, we all knew that some of the more advanced features available in our much more expensive competitors were there for a reason. We sought to bring those to you in Admin Arsenal 2.0. The problem is, however, that we became victims of 2nd System Syndrome. We tried to put too many features in our 2nd version. It became too cumbersome, too clunky and too unintuitive... and these are Tivoli certified engineers who are saying this.
We took a step back and looked at the features that our customers were REALLY using.
1) Software Deployment. This alone was, by far, the feature used the most. In some cases it was the exclusive feature used by our customers.
2) Inventory - This was used in many ways to augment Software Deployment. It was also used to generate reports of installed software.
3) Remote Commands - This was a feature that pretty much had to be demonstrated, highlighted and trumpeted before our customers seemed to say "Oh, hey. This feature rocks"
4) Remote Control (using Remote Desktop, VNC and other tools such as DameWare)
5) Monitoring. This one surprised us. Such a powerful little feature yet, so few of our customers seemed to be using it.
We made an executive decision. Instead of bundling all of these features in one product, let's offer an a la carte type solution. Those of you who want fast, dependable and intuitive Software Deployment could simply use the free version of PDQ Deploy. If you want extra features such as the ability to run multiple commands / installers (in one "deployment") or schedule deployments for more convenience (to end users) then you could make a move to PDQ Deploy Pro.
For those of you who wish to base your deployments off of Inventory data or those who want to understand the software/service configurations in your environments can use the soon-to-be-released PDQ Inventory. If you want to dig deeper and create customized reports or scan for additional Windows elements such as the Windows registry and the file system then you can move up to the PDQ Inventory Pro.
Our goal is to mesh PDQ Deploy Pro and PDQ Inventory Pro in such a way that you really have Reese's Peanut Cups. Chocolate and Peanut Butter.
You will be seeing blog posts, idle chatter and forum discussions around PDQ Deploy Pro AND PDQ Inventory.
We really want to hear what you think. What do you expect from your Hardware / Software inventory? This goes way beyond just listing what software is installed. This goes deep into the configuration of all of your Windows systems. What will make your job easier?
You can make a feature request on our forum here. You can send us an email at support at admin arsenal dot something or other.
Remember that Adobe likes you to reach out and touch them every year just to get the OK to deploy their free products within your company. It's pretty simple, though it can be frustrating to wait for approval from Adobe.
To avoid having your users install Adobe Reader themselves simply follow these steps to get access to the redistributable Adobe Reader and Adobe Flash.
Visit the Adobe distribution page and select "Apply to distribute Reader". (We're actually going to apply to distribute all their free products).
You'll need to fill out a form that pops up. We suggest that you apply to distribute all their free products (Reader, Flash, AIR, and Shockwave).
You'll need to fill out each section, but the entire form shouldn't take more than 3 minutes.
After submitting the form you'll receive an auto reply from Adobe that you will need to open and click a link to activate your application.
At this point you're pretty much done for the day. You need to wait for Adobe to approve your application. Once approved (they say less than three days) they'll email you a link to download the distributable applications.
Remember that it's usually a good idea to use the Adobe Wizard to create a customized Reader deployment.
Here are some older blog posts that will help you get moving along (after you've received approval from Adobe, of course).
Adobe maintains a regular schedule in patch versions so it's important to keep in touch with the company. During the registration process for Adobe products you're given the opportunity to opt into product emails. I suggest that you do so. It's important to know when security patches are available.
Deploy software using PDQ Deploy, our free deployment tool.
Photo by net_efekt
I spend most of my time working on virtual machines. Mostly VMWare but also occasionally Parallels and Hyper-V. I've learned a few things about getting the best performance out of these machines and here are my top recommendations.
Fast Hard Disks
Fast disks are critical to a well functioning virtual machine, particularly if you have several machines on the same computer.
Speedy Disk Drives
Coming in a close second is the need for speedy disk drives, especially if one computer is hosting several virutal machines.
Performant Persistent Storage
Following closely on is the need for high performance storage for the virtual machines, most critical when there is a plenitude of artificial computers operating within the confines of an individual physical device.
In all seriousness, I have found nothing that gives a greater boost to the performance of VMs than fast disk drives. It's also important to keep the VMs running on a separate physical disk from the operating system.
It's also very important to turn off as much of the UI pizzazz as possible. Windows 7 Aero themes just suck up the processor. VMs seem to lag furthest behind hardware in the graphics adapter department.
Other than that it's just a matter of tweaking the right balance of virtual proessors, RAM, and other software that may be running on the same system. A few extra percent of performance can be wrung out with some trial and error.
Any other tips you might have to share? Please post them in the comments.
I'm wrapping up a vacation week in San Diego. Since we have a bunch of kids our vacation included the obligatory visit(s) to Sea World.
I'm not besmirching Sea World. We used to live in San Diego and we've had season passes before. We've crawled over every single inch of that park. We've seen every show numerous times, which is why we were intrigued to learn that the Dolphin show was "new". It's called "Blue Horizons". The fact that they omitted the word "dolphins" should have been our first warning.
The show was, in a word; disappointing.
It had all the makings of a great Broadway production: Talented actors, acrobats, live birds, amazing costumes, and a huge pool of salt water. Sadly, the only thing missing from the new dolphin show was... dolphins.
If Blue Horizons was a movie, the dolphins would, at best, be supporting actors. At worst they would be uncredited cameos.
I think the producer of Cirque de la Mer had been given full reign over the show. Too bad he or she didn't consult with the dolphin handlers.
Gone are the jumping for rings and audience participation. Instead the audience was regaled by a lady dressed as a red parrot doing a 'sort of' ballet. You could just hear the muted groans when the male dancer came strutting out. (I think half the video recorders were turned off at that point.) Even my wife, who is undoubtedly artistic, gave me the 'oh-please-say-it-isn't-so' look. It was like watching Sir Laurence Olivier suddenly appear in a John Wayne movie.
OK, the Olivier comparison may seem harsh, but in its defense, there are two points in the show where the handlers are water skiing on the dolphins. Now that's actually part of the old show, but in this case it's just weird. You have a man, and then the woman, who are dramatically dancing around the stage in what appears to be a scene right out of the Nutcracker, and 30 seconds later they're water skiing on dolphins. Now, if you haven't seen dolphin water skiing, let me say that it isn't graceful. You have to do a sort of bull-legged balancing act. Bull-legged wobbling and ballet should never be spoken in the same sentence, let alone performed in the same production.
OK. So let's draw a parallel to our jobs as sys admins.
There is no parallel.
I just thought I'd forewarn you. Afterall, summer vacation is just around the corner.
You know the ol' diver's addage "Plan your dive and dive your plan"? Well these are truly wise words. Planning a project, getting the necessary buy off of said plan and then executing the plan's flawless execution is wonderful if it ever actually happened. It seems that, in every project, there comes at least one point when you just say "screw it" and just go Mujahideen on a particular problem.
Yep, every project I'm on seems to have at least that moment where I'm an adrenaline filled, attention starved, insecure DEA agent and the only thing that is standing between my lowered shoulder and self-validation is a locked door made of Balsa.
These types of "let's do it!" decisions don't necessarily fall under the "It's easier to get forgiveness than permission" umbrella as much as they fall under the "I could hit a sick, wobbling armadillo directly ahead or a station wagon carrying a family singing traveling songs on the way to Knott's Berry Farm slightly to my left and I made a judgement call" umbrella. (Oh c'mon, you know that that family is now in heaven having a better time than they would have had in Orange County)
Seriously though, these moments are often why we all have the jobs that we currently have: We have a history of making tough, game-time decisions that win the day. There are some things they simply can't teach in school and one of them is that gut-instinct that I have witnessed in a few co-workers. That one decision that turned what would have been an arduous two day rectal probe into a swift band-aid removal. These admins understand cause and effect, odds and what is at stake. They also generally have a distrust of bureaucracy anything typed in triplicate. Folks like Tom, Doug, Adam, Shawn, Layne, Teresa, Jake, James and Charles just to name a few. Thank you.
I remember an incident in November 2006 when a stupid move by a mediocre (at best) fellow admin caused a major disruption in service. I had just landed in Detroit when my phone started ringing. I am pleased to say that I kept my wits about me while so many seemed to be running around playing the blame game. I thought "we need to get all these systems functioning NOW". Screw blame. Screw CYA. I walked another admin though a few quick actions that, in less than four minutes, restored functionality to over 300 servers. (Honestly, experiences like this one led us to want to create the Remote Command feature in AA Console and the multiple "Actions" in PDQ Deploy Pro)
Anyway, after the business side was seen to, that is when I got pissed off. Over three hours into the conference call (I was now far away from the airport in Detroit and hanging in my brother's upstairs office so that my nephews wouldn't hear me swearing) we found the root of the problem and the fool who caused it. I say "fool" for one reason and one reason only: This person not only pushed the wrong button (hey, we've all done that) but he denied it and tried to cover it up. I used to like this guy but the amount of respect that I lost for him in the following few weeks was immense. He dug in for all the wrong reasons.
I love the saying "Unless it becomes a habit you'll never be fired for pushing the wrong button. You will, however, be fired for trying to cover it up".
Sometimes the best plan is to go off instinct and experience. When the game is on the line, give me the Admin who isn't afraid of his own shadow and see's the business need as more important than proper etiquette.
Most of our software is developed using Microsoft .NET and this causes an issue to comes up from time to time: What version to target. It's not such an easy issue to resolve, as it turns out.
There are several major versions that one can choose to support:
Version 1.0 and 1.1
These versions aren't supported any more by Microsoft development tools and aren't really on the table.
This is the oldest version supported by Microsoft's current tools. It supports all of the latest language features but is missing many of the libraries that modern applications might want to use. It's also the most widely distributed.
Version 2.0 Service Pack 1
This version includes a few additional libraries and fixes but strangely isn't as widely distributed as one might think. Confusingly, it is not included as part of Version 3.0 as its version number would imply. I blogged about this strange annoyance 2 years ago.
This is the first version to be included with Windows (Vista to be exact). It includes WPF (Windows Presentation Foundation) which is Microsoft's next generation GUI. It has a good installed base since it shipped with Vista. Microsoft dropped support for Windows 2000 with this version.
Version 3.5 Service Pack 1
Service Pack 1 followed pretty closely on the heels of 3.5 and is the version that ships with Windows 7 and Server 2008 R2 (more on that below). It can be considered WPF version 2.
The latest and greatest version is good for the bleeding edge, but its installed base is smaller than the others.
Microsoft has been shipping .NET with its servers for a few years now but it's not installed by default. That makes it necessary to treat servers similar to Windows XP in that it needs to be assumed that .NET isn't installed.
Microsoft has never deployed .NET through Windows Update to computers that don't already have it installed. As a developer who uses .NET I simply cannot understand this decision. It's less of a concern today since Vista and Windows 7 do get updated to Version 3.5 SP 1 (and XP if it has any version installed). Version 4 is still an optional update but that may change in the future.
So where does that leave us? Here are the broadstrokes that I've been following.
If you need to support Windows 2000 go with Version 2.0. Skip SP 1 if you can avoid it since it's currently living in a strange part of limbo.
Version 3.5 SP 1 is the best choice for everything else. It's been out for nearly 2.5 years and has an installed base close enough to 2.0 to make it worth it for the extra features.
Hold off on Vesion 4 for now unless it has something that is critical for the application and, if so, swear at Microsoft quietly under your breath for not making it an automatic update.
That's the high level developer's perspective on the issue. What's the system administrator point of view? Do you have a policy on installing and deploying .NET on your system?