Relationship Between Communication Skills and Troubleshooting (14.1.1.1)

Think of a time when you had to call a repair person to get something fixed. Did it feel like an emergency to you? Perhaps you had a bad experience with a repair person. Are you likely to call that same person to fix a problem again? What could that technician have done differently in his or her communication with you? Did you have a good experience with a repair person? Did that person listen to you as you explained your problem and then ask you questions to get more information? Are you likely to call that person to fix a problem again?

Speaking directly with the customer is usually the first step in resolving a computer problem. To troubleshoot a computer, you need to learn the details of the problem from the customer. Most people who need a computer problem fixed are likely to be feeling some stress. If you establish a good rapport with the customer, the customer might relax a bit. A relaxed customer is more likely to be able to provide the information you need to determine the source of the problem and then fix it.

Follow these guidelines to provide great customer service:

• Set and meet expectations, adhere to the agreed upon timeline, and communicate the status with the customer.

• If necessary, offer different repair or replacement options.

• Provide documentation on the services provided.

• Follow up with customers and users after services are rendered to verify their satisfaction.

A technician’s good communication skills are an aid in the troubleshooting process. It takes time and experience to develop good communication and troubleshooting skills. As you gain more hardware, software, and OS knowledge, your ability to quickly identify a problem and find a solution will improve. The same idea applies to developing communication skills: The more you practice good communication skills, the more effective you will become at working with customers. A knowledgeable technician who uses good communication skills will always be in demand in the job market.

As a technician, you have access to several communication and research tools. All these resources can be used to help gather information for the troubleshooting process.

Relationship Between Communication Skills and Professional Behavior (14.1.1.3)

Whether you are talking with a customer on the phone or in person, it is important to communicate well and to present yourself professionally.

If you are talking with a customer in person, the customer can see your body language. If you are talking with a customer over the phone, the customer can hear your tone and inflection. Customers can also sense whether you are smiling when you are speaking with them on the phone. Many call center technicians use a mirror at their desk to monitor their facial expressions.

Successful technicians control their own reactions and emotions from one customer call to the next. A good rule for all technicians to follow is that a new customer call means a fresh start. Never carry your frustration from one call to the next.

Know, Relate, and Understand (14.1.2.1)

One of your first tasks as a technician is to identify your customer’s computer problem. Table 14-1 lists the three general rules for talking with a customer: know, relate, and understand.

Active Listening (14.1.2.2)

To better enable you to determine the customer’s problem, practice active listening skills. Allow the customer to tell the whole story. During the time that the customer is explaining the problem, occasionally interject some small words or phrases, such as “I understand,” “Yes,” “I see,” or “Okay.” This behavior lets the customer know that you are there, and that you are listening.

However, a technician should not interrupt s customer to ask a question or make a statement. Doing so would be rude and disrespectful, and it would create tension. Many times in a conversation, you might find yourself thinking of what to say before the other person finishes talking. When you do this, you are not actively listening. Instead, listen carefully when your customers speak, and let them finish their thoughts.

When you ask the customer to explain the problem to you, you are asking an open-ended question. An open-ended question rarely has a simple answer. In explaining the problem to you, the customer probably provided information about what he or she was doing, what he or she was trying to do, and why he or she is frustrated.

After you have listened to the customer explain the whole problem, summarize what the customer has said. This helps the customer know that you have heard and understand the situation. A good practice for clarification is to paraphrase the customer’s explanation by beginning with the words “Let me see if I understand what you have told me.” This is a very effective tool that demonstrates to the customer that you have listened and that you understand.

After you have assured the customer that you understand the problem, you will probably have to ask some follow-up questions. Make sure that these questions are pertinent. Do not ask questions that the customer has already answered while describing the problem. Doing so would irritate the customer and show that you were not listening.

Follow-up questions should be targeted, closed-ended questions based on the information that you have already gathered. Closed-ended questions should focus on obtaining specific information. The customer should be able to answer a closed-ended question with a simple “yes” or “no” or with a factual response, such as “Windows 10.”

Use all the information that you have gathered from the customer to complete a work order.

Using Professional Behavior with the Customer (14.1.3.1)

Be positive when communicating with a customer. Tell the customer what you can do. Do not focus on what you cannot do. Be prepared to explain alternative ways that you can help, such as by emailing information and step-by-step instructions or using remote control software to solve the problem.

When dealing with customers, it is sometimes easier to explain what you should not do. The following list describes things that you should not do when talking with a customer:

• Do not minimize a customer’s problems.

