Before I get into the CubMakr tool, for those who are unfamiliar with ICE (Internal Consistency Evaluator) Validation, let me explain. You likely already know that a Windows Installer File (MSI) is actually a database, if you open it up with an MSI Editor such as InstED or Orca, you will see it contains multiple tables. Well, ICE Validation is a concept where by, you analyze your MSI tables for compliance with standards and best practices. You do this by using a CUB file which is basically an algorithm containing logic to check against each row in each table within an MSI. If the validation finds something which is against Best Practice say; MSILockPermissionsEx and LockPermissions being used in the same MSI, it will flag this as an issue with an explanation and in most cases a link to a knowledge base with more information.
Throughout my short career, I have worked in companies in which we tended to create our own custom CUB files, which would not only check the Industry best Practices, but would also check for specific configurations in an MSI which we set as our own Best Practices. It offers a great aide to Packagers during the Packaging Process, as well as to any others doing Quality Assurance work on a package. The Errors or warnings themselves appear within the packaging tools window, in plain sight and easy to read, you can also save these as a text file and keep with your QA information to show that validation was carried out and what the results were. You can double click on the message of any error or warning, this will bring you to the erroneous entry in whatever table the issue was flagged in. It’s very useful to create your own custom CUB files, but to me at least, it has always been a bit of a pain in the neck. It required a lot very manual effort, there’s a few different methods you can use, for more on these take a look HERE , HERE and HERE. But none are easier than CubMakr. Simply put this tool turns what’s typically a few hours work, into a few minutes. Go ahead, look at the links I provided, you’ll see there’s a lot of manual effort and testing required to setup rules using traditional methods. Not with CubMakr, it’s a great tool! Read on for my own break down of the app but also check out the information on the creators website:HERE
The tool is web based. You can register online HERE , The site appears to allow you to create one Client. So I went ahead and created my own client , let’s say I named it Rorymon, Created my own Project RMCUB and also named my CUB RMCUB, all of this information is for naming purposes and consistency, you will browse to these later, no big deal. You can also choose to duplicate a template CUB provided by the site which contains some ‘out of the box’ ICE rules and work on top of that. Once you’ve got your info populated you’re ready to create your CUB files rules.
Here you select whatever you just created in the drop down menus at the top of this page. Now all that’s left is setting your rules, so what might you want to validate with your Custom ICE Validation CUB file? Maybe you want to set certain properties in your applications, for example ALLUSERS=1, well you can validate that. I created some custom rules to validate about 9 custom properties which I like to set in my applications for tracking purposes, I use an Application Database (I import all of my info from MSI’s into a central database), so I can query all applications with a certain property set…for example: Application Owner= Rorymon…I can then query All applications in my database which are owned by Rorymon. Which I really want to validate, I want to ensure this is set correctly in every application. I want this because, next time I need to migrate my applications to another Operating System, maybe Windows, when I rationalizing my application portfolio, I may need to contact the application owner…Well what if the Application Owner left the company? Well, I also set the Cost Center or Department that person works in as properties…having these properties set in a database is a great advantage for these kinds of efforts. And an automated validation of these properties is a huge benefit to ensure these are set for each package! Ensuring you’ve got an accurate and detailed account of all of your applications contents and metadata.
In the above screenshot you can see a simple example of validating the existence and value of a property. This one being ALLUSERS=1 which I mentioned above. It really is that simple. I had taken screenshots of different rules that I had created but it’s one of those times when I figured what I took the screenshots of, doesn’t actually add any usefulness, as the creators have really good examples which you can follow for creating your own rules. Just follow the same examples that I used, you can find these HERE
The page for creating the rules has a drop down box. This drop down contains the different tables which can exist in an MSI. So it’s as simple as picking which table you want to validate the information in. E.g. Maybe you set a custom action in all your apps, you can validate to ensure this exists in every app your packagers output. Maybe you set a Launch Condition to stop the applications from being installed on an older Operating System, well…pick that table and then go to work.
Once you select the table you want a drop down just below the drop down populated with the different tables, dynamically gets populated with the different column headers for that table. The above example shows the different columns which are typically found in the CustomAction table. If you are not familiar with MSI and the above makes no sense, I would advise you to simply open an MSI in InstEd or Orca when creating your Rules, you can just browse to the tables to check out where the data you want to validate exists.
Next you can select the type of query you use for the value you’d like to validate. Nothing too complicated here. The textfield can then contain the value you would like to validate. Perhaps you’d like to validate that a certain value is set in every app like ALLUSERS=1, enter 1 in the textfield. You can next select the Resolve Properties checkbox…
Then select Finish the Search to stop the search for the value, if you it could exist in a different table, you may want to match a second column. Next check the radio button for do nothing, this means if ALLUSERS is set to 1, an error will not appear when validation is complete..UNLESS the value is not set to 1. So you are validating against an expected, known value here. You can also query for properties which may contain a known value which you want to flag as an error, for example if you use template project files which contain placeholder values, you can search the place holder value, if it’s set prompt with a message (more on this below) that a valid value must be set or whatever you would like, or maybe even just ensure properties are not left blank.
Finally, you can provide your own explanation message for example: “Ensure ALLUSERS is set to 1 or”, You can select the Message Type, if it should appear as a Warning, Info, Error etc. If you use Installshield for packaging, this determines the icon which will appear beside the message. Be it a Red icon with a white X or the Yellow Warning icon… And of course Condition which can be used for to ensure to only flag an issue if the application is let’s say, just for Windows 7.
When ready, click Add Rule. At any time you can click Save CUB to save your work and also you can click Generate CUB which will prompt you for a save location and a name for the file, of course ensure the extension is left as .cub. I also advise to provide version control in the name, for example RMCUB102013. As you may make changes in the future, it’s a good idea to ensure the CUB file is updated each time you update your packaging standards. Actually one of the properties I set in my template files is usually TemplateVer, which I can then ensure my Cub file used by all packagers will validate the template version they are using. If they are using the incorrect Template, it will prompt them to ensure they package using with the most current.
Upon adding a rule you will see the rule appear at the bottom of the screen, you can click to Edit the rule at any time. You can also click Clear All Rules, if you’d like to start from scratch.
I know my site is very Application Virtualization heavy, but even so, not everything can be virtualized still and so I find myself still doing quite a bit of MSI packaging in my day to day work. I have also been responsible for creating company Packaging Standards and Procedure documents in all of my jobs. I was lucky enough to have help with creating the custom CUB files when with a previous employer, but at one time this help told me it would be weeks until they were available again so I had to tackle it myself, it was a frustrating and manual task involving scripting and testing out multiple scenarios over and over again. With CubMakr, it’s even easier than writing a SQL query, the tables and columns in these tables are all pre-populated, the site has provided a bunch of great examples to work off of. All in a nice friendly user interface with no need to go digging around. I plan to continue to use this tool into the future for any validation requirements I have. Actually on a side note as another reason why this is great. Flexera released something called ACE rules, which encapsulate the standard ICE validation rules but also provide a somewhat similar interfact to CubMakr, only in my opinion, it’s not as user friendly or powerful. You still need to dig around a bit before writing your queries.
Well, my problem with ACE rules thus far has been that you need to import your MSI’s into the application manager tool just to run the rules. I’m not perfect, sometimes I think I’ve fixed something but then realize I didn’t set it to the right value, so I then need to re-import the app again after I believe I have fixed the problem…then I find out it’s still showing with an error? That sucks! Maybe it’s because I’m a creature of habit but I like ICE validation, I like seeing the issue within the packaging tool, I like that I can browse to the table and find the erroneous item highlighted for me. In 11.5SP2, the ACE rules show up in the body of a text file, which you need to scroll through to find! I have been informed in the latest version these appear in a proper report but even still, that means going into a separate tool and going back and forth to make any amendments, as well as re-importing the MSI each time I think I have resolved the problems. Anyways, kind of a rant at the end there, I’m just trying to show that I still highly value ICE validation and really appreciate this tool, If you work with MSI’s, I strongly advise you to give this a look.