Microsoft System Center 2012 Service Manager Cookbook

By Samuel Erskine , Steve Beaumont , Anders Asp (MVP) and 2 more
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. ITSM Frameworks and Processes

About this book

Microsoft System Center Service Manager (SCSM) offers enterprises a complete, integrated platform for automating and adapting IT Service Management best practices to your organization's requirements.

Microsoft System Center Service Manager Cookbook provides you with real-world, immediately usable recipes which will show you how to configure and administer System Center Service Manager 2012 and understand how to solve particular problems and scenarios to take this tool further.

In Microsoft System Center Service Manager Cookbook, you will get to grips with practical recipes which will show you how to configure and administer System Center Service Manager 2012. This cookbook features distinct recipes on the practical implementation of ITSM Frameworks and Processes, Microsoft System Center 2012 Service Manager Administration, how to configure Service Level Agreements (SLAs). It will also cover incident and problem management, the design of change and release management as well as implementing and editing security roles.

Publication date:
October 2012
Publisher
Packt
Pages
474
ISBN
9781849686945

 

Chapter 1. ITSM Frameworks and Processes

This chapter provides a background into the creation of processes aligned with ITIL© and MOF (Microsoft Operations Framework) principles, and explains some of the key areas and how they relate to Service Manager; specifically we will cover the following areas:

  • Understanding ITSM frameworks

  • ITIL© processes

  • Creating an Asset Management process

  • Creating a Configuration Management System (CMS) process

  • Creating a Service Request Fulfillment process

  • Creating an Incident and Problem Management process

  • Creating a Change and Release Management process

  • Creating an IT Service Desk process

  • Service Level Management process

 

Introduction


System Center 2012 Service Manager (SCSM) is built on the principles of the Information Technology Infrastructure Library (ITIL©) and the operational principles of the Microsoft Operations Framework (MOF). This chapter discusses the operational execution of these principles in real world implementations.

There are various books and online resources available to you on ITIL© and MOF. The authors recommend you review and research the principles of ITIL© and MOF in the areas in scope of your SCSM implementation.

The goal of creating processes regardless of the framework, is to move your organization or teams from using individual flexible approaches, to using an agreed uniform policy-driven best practice approach to meet your objectives. This approach is usually described as process maturity.

ITIL© is commonly described as an industry recognized process framework. MOF is the Microsoft standard for the execution of the processes typically using (but not limited to) Microsoft products.

 

Understanding ITSM frameworks


This recipe provides a summary analysis of the ITSM frameworks in general and what they mean to each organization.

Getting ready

A general understanding of the objectives of standards and frameworks is required for this recipe.

How to do it...

Plan to invest in one or more of the following:

  • Buy this book

  • Research the subject of frameworks using your preferred method of learning

  • Attend an accredited training course in the subject

  • Adopt and adapt frameworks to your specific organization needs, strategies, and capabilities

How it works...

IT Service Management is a broad term used to describe a process-focused approach to IT management. The goal for most organizations is to implement a service-focused approach to deliver IT dependent services to the end customer.

The industry standard approach for achieving the ITSM objective is to use best-in-class standards as a guide. Examples of common industry frameworks include, but are not limited to, the following:

  • Information Technology Infrastructure Library (ITIL©)

  • Microsoft Operations Framework (MOF)

  • Core Practice

Frameworks are guides and can be compared to the rules of a game (for example, Soccer). In a game, the rules provide a consistent approach but do not limit the individual or team strategy. Another critical factor is individual creativity, which is championed and often leads to a strategic advantage.

ITSM frameworks work best for organizations when the adoption is personalized to the organizations specific strategies and internal capabilities.

 

ITIL© processes


This recipe provides a summary discussion of the current ITIL© V3 processes.

Getting ready

The authors recommend that you read the Understanding ITSM frameworks recipe.

How to do it...