• Do not use jargon, abbreviations, acronyms, and slang.

• Do not use a negative attitude or tone of voice.

• Do not argue with customers or become defensive.

• Do not make culturally insensitive remarks.

• Do not disclose any experiences with customers on social media.

• Do not be judgmental or insulting or call the customer names.

• Avoid distractions and do not interrupt when talking with customers.

• Do not take personal calls when talking with customers.

• Do not talk to coworkers about unrelated subjects when talking with the customer.

• Avoid unnecessary and abrupt phone holds.

• Do not transfer a call without explaining the purpose of the transfer and getting customer consent.

• Do not make negative remarks about other technicians to the customer.

If a technician is not going to be on time, the customer should be informed as soon as possible.

Tips for Hold and Transfer (14.1.3.2)

When dealing with customers, it is necessary to be professional in all aspects of your role. You must handle customers with respect and prompt attention. When on a telephone call, make sure that you know how to place a customer on hold, as well as how to transfer a customer without losing the call, using the tips in Table 14-2 and Table 14-3.

14.1.3.4 What Do You Already Know? - Netiquette (14.1.3.4)

As a technician, you should be professional in all communications with customers: respecting people’s time and their privacy, being forgiving of other’s mistakes, and sharing your expert knowledge. For email and text communications, there is a set of personal and business etiquette rules called netiquette. The following list describes some common netiquette dos and don’ts:

• Do be pleasant and polite, even if someone is not being pleasant or polite with you.

• Do begin emails with an appropriate greeting, even within a thread.

• Do check grammar and spelling before you send an email or a text. This is always a good idea. You never know what serious mistake you might have missed.

• Do be ethical. This is true for email and texts, just as it is in all your other interactions with people.

• Do not send or forward chain letters via email.

• Do not send anger-filled, accusatory emails, called “flames.”

• Do not reply to flames. Flames never solve a problem but only make it worse.

• Do not use all uppercase in email. Using all uppercase letters is considered SHOUTING.

• Do not email or text anything you would not say to someone’s face. Not only is doing so unethical, your emails and texts could possibly be traced back to you.

Keeping the Customer Call Focused (14.1.4.1)

Part of your job is to focus the customer on the problem during the phone call. When you focus the customer on the problem, you can control the call. The following practices make the best use of your time and the customer’s time:

• Use proper language: Be clear and avoid technical language that the customer might not understand.

• Listen and question: Listen carefully to the customer and let him or her speak. Use open- and closed-ended questions to learn details about the customer’s problem.

• Give feedback: Let the customer know that you understand the problem and develop a friendly and positive conversational manner.

Just as there are many different computer problems, there are many different types of customers. By using active listening skills, you may get some hints about what type of customer is on the phone with you. Is this person very new to computers? Is the person very knowledgeable about computers? Is your customer angry? Do not take any comments personally and do not retaliate with any comments or criticism. If you stay calm with the customer, finding a solution to the problem will remain the focal point of the call. Recognizing certain customer traits can help you manage the call accordingly.

Videos 14.1.4.2 through 14.1.4.6 demonstrate strategies for dealing with different types of difficult customers. The list is not comprehensive, and often, a customer will display a combination of traits. Each video contains a recording of a technician handling a difficult customer type incorrectly, followed by a recording of the same technician handling the customer professionally. A quiz follows each example.

Documentation Overview (14.2.1.1)

Different types of organizations have different operating procedures and processes that govern business functions. Documentation is the main way of communicating these processes and procedures to employees, customers, suppliers, and others.

Purposes for documentation include

• Providing descriptions for how products, software, and hardware function through the use of diagrams, descriptions, manual pages, and knowledge base articles

• Standardizing procedures and practices so that they can be repeated accurately in the future

• Establishing rules and restrictions on the use of the organization’s assets, including acceptable use policies for Internet, network, and computer usage

• Reducing confusion and mistakes, saving time and resources

• Complying with governmental or industry regulations

• Training new employees or customers

Keeping documentation up to date is just as important as creating it. Updates to policies and procedures are inevitable, especially in the constantly changing environment of information technology. Establishing a standard timeframe for reviewing documents, diagrams, and compliance policies ensures that the correct information is available when it is needed.

IT Department Documentation (14.2.1.2)

Keeping documentation current is challenging for even the best-managed IT departments. IT documentation can come in many different forms, including diagrams, manuals, configurations, and source code. In general, IT documentation falls into four broad categories:

• Policy documents:

  • Acceptable use policies that describe how technology is to be used within the organization

  • Security policies that outline all aspects of information security, including password policies and security incident response methods

  • Regulatory compliance policies that describe all federal, state, local, and industry regulations that apply to the organization

  • Disaster recovery policies and procedures that provide detailed plans for what must be done to restore services in the event of an outage

• Operation and planning documents:

  • IT strategy and planning documents that outline the near- and long-term goals of the department

  • Proposals for future projects and project approvals

  • Meeting presentations and minutes

  • Budgets and purchasing records

  • Inventory management, including hardware and software inventories, licenses, and management methods, such as the use of asset tags and bar codes

• Project documents:

  • User requests for changes, updates, or new services

  • Software design and functional requirements, including flow diagrams and source code

  • Logical and physical network topology diagrams, equipment specifications, and device configurations

  • Change management forms

  • User testing and acceptance forms

• User documentation:

  • Features, functions, and operation of software, hardware, and services provided by the IT department

  • End-user manuals for hardware and software

  • Help desk ticket database with ticket resolutions

  • Searchable knowledge base articles and FAQs

Regulatory Compliance Requirements (14.2.1.3)

Federal, state, local, and industry regulations can have documentation requirements over and above what is normally documented in the company’s records. Regulatory and compliance policies often specify what data must be collected and how long it must be retained. A few of the regulations may have implications on internal company processes and procedures. Some regulations require keeping extensive records regarding how the data is accessed and used.

Failure to comply with laws and regulations can have severe consequences, including fines, termination of employment, and even incarceration of offenders. It is important to know how laws and regulations apply to your organization and to the work you perform.

Change Control Process (14.2.2.1)

Controlling changes in an IT environment can be difficult. Changes can be as minor as replacing a printer or as important as upgrading all the enterprise servers to the latest operating system version. Most larger enterprises and organizations have change management procedures in place to ensure that installations and upgrades go smoothly.

A good change management process can prevent business functions from being negatively impacted by the updates, upgrades, replacements, and reconfigurations that are a normally part of IT operations. Change management usually starts with a change request from a stakeholder or from within the IT organization itself. Most change management processes include the following:

• Identification: What is the change? Why is it needed? Who are the stakeholders?

• Assessment: What business processes are impacted by this change? What are the costs related to and resources necessary for implementation? What risks are associated with making (or not making) this change?

• Planning: How long will it take to implement this change? Will there be downtime involved? What rollback or recovery process will be used if the change fails?

• Approval: Who must authorize this change? Has approval to proceed with the change been obtained?

• Implementation: How are stakeholders notified? What are the steps to complete the change, and how will the results be tested?

• Acceptance: What are the acceptance criteria, and who is responsible for accepting the results of the change?

• Documentation: What updates are required to change logs, implementation steps, or IT documents because of this change?

All the results of the process are recorded on a change request or change control document that becomes part of the IT documentation. Some expensive or complex changes that impact necessary business functions may require the approval of a change board or committee before work can begin.

Figure 14-1 is an example of a change control worksheet.

Disaster Recovery Overview (14.2.3.1)

We often think of a disaster as being something catastrophic, such as the destruction caused by an earthquake, a tsunami, or a wildfire. In information technology, a disaster can include anything from natural disasters that affect the network structure to malicious attacks on the network itself. The impact of data loss or corruption due to unplanned outages caused by hardware failure, human error, hacking, or malware can be significant.

A disaster recovery plan is a comprehensive document that describes how to restore operation quickly and keep critical IT functions running during or after a disaster occurs. The disaster recovery plan can include information such as offsite locations where services can be moved, information on replacing network devices and servers, and backup connectivity options.

Some services may even need to be available during the disaster in order to provide information to IT personnel and updates to others in the organization. Services that might need to be available during or immediately after a disaster include:

• Web services and Internet connectivity

• Data stores and backup files

• Directory and authentication services

• Database and application servers

• Telephone, email, and other communication services

In addition to having a disaster recovery plan, most organizations take steps to ensure that they are ready in case a disaster occurs. These preventive measures can ease the impact of unplanned outages on the operation of the organization.

Preventing Downtime and Data Loss (14.2.3.2)

Some business applications cannot tolerate any downtime. Such businesses use multiple data centers capable of handling all data processing needs, which run in parallel and have data mirrored or synchronized between the centers. Often, these businesses run their applications from cloud servers to minimize the impact of physical damage to their sites.

Elements of a Disaster Recovery Plan (14.2.3.3)

