locked
Strange behavior of SCSM 2012 CMDlets RRS feed

  • Question

  • I am working with the new SCSM cmdlets, and I have a strange issue here...

    Run this command....

    PS C:\> Get-SCClassInstance -Class ($crclass) | select ID
    
    Id
    --
    CR1081
    CR1094
    CR1102
    CR1121
    CR1127
    CR1138
    CR1168
    CR1184
    CR121

    But when I try to filter on the ID property and I get this error

    PS C:\> Get-SCClassInstance -Class ($crclass) -Filter "ID -eq CR121"
    Get-SCClassInstance : Id='CR121' -- Guid should contain 32 digits with 4 dashes
     (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
    At line:1 char:20
    + Get-SCClassInstance <<<<  -Class ($crclass) -Filter "ID -eq CR121"
        + CategoryInfo          : InvalidOperation: (Microsoft.Syste...InstanceCom
       mand:GetSCClassInstanceCommand) [Get-SCClassInstance], UnknownDatabaseExce
      ption
        + FullyQualifiedErrorId : ExecutionError,Microsoft.SystemCenter.Core.Comma
       nds.GetSCClassInstanceCommand

    Am I doing something wrong? would seem pretty straight forward??

    Joshua Fuente

    Friday, December 7, 2012 1:52 AM

Answers

  • This error occures because there's an "ID" for a work item object, and there's an ID for the Service Manager object that represents that work item object. Sounds a little confusing, but basically, there's a "generic property" called ID that the Service Manager framework uses to identify objects. This ID is actually a GUID. There is also a work item class property called "ID" that we mere mortals use to identify our work items (SR1234, etc).

    Next, there are two query types you can run..the simple "Property = Value" style, like you use with -Filter, and the XML style, where you write up that long XML block and use that as your query criteria. When you run a query using the simple "property=value" style the generic property takes precedence over the class property. Thus, the query expects a GUID and will throw an error.

    The efficient way to run the query is to use the XML style, using the -Criteria option..but that requires creating an EnterpriseManagementObjectCriteria and the associated XML query block.

    http://blogs.msdn.com/b/scplat/archive/2010/12/27/using-sdk-criteria-querying-instances.aspx

    Dennis's workaround works, but the downside is that it brings back _every_ work item and then filters them. Using the criteria/query styles filters the objects before bringing them back.

    http://blogs.technet.com/b/servicemanager/archive/2011/04/04/properly-querying-scsm-using-smlets-get-scsmobject-cmdlet.aspx

    • Marked as answer by NachoScript Monday, December 10, 2012 6:28 PM
    Monday, December 10, 2012 4:25 PM

All replies

  • Hello Joshua,

    I don't have the answer why this doesn't work.

    But I do have a workaround, I am using the Where-Object cmdlet:

    Get-SCClassInstance -class ($crclass) | Where-Object {$_.ID -eq 'CR121'}
    Hope this helps


    - Dennis | Netherlands | Blog | Twitter

    Monday, December 10, 2012 9:14 AM
  • Thanks, I am aware of that, but its far less efficient.

    I am going to leave the question open a bit longer, and see if anyone else replies.


    Joshua Fuente

    Monday, December 10, 2012 3:19 PM
  • It looks to me like your filter should work.  It would be great if you reported this behavior on the Connect site.  You will need to join the "SC 2012 SP1 Evaluation", and then you can submit feedback on the SP1 beta for SM.

    Nash Pherson, Senior Systems Consultant
    http://www.nowmicro.com - http://myitforum.com/myitforumwp/author/npherson
    <-- If this post was helpful, please click "Vote as Helpful".




    • Edited by NPherson Monday, December 10, 2012 5:07 PM
    Monday, December 10, 2012 4:04 PM
  • This error occures because there's an "ID" for a work item object, and there's an ID for the Service Manager object that represents that work item object. Sounds a little confusing, but basically, there's a "generic property" called ID that the Service Manager framework uses to identify objects. This ID is actually a GUID. There is also a work item class property called "ID" that we mere mortals use to identify our work items (SR1234, etc).

    Next, there are two query types you can run..the simple "Property = Value" style, like you use with -Filter, and the XML style, where you write up that long XML block and use that as your query criteria. When you run a query using the simple "property=value" style the generic property takes precedence over the class property. Thus, the query expects a GUID and will throw an error.

    The efficient way to run the query is to use the XML style, using the -Criteria option..but that requires creating an EnterpriseManagementObjectCriteria and the associated XML query block.

    http://blogs.msdn.com/b/scplat/archive/2010/12/27/using-sdk-criteria-querying-instances.aspx

    Dennis's workaround works, but the downside is that it brings back _every_ work item and then filters them. Using the criteria/query styles filters the objects before bringing them back.

    http://blogs.technet.com/b/servicemanager/archive/2011/04/04/properly-querying-scsm-using-smlets-get-scsmobject-cmdlet.aspx

    • Marked as answer by NachoScript Monday, December 10, 2012 6:28 PM
    Monday, December 10, 2012 4:25 PM
  • Thanks Aaron, I will give the -criteria options a try...

    Joshua Fuente


    • Edited by NachoScript Monday, December 10, 2012 6:29 PM
    Monday, December 10, 2012 6:28 PM
  • For standard cmdlets field names are case sensitive. So just use "Id" field name:

    Get-SCClassInstance -Class ($crclass) -Filter "Id -eq CR121"
    


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    • Proposed as answer by Aaron Croasmun Monday, December 10, 2012 9:58 PM
    Monday, December 10, 2012 7:49 PM
  • well, now don't I feel silly. I forgot about the ID being case sensitive.

    Monday, December 10, 2012 9:54 PM
  • Yep, I'm always confused around the Id field because with SCSM Shell you must remember about case sensitive but with SMLets you must remember about using Name instead Id.

    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    Monday, December 10, 2012 10:06 PM
  • Unmark my post as an answer since it's definitely not a correct answer :)
    Monday, December 10, 2012 10:12 PM