I think the development of Habitat and the App manager is doing great. However, I do have several items that I thought could use some attention to see if consideration could be taken on them.
Item 1.
There is still something wrong with the schedule. The schedule doesn't appear to be activating when switching back and forth between daily and weekly mode, even when it says it has saved. When I look at the LT script logs, I can see that the Habitat App manager scripts don't actually kick off as corresponding to the schedule type. The problem can be in either direction. I think that is part of the problem I was previously reporting. Honestly, I think it would be better to have three radio boxes where you could select Daily, Weekly, or Monthly and then press save. Having a radio button for all three would be more intuitive and probably more reliable in the long run as there have been problems with the current method not working as expected. For example, I switched two customers to daily at the beginning of the week to test this, and the schedule clearly says daily, but the last script run was a week ago on the previous weekend scheduled day when the schedule was weekly mode on the weekend. But when switching back to daily, the scripts aren't activating on daily. Previously I was seeing this in reverse when the scripts would not kick off on the day of the week the weekly schedule was set to. I was also still having issues with turtle mode on either, but if I just stick to Rabbit mode, that would be fine as long as the glitch in the schedule is fixed, but if I switch back and forth a few times and restart the database, then things kick back into gear, or so it seems.
Item 2.
The caching agent system can't seen to scan itself, list versions or update itself. The caching agent actually has blank data for all the columns as it is not populating any info by default. To correct that, I can simply right-click on the caching agent and select run version scan, then update now. That's not a huge deal, but I have confirmed that issue on several customers, so that may want to get looked at so it is also automatic. I think this issue is related to a problem when it tries to clear the cache upon completion for just the Caching Agent system.
Item 3.
There are issues downloading some package files. Part of this may be just an issue with bad packages, but I wanted to run this by you just in case. This issue deals with specifying variables in the download source link that is not valid. For example, the issue with Firefox is that it includes the "locale" variable at the end of the download line, which is not valid.
Download Failed:
https://download.mozilla.org/?product=f ... g=${locale}
If I remove the "&lang=${locale}" at the end of the line, it works. It seems like it might be a Firefox package or site issue, but if that is related to the parsing from Habitat in any way I wanted to bring it up.
Here is a list of various package download issues I am seeing, which may be issues with those packages or possibly with Habitat.
- Habitat cache.PNG (114.15 KiB) Viewed 2027 times
Item 4.
There are issues with the package download on the Caching Agent, even though the downloads almost always complete. This may be related to the issue of applications and versions not populating. Specifically, I am seeing "Access Denied to the path 'C:\Windows\LTSvc\Habitat\packages". This is shown on every application listed but only shows on the Caching Agent system.
I don't know why it would be downloading there because that is not the cache location, unless it is trying to copy from the "Script and template variables" Drive.
Here is an example.
- Habitat cache access denied.PNG (38.08 KiB) Viewed 2027 times
To be more specific, on the caching Agent/Server every application triggers a "Checking repo cache for [application_name]"
On every package, it always triggers the following error every time it goes through a repo cycle.
"Cacher status -> [Directory 'C:\Windows\LTSvc\Habitat\packages' does not exist.]"
That is not the repo cache directory, so it doesn't make sense why it's checking the default LT Habitat location for a packages directory as that is not the configured Habitat packages directory. The configured packages directory as specified at the LT site level is where the packages directory exists.
Item 5.
Would it be possible to include a method to reset all application data and versions at a global level and at a customer level? I say this because sometimes there might be situations where there are major application changes across either a particular customer or all customers. It would be more reliable to start over with a new scan of new application data and versions and to truncate all old data. The second reason would be after any technical issues such as a modification to the Habitat or the application list or other issues that require troubleshooting and require a reset. Being able to do this at a customer level would be very convenient, especially when a particular customer just doesn't work. I'm also thinking at the global level for the same reason if there are major issues, as this would be a lot more convenient than adding a truncate table command from the SQL maintenance tool.
Item 6.
Would it be possible for a repository rescan button on the Application management main console instead of waiting overnight for that particular script of Habitat to kick off. I say this because if I'm troubleshooting something and I change the list of global applications, the repository field will say none until 5AM. This can be problematic if I'm troubleshooting something. I'd like to be able to press a button that allows the global application list to rescan the Chocolatey repository and record the version information. I'd also like to see a reset button that clears all the values to none so I can then press a rescan button to recheck all the versions, which can wipe out any legacy applications that no longer have valid repository information in Chocolatey. This would be helpful when troubleshooting applications and removing stale applications that are legacy or if there is any problem with the list. For example, this screenshot shows applications I was troubleshooting, but I have to wait overnight to see if the version populates, confirming it is working.
- Habitat Search.PNG (47.18 KiB) Viewed 2009 times
Item 7.
Is there a way for Habitat to truncate applications that no longer exist when it does its rescan at the customer level? I ask because we removed an application a few weeks ago from all systems of a customer, but yet Habitat still says that the application is still installed on each system, with the version at the time, but in fact, that software is not even installed. I think this is critical to ensure that people have faith in the data being reported to ensure it can be trusted. If that function isn't possible, then that customer level reset button is what I would need so I can issue a reset to correct such anomalies to ensure accurate data.
Item 8.
Is there a way to include the application's actual name on the Managed Applications list at the customer level, which is resolved and shown on the main console at the global level during the search? At the customer level, it currently shows the application package name, the last update, installed version, and repo version. But the package name is being listed as the application name. However, it would be great if the actual application name could be a column such as the first column and then the column for the package name. This is very helpful when the package names don't line up with the application name, which is the case with some package names. This is also helpful when the same package name is used for multiple installed applications or when troubleshooting variances in application names where it might actually require a different package, and you can't see what application is being targeted.
Item 9
In some situations, the installed version column is still not showing up, and there is an error stating, "Application source is unavailable". These systems pass all the script checks, and some systems in the same site are showing up correctly. See the screenshot below to so you can see what I mean.
- Habitat app error.PNG (43.43 KiB) Viewed 1978 times
Item 10.
Is there a way for Habitat to update the “Programs and Features” / “Add Remove Programs”, so it properly reflects the updated version after the applications have been updated? I noticed that even though the applications are being updated, Windows still sees the applications as having the old versions. Also, when Labtech does its inventories, it also still shows the applications having the old versions. This is problematic when doing audits for auditors because we are not in compliance unless the inventory lists show the application versions as current. The auditors then verify this information on systems by spot-checking the “programs and features” version list or issuing a remote query to query the system to pull the software installation status and versions that also show the old version. I am hoping that Habitat can find a way to update Windows with the updated application version when it completes the application upgrade. Since this is a major issue with auditors, I am hoping there is some way we can deal with this setback.
Thanks for all the help through these remaining issues.