It's annoying that we have to report Bugs in UserVoices
and its a shame that M$$ is fixing BUGS only if there are enough UserVoices.

Anyway:

Hello

If we create this Directory Junction between local Drives:
mklink /J C:\Temp D:\Data\Temp\

So that accessing: C:\Temp\
in fact works here: D:\Data\Temp

Now, if we call e.g.
(Get-Item C:\Temp\MyFile.txt).Target

We get:

Wrong: Target : {C:\Data\Temp\MyFile.txt}
Should be: Target : {D:\Data\Temp\MyFile.txt}
It's a shame that M$ still does not have Unit Tests to validate the most basic situations.
(Assuring to return the right Target on different LinkTypes, is the most important reason for this code.)

This issue exists in all PowerShell versions, probably because even Tools like FindLinks64.exe (Sysinternals) returns the wrong Drive.

Kind regards,
Thomas

It's annoying that we have to report Bugs in UserVoices
and its a shame that M$$ is fixing BUGS only if there are enough UserVoices.

Anyway:

Hello

If we create this Directory Junction between local Drives:
mklink /J C:\Temp D:\Data\Temp\

So that accessing: C:\Temp\
in fact works here: D:\Data\Temp

Now, if we call e.g.
(Get-Item C:\Temp\MyFile.txt).Target

We get:

Wrong: Target : {C:\Data\Temp\MyFile.txt}
Should be: Target : {D:\Data\Temp\MyFile.txt}
It's a shame that M$ still does not have Unit Tests to validate the most basic situations.
(Assuring to return the right Target on different LinkTypes, is the most important reason for this code.)

This issue exists in all PowerShell versions, probably because even Tools like FindLinks64.exe (Sysinternals) returns the wrong Drive.

Kind regards,
Thomas

Recently the new "docs"" site was implemented on MS. The old TechNet and MSDN PowerSHell help documentation is now buried and hard to access. The new help is no longer linked to any help for an CmdLet. We get "404" for all attempts.

Also the new doc style is very pretty but not very useful. Same for the new Net class browser. On both the documentation is incomplete and has many errors compared to the original documentation.

Please address this as using the documentation has become a nightmare. MS needs to go back to managing this directly and try and undo the mess that has been created.

Hi Team,

