2 Replies Latest reply on Sep 26, 2014 5:46 AM by mgeertsen

    Procedure for archiving a package




      We are thinking about doing a thorough clean-up of our CORE server to get rid of stuff that are no longer in use or outdated.


      I've via SQL identified which packages we have that are currently not assigned to a task in any way (preliminary, main or final) and would like to establish a procedure for archiving those packages before deleting them so I have them as a backup in case they're still needed in near future.


      The initial thought of what I'd like to end up with is having the package exported to a folder as an .ldms file with all it's settings as well as all the files (primary file and any eventual additional files) in the correct folder structure. This could then be zipped for easy storage.


      Depending on the complexity of the package, this could be anything from a 2 minutes job to a hour long job per package if the package contains a lot of additional files from multiple separate folders. Knowing that this potentially needs to be done for several hundreds of packages, this could be a very time consuming task.


      Does anybody have a better idea or perhaps a (semi)automated way of archiving a package? I'm aware of package.porter.exe but that doesn't work for individual packages.


      Thanks in advance.



        • 1. Re: Procedure for archiving a package
          Tanner Lindsay SupportEmployee

          If you are looking for a way to move the packages out of the console entirely, instead of into some kind of "archive" folder in the LDMS console, then this sounds like a valid option. Especially getting the supporting files and folder structure. Unfortunately I'm not familiar with an automated way to do this.


          There might be a slightly different approach you could take going forward to help reduce this work later. I'm not sure how many packages you have or what they look like (especially the ones you are trying to archive) but one way to reduce work like this is to maintain only "current version" packages. For example, instead of having an Adobe Reader 10.1 package, you have an Adobe Reader Current package. Anytime a new version or update is approved in your environment, you would update the single package. That means any future deployments would be the most current version and reduces any confusion about what version to send out. Additionally, if you use Provisioning, you can add the "current" variant of the necessary packages so that all machines that are imaged get deployed with the most up-to-date versions of software. Bundles would work the same way.


          Using a system/process like that could reduce the number of packages you have to keep track of or archive later. Instead of Adobe 10.1, 10.2 and any other versions, you have a single package. If you wanted to keep the files archived, then zipping them up like you describe would work well.


          Not sure how much this helps, as you might already have this in place or I might be missing something, but I hope it helps you (or someone)

          1 of 1 people found this helpful
          • 2. Re: Procedure for archiving a package

            Thank you for your comment, tanner - good post.


            I'm talking about moving the package completely out of the console so it doesn't exist there anymore.


            I'm thinking about developing a quick script with AutoIT that can analyze the exported .ldms file for the package to collect the files used for the package and zip them together. That still leaves a bit of manual work behind in regards to deleting the package from the CORE, but that's the easy part.