The first step in creating a disaster recovery plan is to identify the most critical services and applications that will need to be restored quickly. That information should be used to create a disaster recovery plan. Creating and implementing a disaster recovery plan consists of five major phases, as shown in Figure 14-2 and described in the list that follows.

• Phase 1: Network design recovery strategy: Analyze the network design. Some aspects of the network design that should be included in the disaster recovery are:

  • Whether the network is designed to survive a major disaster, whether there are backup connectivity options, and whether there is redundancy in the network design

  • Availability of offsite servers or cloud providers that can support applications such as email and database services

  • Availability of backup routers, switches, and other network devices

  • Location of services and resources that the network needs, whether they are spread over a wide geography, and whether backups are easily accessible in an emergency

• Phase 2: Inventory and documentation: Create an inventory of all locations, devices, vendors, services used, and contact names. Verify cost estimates that are created in the risk assessment step.

• Phase 3: Verification: Create a verification process to prove that the disaster recovery strategy works. Practice disaster recovery exercises to ensure that the plan is up to date and workable.

• Phase 4: Approval and implementation: Obtain senior management approval and develop a budget to implement and maintain the disaster recovery plan.

• Phase 5: Review: After the disaster recovery plan has been implemented for a year, review the plan. Information in the plan must be kept up to date, or critical services may not be restored in the event of a disaster.

Ethical and Legal Considerations in IT (14.3.1.1)

When you are working with customers and their equipment, you should observe some general ethical customs and legal rules. These customs and rules often overlap.

You should always have respect for your customers, as well as for their property. Computers and monitors are property, and property also includes any information or data that might be accessible, including:

• Emails

• Phone lists and contact lists

• Records or data on the computer

• Hard copies of files, information, or data left on a desk

Before accessing computer accounts, including the administrator account, get the permission of the customer. During the troubleshooting process, you might have gathered some private information, such as usernames and passwords. If you document this type of private information, you must keep it confidential. Divulging customer information to anyone else is unethical and might also be illegal. Do not send unsolicited messages to a customer. Do not send unsolicited mass mailings or chain letters to customers. Never send forged or anonymous emails. Legal details of customer information are usually covered under the service-level agreement (SLA). The SLA is a contract between a customer and a service provider that defines the service or goods the customer will receive and the standards with which the provider must comply.

Personally Identifiable Information (PII) (14.3.1.2)

Take particular care to keep personally identifiable information (PII) confidential. PII is any data that could potentially identify a specific individual. NIST Special Publication 800-122 defines PII as “any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual’s identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.”

Examples of PII include, but are not limited to

• Names, such as full name, maiden name, mother’s maiden name, or alias

• Personal identification numbers, such as Social Security number (SSN), passport number, driver’s license number, taxpayer identification number, financial account or credit card number, and address information, such as street address or email address

• Personal characteristics, including photographic images (especially of the face or other identifying characteristics), fingerprints, handwriting, or other biometric data (for example, retina scan, voice signature, facial geometry)

PII violations are regulated by several organizations in the United States, depending on the type of data. The EU General Data Protection Regulation (GDPR) also regulates how data is handled for personal data, including financial and healthcare information.

Payment Card Industry (PCI) (14.3.1.3)

Payment Card Industry (PCI) information is considered personal information that needs to be protected. We often hear news about breaches of credit card information that impact millions of users. Often it is days or weeks before a merchant realizes a breach has occurred. All businesses and organizations, large or small, need to adhere to strict standards to protect consumer information.

The PCI Security Standards Council was formed in 2005 by the five major credit card companies in an effort to protect account numbers, expiration dates, and magnetic strip and chip data for transactions around the globe. The PCI Security Standards Council partners with organizations, including NIST, to develop standards and security procedures around these transactions.

In one of the worst breaches in history, malware infected the point-of-sale system of a major retailer, impacting millions of consumers. This breach could potentially have been prevented with adequate software and policies for data breach prevention. As an IT professional, you should be aware of PCI compliance standards.

For more information on the PCI Security Standards Council, visit www.pcisecuritystandards.org.

Protected Health Information (PHI) (14.3.1.4)

Protected health information (PHI) is a particular form of PII that needs to be secured and protected. PHI includes patient names, addresses, dates of visits, telephone and fax numbers, and email addresses. With the move from paper records to electronic records, electronic protected health information (ePHI) is also regulated. Penalties for breaches of PHI and ePHI are very severe and are subject to the Health Insurance Portability and Accountability Act (HIPAA).

