Sign in
 
HomeWindows Server “8” Beta20082003LibraryForums
Windows Server TechCenter > Windows Server Forums > Windows PowerShell > GWMI, asjob, and firewalls

Answered GWMI, asjob, and firewalls

    •  
      Friday, March 05, 2010 4:42 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      I've been running into a problem recently as I'm improving some old VBScripts by converting them to Powershell.  I've broken down my main problem into this simple example.  If I run:


      gwmi win32_computersystem -computername machinename1

      I get a proper answer.  However, if I run:

      gwmi win32_computersystem -computername machinename1 -asjob

      it invariably fails with the "The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)".  I have narrowed it down to a local firewall problem, such that if I turn off my local machine's firewall (remote machines do not have a firewall) it works fine.  I'd rather keep my local firewall active, and I'll need to run commands similar to this quite frequently.  I write and test scripts from Win7 (and powershell is being run as admin), but they'll typically run from an WinXP workstation (which has been tested to have the same outgoing firewall issue). 

      My questions are:

      • Why is the interactive command and the -asjob command treated differently by my local firewall?  (are there any other commands besides gwmi that behave differently "asjob"?)

      • What explicitly should I allow on the firewall to let this command run (for Win7 and WinXP)?  I've played around with a few of the rules but firewalls are not my specialty and all I seem to be able to do is slow down the failure.  I'm most confused because both machines running scripts are set to allow outgoing connections by default, yet obviously something is being blocked.


      Thanks!
      -B

       

    Answers

    • Monday, March 08, 2010 12:27 PM
       
       Answered
      Sign In to Vote
      1
      Sign In to Vote
      "On the local computer, add the client application to the Windows Firewall Exceptions list so that the reverse connection can be completed.

      The client application is frequently the Unsecapp.exe application.       The Unsecapp.exe application is used to send results back to a client in a process that may not have permissions to be a DCOM service. Both scripting and the Microsoft .NET System.Management namespace rely on the Unsecapp.exe application to receive the results of asynchronous operations."

      Path to Unsecapp.exe application is c:\Windows\System32\wbem\unsecapp.exe.

      I've done the following on my local computer (Win XP SP3 with enabled Windows Firewall):

      1. First I've changed local group policy to allow remote administration exception
      1. Click Start, click Run, type gpedit.msc, and then click OK.
      2. Under Console Root, expand Computer Configuration, expand Administrative Templates, expand Network, expand Network Connections, expand Windows Firewall, and then click Domain Profile.
      3. Right-click Windows Firewall: Allow remote administration exception, and then click Properties.
      4. Click Enabled, and then click OK
      2. Then I've executed gwmi win32_computersystem -comp server01 -asjob and the window popup with the option to unblock access to WMI.

      You can do that manually and add unsecapp.exe application (c:\Windows\System32\wbem\unsecapp.exe) to the Windows Firewall Exceptions list.

      HTH,
      Aleksandar


      Aleksandar Nikolić http://powershellers.blogspot.com http://twitter.com/alexandair
       

    All Replies

    • Friday, March 05, 2010 5:48 PM
      Moderator
       
       
      Sign In to Vote
      0
      Sign In to Vote
      Very odd, the only difference I can think of (without looking), is to whether a different process is invoked when doing the remoting.

      I'll only be able to look into this next week...

      You're developing on Win7 (and run on XP), but what do you typically connect to?  Just curious...
       
    • Friday, March 05, 2010 7:27 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Our terminals are all WinXP right now.  This is the main reason my script runner is XP, too.  I find it easier to manage our machines using the same OS.

      No worries on the timing, I'm working just fine with my firewall down.  I'm happy to have someone else befuddled, too. :)

      Yeah, next up on my confusing questions is why my simple query takes for ever and eventually crashes my machine when in powershell...  but the one I hobbled together faking multithreading in VBS runs great and queries all 6500 machines in exactly 9 minutes...

      but I'll save that for a different thread.

       
    • Sunday, March 07, 2010 6:26 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      -asjob runs command on remote machine evenif objects are on localhost, hence firewall plays a major role while running commands with -asjob

      Enable RPC related rules for incoming RPC calls.

      Keep us posted ...:)
      Vishal Jain, MSFT
       
    • Monday, March 08, 2010 12:27 PM
       
       Answered
      Sign In to Vote
      1
      Sign In to Vote
      "On the local computer, add the client application to the Windows Firewall Exceptions list so that the reverse connection can be completed.

      The client application is frequently the Unsecapp.exe application.       The Unsecapp.exe application is used to send results back to a client in a process that may not have permissions to be a DCOM service. Both scripting and the Microsoft .NET System.Management namespace rely on the Unsecapp.exe application to receive the results of asynchronous operations."

      Path to Unsecapp.exe application is c:\Windows\System32\wbem\unsecapp.exe.

      I've done the following on my local computer (Win XP SP3 with enabled Windows Firewall):

      1. First I've changed local group policy to allow remote administration exception
      1. Click Start, click Run, type gpedit.msc, and then click OK.
      2. Under Console Root, expand Computer Configuration, expand Administrative Templates, expand Network, expand Network Connections, expand Windows Firewall, and then click Domain Profile.
      3. Right-click Windows Firewall: Allow remote administration exception, and then click Properties.
      4. Click Enabled, and then click OK
      2. Then I've executed gwmi win32_computersystem -comp server01 -asjob and the window popup with the option to unblock access to WMI.

      You can do that manually and add unsecapp.exe application (c:\Windows\System32\wbem\unsecapp.exe) to the Windows Firewall Exceptions list.

      HTH,
      Aleksandar


      Aleksandar Nikolić http://powershellers.blogspot.com http://twitter.com/alexandair
       
    • Tuesday, March 09, 2010 7:27 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      > Why is the interactive command and the -asjob command treated differently by my local firewall?

      When you run command against local computer, communication accurs through loopback network adapter that usually cannot be protected by firewalls.

      > What explicitly should I allow on the firewall to let this command run (for Win7 and WinXP)?

      Windows Remote Managment (in Windows Firewall) or something like this in other firewalls.
      http://www.sysadmins.lv
       
    • Tuesday, March 09, 2010 12:53 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Vadims,


      You don't need Windows Remote Managment firewall exception to run the following command:

      gwmi win32_computersystem -comp server01 -asjob



      Aleksandar Nikolić http://powershellers.blogspot.com http://twitter.com/alexandair
       
    • Wednesday, March 10, 2010 5:39 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Nice Job Aleksandar,

      Might I ask where from where that quote comes?  I think I'd like to read the rest of it. 

      I had to go with direct firewall edits, allowing unsecapp.exe inbound access.  The policy edits didn't seem to do anything for me, and the machines I run from where I run these scripts are not covered by domain policy very much.  

      There were some other oddities

      • For the WinXP Sp3 machine, the WMI exception was already there, and thus the -asjob was working fine this time around.  After playing with it a bit, I found that any changes to either this machine or my Win7 machine did not seem to actually start working until after a logout/login, which I find odd. In fact, on both machines, I could get them working with the right settings and a reboot. I could then block access easily. Re-allowing access always required work, and the more I played with it without reboot/relogin, the longer gwmi calls would take to fail. Eventually, calls from the Win7 machine would simply never finish. Reboot, and it all works.
      • The WinXP machine would work with allowing WMI via the alert pop-up, or explicitly allowing unsecapp. However, if I choose to Ask Me Later or Keep Blocking when the pop up occurred, it would actually never ask again later until a reboot.
      • Win7 never had a pop up, but began working with the pre-defined inbound rule: Windows Management Instrumentation (ASync-In). The WMI-In, and DCOM-In, had no noticable effect. I note this in case anyone one else out there just wants to use the predefined rules.

      So thank you very much, it all seems well now.  Any clues as to what could change the rules on the fly would be nice, such as restarting a service or two.  I've tried a variety of services such as WMI or Firewall, but never works.  I'm fine with reboots if that's what's necessary, it's not like this changes often. 

      Thanks big time!
      -B

       
    • Thursday, March 11, 2010 12:31 AM
       
       
      Sign In to Vote
      1
      Sign In to Vote
      The quote comes from "How to troubleshoot WMI-related issues in Windows XP SP2" article (link).

      I've experienced the same oddities. The only thing that I've done differently is that instead of rebooting, I've just turned firewall off for a second, and then on. After that, changes were accepted and everything worked as I wanted.


      Aleksandar Nikolić http://powershellers.blogspot.com http://twitter.com/alexandair