I'm new to KACE, having taken over the admin role of an established setup; over the past couple of weeks I've tried to provision a dozen or so boxes, more for trying to learn the process than for need; they all have failed, mostly with network-related failures.

Being specific, I've got a brand new Win10 setup, on the campus domain, set up in a Virtualbox VM. I'm 99.9% confident the VM has no relation to the problem, as the VM is completely functional otherwise, and as mentioned, I've had similar failures pushing the agent to a dozen other (real) machines.

The failure I'm getting is:

  [05/10/16 09:09:20 AM] Begin provisioning...

  [05/10/16 09:09:20 AM] Executing Windows platform provisioning.


  STEP 1: CONNECT TCP/SSH - SUCCESSFUL


  [05/10/16 09:10:35 AM] Executing remote communications:


      Initializing RPC

      Connecting to ADMIN$


  STEP 2: AUTHENTICATION - FAILED


      ERROR: Failed to open connection - NT_STATUS_IO_TIMEOUT


  STEP 3: PUSH SCRIPT\PROVISIONING - FAILED


  [05/10/16 09:10:35 AM] End of remote communications.

  [05/10/16 09:10:35 AM] End provisioning run.

I've googled for the past week and a half trying to find a solution, but have come up empty. Remember - I'm a newbie at KACE, and I'm confident that what I understand about KACE is probably not entirely accurate. Any help would be greatly appreciated.

Thanks!

--
Kent

Answer Summary:
Cancel
6 Comments   [ + ] Show Comments

Comments

  • More Info:

    I built a brand new Win7 Enterprise box, not in a VM, but on actual hardware, on the same VLAN as the K1000 box.

    I did not rename it yet, nor have I added it to the domain.

    The K1000 appliance can ping this new Win7 PC (a Dell All-In-One, by the way), but the provisioning attempt fails with the same "NT_STATUS_LOGIN_FAILURE" error.
  • This content is currently hidden from public view.
    Reason: Removed by member request
    For more information, visit our FAQ's.
  • I have discovered that if I turn off the Windows Firewall on the real PC, I can connect to the ADMIN$ share, but if the Firewall is turned on, I can not.

    Making progress.
  • I have created a brand new Win10 virtual machine, and have not added it to the domain or added any additional software.

    I try to push the provisioning agent, and get the "NT_STATUS_IO_TIMEOUT" error.

    Nor can I connect to the ADMIN$ share via samba (tried from a Debian GNU/Linux box).

    Then I turned on "File and Printer Sharing" in the "Allow an app or feature through Windows Firewall" settings; still can't connect via samba.

    Then I turned off the Firewall completely; still can't connect via samba.

    Then I rebooted. Still can't connect via samba.

    I then added the following to the registry:

    Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
    Value: LocalAccountTokenFilterPolicy
    Data: 1 (to disable, 0 enables filtering)
    Type: REG_DWORD (32-bit)

    Apparently with newer versions of Windows, you can't remotely connect to the ADMIN$ and C$ shares with a local account, unless this filter is disabled.

    In addition, the Firewall needs to either be turned off, or you need to allow access through the Firewall for "File and Printer Sharing".

    Now I'll go try provisioning again, and will report back.
  • Provisioning still fails, with the same error.

    So I turned the Windows Firewall completely off, and provisioning still fails, but now with a different error:

    NETWORK/AMP Connection not detected
  • The full Provisioning Log:

    [05/11/16 10:46:27 AM] Begin provisioning...

    [05/11/16 10:46:27 AM] Executing Windows platform provisioning.


    STEP 1: CONNECT TCP/SSH - SUCCESSFUL


    [05/11/16 10:46:56 AM] Executing remote communications:


    Initializing RPC

    Connecting to ADMIN$

    Copying service file

    Disconnecting ADMIN$

    Connecting to IPC$


    STEP 2: AUTHENTICATION - SUCCESSFUL


    Opening pipe to service

    IN: pipe_open(\KBRemoteService, 7790178)

    Sending commands

    Commands: //k1000.acu.local/client/agent_provisioning/windows_platform/agent_msi_provision.bat k1000.acu.local client ampagent-6.4.180-x86.msi k1000.acu.local

    Sending login credentials

    Login: .\acutech

    [MSGCODE: 000] Begin agent_msi_provision.bat processing.

    [MSGCODE: 064] Detected 64-bit platform.

    [MSGCODE: 015] Executing MSI installer.

    %s

    C:\Windows\TEMP>start /wait msiexec.exe /qn /l*v C:\Windows\TEMP\ampmsi.log /i \\k1000.acu.local\client\agent_provisioning\windows_platform\ampagent-6.4.180-x86.msi HOST=k1000.acu.local

    %s

    C:\Windows\TEMP>echo off

    MSI Info: [ERROR_INSTALL_FAILURE] A fatal error occurred during installation.

    Access is denied.

    [MSGCODE: 002] K1000 Agent is not installed.

    [MSGCODE: 092] AMP is not connected.

    ERROR: The system was unable to find the specified registry key or value.

    [MSGCODE: 095] KUID value not written by MSI installer.

    [MSGCODE: 100] End agent_msi_provision.bat processing.

    OpenService - NT_STATUS_OK

    StopService - NT_STATUS_OK

    DeleteService - NT_STATUS_OK

    CloseServiceHandle - NT_STATUS_OK

    CloseSCMHandle - NT_STATUS_OK

    Connecting to ADMIN$

    Deleting service file

    Disconnecting ADMIN$


    STEP 3: PUSH SCRIPT\PROVISIONING - FAILED


    [05/11/16 10:46:56 AM] End of remote communications.

    [05/11/16 10:46:56 AM] End provisioning run.
  • I turned the Windows Firewall back on, but allowed the "Netlogon" feature within the "Allow an app or feature through Windows Firewall" settings, which gets me the same result as above when I had the Firewall totally turned off.

    Making progress....
  • This content is currently hidden from public view.
    Reason: Removed by member request
    For more information, visit our FAQ's.
Please log in to comment

Answer Chosen by the Author

0
Not a complete answer to solving the provisioning (the details are in the comments following my original post), but here's the answer to the immediate problem of this question, solving the NT_STATUS_IO_TIMEOUT issue.

1. Access must be allowed through the Windows Firewall on the client PC. Search for "Windows Firewall" and go into that control panel; then "Allow an app or feature through Windows Firewall"; then allow:
    Netlogon service

2. If you're connecting with local credentials from the client PC (e.g., your client is not part of a domain or you, for other reasons, don't want to use a domain account), you have to make a registry tweak to allow those local creds to be used remotely:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Value: LocalAccountTokenFilterPolicy
Data: 1 (to disable, 0 enables filtering)
Type: REG_DWORD (32-bit)

Whew!
Answered 05/11/2016 by: kentwest
Yellow Belt

Please log in to comment

Answers

Answer this question or Comment on this question for clarity