asmug february 2015 knowledge event

44
Australian Service Manager User Group Knowledge Event February 24, 2015 2:00pm AEDT

Upload: jmustac

Post on 20-Jul-2015

50 views

Category:

Technology


0 download

TRANSCRIPT

Australian Service Manager User Group

Knowledge Event

February 24, 2015

2:00pm AEDT

Objective• To share knowledge of SCSM• To help users get the most from SCSM• To facilitate an Australian wide community that can peer and network• To assist users of Cireson apps get the most from their investments

Spread the word• Tell others about the group• Share items on social• Tell us about topics or questions for future knowledge events

This event is being recorded.

Welcome

Agenda

Item Presenter Timing

Welcome John MustacSystemology

2:00pm

SCSM knowledgeClass System / Data Model

Mat BarnierSystemology

15 - 30 mins

SCSM ConnectorsBest practices

Chris RossCireson

15 - 30 mins

Open Q&A Open 30+ mins

Close 3:30pm

SCSM Class Structure / Data Model

Mat Barnier

Director, Systemology

Systemology

Agenda

Data Model

Model Database

8

• All hardware, software, services, and other logical components that

you want Service Manager to be aware of are described in a model.

• A model is a computer-consumable representation of software or

hardware components that captures the nature of the components

and the relationships between them. In ITIL or MOF these are

Configuration Items (CI’s )

• An example: To Monitor an email messaging service:

• Configuration Level Monitoring

• Involves monitoring a variety of components (mailbox

servers, front-end servers, operating system

components, disk subsystems, Domain Controllers, or

DNS servers)

• Business Service Level Monitoring

• Requires discovering and monitoring the interaction

between these systems, such as monitoring whether e-

mail is flowing through the system.

Modelling in System Center

Service Manager

Model Database

9

• Based on and extends the Operations Manager

modeling system

• Uses the same terminology

• Management pack formats, SDK, API’s and

the database support for all System

Center Modules

• In Service Manager Model Extended to support

• Configuration items

• Work items

• Other

• Further extends support to the model with

additional class extensions and categories.

Modelling in System Center

Service Manager

• Incidents

• Activities

• Releases

• Service Requests

• Changes

• Problems

Work Item

• Business Services

• Environments

• Computers

• Printers

Configuration

Item

Model Database

10

• Work items are the operational category of things

we work with like

• Incidents

• Change Requests

• Activities

• Problems

• Releases

• Service Requests

• They Inherit properties from their parent objects

and extend the model

• They also may have relationships

Work Item Hierarchy

Model Database

11

• Configuration Items are the operational category of

things we work with like

• Computers

• Business Services

• Network Cards

• Databases

• They Inherit properties from their parent objects

and extend the model

• They also may have relationships, we have different

types of relationships to represent different ways

the Configuration Items may relate to eachother

Configuration Items Hierarchy

Classes Defined in the Model

12

Model-Based Database

13

The Common

Data Model for

Service Manager

Management Packs

14

• XML-based file that contains definitions for classes, workflows, views,

forms, reports, and knowledge

• Consists of an XML manifest that defines metadata about these

objects and the references to resources that the objects use.

• Used to extend Service Manager with the definitions and the

information necessary to implement all or part of a service

management process.

• You can use a management pack to do the following:

• Extend Service Manager with new objects.

• Extend Service Manager with new behavior.

• Store new custom objects that you created, such as a form or

a template.

• Transport customizations to another Service Manager

deployment or implement the customizations in a newer

deployment.

Introduction To Management

Packs

Classes

15

• Class = property bag (set of properties)

• Each property is defined as

"name/type"

• Properties are always of simple

types such as int, string, double, etc.

• There are no arrays or sets in a

property.

• A class as defined in the

management pack would look

similar to the following:

Introducing Service Manager

Classes

Classes

16

• All classes require a base class

• Except for the class Entity

• A class will define all of its properties additional to the

properties that have been inherited

• Allowed property values can be further constrained using

property attributes in XML

• MaxLength,

• CaseSensitive,

• MinValue,

• RegEx,

• Required

• In the SCSM model, there are no complex properties.

• Complex properties are emulated using relationship types

Properties and attributes of a

Class

Classes

17

System.Computer

System.ConfigItem

System.LogicalEntity

System.LogicalHardware

Computer_Derived

Computer_ExtendedOriginal

Form

Extended

Tab

System.Device

System.Entity

Classes

18

• Support new types of managed resources or

process artifacts

• Need to add a new behavior.

• For example: managing HVAC units or overhead

projectors would require a new class

