Votes from Connect: 22

Original Date Submitted: 12/27/2013 7:41:19 AM

Description:
Contact Information
Handle: Mark Michaelis
Site Name: PowerShell
Feedback ID: 812361

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Hi,

I have created several providers that work for files (e.g. Skydrive, Dropbox, photo sights, etc.). I would like to be able to copy files from the file system up to these providers and vice-versa. Please provide some means so that the provider copy-item and move-item operations will work across providers. Without this feature the following error is returned:

 "Source and destination did not resolve to the same provider."

Currently there doesn't seem to be any work around while still using the Copy-Item/Move-Item pattern.

Thanks,
Mark

Mark Michaelis | Chief Technical Architect, Microsoft Regional Director & MVP
Author of Essential C# 5.0

Product Studio item created by Connect Synchronizer due to creation of feedback ID 812361 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=812361).

Repro Steps:
Expected Results:

Internal BugId: 7564

Votes from Connect: 11

Original Date Submitted: 11/21/2013 7:25:26 AM

Description:
Contact Information
Handle: Gary Bonie
Site Name: PowerShell
Feedback ID: 809166

Frequency: Always Happens
Regression: I do not know if this issue existed previously

Problem Description:
All help updates correctly except the help for AppBackgroundTask.

Update-Help : Failed to update Help for the module(s) 'AppBackgroundTask' with UI culture(s) {en-US} : The value of the HelpInfoUri
key in the module manifest must resolve to a container or root URL on a website where the help files are stored. The HelpInfoUri
'http://technet.microsoft.com/en-us/library/dn296421.aspx' does not resolve to a container.
At line:1 char:1
+ Update-Help -Verbose -force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidOperation: (:) [Update-Help], Exception

+ FullyQualifiedErrorId : InvalidHelpInfoUri,Microsoft.PowerShell.Commands.UpdateHelpCommand

PS C:\WINDOWS\system32> $PSVersionTable

Name Value

PSVersion 4.0

WSManStackVersion 3.0

SerializationVersion 1.1.0.1

CLRVersion 4.0.30319.34003

BuildVersion 6.3.9600.16394

PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}

PSRemotingProtocolVersion 2.2

Product Studio item created by Connect Synchronizer due to creation of feedback ID 809166 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=809166).

Repro Steps:
PS C:> Update-Help -Verbose -force

Expected Results:

Internal BugId: 6488

Votes from Connect: 20

Original Date Submitted: 5/10/2013 10:10:12 PM

Description:
Contact Information
Handle: Kirk Munro
Site Name: PowerShell
Feedback ID: 786717

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
It is well known that the line continuation implementation is challenging (the fact that it doesn't work if there is anything after it, even just whitespace, causes problems for beginners; also, it doesn't help that it simply looks like a spec of dirt on the screen). Yet some of us find that commands are more readable when they span multiple lines, like this:

Do-Something `

-Param value1 `

-Param value2

Also, some of us use line continuance so that we can start a stage in a pipeline with the pipe symbol, like this:

Do-Something `

| Do-SomethingWithIt `

| Do-SomethingElse

Both of these syntaxes make for easy identification of commands that span multiple lines in structured documents.

With these syntaxes being desirable, and with the strong dislike for the backtick line continuance, why not just support these syntaxes without the line continuance character requirement? It would make scripts like this even easier to write, and if you could have comment lines in the middle (please do) it would allow for more detailed comments where desired. Plus, with support for comments in the middle you could play around with pipelines and parameters more easily by commenting/uncommenting various stages by simply commenting or uncommenting lines.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 786717 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=786717).

Repro Steps:
Get-Command

-Verb Get

-Module Microsoft.PowerShell.Management

Get-Service wuauserv

| Where-Object Status -eq Stopped

| Start-Service -Whatif

Expected Results:
Both of these should work as is without requiring line continuance characters. Line continuance characters should be reserved for abnormal line breaks in scripts.

Internal BugId: 4209

Votes from Connect: 10

Original Date Submitted: 5/9/2013 12:57:09 AM

Description:
Contact Information
Handle: Kirk Munro
Site Name: PowerShell
Feedback ID: 786596

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
In PowerShell 3 you cannot use Add-Type to compile C# code written using CSharp 4.0. Nor can you compile C# code written using CSharp 5.0. The highest version available in the Language parameter is CSharpVersion3.

