I've been using Get-SPContentDeploymentPath to do some validation on the content deployment paths I'm creating. However, there seems to be some discrepancies between the members printed to the screen and the actual members contained within the object. Below, I've stored the return object from Get-SPContentDeploymentPath into a result object:

The values are printed to the screen, but trying to fetch the values individually results in null

Piping this object to 'gm' (get members), we see that the members of this object are completely different from what gets printed, and what is listed on the API. In fact, the parameters the cmdlet takes correspond to the values above, but the object itself uses different naming conventions.

The table below shows the mappings between the printed members and "real" members

Printed Members Real Members
Name Name
Description Description
SourceSPWebApplication SourceServerUri
SourceSPSite SourceSiteCollection
DestinationCentralAdministrationURL DestinationAdminServerUri
DestinationSPWebApplication DestinationServerUri
DestinationSPSite DestinationSiteCollection
Authentication AuthenticationType
UserID UserID
PathEnabled IsPathEnabled
CompressionEnabled EnableCompression
EventReceiversEnabled EnableEventReceivers
ImportUserInfoDateTimeOption IncludeUserInfoDateTime
DeploySecurityInformationOption IncludeSecurity
KeepTemporaryFilesOption KeepTemporaryFiles

 

Keep in mind that not all members return a String, some return more complex objects. Hopefully this clears up any confusion people have had about this. I'm not sure if any other cmdlets suffer from this same issue, I've only noticed it on Get-SPContentDeploymentPath so far