Chapter 2: Service Management

Overview

Scenario...

At the North American headquarters of Woodgrove Bank, Neil Orint is on the phone with airport security, frantically trying to track down a stolen unsecured corporate laptop, as he watches 15 new support messages pop up in e-mail. Virus and worm attacks have support costs spiraling, while the lack of required security updates corporate-wide continue to generate more problems and, as he continues to hold, more e-mail.

Neil is Woodgrove Bank's IT Manager in charge of North America; his overall responsibility is to evaluate technology solutions and their impact on core business needs and IT resources. In his Service Management role at Woodgrove, he looks to increase customer satisfaction through the consistent delivery of desktop service, the protection of data, and an overall lower IT cost of ownership.

The bank is considering upgrading to Windows Vista, and Neil is doing research on how Windows Vista might help alleviate some of the problems he is facing. After performing a quick search on TechNet, he finds guidance from Microsoft on how the new features of Windows Vista better enable desktop service management.

NoteService Management for the Desktop is comprised of the technology, people, and process components required to meet business needs. Its purpose is the consistent design and delivery of a technology service at the right quality, cost, and operating efficiency, set by customer expectation. In Service Management, the IT organization is the service provider. The benefits of Service Management can be found in reliable and consistent delivery of WindowsVista desktop service with increased data protection and IT capability, all of which leads to higher overall customer satisfaction.

****

Scenario...

Neil begins by evaluating the current desktop environment at Woodgrove. He meets with Linda Mitchell, the Desktop Configuration Administrator, to better understand the current desktop environment at Woodgrove.

Neil discovers the following deficient areas and identifies their impact on customers:

• Lack of consistent desktop configuration. There is a lengthy mean time to repair because of unknown state; update services cause errors and performance issues because testing is inadequate due to the large variation of images.
• Lack of security policies and audit. There is a risk of potential loss of personally identifiable information and other highly sensitive organizational data.
• Lack of virus and security threat management. Slow response times to detect and deal with virus attacks create downtime, vulnerability of system integrity, and unknown user state.
• Lack of customer service. Issues take multiple phone calls to resolve; uneducated and untrained support staff and/or lack of knowledge of user environment causes long diagnostic time.

Service Management Process

The following steps show the process of defining a desktop service.

Figure 2.1. Service management process steps

Step 1: Gather Business Requirements

Scenario...

In order to solve these problems, Neil surveys Woodgrove business department managers to gather information to analyze current desktop needs. Based on the survey feedback, he is now able to determine the requirements of the WindowsVista desktop service.

Examples of requirements for the Windows Vista desktop service that might be generated from a meeting with the users and business include:

• 7X24 support. Users want their issues to be resolved with first contact or otherwise expect a response within 2 hours.
• Replacement computers. The business wants to ensure replacement computers are available.
• Connectivity and security when traveling. Users need to maintain the integrity of data and remote access connections while traveling.
• Security. This includes measures to ensure confidentiality, integrity, and access to secure data. Organizations are under regulatory pressure to secure all data regardless of the location of laptop or PC, including those that have been lost or stolen.
• Microsoft Office. All users use key applications: Microsoft Office and line-of-business (LOB) applications.
• Internet connectivity. All users access the Internet for connectivity and communication to customers and business partners.
• Backup. Because of the reliance on the desktop and the local storage usage, a consistent backup must occur with known recoverability.
• Protection against malware and viruses. Users must be protected against intrusion and expect IT to automatically protect them with little or no effort on their parts.
• Provisioning and deployment. The business needs the ability to provision and deploy a new WindowsVista desktop with a consistent process and within a pre-determined time frame.

NoteTo determine current desktop capabilities, Microsoft recommends meeting with team members who have accountabilities toward the desktop service. Microsoft Operations Framework (MOF) recommends including team members from all MOF roles. When combined, these perspectives ensure the quality and efficiency of delivering the desktop service. These perspectives identify and capture the tasks required to support the service. The organization must assign each accountability to a specific group or individual.

Step 2: Create Service Catalog Entry

Scenario...

Neil schedules an all-day brainstorming session with Linda Mitchell (Desktop Configuration Manager), Kevin Cook (Security Manager), Ray Chow (Infrastructure Manager), Gurinder Singh (Support Manager), Phil Spencer (Services Manager), and other appropriate team members to begin the process of defining the desktop service. Using the corporate-wide survey feedback, they finalize these service catalog entries for the desktop service.

