In the Integration Pack for Service Manager 2012 there is a activity to upload attachment, you can also look at attachments with the Get Object activity. But what you are looking is just the object, not the context of the file. For example you can see that incident IR123 has a related file (System.FileAttachment), you can see some properties of the file, like name and size, but you cant read it. This has been a challenge in a number of scenario. A couple of days ago I asked Patrik if we couldn’t do something about it and today he uploaded the first public version of a Powershell script. This Powershell script, Get-FileAttachments, will dump all file attachments to a folder. It works with both work items like incidents and configuration items like Windows computers.

One scenario that I read about in the forum a couple of days ago is the fact that attachments are not moved to the data warehouse in Service Manager. Instead you need to archive them before the work item or config item is moved to the data warehouse. There is no built in feature for this. But with a simple runbook in Orchestrator and the get-fileattachments script it is solved 🙂

This example monitor Service Manager for incidents that is updated with a new status that is equal to closed. The runbook then checks if there are any related file attachments, if there are, the script is triggered. The script that I run as a command in this example gets the SC Object GUID from the Monitor Closed Incidents activity as input. C:\SCSM_Archive is my archive folder where all attachments are stored. The scripts creates a folder named as the incident and stores all files in the folder.

Some time ago I wrote a blog post about converting incidents to service requests. That is a scenario where you also would like to include this get-fileattachments script, to make sure all attached files are moved to the other work item too. You can build activity and a integration pack on the script too, see this blog post for a example

You can download the script here.

A couple of weeks ago I was working on a scenario were we needed to add a review activity to a service request with Orchestrator. Part of the solution for that scenario were a couple of runbooks that I want to share in this blog post. These runbooks adds a new review activity to a existing service request. All runbooks require a input parameter when it starts, the service request ID. These runbooks set the domain admins group as reviewers in the new review activity.

When adding a new activity to for example a service request it is always added as the first activity. If there are already two activities the new activity is added before them, in other words the new activity is the one that will run first. You can control this by working with the sequence ID parameter. The first activity have value 0 and the second have value 1 and so on. If two activities have the same value they will run at the same time. You can update activities already existing in the service request and insert the new activity in any order you need, as the 70.2 runbook do.

This example is built on three runbooks.

• 70.1. This runbook adds a new review activity to a existing service request. The new review activity is added as the first activity (sequence ID equals 0) and the Domain Admins security group is set as reviewers.
• 70.2. This runbook is used to update current activities with a new sequence ID. The runbook simple add one (+1) to each sequence ID value. This is because in the example we want to add the new activity as the first activity, as we add one to each existing activity there will no longer be a activity with sequence id equals 0. We can then create the new activity and add it with sequence id equals 0.
• 70.3. This runbook is used to get current activities and each sequence ID. The result is written as platform events. This runbook is not really needed but it is nice to have to see the current configuration

The result is that a new review activity is created in the service request. Domain Admins are set as reviewers on the new review activity.

You can download my example runbooks here, 20120730_addActivity_Sanitize , please note that this is provided “as is” with no warranties at all.

In this blog post I show how activities in a service request can be updated by a runbook activity, for example dynamic approval steps.

One of the most common tasks for an IT department is administration of security groups. Security groups are used to control access to most of today’s applications. Memberships of some groups are modified often, for example group that control access to project work spaces. Often I see this modification handle as a request to service desk that service desk either does it manual or they escalate it to 2^nd line that does it manually. Often it is done direct in Active Directory Users and Computers whit a user account that has unnecessary high permissions. The risk of human errors are always there, as often the Active Directory tool is run with a high privilege account and the engineer modifying the group can misunderstand what to do.

In this blog post I will show a idea how to handle group management with the self service portal in Service Manager and configure Orchestrator to execute all modification. A nice benefit by using Service Manager is that you get tracking of everything, who submitted the change, who approved it and so on. A nice benefit of using Orchestrator is that is will be done the same every time and no manual steps are required. In this example a manager, a user that is configured as manager on a security group in Active Directory can, with the self service portal in Service Manager

• Add member to security group
• Remove member from security group
• Request a list of members of a security group

I wrote a blog post a couple of weeks ago around password reset with Service Manager and Orchestrator. This idea around group management is very similar to the password reset idea, for that reason I will not write down all the steps again. Look at the password reset post how this build the integration between Orchestrator and Service Manager. One difference compared with the password reset post is that I use Business Phone instead of Pager to store the manager value. That is affect both runbooks and when you build the portal offering,

The group management idea is built on a number of runbooks

• 10.1.1 Invoke 10.1.2 and 10.1.3 to list group members, update the service request and then send a updated list of members to the manager
• 10.1.2 List group members. This is done with a customer assembly. The Active Directory integration pack includes a “Get Group” activity, but it do not get members of the group, only the group itself. I created a new activity that use Powershell to list group members.
• 10.1.3 Updates the service request with a new description
• 10.1.5 Handle add member to group
• 10.1.6 Handle remove member from group

List group members

