Home » Articles posted by Anders Bengtsson (Page 19)

Author Archives: Anders Bengtsson

Override RunAs Logon Check Failed

December 17, 2010 / 1 Comment on Override RunAs Logon Check Failed

The other day I needed to configure a web application check against a web service in a DMZ. This DMZ had its own Active Directory domain with no trust or connection to the internal domain where Operations Manager was installed. One of the criteria of the web application monitoring was to verify that we could log on to the web service. We ran into a challenge when configure the run as account for the web service. Operations Manager is trying to verify the account, as we didn’t have a trust or any connection to the DMZ domain that was not possible. We tried to override only for this account on the watch node, but unfortunately it was all account checks or none.

After some investigation we found that the event generated on the agent (the watch node in this case) included the account that did pass the check.

The solution to this was to disable the monitor for the watch node, then create a new monitor only for the watch node with the same criteria, but with one extra criteria, not to include events where event description includes LITWARE\Administrator. LITWARE\Administrator was the account that we didn’t want an alert on.

State based on logon status

December 12, 2010 / 1 Comment on State based on logon status

I read a question this week about presenting a state based on if a service account was logged on to a machine or not. There are a couple of different ways to do that. We will need a monitor in both of them, as we want to present a state. You could solve it with a monitor running a script, checking current logged on users. You could also solve it with a monitor checking log-on and log-out events.

If you want to do it with two events and running server 2008 you could look at even 4624 (an account was successfully logged on) and 4647 (User initiated log-off). To configure a monitor like that you follow the steps below. This example will configure a monitor to generate an alert if not the CONTOSO\svc-contoso-service account is logged on.

  1. In the console, navigate to Authoring/Management Pack Objects
  2. Right-click monitors and create a new Simple Event Detection/Windows Event Reset monitor
  3. Choose a suitable management pack, not the default management pack. Click Next
  4. Input a name, a target and choose a parent monitor. Click Next
  5. Event Log (Unhealthy Event). Select Security as event log name. Click Next
  6. Event Expression (Unhealthy Event). Select Event ID equals 4647 and EventDescription Contains CONTOSO\svc-contoso-service. Click Next
  7. Event Log (Healthy Event). Select Security as event log name. Click Next
  8. Event Expression (Healthy Event). Select Event ID equals 4624 and EventDescription Contains CONTOSO\svc-contoso-service. Click Next
  9. Configure Health. Click Next
  10. Configure Alert. Check the “Generate alerts for this monitor” check box. Click Create

    11. By default this new monitor will be forced to healthy state first. This mean we will not get an alert until the account log off. In other words, if there is a machine where this account is not logged on right now, Operations Manager will not notice it. It is only looking for the log-in and log-off event. To generate an alert we first need to log-on with the account, in this example CONTOSO\svc-contoso-service, then log-out again. The monitor will then go into unhealthy state.

    The second way to solve this is with a script. To configure a monitor like that you follow the steps below

  1. In the console, navigate to Authoring/Management Pack Objects
  2. Right-click monitors and create a new Scripting/Generic/Timed Script Two State Monitor
  3. Choose a suitable management pack, not the default management pack. Click Next
  4. Input a name, a target and choose a parent monitor. Click Next
  5. Schedule. Configure how often you want the script to run, to see if the account is logged on. Dont configure it to run to often, check your organization requirements. Click Next
  6. Script. Input a script name, for example accountcheck.vbs. Paste the script into the script text field. You can download the script here. One of the first lines in the script configure which account to check. Don’t forget to update it. Click Next
  7. Unhealthy Expression. Input
    Property[@Name=’Status’] Does not equal OK
    Click Next
  8. Healthy Expression. Input
    Property[@Name=’Status’] Equals OK
    Click Next
  9. Health. Click Next
  10. Configure Alert. Check the “Generate alerts for this monitor” check-box and input a alert description. Click Create

If you need to display the account status in a distributed application it is easiest if you can target the monitor to a new customer class. The health model of the class will then be only this monitor, in other words the class instance health it will only show the status of the account.  

Thanks to Guy Thomas for his script that I adapted.