Please add CSharpVersion4 and CSharpVersion5 support to Add-Type so that it is keeping up with the times.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 786596 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=786596).

Repro Steps:
Try to use Add-Type to define C# classes with code that requires C# 4.0 or C# 5.0. A simple example is a class with methods that have optional parameters with default values.

Expected Results:
You should be able to do this.

Internal BugId: 4204

Votes from Connect: 10

Original Date Submitted: 12/6/2012 12:15:54 AM

Description:

Contact Information
Handle: Trevor Sullivan
Site Name: PowerShell
Feedback ID: 773554

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
When writing a PowerShell function, script, or ScriptBlock that accepts named parameters, it is sometimes desirable to have the end user prompted for input. PowerShell input prompts work great for strings and integers, but fails with other data types (eg. bool, object).

Product Studio item created by Connect Synchronizer due to creation of feedback ID 773554 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=773554).

Repro Steps:
function Test-Parameter {

[CmdletBinding()]

param (

    [Parameter(Mandatory = $true, HelpMessage = "Please input a Process object")]

    [System.Diagnostics.Process] $input

)


Write-Host -Object $input.Description;

}

$Process = (Get-Process)[10]; # Get a System.Diagnostics.Process object
Write-Host -Object $proc.GetType().FullName; # Make sure we actually have a System.Diagnostics.Process object

Test-Parameter; # Call the Test-Parameter function. When prompted for input

                                           # plug in $Process.

#

function Test-Parameter {

[CmdletBinding()]

param (

    [Parameter(Mandatory = $true, HelpMessage = "Please input a Process object")]

    [bool] $TrueOrFalse

)


Write-Host -Object $TrueOrFalse;

}

Test-Parameter; # When prompted, type $false. The function returns $true, because the inputs is evaluated as a string.

Expected Results:
You should be able to specify variable input when prompted to input parameter values. For boolean values, you should be able to input $true or $false when prompted. For arbitrary objects, you should be able to specify a variable that contains the object you want to use as input.

Internal BugId: 3995

Votes from Connect: 10

Original Date Submitted: 10/10/2012 11:44:45 PM

Description:
Contact Information
Handle: Aleksandar Nikolić
Site Name: PowerShell
Feedback ID: 766908

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
When you pipe something to Select-Object –First (or –Last, -Skip, and –Unique), the input and the output type should be the same, because you are not changing any member.

And that’s true for every type (compare, for example, Get-Process | Get-Member and Get-Process | select -First 1 | Get-Member) , except for the PSCustomObject type. In case of the PSCustomObject type will be prefixed with "Selected.".

PS C:> import-csv .\comps.csv | gm

TypeName: System.Management.Automation.PSCustomObject

PS C:> import-csv .\comps.csv | select -First 1 | gm

TypeName: Selected.System.Management.Automation.PSCustomObject

PS C:> import-csv .\comps.csv | select -unique | gm

TypeName: Selected.System.Management.Automation.PSCustomObject

Product Studio item created by Connect Synchronizer due to creation of feedback ID 766908 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=766908).

Repro Steps:
Expected Results:

Internal BugId: 3868

Votes from Connect: 10

Original Date Submitted: 9/11/2012 2:44:04 AM

Description:
Contact Information
Handle: Jason Shirk
Site Name: PowerShell
Feedback ID: 761976

Frequency: Always Happens
Regression: Yes, this happens in previous released versions

Problem Description:
V3 added useful event handlers during command discovery including:

• Pre command lookup


• Post command lookup


• Command not found

It would be very useful to have similar events for modules:

• Pre module lookup


• Post module lookup


• Module not found

I'm most interested in post module lookup, but the others seem useful as well.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 761976 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=761976).

Repro Steps:
Expected Results:

Internal BugId: 3795

Votes from Connect: 10

Original Date Submitted: 8/28/2012 1:41:15 AM

Description:
Contact Information
Handle: Shay Levi
Site Name: PowerShell
Feedback ID: 759607

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
When the Test-Connection cmdlet is used to ping a computer name, the ProtocolAddress property is displaying the resolved ip address (in IPV4Address and ProtocolAddress properties).

