Habitat Upgrade Assistant - Remote computer issue and feature request

[rshaw.golden]

To save bandwidth we had been making use of the Network Cache feature. However when I ran it last night, some computers that were remote to the client's network and not VPN'd in were unable to reach the cache(as expected) but did NOT download the ISO to themselves and run it - they tried to download to the location that it had already failed to reach, which of course didn't work.

Similarly, I do have some clients with multiple sites that cannot talk to each other, but DO have servers for caching, and when scheduling those I was having to manually check each machine to see which location it was in,. This is unfeasible for a larger client than the one I did it for, I feel.

As such I have two requests. First, can we get a location column added to the scheduling interface? The way sorting works right now won't let me sort by client and then location even if this was in place already, but with a location column I can at least see what location each computer is in without bouncing back and forth and easily ctrl-click to select the right ones for each location to assign the proper policies.

Second, is it possible to have the download portion fail over to local location and download from the source if the network cache is not working or available? Even if it needs another checkbox to enable, this would make things far simpler.

[Cubert]

I will look and see what's needed to add a location column.

As for different functions based on location, I would create a policy for each location and for remote agents and configure the policies as needed.


Your second request is actually in there now but reversed. If an agent is set to grab ISO (from somewhere) and or use network cache then it will look at cache and if not there attempt to download it. I will need to review the process of this but I believe it saves it locally then tries to push a copy to networks which in your case would fail if network was not available. I believe the script would continue with local copy.

[rshaw.golden]

Not sure if you've been able to test yet, but for me in every instance where it fails to reach the network cache it appears to download(judging from timestamps), tries to access the cache afterwards, then fails and exits, so it does not seem to be proceeding onward using the local copy if the cache location is unavailable.

[Cubert]

Try disabling line 219 in the updater script and see if that sends you on to "ContinueWindowsInstaller" section where the mastercacheagent should now be set and forces a local install.

[rshaw.golden]

I got a chance to try this, and while it did proceed onward, it still errored out with

Mounted ISO as Drive letter [ Mount-DiskImage : The system cannot find the file specified. ]

Based on 233 and 234, it looks like it still tried to read from the network cache location.

[Cubert]

What we done since our last post is change the behavior of the NETWORKISOFAILED to instead of logging and exiting to logging and continuing with MasterCacheAgent set to 1

So the 219 line will remain enabled now but will not cause an exit.



At line 239/240 we will test for MasterCacheAgent to be a (1) one and if so we start with MOUNTLOCALISOFILE which should log at line 242 to the script log that we are using local ISO. Then on line 244 it mounts the path @ISOPATH@ which was set at line 208/209 and or 214 if Enterprise.

When you go to run and debug see if it shows log about local or network ISO being used so we can see if you are failing inside the LOCALISOFILE section.


You can find the new Habitat 1.0.0.63 build at

https://delivery.shopifyapps.com/-/e00e ... 5a26c7b329


Or Habitat will auto update tonight.

[rshaw.golden]

I'll let it auto-update tonight and see how things go after that. I may not know until after the weekend, depending on when it auto-updates.

On a side note I found a bug with how it detects if setup is still running. I had a bad ISO cached at one location and this was causing setup.exe to pop a error box in the background and just never close out, which then prevented future runs. The key is that the process name in line 295 has to leave off the .exe i.e. use setup instead of setup.exe. The latter doesn't pick up even if it is running at that exact moment.

Screenshot 2021-02-18 110550.png (148.12 KiB) Viewed 4281 times

Screenshot 2021-02-18 110755.png (41.85 KiB) Viewed 4281 times

[rshaw.golden]

Alright, was able to test. It worked fine for 64 bit, but 32 bit ran into issues. The issue there was the ISOPATH:

%ltsvcdir%\Habitat\Windows10UG\20H232.iso

It's missing the _ between the version and the architecture for 32-bit, on line 208. When I tried adding it myself and testing, it went through fine, so looks like that's the only tweak needed there right now.

[Cubert]

Awesome,


YEap I see the typo and have it now fixed