Service Manager and Opalis 6.3

November 15, 2010 / 2 Comments on Service Manager and Opalis 6.3

In this post I will show you a idea how you can connect Service Manager 2010 with Opalis. The demo scenario is very common, create user account based on a change request. In this demo the change request will be in Service Manager and the user will be created in Active Directory. 

Opalis 6.3 will include new Integration Packs for the four remaining System Center suite products – Configuration Manager, Data Protection Manager, Virtual Machine Manager and Service Manager.  These four new packs along with the existing Operations Manager pack provide deep, dynamic integration within the Datacenter.  And of course you can go cross-platform and cross-application with the 26 other Integration Packs. Opalis 6.3 will be released Q4 CY2010, in other words pretty soon 🙂 More info about 6.3 here. Keep in mind that the information in this article is based on a beta version of the Opalis IP for Service Manager and is subject to change

We will extend Service Manager with a new activity for creating accounts in Active Directory. When Opalis find a instance of the new activity, in “in progress” state, it will read the properties of it and create the account in Active Directory based on them. Opalis will then update the activity in Service Manager so it can continue with other activities in the change. To get this to work we need to perform two major steps, extend service manager and build the workflow in Opalis. The Service Manager step includes two parts, first to author the new management pack with the authoring tool and then create templates in the Service Manager console.

Before we begin, please note that the purpose of this post is to give you a idea what you can do with the new Service Manager integration pack. This is not a production ready solution, for example the Opalis workflow is very simple and without any error handle. Lets begin!

  1. Begin with start the authoring tool for Service Manager. In the management pack explorer pane, right-click classes, select “Create other class…”
  2. In the Base Class window, select Activity as base class
  3. In the Create class window, input contoso.createaccount
  4. In the contoso.createaccount pane, delete the default Property_16 property
  5. Create the following properties in the contoso.createaccount class
    1. First
    2. Last
    3. Department
    4. Opalisinfo
  6. Select the Department property and then in the details pane change data type to list
  7. In the Select a list window, click Create List…
  8. In the create list window, input Departments as internal name and displayname. Select your new list and click OK
  9. In the Management Pack Explorer pane, right-click Forms and select Create
  10. In the Base Class window, select contoso.createaccount
  11. In the Create form window, CreateAccountForm as internal name
  12. Design the form as the picture below. Bind each text box to a propety according to the list below
    1. First name = First
    2. Last name = Last
    3. Department = Department
  13. Add one extra label, and bind (binding path) it to the OpalisInfo property, without any default values. Opalis will populate it later
  14. Save your new MP
  15. Switch to the Service Manager 2010 console and import it into Service Manager 2010
  16. Navigate to Library/Lists and populate the Department list with your departments. Note that this is stored in the management pack. So if you edit the MP in the authoring tool and import it again you will have a blank department list. Instead export the MP from the service manager console and import it in the authoring tool when you need to edit it.
  17. Navigate to Library/Templates and click “Create Template” in the tasks pane
  18. In the Create Template window, input “Create Account” as Name and Description, select “contoso.createaccount” as class and contoso.autoaccount as management pack. Click OK
  19. In the “Form Host” window, click OK to save
  20. Click “Create Template” in the tasks pane again
  21. Input “New User Account” as name, select “Change Request” as class and contoso.autoaccount as management pack. Click Ok
  22. In the “form host” window, change area, priority and risk to suitable value
  23. Click the Activities tab
  24. On the Activities tab click Add, add the “Create Account” activity and click OK and save the new template.

Now we have built the new activity in Service Manager and a change template that use it. The next step is to build a workflow in Opalis that picks up this activity and create the account in Active Directory. The following picture show you how a very simple version of that workflow could look. Please note that this workflow is not production ready and only for demo. To get some ideas how you should build your workflow take a look at this (Fault-tolerance in Opalis policies) and thispost (Opalis creating accounts in Active Directory).