Plan to do one or more of the following:

  • Attend one or more ITIL© training courses in the recommended order

  • Invest in the ITIL© official book(s) and complementary books

  • Use the vast free resources on the Internet

  • Implement and improve your organizational ITSM processes using the ITIL© knowledge as a guide

  • Review and update your processes in line with organization strategies and capabilities

How it works...

ITIL© processes take a repeatable cyclic approach to organization IT Service Management underpinned by continual service improvements. The ITIL© goals are aimed at ensuring that the organization:

  • Plans for services

  • Catalogue and track IT services

  • Introduces new services with minimal risks

  • Manages and operates active services consistently

  • Performs maintenance and updates to existing services with minimum risk and maximum value to the business

  • Continually monitors and improves the services delivered to the business

The official phases of ITIL© are as follows:

  • Service Strategy

  • Service Design

  • Service Transition

  • Service Operation

  • Continual Service Improvement

SCSM is a technology capability enabler of a subset of the ITIL© processes. It is important to follow the principle of: People, Processes, and Products. SCSM is the product that complements your organizations agreed processes and needs people to implement, manage, and continually improve the overall IT service strategy.

ITIL© implementation is not mandatory for SCSM deployment, but an understanding of ITIL© is recommended.

See also

  • Appendix B, Useful Websites and Community Resources provides a list of useful websites for ITIL© and is highly recommended by the authors

 

Creating an Asset Management process


This recipe will provide steps for creating a sample Asset Management process.

Getting ready

For this recipe the authors recommend you read up on the difference between asset inventory and asset management as an organizational process.

How to do it...

Asset Management is a life cycle process, which tracks an IT asset with its associated financial data from when the asset is requested to when the asset is retired as shown in the following figure:

An example of the steps for creating an Asset management process is as follows:

  1. Agree and document the organization's asset management policy.

  2. Document the operational process to support the asset management policy.

  3. Create and assign people roles to manage the process. At a minimum you should plan to include the following:

    • Hardware Asset Managers

    • Hardware Asset Inventory agents

    • Software Asset Managers

    • Software Asset Inventory agents

  4. Identify and agree on an asset register management system. An asset register in its basic form is a manual process. It should capture the following:

    • IT Asset type

    • Financial information

    • Align the IT asset to its financial data

    • Input to a configuration Management system (CMS)

    • Continually aligned to the CMS

  5. Implement Asset Management in SCSM using one of the following methods:

    • Manually extend the Configuration Items (CI) class to include financial data for assets

    • Purchase an asset management solution for SCSM (for example, Provance IT Asset Management Pack for SCSM)

  6. Continually review the policy and operational process. The goal of this step is to improve the process and ensure compliance.

How it works...

Asset Management begins and ends with people and ultimately can cost or add value to a business. A non-IT related analogy is the lessons from retail stock takes, which typically happen annually. The stocktake is the best opportunity for a retail shop to get the most accurate figure for its profit or loss on stock. Two forms of lost revenues are:

  • Damaged goods

  • Missing goods

IT asset management is the stocktake required for all your technological assets, and its resultant analysis for intelligent decision making to provide factual compliance measurements. The IT equivalent of the stock take process is referred to as audits for software and hardware. SCSM with partner extensions or in-house authoring provides 80 percent of the Asset Management for the organization. People and process critically account for the high value 20 percent.

There's more...

There are various tools (products) labeled as Asset Management tools. The true Asset Management tools should have the capability of tracking assets from order to decommission.

Asset Management is an end-to-end process, and the tools are enablers of successful implementation. The successful Asset Management organization programs recognize the full life cycle management of assets.

See also

  • See the Using the SCSM Authoring Tool and Extending Service Manager classes recipes in Chapter 10, Extending SCSM with Advanced Personalization for advanced recipes on management pack authoring

 

Creating a Configuration Management System (CMS) process


This recipe provides steps for creating a Configuration Management System process.

Getting ready

