Thursday, April 2, 2015

crack any wintel L2 interview

wipro tcs cts verizon FIS citiban microsoft.... etc inetrview questions

Day to day activities of wintel admin










Once you join a company to work as a system & network administrator,just like me, it requires ongoing day-to-day maintenance and improvement. In this document,  I’d like to share a dozen daily tasks that a successful system administrator needs to perform to keep his system and network running smoothly.
In this document:
 Using your management toolkits
 Fire fighting—end user support issues
 Servers Troubleshooting
 Performing regularly scheduled tape backups and verifying backups via test restores
 Testing server and desktop virus protection and updating virus data
 Verifying free disk space on your servers
 Keeping tabs on your servers with Event Viewer
 Verifying that all servers, applications, and databases are up and functional
 Verifying LAN and WAN connectivity
 Adding new hardware to your Windows server
 Documenting and sharing procedures
 Keeping your users working and happy
At this point, your Server network is up and running: Your servers with multi-operation system including windows series and Linux/UNIX are set up, the applications have been installed, the users are happily working away, and everything’s going well. You’re the new hero around the office. Now what?
Well, your job isn’t getting any easier. Day-to-day administration of your system and network will be every bit as challenging as the initial setup, but it will be just as much fun as well. This article will explore the daily tasks every system administrator should perform to ensure that his or her network stays up and purrs along efficiently. A good system administrator should make it a goal to perform all of these tasks daily, but all of us in the real-life administration game know that’s not always feasible. Just do your best, and customize these tasks to meet the needs of your network.
This article includes a concise 12-step approach to the daily in’s and out’s of System Administration. These are the daily dozen activities an administrator can expect to perform. Undoubtedly, you will be able to add your own daily activities to this “list” as you see fit.
  • STEP 1: THE MANAGEMENT TOOLKITS Every System administrator has a number of tools he or she uses each day to help keep the network humming along. Most of these tools are supplied with the operating system: User Manager for Domains, Server Manager, Event Viewer, Performance Monitor, and several others. But a few of these tools are physical tools such as real hardware tools, CD-ROM guides, books, even emergency telephone numbers. All of these are discussed in this section. Everyone has a different approach to running his or her network, but at least several of these wide-ranging tools are found in just about every admin’s list of frequently called-upon utilities and bag of tips, tricks, secrets, and general know-how.
    The first step is to gather all of your frequently used programs into one place on your administrative workstation. I have a folder on my Workstation’s desktop called “Toolkit”,This folder contains all of the programs and scripts I use on a daily basis while maintaining my network. I always leave the Toolkit window open, so these programs are within easy reach throughout the day. You’d be surprised how much time this saves over searching through the Start menu.
  • System administrative tools
    Such as Microsoft administrative packects.I have download and installed on my computer thus I can manager the windows servers most quickly and conveniently.So if you have installed the Microsoft windows series server,strongly recommand to find and download the relative toolkit from Microsoft site.
  • Third-party administration tools .
    In addition to the tools Microsoft supplies with Windows NT Server, administration utilities are available from several third parties.One that I swear by is Hyena, from Adkins Resource in Adkins, Texas . Hyena makes daily administration a lot easier for myself and my partners at work: It combines all the functionality of User Manager, Server Manager, and Event Viewer into one application, and it includes some Windows Explorer functions as well, such as NTFS permissions management for local and remote servers.
  • Real hardware tools
    I carry a limited set of real tools including two screwdrivers,a chip extractor and static energy discharger wristband. It’s safe to say that this type of toolkit is a necessary and required fixture for any System Administrator. I mean, any SA has to be at least able to connect a cable or open a workstation! If you’re gonna earn the lofty salaries paid to SAs, you gotta at least have the basics down.
  • Microsoft Knowladge Base and Internet,such as Google & BBS.
    These toolkit on internet almost can answer and resolve all of your question and problem. Good to use them you will get more benefits.
  • Some scripts written by yourself.
    I have write some script files with commands used frequently to manage and monitor the status of system and network.
  • Emergency Phone List.
    It is really very very important when you cannot resolve a emergency problem,or need to call somebody others or supplier,it will save many times.
    I always take with a name card with collection of emergency phone list.
  • STEP 2: END USER SUPPORT Every seasoned System Administrator has experienced this one: You’re at your desk, on the verge of solving that server performance problem that’s been nagging you for weeks, when the VP of Finance walks up and rather testily informs you that she is unable to print. Read hold everything! It’s a fire! Next thing you know, you’ve spent an hour removing and reinstalling the VP’s print drivers, undoing the damage her free online service software did to the PC’s network setup, and you can’t even remember your fantastic server performance solution.
    These "fires" are frustrating sometimes, but it’s key for System Administrators and engineers to remember that the end users are our raison d’etre. They are our customers: why we do what we do. Many of "them" also approve our budget. Even if you’re lucky enough to be insulated from the end users by a first-tier help desk, chances are that you’ll be called upon to provide escalation support at least once a day.
    Here are some techniques I’ve learned that help me dispatch fires as they come up and hopefully prevent new ones.
    When a support issue comes up, whether it’s bad print drivers or users unable to connect to the network because of a server crash, always jot down a little note to yourself before jumping up from your desk to fight the fire. Five times out of six, before I started doing this, I’d forget what I was working on when I got back to my desk after correcting the problem.
  • Remember your manners
    Even if you’re interrupted in the middle of a major breakthrough by what you may consider a minor problem, remember that your minor problem may be a major one for the user. Think back to the days when you were an end user, and how you felt if a technical support person blew you off because they considered your problem inconsequential. Nobody wants to be Dogbert the mean network administrator, and in the real world, brushing off end users’ problems can be severely career limiting. Keep your role as "doctor" in mind, and solve the problem quickly and professionally. You’ll get back to your breakthrough soon enough.
  • Educate the user
    If possible, explain to the user the steps you’re taking to solve their problem. An educated user is a happy user. Obviously some users will not be interested in this level of detail, preferring to be notified "when the darn thing works," but many users will appreciate this extra information. The same goes for first-level tech support people: If they learn how to solve the problem, chances are they won’t be escalating it to you next time. Also, many help desk staffers are grateful for the chance to observe more senior administrators. I started my IT career on a help desk, and every chance I got, I went into the server room and watched as the Windows NT administrators solved a problem. This exposure proved very valuable in later years.
  • Document your solutions
    After fighting a fire, it’s always a good policy to write an e-mail message or note to yourself explaining the problem and the solution, so you’ll have that knowledge available in case the problem crops up again. I can’t count the times I’ve been trying to solve a nagging support issue and got the feeling that I had dealt with the same thing several months before. Had I documented the problem and resolution, I wouldn’t have had to reinvent the wheel. If your company has a help desk application or a homegrown solutions database, enter the situation so that the information will be available next time. If the solution was particularly interesting or you think the issue will come up again, share the information with other members of your group, so they’ll be "in the know" if they’re tapped to solve the problem later.
    Like it or not, end user support is a big aspect of any System Administration career. If you have the right attitude and follow the proper procedures, you can learn a lot from those day-to-day fires.
  • STEP 3: SERVERS TROUBLESHOOTING Another big part of any System Administrator’s job is server troubleshooting. Despite what system would have you believe, IT doesn’t run trouble-free at all times, and external influences as well as internal software errors can cause problems with the system. When these issues come up, it’s key to remember that you, as the administrator, have many different tools at your disposal. I’ll touch on each of these briefly a little later.
    Right now, my coworkers and I are trying to narrow down the software villain that’s causing our 2000 server to crash every couple of weeks. A reality of  networking is that no matter how fault-tolerant you make your server hardware, adding redundant power supplies, RAID arrays, load-balanced network adapters, and so on, there’s usually a software bug that can bring all of that crashing down.
    When this particular server dies, user impact is very heavy, as the majority of users keep their data on this box. Every two weeks or so, with no regularity or predictability, the server’s network response time will begin to slow down, and soon it will quit servicing network users entirely. We’ll run into the server room, and the console is unresponsive. There’s nothing left to do but perform a dirty reboot. When the server comes back up, we immediately check the event logs and the Compaq hardware logs for errors, and yes, you guessed it: nothing. These are the server problems that try administrators’ souls and sometimes cause us to question our motives for going into such a crazy business. Luckily, the problem-solving tools are there. Here is how we are applying them on my network.
    Documentation
    One of the first things to ask when a new server problem crops up is whether anything changed on the server just before the problem began. Windows Server can be a fickle system, and even the most innocuous change has the potential to send it into a tailspin, sometimes for unexplained reasons. Keeping a detailed log of any and all changes to each server on your network can save you countless hours of troubleshooting. In my office, we have an Excel spreadsheet with separate sheets for each server, and we record the date, time, and nature of each change to the server, from installing new software to scheduled or unscheduled reboots, adding new drives or other hardware, and so on. These logs have proved very valuable in the past, when a change we made one week caused problems the next. Unfortunately, this technique hasn’t helped us with the current challenge, so we moved on to the process of elimination.
    Logical deduction and process of elimination
    At first glance, my group thought the server might be crashing because of a network problem. However, all the servers reside on a relatively low-usage 100 Mbps Ethernet segment, and none of the other boxes had any problems servicing users: the Exchange server and our main application server were humming along just fine. Also, we weren’t seeing an excessive number of collisions on that server’s port on the switch. Thus, a broadcast storm or other network problem was eliminated. Since then, we’ve tried to simplify the server’s configuration as much as possible: stopping and disabling nonessential third-party services we’ve added, moving print services off to another server, and watching closely to see whether these steps make any difference. It’s been less than two weeks since our last server crash, so the jury’s still out, but we’re hopeful that removing some of the load from the server will solve our problem. Then, we’ll slowly begin adding the third-party services back in and testing to see which of them might have caused the crashes.
    Microsoft TechNet
    I guess I can’t mention this resource enough. Microsoft TechNet and its online partner Support Online are fantastic resources for Windows IT professionals). Chances are if you’re having a strange problem with your server, someone else has had the same problem and reported it to Microsoft. When Microsoft identifies a problem, they issue a support article on it, and thousands of those articles are gathered together with white papers and other information on the TechNet CD each month. The access to service packs, late-breaking technical information, and upgrades can be priceless.
    Ironically, one of TechNet’s strengths is also one of its weaknesses. There is so much information that it can take most of an afternoon to search through all the articles that may come up on a search.  When you are using TechNet or Support Online, the more specific your query, the better.
    Support Online can be found at support.microsoft.com/support and offers access to the same Knowledge Base articles as a TechNet subscription does, but without many of TechNet’s other features .
    Internet support groups
    In my opinion, the best aspect of the Internet revolution is the ability it has given private citizens to gather together in clubs and user groups to share information and solve problems quickly. Whether it’s a car club sharing information about how to go faster at the racetrack or computer types trying to solve a problem, private parties now have much more information at their fingertips than they did just three or four years ago. Rather than waiting for a once-a-month user group meeting, Windows NT professionals have access to many ongoing support discussions, where they can bounce problems off other working administrators. Often, they can get solutions in minutes or hours instead of waiting days or weeks for an answer from Microsoft or another vendor.
    This ability to tap into the knowledge of hundreds or thousands of other administrators and ask "Any of you guys ever seen this one before?"
    has proved priceless on several occasions in my NT administration career. Someone halfway across the world may have solved the same problem you’re facing a month ago, or may be able to help you look at the problem in another way that might propel you toward a solution.
    Internet support groups come in two flavors: e-mail mailing lists and Web site–based solutions databases. It’s worth any IT professional’s time to join one of the mailing lists and search these sites for answers.
    Windows Server troubleshooting is definitely a challenging aspect of any System Administrator’s daily task list, but it can be made easier if you take advantage of all the tools that are available.
  • STEP 4: TAPE BACKUPS Backups as an essential element of any well-run system. However, backups are only as good as the media they’re recorded on. Even if your network has a bulletproof backup plan in place, you must verify that the proper files were actually backed up and make sure the backups are "good", that the files will be intact should you need to restore them.
  • Defining a backup schedule
    An important part of implementing any backup scheme for your system is defining a schedule and sticking to it. Depending on the size and complexity of your network, and the volatility of your users’ data, you may need to do nightly backups, or once a week might be sufficient. Once you determine how often backups will be run, you must ensure that this process happens each day or each week. Most third-party backup solutions have an automatic scheduling facility built in, and Windows native NTBACKUP program can be automated using command scheduling utility. Once this task is complete, backing up can become as easy as swapping a few tapes daily. However, even this can have its pitfalls: In my network, we rely on end users in field offices to change tapes each day and send the old tape out for offsite storage. On a couple of occasions, a user assigned that task got busy and forgot to put the new tape in after removing the old one. Luckily the server didn’t crash the day after one of these mishaps, as we would have had severe "data exposure", but the incidents made us nervous nonetheless back at the home office.
  • Checking backup logs
    Most backup utilities have logging built in that enables administrators to see which files were backed up, if any backups failed, and why they failed. Good network policy dictates that the administrator checks these logs each day to ensure that backups went the way they planned. This has been a requirement in every network I’ve worked with and has saved my administrative bacon more than once. If you determine that some files were not backed up, it is sometimes possible to grab a quick online backup, especially if the administrator gets into the office earlier than the users.
  • Performing test restores
    As I mentioned, backup sets are worthless unless the data contained on them is intact. As such, it’s a very good idea to restore some test data each day, to make sure that the files were not corrupted during the backup process. It’s best to do this with test files that are changed each day, but if you want to test-restore actual user data, restore it to a test server rather than its original location. Users have a funny way of getting annoyed when the Excel spreadsheet they were working on before lunch suddenly becomes yesterday’s version. In my network, we generally restore a few files each week to a test server that we’ve set up. Once we’re convinced that the backup is good, we can send a copy of it to our offsite storage facility. Offsite storage is very important to a successful network backup scheme, so don’t give it short shrift when budgeting for backups.
  • STEP 5: VIRUS PROTECTION Virus are one of the biggest headaches for System Administrators today. I know I’ve lived through my share of virus outbreaks, some worse than others, but none pleasant. The company I work for now didn’t even have a formal virus protection plan until the CEO’s PC got a virus via e-mail. He became understandably upset about this, and within two weeks, every desktop in the organization had some form of virus protection enabled, and the servers soon followed suit.
    While installing virus protection was a very important step (you wouldn’t believe what we found and cleaned!), testing the protection programs and keeping data files up to date is an ongoing challenge.
  • Testing your antivirus software
    The best way to see if your network is protected is to try and infect it. This is best accomplished in a very controlled environment, such as a test server that’s not connected to the network. While this sort of precaution is overkill for the vast majority of viruses out there, there are some real nasties to be found in the wild, and it’s much better to be safe than sorry when you’re dealing with live production data.
    Test documents infected with certain viruses can generally be found on the Internet, so that’s a good place to start when you’re looking to test your server’s safety net. Network Associates’ VirusScan product is a popular antivirus solution . Once you have the virus in hand, put the document on a disk, throw it in the server and open it, and see what happens. If your antivirus program is doing its job, it should catch the critter and clean the document. If it doesn’t, perhaps you’d better look into updating your software’s data files.
  • Updating data files
    Viruses are constantly changing: It seems as though a new one is being written and distributed nearly every week. Antivirus software vendors recognize this and thus update their programs with new "data files" periodically. These files give the antivirus software blueprints for the new viruses, so it is then able to catch and clean them. The real challenge, from a network administrator’s point of view, is figuring out how to distribute these updated data files across the network. Even on a 20-user network, visiting each desk is time consuming. In a 3,000-user WAN-connected network, desktop visits are an impossibility. Some vendors offer automatic, built-in data file upgrades with their desktop virus protection products, but you must update the files manually with others.
    We’re working on this challenge at my workplace right now. We’ve come up with three solutions:
    • Visiting each desktop as new data files come out. This is possible in our network, but we would really prefer to avoid it.
    • Distributing the updates via a batch file sent through e-mail. The users run this batch file, and it automatically copies the new data files down from a central network location. This is what we’ve been doing for a few months: It works, but success depends on the users remembering (or being willing) to run the batch file. As every System administrator knows, depending on the users to take care of themselves isn’t always the wisest option: When that VP’s computer becomes infected with a new virus because they forgot to run the batch file, it’ll be your hide, not theirs.
    • Configuring our network logon script to compare the dates on the users’ virus data files to the latest ones on the network, and copy down the latest files if the users’ data is out of date. This is a better solution than the one previously described, but it still has some pitfalls. For instance, we have a number of users who work from home offices with telephone lines running at a maximum of 56Kbps. Considering the reality of today’s phone lines, this figure is closer to 40–45Kbps. When these users log on after a virus data file update, they will have a pause in their logon script while the data files download, which will almost certainly generate a support call. Even so, we are leaning toward this option; for our network, it’s the best solution to the virus data file distribution challenge. Your mileage may vary, as no two networks are the same.
    • Centralizing virus protection
      If most vital data in your organization is kept on the network (and it should be!), then centralized virus protection on your servers is the most effective way to ensure that virus infections do not interrupt your company’s business operations. Be sure to install virus protection software on all of your file and application servers, your e-mail or groupware server, and your Internet gateway, if possible, and keep all of these locations updated with the latest data files. This sounds fairly straightforward, but you’d be surprised how many networks I’ve seen with last year’s virus data protecting the servers.
      Remember, your network’s virus protection is only effective if all workstations and servers have the product installed, and if they are kept up to date with the latest virus data files. It’s your job as the Windows NT administrator to ensure these tasks are completed. If you take care in keeping your protection tools healthy, your network can remain virus-free without too much effort.
  • STEP 6: FREE DISK SPACE In the world of Windows series Servers, few things can choke a server faster than running out of free disk space. Running low on free space can have all sorts of detrimental effects, ranging from poor performance due to lack of paging space to services actually shutting down for lack of resources. Some products, like Microsoft Exchange Server, will shut themselves down if disk space is getting low, to prevent permanent damage to the application’s database. Believe me, you don’t want to find out about low disk space when you start getting calls because nobody in the enterprise can get into their e-mail.
    In today’s environment of cheap storage, there really is no excuse for allowing servers to run low on disk space. As long as you stay on top of the storage situation, you will never be caught with your administrative pants down and end p in a crisis situation.
  • Successful storage techniques
    First, it’s very important to "right-size" your drive arrays when a new server is built. Determine approximately how much space the server will need when the network is fully functional, and then add fifty percent to account for future growth. This won’t keep you covered for long, though: In a fast-moving business, it might be a good idea to buy double the storage you think you need. Temper this interest with financial sense, however: Depending on your situation, it might be a better idea to hold off on purchasing more drives until you actually need them. You’ll likely pay less for the drives a year or two down the road than you’d pay right now.
    Second, keep track of your server’s disk space on at least a weekly basis. This can be done from the server console, via a batch file that connects network drives and executes DIR commands, or from your desktop with a third-party utility such as Hyena. At this point, it’s not necessarily important to note which directories are growing the fastest, although you’ll want to map out your directories on at least a monthly basis. More on that in Chapter 12.
    Third, it’s crucial that you have a plan to add more storage if and when you need it. Don’t assume that adding extra hard drives to your existing setup will be easy: Depending on your hardware, you may not be able to accomplish this without destroying the drive partitions and restoring the entire server from backups. It’s important to know just what will be involved before it’s crunch time and your server is working with less than 100 megabytes of free space while you try to figure out how to add another drive.
  • Secret: Don’t forget that at the enterprise or near-enterprise server environment, ordering a hard disk means that you must order it from your original server manufacturer. With high-end HP, Dells, and the like, it is simply not possible to trot down to your local clone computer shop and purchase appropriate drives on short notice. Thus, you are best advised to keep a supply of hard disks that are known to work on your server in the server room. Just in case!
  • More detail on weekly disk space monitoring
    As I mentioned, you have several ways to monitor your servers’ free disk space. The ‘built-in’ way to do this, though not necessarily the most efficient, is to follow this procedure:
    1. Go to each server’s console.
    2. Double-click My Computer, and then right-click the drive in question.
    3. Click Properties, and then record the figures given in the server’s Properties sheet.
    An alternative to this is to use a third-party utility. In the Hyena administration tool mentioned earlier, each server has a "Disk Space" object that can be double-clicked and inspected.
    At my office, one of my coworkers came up with a simple but effective way to monitor all of our servers’ disk space using a batch file. The process includes a FOR loop, which calls another batch file for each server listed in a specific text file. The second batch file then connects to the root of each drive on those servers and performs a DIR command, directing the output to another text file that we inspect to get the actual free space readings. It’s rather elegant, actually, for a home-grown solution.
    Whether you choose to use the built-in NT tools, adopt a third-party solution, or "roll your own" free space utility, definitely keep an eye on your servers’ disks, and don’t let them fill up. In my career, I’ve been through a couple of "disk full" situations, and neither of them was very pleasant. Luckily, this type of problem is easily avoided. Each week, spend a few minutes with your hard disks; you’ll be glad you did.
  • STEP 7: EVENT LOGS
    When Microsoft designed Windows NT, they included a tool that is an essential part of the operating system: event logging. This logging, together with the Event Viewer, which enables administrators to inspect the logs generated, can tell Windows NT professionals exactly what has taken place on their servers. This kind of detail can prove very valuable if the server starts having problems; more often than not, a server problem has a reasonable explanation, and that explanation is often found in the event logs. Event logging isn’t limited to the operating system. Applications that are designed for Windows NT bring with them their own event sources and IDs. Also, security logging takes place when the server is a domain controller or when you have specified that certain actions, such as file accesses, be audited for later inspection.
    Before I get too much farther into event logging, a discussion of the types of events and their characteristics is in order.
    Windows NT series Server events come in five flavors:
    • Information. These events generally are recorded when a significant but successful event happens on your Server; a service starts successfully, for example. You will see several of these events each time a server is booted, as the services start themselves up. Information events are marked in the Event Viewer with a blue circle containing an "I".
    • Warning. These events are recorded when something happens on the server that may not be significant now but could spell trouble later. Low disk space is a good example of a situation that could cause a Warning event .Warning events are recognized because they appear next to a yellow circle with an exclamation point inside.
    • Error. This indicates that a serious problem has occurred on the server that could hamper its performance. Error events are most commonly generated when services fail to start, but they can be associated with such serious events as hard drive failures in a RAID array, or worse. Error events are marked with a red stop sign.
    • Success Audit. These auditing events are recorded in the Security log when a successful security event takes place, such as a user logging on successfully or gaining access to a file or directory that is marked for auditing. The Success Audit’s icon is a yellow key.
    • Failure Audits. These are generated when a user is unable to log on, or when the user attempts to access a file, directory, or privilege he or she does not have access to. Failure audits are marked with a gray padlock.
    Windows NT series server events also contain several attributes, explained in.
    At my business, checking event logs is a weekly task, unless something seems to be going wrong with one of the servers. In that case, we go right to the logs to look for information on any possible problems.
    One thing that’s very important to remember about Event Viewer is that just because a Warning or Error event doesn’t sound too serious, or because you don’t know what it is, you shouldn’t just clear the log and ignore the event. Sometimes these "unknown" events can be precursors to a major system problem. If the error’s content or cause isn’t clear from the information in the event log, record the Event ID and jump into TechNet or Support Online to query on that ID. Often, these confusing events are caused by bugs in software or the operating system, and eight times out of ten, I’ve found a solution by searching TechNet and finding references to service packs or hotfixes that correct these strange events. On another occasion, my cohorts and I couldn’t identify the cause of a periodic serious error that was recorded in our event logs. After searching TechNet, we were able to determine that is was a precursor to a major SCSI device failure, and we were able to replace the failing device before it took down the server.
    In short, Event Viewer is a tremendously powerful tool for Windows IT professionals: The event logs are like a continuous record of your server’s health, with possible problems recorded in real time throughout the day. By making proper use of Event Viewer, you can prevent server and network problems from rearing their ugly heads. Even if these challenges do get the best of your server, Event Viewer can assist you in diagnosing and correcting the problem.
  • STEP 8: VERIFICATION OF SERVERS AND APPLICATIONS This task should be first and foremost on each System Administrator’s morning checklist. When you get into the office, take a few minutes to check out all the servers, applications, and databases. If they’re not working properly, it’s a lot better for you to find out about it before too many users get into the office than for your phone to start ringing off the hook while you sit in clueless bliss drinking your coffee. Also, if your schedule allows it, try to get into the office at least a half hour before the majority of the users. This way, if there is a problem, you have a little cushion of time to try to fix it. Even in 7 × 24 shops, most people still work 8 to 5, so getting in at 7:30 or earlier will help lower your stress level if one of your servers decides to go on vacation overnight.
  • First: Check on the servers and services
    Many server hardware products come with Simple Network Management Protocol (SNMP)–based remote management tools that can tell you at a glance which boxes are running and which are not. Although these tools are good for ensuring that the hardware is on and the operating system (networking) is functional, they don’t really tell you anything about the services on the server. It is certainly possible for a Primary Domain Controller to be up and running, but if the Netlogon service has stopped, ain’t nobody logging on from nowhere. Thus, it’s a good idea to look at the actual services on each server using Server Manager or your favorite third-party utility . This process takes a little while, but it definitely pays for itself in the long run. For instance, someday it could save you from having to explain to the boss why you didn’t check to make sure the Exchange Information Store was running on your Exchange server because your management tool said the machine was up.
    If you do discover a problem during your morning check, now’s the time to fix it, before many more users come into the office and start hammering on the systems.
  • Second: Check applications and databases
    After you’re convinced that your servers are up and healthy and the services are running, the next step is to actually log onto each application and do some test operations to make sure the apps themselves are working properly. This operation doesn’t have to be elaborate; a simple test query or two will do, but every Windows NT administrator should at least have the access and the know-how to log on and test each application on his or her servers. At my office, we have four main applications that reside on our NT servers, and we try to test them out each morning as soon as we get in. If we find something wrong and it looks like the server itself is up and running, we can report the problem to the appropriate applications group for resolution.
  • STEP 9: VERIFICATION OF LAN AND WAN CONNECTIVITY.
    Once you’re satisfied that your servers and applications are running and ready for the users, the next step in a System administrator’s daily checklist is to make sure everybody on the network is talking. This can be accomplished in a couple of ways, depending on the size of your network and the tools at your disposal. If you use an SNMP network management system like HP OpenView, Tivoli NetView, or Computer Associates Unicenter TNG, your SNMP console will tell you in an instant whether network links are up or down. However, if you’re in a smaller organization that didn’t budget for these rather expensive tools, you can still easily verify whether your network is intact each day. It’s a fairly simple task to write a batch file that uses the TCP/IP ping utility to attempt to reach all servers and network devices on your LAN and WAN and then write its results to a text file that’s available for your inspection. If you’re still using IPX exclusively and do not have TCP/IP running on your networks, you can write a routine that connects to remote machines via RPC calls, such as attempting to map a drive on the remote machine. A TCP/IP ping batch file might look something like this: 
    REM Testing network connectivity on LAN and WAN