Examples of ePHI breaches are easily found with an Internet search. Unfortunately, a breach may be undetected for months. Some breaches have occurred from one person giving out information to an unauthorized person. Human error can cause violations. For example, accidentally faxing health information to the wrong party is a violation. Sophisticated attacks also lead to violations. Recent phishing attacks on a California-based health plan went undetected for almost a month before the plan recognized it and then notified 37,000 patients that their data had been breached. As an IT professional, you should be aware of protecting PHI and ePHI.

For more information about PHI and ePHI, visit www.hhs.gov and search for PHI.

Search the Internet for the regulatory agencies in your state, country, or province.

Legal Considerations in IT (14.3.1.6)

The laws in different countries and legal jurisdictions vary, but generally, actions such as the following are considered to be illegal:

• It is not permissible to make any changes to system software or hardware configurations without customer permission.

• It is not permissible to access a customer’s or coworker’s accounts, private files, or email messages without permission.

• It is not permissible to install, copy, or share digital content (including software, music, text, images, and video) in violation of copyright and software agreements or applicable law. Copyright and trademark laws vary between states, countries, and regions.

• It is not permissible to use a customer’s company IT resources for commercial purposes.

• It is not permissible to make a customer’s IT resources available to unauthorized users.

• It is not permissible to knowingly use a customer’s company resources for illegal activities. Criminal or illegal use typically includes obscenity, child pornography, threats, harassment, copyright infringement, Internet piracy, university trademark infringement, defamation, theft, identity theft, and unauthorized access.

• It is not permissible to share sensitive customer information. You are required to maintain the confidentiality of this data.

This list is not exhaustive. All businesses and their employees must know and comply with all applicable laws of the jurisdiction in which they operate.

Licensing (14.3.1.7)

As an IT technician, you might encounter customers who are using software illegally. It is important that you understand the purposes and types of common software licenses in case you determine that a crime has been committed. Your responsibilities are usually covered in your company’s corporate end-user policy. In all instances, you must follow security best practices, including documentation and chain of custody procedures.

A software license is a contract that outlines the legal use or redistribution of a piece of software. Most software licenses grant end-user permission to use one or more copies of the software. They also specify the end user’s rights and restrictions. This ensures that the software owner’s copyright is maintained. It is illegal to use licensed software without an appropriate license.

Personal License

Most software is licensed rather than sold. Some personal software licenses regulate how many computers can run a copy of the software. Other licenses specify the number of users who can access the software. Most personal software licenses allow you to run the program on only one machine. Some personal software licenses allow you to copy the software onto multiple computers. These licenses usually specify that the copies cannot be used at the same time.

One example of a personal software license is an end user license agreement (EULA). A EULA is a license between the software owner and an individual end user. The end user must agree to accept the terms of the EULA. Sometimes, accepting a EULA is as simple as opening the physical package that holds a CD of the software or downloading and installing the software. A common example of agreeing to a EULA occurs when updating the software on tablets and smartphones. The end user must agree to accept the EULA when updating the operating system or installing or updating software found on the device by selecting I Accept the License Terms and clicking Accept, as shown in Figure 14-3.

Computer Forensics (14.3.2.1)

Data from computer systems, networks, wireless communications, and storage devices may need to be collected and analyzed in the course of a criminal investigation. The collection and analysis of data for this purpose is called computer forensics. The process of computer forensics encompasses both IT and specific laws to ensure that any data collected is admissible as evidence in court.

Depending on the country, illegal computer or network usage may include

• Identity theft

• Using a computer to sell counterfeit goods

• Using pirated software on a computer or network

• Using a computer or network to create unauthorized copies of copyrighted materials, such as movies, television programs, music, and video games

• Using a computer or network to sell unauthorized copies of copyrighted materials

• Pornography

This is not an exhaustive list. Becoming familiar with the signs of illegal computer or network usage can help you identify situations where you suspect illegal activity and report them to the authorities.

Data Collected in Computer Forensics (14.3.2.2)

Two basic types of data are collected when conducting computer forensics procedures:

• Persistent data: Persistent data is stored on a local drive, such as an internal or external hard drive, or an optical drive. When the computer is turned off, this data is preserved.

• Volatile data: RAM, cache, and the Registry contain volatile data. Data in transit between a storage medium and a CPU is also volatile data. If you are reporting illegal activity or are part of an incident response team, it is important to know how to capture this data because it disappears as soon as the computer is turned off.

In Figure 14-4, the computer forensic expert is examining a hard drive for damage before inspecting it for persistent data.

Cyber Law (14.3.2.3)