I am using powershell to trigger commands on remote machine (as this doesn't require anything additional package to install). Recently I am facing issues with running commands on remote machine.

$ComputerName = "***.***.***.***"

Function ExecuteCommand() {
Get-PSDrive
}

Set-Item WSMan:\localhost\Client\Trustedhosts -Value $ComputerName -Concatenate -Force

$Credentials = Import-Clixml $CredentialsFile

Invoke-Command -ComputerName $ComputerName -Credential $Credentials -ScriptBlock ${function:ExecuteCommand} -HideComputerName

I am storing the credentials in the file and using the above script to run commands on remote machine.

1. Get-PSDrive doesn't return mapped network drive details.
2. using net use command to map network path. Network path gets mapped successfully but the status of the mapped network path is unavailable. This was working properly around 1 and half month ago but not sure what changed in past 1 and half month.

I am using
OS: Windows Server 2012 r2
Powershell 4.0
PSRemotingProtocolVersion 2.2

Can someone please help here?

Thanks.

Reset LCM configuration.

Hi and sorry for my funny English.
When I configure my LCM, it's impossible to reset state.
If I want a default configuration, I send a new configuration this default value for all Settings (here, no value, just settings).

[DscLocalConfigurationManager()]
Configuration ResetLCM {
Node MyNode {
Settings {
ActionAfterReboot =
AllowModuleOverwrite =
CertificateID =
ConfigurationDownloadManagers =
ConfigurationID =
ConfigurationMode =
ConfigurationModeFrequencyMins =
DebugMode =
MaximumDownloadSizeMB =
RebootNodeIfNeeded =
RefreshFrequencyMins =
RefreshMode =
ReportManagers =
ResourceModuleManagers =
SignatureValidations =
StatusRetentionTimeInDays =
}}

I think it's easier to use command.

For example, there is a reset configuration for DSCConfigurationDocument.
Remove-DscConfigurationDocument -stage Current

Do you think it's possible for LCM ?
Remove-DscLocalConfigurationManager ?

Regards
Thierry

I have started experiencing an issue on multiple machines where modules that once worked fine now stop functioning correctly.

The issue appears to affect Windows 10 machines that have been in service for some time, but does not affect new Windows 10 installs. This leads me to believe that something like a windows update broke the correct functioning of the module import functionality on these machines at some point in the past.

The modules in question have been SQLPS (installed with SSMS), SqlServer (from PSGallery), and AWSPowerShell (also from PSGallery). The issue is that after installing the module and importing it to the current session, any Cmdlets included in the module are not imported. (That is, anything listed under CmdletsToExport in the module manifest.)

This is unfortunately a "works on my machine" problem, so I will need some help to troubleshoot the root cause of the issue. Others have commented/upvoted my post on StackExchange here: https://superuser.com/q/1328129/4782 and I have found a similar forum post here: https://forums.aws.amazon.com/thread.jspa?threadID=270534&tstart=0

1.Issue:
The VSTS Deploy task Azure PowerShell and Build task - PowerShell are not able to handle secret variables and Azure key vault variables correctly while writing their values to console using write-host. This is causing the values of secret variables to the exposed in log files.

2.Steps to reproduce

a. Sample script:

param(
[Parameter(Mandatory=$true)]
[string]$Secretvariablewithspecialcharacter,
[Parameter(Mandatory=$true)]
[string]$normalVariablewithspecialcharacter,
[Parameter(Mandatory=$true)]
[string]$Secretvariablewithnospecialcharacter
)
Write-Host "Printing parameters:"
Write-Host "Secretvariablewithspecialcharacter: $Secretvariablewithspecialcharacter"
Write-Host "normalVariablewithspecialcharacter: $normalVariablewithspecialcharacter"
Write-Host "Secretvariablewithnospecialcharacter: $Secretvariablewithnospecialcharacter"

$notspecialcharacter="1234abcd";
$specialcharacter ="1234§-¤%#&/=abcd"

Write-Host "notspecialcharacter: $notspecialcharacter"
Write-Host "specialcharacter: $specialcharacter"

if ($Secretvariablewithspecialcharacter -eq $specialcharacter)
{
Write-Host "Secretvariablewithspecialcharacter $Secretvariablewithspecialcharacter and $specialcharacter specialcharacter match"
}

else
{
Write-Host "Secretvariablewithspecialcharacter '$Secretvariablewithspecialcharacter' and '$specialcharacter' specialcharacter don't match"
}

if ($normalVariablewithspecialcharacter -eq $specialcharacter)
{
Write-Host "normalVariablewithspecialcharacter '$normalVariablewithspecialcharacter' and '$specialcharacter' specialcharacter match"
}

else
{
Write-Host " normalVariablewithspecialcharacter'$normalVariablewithspecialcharacter' and '$specialcharacter' specialcharacter don't match"
}
if ($Secretvariablewithnospecialcharacter -eq $notspecialcharacter)
{
Write-Host "Secretvariablewithnospecialcharacter '$Secretvariablewithnospecialcharacter' and '$notspecialcharacter' notspecialcharacter match"
}

else
{
Write-Host " Secretvariablewithnospecialcharacter '$Secretvariablewithnospecialcharacter' and '$notspecialcharacter' notspecialsecretexp don't match"
}

Write-Host "1234abcd";
==========End of script=============

b. Details of VSTS Deploy task - Azure PowerShell

2018-08-27T16:25:01.9014389Z Task : Azure PowerShell
2018-08-27T16:25:01.9014659Z Description : Run a PowerShell script within an Azure environment
2018-08-27T16:25:01.9014900Z Version : 3.1.2
2018-08-27T16:25:01.9015134Z Author : Microsoft Corporation
2018-08-27T16:25:01.9015401Z Help : More Information
2018-08-27T16:25:01.9015965Z ===================================================================

c. Details of Build task - PowerShell

2018-08-27T16:13:20.6918025Z Task : PowerShell
2018-08-27T16:13:20.6918306Z Description : Run a PowerShell script
2018-08-27T16:13:20.6918619Z Version : 1.2.3
2018-08-27T16:13:20.6918890Z Author : Microsoft Corporation
2018-08-27T16:13:20.6919248Z Help : More Information
2018-08-27T16:13:20.6919642Z ===================================================================
d. In the above Azure PowerShell task and build task the Script argument are as follow:

-Secretvariablewithspecialcharacter "$(Secretvariablewithspecialcharacter)"
-normalVariablewithspecialcharacter "$(normalVariablewithspecialcharacter)"
-Secretvariablewithnospecialcharacter "$(Secretvariablewithnospecialcharacter)"

e. The values of the environment variable are set as below

1.Below is a secret environment variable with special character
$(Secretvariablewithspecialcharacter) = "1234§-¤%#&/=abcd"

2.This is a environment variable with special character
$(normalVariablewithspecialcharacter)= "1234§-¤%#&/=abcd"

3.Below is a secret environment variable with no special character
$(Secretvariablewithnospecialcharacter)" = "1234abcd"

Expected behavior after triggering the build:

Printing parameters:
Secretvariablewithspecialcharacter: ******
normalVariablewithspecialcharacter: 1234§-¤%#&/=abcd
Secretvariablewithnospecialcharacter: ******
notspecialcharacter: 1234abcd
specialcharacter: 1234§-¤%#&/=abcd
Secretvariablewithspecialcharacter ***** and 1234§-¤%#&/=abcd specialcharacter match
normalVariablewithspecialcharacter '1234§-¤%#&/=abcd' and '1234§-¤%#&/=abcd' specialcharacter match
Secretvariablewithnospecialcharacter '****' and '1234abcd' notspecialcharacter match

Actual behavior after triggering the build:

2018-08-27T16:13:22.5803219Z Printing parameters:
2018-08-27T16:13:22.5975638Z Secretvariablewithspecialcharacter: 1234�-�%#&/=abcd
2018-08-27T16:13:22.5982503Z normalVariablewithspecialcharacter: 1234�-�%#&/=abcd
2018-08-27T16:13:22.5988068Z Secretvariablewithnospecialcharacter: ***
2018-08-27T16:13:22.5994138Z notspecialcharacter: ***
2018-08-27T16:13:22.6000358Z specialcharacter: 1234A�-A�%#&/=abcd
2018-08-27T16:13:22.6022558Z Secretvariablewithspecialcharacter '1234�-�%#&/=abcd' and '1234A�-A�%#&/=abcd' specialcharacter don't match
2018-08-27T16:13:22.6029803Z normalVariablewithspecialcharacter'1234�-�%#&/=abcd' and '1234A�-A�%#&/=abcd' specialcharacter don't match
2018-08-27T16:13:22.6035509Z Secretvariablewithnospecialcharacter '***' and '***' notspecialcharacter match
2018-08-27T16:13:22.6041088Z ***

As you see above the expected behavior and actual behavior are not same.

Please help in handling the secret variables and secret variables with special characters correctly in the above script.
the statement Write-Host "1234abcd"; should write the value 1234abcd, but instead its masked using ***
Please let me know if you need additional details.

The $PSVersionTable.PSVersion is 5.1.14393.2312
I have setup the build and release task setup at https://rathirad.visualstudio.com/HelloWorldPowershell/
Please let me know if you would like to have a look.

Problem Description
------------------
If you are using the `using module` statement, it will load the module without any issues. However, if you make a change to the module and run the `using module` statement again without restarting your PowerShell session, it will not load the new modified module into memory, and instead will continue to use the old existing module that was loaded. This makes doing development with `using module` statements very tedious as you must continually reload your PowerShell session whenever you make changes to the module.

Ideally we would just use `Import-Module -Name [module name] -Force` to avoid this issue, but that does not work for importing `class`es, so the `using module` statement **must** be used.

Steps to reproduce
------------------
Create the following module and script files:

In `TestModule.psm1`:
```powershell
class TestClass
{
[string] $ClassPropertyText = "Initial text"
}

function Get-ModuleFunctionText()
{
return "Initial text"
}

Export-ModuleMember -Function Get-ModuleFunctionText
```

In `Test.ps1`:
```powershell
using module '.\TestModule.psm1'

$instance = [TestClass]::new()
$instance.ClassPropertyText

Get-ModuleFunctionText
```

Run `Test.ps1` and it will output:
```
Initial text
Initial text
```

Then modify `TestModule.psm1` to:
```powershell
class TestClass
{
[string] $ClassPropertyText = "Updated text"
}

function Get-ModuleFunctionText()
{
return "Updated text"
}

Export-ModuleMember -Function Get-ModuleFunctionText
```

Run `Test.ps1` again and it will still output:
```
Initial text
Initial text
```

Expected behavior
-----------------
When running `Test.ps1` the 2nd time, it should output:
```none
Updated text
Updated text
```

Environment data
----------------

<!-- provide the output of $PSVersionTable -->

```powershell
> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.17134.228
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17134.228
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
```

Additional Info
----------------
The problem can be somewhat reduced by using _both_ the `using module` statement and `Import-Module -Force` statement, like this:
```powershell
using module '.\TestModule.psm1'
Import-Module -Name '.\TestModule.psm1' -Force

$instance = [TestClass]::new()
$instance.ClassPropertyText

Get-ModuleFunctionText
```

This code would result in the following output:
```
Initial text
Updated text
```

So here the module code was updated, but the `class` code was not.

Proposed Solution
----------------
To fix this issue I propose adding a `-Force` flag to the `using module` statement that forces the module to be reloaded into memory; the same way that the `-Force` flag works for the `Import-Module` cmdlet. This will allow developing code that uses the `class` construct to work much smoother.

I also proposed this same change to PowerShell Core at: https://github.com/PowerShell/PowerShell/issues/7654