MEP will not push to new Win 10 computers

[r042wal]

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.  

[djacobson]

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

[r042wal]

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>

[r042wal]

Sorry, the error is "The RPC server is unavailable. Please allow WMI through Windows Firewall"

[r042wal]

I can telnet from the client to port 18457 on the server

[djacobson]

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.

[r042wal]

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.

[djacobson]

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

 

GPO or Firewall Rules -> Add Predefined -> File and Print Sharing

 

[djacobson]

If this still fails, record a push attempt with Wireshark and I will review it for what might still be blocking it.

[r042wal]

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.

[djacobson]

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.

[r042wal]

OK thanks.  I'm uploading a capture.  The computer I'm pushing in the capture is 192.168.0.43

amanda3.zip

[djacobson]

I'm seeing blocks on port 135 and 445 as the server tries to unpack the install files, try opening those. I'll keep looking to see if I find anything else.

[djacobson]

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.

[r042wal]

What port is it getting blocked on?

[djacobson]

135 and 445.

[r042wal]

No luck.  Made explicit inbound rules on the endpoint for both ports

[djacobson]

It could be that DCOM isn't configured to allow the connection. You can see in the Wireshark that 135 and 445 are being used via a high DCOM port. Check out this article - https://msdn.microsoft.com/en-us/library/aa393266(v=vs.85).aspx

[r042wal]

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 

[djacobson]

Excellent! I'm very happy to hear that got you going!

[BRAM]

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

 

[djacobson]

Hi @BRAM, which things are you curious about?

[BRAM]

Hi @djacobson I'm not sure I understand your question? Are you asking why I'm curious if they management console is going to be fixed?

Thanks,

Brad

[djacobson]

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.