Support Forum

Hello - We need to be able deploy Win10 Upgrades through patch remedy on machines that either can't reach the Drive variable location, or the location doesn't have a Drive variable set.

We have the ISO hosted in our webspace and the configuration for PR set to pull the ISO from there.
When I tried to have it run on my machine (which is outside of our network, but in the "Main" location so there is a Drive variable set) it came back with the error that it could not reach the network share to download the ISO.

I then moved my computer into a location with no Drive variable. Did the update config, verified in the Effective policy that nothing was set for the network share. I triggered the update again and this time it gave me an error I believe saying the location didn't have a LTShare set, but I am trying to recreate to verify.

To actually get it to install, I had to set the Drive variable to \\127.0.0.1\LTShare, create that folder on my desktop, share and share it. Then it finally let me do the upgrade.

Based on the documentation I have read, the webspace option disabled teh LTCache option and is supposed to be for if machines are unable to reach the ltcache, so I am a little perplexed if why it is needing an LT cache to download and install from the webspace..

We have several clients that have remote machines and some that don't have server environments all together. We need this functionality to update them.

Any help on this?
I had someone review the script code and even it looks to be requiring a drivelocation no matter what even though that is not what the setting page nor the documentation say when using the web URL
Even with this set like this, I get this error when trying to update a machine in a location with no drivelocation set. Would really like some input on this as this was one of the big things we wanted to utilize PatchRemedy for and not being able to to this is a major setback.

Reference information
http://support.plugins4automate.com/vie ... 5bc98a807f


Here is the cliff notes to the above more detailed information.

PR uses the WEB URL to find and download what is typically 4G+ of ISO file for either 32 or 64 bit OS, the potential download could be over 8GBs to cover both platforms. If we were to do this for every agent the bandwidth required would drowned out a company internet access. So to prevent this PR instructs the first agent that attempts the the upgrade to cache the ISO to a local network share "Location Drive" before attempting upgrades. Every agent then looks to this cache first to see if the ISO they need exists there. If not, the next agent will attempt to do the same caching.

The script looks to see if this location is set in configs for each company's locations.



If this is not set and available then the process will fail.

If you want to bypass the location drive then this is the acceptable work around.

To actually get it to install, I had to set the Drive variable to \\127.0.0.1\LTShare, create that folder on my desktop, share and share it. Then it finally let me do the upgrade.

But keep in mind that every agent will cache the file locally and no other agent can access ISO locally. For locations where multiple agents are at same location expect to see bandwidth spikes.

You can also create a location for remote users to be stored and apply those settings to that "remotes" location which one would expect all agents to be on seperate networks.

Cubert wrote: ↑Wed Apr 24, 2019 12:45 pm If you want to bypass the location drive then this is the acceptable work around.

To actually get it to install, I had to set the Drive variable to \\127.0.0.1\LTShare, create that folder on my desktop, share and share it. Then it finally let me do the upgrade.

But keep in mind that every agent will cache the file locally and no other agent can access ISO locally. For locations where multiple agents are at same location expect to see bandwidth spikes.

You can also create a location for remote users to be stored and apply those settings to that "remotes" location which one would expect all agents to be on seperate networks.

Thanks Cubert I think that tells me what I need. The programmers may want to take out that veribage about using the weblocation disabled the LTShare because it clearly still requires the LTShare.
Any chance of being able to add logic that would say something to the effect of "If the LTShare/Drive Location can't be reached download locally"?
I understand about the bandwidth thing but we have a lot of clients that work outside of an office. We are in a cloud world now for better or worse.

Yes, We could put some added switch in that give you a "No local drive override" allowing you to service off premise agents.

Let me poke around with that and get back to you.

Are you expecting the Windows 10 May Updated to cause havoc by the way?

not currently..

Any update on this ?