none
Read Proxy settings: SCCM vs PSEXEC RRS feed

  • Question

  • Hello All,

    SCCM 2012 SP1 R2


    I wish to read and dump the proxy settings for the System account to a log file via an SCCM deployment.

    All machines are Win7 Pro x64

    We assume no user is logged on to the machines

    Using psexec, the following works well remotely

                    - psexec -s \\RemotePC cmd

                    - netsh winhttp show proxy

                                    Current WinHTTP proxy settings:

                                    Proxy Server(s) :  test.cmx:8080

                            Bypass List     :  (none)

    The above is the expected output.

    I now want to dump the above from an SCCM deployment to c:\windows\temp\pr1.txt

                    - program created with run as admin

                    - Created a .vbs file with:

                                    WshShell.run("cmd /c netsh winhttp show proxy >> c:\windows\temp\pr1.txt", 1, true)

                   

                    But this logs to pr1.txt as :

                                    Current WinHTTP proxy settings:

                                    Direct access (no proxy server).

                                   

                    whoami = nt authority\system

                    I expected the 32/64 bit redirection to be causing an issue.

                    But all the following combinations of system32 and syswow64 produce the same output

    ====================================

    tmp = WshShell.run("cmd /c whoami >> c:\windows\temp\pr1.txt", 1, true)

    tmp = WshShell.run("c:\windows\system32\cmd /c c:\windows\system32\netsh winhttp show proxy >> c:\windows\temp\pr1.txt", 1, true)

    tmp = WshShell.run("c:\windows\system32\cmd /c c:\windows\syswow64\netsh winhttp show proxy >> c:\windows\temp\pr1.txt", 1, true)

    tmp = WshShell.run("c:\windows\syswow64\cmd /c c:\windows\system32\netsh winhttp show proxy >> c:\windows\temp\pr1.txt", 1, true)

    tmp = WshShell.run("c:\windows\syswow64\cmd /c c:\windows\syswow64\netsh winhttp show proxy >> c:\windows\temp\pr1.txt", 1, true)

    --------------

    OUTPUT

    --------------

    nt authority\system

    Current WinHTTP proxy settings:

        Direct access (no proxy server).

    Current WinHTTP proxy settings:

        Direct access (no proxy server).

    Current WinHTTP proxy settings:

        Direct access (no proxy server).

    Current WinHTTP proxy settings:

        Direct access (no proxy server).

    =====================================

    Could someone please assist in getting the SCCM client to write the Proxy (as with psexec) to the file? Thanks.

    Friday, August 16, 2019 1:59 AM