• Specialise a new class of incident (called

"HRIncident“) this new subset of incidents will also

require a new class.

• Query for HRIncident, returns the subset of

Incidents called HRIncidents

• New HRIncident class will have a dedicated

set of workflows

• In XML the new class would look like the

following:

Defining a New Class

Classes

19

• Have additional properties and behaviors to add

• If you cannot update the type because it is defined in a

"sealed" management pack

• In XML the extended class would look like the following:

• Adds "DepartmentName" and "MyBugId" to all incidents

and its descendants

• Implemented with the addition of a type Extension.

• The new incidents should behave exactly like an

Incident

• Query returns all classes of incidents including

those derived from the Incident base class and they

all will have the new properties of

"DepartmentName" and "MyBugId."

• When extending the class, all incidents and classes

that that descend from it will have the new

property values

Extending a Class

Cireson Knowledge Share

SCSM Connectors – Best Practices

Chris Ross

Cireson

Service Manager 2012 Connector: Best Practices from

the Field

Chris Ross, MVP3, ITIL

Director of Program Management

Cireson

What are the Various Connectors?

Out of the box…

Active Directory

Configuration Manager

Operations Manager CI

Operations Manager Alert

Orchestrator

Virtual Machine Manager

Exchange

CSV

Cireson Connectors…

SMA Connector

Asset Import

Software Metering

Coming Soon…

Project Server Connector

TFS Connector

What are the Right Questions to Ask?

How Many Objects

What is the quantity of data that will be stored?

Transaction Volume

What are the scenarios?

What is the degree of customization?

How many concurrent, (active) connectors will there be?

Quantity of Data

The bigger the database is the slower every query runs and the more space it

takes on disk.

Contained data is especially impactful to performance.

Computer -> SQL Server -> Database

Container Object Contained Object

Computer 1 SQL Server 1

SQL Server 1 Database 1

Computer 1 Database 1

SQL Server 1 Database 2

Computer 1 Database 2

Good Data, Bad Data

Good Data Bad Data

Incidents (w/ action logs and activities) Users

Service requests (w/o action logs and

activities)

Action logs

Computers from AD or SCCM Contained activities (especially nested)

File attachments Computers from SCOM

Knowledge CI data from SCOM in general

Good, Bad CustomizationsGood Customizations Bad Customizations

User roles Notification subscriptions

Views* Work item event workflows

Data model extensions Custom workflows

Templates Groups

List items* Queues

Tasks* Service level objectives

DW extensions SCCM connectors, especially w/ DCM

Notification templates SCOM connectors

Reports AD connectors

Portal customizations

SLO calendars & metrics Form customizations

Analysis libraries & Excel workbooks

SCVMM and SCOrch connectors

Scoping Connectors

Active Directory

Scope by domain, OU, or security group

Configuration Manager

Scope by collection

Operations Manager – CI Connector

Scope by Add|Remove-AllowedList cmdlets (white listing)

Operations Manager – Alert Connector

Scope by alert property query criteria (alert subscriptions on SCOM side)

Design Better Connectors! [custom]

Query once and do business logic in runtime using one of these

options:

Custom SCSM workflows (PowerShell)

Orchestrator (scale out)

The difference is hundreds of queries running periodically vs. a single

query running periodically. Evaluating A vs. B vs. … in memory on a

management server is lightning fast.

Don’t roundtrip back to the database! Pass in the data that is needed

to the workflow.

CONNECTOR:

DO’S AND DON’TS

Connectors: Do These Things…

Do scope your connectors properly

Properly scoping your connector(s) allows you to ensure

your connectors run error free

Limit each individual connector to ≤ 10,000 objects

If you have more objects, create more connectors

Connectors: Do These Things…

Do schedule your connectors to run at different

times

Running multiple connectors simultaneously can cause

performance impacts (SCSM or source system)

Connectors: Do These Things…

Do schedule connectors to run during non-business

hours

Method 1: Change the synchronization schedule using

PowerShell

Method 2: Initiate the synchronization using PowerShell

http://bit.ly/1DMchhh

Connectors: Do These Things…

Do import AD Users

The AD connector imports all users in a domain, regardless enabled or disabled.

Also if you have contacts in AD that are created as Domain users, these are imported as well.

If is very important to consider which OUs to import, and also whether or not to import both Enabled and Disabled users.

Connectors: Do These Things…

Do use LDAP queries

This will limit the amount of data returned by the connector

Lets only bring in what is relevant

Connectors: Do These Things…

Do use unique accounts for connectors

This will create a separate Monitoringhost.exe process on the workflow management server for each connector when it runs

This makes it easier to see which connector is currently running and how much memory/CPU it is consuming

It also makes it easier to isolate that one process from other workflows/connectors so that it can be terminated without affecting other workflows/connectors running

Connectors: Do These Things…

Do keep Exchange Connector set to 5 min+

If you are using queues for security purposes keeping Exchange Connector set for longer durations allows the needed time for group settings to take effect

Less impact on the Exchange environment

Connectors: Don’t Do These Things…

Don’t import AD Computers (AD Connector)

If you're also using the Configuration Manager connector, there may not be a need for the AD connector to import all computers

Doing so only means SCSM needs to import, rationalize and normalize two sources

All relevant information about the computers are delivered by the SCCM connector

There could be examples where the AD connector needs to import computers or subsets of computers from AD

Connectors: Don’t Do These Things…

Don’t use DCM (really DON’T)There is a Rule which exists in the Configuration Manager Connector Management Pack which is called

Incident_Desired_Configuration_Management_Custom_Rule.Update

This Rule can cause workflows (Subscription Rules) to lag behind a lot and cause the grooming jobs to fail, thus causing the EntityChangeLog table to get very large.

In turn this causes in internal SQL Stored Procedure called p_EntityChangeLogSnapshot to take a lot of time to finish.

This stored procedure is executed very often and while it is running, the performance of the Console is also impacted a lot.

http://bit.ly/1FlY4oq

Connectors: Don’t Do These Things…

Don’t sync null values in AD connectors

Unless needed for a purpose, always select the option: “Do not write null values for properties not set in Active Directory”

Using this setting ensures the connectors do not update the same attributes, despite being null

Connectors: Don’t Do These Things…

Don’t synchronize data you don’t need!

When in doubt, use the KISS method!

Questions?

Audience Knowledge Share

An opportunity for audience members to share information or knowledge

Guest

Open Q&A

An opportunity for audience members to ask questions of the group

Questions can be raised via IM or round table discussion

Open Mic

• Recording• To be posted on Systemology website

• Post questions and topics for next knowledge event• Post on ASMUG page on Systemology website (coming soon)

• Next Knowledge event• April 2015

• Share & Social• Expand the network

Close