A manager navigates to the self service portal and request a list of group members. The manager can select only groups where the manager is owner. Read more about details how that works in the password reset blog post. The 10.1.1 runbook executes, as it is part of the service request template for the list group members offering. The runbook ends with sending a e-mail to the manager. The e-mail contains a list of all members of the security group.

Add/remove member of group

A manager (owner of at least one group) navigates to the self service portal and select either the Add User To Group offering or the Remove User From Group offering. Select which group and input the username of the user to add or remove to/from the security group.

This was a simple example of what you could do with Service Manager and Orchestrator. You can of course add a lot more features and  details. I didn’t spend any time on fault tolerance or error handling in the runbooks as this is an example, but for all production runbooks you should really spend time on that.

You can download my custom assembly file for list group members in Active Directory, Service Manager management pack and Orchestrator runbooks here, 20120716_GroupManagement. Please note that this is provided “as is” with no warranties at all.

With default settings you can report incident with the self-service portal in Service Manager. But the form is generic, and often you want to customize it. For example if someone reports a issue with e-mail you might want them to submit some e-mail specific details like Outlook version and location. I was looking into this last week and want to share with you some ideas. We can publish incident templates in the self-service portal the same way we can do with service request. They are both published as request offerings. When we configure a request offering we setup a number of user inputs. We can do this with a incident template too, but there are not many suitable fields on a incident to store custom data, like Outlook version. Instead we can create activities on a incident template and on each of them store data, but out of the box we have only the manual activity to use, and lets say we want to store five custom fields, we don’t want to use five manual activities in the incident template. Instead we can create a new activity class, that includes for example five generic fields. To do that we need to start in the Service Manager Authoring Tool

1. Start Service Manager Authoring Tool
2. Create a new Management Pack, for example ContosoManualActivity
3. Right-click Classes and select Create Other Class
4. Base Class, select Manual Activity as base class
5. Create Class, input Contoso.Manual.Activity as internal name
6. Delete the default property named something like Property_XX
7. Click Create property, input internal name, for example text01
8. Click Create property, input internal name, for example text02
9. Click Create property, input internal name, for example text03
10. Click Create property, input internal name, for example text04
11. Click Create property, input internal name, for example text05
12. Save the management pack
13. Seal the management pack, more info how to seal a management pack and generate a key file here
14. Start the Service Manager Console, import the seal management pack (mp file)
15. Restart the Service Manager console to reload class structure
16. In the Service Manager console navigate to Library/Templates
17. Click Create Template in the Tasks pane
18. Create Template, input a name, for example Contoso – Template – Manual Activity. Select the Contoso.Manual.Activity class (under basic classes). Create a new management pack named for example Contoso Activity where you store the template
19. Manual Activity Template, input a title, for example Contoso – Manual Activity. Click OK
20. Click Create Template again
21. Create Template, input a name, for example Contoso – Template – Mail Incident. Select Incident as class and select the same management pack as before
22. Incident Template, configure classification category, source, impact, urgency
    
23. Click on the Activities tab
24. Click Add…
25. Select a class, select Contoso.Manual.Activity and click OK
26. Select Template, select Contoso – Template – Manual Activity
27. Click OK
28. Click OK to close the Incident Template form
29. Time to publish this as a Request Offering. Navigate to Library/Service Catalog/Request Offerings, click Create Request Offering from the Tasks Pane
30. Create Request Offering, General,
    1. input title Exchange Issue
    2. Template name, Contoso – Template – Mail Incident
31. Create Request Offering, User Prompt. Note that we use only strings here. You could configure your management pack properties to be true/false or any other data type. You can then also use the same data type in Service Manager user input, for example let the user select Outlook and Windows version from a drop down menu.
    
32. Create Request Offering, Map Prompts,
    
33. Create Request Offering, Publish. Change Offering Status to Published. Finish the wizard
34. Create a new Service Offering, named for example Incident, and include the request offering you just created. Don´t forget to change the service offering status to Published.
35. Browse to the self-service portal now

If the user then submits the incident you can see all the custom data under the activities tab. As we added the text fields to the new activity class. That is not optimal to have it there, as it will require some extra clicks to show it.

You can of course solve this with Orchestrator 🙂 I have create a simple runbook that picks up the incident and merge the User Input data with the Description field. The User Input field is a default field on a incident that contains all the data we added to the custom text fields on the activity. You could trigger this runbook automatically when a new incident of this type is created. One thing to think about is that you want to merge the User Input data with the already existing Description field, make sure not to overwrite it. As you can see in the last image we also get the XML code from User Input. I did not create a runbook to clean that, but you could of course do that with a runbook too, to only keep the user input text.

The result, you can use custom input fields, different for different type of incident, to let user report incident with the self-service portal.

As usual thanks to Patrik  for Service Manager authoring support

Please note that this is provided “as is” with no warranties at all.

