/build/static/layout/Breadcrumb_cap_w.png

Customizing .MST transforms for vendor released .MSI - Best Practices?

Let me use Java JRE 7.40 as an example. I am using the vendor bits,  offline installer MSI for java 7.40. I have created an .mst transform to apply settings for what my company wants to use in the property tables(updates off, hidden systray, etc).

I was wondering what best practice other people and companies have defined in their orginizations or businesses for  naming, descriptive info, or MST settings different folks have developed. Like naming, info, any descriptive fields or properties related to a mst for tracking or setting audit reg keys , etc?

 

Any examples would be awesome, simple or complex.

Ive been searching the forums here , havnt found an area for this - if there is one - a link or advise on how to search/find this.

 

thank you

Asked 11 years ago 1817 views
5 Comments   [ + ] Show comments
  • Maybe this one can help, works for Update 40 as well.

    http://www.itninja.com/blog/view/java-7-update-25-best-way-to-deploy-with-customized-settings - tecrumors 11 years ago
    • Nice walkthough, this is very similar to how I have done this. Thank you.

      My qestion here is more related to developing a best practice to naming or documenting transforms and how people like to do that. - indierox 11 years ago
  • I do most of my naming / info in the notes are of my SCCM deployment and also the notes of the AD group the service desk use.
    For example I may leave a note in AD saying ‘requires a reboot’ or ‘64bit only’ - accesser 11 years ago
    • good feedback , thank you - indierox 11 years ago
  • As for naming, most clients I've worked with have used a prefix for stuff which gets added, like features, components and properties, as well as descriptive names but it depends very much on the client.

    Invariably, there will also be either a document or a ReadMe.TXT that goes alongside the package for support Johnnies to refer to, so that they can see what's been added, removed, edited, whatever. - anonymous_9363 11 years ago
  • I have my readme documentation for the Johnnies. So you have named the package according to client requests? Have you done any notating or custom changes or vendor/client names in the actual transform itself? When I say this, I mean no programs settings, but just info properties, or maybe custom ARP info, etc? I know its bad practice to alter the vendor bits in most all cases, but it seems a transform would be a good place to add additional msi table information for your actual client or company using the custom transform , while leaving the source vendor bits untouched.

    thank you - indierox 11 years ago
  • When I create an MST, I use the same name as the MSI, unless the name of the MSI is more than 25 or 30 letters; then I just use the company name or something short. If I need to create more than one transform, I'll name it something that identifies its unique reason for existence (EastCoast.mst or R&D.MST) I'll also add any configuration files or reg keys so the install delivers everything they need so the Johnnies don't need to touch the machine to make any tweaks. The subdirectory structure I create is the primary method for identifying what application you're looking at; Z:\Packages\Widget\2.5\01\

    In every MST, I add a "signature key" (HKLM\SOFTWARE\{Client Name}\{Product Name}{Version} with some metadata such as install date, source location, name of MST, who created the package, etc. All of these keys are variables so I just have to import the REG file and not edit anything. This helps in troubleshooting and also helps to figure out if the authorized package was used or if someone did the install outside of the normal, supported process. I also add the Properties ALLUSERS and REBOOT to the packages.

    I've been lucky in that I'm usually part of a Windows migration project and the client doesn't have any packaging experience. I become the person giving training on the packaging process, then sticking around to manage the packaging effort. I keep it simple so we don't have to have unnecessary documentation for an install that really boils down to "Next, Next, Finish" - vjaneczko 11 years ago
    • Very good, thank you. - indierox 11 years ago
    • Agreed vjaneczko! I do pretty much this as well (I work for an integrator). Always name the MSI and MST the same thing unless not suitable, then I go [Vendor] [Product] [Version] - [Business Unit] and I also create the folder structure under config manager "vendor\product - product version\package revision\structure" where structure is "distribution, development, documentation, source" and this contains the package history. The Documentation is usually an RTF (so it can be opened on the SCCM server) and contains what was done inside that transform etc). Will also contain a suitable item for the ConfigMgr application detection clause. Usually the product code or signature key as above.

      Agree with the signature key stuff as above as well. Client always says "your java package wants to update! fix it!" and it turns out the user has installed it from the web :/ this is where signature keys are handy

      Something else I tend to do is remove launch conditions, because your SOE should contain pre-requisites etc from the testing. I also try and do MSI's so they can be tracked by the applications engine in config manager 2012.

      Cheers!!! - warped_foobie 11 years ago
      • very helpful warped, I think I'll implement some of this practice - indierox 11 years ago

Answers (0)

Be the first to answer this question

 
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