Tuesday, 31 May 2011
Tuesday, 5 April 2011
What you will learn in this tip: Today’s call centers and contact centers use voice over IP (VoIP) technology, and the supporting computer systems and databases typically use the same network infrastructure. This presents unique challenges should a disaster occur. Learn about call center disaster recovery (DR) planning best practices in this tip, and read our call center checklists so you'll know what to include in your call center disaster recovery plan.
In order to determine what to include in your call center disaster recovery plan, we first have to examine a typical call center system.
The following diagram (Figure 1) depicts two primary systems, the voice system and the information system, and how they connect. Incoming calls are processed by the call center system; the call center system gathers relevant data from the caller and synchs up with the organization’s databases via the call center information system. This latter element can be part of the voice communications system, but for the purposes of this discussion we show it as a separate entity.
Figure 1: A typical call center system
Relevant information the agent needs for the call is displayed on their system. The agent can interact directly with the company’s information systems and databases while still on the call.
Call center system elements are typically linked by a local area network, such as 10/100 MB Ethernet or Gigabit Ethernet, depending on the number of agents, number of calls and the amount of data to be moved.
What should be in your call center disaster recovery plan?
As you can see from Figure 1, nearly any part of a call center operation is a potential risk to the call center. The list below covers some of the potential risks that can impact call center operations. Use this list in your efforts to assess risks. As you develop your call center disaster recovery plan, you can base it on the risks you identify.
1. Loss of incoming calls through a network outage or other service disruption
2. Loss of network-based information, such as caller ID, that is needed to process the calls
3. Loss of physical connection from the network side to the switch side due to a cable cut, lightning strike or trunk interface failure
4. Loss of the call center switch due to a power outage, circuit board failure, software failure or human error
5. Loss of the database and other supporting information systems due to a power outage, server failure or storage element failure
6. Loss of the local area network (LAN) connecting all components due to a power outage, network interface card failure, cable problem or cable connector problems
7. Loss of the agent workstation due to power outage, system failure or software failure
8. Loss of the agent due to illness, union-based work stoppage, or the need for additional training
Call center disaster preparedness checklist
Like any specialized technology, call center systems have their own attributes, especially older call center systems that operate independently of data networks and the Internet. With newer systems, such as VoIP, some of the issues addressed below may be superseded, but it’s a good idea to factor them into your planning.
The following checklist can be used to determine you call center's preparedness.
1. Location of the equipment in a separate room as opposed to sharing space in a room with other systems; location of equipment in agent work areas
2. Need for separate heating, ventilation, air conditioning (HVAC) facilities
3. Need for separate power supplies, including commercial power outlets, battery backup systems, proper grounding and lightning protection
4. Need for access to specialized local access lines for connecting to local and long distance service providers; may also need separate Internet access lines
5. Specialized peripheral subsystems, such as call detail recording, source for music on hold, voice mail and computer-telephony interface (CTI) technology
6. Specialized phone devices for agents as well as individual users
7. Connectors for agent phones (e.g., RJ-11 or RJ-12, as opposed to RJ-45 typically used in VoIP systems)
8. Unique call center operating systems and frequently-changing databases that must be backed up periodically, both on site and at the vendor’s tech center
9. Unique call center system circuit boards that may need to be replaced quickly following a disaster; supplies of tested boards should be on site and readily available from vendors
Checklist for a call center disaster recovery plan
Before you begin developing a call center disaster recovery plan, be sure you have/address the following 10 items so you will initially be able to respond and recover from a disaster.
1. Ensure that call system maintenance plan covers disaster situations
2. Ensure that service-level agreement (SLA) provides remedies for disruptive situations
3. Have battery backup system(s)
4. Have spare circuit boards and/or telephone instruments
5. Have backup (and up-to-date) copies of all system-level software, including call center system and all other ancillary system elements
6. Contact list for all vendor and network service providers is up-to-date
7. Contact list for all agents
8. Contact list for any other stakeholders in the call center
9. Ability to reconfigure call center so that agents may work at alternate locations
10. Alternate space for emergency relocation of call center
Creating a call center disaster recovery plan -- one that responds to and eventually recovers the systems and/or network services -- is largely a straightforward process. The keys to success are to understand the risks to the call center systems and CTI technology, network infrastructure (both internal and external) and staffing; partner with vendors and network service providers as much as possible; define step-by-step procedures for response and recovery; validate these actions through periodic exercising; and keep the plan and its various components up to date.
In order to determine what to include in your call center disaster recovery plan, we first have to examine a typical call center system.
The following diagram (Figure 1) depicts two primary systems, the voice system and the information system, and how they connect. Incoming calls are processed by the call center system; the call center system gathers relevant data from the caller and synchs up with the organization’s databases via the call center information system. This latter element can be part of the voice communications system, but for the purposes of this discussion we show it as a separate entity.
Figure 1: A typical call center system
Relevant information the agent needs for the call is displayed on their system. The agent can interact directly with the company’s information systems and databases while still on the call.
Call center system elements are typically linked by a local area network, such as 10/100 MB Ethernet or Gigabit Ethernet, depending on the number of agents, number of calls and the amount of data to be moved.
What should be in your call center disaster recovery plan?
As you can see from Figure 1, nearly any part of a call center operation is a potential risk to the call center. The list below covers some of the potential risks that can impact call center operations. Use this list in your efforts to assess risks. As you develop your call center disaster recovery plan, you can base it on the risks you identify.
1. Loss of incoming calls through a network outage or other service disruption
2. Loss of network-based information, such as caller ID, that is needed to process the calls
3. Loss of physical connection from the network side to the switch side due to a cable cut, lightning strike or trunk interface failure
4. Loss of the call center switch due to a power outage, circuit board failure, software failure or human error
5. Loss of the database and other supporting information systems due to a power outage, server failure or storage element failure
6. Loss of the local area network (LAN) connecting all components due to a power outage, network interface card failure, cable problem or cable connector problems
7. Loss of the agent workstation due to power outage, system failure or software failure
8. Loss of the agent due to illness, union-based work stoppage, or the need for additional training
Call center disaster preparedness checklist
Like any specialized technology, call center systems have their own attributes, especially older call center systems that operate independently of data networks and the Internet. With newer systems, such as VoIP, some of the issues addressed below may be superseded, but it’s a good idea to factor them into your planning.
The following checklist can be used to determine you call center's preparedness.
1. Location of the equipment in a separate room as opposed to sharing space in a room with other systems; location of equipment in agent work areas
2. Need for separate heating, ventilation, air conditioning (HVAC) facilities
3. Need for separate power supplies, including commercial power outlets, battery backup systems, proper grounding and lightning protection
4. Need for access to specialized local access lines for connecting to local and long distance service providers; may also need separate Internet access lines
5. Specialized peripheral subsystems, such as call detail recording, source for music on hold, voice mail and computer-telephony interface (CTI) technology
6. Specialized phone devices for agents as well as individual users
7. Connectors for agent phones (e.g., RJ-11 or RJ-12, as opposed to RJ-45 typically used in VoIP systems)
8. Unique call center operating systems and frequently-changing databases that must be backed up periodically, both on site and at the vendor’s tech center
9. Unique call center system circuit boards that may need to be replaced quickly following a disaster; supplies of tested boards should be on site and readily available from vendors
Checklist for a call center disaster recovery plan
Before you begin developing a call center disaster recovery plan, be sure you have/address the following 10 items so you will initially be able to respond and recover from a disaster.
1. Ensure that call system maintenance plan covers disaster situations
2. Ensure that service-level agreement (SLA) provides remedies for disruptive situations
3. Have battery backup system(s)
4. Have spare circuit boards and/or telephone instruments
5. Have backup (and up-to-date) copies of all system-level software, including call center system and all other ancillary system elements
6. Contact list for all vendor and network service providers is up-to-date
7. Contact list for all agents
8. Contact list for any other stakeholders in the call center
9. Ability to reconfigure call center so that agents may work at alternate locations
10. Alternate space for emergency relocation of call center
Creating a call center disaster recovery plan -- one that responds to and eventually recovers the systems and/or network services -- is largely a straightforward process. The keys to success are to understand the risks to the call center systems and CTI technology, network infrastructure (both internal and external) and staffing; partner with vendors and network service providers as much as possible; define step-by-step procedures for response and recovery; validate these actions through periodic exercising; and keep the plan and its various components up to date.
Wednesday, 23 March 2011
The disaster in Japan has midmarket CIOs focusing on their own IT disaster recovery/business continuity (DR/BC) plans -- and it's a good thing, since earthquakes, tsunamis and other disasters are responsible for only a tiny fraction of network outages, according to a recent poll by technology solutions provider CDW LLC.
Everyday power outages -- perhaps caused by a thunderstorm or high winds -- were responsible for nearly a third (32%) of the disruptions noted by respondents to the survey, a mix of midmarket and large companies. Hardware failures accounted for almost another third (29%), and a loss of telecom services caused 21% of business technology interruptions.
To guard against such business interruptions, Sisters of Mercy Health System in Chesterfield, Mo., recently flipped the switch on a new hot site that's chock full of redundancies, according to Jeff Bell, chief operating officer. "There are two generators instead of one; two utility feeds from a power generation plant; all the chillers back up to UPSes. If you look at the mechanical cross section, it's a mirror image," Bell said. This enables the IT department to take down only half of the building if there's a problem, and fix it.
And even though the new data center in Washington, Mo., is designed to take withstand a category F2 tornado, Sisters of Mercy is keeping its original data center in Sunset Hills open as a backup to the hot site. "There's always a disaster," Bell said. "The new data center is very unlikely to take a direct hit [from a tornado], but if it did, it might not survive. That's why we keep Sunset Hills up and running."
A grim truth about IT disaster recovery plans
Unlike Mercy, just over a third of the businesses responding to CDW's survey (34%) said they are updating their DR/BC plans, by improving network connectivity (30%); extending DR/BC coverage to accommodate an outage of 72 hours or more; increasing remote access for employees (18%); and improving data center power and backup capabilities (17%). However, one out of every five businesses (20%) is not planning any immediate changes to its DR/BC plans.
Since the Business Continuity Institute has deemed this Business Continuity Awareness Week, it's worth asking whether IT departments are wearing rose-colored glasses.
Judging by the results of CDW's survey, the answer would be yes. The Vernon Hills, Ill.-based firm asked 7,000 IT managers whether their businesses had suffered an outage in the prior year, and about 1,800 said they had. CDW closed the survey when 200 respondents, from enterprise and midmarket firms, had responded fully to its query.
The sobering statistic is that 82% of these 200 respondents said they'd had faith in their IT disaster recovery plans before the disruption, but 30% said at times, they were unable to operate at all due to a network disruption, and their location shut down completely.
A staggering 97% said their business had suffered detrimental effects as a result. Indeed, CDW estimates that such outages cost U.S. businesses $1.7 billion in lost profits last year. More than half of businesses (57%) reported productivity loss as the top negative effect, and more than a third (34%) said customer communications were interrupted. Internal communications also suffered at 22% of the companies, and 14% suffered data loss. Regardless of the cause, more than half of the companies said employees had problems connecting to the network, both inside and outside the building.
Solutions for IT disaster recovery
In a report on disaster recovery last year, Boston-based research firm Aberdeen Group Inc. estimated the average cost per hour of business interruption to be $98,000. In a nutshell, the report said, successful disaster recovery and business continuity involves keeping a backup of critical data off-site, and restoring it as quickly as possible.
Remember the old saw: Don't keep all your eggs in one basket. Aberdeen analysts recommend a mix of backup solutions, at various costs. Tape stores data sequentially and is ideal for data that isn't accessed frequently.
Another solution is to store backups of critical data and backups off-site. Off-site storage services often specialize in secure practices and data restoration, enabling CIOs to set parameters for service levels such as the length of time it takes to retrieve data from a backup.
In addition, a number of best-in-class companies are backing up real-time data to remote locations or servers, or using this type of remote storage for archival purposes. These companies are also implementing all three backup scenarios two to three times faster than laggard companies.
Testing key to IT disaster recovery plans
There are several steps to ensuring that an IT disaster recovery plan will work, according to CDW. First, it's important to conduct a business impact assessment by working with leaders of each functional area to understand the cost and repercussions of losing each category of data.
CIOs should then document configuration diagrams of hardware, software and network components to be used in recovery, and include personnel requirements, travel needs and associated costs. Employees who are critical to continuity operations should be trained to work remotely, even if they don't do so regularly.
Also, consider adding uninterruptible power supplies for critical servers, network connections and select computers, and back up frequently. Look at telecom options such as redundant connections to cover spot outages, and alternatives such as wireless or satellite phones.
Finally, the key to recovery is to test the DR/BC plan at least once every 12 months to make sure people and systems are ready for the unexpected.
Everyday power outages -- perhaps caused by a thunderstorm or high winds -- were responsible for nearly a third (32%) of the disruptions noted by respondents to the survey, a mix of midmarket and large companies. Hardware failures accounted for almost another third (29%), and a loss of telecom services caused 21% of business technology interruptions.
To guard against such business interruptions, Sisters of Mercy Health System in Chesterfield, Mo., recently flipped the switch on a new hot site that's chock full of redundancies, according to Jeff Bell, chief operating officer. "There are two generators instead of one; two utility feeds from a power generation plant; all the chillers back up to UPSes. If you look at the mechanical cross section, it's a mirror image," Bell said. This enables the IT department to take down only half of the building if there's a problem, and fix it.
And even though the new data center in Washington, Mo., is designed to take withstand a category F2 tornado, Sisters of Mercy is keeping its original data center in Sunset Hills open as a backup to the hot site. "There's always a disaster," Bell said. "The new data center is very unlikely to take a direct hit [from a tornado], but if it did, it might not survive. That's why we keep Sunset Hills up and running."
A grim truth about IT disaster recovery plans
Unlike Mercy, just over a third of the businesses responding to CDW's survey (34%) said they are updating their DR/BC plans, by improving network connectivity (30%); extending DR/BC coverage to accommodate an outage of 72 hours or more; increasing remote access for employees (18%); and improving data center power and backup capabilities (17%). However, one out of every five businesses (20%) is not planning any immediate changes to its DR/BC plans.
Since the Business Continuity Institute has deemed this Business Continuity Awareness Week, it's worth asking whether IT departments are wearing rose-colored glasses.
Judging by the results of CDW's survey, the answer would be yes. The Vernon Hills, Ill.-based firm asked 7,000 IT managers whether their businesses had suffered an outage in the prior year, and about 1,800 said they had. CDW closed the survey when 200 respondents, from enterprise and midmarket firms, had responded fully to its query.
The sobering statistic is that 82% of these 200 respondents said they'd had faith in their IT disaster recovery plans before the disruption, but 30% said at times, they were unable to operate at all due to a network disruption, and their location shut down completely.
A staggering 97% said their business had suffered detrimental effects as a result. Indeed, CDW estimates that such outages cost U.S. businesses $1.7 billion in lost profits last year. More than half of businesses (57%) reported productivity loss as the top negative effect, and more than a third (34%) said customer communications were interrupted. Internal communications also suffered at 22% of the companies, and 14% suffered data loss. Regardless of the cause, more than half of the companies said employees had problems connecting to the network, both inside and outside the building.
Solutions for IT disaster recovery
In a report on disaster recovery last year, Boston-based research firm Aberdeen Group Inc. estimated the average cost per hour of business interruption to be $98,000. In a nutshell, the report said, successful disaster recovery and business continuity involves keeping a backup of critical data off-site, and restoring it as quickly as possible.
Remember the old saw: Don't keep all your eggs in one basket. Aberdeen analysts recommend a mix of backup solutions, at various costs. Tape stores data sequentially and is ideal for data that isn't accessed frequently.
Another solution is to store backups of critical data and backups off-site. Off-site storage services often specialize in secure practices and data restoration, enabling CIOs to set parameters for service levels such as the length of time it takes to retrieve data from a backup.
In addition, a number of best-in-class companies are backing up real-time data to remote locations or servers, or using this type of remote storage for archival purposes. These companies are also implementing all three backup scenarios two to three times faster than laggard companies.
Testing key to IT disaster recovery plans
There are several steps to ensuring that an IT disaster recovery plan will work, according to CDW. First, it's important to conduct a business impact assessment by working with leaders of each functional area to understand the cost and repercussions of losing each category of data.
CIOs should then document configuration diagrams of hardware, software and network components to be used in recovery, and include personnel requirements, travel needs and associated costs. Employees who are critical to continuity operations should be trained to work remotely, even if they don't do so regularly.
Also, consider adding uninterruptible power supplies for critical servers, network connections and select computers, and back up frequently. Look at telecom options such as redundant connections to cover spot outages, and alternatives such as wireless or satellite phones.
Finally, the key to recovery is to test the DR/BC plan at least once every 12 months to make sure people and systems are ready for the unexpected.
System Center 2012 cloud and datacenter management solutions empower you with a common management toolset for your private and public cloud applications and services. System Center helps you confidently deliver IT as a Service for your business. Virtual Machine Manager (VMM) 2012 Beta is a key component of the forthcoming System Center 2012 releases.
Virtual Machine Manager 2012 enables you to:
*
Deliver flexible and cost-effective Infrastructure as a Service (IaaS). You can pool and dynamically allocate virtualized datacenter resources (compute, network, and storage) enabling self-service infrastructure experience for your business, with flexible role-based delegation and access control.
*
Apply cloud principles to provisioning and servicing your datacenter applications with techniques like service modeling, service configuration, and image-based management. You can also state-separate your applications and services from the underlying infrastructure using server application virtualization. This results in a “service-centric” approach to management where you manage the application or service lifecycle and not just datacenter infrastructure or virtual machines.
*
Optimize your existing investments by managing multi-hypervisor environments such as Windows Server 2008 R2 Hyper-V, Citrix XenServer, and VMware vSphere 4.1 in a single pane of glass.
*
Dynamic optimization of your datacenter resources based on workload demands, while ensuring reliable service delivery with features like high availability.
*
Best-of-breed virtualization-management for Microsoft workloads like Exchange and SharePoint.
Virtual Machine Manager 2012 enables you to:
*
Deliver flexible and cost-effective Infrastructure as a Service (IaaS). You can pool and dynamically allocate virtualized datacenter resources (compute, network, and storage) enabling self-service infrastructure experience for your business, with flexible role-based delegation and access control.
*
Apply cloud principles to provisioning and servicing your datacenter applications with techniques like service modeling, service configuration, and image-based management. You can also state-separate your applications and services from the underlying infrastructure using server application virtualization. This results in a “service-centric” approach to management where you manage the application or service lifecycle and not just datacenter infrastructure or virtual machines.
*
Optimize your existing investments by managing multi-hypervisor environments such as Windows Server 2008 R2 Hyper-V, Citrix XenServer, and VMware vSphere 4.1 in a single pane of glass.
*
Dynamic optimization of your datacenter resources based on workload demands, while ensuring reliable service delivery with features like high availability.
*
Best-of-breed virtualization-management for Microsoft workloads like Exchange and SharePoint.
Monday, 21 March 2011
Get on track for working in the cloud with this free Windows Server 2008 R2 study guide, powered by Microsoft TechNet, from ExamForce.
Windows Server 2008 R2 is the server release for Windows 7 and expands the Windows Server 2008 platform, adding tools for virtualization and services critical to delivering technology for organizations as they continue migration to the cloud.
This free study guide covers material in the three Windows Server 2008 R2 Exams:
* 70-640 Windows Server 2008 Active Directory Configuring
* 70-642 Windows Server 2008 Network Infrastructure Configuring
* 70-646 Windows Server 2008 Administrator R2
Windows Server 2008 R2 is the core server platform for companies transitioning to Windows 7 and the cloud. It is designed to capitalize on the move to virtual platforms, providing new web tools, management utilities and scalability enhancements that save organizations of all sizes time and money.
ExamForce brings it all together for you with our latest study guide for Windows Server 2008 R2. This guide provides well organized, concise information in 106 pages, so you spend less time studying and more time learning.
Download link http://www.examforce.com/?page_id=1087&sid=1443
Monday, 14 March 2011
“Everything“, a free tool to search for files or folders on a Windows computer. The most impressive feature that Everything Search Engine has is the ability to list ALL files and folders on the program’s window instantly without any lag. Try exporting the list displayed on Everything from File > Export and then open the text file with Notepad. You will notice that Notepad takes even longer to open compared to Everything Search Engine. The export feature is useful for users that wants to keep track of new files being created or copied to the computer, but do note that ONLY file and folder names are in the exported text file without any other information such as file size, date modified, etc.
For more information and download refer the link.
Wednesday, 26 January 2011
While most Windows developers know of Event Tracing for Windows (ETW) as a logging and tracing mechanism, many administrators have never heard of it. Simply put, ETW includes event logging and tracing capabilities provided by the operating system. Implemented in the kernel, it traces events in user mode applications, the operating system kernel and kernel-mode device drivers.
Event Tracing for Windows is used by a number of core OS components and some third-party applications to provide event logging and tracing. Although it required access to a checked build of Windows to gather ETW information when first released with Windows 2000, more recent versions provide built-in tools with normal (free) Windows builds.
Getting started with Event Tracing for Windows
When diagnosing and troubleshooting Windows Server issues, it seems there is never too much data. The admin is always looking for additional details on what is going on with various components to pinpoint the problem. As such, there are a number of tools like Process Monitor, Process Explorer, Performance Monitor (Perfmon) and Performance Analysis for Logs (PAL) that dig considerably deeper than the event log, but there are times when we need to dig even further down than that.
ETW allows additional instrumentation for gathering data that would not otherwise be available and has a number of advantages. For example:
*
it uses per-processor kernel buffers from a non-paged pool that are not impacted by application crashes or hangs
*
it uses very low CPU overhead
*
it’s available for x86, x64 and IA64 architectures
*
it can enable and disable tracing without rebooting or restarting applications
Event Tracing for Windows may seem like a great tool, but using it is another issue since there is no GUI or user guide. It also requires a few preliminary steps just to produce output that can be used for analysis.
In order to provide useful output you need a consumer. The consumer built in to Windows Server is Tracerpt.exe. As you can imagine, there are a number of flags for Tracerpt to provide specific output formats, so it’s important to become familiar with the Tracerpt and Logman utilities that are native in Windows Server 2003 and up, as well as Windows 7 and Vista.
It’s also important to understand the architecture for ETW. As you can see in Figure 1, the controllers are used to start and stop a tracing session. The tool used to do this in Windows Server 2003 and 2008 is Logman.exe.
Windows Server 2003 also contains a handful of event providers that return specific events, including the following Active Directory-related providers:
* Active Directory: Core
* Active Directory: Kerberos
* Active Directory: SAM
* Active Directory: NetLogon
For instance, specifying Active Directory: Kerberos as a provider will only return Kerberos-specific events.
Event providers differ between Windows versions, however. For example, Windows Server 2003 has 22 providers, while Windows 2008 has 387. This gives more power to the trace and offers more granularities. Yet when it comes to LDAP traffic, the Active Directory: Core provider appears to give the same detail for either Windows version.
You can also combine event providers into a single trace. Since Kerberos authentication was involved in the example above, I used the Active Directory: Kerberos and the Active Directory: Core providers and applied the Logman option-pf, as shown in the following example:
Logman Create Trace CoreKerb –pf c:\etw\input.txt –o c:\etw\coreKerb
For more info refer the link
Subscribe to:
Posts (Atom)
