Sunday, April 12, 2015

Service Manager - Employee Management, Part 1

12:13 PM Posted by A No comments

One of the big payoffs of Service Manager is its ability to feed and leverage Orchestrator so as to know what. This is the part of almost every other blog I see, say "anything" and I'll try my hardest not to in this case. Because I want to talk about Employee Management or perhaps a more direct way of saying it - LETS AUTOMATE ACTIVE DIRECTORY!!!

It's a bold statement to many I'm sure. But I can assure you that day to day AD management is thing of the past as organization come on board with SCSM and SCO. New employees? Returning employees? Terminating employees? All of these mundane tasks can be automated leaving your IT department time to focus on actual IT work. Make no mistake, if you haven't started customizing your Service Manager environment yet then buckle up because you have to in order achieve Active Directory automation through SCSM and SCO. So before we even get into either of those programs, let's get into the SCSM Authoring Tool to start building a custom management pack for your business that you'll leverage to do a few things with...
  • Onboard Employees
  • Terminate Employees
  • Change Employee Titles, Managers, etc.
  • Extend Expiration Dates
  • Reactivate Employees
After all, part of Service Manager's sell is this "Service Request" idea with heavy automation and no less truly customizing the product to your needs. Fortunately there is enough of a "base class" that the management pack we'll build we'll meet enough of these objectives and leave plenty of room for you to innovate within. Anyway, time to get started.

Getting Started
NOTE: Times have changed and so have my opinions. Please read this first -

To begin assembling our management pack, we're going to take the (as I like to refer to it) middle of the road approach via the Service Manager Authoring Tool. I say middle of the road approach as the two alternatives are raw XML writing (probably not something you're interested in learning...yet) and Visual Studio Authoring Extensions (VSAE for short) that requires a fundamental understanding of how management packs are assembled in the first place PLUS programming experience as these plugins are built for Visual Studio (a tool typically used by dedicated developers).

Regardless, you'll need to the get the Service Manager Authoring Tool installed. You can read my setup instructions here since you will run into an issue installing it.

Lets Build the Empty Management Pack...
Alright, now that you the Authoring tool up and running time to start assembling our basics for said management pack. As is standard for Windows apps, we'll start by going to File -> New and giving our management pack a name. You can call it whatever you'd like, just keep in mind as we move forward to substitute what I call it for yours. I'm going to call mine EmployeeManagement. You'll also quickly discover if you didn't like my single word name, that you can't create management packs with spaces, special characters, etc.

Sometimes I think it'd be great if I was done at this point.

So now we have an empty management pack, the next step is to fill it with our customizations! If you are new to the Service manager world you may also be still coming to terms with the idea of Service Requests, Incidents, etc. Suffice it to say this is how you should, if not absolutely need to view the following...
  • Incidents are break/fix scenarios
    • They can be viewed as singular entities
    • They are things like "my laptop blue screened" or "Failed to setup new employee accounts"
    • Your end user community can raise them
    • System Center components can raise them
  • Service Requests typically start with a "I need..."
    • Nothing is broken
    • They are things like "I need a new laptop" or "I need to order a Bluetooth headset" or "I need to hire a new employee"
    • They are by definition requests
    • They entities that are comprised of child work items (in the case of SCSM they are Activities)
    • The activity flow are what you or your management may typically refer to as the request  "workflow"
With the above said, we are going to be working within the Service Request to manage our employees, automate Active Directory, etc and to do so we are going to alter the native functionality of the Service Request class of SCSM. An entirely supported, native, and expected thing Microsoft expects you as a customer of SCSM to do.

Building our Custom Management Pack Foundation...
Next, let's open the OOB Service Request You can do this via the search in the Autoring Tool, right clicking on it, and then hitting "View"

 Now your open management pack selection should look like this...

If you read through the Management Pack Authoring 101 tutorial, we are going to leverage the native Microsoft provided Management Pack to build our custom version of it. To do so, we're going to:

  1. Right-click on the "Service Request" class that we just opened from the native Microsoft Management Pack
  2. Then we're going to hit "Inherit from this class"
Why Inherit? Why not extend? Seems like I'm already doing something wrong

I feel this verbiage could be written a bit better, but regardless I want to quickly explain this difference.

  1. Extend Class - Whatever customization I'm building, I want to appear on EVERY instance of that particular item
    1. Example: I want the Affected User's manager to appear as a field on every Incident form I open
  2. Inherit from this class - Whatever customization I'm building, I want to appear ONLY within the thing that I'm building 
    1. Example: I want to build an employee onboarding management pack, but I don't want the things I'm building to appear on all Service Requests. Because it'd be weird to see "Order a New PC" with this kind of information on it.
With this said - we're clearly choosing Option #2. Hopefully that make a bit more sense? Moving along! After selecting "Inherit from this class" we get the infamous "Your customizations cannot be saved in a sealed management pack." Here's where we pick our empty management pack, as we'll store all the changes we make to this thing. 

The next thing you'll have to do is uniquely name your modified version of the Service Request class. I called mine "ServiceRequestHumanResources" there a few reasons I did this and I don't want to digress explaining them now, but one of the reasons has to do with Orchestrator which I'll get into subsequent posts.

Hurray, the class has been inherited and it's now inside my under development management pack!

Next, I'll give a friendly name to this class by changing the "Class name" and adding a useful description for myself/onlookers of future Service Manager management pack development.

Finally, the last thing we need to do is scroll down within the "Class properties and relationships" area and go all the way to bottom to find and then delete a property that the Authoring Tool creates by default. We need to delete it as you may have noticed in several places the Authroing Tool likes to remind you to "Provide an internal name. This name cannot be changed"

