Udostępnij za pośrednictwem

Error: "The parameter is incorrect" when connecting to a server using WMI.

  • Artykuł

 

You test WMI connectivity remotely using WBEMTEST > Error: "The parameter is incorrect"

 

Analysis:

Network trace during the issue shows that communication is happening with TCP Port 135 but after that secondary connection other DCOM/WMI interface not happening on other DYNAMIC RPC ports (above 1024).
All ports between the client and the target server are open.

 

Network trace during the problem: communication only with TCP port 135

10.171.72.119 abizerh-lab MSRPC   MSRPC:c/o Bind: UUID{000001A0-0000-0000-C000-000000000046} IRemoteSCMActivator(DCOM)   Call=0x4 Assoc Grp=0x0 Xmit=0x16D0 abizerh-lab 10.171.72.119 MSRPC   MSRPC:c/o Bind Ack:   Call=0x4 Assoc Grp=0x71F7 Xmit=0x16D0 Recv=0x16D0
10.171.72.119 abizerh-lab MSRPC MSRPC:c/o Alter Cont: UUID{000001A0-0000-0000-C000-000000000046} IRemoteSCMActivator(DCOM) Call=0x4
abizerh-lab 10.171.72.119 MSRPC MSRPC:c/o Alter Cont Resp: Call=0x4 Assoc Grp=0x71F7 Xmit=0x16D0 Recv=0x16D0
10.171.72.119 abizerh-lab DCOM DCOM:RemoteCreateInstance Request, DCOM Version=5.7 Causality Id={F756624A-7CA5-4534-9F62-6638201C68CD}
abizerh-lab 10.171.72.119 DCOM DCOM:RemoteCreateInstance Response, ORPCFLOCAL - Local call to this computer ----->ReturnValue: 0x00000057 - ERROR_INVALID_PARAMETER - The parameter is incorrect.

 

Working trace: You can see that apart from the connections to TCP 135, secondary connection are being made to other UUID of DCOM / WMI interface.

10.171.72.119 Abizerh-lab MSRPC   MSRPC:c/o Request: unknown Call=0x3 Opnum=0x5 Context=0x0 Hint=0x0
Abizerh-lab 10.171.72.119 MSRPC MSRPC:c/o Response: unknown Call=0x3 Context=0x0 Hint=0xE4 Cancels=0x0
10.171.72.119 Abizerh-lab DCOM DCOM:RemoteCreateInstance Request, DCOM Version=5.7 Causality Id={03728AE5-CD86-4477-BA31-7B275C0A7CFF}
Abizerh-lab 10.171.72.119 DCOM DCOM: Response, ORPCFLOCAL - Local call to this computer, Unknown IRemoteSCMActivator Method opnum=010.171.72.119 Abizerh-lab MSRPC MSRPC:c/o Bind: UUID{00000143-0000-0000-C000-000000000046} IRemUnknown2(DCOM) Call=0x1 Assoc Grp=0x0 Xmit=0x16D0
Abizerh-lab 10.171.72.119 MSRPC MSRPC:c/o Bind Ack: Call=0x1 Assoc Grp=0x7688 Xmit=0x16D0 Recv=0x16D0
10.171.72.119 Abizerh-lab MSRPC MSRPC:c/o Auth3: Call=0x1
10.171.72.119 Abizerh-lab DCOM DCOM:IRemUnknown2:RemQueryInterface Request, DCOM Version=5.7 Causality Id={03728AE5-CD86-4477-BA31-7B275C0A7CFF}
Abizerh-lab 10.171.72.119 DCOM DCOM:IRemUnknown2:RemQueryInterface Response, ORPCFNULL - No additional information in this packet
10.171.72.119 Abizerh-lab MSRPC MSRPC:c/o Alter Cont: UUID{D4781CD6-E5D3-44DF-AD94-930EFE48A887} IWbemLoginClientID(WMIRP) Call=0x2
Abizerh-lab 10.171.72.119 MSRPC MSRPC:c/o Alter Cont Resp: Call=0x2 Assoc Grp=0x7688 Xmit=0x16D0 Recv=0x16D0

Dumped the endpoint mapper database of the TARGET server (we are trying to connect to via WMI) containing the details of the services asociation with different protocols/ports.
- RPCDUMP /s target_server /v /i > rpcdump.txt
**RPCDUMP is a part of windows resource kit.

 

This output during the problem, from the target server, showed services listening on ncacn_np, ncalrpc but NO services listening on ncacn_ip_TCP. In a normal scenario, the above output should show atleast a few services listening on Dynamically allocated TCP ports i.e. associated with ncacn_ip_TCP protocol. A few services that you should fine listening on all Windows server is SAM {12345778_1234_abcd_ef00_0123456789ac} or SVCCTL {367abb81_9844_35f1_ad32_98f038001003}.

 

You should see something like this in the RPC dump to confirm that Dynamic allocation of TCP ports is happening on the server.

 ProtSeq:ncacn_ip_tcp
Endpoint:5003
NetOpt:
Annotation:
IsListening:YES
StringBinding:ncacn_ip_tcp:ABIZERH-LAB[5003]
UUID:12345778-1234-abcd-ef00-0123456789ac
ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT
VersMajor 1 VersMinor 0

 

After receiving the hint from the RPCdump output, of the Target server, we looked up the following registry key/values on the Target server.

 HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet
- Ports
- PortsInternetAvailable
- UseInternetPorts

**These values were present and configured on the Target server.

Note: the above registry values are not present by default and are set it case you want to set a range of TCP ports for RPC dynamic port allocation.

How to configure RPC dynamic port allocation to work with firewalls
https://support.microsoft.com/kb/154596

So was this RPC dynamic port allocation configuration causing the problem? NO NO NO

On the problem target server, we found that the RPC dynamic port allocation configuration were not set correctly i.e. the Port range had a space between them for example Ports = '5100 - 5200' instead of '5100-5200' . This was basically confusing the OS where it knew that the RPC dynamic allocation restriction was set but could make sence of the values, hence causing it not to allocate any ports to any services at all.

Further testing showed that even when "PortsInternetAvailable" or "UseInternetPorts" were mis - spelled , OS couldn't handle it correctly.

Correcting the above settings related to ‘RPC dynamic port allocation’ and rebooting the target server resolved the issue and now we were able connect to the server using WMI.

 

 

- Abizer

Comments

  • Anonymous
    April 10, 2012
    Hey, thank you very much!!! 3 years later, your post has saved me maaaany debugging time...

  • Anonymous
    August 29, 2012
    Abizer, good job! Thanks a lot!

  • Anonymous
    August 30, 2012
    My previous extensive comment somehow was not saved... anyway, I was receiving error 0x80070057 while using WMI with remote server: C:temp>wmic /node:SERVER logicaldisk Node - SERVER ERROR: Code = 0x80070057 Description = The parameter ins incorrect. Facility = Win32 It's a pitty you don't have this error in your article, probably it would help find this article and fix the root cause faster, because to reach this article I had to look quite a while.

  • Anonymous
    August 05, 2015
    I had a similar issue on one for the latest Windows 2012 R2 server, turns out because of Veeam , following blog post explain the solution
    http://www.grishbi.com/2015/08/windows-2012-r2-wmi-failed-to-connect-win32-the-parameter-is-incorrect/