The following pictures show the configuration of my three workflow objects. The first object monitors for new objects of our new class (contoso.createaccount). When it finds a object it moves on to the Active Directory object that will create the user account based on information in the contoso.createaccount object. The Active Directory object could of course include a lot more information about the users, but for this example I only use department, first and last name. When the user account is created the Service Manager object udates the object, both with a new status and with information about the account. The account information is written in the opalisinfo property of the contoso.createaccount class. We did add a blank textbox in the form and bound it to the opalisinfo property. That is where this info will be displayed. Ad you can see in the picture below, the “get object” object will query Service Manager to get a list of your classes, and we can easy select our new class.

Note that we can use any property of the new class, Opalis will query Service Manager and show us all the properties we created in the Authoring Tool. It will in the last step update the service manager object, in this scenario the activity.

I don’t use many of the settings that we can use in Opalis when working with Active Directory and Service Manager. My workflow picks up the new instance of our new activity class. It creates a Active Directory user based on the information that we filled in in the change form. When the workflow has created the user, it updated the form with information about the account, see below. Some things that you might want to add is fail tolerance, what if the user name is already in use? Or if there is anything else that interrupts the workflow. See my post about Opalis failover for more ideas around that. You could also input more properties of the user in the change form, so you get more information inserted into Active Directory direct.

This post showed you a simple example of the integration between Opalis 6.3 and Service Manager 2010. The Opalis IP for Service Manager could be used in a number of ways to integrate system and services to and from Service Manager. I guess you have already figure out a number of scenarios where you can use this integration. Good Luck!

Send e-mail to affected user

November 3, 2010 / 15 Comments on Send e-mail to affected user

In this post I will show you how to build a simple task to send a e-mail to the affected user of a incident. The e-mail will be logged in the action log of the incident.Please note that this will not affect how you handle incoming e-mails, it will only give you a fast way to send a e-mail to the affected user.

  1. In the SCSM Console, go to Library, check Tasks
  2. In the Tasks pane click Create Task
  3. Input the following settings in the “Create a task” wizard
  4. General
    • Task name: Contoso – Send e-mail to affected user
    • Target class: Incident
  5. Categories: Incident Support Group Folder Tasks
  6. Command Line
    • Full path to command: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
    • Parameters: .\emailenduser.ps1 Property/WorkItem/ID Property/AffectedUser/Username Property/WorkItem/Title Property/AffectedUser/Firstname
    • Please note that each property is inserted with the “Insert Property” button
    • Check both “Log in action log when this task is run” and “Show output when this task is run”
    • Working Directory: C:\Scripts\
  7. Save your new task

As you can see in the task we are using a script here, C:\Scripts\emailenduser.ps1. It is a powershell script that you can download here, emailenduser. Please note that you will need to modify the script to work in your environment, there are some notes about that in the script.

Now, if you select a incident in a incident view you will have a new task in the tasks pane, “Contoso – Send e-mail to affected user”. If you click it you can input a text. This text will be in the e-mail. The e-mail will also add a “Hi affect user name” and “thanks, br service desk…”. Don’t forget to modify that part to in the script.

The operator will see the e-mail and it will also be inserted into the action log of the incident.

Fault-tolerance in Opalis policies

October 22, 2010 / 6 Comments on Fault-tolerance in Opalis policies

Lately I have been working with Opalis and special around fault-tolerance both in a policy and in the Opalis infrastructure. I think this is two areas that needs to be combined to get a really fault-tolerance Opalis implementation. In this blog post I want to show you some things to think about when building your opalis policy.

Opalis is an automation platform for orchestrating and integrating IT tools to drive down the cost of datacenter operations, while improving the reliability of IT processes. It enables IT organizations to automate best practices, such as those found in Microsoft Operations Framework (MOF) and Information Technology Infrastructure Library (ITIL). This is achieved through workflow processes that coordinate System Center and other management tools to automate incident response, change and compliance, and service-lifecycle management processes. More info at source.

When you install your first action server it will be your default/primary action server, you can then install more action servers that can work as standby servers. If the Opalis Management Server don’t receive heartbeats from the primary action server it can failover all policies to the secondary server. You can then install another action server that can be standby for the first standby server. A nice thing is that you can design some of your policies to run on the standby machine, even when the primary action server is alive. Could be good in some resource intensive policies or policies that require a special software. To mention one more of the Opalis failover features, you can place the database on a cluster, and this is also something to think about when building you Opalis infrastructure.

