Some-CmdLet | Select * | Select -First 1
Will give you all the properties of the first object that is returned by the Cmdlet, but not necessarily all the properties that the objects returned by the Cmdlet are capable of containing.
Many if not most Cmdlets return dynamic objects, where a property simply will not exist (as opposed to the property existing but with a null or blank value) if that property is not populated in whatever provider from which the data is retrieved.
Edit2: Also, you can try something like this:
PS C:\> ForEach($P In $(Get-ADUser ryan -Properties *).PSObject.Properties) { $P.Name }
AccountExpirationDate
accountExpires
AccountLockoutTime
AccountNotDelegated
AllowReversiblePasswordEncryption
BadLogonCount
badPwdCount
c
CannotChangePassword
CanonicalName
....
userAccountControl
userCertificate
UserPrincipalName
uSNChanged
uSNCreated
whenChanged
whenCreated
PropertyNames
PropertyCount
You can't really see what the Cmdlet could possibly return before you even run it, because of dynamic return objects... there is no knowing exactly what it will return before it's run. For instance, an object returned by Get-ADUser may or may not have the property 'EmployeeID' based on whether it is populated in AD or not. I don't mean that the property will have a value of $Null or [String]::Empty, I mean that property will literally not exist on that object.
If you use Set-StrictMode, this is especially apparent, as it will bark at you for trying to filter on a non-existent property of an object, even if the property exists on some but not other of the objects in the total returned set.
To elaborate on my point... when I'm authoring a Cmdlet, I can have logic in my Cmdlet, where if a certain condition is true, I can add a certain new property to the object to be returned, or otherwise the property is not returned...
if($x = $true)
{
$object | Add-Member -Type NoteProperty -Name $name -Value $y
}
Else
{
# In this case, $object will NOT have the above property!
}