This recipe is focused on a Configuration Management System process using SCSM. The CMS process differs from a Configuration Management Database (CMDB). A CMS combines one or more CMDBs. SCSM implements a CMS within its CMDB by merging data from multiple CMDBs including the following:

  • Active directory (AD)

  • System Center Configuration Manager (ConfigMgr)

  • System Center Operations Manager (OpsMgr)

This recipe is focused on how you create a CMS process with SCSM using AD, ConfigMgr, and OpsMgr.

How to do it...

An example of the steps for creating CMS process is as follows:

  1. Plan to agree and document the organization configuration management policy.

  2. Document the operational process to support the configuration management policy.

  3. Create and assign people roles to manage the process.

  4. Install and configure the CMDB systems in scope (in this example, AD, ConfigMgr, and OpsMgr).

  5. Add the AD capable assets to the AD CMDB.

  6. Discover the AD joined assets with ConfigMgr and deploy the ConfigMgr agent.

  7. Discover the AD joined assets with OpsMgr and deploy the OpsMgr agent.

  8. Configure the AD connector for SCSM and synchronize the data from AD with SCSM.

  9. Configure the ConfigMgr connector and synchronize the data from ConfigMgr with SCSM.

  10. Configure the OpsMgr connector and synchronize the the data from OpsMgr with SCSM.

  11. The CMS example structure is shown in the following figure:

How it works...

SCSM addresses the technology requirements of a CMS process by providing a simplified and consistent framework for connecting multiple CMDBs. In the example the three CMDBs provide information, which SCSM merges to provide a single view of the asset. Using a database server as our asset example:

  • AD provides the computer details and information registered in the AD CMDB

  • ConfigMgr provides information on the hardware and software of the asset (for example, 64-bit operating system with Microsoft SQL Server 2008)

  • OpsMgr provides information on what databases are installed on the computer

SCSM presents a consolidated view of this information to the analyst and is dynamically refreshed by the owner of the data.

SCSM builds the ITIL© process on its CMDB, which is a dynamic CMS. The CMS approach ensures that the data accuracy and management is performed at the source (AD, ConfigMgr, OpsMgr, or other supported connector). This approach removes the risk of data inconsistency typical of other systems where the IT Service Management (ITSM) tool does not automatically synchronize with CMDBs in scope.

See also

  • The Importing active directory configuration items recipe in Chapter 4, Building the Configuration Management Database (CMDB)

  • The Importing configuration manager configuration items recipe in Chapter 4, Building the Configuration Management Database (CMDB)

  • The Importing Operations Manager configuration items recipe in Chapter 4, Building the Configuration Management Database (CMDB)

 

Creating a Service Request Fulfillment process


This recipe provides guidance on creating an organization Service Request Fulfillment process.

Getting ready

Service Request Fulfillment is typically a process put in place to support a proactive approach to providing services to customers.

How to do it...

An example of the steps for creating a Service Request Fulfillment process is as follows:

  1. Agree and document the organization Service Request Fulfillment policy.

  2. Document the operational process to support the Service Request Fulfillment policy.

  3. Create and assign people roles to manage the process.

  4. Create a service catalog of the organization services available to the end customers.

  5. Sort the services by categories. An example of two category types are:

    • Approval required services

    • Non approval required services (standard services)

  6. Agree and establish the organization supported channels for requesting services. Examples of channels include the following:

    • Phone calls into the service desk

    • E-mail

    • Self-service Web Portal

  7. Publish the list of services and provide guidance on how to order services, including approval processes and costs.

  8. Provide training and guidance to the support teams responsible for service request fulfillment.

  9. Plan to review the process and improve the service based on customer feedback and technological advances.

    An example of a Service Request Fulfillment process structure is shown in the following figure:

How it works...

A Service Request Fulfillment process aims to address the proactive goals of ITSM. Some of the common objectives when establishing this process are to:

  • Provide predictable services at a known cost.

  • Engage customers by using predictable published channels of service delivery.

  • Improve the change management processes. A repeatable change request with a low risk known outcome may qualify for a published service request with a simpler approval process.

  • Provide visibility and proactive management of services in the service catalog.

