/build/static/layout/Breadcrumb_cap_w.png

Software Deployment Question


Deploy Directly From Server Option

07/16/2020 309 views

Some explain this to me as I don't completely understand.

We are trying to fix some speed issues at one of our deployment locations.  The KACE SDA is housed at one campus and we have a RSA at the other 3 campuses.  Each image that I uploaded to the SDA has been pushed to each RSA.  Each image was captured and marked as "Deploy Direct from Server" during the capture process.

My question is: What does the "Deploy Directly From Server" option actually do?  Does it mean that it processes the install from the SDA rather than the RSA?  I'm just wondering if the system is slower than it needs to be because it is pulling the image from the SDA at another campus rather than pulling the upload one on the RSA.

0 Comments   [ + ] Show comments

Comments


All Answers

0

That option debuted on version 5.1.

Before that, every WIM Image, had to be copied as a whole to the Target Device HDD and then applied.

For example, the KACE SDA had to transfer a Single WIM File (10GB), into the C:\ and then proceed to apply it.  This caused network issues for some environments.

Direct Deploy was added as an option, and now instead of transferring that huge payload, the KACE will apply\deploy the image directly from the server, streaming pieces of the image through the network. This helps to maintain a good speed and not saturating a single pipe.

Direct Deploys are something SDA and it's RSAs are able to do.

Answered 07/16/2020 by: Channeler
Red Belt

  • OK, well that tells me that part is not it then since I have the option checked on all images at all locations.

    The only other item that I can check is the KBE. I just built a new one but the only change we made was instead of pointing to the SDA, I pointed each location to their own RSA to boot from. Any idea if that caused issues there?
    • normally
      Only one KBE is needed...
      then that same KBE is synced to X amount of offices (RSA).
      When you PXE boot , the DHCP at that office\network is the one who's going to tell the KBE what's the IP of the imaging server.

      It can be an SDA OR an RSA.
      The KBE finds this IP, and proceed to attach itself to the SDA or RSA (based on the DHCP option 66 value).

      If a KBE fails to contact an RSA, it's going to fallback to the main SDA.

      I'm not sure how are you dealing with the booting process, but like I said, 1 KBE should be enough to deal with 50 RSAs... or more.
      • While I realize that only one KBE is needed, I was tasked to see if I could build a separate on for each location that pointed to the RSA rather than pointing back to the SDA. My manager felt that our issue could be campus to campus connectivity rather than on site connectivity.

        If what I have done won't do any good, I can just purge the extra KBE's for each individual location.
      • well, a lot of time was put from R&D, to prevent users with say 100 RSAs from having to build one KBE per RSA...

        What is the issue you are having?

        When you boot to a KBE, if you take a look at the KBE footer, is going to give you the IP address of the SDA or RSA it's currently attached to.

        Is that value not desired?

        (NOTE: if you can't see it, go to troubleshooting tools, open CMD and type:

        echo %KBOX_IP%

        It will print the IP address of the SDA or RSA currently in use by this KBE)
    • Building a KBE for a specific RSA is usually because DHCP in winpe is unable to find the RSA and then falls back to the SDA as @Channeler mentioned. He also correctly mentioned that in some user's environments, deploying direct from server is faster. When deploying direct from server, the term "server" refers to the appliance you pxe booted to, so in your case it would deploy directly from that RSA (not the SDA). Something else to keep in mind is that you can't multicast using direct from server, because the benefit of multicast is transferring one large file.
 
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