Problems running netsh

Content Authoring
1

(imported topic written by menke123491)

I’m trying to deploy a fixlet to run netsh to re-configure WINS addresses. I’m running into, what I’m guessing is, a permission problem.

I’ve tried creating a batch file where each netsh command is run separately, e.g. “netsh int ip set wins…”, “netsh int ip add wins…”, etc. I’ve tried creating a netsh script and invoking it via “netsh -f scriptname.txt”. I’ve ran both scripts under the System account (via both “at” and using psexec) - and they work fine.

However, when deployed through the fixlet, they don’t work completely. For example, before running the script, I have WINS servers 1.1.1.1 and 2.2.2.2. The batch file invoked through the fixlet changes the WINS servers to 3.3.3.3 and 4.4.4.4-

netsh int ip set wins name=“Local Area Connection” source=static addr=3.3.3.3

netsh int ip add wins name=“Local Area Connection” addr=4.4.4.4

After running the fixlet, “ipconfig /all” continues to report 1.1.1.1 and 2.2.2.2 and I continue to see WINS traffic to those two addresses. Interestingly, “netsh int ip show wins”, the registry, and the gui interface properties show the new addresses - 3.3.3.3 and 4.4.4.4. It’s like the command makes the changes, but can’t quite commit them.

I’d think it was a netsh issue, but again, it works fine - run under the System account - outside of Bigfix. Are there any other restrictions on running commands through the BES client?

2

(imported comment written by BenKus)

Hey Menke,

That is very interesting… When the agent does a shell-execute, it is does so in the same way as any other process… There should be no distinction between a command run as the system account a command run by the BigFix Agent… But one thing that might be different is the environment of the cmd shell… using

waithidden netsh …

is different from

waithidden cmd.exe /C netsh …

Also note that the cmd shell is restarted for every line of the action so maybe there is some effect of that on your commands…

Are you using the “cmd shell”? Are you using the “wait” or “run” command? Can you post your actionscript in its entirety?

Ben

3

(imported comment written by menke123491)

Ben,

Following is an actionscript that exhibits the behavior. (Hosts are Win2k3 64-bit, sp2)-

createfile until ENDCREATE

@echo off

date /t > c:\temp\update_wins.log

echo %username% >> c:\temp\update_wins.log

ipconfig /all >> c:\temp\update_wins.log

netsh int ip show wins >> c:\temp\update_wins.log

echo ************************* >> c:\temp\update_wins.log

netsh int ip set wins name=“Local Area Connection 5” source=static addr=3.3.3.3 >> c:\temp\update_wins.log

netsh int ip add wins name=“Local Area Connection 5” addr=4.4.4.4 >> c:\temp\update_wins.log

echo ************************* >> c:\temp\update_wins.log

ipconfig /all >> c:\temp\update_wins.log

netsh int ip show wins >> c:\temp\update_wins.log

ENDCREATE

delete update_wins.bat

copy __createfile update_wins.bat

wait update_wins.bat

I’ve attached the resultant log file (only change was to substitute prod host and dns addresses). Notice the discrepancy between the the “netsh int ip show wins” output and the “ipconfig /all” output. It’s more than cosmetic, however. I’ve verified we’re still seeing WINS traffic to the old addresses after the actionscript is run.

4

(imported comment written by menke123491)

One more curious thing. When running the batch file with normal user credentials (admin) or as System (either through “at” or psexec), the stdout of each netsh commands is “Ok.” We see two "Ok."s between the asterisk lines in the log file. However, when run through Bigfix, we’re not seeing any stdout.

5

(imported comment written by BenKus)

What if you changed the last line to:

wait cmd.exe /C update_wins.bat

Does that change anything?

Ben

6

(imported comment written by menke123491)

Nope. Same result.

7

(imported comment written by BenKus)

That is baffling… Just to see what happens, try using RunAsCurrentUser with an admin logged in and see if that works (http://support.bigfix.com/cgi-bin/kbdirect.pl?id=392)

Ben

8

(imported comment written by menke123491)

I was able to determine what the problem is, but I still need help on the resolution. The problem is that the BESClient is launching the 32-bit version of netsh (c:\windows\syswow64\netsh.exe) instead of the 64-bit version of netsh (c:\windows\system32\netsh.exe). I was able to reproduce the problem (using both local Admin account and System) by explicitly calling the 32-bit version of netsh. (fyi - I used Process Monitor from sysinternals to determine it was the 32-bit version running each time. It also reported an exit code 1, while the 64-bit version reported an exit code 0.)

The problem is how do I explicitly call the 64-bit version of netsh from the action script? No matter what I’ve tried, the 32-bit version gets used. I’ve tried the following-

  1. explicitly setting the path of netsh in the batch file

  2. setting the PROCESSOR_ARCHITECTURE environment variable to “AMD64” (it was “x86”)

  3. explicitly setting the path of ‘cmd’, which then calls the batch file, i.e.

wait c:\windows\system32\cmd.exe /C update_wins.bat

  1. all of the above

This is my action script currently-

createfile until ENDCREATE

@echo off

date /t > c:\temp\update_wins.log

SET PROCESSOR_ARCHITECTURE=AMD64

echo %username% >> c:\temp\update_wins.log

set >> c:\temp\update_wins.log

ipconfig /all >> c:\temp\update_wins.log

C:\WINDOWS\system32\netsh.exe int ip show wins >> c:\temp\update_wins.log

echo ************************* >> c:\temp\update_wins.log

C:\WINDOWS\system32\netsh.exe int ip set wins name=“Local Area Connection 5” source=static addr=3.3.3.3 >> c:\temp\update_wins.log

C:\WINDOWS\system32\netsh.exe int ip add wins name=“Local Area Connection 5” addr=4.4.4.4 >> c:\temp\update_wins.log

echo ************************* >> c:\temp\update_wins.log

ipconfig /all >> c:\temp\update_wins.log

C:\WINDOWS\system32\netsh.exe int ip show wins >> c:\temp\update_wins.log

ENDCREATE

delete update_wins.bat

copy __createfile update_wins.bat

wait c:\windows\system32\cmd.exe /C update_wins.bat

Any other ideas?

9

(imported comment written by BenKus)

Aha!

Good catch… You will need to tell the agent to use the “wow64redirection”, which is documented here: http://support.bigfix.com/fixlet/documents/WinActions-2007-09-08.pdf (page 56)

From the doc:

This command allows the client to get outside of the 32-bit world created for it by the Windows On Windows64 (Wow64) facility built into the new 64-bit versions of the Windows operating system, including Windows 2003 x64 and Windows XP Pro x64.

When this command is executed in an action on a 64-bit OS with a value of true, the client enables Wow64 redirection in any subsequent commands that involve filenames. This state continues until the action completes or the client executes the action uses wow64 redirection false command.

You can use Relevance substitution to supply the <true|false> value. The file system redirection provided by Wow64 is disabled using the Wow64DisableWow64FsRedirection and re-enabled using the Wow64RevertWow64FsRedirection Windows API.

The commands affected by this setting include:

dos, run, wait, rundetached, waitdetached, runhidden, waithidden, delete, copy, move, open

action uses wow64 redirection <true|false>

So to fix this issue, put this line at the top of your action:

action uses wow64 redirection {x64 of operating system}

This will make your action work on either 32-bit or 64-bit OSes (because it will return True on x64 and False on 32-bit).

Ben

10

(imported comment written by menke123491)

Thanks Ben. That did the trick. However, it’s really “action uses wow64 redirection {not x64 of operating system}”, right? Since you want to turn off redirection for 64-bit clients. In any event, that’s what worked for me.