Jump to content

MEP will not push to new Win 10 computers


Recommended Posts

I have some new Win 10 computers on my network, out of the box, no 3rd-party antivirus/firewall products.  I get two different errors depending on whether WMI is checked or not:

Installation failed.  Access is denied.  Failed to create remote service. (winthout WMI)
Installation failed.  The RPC server is unavailable (enable WMI)

I confirmed the .NET 3.5 role is enabled.  WMI service is running on the computer.  All my Win 7 clients pushed out without issue.  The new Win 10 computers are on a Small Business Server 2011 network.  Group Policy prevents the firewall from being disabled.

Thanks for any assistance.  

Link to post
Share on other sites

Hi @r042wal, RPC failure on the machine means that the WMI needs to be opened on the machine. You may experience this problem, even with the firewall off, depending on the permissions settings of a target endpoint.

RPC server is unavailable. Please allow WMI through Windows Firewall.

If this occurs, open a command line window on the endpoint (as an administrator) and enter the following:

Old command
netsh firewall set service RemoteAdmin enable

New commands
netsh advfirewall firewall set rule group="remote administration" new enable=yes
netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes
netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

Link to post
Share on other sites

I applied the rules (see below) and still receive both errors depending on whether I check WMI off or not:

 

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\Windows\system32>netsh firewall set service RemoteAdmin enable

IMPORTANT: Command executed successfully.
However, "netsh firewall" is deprecated;
use "netsh advfirewall firewall" instead.
For more information on using "netsh advfirewall firewall" commands
instead of "netsh firewall", see KB article 947709
at https://go.microsoft.com/fwlink/?linkid=121488 .

Ok.


C:\Windows\system32>netsh advfirewall firewall set rule group="remote administration" new enable=yes

Updated 3 rule(s).
Ok.


C:\Windows\system32>netsh advfirewall firewall set rule group="Windows Remote Management" new enable=yes

Updated 2 rule(s).
Ok.


C:\Windows\system32>netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

Updated 8 rule(s).
Ok.


C:\Windows\system32>

Link to post
Share on other sites

18457 is for communication after install, not the actual install. Install uses netbios; 135, 137, 138 and 139. You likely have a much more locked down environment than the client push utility is going to be able to work with, I would suggest that you make an offline installer package in policy \ installation pacakge and deploy that through some other means like GPO, SCCM or PDQ deploy.

Link to post
Share on other sites

No that's not the case.  I have 26 Windows 7 clients and 4 servers and they all worked fine pushing.  I have not done anything out of the ordinary.  As I said this appears to be something specific to Windows 10 and if I can't manage them through the policy on the server, why bother.  Maybe if you can't figure it out I will go back to my sales rep and have them escalate it.  I can't afford to have problems with Win 10 computers right out of the box going forward.

Link to post
Share on other sites

You are assuming that I am not able to figure this out but what I am really doing is trying to save you time. Time from troubleshooting and the back and forth. The offline installer is extremely effective and a simple workaround when you only have a small population of machines left to deploy, especially since NetBIOS has been purposely deprecated by Microsoft and is locked down on newer operating systems. It is up you to make sure all of your systems conform to the prerequisites listed in your documentation.

 

NetBIOS must be enabled, TCP port 137 must be open. Since you are using GPO to control your firewall, use the following to allow the connections:

GPO or Firewall Rules -> Add Predefined -> WMI

59a88b0b63705_wmi1.JPG.db9d2fc99b58c5337e47d0321732162e.JPG59a88b0d635ad_wmi2.JPG.3b89d4157af8d42a71b4f519473bb36c.JPG

 

GPO or Firewall Rules -> Add Predefined -> File and Print Sharing
59a88b1060c4e_fileandprintsharing1.JPG.770c3bdeac77e10d34ba5b0eaabaffe9.JPG59a88b12bc781_fileandprintsharing2.JPG.13a1018934ad7e656bc34c853284fc73.JPG

 

Link to post
Share on other sites

I already had the WMI rules.  I had a GPO for that but I also added it manually to the Win 10 computer as well ass the File and Printer Sharing inbound rules.  It still didn't work:

192.168.0.43    Installation failed. Access is denied. Failed to create remote service.            
8/30/2017 2:38:21 PM

192.168.0.43    Installation failed. The RPC server is unavailable. Please allow WMI through
Windows Firewall.            8/30/2017 2:38:21 PM

I made an install package.  I'm not too impressed that all this worked had to be put into a computer just because it is Win 10.  I'm sure I won't be the last to complain.  Thanks for your help.

Link to post
Share on other sites

I know your frustration. It used to not be this way, it worked as is out of the box up pretty great until about July 2016 when Microsoft started locking down NetBIOS. That campaign culminated in April 2017, and it basically crippled our push tool. We are also not the only vendor to suffer for that. But lesson learned. Our new cloud product now has several alternatives that it will go through for push installs rather than just WMI and NetBT.

If you still want to dive deeper, we can do that Wireshark capture so you'll know exactly what to turn on or open for any new machines you may get.

Link to post
Share on other sites

It's getting a reset, and a close request each time it tries to put the files on. The lines that are saying sack_perm means the packet is not going through, WMI is still blocked inbound on the client. Netbios looks good, the credentials are good, .Net looks good.

Capture.thumb.JPG.8de5e1e0e94b44642a4ff78c8c02753c.JPG

59a8aab6d0677_Capture2.thumb.JPG.b9376ad868f38485b18993de9bdac2bf.JPG

Link to post
Share on other sites

Dyllon, problem solved and thanks for your patience and perseverance.  The DCOM WMI article was informative and shed new light on the subject.  As you know, the administrator account is disabled by default on a domain controller and we are encouraged to create a user account with domain admin rights.  That's the way this network has been since 2006.  Administrator account had been disabled and the Domain Admin crated was named sbsadmin since it is a Small Business Server 2011 network.  As soon as I tried to push an install to the problematic Win 10 computer using the built-in administrator account it worked!

Thank you 

Link to post
Share on other sites
  • 2 months later...

Thanks r042wal for posting your fix. That worked for me too.

Malwarebytes - Is the management console going to be updated to account for the changes in Microsoft technologies? Central management capability is key for a business class product such as this.

Thanks

 

Link to post
Share on other sites

I was meaning which feature of Windows was your concern.

The console isn't broken for pushing, it is that Windows is now more locked down than in previous years. This is an iterative process that Microsoft does through Windows Updates. More effort needs to be expended on the system admin's part to open certain things and meet the prerequisites for using the push utility. Once the push is completed, Windows can once again be closed up. Or you can choose to use the installation package feature and do your deployment through whatever other tool you may prefer to use, including Window's own GPO functionality.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.