In this blog post I will show you how you can setup password reset with the self-service portal, Service Manager and Orchestrator. The scenario is that a manager should be enable to reset password for colleagues reporting to he or she. The manager could also be something like instructor or teacher for a class. The request offering for password reset should only be shown to members of the “Manager” user role, and the manager should only be enable to reset password for members of their team. To make this work you need to configure the manager attribute on your users in Active Directory, as shown in the image below. We will use a dynamic query based list to show only people reporting direct to the manager. In this example I use Orchestrator to generate a 10 characters complex password, but you could also add “New Password” as a parameter to the service request. Then you input the new password in the service portal. You could also configure the runbook to check the “User must change password at next logon” checkbox on the user account. That check box sometimes result in issues for some applications so I have not included it in this demo.

Runbook

• Start
• Get Runbook Activity. Gets the runbook activity, we submit the ID as a input parameter to the runbook from Service Manager
• Get Related Service Request. We pickup the service request from the runbook activity, by the relationship
• Get Related User. When we configured the query list in Service Manager we configured that the user should be set as a related item to the runbook activity. This activity gets the related user
• Get Service Request. Read the Service Request item
• Get User. Read the User object
• Generate New Password. Generates a 10 characters complex password
• Reset User Password. Set the password to the generated complex password
• Update Service Request. Update the description field on the service request with the new password and account information

The runbook is quite simple, we start with the runbook activity as we get it from Service Manager as ObjectID. We then pickup related service request and user. We generate a new password and set it on the user. We then update the service request with new description, including the new password.

Service Manager Side

1. Start the Service Manager console
2. Synchronize the runbook over to Service Manager by using the Orchestrator connector
3. Navigate to Library/Runbooks, select the runbook (2.2.1 Password Reset) and click Create Runbook Automation Activity Template in the Tasks pane
4. Create Template,
   1. Input a name, for example Contoso – Runbook Activity – 2.2.1 Password Reset.
   2. Create a new management pack, for example Contoso Password Reset.
   3. Click OK
5. Runbook Activity Template,
   1. Check Is Ready For Automation
   2. Input title, for example Contoso – Runbook Activity Template – 2.2.1 Password Reset
   3. Click the Runbook tab
   4. Map ObjectID to Object/ID
   5. Click OK
      
6. Navigate to Library/Templates. Click Create Template from the Tasks pane
7. Create Template,
   1. input name, for example Contoso – Service Request Template – Password Reset
   2. Select Service Request as Class
   3. Select the Contoso Password Reset management pack
   4. Click OK
8. Service Request Template,
   1. Input title, for example Contoso – Service Request – Reset Password
   2. Click the Activities tab
   3. Add “Contoso – Runbook Activity – 2.2.1 Password Reset” as activity
   4. Runbook Activity Template, click OK
      
   5. Click OK
9. Navigate to Library/Service Catalog/Request Offerings
10. Click Create Request Offering in the Tasks pane
11. Create Request Offering – General, input title, for example Password Reset
12. Create Request Offering – General, select Contoso – Service Request Template – Password Reset as template
13. Create Request Offering – User Prompts, add one prompt named User and configure it as query result
    
14. Create Request Offering – Configure Prompts, select the User prompt and select Configure
15. Configure Query Results,
    1. Select Class, change to Combination classes and select User (advanced)
    2. Configure Criteria, select Manages User and select Pager, click Add Constraint. Configure as image below. Use “Set Token”. Why do we use Pager? The Token: Portal User Name is in format CONTOSO\leni (DOMAIN\username). We don’t store that on a user CI in Service Manager, we store username and domain, but not in that format. Instead I have updated each manager with that information in the Pager attribute, as we don’t use it for anything else in this environment. You can easy update the Pager attribute with a runbook, the export file includes a example of that.
    3. Display Columns. select User (advanced), the Object/DisplayName and Domain User or Group/User Name
       
    4. Options, select “Add User-selected objects to template objects as related item: select the Runbook Automation Activity
       
    5. Click OK
16. Create Request Offering – Map Prompts,
    
17. Create Request Offering – Publish, change offering status to Published
18. Create the request offering
19. Navigate to Library/Service Catalog/Service Offering
20. Click Create Service Offering from the Tasks pane
21. Create Service Offering
    1. General, fill in title for example Manager
    2. Request Offerings, add the Password Reset request offering
    3. Publish, change offering status to Published
    4. Finish the wizard and create the service offering
22. Navigate to Library/Groups. Click New Catalog Group
23. Create Catalog items group,
    1. General, group name, for example Contoso Managers
    2. Included Members, click Add, add the Password Reset request offering and the Manager Service offering
    3. Finish the wizard and create the group
24. Navigate to Administration/Security/User Roles
25. Click Create User Role > End User
26. Create User Role,
    1. General, Name, for example Contoso Managers
    2. Management Packs, select the Contoso Password Reset management pack
    3. Catalog item Groups, select Contoso Managers
    4. Users, add managers
    5. Finish the wizard and create the user role

You can download my example runbook here, 20120617_PasswordReset_WOLF

Please note that this is provided “as is” with no warranties at all.