Exhibit 2.1. Sample Desktop Service Catalog Entry

Description of service	Woodgrove Bank's IT department hosts the entire WindowsVista desktop service infrastructure, giving Woodgrove Bank employees the facility to use desktop computing to accomplish their critical business tasks.
Business alignment	This service is funded as part of Woodgrove Bank's IT operational budget. The service benefits all users by providing a centralized facility for corporate resources such as printing, e-mail, the Internet, and LOB applications using IT-supported hardware and software.
Business owner	The Chief Operating Officer is the business owner for this application.
Service qualification	This service is available to all regular employees of Woodgrove Bank at all locations in North America. Each employee receives either a desktop or laptop computer as required by his or her job function. The computer is loaded with the standard corporate WindowsVista image and the appropriate role-based application package.
Service manager	Neil Orint
Service initiation contact	Service is initiated by the Human Resources department for each new employee or personnel as part of the hiring process.
External dependencies	External dependencies include Internet communication facilities, VeriSign security certificate services, and partner, hardware provider, and maintenance contracts.
Service elements	Service Desk/Incident Management Application availability and metric reporting Application service level agreement (SLA) Hours of service Problem Management Tier 2 escalations and proactive root-cause issue analysis Change Management Technology upgrades Patch management Security Management Security protection: intrusion detection, locked-down security policies Internet-specific security protection: antivirus, anti-phishing, anti-spam Additional service features Proactive health monitoring High-availability management Nightly storage data backup
Services included	Included dependent services: Platform management. Server and remote data backup and archive profile management, management of guideline compliance and end of life policies, equipment procurement, infrastructure planning and capacity management, configuration management, platform compliance management, server hardware operations, server/network security, desktop hardware operations Platform monitoring. System Center Operation Manager
Optional services	Optional services available at additional cost: Microsoft BitLockerdata encryption Customized form and workflow development
Service users	End users of this service include: Woodgrove Bank employees of North America External consultants and project hires who may be given temporary desktop computing facilities
Service priority	Mission-critical Impact from desktop service being down could result in lost customers and negative customer satisfaction due to an inability to complete customer requests or account actions. Poor system performance could delay operations, resulting in potential business loss as well as real productivity losses.
Service pricing/levels	Service is provided with no chargeback to users. Additional non-standard services are cost-estimated for business-justification purposes only.
Service hours	Business hours for service support: Service Desk/Incident Management 24 hours a day, 7 days a week Problem Management 24 hours a day, 7 days a week
How to get end-user assistance for this service	Assistance is available by creating an incident report with the help desk.

NoteService catalogs can take many formsfrom a simple spreadsheet to a highly dynamic Web-enabled application. A basic implementation could be an intranet site with the content organized using Microsoft SharePointservices or a similar collaboration tool.

Step 3: Build a Service Map

Scenario...

Neil and his team move to the next step of building a service map to identify critical components and dependencies within the Woodgrove infrastructure.

A service map (see Figure 2.2) represents a service from the perspective of the business and user. It is divided into 5 sections, or streams:

• Customers. Who are the customers and how are they categorized?
• Hardware. What hardware platforms are necessary to deliver the service?
• Applications. What operating system(s) and other applications are required for the service?
• Settings. What are the discrete types of configuration settings that are needed for the service to function?
• Internal/external services. What components is the desktop service dependent on that are needed to ensure availability?

Figure 2.2. Sample Woodgrove Desktop service map

In addition to the five streams, ownership for each area should be determined where possible. Besides aiding in the drafting of realistic service level agreements (SLAs), operating level agreements (OLAs), and underpinning contracts (UCs), the service map shows critical dependencies, settings, and areas of responsibility. This data can then be used to focus on specific and detailed sections of a service in order to facilitate discussions about service delivery and support topics such as:

• Business impact analysis (BIA)
• Service from the perspective of the business
• Availability Planning
• Service Continuity (Disaster Recovery) Planning
• Release Planning
• Problem Management

The first step in building a service map is to identify everyone who should be included in the mapping exercise. For a desktop service, start with the following individuals or groups as participants:

Desktop Service Manager

Desktop Service Owner

Desktop Administrators

Desktop Architects. Involving key internal service providers and vendors is critical to success. Some groups to include are:

• Network (DNS, DHCP, and so on)
• Active Directory (Group Policy, Authentication, and so on)
• Printing
• Security
• Storage
• Desktop Hardware Vendors

After identifying the participants, a service-mapping session should be scheduled. When scheduling, be sure to allow enough time to obtain proper input from all participants on their respective roles. Fully mapping out a service can be time consuming and sometimes difficult to grasp, but once participants understand the flow the mapping tends to proceed quickly. An effective way to run the exercise is as a guided brainstorming session with a set of questions to generate the flow of ideas. To kick off the session, focus on identifying dependencies that are required to deliver the service as defined by the service catalog entries. The facilitator should also draw out information pertaining to all five streams: (customer, hardware, applications, settings, and internal/external services).

A list of sample questions designed to assist with this process includes:

• What hardware does the desktop service run on?
• What OS versions are currently installed?
  • Service packs
  • Hotfixes
• What applications are running as part of the service? For example:
  • Office
  • Visio
  • Project
  • Microsoft DynamicsCRM
  • Financial, engineering, or other specialized professional software
  • Antivirus
  • Web browser
  • Monitoring or management software such as System Center Configuration Manager or System Center Operations Manager
  • Backup
• How critical are these applications to the customer?
• Is printing required?
  • How much, in terms of volume and frequency?
  • How critical is printing for the user?
  • Do users need individual printers, departmental, or some mixture of the two?
• What other services is the WindowsVista desktop service dependent on?
  • Network
  • Firewall
  • Active Directory
  • Storage
• Are there specific settings that are critical?
  • Security settings
  • Permissions
  • Default printers
• Who are the customers?
• Who owns each of the streams or stream components?
  • Are there service availability or delivery agreements already in place?

While this is not an exhaustive list, it does demonstrate the type of information that is important to generate and capture. A Visio diagram such as Figure 2.2 of the desktop service map is one way to graphically capture and display this information, but it can also be entered into a spreadsheet.

Exhibit 2.2. Sample Woodgrove Desktop Service Map

Access this content as part of the WVSLM download package.

Note A well-built service map can touch every aspect of a WindowsVista desktop service. The goal of a service map is to get a clear understanding of who delivers and consumes the service and what resources are necessary to deliver the desktop service described in the service catalog.

Step 4: Draft Service Agreements

Scenario...

Neil and his team now have the information components necessary to begin drafting the service contract agreements they will need to negotiate with their clients and outside vendors. Neil looks to MOF for guidance and learns that these drafts should not be complex; the goal here is to zero in on three to five items that cause the most disruption for each partythe business and IT.

The three types of service agreements to be drafted are:

Service level agreements (SLAs). A written agreement documenting the required levels of service. The SLA is agreed on by the IT service provider and the business, or the IT service provider and a third-party provider. SLAs should list the metrics and measures that both parties use to define success.

Operating level agreements (OLAs). An internal agreement that supports the SLA requirements, usually between one or more IT teams.

Underpinning contract (UCs). A legally binding contract in place of or in addition to an SLA. This contract is with a third-party service provider on which service deliverables for the SLA have been built. UCs are covered in more detail in Chapter 8: Partner.

Some points to consider when starting the drafting process include:

• What is this customer's anticipated satisfaction level (1–4 with 4 being Very Satisfied)?
• What are the biggest issues this customer causes IT?
• What are the biggest issues that IT causes this customer?
• What vital business functions (VBFs) (those activities that must be available for the business to meet its objectives) for this customer depend on desktop computing?
• How would success be measured?

These questions are designed to uncover problems and provide opportunities to achieve some quick wins in the SLA process. The first SLA should be designed to initiate a two-way flow of information between the business and the IT service provider. Additional sample survey questions can be found below.

Exhibit 2.3. Sample Woodgrove Survey Questions

Access this content as part of the WVSLM download package.

Here is what should be included in a first SLA:

• Contact information for both parties
• A service description
• SLA duration
• IT roles and responsibilities
• Service hours and exceptions
• Availability targets
• Reliability targets
• The complaint process
• Change process:
  • How will changes to the SLA be handled
  • How much notice is given
  • Who is notified
  • Who can approve
  • Who can request
• Outages:
  • How are outages handled
  • What is the expected recovery time by severity
  • How does escalation occur and who can escalate