Service requests are typically requests for services that do not require change management, but may or may not require approval. As an example, we can have a process for requesting access to a special printer or a request for premium software.

 

Creating an Incident and Problem Management process


This recipe discusses creating an Incident and Problem Management process.

Getting ready

In Incident Management we focus on restoring a service to its known mode of operation before an unplanned interruption. Problem Management requires you to focus on understanding the actual cause of the interruption with the goal of providing a permanent resolution.

The ITIL© framework books and online resources discuss best practice for Incident and Problem Management processes. You must plan to review and understand Incident and Problem Management principles as a prerequisite to creating the processes.

How to do it...

An example of the steps for creating an Incident and Problem Management process is as follows.

Incident Management

Here are the example steps specific to an Incident Management process:

  1. Agree and document the organization incident management policy.

  2. Document the operational process to support the incident management policy. This should include but not be limited to:

    • Support hours

    • Classification categories

    • Escalation procedures

  3. Create and assign people roles to manage the process. For example:

    • Service Desk analysts

    • Desktop support

    • Infrastructure analyst

    • Service Desk managers

  4. We typically have two channels for incident management:

    • Service Desk team-created incidents using the SCSM console.

      Sample process steps from incident creation to priority allocation are shown in the following figure:

    • Automated or end user self-service created incidents (end user web portal, e-mail, or automatic system event driven).

      Sample process steps from incident creation to priority allocation are shown in the following screenshot:

  5. The difference between the two typical channels is how the incident is initially categorized (triage). The next step "Process Incident" involves the creation of a process flow to match how the incident management team manage the incident based on your policies and procedures. An example is shown in the following figure:

  6. Monitor and report on the performance of the incident management process. The aim is to improve the process and also identify incidents which require Problem Management.

Problem Management

Here are the example steps specific to a Problem Management process:

  1. Agree and document the organization Problem Management policy.

  2. Document the operational process to support the Problem Management policy.

  3. Create and assign people roles to manage the process. For example:

    • Problem analysts

    • Problem managers

  4. Review the Incident Management process with the aim of identifying instances of the following type:

    • Repeated issues over a defined period (for example, monthly, quarterly, or annually)

    • Incidents with known workarounds (typically implies there is an opportunity for root cause investigation)

  5. Perform detailed investigation on incidents escalated to Problem management using internal experts or third-party external support.

  6. Create a change request for problems with known permanent fixes.

How it works...

Incident Management is about getting services that people rely on back to an agreed operational state as soon as possible. An example of Incident Management is a customer who is unable to access their documents:

  1. On investigation we find that the issue is with the laptop assigned to the customer.

  2. We issue the customer with a loan laptop and confirm access to their document.

The previous steps will resolve the incident but we still have a problem. What is wrong with the customer's laptop?

The answer to the question is Problem Management. We use Problem Management to identify the true (root) cause of the issue. Continuing with our scenario from Incident Management:

  1. The desktop engineering team identify the issue as a network hardware device failure in the laptop.

  2. The team also identify that this issue has been happening to a number of laptops over the last quarter.

  3. The team also identify through asset management that we purchase a set of laptops from a vendor and all the issues relate to this set.

  4. We escalate to the vendor and get a driver fix.

  5. A change request is raised to proactively apply the fix to all laptops from the set.

The fix applied to all laptops in scope resolves the issue on the original laptop. We can close the problem and also change the original status of the incident to close. A final best practice will be to create a knowledge article about this known issue and its corresponding fix.

The previous examples illustrate how Incident Management and Problem Management work in practice.

 

Creating a Change and Release Management process


This recipe discusses creating a Change and Release Management process for an organization.

Getting ready

In Change Management we focus on enhancing existing services, service components, or introducing new services and components without an unplanned interruption to existing services. Release Management focuses on when the changes are implemented and manages planned interruption to services.