There is no single law known as a cyber law. Cyber law is a term used to describe the international, regional, country, and state laws that affect computer security professionals. IT professionals must be aware of cyber law so that they understand their responsibility and their liability in relation to cybercrimes.

Cyber law explains the circumstances under which data (evidence) can be collected from computers, data storage devices, networks, and wireless communications. It can also specify the manner in which this data can be collected. In the United States, cyber law has three primary elements:

• Wiretap Act

• Pen/Trap and Trace Statute

• Stored Electronic Communication Act

IT professionals should be aware of the cyber law in their country, region, or state.

First Response (14.3.2.4)

First response is the term used to describe the official procedures employed by people who are qualified to collect evidence. System administrators, like law enforcement officers, are usually the first responders at potential crime scenes. Computer forensics experts are brought in when it is apparent that there has been illegal activity.

Routine administrative tasks can affect the forensic process. If the forensic process is improperly performed, evidence that has been collected might not be admissible in court.

As a field or bench technician, you may be the person who discovers illegal computer or network activity. If this happens, do not turn off the computer. Volatile data about the current state of the computer can include programs that are running, network connections that are open, and users who are logged in to the network or to the computer. This data helps determine a logical timeline of the security incident. It may also help to identify those responsible for the illegal activity. This data could be lost when the computer is powered off.

Be familiar with your company’s policy regarding cybercrimes. Know who to call, what to do and, just as importantly, know what not to do.

Documentation (14.3.2.5)

The documentation required by a system administrator and a computer forensics expert is extremely detailed. They must document not only what evidence was gathered but how it was gathered and with what tools. Incident documentation should use consistent naming conventions for forensic tool output. Stamp logs with the time, date, and identity of the person performing the forensic collection. Document as much information about the security incident as possible. These best practices provide an audit trail for the information collection process.

Even if you are not a system administrator or computer forensics expert, it is a good habit to create detailed documentation of all the work you do. If you discover illegal activity on a computer or network on which you are working, at a minimum, document the following:

• Initial reason for accessing the computer or network

• Time and date

• Peripherals that are connected to the computer

• All network connections

• Physical area where the computer is located

• Illegal material that you have found

• Illegal activity that you have witnessed (or that you suspect has occurred)

• Which procedures you have executed on the computer or network

First responders want to know what you have done and what you have not done. Your documentation may become part of the evidence in the prosecution of a crime. If you make additions or changes to this documentation, it is critical that you inform all interested parties.

Chain of Custody (14.3.2.6)

For evidence to be admitted in legal proceedings, it must be authenticated. A system administrator may testify about the evidence that was collected. He or she must also be able to prove how this evidence was collected, where it has been physically stored, and who has had access to it between the time of collection and its entry into the court proceedings. This is known as the chain of custody. To prove the chain of custody, first responders have documentation procedures in place to track the collected evidence, such as evidence bags, as shown in Figure 14-5. These procedures also prevent evidence tampering so that the integrity of the evidence can be ensured.

Incorporate computer forensics procedures into your approach to computer and network security to ensure the integrity of the data. These procedures help you capture necessary data in the event of a network breach. Ensuring the viability and integrity of the captured data helps you prosecute the intruder.

Call Centers (14.4.1.1)

A call center environment is usually very organized and professional. Customers call in to receive help for a specific computer-related problem. The typical workflow of a call center starts with calls from customers displayed on a callboard. Level one technicians answer these calls in the order in which the calls arrive. If the level one technician cannot solve the problem, it is escalated to a level two technician. In all instances, the technician must supply the level of support that is outlined in the customer’s service-level agreement (SLA).

A call center might exist within a company and offer service to the employees of that company as well as to the customers of that company’s products. Alternatively, a call center might be an independent business that sells computer support as a service to outside customers. In either case, a call center is a busy, fast-paced work environment, often operating 24 hours a day.

Call centers tend to have a large number of cubicles, as shown in Figure 14-6. Each cubicle has a chair, at least one computer, a phone, and a headset. The technicians working at these cubicles have varied levels of experience with computers, and some specialize in certain types of computers, hardware, software, or operating systems.

As calls come in to the call center, they must be prioritized so that the most urgent calls are resolved first. Table 14-5 is an example of a call prioritization system.

All the computers in a call center have support software. The technicians use this software to manage many of their job functions. Technicians use support software to complete the following tasks:

• Log and track incidents: The software might manage call queues, set call priorities, assign calls, and escalate calls.

• Record contact information: The software might store, edit, and recall customer names, email addresses, phone numbers, location, websites, fax numbers, and other information in a database.

