10 midyear resolutions for net admins

Now that we're heading into the second half of 2007, IT professionals are deciding what to make a priority between now and the end of the year -- as well as what to relegate to another burner because the back burner is still full.

IT pro Rick Vanover put together a list of resolutions awhile back aimed at helping net admins line up their priorities, effectively deal with the day-to-day issues, and plan and execute improvements. Here's a look at his goals, to help guide your progress during the final months of 2007.

#1: Develop security strategies for enterprise wireless networking

Our reluctance to embrace WLANs isn't going to make the issue go away. Now's the time to develop the protections at software and authentication levels, treating the office wireless network like the Internet from the security point of view.

IT professionals, users, and everyone in between can benefit from the wireless workplace. However, we need to accept that yes, our office now extends to Panera Bread. Our task is what can we do to make it secure?

#2: Put a moratorium on buzzwords and phrases

I dread hearing buzzwords and overused phrases as much as any of you. Here are my top three:

  • What can we do to move forward? How many times have you had meetings that involved too many nontechnical people and that concluded with this statement, which led to another meeting, which led to the same conclusion... but yet brought no results?
  • We don't have the bandwidth for ... Sorry to hear that. I guess this isn't us asking for such resources, but us telling you that we need such bandwidth. Whether it be staff resources, computing horsepower, or a fat pipe on the LAN, if the case and need are presented well, we need that bandwidth.
  • There needs to be some accountability... This is the worst. What's funny is that the people (management) who use this term don't really exact any accountability. It's a word that's more visible in the early stages of a project. However, it mysteriously stops popping up later on -- even when results warrant some accountability!

#3: Make a decision on leasing vs. purchasing IT equipment

Many organizations have blanket rules to lease or purchase IT equipment. A better approach may be a standard set of criteria that's applied to systems during planning to determine their scenario. Consider making a provisioning chart that will help determine whether a system is a candidate for leasing or direct purchase. This will lay forth specific criteria that, depending on your IT climate, will more clearly identify candidates for leasing. Here's a sample system provisioning chart to determine whether a lease is appropriate:

Of course, there are always many factors (like price and money!) that will influence how assets are procured. But a planned implementation with the end in mind (such as a lease return) can simplify the ongoing support of systems, especially as they become more complex.

#4: Avoid 5eCuR1TY & P@sSW0rD Ov3Rk1!!

What's worse than working with your own security requirements? Easy: It's dealing with another party that has security requirements at your level or higher. Sure we've got to be secure, but how many times has security locked out an authorized party? I've had it happen to mission-critical systems for silly things like a MAC address not authorized to participate on a network (in the case where a secondary system has a different MAC address).

Or how about this complex password requirement: 10 characters, including five special characters and mixed case for the remnants, and use of numbers. The password is: 8$4rR#Z@! . Don't bother counting, it is that way by design. (Yes, there is a space at the end of the password.) That was fun to troubleshoot after it was assigned.

Really, wouldn't investments in brute force detection, lowered bad password thresholds, and automated password reset utilities be worthwhile?

#5: Take a stand against the off-brand!

How much time have you spent working with inferior equipment? It can be viewed as pennywise and pound foolish to skimp on the equipment dollars. Using top-tier quality, branded equipment provides a superior support channel for drivers, issues, and spare parts. This applies to servers, networking equipment, PDAs, mobile phones, and even cables and tools.

Great efficiencies can be made by consolidating vendors of equipment (more on that later) as well as gaining a professional appearance by having the equipment represent an extension of the service provided by the technology. Besides, if the equipment fails, this is too easy a point to get burned on.

#6: Make sure you know what you're getting for the money

Price is always important, but remember to consider what you get. For example, on the server platform, analyze items like standard warranties as well as price-per-Gigahertz or -Gigabyte. Of course, we are all dealing with shrinking budgets as well as increased service responsibilities, so price is definitely a factor that will not go away. Sure, an easy solution is to buy up and overprovision systems at the start -- but that goes too far. A delicate balance needs to be met.

#7: Recognize that it's time to retire NT

You would be surprised how many installations still have Windows NT Server 4.0 systems running vendor -provided mission-critical applications, legacy Windows domain controllers, and government systems. Some organizations still have it as the standard.

Core support for NT has stopped, and driver support is soon to follow on server-class systems. You can live without service packs -- but not drivers.

#8: Reap the benefits of platform standardization

Let's all take a page from the Southwest Airlines playbook as a good example of how to keep overhead low. By having all equipment, operating systems, and software versions standardized, you'll realize savings. For example, consider the small to midsize enterprise that has a single server platform. This greatly enhances the internal support options. With a single server platform, you can:

  • More quickly build a server (standardized process).
  • Maintain fewer spare parts or systems (less unused inventory).
  • Reduce staff training knowledge requirements (reduced training expenses).
  • Build a higher competency on the standardized platform (better service).
  • Manage fewer baseline images, if used (less storage requirements).

For software title and version standardization, a big expense in compatibility testing is reduced to a single instance. Having lower overhead without compromising the result of the IT server is achievable for many organizations. It may be difficult to migrate to a standardized environment across the board (notebook, desktop, server, operating system, productivity suite, etc.), but the long-term benefits are habits of successful organizations. Even if a system is "over-provisioned" to meet the standard, that may be better than an array of oddball systems in the enterprise.

#9: Just say No!

Is it that tough? Well, sometimes it is. The common plight of the IT professional: Here is the functionality, now make it happen. And of course you don't get any more resources (money).

