The nexus of this article is derived from helping my company screen and interview potential candidates for various IT consulting jobs around our area (Hampton Roads, Virginia). The process has been daunting, to say the least. Not because it is difficult to screen or interview, it's not. Entertaining and interesting are two words that sum up that exercise actually (interviews are particularly entertaining at times). The daunting part is finding good candidates.
After months of wrangling and let-downs (we are very careful and discerning about who we hire, after all), we decided it might be worthwhile to find a "junior-level" candidate and train them ourselves. In most scenarios, this wouldn't be cost effective for a small consulting firm to consider such an idea, but our contracts are making it worthwhile and we have a reputation to uphold, so it may indeed be cost effective in our case.
The other nexus is that this might be part of a forthcoming book, but that's not for certain yet. You tell me: is this worthy of a book subject?
The Crux
During a recent interview to fill a software repackaging position, the candidate responded to my questions aimed at determining what he/she knows about the fine art of repackaging software. I asked the usual questions about msiexec, setup.exe, silent installs, uninstall methods, logging, upgrades, and patches. I realized that my line of questioning was following a similar pattern used in previous interviews so it dawned on me that it might be smart to at least try and document it. When the candidate asked me "what's the difference between packaging and repackaging" I knew I had to do this.
What is Packaging and Repackaging?
Software Packaging is basically the process of bundling software into a cohesive installation for others to be able to install it more easily. Software Repackaging is basically taking a mix of packaged and unpacked software (or any ratio in between) and making a new, customized, installation. Most software packaging you'll find is in places where they write original software products and sell or share them (shareware, retail, freeware, open source, etc.). Think of Microsoft, Symantec, Adobe, Autodesk, and Apple, to name a few. Most software repackaging you'll find is in places that typically "use" those packaged products, but need to customize them for their own needs. Corporate customer environments are the most common places to find this, since they have the budget and resources to staff an operation to devote to the value-added process of customizing software installations. Small shops do it as well, but to a much lesser extent, and with smaller budgets, often cannot afford to purchase expensive products like InstallShield AdminStudio.
What do you need to know?
It is vital (repeat: VITAL) that you understand what a "silent installation" is, and what it is used for. Don't forget to have an appreciation of a "silent uninstall" as well.
It helps to have some familiarity (ok, a STRONG familiarity) with how the msiexec.exe feature works. It is important to understand all the available command-line parameters like "/qb" or "/quiet" and "/norestart" among all the others, and what each of them does. Not just "/i" for installations, but "/x" for uninstalls, and "/update" for applying .msp patch updates, or "/f" for repairs, or "TRANSFORMS=" for applying .mst transformations.
It is important that you understand how "legacy" InstallShield [setup.exe] installations work, and how to use the various "switches" to perform custom actions, such as the -r switch to capture an unattend answer file, as well as the /s (silent) and /f (script file) switches, for performing unattended "silent" installations. It's also helpful to know how older versions of InstallScript handle switches as compared with newer versions.
It's important that you understand basic software forensics: How to determine what is installed, what versions, where the installation paths are, what components are placed where (folders and files), what registry keys and values are added or modified, and what services (and processes) are created and activated. Be able to diagnose what an installation does to the state of a computer, before installation, after installation, and after being uninstalled. You need to be able to determine what gets left behind from an installation so you can determine how to properly clean up behind it.
You need to understand, CLEARLY, what user context is, and what it means for both installing software and using it. What things can be modified under "limited" user rights, and what requires elevated or special permissions. If you understand how to effectively use Microsoft Application Compatibility Toolkit (ACT), you should have a strong understanding of this already.
Scripting knowledge is enormously helpful, but really necessary. It can help with understand basic logic and decision processing (if this is true, then do that, etc.)
Understand what things a software product installation CAN do to a given computer:
- Creates folders and files
- Creates registry keys and values
- Registers DLL components
- Registers .NET assemblies
- Creates new Windows Services
- Modifies built-in Windows Services
- Modifies security permissions on folders or files
- Modifies security permissions on registry keys
- Creates Start Menu program groups and shortcuts
- Creates Desktop program groups or shortcuts
- Adds WMI namespaces and classes
- Adds local user accounts or groups
- Modifies local groups
- Installs device drivers
- Modifies Windows Firewall exceptions
- Creates or modifies ODBC or OLEDB data sources
Some environments do not place much (or any) value or weight on some of these aspects. Some place an extremely high value on some of them. Few place a high value on all of them. BUT - it always helps to at least understand these aspects, and how to probe and manage each of these.
What's the End Game?
What exactly is the goal here? What is the desired end result for all this effort? The goal is to automate a tedious task to the point of being almost ignored. Let's face it, walking around to 50, 500, 5000, or 50,000 computers and inserting a DVD to install Microsoft Office 2010, or AutoCAD 2012 (ok, multiple DVD's), is not very cost effective. Most IT workers would jump in front of a speeding bus before getting half-way through the list. Most IT folks know this, so I'm preaching to the choir I know. But for folks with only a passing involvement with IT stuff this might be a revelation. Automation is king. Automation is how you squash one pest and have time for more interesting/important things.
What does repackaging do for automation? It allows you to configure options BEFORE you install the products. It lets you install the products silently, without any required input or button clicking. It lets you control how your log files are created, where they're created and when.
- Want to install Office 2010 without InfoPath or OneNote? No problem.
- Want to install AutoCAD 2012 with pre-configured FlexLM server lists? Easy.
- Want to install Firefox so it doesn't check for updates automatically? Piece of cake.
- Want to create a folder, copy a bunch of files into it, modify the permissions on the folder, add some registry keys, set some registry values, create shortcuts, add some ODBC settings, create a service and reboot the computer at the end of it all? Not a problem.
Or... you could sit down at each computer and do it manually. If you'd rather do it manually, as a rule, not as the exception, I cannot help you. You need to be sent to another planet where the creatures find that to be a logical view.
What You're Given
The biggest part of repackaging is dealing with what you have to work with. By that, I mean what the vendor provides for installation. They might provide a nice, simple, MSI package file. They might provide a MSI with an associated CAB file (or several). They might provide a setup.exe that supports making an answer file using setup.exe -r and might work with /s /f to use the answer file to execute a silent installation. It might be a .ZIP or .7z, file that simply needs to be extracted into a specific location. Maybe it's a Microsoft One-Click installer. Maybe it has an ACT "shim" that needs to be installed afterwards. Maybe it it's a .MSP patch file, the vendor provides a .MST transform.
Some vendors, like Autodesk and Adobe, provide dedicated tools for building silent installation packages. Some provide built-in functionality such as how the Office 2010 administrative install process works, and the building of the .MSP and a custom .XML manifest.
Then there's the shitheads. The idiot rubes that make crappy installers that support neither silent installations nor customization. For those sticks-and-mud piles of dung, you often end up doing a knuckle dragging "snapshot" or "capture" process to build a new installer package from the delta analysis.
The Tools
- Sysinternals (Microsoft) - ProcMon, ProcExp, PSList, AutoRuns
- Orca - an age-old MSI editor utility, also decent for making transforms
- InstallShield - The de facto standard of packaging and repackaging products
- Wise Package Studio - Once a great product, now gradually decaying in the abandoned field of neglected products acquired by Symantec
- SC.exe and PSService
- CACLS/XCACLS - modify permissions on files and folders
- REGINI - modify permissions on registry keys, the old-fashioned way
- Scripting - easy/effective/free way to bundle multiple tasks into a single "package"
- SMSTrace32 - legacy (and nice) log viewer utility
- Virtual Machines - Vmware Workstation, Hyper-V, or anything that supports "snapshots" or the means to save point-in-time state captures which can be reverted to at any time. If it doesn't support snapshots, DO NOT USE IT (yes, this means you: Virtual PC).
The Rub
The rub here is that hardly anyone considers themselves a "packager", much less a "repackager". 99.999% of people I know that invest serious time in this stuff do not call themselves anything close to it. Most go by the titles of "Systems Administrator", or "Systems Engineer" or "IT Manager" or "Programmer". They're still aiming for the same admirable goal: save time and headache by investing the work up front, to save 10x the work later. There are a lot of available software packaging jobs around the U.S. I know, because I get calls and emails every week asking if I want to apply, or if I know anyone else. Talking to recruiters it's obvious that there's a major shortage of this skill set in the U.S., which usually means employers will soon seek out foreign labor or outsource the work overseas. Like a lot of jobs that aren't big-name titles on TV ads for tech schools, the demand is outpacing the supply, and businesses will be forced to fill those jobs with whoever steps up to the plate.
Still Interested? Live in the area? :)
3 comments:
Best description of a (re)packager I've seen. My job is (re)packaging software, but it isn't quite recognised as the skiled job It should be. People don't seem to understand why software isn't always simple to deploy in a big organisation. They always compare with: "Well it's simple to install at home, so why not here?" Too bad I'm not in your area, I would have applied for a job.
Thank you! And if it's any consolation (and you're not happy where you are now) just about every IT recruiter across the U.S. is searching for "package engineers", which it sounds like you qualify for.
Most of us "Package Engineers" do more than just that. I think the most correct title is "Systems Management Administrator." Most of the delivery systems for enterprise software are part of a larger management software suite. Personally, I've used Zenworks, Altiris and for the last 6 years have run Computer Associates IT Client Manager.
And yes, I'm a long time VBScript expert, powershell, python and even C# are in my vocabulary. What's different about us? Normal "Administrators" are content to do one thing at a time, clicking on buttons. Where Systems M. Admins excel is in the area of automation. We want to do it a hundred thousand at a time, and perfectly every time. ;)
Post a Comment