/build/static/layout/Breadcrumb_cap_w.png

Practices for managing automatic deployment of software package (groups) to new systems?

Hello all,


I work for an EDU that has the K1000 and K2000 appliance.  We currently have a very diverse software stack that varies depending upon department, geographical location and a few other variables.

Historically, we have built monolithic, hardware dependent images that we captured and deployed via the ghost platform. 


We are in the process of moving over to hardware agnostic processes using the K2000 and K1000 which has worked very well for our smaller and baseline images.

We currently have a baseline image for Employee, Instructional and special use systems. After deploying one of these baseline images via the K2000 appliance a tech then installs the additional software needed for that area via the K1000.

It is on the road map to eliminate the process of having to manually add software after deployment but A lot of these areas have significant overlap and duplicates in between packages.  The main thing I'm trying to avoid is numerous hard references to the same software inventory package as that creates issues where things will fall out of parity.

My current thought process is that we may need to break things down granularity by labels.


Let's say that a lab needs the following packages.

- 7-Zip

- Notepad++

- Autodesk Suite

- Solidworks Suite.

- Misc apps that belong exclusively to the architecture department.


7-zip and Notepad++ are on all systems whereas Autodesk are only on some areas. I'm thinking I would want to create Labels bound to MI's that are structured similar to this.

- Software Bundle: Instructional - All

- Software Bundle:  Autodesk Suite

- Software Bundle: Solidworks Suite

- Software Bundle: Architecture Department


Thoughts?



0 Comments   [ + ] Show comments

Answers (1)

Posted by: akmagnum 5 years ago
Red Belt
0

I hope I'm understanding your question correctly.

taking your architecture department as an example.........

All machines have 7zip and notepad++........

Then for each software you want to add to the architecture dept automatically....

----I would create a  "Smart Label" for all machines in that department....(hoping they have something in common in their names or IP range)

     that do "NOT" contain the software with that name .

---Add this "Smart label" to the "managed install" software.

Do this fo all other software the architecture dept needs .

I assume you know how to create labels by using the advanced search in the inventory.

.................Example...............(do this for each software that needs to be deployed )


Search all computers with "Architecture" in their name (Or some ip range for the Architecture dept)....

"AND" computers that do not contain software name e.g "Autodesksuite".


Now add this label to the Autodesk Managed install .

So every time a machine from the architecture dept inventories to the k1000, it will

check to see if the machine does not have that software installed. If not.....it will install it.

Hope this helps








Comments:
  • Thanks, labels are the route I'm considering going, Ideally by LDAP heirarchy for most systems and manual labels for a small subset of machines that may have software with licensing restrictions that don't get deployed to the other machines in that group.

    We've however not used MI's in this manner before so I have a question about a hypothetical scenario.

    As you may know, the software inventory tends to generate a new entry with the version in the name whenever a new version if discovered. We've generally been uploading a package to the version specific entry but this requires manually moving over any references to it. I'm currently leaning towards creating a concurrent software inventory item for a package where I'll update the binaries and version # when we are supporting a new build of it.

    In this case, Would machines that have the MI assigned to it automatically run the script to install the updated version if the version property of the software package changes? - Kiyolaka 5 years ago
 
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