going from Altiris 6.9 to Kace
I'm moving from Altiris to Kace. But how do I resolve these challenges. I do a lot of "post image tasks" after imaging, and some tasks are conditional on the computer name prefix. Maybe that's not the best way to do it.
Kace client is 32k-bit. So for example calling reg.exe in a .bat script will be 32-bit.
No hierarchical folders for computers or scripts. (Wish I could drag and drop too.)
No way to script a reboot action and wait for the action to finish.
Answers (2)
If you're looking to replace altiris 6.9 you may want to look into leveraging the K2000 for imaging as post-imaging tasks can be flagged as requiring a reboot which the k2000 will gracefully facilitate. As for the conditional tasks, I'm currently in the same boat and trying to determine the most scalable method for doing this. It will likely involve software collections and labels. I'm currently unsure how i want to do the label targeting whether heirarchal Active Directory OU based targeting for the majority of the packages.
Comments:
-
No K2000. - jszabo 6 years ago
We made that transition about five years ago, here are some tips I can share:
Conditional Tasks - Use smart labels for these. You create smart labels in the device inventory based on given criteria. When computers run their inventory the label will be applied if the machine meets the criteria.
32bit client - Use the /reg:64 flag to import keys into the 64bit area of the registry.
https://ss64.com/nt/reg.html
Folders for devices and scripts - This is a hard one to lose, especially the folders for scripts. A robust naming scheme for your scripts is the best advice I can give. As for devices, labels can be nested, so that does help, i.e. We have a label hierarchy for our computer labs, building, lab.
Scripts that require reboot - The script scheduling in the SMA is not as robust as Altiris, that is true. I really miss being able to schedule a script to run tomorrow morning at 5:00am. Surviving restarts is also an issue. There is at least one post on UserVoice for that functionality (https://kace.uservoice.com/forums/82699-sma-k1000/suggestions/16829452-add-a-reboot-in-the-middle-of-a-script) and there are probably more.
Some other helpful advice...
Brush up on your SQL skills. If you don't have any, then start learning or get someone on your team to learn. The appliance is much more powerful if you can create queries, this applies to complicated smart labels and other parts of the appliance.
If you aren't using the service desk, remember that it can still be used to automate tasks. Here is an example of adding data from the device inventory to the associated asset: https://www.itninja.com/question/is-sql-query-for-data-field-possible
Comments:
-
I was thinking of having a zip file with the 64-bit cmd.exe or 64-bit powershell.exe, with a script and dependent files, so that the current directory is right as well. A lot of scripts I run have dependent files.
I know powershell, wmi, and sql pretty well, and we have an mdt server. - jszabo 6 years ago -
I'm very interested in how you've organized these nested labels as I'm currently trying to build out something similar for software package deployment. Could you please provide me with an example of this structure, how they are applied to systems and how they are interlink? - Kiyolaka 6 years ago
-
Nesting labels is done through label groups. We have a top level group named "Labs and Classrooms". For buildings that have multiple labs we create a label for that building and place it in the "Labs and Classrooms" group. Labels are then created for individual labs and they are placed in the appropriate building label group, or directly into the Labs and Classrooms group.
Most of these are applied manually, although some are applied via smart label. Our naming scheme for lab systems is buildingroom-number, so the first computer in Bosler Hall, Room 209 would be bos209-01. A smart label could be created that applies the "Bosler 209" label to any computer that begins with bos209-.
The Bosler 209 label is added to the "Bosler Labs" label group, which is in the "Labs and Classrooms" label group. As a result, when in the inventory, I can click on All Items, Labels, Labs and Classrooms, Bosler, Bosler 209. - chucksteel 6 years ago-
Wow! That's pretty similar to our naming schema. Ours is SITE-BLDG-Room-Station. This sounds exactly like the sort of schema I'm currently looking towards but having a difficult time engineering out and visualizing. Would it be at all possible that you could please demonstrate the label/software hierarchy of two different labs in a tree fashion showing how the packages are bundled and then linked to the label that contains endpoint systems? - Kiyolaka 6 years ago
-
We don't have a label hierarchy for software, so I'm not sure how to describe or visualize a label/software hierarchy. I think that you might be making it more complicated than it needs to be.
We create managed installs for almost all of our supported software. When you create a managed install on the SMA you can target systems individually or via label (in the Deploy section of the MI). If one of the labs that I support needs to have SPSS installed, then I edit the managed install and add my lab's label to the list. Other technicians (and our main line Helpdesk staff) can do the same.
Does that answer your question? - chucksteel 6 years ago -
I believe so. Are you nesting the MI bundles? The The software environment at my school is pretty diverse so I'm trying to divide up and nest packages in order to avoid overlap and having multiple hard references to a software package. We've not really leveraged MI's to this extent previously though.
What I'm trying to do is discovery on our installed software, discern which are installed in what areas and then break up the software pacakges into nested groups.
E.G.
- Instructional Software Baseline.
- Math Software Baseline
- Math ( Campus)
- Room / device specific packages.
If I'm properly planning this, what I think I would want to do is binding similar to this.
MIs for software packages that get installed onto all systems.
- Device label named "Software Deployment: District"
- Nested underneath this would be the two labels that contain all Instructional and Employee windows systems.
MIs for software packages that get installed onto all Instructional systems.
- Device label named "Software Deployment: Instructional"
- Nested underneath this would be the label that contain all Instructional windows systems.
MIs for software packages that get deployed to all Math department systems.
- Device label named "Software Deployment: Math Dept"
- Label that contains all math department PC's (either done via CIR or nesting room labels within)
ETC down to the campus/room level.
I am however wondering if this is over complicated as you say and - Kiyolaka 6 years ago -
First off, each MI should be tied to one particular piece of software (Office 365 is the only exception I can think of). It helps if you think of a Managed Install as a piece of software.
Based on what you describe I would recommend something like this:
"Software Deployment: District" label. Apply this label to the managed installs for your standard software. Then apply the same label to all of the computers that need this software. So you will end up with a label that is applied to both MIs, and computers. Any computers with that label will get the software needed for that function.
"Software Deployment: Instructional" label. Same deal as above, there's no need for a nested label. When a computer needs software that falls into this "category" then it gets the label applied and the SMA handles the rest.
With regards to targeting departments, keep in mind that you can use LDAP labels to label computers based on their location in Active Directory (if you have AD, of course). Our OU structure for lab computers is similar to our label structure, so it makes it easy for us to label all of the lab systems based on that. Employee systems are placed in OUs based on department, so I can easily target all of the employee computers in the Math department based on that label.
We do use labels like this to create "bundles" in our environment, but I don't think of them that way. For instance, we package all of the Adobe CC apps separately, but all of the MIs for the 2018 versions have the "Adobe CC 2018" label, so if a computer needs all of the suite, you don't need to add them to each MI, just slap the "Adobe CC 2018" label on the computer and KACE handles the rest. - chucksteel 6 years ago