One important note about failover to another action server is that your policy will start at the beginning of the workflow. In other word if the policy was running when the primary action server went offline the policy will start in at the beginning again. That is not always a bad thing, but it is something you need to think about when building your policies. It will lead us to the second area of fault-tolerance in Opalis, fault-tolerance in Opalis policy.

When you design your policy you should consider fault-tolerance and not only build a workflow as one large straight stretch. For example if you build a policy that creates a new user account, creates a mailbox, adds the account to a couple of security groups and also network folder like this

What if the fileserver is offline or the user account already exists? The first question could be how will you notice it? Will you monitor Opalis Operator Console or monitor it with Operations Manager? You policy will fail and you will have a user in the Active Directory without a mailbox or network folder. Most likely you will need to open you MMC consoles and create the mailbox and folder yourself manually. If you instead add a couple of extra objects like this

Your policy will start with checking if the user is already in AD or for example if the username is already in use. It will then check that both the mail server and fileserver is up and running. If not, it will stop and write this to log files. Log files you can easy monitor and use to troubleshoot. If you then add some more objects like this

This version, in addition to the two other versions, will check if the user name exists already, and if it exists it will continue along the orange path. The orange path will generate another samaccount name and user attributes then the green path. Both paths will also send an e-mail when the account is created. If the create mailbox object fail the policy will delete the account, or clean up what it has created so far.

You can of course come up with a lot of other scenarios where different parts of the policy fail and you need to take action based on it. One idea could be if the action server failover to the secondary server, then you need to have a policy that knows where to start, for example we might already have the account in AD and want to continue with the mailbox, not create a new account according to the orange path. There is not one easy general answer to how you need to build your policy to cover all different scenarios, but it is something you should think about when designing your policies. Then of course, use the failover mechanism in Opalis to get a fault-tolerance infrastructure.

Show all agents without ACS enable

October 17, 2010 / 1 Comment on Show all agents without ACS enable

In Operations Manager 2007, Audit Collection Services (ACS) provides a means to collect records generated by an audit policy and store them in a centralized database. More info about ACS here.

If you enable ACS gradually or as you install agents it is easy to forget a agent or two. Then you need a view that shows you all agents where you have not enable ACS. I was looking for that kind of view a couple of days ago. Unfortunaly I could not find it so I created it myself instead. My idea was to show all machines where the AdtAgent service, the ACS agent service, is disable. To get this to work we need to do a discovery of a registry value on all machines with a health service. The discovery will tell us the start-up configuration of the AdtAgent service (ACS agent). The result of the discovery will shown as a extra property of the health service.

  1. In the Operations Manager console navigate to the Authoring workspace.
  2. Expand management pack objects and right-click attributes, select Create a New Attribute
  3. In the Create Attribute Wizard, General Properties page, input a name for example Contoso – noACSAgent
  4. In the Create Attribute Wizard, Discovery Method page, input
    • Discovery Type: Registry
    • Target: Health Service
    • Management Pack: Select one of your unsealed MPs or create a new MP
  5. In the Create Attribute Wizard, input
    • Key or Value Type: Value
    • Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AdtAgent\Start
    • Attribute Type: Int
  6. Click Finish to save your new attribute
  7. Navigate to the Monitoring workspace, right-click the management pack where you stored the attribute, select create new state view
  8. Name the view “Contoso – Agents without ACS” and configure
    • Show data related to: Health Service_Extended
    • with specific Contoso – noACSAgent , configure it with 4 (Show all state with 4 Contoso – noACSAgent) A service configured with startup to 4 means that the service is disable.
  9. Click OK to save your new view

This view will now show you all agents with a disabled ACS (AdtAgent) service.

Announcing: System Center Service Manager (SCSM) 2010 Unleashed

October 6, 2010 / 10 Comments on Announcing: System Center Service Manager (SCSM) 2010 Unleashed