The ITIL© framework online resources delve much deeper into the best practices for the Change and Release Management processes. You must plan to review and understand Change and Release Management principles as a prerequisite to creating the processes.

How to do it...

An example of the steps for creating a Change and Release Management process is as follows:

  1. Agree and document the organization Change and Release Management policy with the aim of identifying the following :

    • Change types and categories

    • Change type priorities

    • Policy owner

  2. Create and continually update a service map for all services and applications in scope of Change and Release Management. Examples include but are not limited to the following types of services: infrastructure services, messaging, and collaboration services. A best practice industry approach is the RACI model:

    • Responsible (R): Who is responsible for the service or service component?

    • Accountable (A): Who is accountable for the service? This is typically the assigned business unit application owner.

    • Consulted (C): Who is consulted about the service operations? Typically support team acting as the subject matter experts.

    • Informed (I): Who is informed about service availability?

  3. Document the operational process to support the Change and Release Management policy. The operational procedures should include the following:

    • Technical approvers and management approvers

    • Plan for proxy approvers to cover expected or non-expected absence of main approvers

    • Maintenance schedules (approved change implementation windows)

    • Release process structure:

      • By Change stage

      • By Change Type

      • By Maintenance window

  4. Create and assign people roles to manage the process. For example:

    • Change managers

    • Release managers

    • Change implementers (this would be a logical role as implementers will vary based on the change type and related service)

  5. Review the Change and Release Management process with the aim of identifying instances of the following type:

    • Candidates for Service Request fulfillment (changes that have been successfully validated as low risk and low impact based on an agreed number of successful implementation results).

    • Changes requiring re-classification. For example, a minor change that results in a major outage due to an identified dependency service.

    • Release window adjustment due to a business process schedule change. For example, a financial audit application used during peak accounting periods may require a special release window.

  6. The Change and Release Management process once established typically have the following operational states:

    • Initiate

    • Approve

      • Technical (validation from a technical perspective)

      • Management (validation from a cost and business risk perspective)

    • Implement and Release

      • Implementation steps and owners (who does it and how)

      • Release schedule alignment (when it gets done)

    • Post implementation review. For example:

      • Successful in the time allocated

      • Successful but overrun time allocated

      • Failed

    • Resubmissions

The following figure provides an example of the process from the change initiation stage:

How it works...

In Change Management we use Release Management principles to coordinate multiple changes in cases where these changes may impact on each other. We focus on the following areas when creating and implementing Change Management:

  • Organization culture

    • Successful Change Management creation requires complete buy in from the whole organization

    • Exceptions and breaches of Change Management are opportunities to educate and refine the process as appropriate

    • Change Management is a journey not a destination (expect changing conditions and adapt as appropriate)

  • Categorization and classification

    • What type of change, and how it impacts existing services?

    • How important is the change?

  • Approvals

    • Who has the authority to approve?

    • Who has the best knowledge on the impact and risk to the existing services?

    • Cost justification

  • Post implementation analysis

    • Unplanned impact of changes

    • Configuration management updates and service catalogue maintenance

    • Lessons learnt (Knowledge management)

There's more...

Release Management can be:

  • Simple:

    • Manage the forward change schedule

    • Multiple changes that affect the same service component requires coordination

    • Multiple changes grouped and released during the same maintenance window

  • Complex:

    • Extension of application life cycle management

    • New software developed in house

    • Patch Management is a candidate for Release Management

Release Management is a discipline with broad and wide coverage. Best practice for creating the process is; you should plan to assign a release management expert. The process should also have a supported agreed organizational policy.

 

Creating an IT Service Desk process


This section provides an example of what is typically required to create a Service Desk process.

Getting ready

Service Desks are organization specific but share a common goal. The goal of most Service Desks is to be the central point of contact for customers in the following areas:

  • Request for services

  • Unplanned outages or interruptions to services

  • Feedback channels for improvement to existing services

  • Coordination and tracking of active requests and incidents

A prerequisite for creating a Service Desk process is to define what role it would play in the overall ITSM strategy.