• Research product information: The software might provide technicians with information regarding the products supported, including features, limitations, new versions, configuration constraints, known bugs, product availability, links to online help files, and other information.

• Run diagnostic utilities: The software might have several diagnostic utilities, including remote diagnostic software, in which the technician can take over a customer’s computer while sitting at a desk in the call center.

• Research a knowledge base: The software might contain a knowledge database that is programmed with common problems and their solutions. This database might grow as technicians add their own records of problems and solutions.

• Collect customer feedback: The software might collect customer feedback regarding satisfaction with the call center’s products and services.

Level One Technician Responsibilities (14.4.1.2)

Call centers sometimes have different names for level one technicians. These technicians might be known as level one analysts, dispatchers, or incident screeners. Regardless of the title, the responsibilities of a level one technician are fairly similar from one call center to the next.

The primary responsibility of a level one technician is to gather pertinent information from the customer. The technician has to accurately enter all information into the ticket or work order. Examples of the type of information that the level one technician must obtain are as follows:

• Contact information

• What are the manufacturer and model of computer?

• What OS is the computer using?

• Is the computer plugged in to the wall or running on battery power?

• Is the computer on a network? If so, is it a wired or wireless connection?

• Was any specific application being used when the problem occurred?

• Have any new drivers or updates been installed recently? If so, what are they?

• Description of the problem

• Priority of problem

Some problems are very simple to resolve, and a level one technician can usually take care of these without escalating the work order to a level two technician.

When a problem requires the expertise of a level two technician, the level one technician must describe a customer’s problem on a work order, using a succinct sentence or two. An accurate description is important because it helps other technicians quickly understand the situation without having to ask the customer the same questions again.

Level Two Technician Responsibilities (14.4.1.3)

As with level one technicians, call centers sometimes have different names for level two technicians. These technicians might be known as product specialists or technical-support personnel. The level two technician’s responsibilities are generally the same from one call center to the next.

The level two technician is usually more knowledgeable and experienced than the level one technician or has been working for the company for a longer period of time. When a problem cannot be resolved within a predetermined amount of time, the level one technician prepares an escalated work order, as shown in Figure 14-7. The level two technician receives the escalated work order with the description of the problem and then calls the customer back to ask any additional questions and resolve the problem.

Level two technicians can also use remote access software to connect to a customer’s computer to update drivers and software, access the operating system, check the BIOS, and gather other diagnostic information to solve the problem.

Script Examples (14.4.2.1)

As an IT professional, you will be exposed to many different types of files. One very important type of file is a script file, a simple text file written in a scripting language to automate a process or tasks on an operating system. In the field, a script file might be used to automate the process of performing a backup of a customer’s data or to run a list of standard diagnostics on a broken computer. The script file can save the technician a lot of time, especially when the same tasks need to be performed on many different computers. You should also be able to identify the many different types of script files because a script file may be causing a problem at startup or during a specific event. Often, preventing the script file from running may eliminate the problem that is occurring.

The commands in a script file might be written on the command line one at a time, but it is more effective to use a script file. The script is designed to be executed line by line, using a command line interpreter in order to perform various commands. A script can be created using a text editor such as Notepad, but an integrated development environment (IDE) is often used to write and execute scripts. A Windows batch script is shown in Example 14-1.

Example 14-1 Windows Batch Script

Click here to view code image

@echo off
echo My first batch script!!
echo My hostname is: %computername%
pause

The four lines of this Windows batch script do the following:

1. Turn off automatic echoing output at the terminal.

2. Echo the sentence “My first batch script!!” to the terminal.

3. Echo “My hostname is:” followed by the variable %computername% to the terminal.

4. Pause the script with the prompt of “Press any key to continue...”

Example 14-2 shows a Linux shell script.

Example 14-2 Linux Shell Script

Click here to view code image

#!/bin/bash
echo My first batch script!!
echo My hostname is: $(hostname)
sleep 2

The four lines of this Linux shell script do the following:

1. Identify the shell that the script will be using.

2. Echo the sentence “My first batch script!!” to the terminal.

3. Echo “My hostname is:” followed by the variable $(hostname) to the terminal.

4. Pause the script for 2 seconds.

Scripting Languages (14.4.2.2)

A scripting language is different from a compiled language because each line is interpreted and then executed when the script is run. Examples of scripting languages include Windows batch files, PowerShell, Linux shell script, VBScript, JavaScript, and Python. Compiled languages such as C, C++, C#, and Java need to be converted into executable code by a compiler. Executable code is directly readable by the CPU, and scripting languages are interpreted into code that the CPU can read one line at a time by a command interpreter or by the operating system. This makes scripting languages unsuitable for situations in which performance is a significant factor. Table 14-6 lists scripting languages and their extensions.

