Service Manager

Write Conflict

Aaron Croasmun is a epic level contributor to the Service Manager forums, and he’s helped me personally out on several occasions.

Now, much like Prometheus (the allegory, not the terrible film), he has gifted for us something that will change the very nature of humanity. Ok, well, just the people who use service manager anyways.

Aaron has single-handedly solved the “This item cannot be updated because it has been changed by another user or process” write conflict error.

<pause for the shocked murmur of disbelief in the audience to die down>

Anyone who wishes to leave now and secure a copy from Technet Galleries may be excused. (more…)

MP Variables and MP References

Another forum thread documentation post.

Why are the expansion strings were not replaced in notification templates? In the context of the post, it became clear that the poster had copied the strings from one notification template stored in one of the default MPs into a new notification template stored in a custom MP. Why wouldn’t this work? it’s just computer code things that the system will interpret, why should it care where it is?

Well, let’s start with a breakdown of those strings. they’re actually OMSDK variables that are replaced at run-time with data from the system. to break it down (spaces replaced by BR for readability) :

$Context/Path[Relationship='WorkItem!System.WorkItemAffectedUser'
SeedRole='Source'
TypeConstraint='System!System.Domain.User']/Property[Type='System!System.Domain.User']/FirstName$
  • $ starts and ends a variable. It’s primarily a delimiter for the variable engine but is also used to surrounding meta-properties (i.e. the internal ID can be directly referenced as $ID$) and possibly some other use cases.
  • Context is one of the keywords that control the behavior of the variable. Service Manager is based on the OMSDK, which means the Ops Manager variables (Other Reference) (Yet Again) are the basis for these. Context is new for service manager, and is largely undocumented, but in most situations can be read as the root element of the projection that is the data context of the reference.
    For a form, the forms data context is a projection, referred to as the form’s projection target.
    For a notification template, it’s the projection that is the target of the notification template.
  • Path[] means we are going down the projections path. This allows us to look at related objects in the projection, rather the just the root element.
    • Relationship modifies path by specifying which relationship to follow in the brackets with the Relationship element. This needs to be an MP Reference. more on that later.
    • SeedRole modifies path by setting which side of the relationship the starting objects is on, in this case, the “context” is the source of the relationship, rather then the target.
    • TypeConstraint filters path based on what’s on the other side of the relationship. Yet another MP Reference; this will be important later. In this case, it must be a user.
  • Property[] means we’re reading data from a property of this user, as opposed to pathing down another relationship.
    • Type modifies property by controlling which class definition to get the property set from. Each side of a relationship is defined as a specific class, but any class that inherits from that can also be related. i.e. the most common user class is Microsoft.AD.User, which inherits through a lineage of classes.
  • The last entry is the property name to get data from, i.e. the FirstName property. this needs to be the internal name of the property, not the display string. The internal name is always in American English, because Microsoft and most of it’s programmers are in Redmond, WA. internal names will also have no spaces or special characters, because those might break the surrounding code. Imagine if the internal name of a property contained >, ], or “, characters typically used to end references.

So why do I keep babbling on about MP References? Well MP references consist of two parts, separated with an Exclamation mark (!). The bit to the right is the name of the element and is required. the bit to the left is the Management Pack Alias, and is omitted, along with the bang for elements in the local MP.

The particularly swift (or well informed) reader will already notice that the MP Alias definition isn’t in the code of the notification template. it’s local to the MP, not a global object, and it’s stored at the top of the management pack. It should be clear why copying a notification template using the UI will fail if you store the new one in a different MP; ‘Workitem!System.WorkItemAffectedUser’ is only valid if the MP alias ‘Workitem’ already exists in the new MP, and points to the MP that contains the element ‘System.WorkItemAffectedUser’ that defines a relationship.

But wait, why does reinserting the sometimes fix the issue? well the insert button is looking for existing MP Aliases, and adding new MP aliases behind the scenes if it can’t find an existing one, but the aliases the console throws in are not always the same as the aliases you want. The console created alias will often look like “Alias_150d3d58_e565_44f1_90da_c4f4181416f9” not “workitem”.

So where do those American English human readable alias in  names come from? Human American English Programmers.

Dependancy Inversion in Service Delivery

My college over in Application Development published a blog post on the corporate blog on the Dependency Inversion Principle, and the benefit of applying this to API contracts. I do a lot of work in System Center Service Manager, which is unsurprising to anyone who has seen this blog, and this post got me thinking about the social contract between service desks and the user base.
(more…)

Anatomy of a view

I posted this over on Technet Forums, but I figured it would be a good idea to archive it here as a reference. I’ll probably be doing this a lot more, At least until a pay the Aaron back for Helping Me

The question came up how to Copy a view. this gave me a good opportunity to drone on a bit about how a view works in XML, and what each part means, at a high level. Forewarned: we’re going to get dirty and crawl into the XML.
(more…)

Things Service Manager needs

In light of The Phoenix Post over at Technet blogs, I figured now would be a good time to start recording things I wanted to see in SM. This is my running list of improvements, advancements and enhancements that I want to see in service manager.

It should be noted that I don’t think any of these are required or essential. Service Manager is extremely flexible and has the ability to compete with the best ticketing systems on the market. Moreover, it’s the only ticket system (to the limits of my knowledge) that is both strongly typed enough to implement ITIL best practices, and flexible enough to allow companies to completely ignore them. That being said, it’s also kinda rough in some places, and these are the places I want to see polished for Service Manager V.Next: (more…)

Service Manager 2012 SP1 CU4 and System.IO.Exception

Update: Looks like Anton talked about this in a recent blog post. I feel like I’ve won an insignificant victory by being a good 6 months ahead of him on this. Original article Published on: Dec 26, 2013 @ 15:26.

For those of you not aware, SCSM 2012 SP1 CU4 (or UR 4, depending on who you ask) was released in the middle of November. I’ve been heads down on a current project, so I just recently discovered it. In patching a development environment, I ran into the following error:

CU4-IOException

The referenced exception is System.IO.Exception. This is a generic category for any IO operation throwing an exception. This particular error cropped up immediately after accepting the EULA, and was consistently occurring on the test systems.
(more…)

HealthService 1200 and 1209 errors

see update at the bottom of this page:

Management Pack with id: “{<GUID>}”, version: “{<GUID>}” has been requested “<LARGE NUMBER>” times. Management Group “SMProd”. 

This is kinda a bane of my existence right now. Operations manager (and by extension, Service Manager, which runs on the same engine) distributes MPs to registered agents in a largely undocumented process that populates the Health Management State folder. Sometimes this fails, and it’s not really clear why, but it seems to be happening a lot more since 2012 SP1.

The reason this is a problem is that an agent that can’t get an MP will assume the health state isn’t up to date, and will never start any workflows. For Ops Manager, this means no health checks, no reports back to the management servers, and a grey mark in the health explorer. For Service Manager, the agent on the workflow management server executes workflows that do background maintenance, such as advancing activities, processing votes, populating connectors, and generating notifications.
(more…)