Answers

  • sysnative is a special alias that directs 32-bit processes running on a 64-bit OS to %windir%\system32. It's not valid from 32-bit OSes or 64-bit processes. See https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector.

    Also, running reg.exe (or any process that reads the registry) from a 32-bit processes and trying to access HKLM\Software will be silently redirected to HKLM\Software\Wow6432Node. Info on that at https://docs.microsoft.com/en-us/windows/win32/winprog64/registry-redirector.

    You can avoid this by using /reg:64 switch to reg.exe.

    Packages/programs in ConfigMgr run as 32-bit processes so these you must always account for these redirections.

    Also, assuming that "ping localhost -n 10 >nul" is meant for a pause in the batch file execution, a much better method is to use the timeout command.

    None of this gets you/us any closer specifically to being able to explain what you are seeing with netsh though (at least I don't think it does).


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by sccm72 Monday, August 19, 2019 11:21 AM
    Saturday, August 17, 2019 12:16 AM

All replies

  • Why are you using a VBScript to run an .exe? A simple batch file or just the netsh.exe command-line itself is totally sufficient (no cmd /c neede either as netsh is an .exe). What you have above is a VBScript, launching a command shell that in turn launches an .exe. That's three layers of indirection.

    32-bit vs. 64 bit shouldn't be an issue for netsh as the proxy configuration is not architecture specific to my knowledge. Just to validate though, you can try the following as the program command-line (no VBScript needed):

    %windir%\sysnative\netsh.exe winhttp show proxy >> %windir%\temp\pr2.txt


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, August 16, 2019 2:30 AM
  • Hello,
     
    Is the "show proxy"  only section in your VBScipt? I tested to use VBScript to report proxy information and get the expected results. I did not deploy the VBScript as a program but run it locally under system context. Have you tried to run your script locally and check the results? Here is the script I used.
     
    Option Explicit
    
    Dim WshShell
    
    Set WshShell = WScript.CreateObject("WScript.Shell")
    
    WshShell.run "cmd /c netsh winhttp show proxy >> c:\pr1.txt", 1, true
     
    Hope my answer could help you and look forward to your feedback. 

    Best Regards,
    Ray

    Please remembers to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Friday, August 16, 2019 6:45 AM
  • Yes Ray, Its all good using psexec or from command prompt. The same script does not work by SCCM
    Friday, August 16, 2019 11:20 PM
  • Hello Jason,

    Thanks - I finally have some result, though some more confusions. Sorry, due to lack of time I am not being able to test enough myself.

    As suggested, I removed vbs and replaced with batch file

    =======================================

    echo %date% %time% >> c:\windows\temp\batch1.txt

    whoami >> c:\windows\temp\batch1.txt
    wmic os get name >> c:\windows\temp\batch1.txt
    wmic os get osarchitecture >> c:\windows\temp\batch1.txt


    c:\windows\system32\netsh winhttp show proxy >> c:\windows\temp\batch1.txt
    ping localhost -n 10 >nul
    c:\windows\syswow64\netsh winhttp show proxy >> c:\windows\temp\batch1.txt
    ping localhost -n 10 >nul


    c:\windows\system32\reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections" >> c:\windows\temp\batch1.txt
    ping localhost -n 10 >nul
    c:\windows\syswow64\reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections" >> c:\windows\temp\batch1.txt
    ping localhost -n 10 >nul



    %windir%\sysnative\netsh.exe winhttp show proxy >> %windir%\temp\batch1.txt

    echo ENDING >> %windir%\temp\batch1.txt

    ===================================

    Running the above remotely using psexec -s \\RemotePC cmd gives the excepted but the sysnative does not print at all

    Fri 08/16/2019 18:24:34.52 
    nt authority\system
    N a m e                                                                                                                                               
     
     M i c r o s o f t   W i n d o w s   7   P r o f e s s i o n a l   | C : \ W I N D O W S | \ D e v i c e \ H a r d d i s k 0 \ P a r t i t i o n 1     
     
     O S A r c h i t e c t u r e     
     
     6 4 - b i t                     
     
     
    Current WinHTTP proxy settings:

        Proxy Server(s) :  test.cmx:8080
        Bypass List     :  (none)


    Current WinHTTP proxy settings:

        Direct access (no proxy server).


    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
        WinHttpSettings    REG_BINARY    2800000000000000030000000D000000746573742E636D783A3830383000000000


    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
        WinHttpSettings    REG_BINARY    1800000000000000010000000000000000000000

    ENDING 

    ====================================

    Running from SCCM, sysnative works fine, the rest does not

    Fri 08/16/2019 18:13:36.62 
    nt authority\system
    N a m e                                                                                                                                               
     
     M i c r o s o f t   W i n d o w s   7   P r o f e s s i o n a l   | C : \ W I N D O W S | \ D e v i c e \ H a r d d i s k 0 \ P a r t i t i o n 1     
     
     O S A r c h i t e c t u r e     
     
     6 4 - b i t                     
     
     
    Current WinHTTP proxy settings:

        Direct access (no proxy server).


    Current WinHTTP proxy settings:

        Direct access (no proxy server).


    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
        WinHttpSettings    REG_BINARY    1800000000000000010000000000000000000000


    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
        WinHttpSettings    REG_BINARY    1800000000000000010000000000000000000000


    Current WinHTTP proxy settings:

        Proxy Server(s) :  test.cmx:8080
        Bypass List     :  (none)

    ENDING

    =============================

    Just FYI: from the command prompt, the following gives and error. Just how did it work from SCCM?

    C:\>%windir%\sysnative\netsh.exe winhttp show proxy

    The system cannot find the path specified.

    Friday, August 16, 2019 11:33 PM
  • sysnative is a special alias that directs 32-bit processes running on a 64-bit OS to %windir%\system32. It's not valid from 32-bit OSes or 64-bit processes. See https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector.

    Also, running reg.exe (or any process that reads the registry) from a 32-bit processes and trying to access HKLM\Software will be silently redirected to HKLM\Software\Wow6432Node. Info on that at https://docs.microsoft.com/en-us/windows/win32/winprog64/registry-redirector.

    You can avoid this by using /reg:64 switch to reg.exe.

    Packages/programs in ConfigMgr run as 32-bit processes so these you must always account for these redirections.

    Also, assuming that "ping localhost -n 10 >nul" is meant for a pause in the batch file execution, a much better method is to use the timeout command.

    None of this gets you/us any closer specifically to being able to explain what you are seeing with netsh though (at least I don't think it does).


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by sccm72 Monday, August 19, 2019 11:21 AM
    Saturday, August 17, 2019 12:16 AM
  • Hello Jason, I spent some time over the weekend to learn this new concept. By creating a hung netsh process via SCCM (netsh without params), I could see via Process Explorer that it was indeed running netsh as 32-bit syswow\netsh even though the command line was system32\netsh

    With this knowledge, I could solve the underlying issue. 

    Thanks a lot for your help

    (p.s. this pitfall is so subtle that I am sure to fall into it again in future)

    Monday, August 19, 2019 11:21 AM
  • I'm quite surprised that there are separate proxy settings for 32-bit and 64-bit. I would have thought Windows would keep these in sync or have a single source of configuration for this, but I guess not.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, August 20, 2019 12:54 PM