SQL Reporting - Affected User Report

I'm just going to go ahead and say it - the reports that come out of box with Service Manager does almost nothing in the way of providing value on Day 1.

But then again, neither does complaining about it. So it wouldn't hurt to start sharing some SQL queries to get you going ASAP on your SCSM data warehouse. While their are a host of things you could report on I want to start with a few that you typically would have to do a double take on and say aloud "Wait, that isn't an out of box report?" This is probably going to be the first in a series of said reports so I'll start with something I recently answered on TechNet...

How Do I Get an Affected User Report?

There are a few ways to answer that question, so I'm going to go with the one that gets you a whole lot of data and then leave it to you to remove what you don't want via picking and choosing what's in the SELECT or WHERE statements. Specifically this query will get you the following...

• Get me a list of all Incidents (IR34985, IR34986, etc.)
• For each incident show me the
• Status
• Title
• Resolution Description (will be null if not resolved)
• Incident classification
• Employee (Affected User)
• Employee's Department
• Hours and Minutes to resolve

I like this query because I think it's an absolutely great starting block for building other similar reports such as...

• Show me all Incidents broken up by Department (AD User's Department attribute)
• Show me Average Time to Resolve per Affected User
• Show me Average Time to Resolve per Department
• Show me Average Time to Resolve per Classification
• etc

With that said, this is best viewed as a starting point. It will run on its own as is, but the power is going to come from your selective modifications of it. Additionally, consider this query a quick way to solve the problem. SQL joins aren't done as pleasantly as they could be (i.e. I was lazy and didn't join the Status table and instead just used substrings)

Get to downloading here on TechNet and if you'd like to see the original thread (which is almost verbatim what I typed) you can check that out here.

Update 6.29:
This report was updated on TechNet and I wrote a follow up blogpost as to the "why". You can read it here.

Read More

Service Manager - Employee Management, Part 2

My personal driving incentive here is to familiarize people who have ZERO experience with Service Manager, Orchestrator, and PowerShell - a starting ground from the perspective of someone who has to develop for the entire product by themselves. Don't even get me started on the 18 blogs, 3 TechNet forums, and other places I had to compile in my head just to build a "Create a Shared Mailbox on Office 365" Service Request. Blehhh...well. Now that I think of it, that would probably make a good post. Anyway, back to customizing that EmployeeManagement management pack!

NOTE: Times have changed and so have my opinions. Please read this first - http://scsmmercenary.blogspot.com/2016/02/in-defense-of-class-extension-vs.html

With the definitions of our management pack...uhh....defined. Next we want to customize the Service Request form so that we can interact with these properties from the Service Manager console.

To start, just right click on "Forms" within the custom management we've been building (in this case Forms underneath our EmployeeManagement management pack) and click Add Custom. In the next window that opens, search for "Service Request"



One of those options look familiar? :)

Select "Service Request, Human Resources" and hit OK. If you called your class something else then pick that. What we are doing in this step is defining what the GUI form we see in SCSM is based off of. In picking our custom class, we are building a wholly unique Form with our custom backend properties. This is important as in doing so we'll have a truly custom management pack that can be imported/deleted from SCSM environments. So if you have a dev environment, if you are building management packs for other people, this is how we truly isolate the management pack and its respective customizations. When this post wraps, we'll have a SINGLE file that contains the alterations to the Service Request class (EmployeeFirstName, etc) and a custom Service Request form that displays our new values.

Now before you can fill out the next window that pops up, there is some file management we need to take care of before moving on. Open up File Explorer and navigate to the Authoring Tool installation directory. It should be this...

C:\Program Files (x86)\Microsoft System Center 2012\Service Manager Authoring\Library\ServiceRequest

And then copy this file to the directory where you are currently saving your EmployeeManagement management pack too.

Microsoft.EnterpriseManagement.ServiceManager.Applications.ServiceRequest.Forms.dll

Wait a second, how did you know how to do that. There is no way I would have known to find this file, in this folder...

This is one of my larger criticisms on the Service Manager development front, because it's this kind of stuff that makes SCSM not only look intimidating to outsiders, but it makes less approachable when the only documentation that can only be assumed to exist is TechNet. Even still, this in its own right requires one to invest a fair amount of time (no less if you've never done this before)! This also to be fair is the kind of thing that is part of the "hidden costs" of Service Manager and that hidden cost is development time.

