Set-DscLocalConfigurationManager and Proxy awareness

Hi All,
I’ve been messing around with trying to get “Set-DscLocalConfigurationManager” to play nice behind a proxy server. My conclusion up until now it that this cmdlet is not proxy aware, but wanted to reach out to this community to see if anyone else ever got this to work?

Here’s my test setup:

    Member1: Windows 2016 Member server DC01: Windows 2016 DC, DNS Edge01: Proxy server, DNS, (Optional NAT)

Member1 is the server that needs to get the DSC configuration. Member1 has proxy configuration set in IE and configured with “Netsh winhttp”. I verified that Internet connectivity works using IE, running Windows update and “Invoke-WebRequest”. When running “Set-DscLocalConfigurationManager” it fails in this setup with the error message:

“Registration of the Dsc Agent with the server failed. The underlying error is: Failed to register Dsc Agent with AgentId 29A9E37B-1D35-11E8-9669-00155D7CD013 with the server‘29A9E37B-1D35-11E8-9669-00155D7CD013’)”

  • I replaced the guid with (GUID)

When I use the same setup and place this machine outside of the network so that it can directly connect to Azure, or enable NAT on the proxy the registration succeeds immediately, hence my conclusion that the cmdlet is not proxy aware.

Anyone have any ideas? Is there a way to tell PowerShell in general or this specific cmdlet, “Use this proxy”?

Those communications are currently CIM running over WS-MAN, so the operating system’s underlying proxy awareness doesn’t come into play.

Have you looked at ?

Hi Don,

Well, that confirms my suspicion. I did some network traces and the connection does not even try to use the proxy as you mentioned. That’s a bit unfortunate because I could not find that requirement on the Azure DCS doc pages anywhere. I’ll take a look at the blog you suggested!

Just to be clear, before I go down this route, can this be made to work with a proxy, or is it a big no, no?

It should, yeah.

Hope is good :slight_smile:

So what I got until now is this

$CIMSessionOption = New-CimSessionOption -ProxyType InternetExplorer
$Session = New-CimSession -SessionOption $CIMSessionOption

But that gives an error:

“New-CimSession : The WinRM client cannot process the request. Setting proxy information is not valid when the HTTP transport is specified. Remove the proxy information or change the transport and try the request again.”

Can you give a hint on how to change the transport? I’ve tried -Usessl but that doens’t seem to work either.

Yeah, that was described in that article I linked. You can’t use a proxy over HTTP. So the remote end needs to have an HTTPS listener, and you do need to specify -UseSSL. It’s all in “Secrets of PowerShell Remoting,” since Remoting also uses WS-MAN under the hood. The HTTPS listener will need a trusted (not self-signed) SSL certificate.

Hmmm so since this is Azure DSC related, I guess that’s a no go, or is there a way to let Azure play nice on this?

No, Azure offers an HTTPS endpoint. But you’d need to either find that in your account or contact their support if it’s not obvious. It might need to be explicitly set up, for example. I’m not a huge Azure expert.

Well I’ve got a premier support case running at the moment, I’ll promise to let you know once they have provided me with an answer. Perhaps I’ll even create a blog post around it.

I’ll start digging in the secrets book you mentioned. Just so I can get this local thing up and running.

ps: bought your “The DCS Book”, Forever edition a couple of weeks ago. Good stuff, got me up and running really quick. Thanks for publishing that!

The issue here is that LCM itself is not proxy aware. We are working on this but don’t have a firm ETA as of yet. Until then the only other option would be to allow traffic to the Azure datacenter IP whitelist.

Hi Michael,

Thanks for the clarification, appreciate the openness. I will add the information you provided in the design and send the information back to the premier support folks at Microsoft. For the time being, where the situation arises where the IP address cannot be whitelisted we could always just use runbooks to update and manage the LCM locally, instead of having a Azure pull server.
PS, Would it be okay if I mentioned your statement in the case?

Yes, anything that I can do to help. They can add me to the case Email, etc. No worries.

Cool, thanks! Will add your name to the case.

As recommended by the case engineer I’ve added an entry into uservoice.

A potential (dirty) workaround for this is to use WCCP to force traffic through your proxy even for non proxy-aware systems like the LCM.

It’s worth checking whether you can do this if needed, although I’d avoid it as much as possible.

Here’s a link with a nice technical description of the concepts and an implementation (but not tested with DSC):

I can understand the “dirty” part behind it. Problem I’m facing is that it would have to run on our medical device, meaning that ever additional piece of software would have to be verified before release. Powershell has already undergone such a rigorous validation. Hopefully with the uservoice entry it will be changed in the near future. I would still have the direct connect option to azure available, but that implies having different conversations with my customers.

Just to avoid confusion, WCCP is at the network level so no config required on the node itself, so not on medical device.
But I get what you mean.
I would not bet on ‘the near future’ though, although it may depend on what you have in mind.

I ran into this issue myself there connecting my sandbox servers to Azure due to a requirement by the security team. There is a workaround, Set up the internet explorer proxy on the local system account. You will need to setup the proxy I use the following code and reg files to setup my proxy with psexec.exe which can execute as local system which might be frowned on by your security team.

$regkey = @'
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections]
"DefaultConnectionSettings"=EXPORT YOUR OWN PROXY SETTINGS to a reg file after setting up your proxy on your user account!.

$ProxyKeys = @'
@echo off
reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t reg_dword /d 00000001 /f
reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer /t reg_sz /d "" /f
regedit /s c:\source\proxy\proxy.reg
powershell.exe -file c:\source\proxy\proxy.ps1
exit 0

#force the proxy settings to reload so we can avoid a reboot
$proxyRefresh = @'
function refresh-system() {
$signature = @"
[DllImport("wininet.dll", SetLastError = true, CharSet=CharSet.Auto)]
public static extern bool InternetSetOption(IntPtr hInternet, int dwOption, IntPtr lpBuffer, int dwBufferLength);

    $INTERNET_OPTION_REFRESH            = 37
    $type = Add-Type -MemberDefinition $signature -Name wininet -Namespace pinvoke -PassThru
    $a = $type::InternetSetOption(0, $INTERNET_OPTION_SETTINGS_CHANGED, 0, 0)
    $b = $type::InternetSetOption(0, $INTERNET_OPTION_REFRESH, 0, 0)
    return $a -and $b

new-item -path c:\source\proxy -type Directory -force
$proxyrefresh | Out-file -filepath c:\source\proxy\proxy.ps1 -Encoding ASCII 
$proxyKeys | Out-file -filepath c:\source\proxy\proxy.bat -Encoding ASCII
$regkey | Out-File -filepath c:\source\proxy\proxy.reg -Encoding ASCII
#psexec.exe -accepteula -s cmd.exe "/c c:\source\proxy\proxy.bat"

$Process = Start-Process -FilePath psexec.exe -ArgumentList "-accepteula -s cmd.exe /c c:\source\proxy\proxy.bat" -Wait -PassThru -NoNewWindow -Verbose
Write-Output "ExitCode: $($Process.ExitCode)"
If ($Process.ExitCode -ne 0) {
    Throw "Proxy setup failed"
    exit 1

Open IExplorer with PSexec.exe and configure the proxy
This way you can setup the proxy as well

Also, your security team can review the datacenter IP ranges for Azure and approve that as a whitelist for network traffic, whether that apply to routes in general for encrypted traffic or traffic to/from your SSL/TLS forward proxy, rather than allowing traffic openly to the Internet.