Everyone working with the System Center product suite has most likely read one of the “Unleashed” books. In many forums they have been described as a technical ”bible.” We are pleased to announce there will be a new “bible” for Service Manager 2010!
Service Manager, the long-awaited third major component of Microsoft’s System Center suite, addresses the “Supporting” quadrant of the MOF process model. System Center Service Manager 2010 Unleashed will provide in-depth reference and technical information about Microsoft System Center Service Manager 2010, as well as information on other products and technologies on which its features and components are dependant.

The content uses an end-to-end feature implementation perspective, facilitating more optimized deployments by covering related topics in a stepwise order for a given feature area. The book begins with an overview, moves into planning, design, and implementation, and then covers the most important and significant feature sets of the product – of interest to SCSM administrators worldwide.

Authors are Kerrie Meyler, Alexandre Verkinderen, Anders Bengtsson, David Pultorak, and Patrik Sundqvist. Also contributing are Travis Wright, Kurt Van Hoecke, and Maarten Goet.

Here are some of the topics we plan to cover:

• Service Manager Basics
• Service Manager 2010 Overview
• MOF & ITIL (Why You Care)
• Looking Inside Service Manager
• Designing Service Manager
• Planning Complex Configurations
• Installing Service Manager 2010
• Using the Service Manager Console
• Connecting to Operations Manager, Configuration Manager, and Active Directory
• Business Services
• Incident Management
• Problem Management
• Change Management
• Release Management Services
• IT Management – Governance, Risk Management, and Compliance
• Using the Self-Service Portal
• Notification
• Service Manager and Security
• Backup, Recovery, and Maintenance
• Customization Planning
• Customizing Workflows and Management Packs
• Reports, Dashboards, and Data Analysis
• Customizing the Data Warehouse and Reporting
• Service Manager and the Managed Service Provider
• Partner Solutions

Service Manager 2010 Unleashed will be published by Sams Publishing, joining the existing System Center series with Unleashed books on Operations Manager and Configuration Manager. The book will incorporate Service Manager 2010 SP1 as well as enhancements in an anticipated R2 release in 2011.
I’m very proud to be working on this book and I would like to thank Kerrie Meyler for asking me to join the project.

I’m heading to Microsoft to be a Premier Field Engineer

October 2, 2010 / 20 Comments on I’m heading to Microsoft to be a Premier Field Engineer

After a number of years as consultant I have decided to accept a new challenge. I have accepted the position as a Premier Field Engineer with focus on System Center at Microsoft in Sweden. I really looking forward to this new challenge which will let me learn new things and do a lot of the things I am good at. I will start at Microsoft in Stockholm/Sweden next week. In case you are wondering what a PFE does, please take a look at this job description.

I will miss my colleagues at Atea; I have really enjoyed their company and learned a lot of things. Of course I will also miss the MVP group, but we will meet again I’m sure. I will continue to run my blog here and work for the community, as usual.

Notification on all unassigned incidents

September 23, 2010 / 16 Comments on Notification on all unassigned incidents