PS> Test-Connection -ComputerName PC1 -Count 1 | ft -a

Source Destination IPV4Address IPV6Address Bytes Time(ms)

PC2 PC1 10.10.10.10 32 0

However, Test-Connection doesn't attempt to resolve IP addresses, this is usually done by setting the ResolveAddressNames
Win32_PingStatus property to TRUE, but there's no way to set it via any parameter of Test-Connection.

Having a switch parameter can solve this and offer another way to resolve ip addresses to names.

PS> Test-Connection -ComputerName PC1 -ResolveAddressNames

Currentl;y we can get then same functionality with this:

PS> Get-WmiObject Win32_PingStatus -Filter "Address='10.10.10.10' and ResolveAddressNames='true'" | ft ResolveAddressNames,ProtocolAddress*

ResolveAddressNames ProtocolAddress ProtocolAddressResolved

   True     10.10.10.10      PC1

Product Studio item created by Connect Synchronizer due to creation of feedback ID 759607 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=759607).

Repro Steps:
Expected Results:

Internal BugId: 3769

Votes from Connect: 15

Original Date Submitted: 7/15/2012 7:48:53 PM

Description:
Contact Information
Handle: Shay Levi
Site Name: PowerShell
Feedback ID: 753770

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
When you issue the Get-HotFix you can see that not all HotFixId's follow a naming convention. For example, on my system some starts with KBxxxxxx and some with numbers only (in some cases 5 digits and in others 6 digits).

That makes it very hard to search for specific hot fixes when all you know is a part of the Id.
That's why the Get-HoptFix -Id parameter should support wildcards. Without wildcard support we must filter using Where-Object (performance hit) or by resorting to WMI.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 753770 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=753770).

Repro Steps:
Get-HotFix -Id *644 # fails

Expected Results:
Output hot fixed that ends with 644

Internal BugId: 3711

Votes from Connect: 28

Original Date Submitted: 6/26/2012 10:32:58 PM

Description:
Contact Information
Handle: Trevor Sullivan
Site Name: PowerShell
Feedback ID: 750939

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
The Windows PowerShell ISE does not currently display .NET object constructor signatures. When instantiating .NET objects using the New-Object cmdlet, along with its -TypeName and -ArgumentList parameters, it would be a great workflow enhancement to have the ISE's Intellisense display the object constructor signatures, such that a developer does not have to resort to pulling up the MSDN documentation online much less frequently. Memorizing object constructor signatures can be challenging for .NET types that are not often used, or for new developers who are exploring an unfamiliar .NET type.

For bonus points, it would be awesome to have the ISE resolve & display a clickable link that would take a developer directly to the MSDN documentation for the .NET type name that is specified in the -TypeName parameter, assuming that it is part of the Microsoft .NET Base Class Library (BCL). Obviously, for 3rd party .NET assemblies, this may be more challenging, although it may still be extractable from assembly metadata.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 750939 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=750939).

Repro Steps:
Type the following command into the ISE, and observe that it does not display any Intellisense for the .NET object constructor:

New-Object -TypeName System.IO.MemoryStream -ArgumentList

Expected Results:
Once the -ArgumentList parameter has been specified (after the -TypeName parameter has already been specified), the PowerShell ISE's Intellisense feature should be intelligent enough to pick up that the developer desires to use one of the object constructors for the System.IO.MemoryStream, and should display the available constructor signatures.

Internal BugId: 3674

Votes from Connect: 10

Original Date Submitted: 5/9/2012 10:46:55 PM

Description:
Contact Information
Handle: Kirk Munro
Site Name: PowerShell
Feedback ID: 741367

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
This is a request for v.Next (post v3). More and more admins have been asking how they can store modules in a central repository so that they can centrally manage them while making them available to all systems where they use PowerShell. This is easy to do, however they need to be careful because some modules are designed to store configuration/state information in their own module folder. That won't work if the end user doesn't have rights to the location where the module is stored. It's also not a good practice to follow because there are specific locations where application data should be stored (Isolated Storage, for example).

I would like to see an enhancement made such that modules either have access to a new automatic variable ($PSModuleLocalStorage) with methods that facilitate writing/reading module configuration data to/from disk in the right location for each user of that module, or a small set of cmdlets specific to modules that are designed to facilitate the same thing. This feature should use the module GUID as part of the path automatically so that changes in module names don't affect the location where configuration/state information is stored.