Regardless, now you know this is here! But more importantly you can go up a level and find other familiar classes (like Incident, Change Request, etc) and take what you learn here to apply to those forms as well.

C:\Program Files (x86)\Microsoft System Center 2012\Service Manager Authoring\Library

Let's Build a Form!
Now on that new Window that opened up after you hit "Add Custom" we need to define a few things.

The first thing I've done is given a name to my form, in this case I went with "EmployeeInformationForm". Next, I browsed to where my custom management pack is currently stored (and where I copied that dll too) and select that dll. If you read the file name it's may be rather obvious what we are doing here - taking the original Service Request form (as defined by Microsoft), and making our own derivation of it. Finally in Type we select "ServiceRequestForm" since that dll contains a few different definitions. Then hit Create.

Woot!

Hopefully this is becoming increasingly clearer to you what we're doing. I've expanded my choices within the custom EmployeeManagement management pack and you can see we have our custom properties (defined via Classes) and our soon to be custom form (defined via Forms) present. As always, if you haven't saved yet now is a great time!

Next, we'll need a way to show off and edit our new Classes. Turning to the Form Customization Toolbox, click and drag a Tab Control into the primary request form area, when you see the blue grid, then drag it up into the tab menu just to the right of the History tab. Make no mistake, this is a slightly frustrating part because unlike Visual Studio this dumb downed version strictly for SCSM is not without it's challenges. If you are currently yelling trying to get the Tab Control onto your canvas and to the right of history...well there is no other way to say this. You'll have to keep trying. It's rather annoying but once you do it, you'll never forget. It's a known issue and I can only hope gets resolved sooner or later.

Much like the properties we created, simply by selecting the item we've just added we're presented with a host of options.

I won't waste time going over what all of these properties are (they are rather self-explanatory, so if you're curious just edit one and see what happens!) because we're only after one property here and it's the "Content" property all the way at the bottom. This for all intents and purposes is the text that is displayed on screen in our form. Since it's a display value only, you could call it whatever you like and have spaces in it but for the sake of good naming conventions I'm just going to call it what it contains. Once you've done that (and if you haven't already) double click on your new tab to present yourself with a blank page.

First off, let's just cut to the chase and show you how to display one of your custom classes on this form. From your Form Customization Toolbox pane, click and drag Text Box out onto your form. With the new text box you just dropped onto the form still selected, head over to your Details pane and look for "Binding Path" then click the ellipses in that.

It's worth pointing out that you can also just drag the property from your Class Browser onto the Form canvas and not only will your binding path automatically get set, it will also pull the correct relationship. Time saver!

On the next window, find a property you'd like to represent. Staying true to Part 1's first example, let's go with Employee First Name then hit OK

Next, it wouldn't hurt to grab a Label and name it accordingly...

Before you go on, the following is worth pointing out. While you could easily repeat the above steps and start presenting all of your custom classes - I'd actually advise against it...well from a design perspective at least. You're welcome to ignore me if you really hate design, but chances are you and other members of your IT department wouldn't mind having some consistency within the SCSM Console. Rather than keep dragging labels and text boxes out onto your form, I suggest you first drag a Panel object out onto your form. Then place your labels and or text boxes inside of the Panel object. I say this for one reason and one reason alone - you can either rearrange all of your labels/boxes every time you have to make an update to this form OR you could just move a panel with all of your objects inside of it saving you a significant amount of time when it comes to updating/redesigning your form.

For example, you could drag out two panels - 1 for labels and 1 for text boxes. Then all of your labels you can right justify and all of your text boxes you could left justify. Then you could drag the panels right up next to each other. Then again, you could drag a panel out for every single label/text box pair. The point here is there are a few ways to do this and they are up to you, the designer of the management pack of how you choose to implement.

So what other types of things do I need to present my classes? It's more than text boxes right?

You are absolutely right. How do you know what to use? Easy, visit your custom class page for a great jump start! For example, here's mine (as defined in Part 1)

Employee End Date = Date Time (text box)
Employee First Name = String (text box)
Employee Last Name = String (text box)
Employee Middle Name = String (text box)
Employee Start Date = Date Time (text box)
Employee Username = String (text box)
Employee Department = List (list)
Employee Manager = Relationship  (user picker)