Exhibit 2.4. Sample Woodgrove Desktop SLA

Access this content as part of the WVSLM download package.

The metrics used to measure service delivery success will vary but should be tied to the contents of the SLA. Below is a table of sample metric types for a desktop service.

Table 2.1. Sample Metric Types for a Desktop Service

Measure	Example
Service availability	Actual availability/target availability (not including maintenance windows) percentage
Support responsiveness	Average time to first contact Average time to resolve Average to workaround
User satisfaction	Overall satisfaction percentage Overall dissatisfaction percentage Trend over time
Security	Total failures due to security-related issues
Printing	Total print jobs Average number of print jobs per month Total failed print jobs Average number of failed print jobs per month

Evaluate the SLA measures using the following criteria:

• Do they support the business objectives?
• Are they specific?
• Can they be measured?
• Are they attainable, even if this requires significant effort on the part of IT?
• Are they realistic in relation to the benefit they will bring to the business?

Figure 2.3. Relationship between the SLA, OLA, and UCs

Effectively drafting OLAs and UCs is largely the same process as drafting an SLA. In simple terms, IT should consider the UC as an SLA with the vendor. The UC is often a legal, binding document that is usually far more complex than the first SLA. It is critical that UCs be developed to identify the internal and/or external IT services that affect the delivery of the WindowsVista desktop service.

Availability targets need to be agreed upon with the business. Always keep in mind that the underlying availability goals must be higher than the agreed upon targets. This is very important and is best illustrated mathematically. Assume that a service with an availability target of 99 percent has three dependent services. If each of the underlying services is targeted at 99 percent availability as well, the best achievable overall service availability would be:

Overall Service: S1(.99) x S2(.99) x S3(.99) = .97 or 97 percent

Step 5: Negotiate Service Agreements with Customer

Scenario...

Neil Orint has defined a desktop service, built a service catalog, and developed draft SLAs and OLAs using the help of a service map. He is ready to sit down with his IT peers to formalize and agree on the draft OLAs and with his customer to formalize and agree on the draft SLA.

Since the OLAs provide the foundation for meeting the targets set in the SLAs, it is best to negotiate them first. The goal is to make the internal groups aware of the impact each of them has on the desktop service and to reach agreement on how the desktop delivery team and its dependent teams will collaborate to deliver a successful service to customers.

Underpinning contracts (UCs) more than likely already exist between the business and partners. If it is determined that the existing agreements do not provide appropriate support for the WindowsVista desktop service, proper legal re-negotiation is needed.

An important point here, especially if Service Management is a new concept in the organization, is to keep the initial agreements concise and focused on the three to five critical factors necessary for the success of the desktop service. Another point to keep in mind is that the relationships being formalized in the negotiation process should be collaborative and focused on the business's overall success in meeting its objectives.

Negotiating OLAs

OLA discussions should focus on the shared responsibility everyone in IT has for delivering quality, cost-justifiable services to the business to help meet organizational targets and objectives. In the beginning, it may make sense to limit the number of OLAs to the three or four that are most critical to the successful delivery of the desktop service. These will vary but four that are always likely to be high on the list are:

• The Active Directory team.
• The Security team.
• The Network team (there may be multiple OLAs due to the breadth of services most Network teams deliverfor example, DNS, DHCP, LAN, WAN).
• The Line of Business Applications team.

It will likely be necessary to educate the other IT groups on the value of OLAs and the impact they have on the successful delivery of a WindowsVista desktop service. Use the service map to help illustrate the relationships and dependencies. Show them the draft SLAs and OLAs and how the latter contributes to the former. It is important to discuss the following:

• Supporting services need to be performed at the level required by the desktop service. OLAs provide formal agreements with clear expectations for both groups.
• OLAs align all services necessary to deliver a service with the business's critical success factors (CSFs) and vital business functions (VBFs).
• OLAs allow the team to set realistic goals for the level of service they can provide to the customer.
• OLAs provide a good process for managing escalations.

At this stage in the meeting, obtain buy-in and agreement with the above points before going on to discuss OLA specifics. If the other party is hesitant, confused, or defensive in any way, now is the time to draw that out. Once it is clear that other IT group decision makers are receptive to the concept of an OLA, the discussion should shift to specific aspects of the draft OLA and how it supports the overall service. Some suggested areas to focus on include:

• Duration of the agreement.
• Contact information for customer, desktop service, and IT owner.
• Service definition.
• Defined roles and responsibilities of the IT desktop support group.
• Service hours, exceptions, and coverage during off hours.
• Availability targets.
• Reliability targets with maximum expected interruptions per month.
• Signature page.

In the beginning, it may be difficult to get the supporting group decision maker to sign the OLA. This should not stop the process. An agreement to use the OLA as a framework for how each party will support its mutual customer is a great win. Strive for formal signed agreements wherever possible, but it may be necessary to prove that the process has mutual value first. If so, keep the OLA as a draft for an agreed period of time with regular reviews of its effectiveness.

Negotiating an SLA

The process of negotiating SLAs is not much different from that of negotiating OLAs. The main difference is that the customer will more than likely have little depth in the technology areas covered by the SLA.

First, explain to the customer why concise, focused SLAs are necessary for a WindowsVista desktop service. Many people may be familiar with long, multi-page SLAs that everyone knows exist but no one can find. This perception of an SLA will need to be addressed before a meaningful discussion about SLAs can take place. Customers will also need to be educated about the concept of IT Service Management and how a computer running WindowsVista as part of a desktop service will benefit them. The best way to address these issues is to begin by asking the customer the same questions used to start the SLA draft activity:

• What is your satisfaction level with the current desktop service? What are your biggest issues with IT?
• What are the biggest complaints you hear from IT?
• Which vital business functions (VBFs) depend on desktop computing?
• How would you measure a successful desktop service?

Use the answers to these questions to list the high-level components the customer wants in the desktop service. Do not go too deeply into the technology here or some customers may get lost or lose interest. A sample set of components for a desktop service is below:

• Desktop computers
• Laptop computers
• Windows XP or WindowsVista
• Microsoft Office applications:
  • Word
  • Excel®
  • Outlook®
• Customer relationship management (CRM) client applications
• LOB applications
• Printing

Brainstorm the list of components with the customer: Which components are most important to the service? A great way to frame this question is in the context of their answer to the satisfaction question above. Try to uncover their top three concerns with the current desktop situation.

The next step is to share the service map with the customer. This should illustrate the depth of thinking that has already gone into the end-to-end delivery of a WindowsVista desktop service. It should, hopefully, reflect the top concerns the customer raised about the desktop. It should also reflect the customer's own perception of the different types of desktop profiles necessary to deliver the service.

At this point in the process, the customer should understand the benefits of an SLA and trust that the desktop service owner understands his or her needs. If there is concern about the customer's level of buy in or understanding of the process, the same techniques used in the OLA negotiationfor example, targeted questioning, brainstorming, mind mapping, backward imagingcan be used to draw out and alleviate the concerns.

An important point to consider about availability goals is that many business customers will say they want 100 percent availability because they are not aware of the costs involved in higher availability numbers. Use the following Nineschart to help frame the conversation about the decreasing impact (and increasing costs) of higher availability numbers.

Table 2.2. Uptime Calculation for Nines of Availability Part 1

	Days/year	Days/year	Hours/year	Minutes/year	Hours/ month	Minutes/ month
	365	365	8,760	525,600	730	43,800
Percent Uptime	Uptime (days/ year)	Downtime (days/ year)	Downtime (hours/ year)	Downtime (minutes/ year)	Downtime (hours/ month)	Downtime (minutes/ month)
99.00%	361.35	3.65	87.6	5,256	7.3	438
99.90%	364.635	0.365	8.76	525.6	0.73	43.8
99.99%	364.9635	0.0365	0.876	52.56	0.073	4.38
99.999%	364.99635	0.00365	0.0876	5.256	0.0073	0.438

Table 2.3. Uptime Calculations for Nines of Availability Part 2

Change in Nines	Uptime gain in days/year	Eliminated downtime in days/year	Eliminated downtime in hours/ year	Eliminated downtime in minutes/year	Eliminated downtime in hours/ month	Eliminated downtime in minutes/ month
2 to 3	3.285	3.285	78.84	4,730.4	6.57	394.2
3 to 4	0.3285	0.3285	7.884	473.04	0.657	39.42
4 to 5	0.03285	0.03285	0.7884	47.304	0.0657	3.942