The fact the Authoring tool creates this default property that is already named almost sets you up from failure from the start if you aren't paying attention because you can't rename them! That said, find it and delete it via the red X.

Now Lets Build the Management Pack!
Before we go any further do yourself a favor and hit the Save icon if you haven't already. As you may or may have not figured out yet, the only thing we've done is setup the basis for this EmployeeManagement pack of ours. We haven't done ANY customizations yet, this has all just been prep work for the next steps. So again, this is a great point to hit Save if you haven't already! Alright, now for the fun development part where I won't blame you if ideas start going off in your head for how to ramp up your own version of this management pack as it relates to your organization.

We're going use the "Create Property" button within the Authoring tool and create our first property. Let's start simple and get the obvious stuff out of the way first.

Here I'm creating a property called "EmployeeFirstName" and I'll use it in my Service Requests to as you may have guessed it store the employee's first name as a plain text (string) value. After hitting Create you'll unlock a new window within the Authoring tool listing all the possibilities you have to define this new property.

These are the default settings for any new property we create within the Authoring tool and of course, grants us the flexibility to change the property to suit our needs. If you've never used Visual Studio this is a common Window made available to developers to...well define properties! So with our "EmployeeFirstName" property...
  1. I may want to add a description. I'll see this inside of the Service Manager console once the management pack has been impoorted
  2. I can change the Name to something more friendly, may put some spaces in there so it's called "Employee First Name"
  3. That's good for this property. It's just a first name, not too much to build on this.
So what's next? How about...
  1. EmployeeMiddleName
  2. EmployeeLastName
  3. EmployeeTitle
  4. EmployeeUsername
If you made it through the steps for configuring the First Name property, repeat for the above four properties. I'll be here while you take care of that.

OK, next properties you probably want and may have already thought of...
  1. EmployeeStartDate
  2. EmployeeEndDate
After creating the first or both of those properties, we need to do something we haven't had to do in the previous examples and that's change the DataType of the property. By default everything is a String, but in the case of a date...well we just need to change it to a DateTime property. Just click inside of DataType and you'll be able to select a drop down menu. Lot of options in here!

With the above done, your management pack should look like the following (unless of course you got really giddy when you realized how quickly you could put this together and decided to start building out a bunch of other properties).

Handling the Manager attribute... 

Well yeah, I did those. But I also added one for EmployeeManager. I get where you're headed with this n all.

Sure, that's fine because why wouldn't you, but, BUT! Did you use the same steps as above in that you hit "Create Property"- Because DON'T DO THAT! Instead what you need to do is "Create Relationship"

So why do you need to do this? Technically speaking (and technicalities matter here) you've probably interacted with Active Directory in your career. When you open up a user's account, you see a lot of plain text (string) fields that you can just type into. Other fields such as the "Manager" field of a user, you'll notice AD doesn't let free form text in the field. In fact, you have to use a User Picker, search for another AD account, and then it drops that person in as the manager. That's because inside of Active Directory you are actually creating a relationship between the two accounts. The same exact principal applies here within the Authoring Tool.

So once we've created our first Relationship, we need to modify the Target Class. We'll switch it from Object to Active Directory User.

Handling the Department attribute...

I made one for Departments, because I'd like to be able to select a list of departments or type them in. You know, something like that.

There are at least two ways (that I can think of) that you could do this. So I'll share them and let you be the judge. Even though my bias is clearly built in...

  1. You leave the "EmployeeDepartment" datatype as a String. Then in the Service Offering you build within SCSM, you may call a field "Department" and then select "Simple List". Then you'd precede to add all of your department to it.
    1. I don't like this because it means anytime I need to rename, add, or remove a department I have to go all the way into the in-production Service Offering. It feels like I'm editing something larger, when in truth I'm modifying just this one thing.
  2. In the Management Pack you change "EmployeeDepartment" datatype to be a List
    1. This is the method I prefer, because in doing so I now end up creating another Management Pack that stores this List (and potentially other EmployeeManagement Lists, maybe a Job Status list? Working hours list?) in the same management pack. In doing so, now I can make changes to a list within the Lists pane of Service Manager. In this route, I could have multiple Service Requests/Offerings be driven by a common List
  3. You build some type of QueryResult that pulls Active Directory user's department attributes and dynamically build the selection
    1. I admit, I'm torn on this. It's advantageous because I seemingly then never have to update anything. However what if the HR department creates a new department? In this scenario (I think) I'd have to create a new Active Directory user with that department name to get it to pop in my query result. This seems like more AD management. Then again, if you've delegated rights of AD to the HR department, maybe it's entirely do-able? Call me a control freak but I'd rather keep this specific attribute to myself. Like I said, I'm torn but never the less investigating a logical way to do this.
So I'll show you how to do this via my preferred method (#2).

1. Change the datatype for EmployeeDepartment to "List". Upon doing so, this window will pop...

 2. Then hit "Create List" and give it a name. The internal name has to be unique so make sure you aren't colliding with another List you may have created. I just called mine "Departments".

DONE! That's it. You'll create the other management pack where you store items in the list later (i.e. after you've imported the Employee Management pack because then you'll see "Departments" in the Lists area).

In the next post we'll go over the Service Request Form design so you can see all of these new properties you've just created inside of SCSM, sealing your management pack, importing it, and playing with the new Departments list we've just created. Don't forget, hit the Save button!!!

Part 2 is here


Post a Comment