There are other possibilities for this feature that could be considered as well, such as:
1. Storing the version of the module with the data so that module authors can detect the version when reading from disk and then perform upgrades if the data being used has changed between versions.
2. Encrypting the data written to disk automatically so that only the current user can access it (could be a module-specific setting).
3. Providing easy reading/writing of a single data file (the most common/simple use case), with support for reading/writing of additional files to the same location (for more complex module needs).

This is just a request for the most basic functionality to start though.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 741367 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=741367).

Repro Steps:
Try to store module configuration/state data for the current user in the module folder when the module is on a file share that the user doesn't have access to. You can't do that. Now try to easily identify where you should store that data and store it there so that it is easily accessible to the module even if the name changes and so that the folder is automatically created if it does not exist without writing a lot of script to handle that. You can't, it takes a fair amount of script to do this right.

Expected Results:
This should be easier, and it should promote best practices automatically, so that module authors do this consistently and correctly every time.

Internal BugId: 3569

Votes from Connect: 40

Original Date Submitted: 3/10/2012 1:56:58 PM

Description:

Contact Information
Handle: ramseyg [MVP]
Site Name: PowerShell
Feedback ID: 730195

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
We have a user-authenticated proxy server on our corporate network. All systems/users must authenticate to access the internet. It is seamless from an internet browser perspective. We have an autoconfiguration script, or we can just enter the proxy information into internet explorer settings, and can browse to the web without any challenge/password.

I can even run commands like get-help get-command -online successfully. But I consistently receive an error when I attempt to run save-help from a corporate network connection. See attached image for more information.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 730195 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=730195).

Repro Steps:
see description. Just configure internet access to require proxy auth, and then attempt to run 'save-help'

Expected Results:
as long as I can access the internet, I should be able to run the 'save-help' command without issue.

Internal BugId: 3426

Votes from Connect: 10

Original Date Submitted: 3/8/2012 8:34:09 AM

Description:
Contact Information
Handle: Nektar
Site Name: PowerShell
Feedback ID: 729570

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
In other scripting languages such as Python and MatLab, you can create say a list of all numbers from 0 to 100 stepping by 5 each time by typing something like 0:5:100. Also, you can splice an array from a point to the end by typing 0:end or in Python the last item is -1. In Powershell the .. operator can only accept a starting and an ending value but from what I know not a stepping value and not a keyword to tell it to find the end of ann array but you have to use the more wordy .length notation instead. So, for example I can't get all the even lines from a file by typing $l = cat file.txt; $f[0..2..end]; for example. I have to write a for loop instead. Please, since you have the .. operator, do not let it stand there without being used. Just add these two little things to it and it could eliminate the usage of so many loops. Otherwise, the .. operator is very limited unlike most other scripting languages.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 729570 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=729570).

Repro Steps:
Type 1..2..9; notice that you get an error.

Expected Results:
A) When I type 0..5..100 I want to get an array of all the numbers from 0 to 100 stepping by 5 each time, i.e. 0, 5, 10, 15, ..., 90, 95, 100.
B) When I type $arr[5..2..end] I want to be able to get all the even elements of the array $arr from element 5 to ($arr.length - 1).

Internal BugId: 3419

Votes from Connect: 10

Original Date Submitted: 12/7/2011 8:49:03 AM

Description:
Contact Information
Handle: MMarcolini
Site Name: PowerShell
Feedback ID: 712014

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
The Output pane is gone and the command pane has been transformed into the frankly clunky blue powershell command prompt. Why? This is like taking 3 steps backwards.

I use the ISE to interactively manage my windows systems in much the same way that I use an xterm to manage my unix systems. I typically have many local and remote command tabs open separated by task with snippets of code in the "Untitled#" Script Pane that eventually make their way into my OneNote script repository. I periodically snapshot my history and output pane to capture workflow.

I prefer the ISE over powerGUI and other editors because it's faster and because I MUCH prefer the way it manages the Command Pane and the Output Pane. The separation is both visually and functionally appealing. If I want to run something in a non-gui command prompt, I just click on the handy "Start Powershell.exe" provided.

