/build/static/layout/Breadcrumb_cap_w.png

K1000: Managed Installations - How to force them to start & troubleshooting failed installs

Is there any other way to force a Managed Install to start immediately other than "Forced Inventory Update"?

Also, does troubleshooting a failed install require access to the local machine?  How does one best go about investigating why a Managed Install failed - log locations, etc? For example, with scripts (again on the K1000), I can go into "Run Now Status" and get some idea where my script failed.

Thanks in advance,

 

Eric


0 Comments   [ + ] Show comments

Answers (4)

Answer Summary:
http://kace.uservoice.com/forums/82699-k1000/suggestions/1551707-add-a-run-now-option-for-managed-installations / Troubleshooting Managed Installs: http://www.kace.com/support/resources/kb/article/Troubleshooting-Managed-Installs
Posted by: dugullett 11 years ago
Red Belt
5

Comments:
  • dugullett that answer is almost cruel lol - RandomITPro 11 years ago
  • Cruel but true. I used the force inventory script a lot as well. Just make sure to not apply this to too many machines at once. - dugullett 11 years ago
    • Not cruel at all...in fact I pretty much knew that there wasn't a better solution and needed the reminder to cast my vote....which I just did. ;-) - etipton 11 years ago
  • Wise words. I made that mistake once - RandomITPro 11 years ago
Posted by: RandomITPro 11 years ago
4th Degree Black Belt
5

Nope machines will need to update their inventory in order to get a managed distribution.

I will create a label that matched a distribution. assign all computers in that label to get that distribution. Call the label and assign the built in "Force inventory update" script. Then run that now.

As for logs you can view to see if the client is actually downloading the package (I think) . In Computer Inventory select the machine and under logs click KBOX Scripting updater. Select show all in the window that pops up and search for "retreive".

Most importantly though is to have a test machine. With no potentail requirements like .net and java etc. That goe along way to making sure your packages work.

 


Comments:
  • Most of my Managed Installs are one-off's but will keep the label idea in mind for any future group installs. As for testing, that goes without saying (for me anyhow) and I do test using different hardware & software configurations but suffice it to say that we have a complex environment. I didn't have a specific install that failed in mind when I asked the question - I just know that it happens from time to time and wasn't sure how to best troubleshoot. I had seen the document above (linked by dugullett) before but will add it to my bookmarks).

    Thanks again for all of the responses. - etipton 11 years ago
    • Another thing to keep in mind is that pre-install messages, and snooze messages count as an attempt. If your setting is left at default (3) and they snooze three times then it might look like it's failing, but it is not. It's just the user refusing to install. - dugullett 11 years ago
  • Good point...have had that happen at least once! - etipton 11 years ago
Posted by: jverbosk 11 years ago
Red Belt
1

In regards to MIs failing, I've found it's typically either due to certain applications or processes running at time of install (which is where a batch file killing said processes prior to the install comes in handy) or simply an issue on the machine itself that requires manual intervention (i.e. copying over the MI files and running manually on the failing machine results in errors due to various factors - corrupt files, non-standard configs, failed prior version uninstalls, etc).  I can attest to a 99.5% completion rate on my MIs, but a good amount of time is spent setting things up and testing against machines with various configs (and previous versions of the same app if applicable) prior to building the MI on the K1000. 

There will always be instances of machines that require some manual intervention, just think of it as the machine's cry for attention. That being said, if an MI is failing most of the time, I would go back to testing (or look into using replication shares if remote machines are typically the ones failing).

As for troubleshooting K1000 processes and related, something here might help:

http://www.itninja.com/blog/view/tracking-processes-on-machines-during-patching-managed-installs-scripts-w-utility-scripts

John

 

Posted by: cnilsson 8 years ago
Senior White Belt
1

I know this is an old question but the answer is still useful.

If you have access to the machine then you can force the process very easily. Forcing inventory does not force your managed installes...it just runs the inventory. The inventory process will "queue up" the needed installs but they will not run until the next time the managed install task runs. Inventory, Managed Installs, and Scripts are independent tasks the kace agent runs on work stations.

From the command line you can navigate to program files\dell\kace and execute "runkbot.exe 4 0" to force the inventory. Then execute "runkbot 6 0" to force managed installs and file syncs, then execute "runkbot 3 0" to force scripts. I would followup with another "runkbot 4 0" to update your inventory with all the changes from the installers.

The runkbot.exe command simply takes in the ID number of a script on the K1000 and runs it. If you click on any of your scripts in the K1000 and then change the ID= variable to 4, 6, or 3 you will see the hidden scripts for Inventory, Managed Installs/File Sync, and Scripts...DON'T EDIT OR DELETE THESE!!!

You can even Put these together in a batch script in the K1000 and name it something like "Rush Installs". Then you could do a "Run Now" against a remote machine that you don't have command line access to remotely.

We use this "Rush" technique as a run once script on all machines coming off imaging to force them to quickly get all their required software.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