We are still getting this log statement on each of our systems when the Application Manager Service runs:
"The agents location does not have a configured "Location Drive" or credentials to access drive, exiting script without agent changes."
Do you have any suggestions for this? I set the agent caching agent last week, and I still get this.
I should also note that also even after a week, the Installed Version column has been blank on all of our systems. The repo version collum is populating though. I know it's a work in progress, but in case it helps, I wanted to provide that info as well.
Thanks.
This would make since if your not able to reach local cache. The Caching agent is getting repo data but either can not access the cache location or the agents trying to get cache can not access cache.
I suspect what you may have is a permissions issue. The caching agent must be able to write and read from location cache where all other agents just need to be able to read. So if you look on your cache location. Is there a Habitat/packages/ located on your Cache location?
If not then Caching agent can not access that share and write to it.
If the folder is there then caching agent can write to the share. You can look in the directory Habitat/packages/ for approved packages.
Also make sure that your caching location is correctly reflected here.
- LocationCacheSettings.PNG (27.99 KiB) Viewed 2461 times
~about one hour later~
A funny thing happened to me on the way to scripting a test for you to use.
As I was writing this post I side-stepped over to creating a test script you could deploy to see if a client is "Ready" for caching at a give location. Well as I wrote this script I kept getting a error about the cache password being null or blank. Well at first it was my fault as the client I was testing really didn't have a password set, my brain fart...OK set the password and still the same result. Well here is that little "gotcha", when you assume something, it typically makes an ass of you.
Here is no different, I can see that the password is "Hidden" in the variables available but, I assumed that when in the script language it was reveled. The developers just didn't want it visible in the debugger.
- Capture.PNG (11.71 KiB) Viewed 2461 times
However, this isn't so as I come to find out. I tried several methods to have it revel the actual passcode and every attempt returned null. So what's going on is that it is using the username but not passing the password as you would expect. If your share is fully accessible by everyone then this passes and all works as expected but if you expect the pass it fails to provide it as expected.
The funny thing is I can just query the locations table for it directly as my own variable so not sure why that is ... Automate is a fickle beast.
Anyhow I will be correcting this today and getting out another build to replace the current one.
I apologize to everyone that I didn't catch this oversight. our development agents and networks are not tightly secured so this got past us when configuring the share security.