Service Desks principles are defined in the ITIL© Service Operations books. Plan to review the industry best practice before creating an organization specific version.

How to do it...

There are three main types of service desks

  • Local Service Desk: Service desk in each customer geographic location, independently managing support services

  • Central Service Desk: One service desk that supports all geographic locations and offers a consolidated picture of issues and requests across the organization

  • Virtual service Desk: Use technology to manage either of the first two types from any location

The successful service desk process is based on communication and coordination. Here are some categories of tools you must plan to implement to support the process:

  • Integrated Service Management and Operations Management systems (For example, the Microsoft System Center Management product)

  • Advanced telephony systems (For example, auto-routing, hunt groups, Computer Telephony Integration (CTI), Voice Over Internet Protocol (VOIP))

  • Interactive Voice Response (IVR) systems

  • Electronic communication (Voice, video, mobile, intranet, Internet, and e-mail systems)

  • Knowledge, search, and diagnostic tools

  • Automated operations and Network Management tools

Here are the common functions the service desk should aim to perform:

  • Receive calls and act as the first-line customer liaison

  • Record and track incidents and complaints

  • Keep customers informed on request status and progress

  • Make an initial assessment of requests, attempt to resolve them, or escalate as appropriate

  • Manage the request and issues life cycle, including closure and verification

  • Communicate planned changes and disruption to services

  • Coordinate hierarchical and functional escalations

  • Highlight customer and service desk personnel training opportunities

  • Monitor and track Service Level Agreements (SLA) and Operational Level Agreements (OLA)

  • Report on customer trends and service desk performance

How it works...

The service desk process, once established, should deliver the following:

  • Act to lower the total cost IT ownership

  • Support the integration and management of the service portfolio and catalogue

  • Make efficient use of resources and technology

  • Optimize investments and the management of business support services

A service desk should aim to provide a unified and simplified experience to the customers it serves.

 

Service Level Management process


Service Level Management (SLM) is the foundation and underpinning element of ITSM. This recipe looks at the common input components of SLM and the deliverables of the process. SLM typically can be applied internally, externally, or both. The external application of SLM can be complex as it typically requires legal contracts with external providers outside an organization. In this recipe our focus will be on the internal execution of SLM.

Getting ready

SLM is a vital organization function. The goal of SLM is to ensure that the customers' expectations are met in line with formal published agreements. We must be able to consistently capture the inputs, and accurately report on the adherence or non-compliance to the agreed SLM objectives. We must have organization buy-in and a full understanding of SLM through official ITIL© material, or appropriate training in the SLM discipline.

How to do it...

SLM is the key to all processes and functions in ITIL©. The common area in SLM is Service Level Agreements (SLA). We will use Incident Management and Service Request Fulfillment as our functions in how to do it:

  1. Agree and publish Service Level Agreements for Incident Management response times and resolution times. The following table provides an example of the SLM inputs for five categories (priority) of incidents based on urgency and impact. The second table provides an example of the SLM inputs for the service request fulfillment.

    Incident Priority

    Target First Response

    Target Resolution Time

    1

    30 minutes

    4 hours

    2

    2 hours

    8 hours

    3

    8 hours

    24 hours

    4

    16 hours

    80 hours

    5

    24 hours

    160 hours

    Service Request Priority

    Target First Response

    Target Implementation

    1

    8 hours

    16 hours

    2

    16 hours

    24 hours

    3

    24 hours

    72 hours

  2. Install and configure an appropriate ITSM tool with SLM implementation capabilities (for example, System Center Service Manager).

  3. Configure the tool with the details of the organization SLM requirements.

  4. Capture the SLM metrics. Examples of some incident metrics are:

    • Number of SLA breaches

    • Average time to resolve incidents

    • Number of incidents per week/month/quarter

  5. Monitor the operational adherence to the SLM metric.

  6. Report and adjust the appropriate execution of the processes to ensure adherence is in line with the agreed SLM objectives.

