Mark Mears at

A compilation of information about Microsoft System Center family products
  • Product Improvement Suggestion on Connect Site

    I proposed a product suggestion today for a future release of SCSM.  The proposal I files is located at on the Connect website.

    Basically this deals with the necessity of having to create a customer SCCM connector if you want to include additional inventory data (like Video Adapter, BIOS information, etc.) that is not retrieved using the default SCCM connector.  SCCM already has these details and it could be more available to us.

    If you have any feelings one way or the other please feel free to click on the link above and provide a comment.  If this is a problem that others are feeling as well, I urge you to comment by suggestion!

  • The public beta of System Center Service Manager 2012 has been released!

    Just a short note to let you know that the public beta of System Center Service Manager 2012 has been announced by Microsoft!  This means that bloggers can discuss and write about all the new features, improvements and fixes that are included in this version.
    Here is the link to download the software:$Microsoft+Download+Center$

    The TechNet Library has also been updated to include the SCSM 2012 documentation located here:

  • Removing/Deleting Many Incidents from the SCSM Database using PowerShell

    Removing/Deleting Incidents from the SCSM Database

    In System Center Service Manager 2010 (SCSM), the console does not allow deletion of work items from the console views. We can however use the PowerShell SMLets to accomplish this.

    A couple of examples of when this might be appropriate are listed below:

    · No test system is available and testing of work items has been conducted on the production system. Now that testing is complete it is desired that the test work items be removed.

    · A problem with a workflow or notification causes a flood of work items to be created. Removal of these bogus work items is desired.

    NOTE: ITIL and MOF guidelines specify that the deletion or removal of work items from live systems is not permitted. This is the reason why no deletion capability exists in the SCSM console.

    NOTE: Direct deletion from the database is not supported by Microsoft and could cause damages to the system that would require removal and reinstallation with the possibility of data loss. Microsoft does allow and has documented the use of the SMLets to remove objects from the database.

    I recently ran into a situation where 25000 incidents were created due to an email flood into the SCSM incoming mailbox. I am going to be documenting one way to remove items from the database and perform this cleanup. A few additional notes along the way will be given to provide some additional insight into how and why.

    Step #1 – Identify the work items to be removed

    Work items of the Incident class are maintained in the ServiceManager database in the MT_System$Workitem$Incident table on the SQL Server used for the SCSM Management Server. Within this table are several columns we can use to identify a particular work item. Several of the columns have a text name and a concatenated GUID to provide a unique column name. This makes it a bit more difficult to select a column at a glance but is it possible to identify the column names we need to look at. Some of the important columns are:

    · Title_* - The title of the Incident as seen from the console view

    · BaseManagedEntityId – The actual ID of the incident in a GUID format

    · ID_* - This is the assigned IncidentID from the console view

    We will be using a PowerShell script to perform the deletion of the objects from the console. (In reality, they are not actually deleted but rather marked for later deletion in the database.) In the PowerShell script that we use to remove the incidents we need to have some manner of detecting or selecting which incidents we want to delete. If the number of incidents is below a few hundred and these have some criteria where we can perform a filter operation, PowerShell can remove them in a single command. If there are more that let’s say 1000 incidents to delete, this can be a bit more challenging due to timeout issues. In my case I had 25000 incidents to delete. Furthermore, I only had a single criteria that I was able to use in the filter operation which did not reduce this number. That criteria was that for each of the affected incidents, the Incident Title was garbled but began with the same characters. So I needed to find some other criteria that I could use to filter the indents that would allow me to delete them.

    I was able to create a SQL query that would perform this filter operation for me and it presented me with the 25000 incident rows in the SQL return set.

    The SQL Query that I used for this was:

    SELECT *

    FROM MT_System$WorkItem$Incident

    WHERE Title_9691DD10_7211_C835_E3E7_6B38AF8B8104

    LIKE 'somestring%'

    Step #2 - Script the deletion

    This returned the entire list of incidents which included all of the data for each incident. The BaseManagedEntityId field contains the actual ID of the incident which is how I went about to start the process. The PowerShell command to remove an object (specifically an incident) from the database is:

    Get-SCSMObject -Class (Get-SCSMClass -Name System.WorkItem.Incident$) -Filter "ID -eq '< BaseManagedEntityId >'” | Remove-SCSMObject –Force

    This is great! But it only deletes a single incident from the database at a time. I didn’t want nor did I have the time to repeat this 25000 times so I needed a better way. Luckily we can get PowerShell to read from a text file so from the SQL query I was able to generate the list of BaseManagedEntityId’s corresponding to the list of incidents that I wanted to delete. I populated a text file with these 25000 entries and modified the Powershell command to utilize and read from the text file.

    The new command I used is:

    Get-Content <Fully Qualified Path to the Text File> | ForEach-Object{$ToClose= Get-SCSMObject -Class (Get-SCSMClass -Name System.WorkItem.Incident$) -Filter "ID -eq '$_'";$ToClose | Remove-SCSMObject -Force}

    To dissect and explain this command we are using the Get-Content command to read a line from the text file that we specify using the fully qualified path and filename. It puts the value it reads into a variable called $ToClose. We are then piping that output to the ForEach-Object command to perform an action on each list entry in the text file. We are basically using the same command as before to remove a single object replacing the ID in the command with the entry in the text file. The Remove-SCSMObject command requires an object to work with so we use the variable that we created ($ToClose) which contains the incident object that we filtered on.

    The –Force parameter is required for work items since the Remove-SCSMObject only marks the item for deletion to be placed in the DeletedItems view visible from the Administration pane. This won’t work for work items since they cannot be restored.

    Step #3 – Verify the results

    The script ran for nearly two hours but when it completed, a refresh of the incident view showed that the 25000 bogus incidents were indeed no longer present. They will exist in the database until the next purge which occurs on a daily schedule at which time they will be removed.

  • Atlanta Systems Management User Group Meeting 10/7/2011

    I will be presenting at the Atlanta SMUG meeting this Friday, 10/7/2011 at Alpharetta in the Microsoft offices for the regular quarterly meeting.  My topic will be a brief overview of System Center Service Manager 2010 from the field perspective as well as a few demos on the product.  If you are in town please come by.

    For more information, agenda and registration information please click here.

  • New SCSM 2010 Book Available!

    While this may be old news, I received my copy of the new SCSM 2010 Unleashed book recently and have started trying to absorb its contents.  There have been some comments in the TechNet forums about bits and pieces of SCSM tidbits scattered all over the Internet.  While may be true this books tries to bring it all together in one place.  It provides a deeper understanding of the components and how they all play together within the product.  This is a definite must buy for any serious SCSM admin or Consultant.  You can get the paperback version which I did or it comes in a Kindle version as well.  Click on the link above for more information.

    Posted Sep 23 2011, 11:06 AM by markmears with no comments
    Filed under:
  • Auto-closing a change request (dual criteria)

    My customer wants to use SCSM 2010 for handling User Access Requests.  These are implemented as Change Requests in SCSM 2010.  I modified the Change Area List to have a Security item and created a Access Control child item below it.  I then created a template to set the Change Area on User Access Change Requests to use the new Access Control change area.  After adding in all of the required steps as Manual Activities the customer wanted to know if these could be automatically closed once they are completed.  Time for a custom workflow using the Authoring Tool!

    I actually got the idea for this from Marcel Zehner’s blog post on Auto-closing Incidents.  I figured if it works for Incidents why can’t it work for Change Requests as well.  Marcel’s post is located here.

    In the Authoring Tool this type of workflow is very easy to create.  Create a new Management Pack and then create a workflow in it.  This particular Workflow will run on a schedule at some scheduled time(s) to go through the list of Completed change requests looking for any that are in the Access Control change area.  Sounds like we need a script to run for this!

    Since I am not a PowerShell guru, I asked for some help on the criteria portion of the script.  Setting up a filter for a single criteria is easy, but that would have auto-closed all of the Completed change requests, not good!  We only want to close the Completed User Access change requests so we need to filter on two criteria, Change Area = “Access Control” AND Status = “Completed”.  Thanks go out to Patrik Sundquist who provided an answer to that!

    After I got the script to work as desired I opened the Authoring Tool and placed a Windows PowerShell script as the only item in the workflow.  We really don’t need anything else as the script handles all of the logic for filtering and closing the change requests.  I saved the solution and imported the Management Pack. 

    I already had several User Access requests in my Test environment in various stages of completion so I triggered the workflow to run.  It closed only the Completed User Access requests, just what we wanted.  I checked the status of the workflow in Administration | Workflows | Status and saw that it was successful.  I could then import the Management Pack into my Production environment for production use.

    Let me take a moment and stress the importance of having a test environment that you can use for just such testing.  If I had run the original script in a production environment, all of the Completed change requests would have bee immediately closed, which may not have been desired. 

    So here is the script.  We’ll break it down and explain what each piece is doing as we go.

    We’ll be using the SMLets module so we need to import that first.

    import-module smlets

    We’ll establish the class of workitem we want to work with (Change Request)

    $class = Get-SCSMClass -name System.WorkItem.ChangeRequest$

    We’re going to set up the criteria we want to filter for, namely Completed User Access Requests

    $statusCompletedId = (Get-SCSMEnumeration ChangeStatusEnum.Completed$).Id
    $catAccessControlId = (Get-SCSMEnumeration ChangeAreaEnum.Security.AccessControl$).Id
    $critString = "Status = '$statusCompletedId' and Area = '$catAccessControlId'"
    $criteriaType = "Microsoft.EnterpriseManagement.Common.EnterpriseManagementObjectCriteria"
    $criteria = New-Object $criteriaType $critString, $class

    Here is where the change requests fitting the criteria are actually selected

    $changes = Get-SCSMObject -Criteria $criteria

    Now that we have all of the changes that we need to modify this next statement actually sets the status on all selected objects to Closed

    $Changes | Set-SCSMObject -property Status -Value Closed

    This workflow is a scheduled workflow that we have established needs to run several times during the day.  Based on your own requirements you may need to vary this due to your own unique environmental conditions. The workflow itself only runs for a few seconds right now but as the number of objects that it needs to filter increases this time may also increase. 

    This small custom workflow may not seem like much but it will save the customer uncounted hours in manually closing all of these change requests.  As the number of User Access requests increases over time that time savings will mount up.

    As always, your comments are welcome!  Please feel free to make any adjustments or changes to suit your environment. 

    NOTE: This solution may not be suitable for your environment. Please test all changes in a test environment prior to production implementation.  While I have tested this code personally and it works for me, all code included here is used at your own risk, I cannot assume responsibility if anything goes wrong.

  • Console Error when creating Connectors

    I installed a new SCSM installation the other day as ta test lab site and asked my customer to configure the Security accounts that would be used.  The accounts should have been the same as are in the production environment.  The next day I tried to create a connector to SCCM but continued to get an error in the console that eventually caused the console to bail.  Web search engines were not helpful as the same error could be thrown for various other conditions as well.

    Looking in the event logs to try some troubleshooting, I noticed one instance of a Windows Error Reporting entry and an entry with a source of System Center Service Manager Console directly preceding it which I copied out to Notepad for further examination.  Here is the first 5 lines of the entry:

    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
       at Microsoft.EnterpriseManagement.ServiceManager.UI.Administration.Connectors.Common.UserValidator.GetUserCredentials(List`1 connectionList, IDataItem secureReferenceItem, String& userName, SecureString& password, String& domain, Boolean& dialogResult)
       at Microsoft.EnterpriseManagement.ServiceManager.UI.Administration.Connectors.AD.ADConnectorHelper.ValidateServerConnection()
       at Microsoft.EnterpriseManagement.ServiceManager.UI.Administration.Connectors.AD.DomainSelectPage.SaveState(SavePageEventArgs e)
       at Microsoft.EnterpriseManagement.UI.WpfWizardFramework.WizardStory.NextStep()

    On the top line I saw “…Object reference not set to an instance of an object”.  I thought about it for a moment.  The only object that this process would reference would have been one of the security accounts so I checked under Administration | Security | RunAs accounts and saw that there were none defined.  After creating the accounts and specifying a valid account in the Create a Connector dialog it created the connector properly without errors.

  • Reporting Services Password Change woes


    I walked into a new engagement this week to help a customer complete an installation of SCSM.  SCSM has been installed prior to my arrival and is already in place although it has not been brought into production use.  I’m getting SSRS errors claiming the Username/Password combination is incorrect.  It’s probably an accurate error since the customer modified the password earlier this week.  Reporting basically is not working for any reports.  Here’s what I’ve done:

    • Reset the account using the SSRS Config Manager in the Service Account area – no change
    • Report Manager URL is functional
    • Web Service URL is functional

    I’m just trying to verify functionality of the SSRS installation right now before fleshing the installation out to full production use in the next 7-8 weeks. 

    I have looked in the ReportManager URL (http://SCSMDW:80/Reports) and drilled down to the List of Incidents canned report, I’m using this report for my reference.  I try to run it and it gives me the following errors:

    An error has occurred during report processing. (rsProcessingAborted)

    Cannot impersonate user for data source 'DWDataMart'. (rsErrorImpersonatingUser)

    Log on failed. (rsLogonFailed)  Ensure the user name and password are correct. (rsLogonFailed)

    Logon failure: unknown user or bad password

    I have looked at the report in ReportBuilder 3 (drill down in Report Manager, right click on report, Edit in Report Builder) and looked at the Data Source (Expand Data Sources, Edit).  It shows that it is using the correct database (DWDataMart) The option to use a shared connection or report model is selected.  Clicking on the Test Connection in the General tab produces a logon failure. 

    Solution and explanation:

    The Report Server is using a shared Data Source that is located under the Report Manager URL (http://SCSMDW:80/Reports/SystemCenter/ServiceManager).  This location is where the Report Folders containing the reports and Data Sources that manage connecting to the database are maintained.  There are five folders and two Data Sources defined at the completion of a standard installation.  I double clicked on the DWDataMart data source to edit it and saw that the credentials are stored there as well for any shared data sources.  I changed the password here to match what was in AD and clicked on the Test Connection button which passed now.  I was then able to run the reports properly and without errors.

    For someone with a background in SSRS this is probably a no-brainer.  I don’t have that and was totally lost for several hours until I was told where to look (thanks Chris!).  I figure that there are probably a few others that may not have an SSRS background either that this might help.

    Posted Aug 11 2011, 03:53 PM by markmears with no comments
    Filed under: ,
  • New SCSM Hotfix released!

    In a scenario where an organization has multiple active directory domain controllers (DCs) that replicate with one another, the Service Manager Active Directory Connector may not function correctly when DC switchover occurs. In this scenario, the connector can potentially miss some updates that are made on the domain controller.

    Additionally, the connector may have the same problem for a single domain controller that has been restored from backup

    For all the details and a link to download the hotfix please see the following article:

    KB2561415 - Active Directory Connector does not synchronize new updates after you switch domain controllers

    Posted Jun 23 2011, 12:26 PM by markmears with no comments
    Filed under:
  • System Center Orchestrator 2012 Beta info

    The System Center Team has released information about System Center Orchestrator 2012 Beta located in the following post:


    I attended the webcast for the Community Evaluation Program kickoff.  Needless to say, the Product Team has been very busy!  Anyone considering or using Opalis or Orchestrator should take a look at what is coming up!

  • Now available: A hotfix for Cumulative Update 1 for System Center Service Manager 2010 SP1: May 2011

  • Need to reopen a closed incident?

    If an incident has been closed that was not supposed to be closed for some reason there is no way within the SCSM console to reopen that incident.  However by using PowerShell, you can reopen an incident that has been closed. 

    NOTE: This does NOT perform any checking and is TOTALLY against the definition of MOF and ITIL!  It merely changes the status of a closed incident.  I am using this as an example of the scripting capabilities of PowerShell.

    OK, now that we have that out of the way, we have an incident that has been closed that for some reason needs to be reopened.

    We can use the following PowerShell script to provide a listing of the closed incidents from which we can select which Incident we need to reopen.  Alternatively we can identify the incident from the SCSM Console view of closed incidents.  We need to provide the ID of the incident to reopen.

        Get-SCSMIncident -Status Closed

    The output of this command looks like this:

    Id  Title     AssignedTo Status Priority AffectedUser LastModified
    --  -----     ---------- ------ -------- ------------ ------------
    IR4 Need help User1      Closed        5 NewUser      5/24/2011 4:39:54 PM
    IR5 Need help User1      Closed        5 NewUser      5/24/2011 4:39:55 PM
    IR6 Need help User1      Closed        5 NewUser      5/24/2011 4:39:56 PM
    IR7 Need help User2      Closed        5 NewUser      5/24/2011 4:39:57 PM
    IR8 Need help User1      Closed        5 NewUser      5/24/2011 4:39:58 PM
    IR9 Need help User1      Closed        5 NewUser      5/24/2011 4:39:59 PM

    We need to reopen the incident that was assigned to User2 because he didn't do something correctly according to company procedures.  Reopening the incident will allow him to complete the closure correctly.  So IR7 needs to be reopened.

    Execute the following command to reopen incident IR7:

       Get-SCSMIncident -ID IR7 | Set-SCSMIncident -Status Active

    Executing this command from the Powershell prompt does not return any message, just a prompt awaiting the next command.  If we want to see the results we can either look in the console or issue another command:

        Get-SCSMIncident -ID IR7

    This would return the following information:

    Id  Title     AssignedTo Status Priority AffectedUser LastModified
    --  -----     ---------- ------ -------- ------------ ------------
    IR7 Need help User2      Active        5 NewUser      5/24/2011 4:45:17 PM

    Verifying this in the console we see that the incident is now open and is capable of being edited like any other open incident. 

    Posted May 24 2011, 05:22 PM by markmears with no comments
    Filed under:
  • Service Manager SP1 CU2 released!

    Posted May 23 2011, 02:39 PM by markmears with no comments
    Filed under:
  • Error opening unsealed Management Pack in Authoring Tool

    When opening an unsealed Management Pack from the default management packs that are shipped with Service Manager you may receive the following error:


    This error is thrown because the Service Manager Authoring tool automatically loads all of the default management packs when a management pack is opened  To work around this error and open the management pack anyway, perform the following steps:

    1.  Copy the Management Pack to a new file name.  For example copy ServiceManager.IncidentManagement.Configurationxml to Custom.IncidentManagement.Configuration.xml. 

    2.  Open the new XML file in Notepad or some other XML Editor of your choice.

    3.  Near the top of the XML file you will see the Manafest section as shown below:


    4.  Notice the ID contains the name of the original XML file.  Change this to match the name you gave to the new XML file you created,  For example, I copied ServiceManager.IncidentManagement.Configurationxml to Custom.IncidentManagement.Configuration.xml.  I would need to have the Manifest section look like the below example:


    5.  Attempt to reopen the new XML Management Pack in the Authoring tool.  It should open successfully now since no other object or management pack exists with that name.

    Posted May 22 2011, 04:13 PM by markmears with no comments
    Filed under:
  • Limitations of the SCSM Self Service Portal in SCSM 2010 SP1

    When one hears about the Self-Service Portal feature in SCSM one has an expectation of what such a portal would encompass what feature set it might have.  I know I did.  However due to the features that the Microsoft Product Team has implemented, an analyst, for example, does not have access to update a ticket that is assigned to him.  Per the documentation, the Analyst Portal has the functionality of the Change Management while the End User Portal works with the Incident Management.  End Users can open and close incidents and view their own incidents.  Notice that I did not use the word “update”.  Updating of incidents is not possible in this version of the portal.

    Posted May 13 2011, 02:46 AM by markmears with no comments
    Filed under:
More Posts Next page »
Copyright -, Inc. - 2010 All Rights reserved.
Powered by Community Server (Commercial Edition), by Telligent Systems