Post-Installation Tasks failing
Hello,
I'm still rather new to both the KACE SMA and KACE SDA. I've been trying to setup some post-installation tasks for one of our scripted installations, but they keep failing. They are tasks which I have imported from Managed Installations on our K1000. The run just fine when I push them out to a device from the K1000, but they fail every time as a Post-Install task from our K2000. I can give more detail on how the Managed Installs are setup, but was just curious if I am missing something really simple. Maybe you all can point me in the right direction.
Thanks!
Answers (2)
this is usually a very easy task. Import, assign to a SI/Image and you are fine.
What errors occur?
Which MI are affected?
What say the logs?
Best practices (and this saves the double work!) would be:
1. Install the KACE agent with SDA. Do not install or set anything else which is not nessesary (in my case there are the following tasks: install agent, (put into domain-I don't do this due to the needs of the env, but would do it in a MS AD env), add the WLAN-configs to the systems with WLAN card, disable UAC for admin users, set energy configs to the standard, set the autologin to 0 as last task)
2. create a label which contains new machines (I read out the timestamp of the setup file from the SDA and hold all machines with a timestamp <24h in this label)
3. bind all scripts, MI etc to this label
This eases the delivery since the SMA does what it can do best from the beginning.
Comments:
-
Thanks for the reply! The MI's affected are just commonly used applications like Chrome, FireFox, Adobe Reader, Office and LogMeIn. So if I'm understanding you correctly, you would advise just running those via the K1000 after deploying a scripted installation? - I3ig-A 3 years ago
-
yes, sind this saves you from reimporting all few weeks if you have a new version avaiable.
Especially since the SMA is designed for that.
(I fully understand the idea of making everything with the SDA but I went away from this idea 6 weeks after I had to update all software a 3rd time and at this time it was slightly more complicated, but the main issue was more or less: TIME needed, as of today too)
Nowadays I update the SI twice a year if a new Windows version comes out to replace the original one and at the same time I also replace the SMA agent. And since MS has the update rollups, I also don't need to use my ctupdate-script anymore (yes, I know it is nowadays known as wsus-offline (https://www.wsusoffline.net/ not affiliated with MS or needs a WSUS!) but when I seen the script first time in the C'T (a german computer magazine) I loved it and used it heavily.) - Nico_K 3 years ago-
Awesome, thanks for the insight. It's tempting, knowing the SDA can handle all of that, but I definitely see your point. I also like the idea of not having to update the SI very often. So I'll go the route of letting the SMA handle the deployment of applications. - I3ig-A 3 years ago
I would suggest you check the basics in your imported post install task, first make sure the package is valid, copy it off the SDA and make sure it is not corrupt. Also check the command line has not been changed in any way when it was imported.
As a final test, build a fresh post install task manually to see if it works.
My point being, at the moment with the SMA and SDA there seems to be loads of functionality that has “just worked” for years, basic 1.1 functionality that we have used, which now, for whatever reason just does not work and exporting MI’s and importing as post install tasks may be another example on an ever increasing list.
So check for corruption first and if all seems ok but it still fails, create the task manually and test again. If that works then we know that despite appearances the SMA or SDA is screwing up the transfer.