How it works...

Service Level Management is what we use to ensure that IT capabilities are aligned with customer expectations of the services provided by IT. The successful implementation of SLM involves creating agreements between the supplier of services (IT and supporting third parties), and the consumer of the services (business customers). A driver for successful SLM is when an organization commits to compliance with industry recognized standards. The following standards are typical drivers:

  • ISO 9001

  • ISO 27001

  • ITIL© Certification

The overall goal is to ensure services are delivered at the right cost to the expectations of the service consumers. SLM is at its most effective when we create credible agreements, report proactively on performance of the service, and accurately capture the service consumer's feedback (for example, using customer satisfaction surveys).

About the Authors

  • Samuel Erskine

    Samuel Erskine is a Systems Management Sr Technical Specialist, Trainer and Author , focused on System Center and MS Cloud technologies. Sam is the content designer and lead author of three Microsoft System Center Cookbooks and co-author of two System Center Unleashed books. He’s also a Microsoft MCT , MVP and a regular speaker at community user groups and conferences worldwide.

    Browse publications by this author
  • Steve Beaumont

    Steve Beaumont has worked for more years than he cares to admit within IT, starting with desktop support. He is now the Product Development Director of PowerONPlatforms and a Microsoft MVP within the Cloud and Datacenter Management area, where he helps organizations realize the benefits of the hybrid cloud. He is also a co-author of the Microsoft System Center 2012 Service Manager, Orchestrator and Operations Manager cookbooks.

    His passion for everything about System Center, Azure and IT systems management reflects through all areas of his work, presentation and day-to-day life in the form of new and innovative solutions brought to market by PowerONPlatforms.

    Browse publications by this author
  • Anders Asp (MVP)

    Anders Asp (MVP) is a Principal Consultant at Lumagate AB with focus on ITSM and automation in the hybrid cloud. He is very active in the community and can regularly be seen speaking at different events, teaching courses, blogging on his blog at www.scsm.se, or answering questions on different forums. For his work in the community, he was awarded the Microsoft MVP award in the Cloud and Datacenter area for the first time in 2012 and has since then been renewed as MVP every year.

    Anders has been working with Service Manager since 2009, when the product was still in early beta, and has provided endless feedback to Microsoft and seen the product evolve to what it is today. Besides Service Manager, he is also very fond of the whole Microsoft Operations Management Suite and helps customers embrace the management capabilities it offers.

    Browse publications by this author
  • Dieter Gasser

    Dieter Gasser is an IT consultant and the management partner of itnetX AG, headquartered in Switzerland. He has a strong focus on the delivery and customization of Service Manager.

    Dieter has been working in IT for more than 13 years, and has focused on Microsoft technologies. He started his career as an application and database developer, and later became the IT manager of an international manufacturing company.

    In 2010, he entered the systems management and automation market. With both his technical and managerial backgrounds, he has focused on Service Manager. Together with his colleagues, he delivers data center management, automation, and cloud solutions based on Microsoft System Center to customers all across Switzerland.

    Browse publications by this author
  • Andreas Baumgarten

    Andreas Baumgarten is a Microsoft MVP and works as an IT Architect with the German IT service provider H&D International Group. He has been working as an IT professional for more than 20 years. Microsoft technologies have always accompanied him, and he can also look back on more than 14 years' experience as a Microsoft Certified Trainer.

    Since 2008, he has been responsible for the field of Microsoft System Center technology consulting and ever since has taken part in Microsoft System Center Service Manager (2010, 2012, 2012 R2 and 2016); additionally, he has participated in the Microsoft System Center Technology Adoption Program with H&D since many years.

    With his deep inside-technology know-how and his broad experience across the Microsoft System Center product family and IT management, he now designs and develops private and hybrid cloud solutions for customers all over Germany and Europe.

    In July 2017, he was awarded the Microsoft Most Valuable Professional (MVP) title for System Center Cloud and Datacenter Management for the sixth year in a row.

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now