That said, the steps are pretty much the same. You'll always drag out a label, you'll always drag a new type of item out and you'll always define it's Binding Path property. Here's my form as it relates to the properties we created in Part 1.

Finally as an interesting point, if you save the Form as it is right now (i.e. you are on this new Tab you created). When you get to importing the mgmt pack, anytime you open it in the console it will always open on this page. Depending on how you choose to view this it may be desirable for your environment where you want to get to the core of the request asap but may be undesirable if you are building a management pack for someone else.

With the above said, context matters:

• If you want the SR to pop the General tab on open, navigate to the General tab and save your management pack
• If you want the SR to pop on the Employee Information tab, navigate to the Employee Information tab and save your management pack

Alright. So our Employee Management pack is almost ready for production! As a refresher here's what we've done so far...

1. Created an empty management pack
2. Added a bunch of custom definitions to it (Class)
3. Created a relationship between our management pack's XML file and Microsoft's Out of Box Service Request Forms dll (Assembly)
4. Used this relationship to build a custom form to present our custom Class on (Form)

We have only have a THREE steps left before you're ready to import! Let's get to 'em!

Let's Get to XML Editing!
That title probably didn't deserve an exclamation mark, but I digress. After you've made your decision as to what tab you want to pop and you've saved your management pack close out of the Authoring Tool.

What we're going to do next is manually modify the XML that defines our currently unsealed management pack. It's not as scary as it sounds, but it's worth making a copy of the management pack and working with a copy before making these edits. If you don't have/use it, I highly recommend downloading yourself a copy of Notepad++ to make edits these files. You can use native Windows Notepad or other plain text editors if you choose.

Once you have your file open, do a CTRL+F and look for the single word "TypeProjections". It will turn up twice. The following is a screenshot in Notepad++ of said area we're looking for. I've added a hint line so you know exactly how to copy and paste everything following after the screenshot.

<Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAssignedToUser']$" Alias="AssignedTo" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemClosedByUser']$" Alias="ClosedBy" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemCreatedByUser']$" Alias="CreatedBy" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAffectedUser']$" Alias="AffectedUser" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemRelatesToConfigItem']$" Alias="RelatedConfigItems" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAboutConfigItem']$" Alias="AboutConfigItem" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAboutConfigItem' TypeConstraint='System!System.Service']$" Alias="AffectedServices" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemRelatesToWorkItem']$" Alias="RelatedWorkItems">
            <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAssignedToUser']$" Alias="RelatedWorkItemAssignedTo" />
          </Component>
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemRelatesToWorkItem' SeedRole='Target']$" Alias="RelatedWorkItemSource">
            <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAssignedToUser']$" Alias="RelatedWorkItemAssignedTo" />
          </Component>
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemHasFileAttachment']$" Alias="FileAttachments">
            <Component Path="$Target/Path[Relationship='SupportingItem!System.FileAttachmentAddedByUser']$" Alias="FileAttachmentAddedBy" />
          </Component>
          <Component Path="$Target/Path[Relationship='CoreKnowledge!System.EntityLinksToKnowledgeDocument']$" Alias="RelatedKnowledgeArticles" />
          <Component Path="$Target/Path[Relationship='Catalog!System.WorkItemRelatesToRequestOffering']$" Alias="RelatedRequestOffering" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemHasActionLog' TypeConstraint='WorkItem!System.WorkItem.TroubleTicket.ActionLog']$" Alias="ActionLog" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemHasCommentLog' TypeConstraint='WorkItem!System.WorkItem.TroubleTicket.AnalystCommentLog']$" Alias="AnalystCommentLog" />
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemHasCommentLog' TypeConstraint='WorkItem!System.WorkItem.TroubleTicket.UserCommentLog']$" Alias="EndUserCommentLog" />

Next, scroll up to the top to your <References> section and paste everything beneath the following screenshot.

      <Reference Alias="WorkItem">
       <ID>System.WorkItem.Library</ID>
       <Version>7.5.2905.0</Version>
       <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
     </Reference>
     <Reference Alias="SupportingItem">
       <ID>System.SupportingItem.Library</ID>
       <Version>7.5.2905.0</Version>
       <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
     </Reference>
     <Reference Alias="CoreKnowledge">
       <ID>System.Knowledge.Library</ID>
       <Version>7.5.2905.0</Version>
       <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
     </Reference>
     <Reference Alias="Catalog">
       <ID>System.ServiceCatalog.Library</ID>
       <Version>7.5.2905.0</Version>
       <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
     </Reference>