The ideal outcome of this meeting is a refined and signed SLA. However, that may not be possible without some period of piloting the agreement. This is perfectly acceptable as long as there is a frequent review process and the conditions that are necessary to move the agreement to a more formal condition are detailed in advance.

NoteThe Pilot SLA is an SLA put in place for a subset of the organization and designed to introduce the SLA concepts in a controlled fashion with the goal of refining the SLAs and making the client group aware of the process. These are usually of short duration (three to six months) and have frequent reviews to quickly incorporate lessons learned.

Table 2.4 summarizes the inputs, tasks, and output involved in negotiating service agreements.

Table 2.4. Negotiated Service Agreements Inputs, Tasks, and Outputs

Inputs	Tasks	Output
A Desktop Service Map Draft OLAs Draft SLAs	Negotiate OLAs with internal service providers Negotiate SLAs with customers	Formal (preferably signed) OLAs Formal (preferably signed) SLAs Agreed schedule for OLA and SLA reviews

Step 6: Review and Continuous Improvement

Scenario...

Neil and his team have successfully launched the pilot SLA with the Financial Analysts group. They have set up bi-weekly reviews for a three-month program duration in order to refine the process and reach a finalized formal SLA.

During this pilot SLA and as part of the initial implementation of a desktop service, it is important to define CSFs and KPIs in order to understand the success criteria of the project and be able to measure and report on its success. Post implementation, ongoing reports should be generated examining the new service against these defined criteria to determine the continuing success of the service and areas for improvement.

Critical Success Factors and Key Performance Indicators

The following critical success factors (CSFs) and key performance indicators (KPIs) should be tracked to measure the success of the Desktop Service.

CSF:

• Deliver a desktop service that meets the requirements of the customers and the business.
• Deliver a desktop service as agreed to by the customer and business.
• Provide a desktop service at an acceptable cost to the business.
• Provide a feedback and continuous improvement mechanism to consistently identify service efficiencies and cost savings.

KPI:

• Overall Customer Satisfaction Rating for the desktop servicetypically generated through survey results.
• Percentage of SLA desktop service targets met = 1 – (# of SLA targets missed / # of SLA targets met)Total cost of desktop service as measured from the acquisition to the retirement of the asset. Include fixed costs such as hardware, operations, support, and variable costs such as management and administration of the service agreements. Percentage of service reports generated on time and appropriate responses taken. Service performance reports should be generated at least twice a year. Service improvement opportunities should be identified and launched as appropriate.
• Total cost of desktop service as measured from the acquisition to the retirement of the asset. Include fixed costs such as hardware, operations, support, and variable costs such as management and administration of the service agreements.
• Percentage of service reports generated on time and appropriate responses taken. Service performance reports should be generated at least twice a year. Service improvement opportunities should be identified and launched as appropriate.

Scenario...

Woodgrove Bank executives were so pleased with the desktop service implementation, they asked Neil to identify further efficiencies and cost savings for the desktop service. Neil went back to TechNet and found the MOF Continuous Improvement Toolkit.

Microsoft recommends designing a service around a standard corporate image to deliver all the required functionality in a highly managed, highly available solution. This image can be locked down to provide consistent deployments, patching, and support. These variations of the desktop service should be displayed in the service catalog and used as the launching point for SLA discussions with the business.

Further, as part of the Operations Assessment process, service owners should be continuously looking to identify further efficiencies and cost savings for the newly implemented desktop service. One tool available to assist with this process is the MOF Continuous Improvement Roadmap, which is available at https://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/index.mspx.

The MOF Continuous Improvement Roadmap

The MOF Continuous Improvement Roadmap (CIR) is a vehicle to help make the continuous improvement of IT services more achievable. The primary goals of the Roadmap are helping customers to be successful with the Microsoft platform while providing and applying linkages into existing and established service management best practices. The roadmap provides an assessment model and a service improvement model. An organization can use the CIR to identify weaknesses and establish a plan to improve their service. Specific focus is given to how people, process, and technology affect the quality of service to the business.

The following is a diagram of the MOF Continuous Improvement Roadmap.

Figure 2.4. MOF Continuous Improvement Roadmap

Scenario...

Neil and Linda continue to work on creating secure, locked-down, computer-user profiles, roaming computer-users profiles, and a unique laptop profile for the Financial Analysts team at Woodgrove Bank, using new WindowsVista features that enhance and simplify the tasks involved.