I saw a question in the forum today about notification on unassigned incidents. This is difficult to do from the console because there is no support for subscribing to the absence of a relationship. If you want notification on all unassigned incidents that are older then X hours you could instead use a custom script. The script could then be triggered by a workflow in Service Manager. In this post I can build a simple script that I will add to a workflow. The script will run every hour and see if there are any unassigned incidents that are older then 2 hours.

  1. Open Service Manager Authoring Tool and create a new management pack, in my case Contoso.Unassigned
  2. Right-click Workflows and create a new workflow
  3. In the Create Workflow Wizard, General, input a name, for example ContosoUnassignedIncidents
  4. In the Create Workflow Wizard, Trigger Condition, select Run at a scheduled time or at…
  5. In the Create Workflow Wizard, Trigger Criteria, select Other interval and 1 Hours
  6. In the Workflow window, from the toolbox, drag and drop the Windows PowerShell Script
  7. In the properties of the script activity, paste the following script into the script body field

    $smtphost=”LUDSRV206″
    $to=”kurt@contoso.local”
    $from=”svc-wf-ludsrv204@contoso.local”

    function Send-Mail
    {
    param($From,$To,$Subject,$Body)
    $smtp = new-object system.net.mail.smtpClient($smtphost)
    $mail = new-object System.Net.Mail.MailMessage
    $mail.from= $From
    $mail.to.add($To)
    $mail.subject= $Subject
    $mail.body= $Body
    $mail.isbodyhtml=$true
    $smtp.send($mail)
    }

    Import-Module SMLets
    $BeforeDate = (get-date).AddHours(-2).ToString(“yyy-MM-dd HH:mm:ss”)
    $getIncidents = Get-SCSMIncident -Status “Active” -CreatedBefore $BeforeDate | where { $_.AssignedTo -eq $NULL } | select ID, Title, AffectedUser

    if ($getIncidents.count -gt 0) {

    $subject= “Unassigned incidents in Service Manager, total of ” + $getIncidents.count
    $body=$getIncidents|convertto-html
    Send-Mail $from $to $subject $body

    }

    Remove-Module SMLets

  8. Modify the following parameters to fit your environment
    • $smtphost = hostname of your mailserver
    • $to = the e-mail address that will recive the e-mail
    • $from = the e-mail address that the script will use to send the e-mail
    • $subject = the subject in the e-mail
  9. Save your management pack
  10. Copy the ContosoUnassignedIncidents.dll to the C:\Program Files\Microsoft System Center\Service Manager 2010 directory on your Management Server
  11. Import your management pack into Service Manager

After a hour the e-mail address in your $TO parameter (in the script) could get a e-mail looking like this

In this e-mail we can see all incidents older then two hours that don’t have anyone in “assigned to”. To verify that your workflow is running you can look in the Workflows/Status view in the Administration workspace. A nice extension of this soultion could be to control notification from the console and not in the script. Also adding support for different notification based on incident area and category. That is something for the feature 🙂 Also, please not that my scrip needs the Service Manager cmdlets, more info about them here.

Quick Calls in Service Manager 2010

September 9, 2010 / 7 Comments on Quick Calls in Service Manager 2010

Quite often someone in the Service Manager forum ask how to ask really quick and simple questions. They think that it is to many clicks to use the default incident form or incident process. In this blog post I will show you a solution to that, a way to create a new type of work items simple.

  1. Open the Service Manager Authoring Tool
  2. Click File>New
  3. Input a name, for example Contoso.QuickCalls
  4. In your new management pack, right-click classes and select Create Work Item Class…
  5. In the Create class window, input Contoso.QuickCall
  6. In the Class properties window, delete the default Property_10
  7. Click Create property and add a property named ClassificationCategory
  8. In the details pane of ClassificationCategory select Incident Classification as List Type (from the Incident Management Library management pack)

  1. In management pack explorer, right-click Form and select Create
  2. In the base class window, select Contoso.QuickCall
  3. In the Create Form window, input Contoso.QuickCall.Form as internal name
  4. On the form drag and drop the following items,
  5. Verify that you have a user picker, a textbox and a list picker and a couple of labels
  6. In the details field of each object configure the binding path according to
    • User picker – Affected User
    • Text box – Description
    • List Picker – ClassificationCategory
  7. On your list picker configure List Type to Incident Classification (Incident Management Library)
  8. Save you new management pack and import it into Service Manager

There are no views to show your new work item class so we need to create a view targeting the new class, and then we will also get a Create task for this work item class.

  1. After import of the management pack, navigate to work items
  2. Select Work Items and Incident Management in the navigation pane and select create view from the task pane
  3. In the Create View wizard input
    • Name: Contoso – Quick Calls
    • Management Pack: Contoso.QuickCalls
    • Search for objects of a specific class: Contoso.QuickCall
    • Display: Create Date, Display Name, ID, Time Added
  4. Click OK to save your new view

Now to create a quick call select the new view, then click Create Contoso.QuickCall from the tasks pane.

Thats it! Now you have a new work item class named Contoso.QuickCall, it takes very new clicks to register a call like this.

Post navigation

← Older posts Newer posts →