Save the management pack then try to open it with the Authoring Tool. If it opens without error, congrats!

Alright...what did I just do besides copy and paste your answers?

So in the first copy and paste for TypeProjections we are defining the standard out of box Service Request relationships. These exist natively to Service Requests and we're merely just stealing the XML so that our Service Request also leverages these native relationships

In the second copy and paste for References we are creating management pack relationships. A very common thing in the general System Center world. Rather than re-invent the wheel you can leverage management packs already developed and defined by Microsoft for use in your management packs. If you look closely, take note of the "Alias" for each reference. It should make a bit more sense.

Time to Seal a Management Pack!
The thing we've created up until this point is a plain-text XML file. However because our management pack defines relationships, has a bunch of customizations, and we'll probably want to upgrade it in the future we need to seal. As you may or may not already be aware if you overwrite an unsealed management pack, the customizations are lost, and then replaced. With a sealed management pack this won't happen and we'll be able to upgrade over previous versions of the management pack.

The act of sealing a management pack (XML) converts it into a *.mp. This new file is the binary representation of that identical XML file. Once it becomes an mp/binary file Service Manager will prevent us from within the console saving customizations into it (this is a good thing!)

So how do you seal? If you guessed with some type of passphrase that only you know, you're almost right. Instead we're going to have Visual Studio generate a keypair. This keypair let's us digitally sign the file. Now it means that if the XML is signed with another key and tried to be upgraded - it will fail since the signatures don't match. Suffice it to say, host of reasons sealing is awesomely necessary. If you have Visual Studio installed you're pretty much set to do this. If not you can get the tools required to build this keypair via the Windows SDK located here. During the install you'll want to make sure you install Tools located underneath .NET Development.

Finally, once this is all installed you are ultimately looking for the Visual Studio Command Prompt. It's here that you'll be able to do this...

sn –k c:\MyKeyName.snk

Store your keyfile in a safe place! You're going to need it anytime you want to upgrade your MP! Now, back to the Authoring Tool!

Right click on your management pack and click "Seal Management Pack"

Fill out where you want to save the exported MP too (I'm going to suggest the directory you are currently saving the XML version in for the final step), the location for your key file, and finally company information. Optionally you can punch in copyright information. Then hit seal.

ONE LAST STEP (really. I promise.)

Create a Management Pack Bundle
The absolute last thing we need to do is combine our MP + the Service Request dll file we used to build our form. Once combined we're going to end up with an *.MPB file that compromises these two sub files.

To do this, kick open PowerShell ISE and drop in the following...

#ONE: Import Service Manager Cmdlets
import-module "C:\Program Files\Microsoft System Center 2012 R2\Service Manager\Powershell\System.Center.Service.Manager.psd1"

#TWO: Specify the Path and filename of your sealed MP
$mp = "C:\EmployeeManagement.mp"

#THREE: Specify the path and file name of the Service Request Assembly (the SR dll assembly)
$assembly01 = "C:\Microsoft.EnterpriseManagement.ServiceManager.Applications.ServiceRequest.Forms.dll"

#FOUR: Specify target path of the final MPB
$mpb = "C:\EmployeeManagement.mpb"

#FIVE – Bundle the sealed MP and assembly as the MPB file
new-scsmmanagementpackbundle -name $mpb -Managementpack $mp -resource $assembly01 -computername yourSCSMmanagementServerHere

You could run this directly off of one of your SCSM management servers or you could do it the remote powershell way and just add the computername parameter like I did above.


DONE!
Well with the management pack authoring at least! Next we need to build the Request Offering in Service Manager and ultimately the Orchestrator runbooks for the 4-5 requests this management pack is going to support.

Part 3 is here

Read More

Service Manager - Employee Management, Part 1

One of the big payoffs of Service Manager is its ability to feed and leverage Orchestrator so as to automate...you 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 - http://scsmmercenary.blogspot.com/2016/02/in-defense-of-class-extension-vs.html

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. http://scsmmercenary.blogspot.com/2015/02/scsm-management-pack-authoring-101.html

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

Read More