When using the No! card, be sure to cite business rules, fundamental standards, resource requirements, or other major obstacles to substantiate your decisions. It's difficult to judge when to pull the No! card. IT should use it if it simply can't do what's requested. The easy answer is to outsource or contract some help for the task, but even that can warrant the No! card. There's no "Easy Button" in IT, but the No! card can be fun.

#10: Address ownership roles

One of the biggest issues that arises in IT is ownership, specifically for an entire system that has shared use with vendors and many internal departments. For example, take a vendor-provided system that interfaces with operations and IT. Does the vendor own it? Does operations? Does IT? It is mission critical, but no one wants to touch it -- at least not when there is a problem.

When systems are incepted, there should be a clear chain of command. IT doesn't generally want to deal with operational topics, operations doesn't want to (and usually can't) deal with IT topics, and the vendor gets frustrated with all the IT groups and operational differences for a system. It's a good investment to get premium support from vendor-provided systems. This keeps IT groups in the best position by having their infrastructure and security topics met, operations dealing with the vendor for support, and the vendor having ultimate ownership of the system -- especially if there is an issue! One less fire to deal with.


Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.


There is no excuse for using simple passwords. Even junior admins should know how to circumvent BIOS, users and even root/admin passwords with the right hardware and software tools.


#7 is irrelevant.


You should not rely on other security measures so that you can have an easy to remember password like your kids name or your favorite sport team. The password that you provided isn't even that secure. Sure its random but the length is not long enough. When creating service accounts, I go for 17 or 20 digit password. You type it in once and your done with it. Store it away in your Blackberry password vault and your good.


Pass phrases are the only way to fly. They're easy to remember and with a little thought they're easy to type after you've done it a few times. Replacing common letters within the passphrase with symbols and numbers adds enough strength to make these simple phrases almost impossible to crack. I'll never say impossible... Example: 1 luv Fr@nk z@pp@! Contains numbers, letters, caps and symbols. Very difficult to crack. Why bother with password generators or outrageously difficult to remember passwords like the one cited in the original post? Of course this doesn't speak to applications or devices that have length limitations on their passwords but those are becoming less common nowadays. The author's post on this matter can be dangerous ground. The spirit of the post is OK but it could give a lazy administrator the ammunition to continue their lazy practices. One should be VERY careful forsaking security for simplicity. Just need to be creative.


I agree it's important and necessary to sometimes say "No" when a request isn't feasible, valuable to the company or even just plain possible. You agree, too, if you work in I.T. But exercise caution when using this option: the technology realm is full of users, managers, and even columnists who seem to feel that if I.T. doesn't do everything they ask, when they ask, then it is "out of touch," "stonewalling," or "an obstacle to business innovation." Peter Cochrane, for instance, is one such columnist and on more than one occasion has issued bitter rants about I.T. dinosaurs trying to stand in the way of his creative efforts. What really happened, I'm sure, is that he brought in some PDA and expected his I.T. department to interface it with the network/email, train him and support it for him, and upon being told it didn't meet security standards, wasn't compatible with the system, or some other logical rationale, decided to launch a tirade against stubborn, ignorant I.T. people, followed by childish columns envisioning the death of the corporate I.T. department and so forth. Certainly we can't bend over backwards to turn water into wine, but when using "No," make sure the user fully understands the reasoning, and discuss with their manager as well, so you don't have to deal with grumbling and rumors behind your back about "unhelpful I.T. staff." Make sure they understand when possible you're not saying no because you don't feel like complying with the request, and that while the I.T. department is there to keep systems running so users can do their jobs, there are also policies for the good of the company (e.g. security related for instance) which must be adhered to. Too many users seem to think ignoring or circumventing restrictions is OK and I.T. is just being a bunch of fun-spoiling "meanies" - perhaps they might feel differently if they understand those "meanies" could be out of a job if some user's home laptop was brought in and used on the company network then later found to be sharing copyrighted files out on a P2P network.


Yes, we can make that PDA work on the corporate network if you exchange it for a device on the supported device list in accordance with the IT purchasing and support policies, which entails manager buy-in and approval for the policy in the first place. I think the 'no' scenario can be greatly avoided with policy. Then there is a proper way for users to submit requests within guidelines acceptable to the various departments and management. Expectations are pre-defined. If the user circumvents policy, well they have their manager to tangle with then. If managers circumvent policy, well then there needs to be a manager meeting. Hopefully you have buy-in from the CEO. However, a procedure for reviewing and amending policy should be in place to avoid the H-bomb meetings. If upper management doesn't understand the importance of being a policy driven organization, then things will be difficult for IT. Also, users shouldn't direct requests to any staff member in IT. That's like trying to deal directly with your mechanic - we know we have to deal with the service writer/manager. There should be a similar role in IT. It can be as simple as an online form for hardware/software support or change requests. With any request that would seem to indicate a 'no' to IT, just do a study and assign a cost to overcoming the obstacles. So 'yes, if we invest in the necessary infrastructure to support a separate wireless LAN for non-official Palms at the cost of $xxxx' is better than a flat 'no'. And you never know, the requesting department might actually get funding for their idea, in which case IT gets the budget to do it correctly. Of course the time to do the cost analysis should be recorded in the IT task management system. I think IT staff should almost never use the word no. It's much better to refer a user to a process guided by a policy that they can navigate. Then if the request is approved by their manager, IT can bill for the time to analyze the request, and propose a solution/scope of work/cost analysis. Based on the solution, the manager may decide not to proceed, which means IT got paid to do the proposal, and didn't have to say no.

Editor's Picks