hi everyone

i tried this with powershell and SMLets installed on the remote Computer:

Invoke-Command -ComputerName srv1 -ScriptBlock {Get-SCSMClass -Name ^classname$}

it appears that this command delivers not as expected an object of type Microsoft.EnterpriseManagement.Configuration.ManagementClass but of type Deserialized.Microsoft.EnterpriseManagement.Configuration.ManagementClass

has anyone an idea why this happens or how to convert from Deserialized to "normal" ManagementPackClass

thanks!

What is the reason to use -Invoke?

You can add the "-ComputerName" parameter at each SMlets command:

Get-SCSMClass -Name System.WorkItem.Incident$ -ComputerName SCSM2012R2-MS

Hope this helps.

@Andres The most freq. reason is SDK and SMLets. In case of Invoke you no need to have it on the current box.

@dev_SCSM2012

You can get real objects using Invoke. You have to install SDK locally OR execute all your code remotely.

More info:

https://technet.microsoft.com/en-us/library/hh847891.aspx

 DESERIALIZED OBJECTS
    When you run remote commands that generate output, the command output is
    transmitted across the network back to the local computer.

    Because most live Microsoft .NET Framework objects (such as the objects
    that Windows PowerShell cmdlets return) cannot be transmitted over the
    network, the live objects are "serialized". In other words, the live
    objects are converted into XML representations of the object and its
    properties. Then, the XML-based serialized object is transmitted across
    the network.

    On the local computer, Windows PowerShell receives the XML-based serialized
    object and "deserializes" it by converting the XML-based object into a
    standard .NET Framework object.

    However, the deserialized object is not a live object. It is a snapshot of
    the object at the time that it was serialized, and it includes properties
    but no methods. You can use and manage these objects in Windows PowerShell,
    including passing them in pipelines, displaying selected properties, and
    formatting them.

    Most deserialized objects are automatically formatted for display by
    entries in the Types.ps1xml or Format.ps1xml files. However, the local
    computer might not have formatting files for all of the deserialized
    objects that were generated on a remote computer. When objects are
    not formatted, all of the properties of each object appear in the console
    in a streaming list.

    When objects are not formatted automatically, you can use the formatting
    cmdlets, such as Format-Table or Format-List, to format and display
    selected properties. Or, you can use the Out-GridView cmdlet to display
    the objects in a table.

    Also, if you run a command on a remote computer that uses cmdlets that you
    do not have on your local computer, the objects that the command returns
    might not be formatted properly because you do not have the formatting
    files for those objects on your computer. To get formatting data from
    another computer, use the Get-FormatData and Export-FormatData cmdlets. 

    Some object types, such as DirectoryInfo objects and GUIDs, are converted
    back into live objects when they are received. These objects do not need
    any special handling or formatting.