Please restore the Output pane! This is such a big deal that I've actually rolled back to the older CTP.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 712014 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=712014).

Repro Steps:
Expected Results:

Internal BugId: 3175

Votes from Connect: 13

Original Date Submitted: 9/21/2011 11:21:52 AM

Description:
Contact Information
Handle: Matthew Reynolds [MSFT]
Site Name: PowerShell
Feedback ID: 689864

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Remote registry is a core feature of Windows since before I can remember. IT Pros shouldn't have to resort to external exes, WMI, WinRM or .Net methods to use remote regsitry from powershell. They should be able to script naturally against remote registry.

Providers/cmdlets which interact with registry (e.g., set-item, get-item, etc) should be updated to use remote registry just like they can use remote files via SMB. The underlying .Net classes support it, Windows supports it.

Something like Get-Item \remotemachine\HKLM:\System\Blah

Product Studio item created by Connect Synchronizer due to creation of feedback ID 689864 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=689864).

Repro Steps:
Expected Results:

Internal BugId: 3027

Votes from Connect: 14

Original Date Submitted: 6/14/2011 7:44:51 PM

Description:
Contact Information
Handle: Vadims Podans
Site Name: PowerShell
Feedback ID: 675309

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
'-Filter' parameter tries to bind filter pattern to a both general name and a name in the 8.3 notation (MS-DOS format). This causes that in the 'Get-ChildItem -Filter' output appears unexpected items. For details see repro section.

Also this may cause catstrophic results if Get-ChildItem output is passed to Remove-Item cmdlet. Administrator will not expect that Program Files folders will match this pattern. Also PowerShell haven't native ways to determine certain object (file or folder) short name in 8.3 notation and returned object doesn't contain related property. This can be done dy running 'dir.exe' with /x switch.

Also documentation has no mention about this behavior.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 675309 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=675309).

Repro Steps:
[↓] [vPodans] dir c:\ -Filter *1

Directory: C:\

Mode LastWriteTime Length Name

d-r-- 08.04.2011. 1:08 Program Files

[↓] [vPodans] dir c:\ -Filter *2

Directory: C:\

Mode LastWriteTime Length Name

d-r-- 24.02.2011. 8:30 Program Files (x86)

[↓] [vPodans]

Expected Results:
Since neither of outputed objects matches this pattern nothing should be returned unless any object name ends with '1'.

Internal BugId: 2944

Votes from Connect: 13

Original Date Submitted: 12/20/2010 5:55:34 AM

Description:
Contact Information
Handle: Bartek Bielawski
Site Name: PowerShell
Feedback ID: 632464

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
Currently I see no easy way to get type of registry values. Info presented by Get-ItemProperty is not very helpful. I found workaround for that (sample):
$key = Get-Item 'HKLM:\software\Microsoft\windows\CurrentVersion\policies\Explorer'
$Property = @{Name = 'Property'; Expression = {$}}
$Value = @{Name = 'Value'; Expression = {$key.GetValue($) }}
$ValueType = @{Name = 'Value Type'; Expression = {$key.GetValueKind($_)}}
$key.Property | select $Property, $Value, $ValueType
I think it would be better if Get-ItemProperty would return type too.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 632464 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=632464).

Repro Steps:
Expected Results:

Internal BugId: 2773

Votes from Connect: 18

Original Date Submitted: 12/13/2010 7:55:24 PM

Description:
Contact Information
Handle: HPH2
Site Name: PowerShell
Feedback ID: 630828

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
From: http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/7d2a0b0e-254f-4725-9c02-20744cd3cdd5/

Powershell version 2.0

Background:
I have a script successfully assembling information about servers in our primary domain.
Now i am trying to use PowerShell Remoting to include information about servers in our DMZ zones.
This works great.

Except when i try to query the Active Directory.

Following runs fine in a powershell window on the server dzms01 in a remote desktop session:

PS C:> $DomainRootPath='LDAP://DC=beodmz,DC=beo,DC=dk'
PS C:> $servername='dzms01'
PS C:> $searcher = new-object DirectoryServices.DirectorySearcher([ADSI] $DomainRootPath)
PS C:> $searcher.filter = "(&(objectClass=computer)(Name=$servername))"
PS C:> $searcher.CacheResults = $true
PS C:> $searcher.SearchScope = 'Subtree'
PS C:> $searcher.PageSize = 1000
PS C:> $ad=$searcher.FindOne()
PS C:> $ad

