Australian Service Manager User Group. Presentation deck from our Knowledge Event in February 2015. Head to our website to see a recording of the event.

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

2. 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

3. Agenda
Item Presenter Timing
Welcome John Mustac
Systemology
2:00pm
SCSM knowledge
Class System / Data Model
Mat Barnier
Systemology
15 - 30 mins
SCSM Connectors
Best practices
Chris Ross
Cireson
15 - 30 mins
Open Q&A Open 30+ mins
Close 3:30pm

4. SCSM Class Structure / Data Model
Mat Barnier
Director, Systemology
Systemology

6. Agenda











7. Data Model

8. 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

9. 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

10. 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

11. 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

12. Classes Defined in the Model
12

13. Model-Based Database
13
The Common
Data Model for
Service Manager

14. 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

15. 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

16. 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

17. Classes


17
System.Computer
System.ConfigItem
System.LogicalEntity
System.LogicalHardware
Computer_Derived
Computer_ExtendedOriginal
Form
Extended
Tab
System.Device
System.Entity

18. 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

19. 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

20. Cireson Knowledge Share
SCSM Connectors – Best Practices
Chris Ross
Cireson

21. Service Manager 2012 Connector: Best Practices from
the Field
Chris Ross, MVP3, ITIL
Director of Program Management
Cireson

22. 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

23. 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?

24. 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

25. 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

26. Good, Bad Customizations
Good 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

27. 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)

28. 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.

29. CONNECTOR:
DO’S AND DON’TS

30. 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

31. 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)

32. 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

33. 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.

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. Connectors: Don’t Do These Things…
Don’t synchronize data you don’t need!
 When in doubt, use the KISS method!

41. Questions?

42. Audience Knowledge Share
An opportunity for audience members to share information or
knowledge
Guest

43. 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

44. • 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