Table 14-7 shows the comment styles used in various scripting languages.

Basic Script Commands (14.4.2.3)

Various commands are available at the terminal of each operating system. Some Windows commands are based on DOS and are accessible through the command prompt. Other Windows commands are accessible through PowerShell. The Windows commands in Table 14-8 were inherited from DOS and work at the Windows command prompt as well as in batch scripts.

Linux commands are written to be compatible with Unix commands and are often accessed through BASH (Bourne Again shell). The Unix-compatible commands in Table 14-9 are available in most Linux distributions. Note that some of these commands are the same as their DOS counterparts.

Variables/Environmental Variables (14.4.2.4)

Variables and environmental variables are unique memory locations used by programs.

User@Linux:~$ cat ./script1.sh
#1/bin/bash
echo -n "What is your last name? "
read LNAME
echo -n "Where are you from? "
read PLACE
echo Hello, $LNAME from $PLACE
User@Linux:~$ ./script1.sh
What is your last name? Smith
Where are you from? Michigan
Hello, Smith from Michigan

User@Linux:~$ cat ./script2.sh
#1/bin/bash
echo The current directory is $PWD
echo The language used is $LANGUAGE
echo The shell being used is $SHELL
User@Linux:~$ ./script1.sh
The current directory is /home/User
The language used is en_US
The shell being used is /bin/bash

Conditional Statements (14.4.2.5)

Conditional statements are needed for scripts to make decisions. These statements usually come in the form of if-else or case statements. In order for a conditional statement to make a decision, a comparison must be made by using operators. The syntax of these commands varies depending on the operator language.

Table 14-11 shows a list of relational operators in various scripts. When making a mathematical comparison, use relational operators. Other types of operators include arithmetic (+, -, *, /, %), logical (and, or, not), assignment (+=, -+, *=), and bitwise (&, |, ^) operators.

User@Linux:~$ date | cut -f 4 -d ' '
09:36:24
User@Linux:~$ cat ./script3.sh
#!/bin/bash
TIME=$(date | cut -f 4 -d ' ' | cut -f 1 -d ':')
declare NOON=12
if [ $TIME -ge $NOON ]
  then echo "Afternoon"
  else echo "Morning"
fi
User@Linux:~$ ./script3.sh
Morning

User@Linux:~$ cat ./script4.sh
#!/bin/bash
read -p "Give me a letter. " LETTER
case $LETTER in
a|e|i|o|u) echo "$LETTER is a vowel." ;;
*) echo "$LETTER is a consonant." ;;
esac
User@Linux:~$ ./script4.sh
Give me a letter. e
e is a vowel.
User@Linux:~$ ./script4.sh
Give me a letter. b
b is a consonant

Loops (14.4.2.6)

A loop can be used to repeat commands or tasks. The three main types of loops used in scripts are the for loop, the while loop, and the do-while loop.

A for loop repeats a section of code a specified number of times. A while loop checks a variable to verify whether it is true (or false) before repeating a section of code; this is known as a pre-test loop. Finally, a do-while loop repeats a section of code and then checks a variable to verify whether it is true (or false); this is known as a post-test loop.

User@Linux:~$ cat ./script5.sh
#!/bin/bash
for COUNT in 'seq 1 5'; do
  let NUMBER1 = "$RANDOM % 256"
  let NUMBER2 = "$(echo "obase=2; $NUMBER1" | bc)"
  echo $NUMBER1 = $NUMBER2
done
User@Linux:~$ ./script5.sh
160 = 10100000
71 = 1000111
43 = 101011
187 = 10111011
7 = 111

User@Linux:~$ cat ./script6.sh
#!/bin/bash
NUMBER=1
while [ $NUMBER -le 8 ]; do
  let NUMBER="$RANDOM % 10+1"
  echo -n "$NUMBER "
done
  echo "> 8 .. loop broken."
User@Linux:~$ ./script6.sh
5 7 9 > .. loop broken.

User@Linux:~$ cat ./script7.sh
#!/bin/bash
while true ; do
  let NUMBER="$RANDOM % 10+1"
  echo -n "$NUMBER "
  if [ $NUMBER -gt 8 ]; then break; fi
done
  echo "> 8 .. loop broken."
User@Linux:~$ ./script7.sh
3 7 4 1 5 7 6 7 1 7 9 > 8 .. loop broken.