Path Properties

LDAP://CN=DZMS01,OU=ProductionServers,OU=Servers,DC=beod... {operatingsystem, countrycode, cn, lastlogoff...}

PS C:> $searcher

CacheResults : True
ClientTimeout : -00:00:01
PropertyNamesOnly : False
Filter : (&(objectClass=computer)(Name=dzms01))
PageSize : 1000
PropertiesToLoad : {}
ReferralChasing : External
SearchScope : Subtree
ServerPageTimeLimit : -00:00:01
ServerTimeLimit : -00:00:01
SizeLimit : 0
SearchRoot : System.DirectoryServices.DirectoryEntry
Sort : System.DirectoryServices.SortOption
Asynchronous : False
Tombstone : False
AttributeScopeQuery :
DerefAlias : Never
SecurityMasks : None
ExtendedDN : None
DirectorySynchronization :
VirtualListView :
Site :
Container :

PS C:> $searcher.SearchRoot

distinguishedName : {DC=beodmz,DC=beo,DC=dk}
Path : LDAP://DC=beodmz,DC=beo,DC=dk

PS C:> $searcher.SearchRoot.path
LDAP://DC=beodmz,DC=beo,DC=dk
PS C:>

Trying to do the same thing from my PC using powershell remote, and using the same login credentials, i get this:

PS C:> $ses = New-PSSession -ComputerName 'dzms01' -Credential $cred
PS C:> Invoke-Command {$DomainRootPath='LDAP://DC=beodmz,DC=beo,DC=dk'} -session $ses
PS C:> Invoke-Command {$DomainRootPath} -session $ses
LDAP://DC=beodmz,DC=beo,DC=dk
PS C:> Invoke-Command {$servername='dzms01'} -session $ses
PS C:> Invoke-Command {$searcher = new-object DirectoryServices.DirectorySearcher([ADSI] $DomainRootPath)} -session $ses
PS C:> Invoke-Command {$searcher.filter = "(&(objectClass=computer)(Name=$servername))"} -session $ses
PS C:> Invoke-Command {$searcher.CacheResults = $true} -session $ses
PS C:> Invoke-Command {$searcher.SearchScope = 'Subtree'} -session $ses
PS C:> Invoke-Command {$searcher.PageSize = 1000} -session $ses
PS C:> Invoke-Command {$ad=$searcher.FindOne()} -session $ses
Exception calling "FindOne" with "0" argument(s): "An operations error occurred.
"

+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

+ FullyQualifiedErrorId : DotNetMethodException

PS C:> Invoke-Command {$searcher} -session $ses

PSComputerName : dzms01
RunspaceId : 19248cc5-e3b2-422d-9f16-62b6419cc0f8
PSShowComputerName : True
CacheResults : True
ClientTimeout : -00:00:01
PropertyNamesOnly : False
Filter : (&(objectClass=computer)(Name=dzms01))
PageSize : 1000
PropertiesToLoad : {}
ReferralChasing : External
SearchScope : Subtree
ServerPageTimeLimit : -00:00:01
ServerTimeLimit : -00:00:01
SizeLimit : 0

The following exception occurred while retrieving member "StringSerializationSource": "An operations error occurred.
"

+ CategoryInfo          : NotSpecified: (:) [], ExtendedTypeSystemException

+ FullyQualifiedErrorId : CatchFromBaseGetMember

PS C:> Invoke-Command {$searcher.SearchRoot} -session $ses
System.DirectoryServices.DirectoryEntry
PS C:> Invoke-Command {$searcher.SearchRoot.path} -session $ses
PS C:> Invoke-Command {$searcher.filter} -session $ses
(&(objectClass=computer)(Name=dzms01))
PS C:>

It seems as the DirectoryServices.DirectorySearcher object is somehow garbled.
Can anyone help me in the right direction?

Product Studio item created by Connect Synchronizer due to creation of feedback ID 630828 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=630828).

Repro Steps:
Se description above.

Expected Results:
Se description above.

Internal BugId: 2770