ping server1 > conntest.txt
ping server2 > conntest.txt
ping wan1server2 > conntest.txt
ping wan2server1 > conntest.txt
end
    Once you have your text file available, you can inspect it and look for ping timeouts and excessive turnaround times that might indicate a problem with your network. In fact, it’s a good idea to automate this process with command so that you can schedule the connectivity test batch file to run a few minutes before you get into the office. That way, the results will be available when you arrive, and you can take action if necessary.
    This method is the way we monitor connectivity at my office, and while it’s not as fancy as some of the network management tools, it is effective and gives us what we need and enables us to make sure our users in faraway branch offices stay as connected as the folks in the home office.
    Secret: If you need a slightly more sophisticated approach than the "home grown" variety displayed previously, you should consider Ping Plotter, a low-cost shareware application from Richard Ness at Nessoft (www.nessoft.com). Not only does this application test ping connectivity, but it also enables you to observe ping performance across several WAN hops. The hop path is even mapped for you! MCSE consultant-types typically use this tool for testing telco/WAN performance. That is to say that Ping Plotter enables you to test the links and down the food chain on your WAN. This ultimately enables you to answer your questions regarding the subscribed bandwidth the telco sold you and the performance that you are actually enjoying. Important questions indeed to get answers to, might I say, on a daily basis.
    Tool like Ping Plotter are also great for keeping a green machine awake. Here is what I mean: Perhaps you’ve installed Windows NT Server on a truly low-cost workstation. But try as you might, you can’t disable the sleep function at the workstation’s BIOS level (it’s happened to me). To keep the workstation from "sleeping" and crashing Windows NT Server, you can use Ping Plotter to maintain a constant activity level that prevents, shall I say, napping. Problem solved.
    Whatever your preferred pinging method is, the bottom line is that you are trying to verify connectivity. On your bad NT days, that becomes an end in itself. Otherwise, this step should just be second nature. And you can always count on your end users to be your connectivity eyes and ears. If they can’t connect, you’ll know.
     
  • STEP 10: NEW HARDWARE
  • As flaky as it is sometimes, the Plug and Play feature of Windows series is nice to have. Nothing beats buying a Plug and Play–compliant peripheral, throwing it into your PC, and having the operating system detect and set up the new hardware. Easy as pie, as long as you buy compliant hardware. So how the heck do you add new hardware to a Windows NT series Server? It’s actually easier than it seems. When you buy a new piece of hardware for your server, it will come with a Setup disk or CD-ROM that contains drivers for the device. However, using the distribution software in the box should always be your second step; the first step is to check the hardware vendor’s Web site. Ninety percent of the time, the drivers on the Web are newer than those in the box, and with very few exceptions, you always want to use the latest driver.
  • Preparing for installation
    Before you set about installing your new hard drive, network adapter, or whatever, you should take stock of the resources currently in use on the system.You can do this by running Windows NT Diagnostics, the NT version of Microsoft’s good ol’ DOS MSD program. NT Diagnostics will enable you to inspect and print out the list of resources in use on your server, including interrupt request lines (IRQs), memory addresses, I/O ports, and direct memory access ( DMA) channels. This way, you can determine where the new hardware will fit in.
    Note: In most cases, a device’s driver setup program will determine and assign free system resources, so the preceding step is only necessary when the setup program will prompt you to choose resource information.
  • Installing the hardware
    Unless you are installing a "hot-pluggable" device as described in the text that follows, the first step in any hardware installation is to power down the server and disconnect its power source. Also put on some sort of static protection device; in our server room, there are several static control bracelets that can be connected to grounded server parts to prevent static buildup and possible damage to sensitive components.
    Once you have opened up the server and identified where the new device will go, install and connect it according to the manufacturer’s directions. Secret: Some servers even allow you to add or replace hard drives while the server is up and running, with no interrruption of service to the end users. These so-called "hot pluggable, hot swappable" drives are invaluable in 7 × 24 operations.
  • Installing and configuring drivers
    After the new hardware is in place, close the server back up and power it on. Take care to properly close all access panels on the computer; some servers have safety switches that prevent them from powering up unless all of these panels are in place.
    After the operating system comes up, run the hardware driver setup program and install and configure the hardware, again according to the manufacturer’s specifications. In many cases, you must reboot the server in order to get Windows NT to recognize and properly utilize the new device, and some device setup programs will even reboot the machine themselves after they’re done installing the peripheral. This is usually not the case with "hot-plug" hardware, but if you have a choice, take care to perform these hardware operations after hours, or schedule a bit of downtime, even if you’re not sure whether you’ll need it.
    When all of these operations are complete, your new hardware should be set up and ready for you and your users to use!
  • STEP 11: DOCUMENTATION AND SHARING PROCEDURES While it’s not as "active" a task as some of the others mentioned in this chapter, documentation is very important for the success of any network. There is absolutely no sense in one person being proficient at a network administration or process while his or her coworkers are in the dark. In my mind, this is actually a dangerous situation, especially if the task in question is vital to the health of the network. What if that person were hit by a truck? What would the rest of you do?
    Documentation is one thing that’s a high priority at my workplace; we are encouraged, in fact required, to document new processes as they are developed and perfected. This isn’t just for others’ sake, either: Ever get a process down perfectly, only to forget it after a couple of months? Find yourself wishing you had written it down before? I sure have, many times over the years.
    In my office, we have a procedures directory on the network that contains more than 100 documents. Some are out of date now, but we keep them around anyway; some of the tasks detailed could crop up again, or the techniques could be adapted for our current network. In addition, we train each other on new procedures as they are written and do "beta testing." When one of us creates a new procedure, such as installing a new application or restoring a Microsoft Exchange mailbox from backups, he will document it thoroughly. The next step is to have another administrator do the "monkey test," where we just follow the procedure step by step, making sure to leave our outside knowledge at the computer room door. When all we have to go on is the procedure before us, it’s easy to identify holes or assumptions and correct them. Some of our procedures are so good that any end user could come into the server room and perform the task by following the step-by-step procedure document. Yikes: That’s not very good for job security!
    If you ever have a bit of downtime between fighting fires and the endless upgrades, think a moment about procedures you use that may not be documented as well as they should be, and address those issues. Good documentation initially makes a Windows NT professional’s job much easier later on.
    Secret: If you are a consultant, performing the documentation task is a great way to find and bill additional hours. Such additional work is great for three reasons. First, it requires virtually no marketing to get. It’s easier to sell your existing clients on additional work than it is to sell work to new clients. Second, the work is easy to perform. Third, if help you toward reaching your annual billable hour goal. Be sure to use Visio or some other networking diagramming tool as part of your network documentation approach.
     
  • STEP 12: WORKING AND HAPPY USERS This last topic is more a philosophical discussion than a technical one. As a Windows NT professional, it is imperative that you keep the needs of your users in the front of your mind at all times. After all, they are your customers, and despite what your org chart might say, you work for them. After you break out of the front-line support game and earn a position back in the server room, it’s sometimes easy to put these thoughts aside, crucial as they may be. I’ve worked in shops that cover both ends of the spectrum: From a place that would drop the Exchange server in the middle of the day if they deemed it necessary, to my current employer, where one of the IT department’s primary goals is to remain invisible, to make sure the users don’t even know we’re there. I prefer the latter, even if it means quite a bit of after-hours and weekend work. The users’ main impression of the company’s network is that it just works. Your users should feel the same way. To that end, here are some helpful tips I’ve picked up over the years.
  • Protect the users
    If you have a choice, choose the action that will impact the users least. For example, a few months back we noticed that one of our servers was starting to go downhill; unexplained Server service warning events were showing up in the event logs, response times were increasing slightly, and it was evident that something was wrong. At this point, it was a judgment call for my group: Do we leave the server up in the expectation that it will make it to the end of the day, or do we reboot it now, in the middle of the afternoon? As we evaluated the situation, we noted that the problem likely would not cause any data loss, and we took into account that this was one of the busiest days of the month. We decided to gamble and leave the server up until the end of the business day, and it coasted along fine. Decisions like these are tough, because you obviously don’t want the server to come crashing down if you can help it, but we decided that the minimum user impact would be to leave the server up. It was a decision between 10 minutes of guaranteed downtime for a reboot, or 10 minutes of possible downtime if the server crashed later and had to be rebooted. We did, however, take steps to notify all affected groups about the situation, which brings me to my next point.
  • Keep the users informed
    In my experience, users have an easier time accepting a service interruption if they know it’s coming. In the preceding example, my group sent out a company-wide e-mail message advising the users that the server was having problems and might crash, and telling the users to save often. We got positive feedback about this approach; even though the users weren’t happy that the server might die in the middle of the day, they appreciated the warning. Had the machine crashed, they would have lost a lot less work than if they hadn’t had any warning.
    End users do like to know the basic reasons for downtime, but it’s also a good practice to keep technical jargon out of end user communications. While you may think it’s neato to explain the intricacies of ESEUTIL in an e-mail message informing users that the Exchange server will be down for the weekend, the fact is that most people just don’t care. Keep your communications straightforward and to the point, and your message will come across loud and clear. If an end user really is interested in what you’re doing with the Exchange box, he or she will reply and ask for more information. For everyone else, a simple note saying "The Exchange server will be down this weekend for database maintenance" will suffice.
  • Keep the help desk informed
    When I worked on an enterprise help desk, it always seemed as if we were the last to know about vital information that would affect the users. Half the time, we gathered this information from the users themselves as they called, which was terribly frustrating and embarrassing. Like every other tech support veteran I know, I swore up and down that once I got to the back of the shop, I’d make help desk communications a priority so that my first-level support would never be without the proper information. Have I made good on this promise? Mostly, although I’m still not as communicative to our help desk as I’d like to be. It’s a good goal to have, though; the better informed your first-level support people are, the better the users’ impression will be of your department as a cohesive unit where groups communicate among one another.
  • Strive for 100 percent uptime
    Continuous uptime may seem like an obvious goal for anyone who runs a computer system, but keeping it in your mind at all times is a real challenge. Now, everyone who’s worked with NT for any length of time knows that NT servers need reboots every so often, but a really good NT administrator should try to minimize this need. Keep your servers simple, assign them only the tasks you need them to perform, and don’t clog up the system with additional services or applications unless they’re absolutely essential. There’s a saying that a person’s body is his or her temple; make temples out of your production boxes. Have fun with your test servers, but when you have a spare moment, spend it working to make your Windows NT servers as fault-tolerant as they can be. As I mentioned earlier, many administrators don’t have a problem spending hundreds or thousands of dollars to make their hardware bulletproof. Put in the hours necessary to make your operating systems and software just as bulletproof. Challenge yourself to work smarter each and every day. This might include reading trade journals such as InfoWorld, PC Week, and the like. You might read another article just for the heck of it. Consider taking an in-classroom or online course. But each and every day, be sure to make a capital investment in yourself so that you work smarter tomorrow than you did today!
Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)