/build/static/layout/Breadcrumb_cap_w.png

Getting a [error] Error while reading 1 bytes from network: 10060 while capturing an image

I am having issues capturing some images created on VM Workstation 12.  I am getting the following errors:
2018-01-23 09:57:39-0800 [info] ...Capture complete!
2018-01-23 09:57:39-0800 [info] gOptImageName=411, gOptLocalDir=D:\K2_2018-01-23_08-26-38
2018-01-23 09:57:39-0800 [info] Hashstore Client (Version 5.0.16)-start
2018-01-23 09:57:39-0800 [debug] CaptureImage-start
2018-01-23 09:57:39-0800 [info] Ready to copy 2 items (10.86 GB).
2018-01-23 09:57:39-0800 [debug] UploadFiles-start
2018-01-23 09:57:39-0800 [info] This is a WIM image:
2018-01-23 09:57:58-0800 [error] Error while reading 1 bytes from network: 10060
2018-01-23 09:57:58-0800 [error] Failure to send manifest add request
2018-01-23 09:57:58-0800 [debug] UploadFiles-early return
2018-01-23 09:57:58-0800 [debug] CaptureImage-end [0]
2018-01-23 09:57:58-0800 [info] Items processed: 1 (0 B)
2018-01-23 09:57:58-0800 [info] Items transferred: 0 (0 B)
2018-01-23 09:57:58-0800 [error] Error while writing 37 bytes to network: 10054
2018-01-23 09:57:58-0800 [info] Hashstore Client-end [0]
2018-01-23 09:57:58-0800 [error] Failed to complete successfully.
2018-01-23 09:57:58-0800 [debug] HashstoreConnection Disconnected
2018-01-23 09:57:58-0800 [error] Error while writing 0 bytes to network: 10054
2018-01-23 09:57:58-0800 [info] ...Deleting image dir: D:\K2_2018-01-23_08-26-38
2018-01-23 09:57:58-0800 [info] Klonewin - Done, exit code: -1

The image has been sysprepped. It is Windows 10 x64. Over half of the hard drive is free space. The K2000 has over 2TB of free space. I have only 502 GB taken up of system images on the server.  As you can see above, the wim file is created on the VM, but for some reason cannot upload to the K2000.  I have been able to capture and upload other images.  I just created a Windows 10 base OS image and it captured and uploaded fine (size 4.79 GB). Any suggestions on what I can look into or how to fix this?  I have a ticket in with Quest Support about this as well.  Thank you for your time and knowledge.

Andy

2 Comments   [ + ] Show comments
  • I also am having this same problem.

    I'm a little out of date at v. 4.1.182 but this worked last year and now it doesn't.

    Our K2 is on a separate internal vlan, and I can deploy to our regular production network, but I cannot capture on:
    Production network using DHCP
    K2000 network using built-in DHCP
    Legacy boot
    iPXE boot

    Nothing is working in terms of capturing and it's becoming very frustrating.

    Again, this all worked last year and our environment has otherwise not changed with regards to how DHCP is setup to point to our K2.

    I've updated and refreshed the Win10PE drivers.
    I've created new KBEs.

    Nada. - rskwire 6 years ago
    • You are loosing packets traveling from the computer to the K2

      2018-01-23 09:57:58-0800 [error] Error while reading 1 bytes from network: 10060

      2018-01-23 09:57:58-0800 [error] Error while writing 37 bytes to network: 10054

      2018-01-23 09:57:58-0800 [error] Error while writing 0 bytes to network: 10054


      Might be environmental, see if all ports are properly open
      https://support.quest.com/kace-systems-deployment-appliance/kb/129799

      Check with support...

      I would also try to update to the latest version, and if your kbox is a VM, make sure vmwaretools is properly installed. - Channeler 6 years ago
      • Sorry for confusion.

        My similarity with this issue was the "Error while reading 1 bytes from network" part.

        It's always:

        2018-01-24 10:57:12-0500 [info] (IP:49674) Received connection.
        2018-01-24 10:57:12-0500 [info] (IP:49674) Capturing image 'x'
        2018-01-24 10:57:13-0500 [client] Completed successfully
        2018-01-24 10:57:13-0500 [error] Connection closed by remote while reading 1 bytes from network.
        2018-01-24 10:57:13-0500 [info] (IP:49674) Client disconnected. - rskwire 6 years ago
      • So check ports, might be silly but it's worth it

        https://support.quest.com/kace-systems-deployment-appliance/kb/129799

        If you are capturing from a VM check this KB article:
        https://support.quest.com/kace-systems-deployment-appliance/kb/232911

        For example, we can't capture images when the VM has 2 vCPUs, so we use one CPU with one Core. - Channeler 6 years ago
  • Thank you for the comments. I got a call from a Quest engineer who suggested that I update to the latest version (5.1.84) for the K2000, which came out two days ago (1/22/18). I am attempting to capture another image right now. Thank you for the link for the VM vCPUs. I hadn't seen that before. I will test that out next. My network engineer has checked the firewall ports and doesn't see any blockages. I will continue testing. - AAnschutz 6 years ago
    • I have my k2000 updated and still getting this issue.
      What are your findings with this?
      I was wondering if we need to update the KBE to work with this update.

      -Alex - adavenport 6 years ago
      • @AAnschutz did you get this issue resolved? - adavenport 6 years ago
      • Since upgrading the K2 to 5.1.84, I have been able to direct capture the WIM twice. I didn't have to recreate the KBE. In talking to Quest's engineer, the upgrade to 5.1.84 is only upgrading things on the server and nothing needs to be upgraded or changed on the client's KBE. The direct capture does take longer than the regular WIM capture but at least it is captured. - AAnschutz 6 years ago

Answers (0)

Be the first to answer this question

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