K1000 Not Pushing completely -PART Files
We're having issues with out K1000. We are rolling out a bunch of machines and can't get them to consistently receive managed installations. The devices are talking to K1000 because we are getting current and accurate inventory information. Below is a brief description of our environment:
Some MIs are tied to regular labels and some tied to smart labels. There are some MIs from both sides that are having issues.
The devices are inventory-ing fine and are getting the appropriate smart labels.
When the devices check in, KInventory runs in task manager, then KDeploy, but only for a second.
There are folders appearing in ProgramData\Dell\KACE with the MI ID as the folder name. Inside are the install files, but all .part and 0 KB in size.
The big push on this is on Win10 devices, but we are seeing this on 7 as well.
Sometimes it works fine. THe device checks in and downloads. and installs everything it needs. But only about 1 every 10 does that. But, at least that tells me that the MIs and Labels are setup properly.
We've rebooted device and server, deleted machines out of inventory and let them check back in, rescripted the OS on the devices, not really much luck there.
If I delete the folders from ProgramData\Dell\KACE, then let it re-inventory, it creates the same folders and PART files.
We are running server v 7.1.149 and agent v 7.1.62. We had upgraded to 7.0 and thats when we seemed to start having issues. Thought upgrading to this version might fix it, but apparently not.
Just out of ideas here. I had submitted a ticket to Quest but they just let it sit for days with no response so I gave up with them and am hoping to find help here.
Thanks!!!
Some MIs are tied to regular labels and some tied to smart labels. There are some MIs from both sides that are having issues.
The devices are inventory-ing fine and are getting the appropriate smart labels.
When the devices check in, KInventory runs in task manager, then KDeploy, but only for a second.
There are folders appearing in ProgramData\Dell\KACE with the MI ID as the folder name. Inside are the install files, but all .part and 0 KB in size.
The big push on this is on Win10 devices, but we are seeing this on 7 as well.
Sometimes it works fine. THe device checks in and downloads. and installs everything it needs. But only about 1 every 10 does that. But, at least that tells me that the MIs and Labels are setup properly.
We've rebooted device and server, deleted machines out of inventory and let them check back in, rescripted the OS on the devices, not really much luck there.
If I delete the folders from ProgramData\Dell\KACE, then let it re-inventory, it creates the same folders and PART files.
We are running server v 7.1.149 and agent v 7.1.62. We had upgraded to 7.0 and thats when we seemed to start having issues. Thought upgrading to this version might fix it, but apparently not.
Just out of ideas here. I had submitted a ticket to Quest but they just let it sit for days with no response so I gave up with them and am hoping to find help here.
Thanks!!!
1 Comment
[ + ] Show comment
-
So can you send out the MI manually and it installs on the computer? - TimHR 7 years ago
Answers (1)
Please log in to answer
Posted by:
chucksteel
7 years ago
First of all, don't settle for poor customer service. Call Quest to get an answer.
To try and answer your question, have you tried enabled debug output on the client? Is it consistent per client, i.e. particular computers always fail to download?
Comments:
-
When you say debug, do you mean through the AMP Agent? Not sure we've ever done that before but can look it up.
The way we see it now, we'll put a script on a machine. Most of the time we see this issue now. Every once in a while we'll have a machine that actually downloads things and works fine to begin with, but that's not common. If we have a machine that starts failing, it just keeps failing no matter what we tell it to do. If we re-script the machine, it could possibly be one of the ones that starts downloading stuff, but one of the good ones might start failing if we rescript it. So, there seems to be no rhyme or reason to it.
We bought 150 Acer Switch Alphas - which is where we first noticed this issue. At first we thought it was either due to the hardware - which isn't impressive - or the fact that this is our first time managing Windows 10. However, we've had to rescript some Win7 machines that have always worked fine for us and those machines now show this same problem...
Thanks! - clarlee 7 years ago-
UPDATE: Tried enabling Debug on the client and got this error "Failed: The key "debug" is not host and host is the only key modifiable" - clarlee 7 years ago
