Cost

Software technology, like any technology, provides a means to solving problems.  Some big. Some small.  Some that help.  Some that hurt.  And as with all tools, they come with a price.  Some big.  Some small.  Some obvious.  Some obfuscated.

Let's itemize, shall we?

• Licensing
• Tracking
• Reporting
• Installing
• Customizing
• Consulting
• Updating
• Upgrading
• Reassigning
• Removing
• Supporting
• Training
• Managing
• Securing
• Hosting
• Deploying

Each of these breaks down into yet more costs.  Some obvious.  Some not so obvious.  And within the small slice of software technology that involves "customizing", it breaks down into an entire ecosystemical world of its own.

Let's itemize, shall we?

• Assessment (requirements)
• Analysis
• Functional Design
• Hierarchical Design
• Interface Design
• Role-Based Access Design
• Build
• Test
• Alpha
• Refine
• Redesign
• Refactor
• Beta
• Pilot
• Fit and Finish
• Release
• Update
• Upgrade
• Retire

Depending upon the nature of the application, any one of the first set can shift weight onto a different item.  For example: Managing.  Content Management Systems are a common example.  Some might lean more on consulting or training, such as SAP.  Some might lean more on securing, such as Internet-facing web services.

Ultimately, for every cost they solve, they add another cost elsewhere.  Just as the shift from classic typewriters to computer-based word processors saved costs in one place (typewriter supplies, repair costs, speed, physical storage), they added more in others (printers, networking, paper, ink and toner, disk storage).  Obviously, nothing is really "free".  That's not to say that the new costs equal the old costs.  But before you sign your name on a proposed shift in technology, make sure you know where the money will flow.  You might be surprised what you discover.

Read More

Making a Poor Man's Web Service

A "true" web service uses a robust and sophisticated structure.  Combining XML with SOAP and other goodies, you can unleash the power of the gods and melt down the entire Universe (or maybe just max out your NIC channel).  In any case, you can still achieve the same basic (repeat: Basic) capabilities using things like the old XmlHTTP object, or the .NET WebRequest object.

What for?

If you write scripts or do any programming, you may run into a situation where you would like to be able to pass a request to a web site via URL and get something back, without ever opening a web browser.

The old way, the "brute force" or "knuckle-dragging" way, was to open up the firehose and collect everything, the entire web page, into a bucket and sift through it. That is commonly called "screen scraping", but it's really just basic text or stream parsing.

With VBScript or KiXtart you can use the Microsoft.XmlHTTP object like this...

URL = "http://intranet.contoso.local/mypage.aspx"
Set objXmlHttp = CreateObject("Microsoft.XmlHttp")
objXmlHttp.Open "GET", URL, FALSE
objXmlHttp.Send ""
$result = objXmlHttp.ResponseText
Set objXmlHttp = Nothing

With PowerShell and .NET you can use the System.Net.WebClient object to do this.  Here is just one example...

$url = "http://intranet.contoso.local/mypage.aspx"

$wc = new-object System.Net.WebClient
$result = $wc.DownloadString($url)

Why bother?

The older you get, and the longer you work with programming, you eventually realize that you can leverage the power of existing structures without reinventing the wheel.  Let's say your best friend works in the web team and has a ASP, PHP, or ASP.NET web site that interacts with a database somewhere, maybe several.  Now let's say you're having lunch with this friend and you ask "hey, don't you have access to the hardware inventory system database?" and he puts down his sandwich and can of Red Bull and says "yes, why?"  "Oh nothing, it's just that I'd like to be able to query some information from it, but I can't wait for access approval from the DBA team."  After some more discussion you determine that the information you want isn't sensitive, but you don't really need to have the DBA folks setup a new DSN for you when your friend already has one for his apps.

Now your brain starts churning.  You think about all the pieces and what you can assemble.  What if your script, running on a remote desktop computer, could submit a query URL to a web page and get back some useful information for your script to continue on with?

What if you could fetch the computer name, or BIOS serial number, and pass that in like "http://intranet.local/computer.aspx?sn=ABC12345" and get back the Purchase Order (PO) number, and information about the warranty dates, service contract number, original owner, etc.?  Maybe your script could grab that, determine if the machine is still under contract support coverage, and go ahead and process an internal support request, or send an alert, based on some condition, all without ever popping up a form asking for user input?

$sn = "ABC12345"

$url = "http://intranet.contoso.local/computer.aspx?sn="+$sn

$filename = "c:\temp\filename.txt"
$wc = new-object System.Net.WebClient
$result = $wc.DownloadString($url)

# parse the contents of $result and do amazing things...

Get the picture?   Is this making sense yet?

You PowerShell nuts out there will obviously see where the above chunk of code can be refactored into a simpler form, but the point is what you can do with it.

This is ONLY ONE example.  Do not run with this and think I'm suggesting this is all it's good for.  There really is absolutely NO limit to where you can go with this.

As I say often:  Technological API's are like Lego building kits.  The more you have, the more you can do.

Ain't it awesome?

Read More

Gazoline or Vazoline

Gasoline sounds so American.  Gazoline sounds like a diabolical German scientist in a black-and-white suspense movie.  I'm not an expert on the subject of Petroleum, nor any of its refined downstream products (except for plastic, of which I use daily, har har), but I do play a petroleum expert on TV.  TV in my mind, that is.  This article is going to blow the minds of a few of my colleagues, who know me as anti-oil, but this should prove that I'm objective by nature and always have been.

And if I were a real bonafide expert on post-production petroleum permutations, I would offer the following insights into the aspects of Gasoline and our cultural perspectives upon it.  Myths be damned...

Myth: The indicators of gasoline price change are easy to predict

Wrong.  They don't exist.  What does exist is picking a reason du jour for blaming anything besides profit drive.  The truth is that of all the various excuses used by big oil, none have held up consistently.  Not oil prices, war, regional conflict, weather and natural disasters, political strife, exploration costs, refinement costs, transportation challenges, not even solar flares.

The biggest "oops!" moment came in 2008, when, at the lowest point in our economic collapse, Exxon-Mobil reported their biggest profits in history.  Not biggest revenues mind you, but biggest profits.

This was during the same week that one of the biggest page 2 stories around the nation was the report from NHTSA that highway traffic was at the lowest volume recorded in the previous twenty years.  Higher unemployment and higher gas prices meant fewer people driving around, it was said.  When asked how they could rake in such insanely-high profits, each of the big oil reps gave a completely different answer.  It seemed that they skipped their weekly golf outing and didn't have a chance to synchronize their stories.  In the end, big oil faded into the background without giving a cohesive explanation, the government panel gave up, and ultimately: nobody cared.  The best example of American determination is our short public attention span.

Conclusion: If you want to know why gas prices go up suddenly, just pick any reason, I'm sure it will stick.

Myth: It's unfair that oil companies can raise prices at will

Wrong.  Companies like Exxon/Mobil, Texaco, Chevron, BP, and so on are NOT social agencies.  They do not exist to support the betterment of society nor the noble efforts of the common worker struggling to make it to their office, their kids events, the bowling alley, the bar, and back home again.  They are what's known as A BUSINESS.  A "business" is defined as an entity that exists for the purpose of making profit.  Period.  Don't like it?  Ride a bicycle or buy an electric car.  Oh wait, there's none to choose from locally.  That's because all those years when the tree-huggers you laughed at were warning you that you'd be tied to Gas like Keith Richards to a heroin couch.  You ignored it and kept dumping your cash into big American-sized shit.  Pat yourself on the back.  Good job.

Myth: Oil companies are to blame for SUV's and 4x4 trucks with crappy mileage

This is the same bullshit argument used against Microsoft's supposed monopoly on operating systems.  No one forced you to buy a stupid, over-sized, difficult-to-park SUV.  Your ego forced it.  You had to keep up with your social circles and not be the only soccer mom without a white Escalade, Lexus or Tahoe.  You had complete control over what you purchased.  You chose poorly and now you want to blame the oil companies.  If you drive a Prius and despise the oafish driving habits of half-blind SUV owners, you still can't blame big oil. Blame the peroxide-blonde with the sunglasses on, carrying a toy poodle in to get groomed.

Myth: Government should step in to regulate gasoline prices

As much as my emotional side wants to agree with that, my rational side sees the downside of that.  Where do you draw the line?  What comes after that?  Hamburger prices?  Cable TV?  Condoms?  Chewing gum? Some people would call that a "slippery slope", but I call it a "lubricated slope".

The best solution?  Pursue alternatives.  I'm not saying to talk about alternatives, that does nothing.  Americans are all about talk, rarely taking action.  "Someday I'm going to lose weight"  Yeah.  And Elvis is coming back.  You want to break your weekly dependence on oil?  Buy an electric car, bicycle or just walk, or just STFU.

Myth:  Cutting back on gasoline use will break our dependence on OPEC and foreign oil

Wrong.  Not only does America import more oil from Canada than anyone else, keep in mind that each automobile tire consumes seven (7) gallons of oil to manufacture.  That's just the start. Now consider everything else that requires oil as an ingredient:  paint and coatings, lubricants (oil and grease), and all the massive amounts of plastics used in your car, your home, your phone, your computer, your TV, your glasses, your clothes, your shampoo and toothpaste, your combs and brushes, your appliances, your food packaging, your makeup, and more.

A pure-electric car would still consume a lot of oil to manufacture and still require more oil to keep it running.  We can't stop using oil.  It's as much a part of our lives as water and air.

Also, while a lot of people assume oil generates most of our electric power in the U.S., it doesn't even come close to coal.  Not even in the same ball park.  Coal is king.  Coal producers are not in the big oil game, they have their own game.

Cheers!

Read More

Software Repackaging: Why Bother?

If you already deal with repackaging, or deploying software, silently, unattendedly (new word, I called it first!), to mass numbers of massively anti-IT users, you can tune out on this one.  You already know the song.  Choir: meet Preacher.  I said I'd have something to blabber about and here it is.  I hope you enjoy it as much as I enjoyed the beer while typing it.

I've heard this from business folks, end users, neighbors, relatives, and my kids' friends: "So, do you just copy the the CD/DVD to a hard drive and install it on all the other computers from there?"  It's a fair question, coming from neophytes and non-technical folks.  But is that how it's done?

No.

It's not that simple.

I wish it were that simple.

I wish software vendors gave a flying shit about making our lives simpler.  Rather than caring only about sales and shareholder value.

I wish just TWO software vendors would work from the same playbook when it comes to what features they support for installing their products.  You know, like maybe Adobe, Autodesk, Microsoft, Oracle, Apple, Symantec, IBM, HP, Intuit, Siemens, you know, those little mom and pop shops like those.  Microsoft has tried to define some game rules, via Windows Installer, and platform guidelines, but even they don't eat the same dog food all the time.  Take a look at the installers for SQL Server, Office, Windows, RSAT, Configuration Manager, SharePoint, .NET and Silverlight.  It could be described as a school teacher telling kids not to do drugs, while meticulously packing the crackpipe and bringing the Butane lighter up to it slowly, all the while never breaking cadence with the DARE speech.  The kids are confused.  Do they follow the teacher?

No.

They prefer to reinvent the wheel.  Why?  Because reinventing wheels can be profitable.  Forget what your school teacher told you.  Forget what you've heard and read.  Reinventing wheels is not only profitable, but it is now the predominant business model for American industry.  Why do they reinvent wheels (translation: invent their own installation methods)?

The answer is:  Because most, I repeat: MOST, software vendors suck at making installations.  MOST of them do not even bother trying to make their software easy to install from a command line (a standard requirement for unattended deployments).  MOST of them do not bother with making it easy to preconfigure options and incorporate them during a silent installation.  MOST of them don't bother using a licensing or activation process that works consistently with other vendors.  MOST of them not only assume all of your users are local Administrators, but expect them to be.  MOST of them just SUCK.  Period.

Then I hear from the smaller vendors that they can't afford to adopt tools like AdminStudio, or InstallShield. They would rather use some rusty old version of INNO setup, or roll their dope-smoke, bong-water, shag carpet with crumbs and hair balls solution that they call an "installer".  Wow.  Some of them just make you want to take a dump and read a month old newspaper.

Try this on...

You come back from a cool conference or presentation and your head is bursting with all kinds of new information you can't wait to put into use.  Things like streamlining security settings, administrative tools and capabilities, automation and more automation.  You start locking things down.  You start cleaning house.

Then a bunch of the software the minions use starts breaking.

Then you start breaking out the tools to see what's broken so you can devise fixes for each of them.

You start making progress, but as you start construction fixes and trying to automate their deployment to the masses, you get more reports of broken things.  Soon you are fighting them off like the bugs in Starship Troopers.  You can either exhaust all your bullets, snacks, drinks, and forget getting any sleep, or retreat to a new defense line.  That's more common than you think.  So many IT shops have had to retreat and give up some security protections in order to mitigate the impact on the software applications that keep the business running.

After all, it's one thing to brag about how tight your security configuration is, but see how well that grin of yours holds up when Mr. CEO **SCREAMS** across the conference room at **YOU** that *YOUR* "awesome security changes" are breaking business operations, and managers are **SCREAMING** about downtime and lost productivity.  Now your cool efforts are costing money.  It feels like telling Don Corleone that you accidentally chopped off Michael's finger while opening a bottle of wine.  Yep.  Not good.

Guess what?  IT is almost always viewed by the suits as being a "Cost Center" as it is.  As soon as you cost them more, you're putting on a clown suit and singing "I'm a fucking dumbass, please beat me to death right now?!".

Don't know what a "Cost Center" is?  That's ok, you're an IT guy and probably didn't study those stuffy MBA books while cramming for your CS exam.  A "Cost Center" is the opposite of a "Revenue Center", which means that while everyone smiles and loves the cute little "Revenue Center" for bringing cash INTO the business, your "Cost Center" is the ugly pug-nosed, crack-whore that "COSTS" the business money.  Sales?  Revenue.  Marketing?  Revenue (indirectly).  Support? Revenue.  IT?  COST.

This is unfortunate, since with a little effort and careful strategy, you can make any IT operation appear to the suits as being a "Revenue Center", but most IT folks aren't focused on that side of the battlefield.  The secret is in the numbers.  Remember:  Numbers are to MBAs as bribes are to politicians.  You can say you are saving the business money, but you have to put that into numbers with pretty charts and slick reports.  Works every time.

I'm straying off topic here.  Can you tell?  That's ok. I'm going to circle back around soon.  Hang in there...

With all this crazy bongwater drinking going on with software vendors, and their team of monkeys cranking installers off like an over-caffeinated wack-a-mole session at Chuck-E-Cheese's, you have an assembly line of crap coming in one door.  Then you have labor costs going out the other door.  You have to close this gap between crap installers and IT labor related to installing it on your computers.

This is the crux of the problem.   Read the last sentence above again.  Never mind, I'm going to repeat it for you...

You have to close this gap between crap installers and IT labor related to installing it on your computers.

This is tantamount.  This is epic.  This is vital, not only for your business, but for the value proposition of your entire IT operation with respect to the microscope being focused on your CIO and down from the CFO and above.

At the very least, you cannot continue looking ineffective and haphazard.  Just because you think things are great and nobody complains that you still handle things like it's 1998 and Prince is topping the charts, doesn't mean the suits aren't talking about your habits at cocktail parties with the heads of IT consulting firms.  Maybe IT staffing firms.  In any case, a few smirks and contorted faces from hearing how you handle tasks is enough to trigger the MBA response: "Oh?  Well, how would YOU handle this differently?" To which the other party will say "Well, for starters..." and it goes on for 30 minutes of (translation:) "Here's why your current IT staff is a bunch of clowns who couldn't herd frozen dead cats with a bulldozer"

Don't be that guy.

Take some time to bundle up the crapware and make it dance like a pig with lipstick.  This is what we repackagers do.  It can be unglorified at times, but for the most part it's actually not bad work.  It can be interesting.  Challenging.  Perplexing.  It will make you smile and growl, laugh and cry.  It will make you want to pick up the phone, dial the vendor and tell them how fucked up they are, then slam the phone down and laugh like a mad scientist, spilling Red Bull all down your shirt and shaking like a heroin addict on Monday morning.

Caveates

There's always caveates.

If you support a dozen computers or less, this may not apply to you.  If all of your computers use the exact same software, you probably handle that with imaging (Ghost, MDT, etc.)  If you support computers that don't have human users touching them every day, you many not have issues like this either.

Here's a quick self-test:  If I handed you a disk and said to install it on EVERY computer in your organization, along with custom settings, a license key, and make it work regardless of the users not having local administrative rights, would it take you more than a single business day to complete the task?

If the answer is "yes", you might qualify for all this mess I discussed above.

Read More

Autodesk Revit 2012 and Configuration Manager 2007: Win7 vs XP

While packaging Autodesk Revit 2012 Architecture Suite for mass deployment (via Microsoft System Center Configuration Manager 2007 R3), I encountered a problem where Windows 7 clients installed just fine, but Windows XP SP3 clients did not.  The error was 1603 or 1619, but the client log did not indicate any more specifics.  I ran the installation  (deployment) manually (interactively) and it worked fine on both platforms, but through Configuration Manager 2007 R3 it would not successfully install on Windows XP SP3 clients.  At all.  Ever.

Until...

It's an old trick that sometimes works, and in this case it did:

Within the Package, under the Program properties settings, on the Environment tab, check the option...

"Allow users to interact with this program"

It now installs on Windows XP SP3 clients as well as Windows 7 clients.

Read More

Voting Time: Help Me Out?

I need to get a better view of how I should manage this blog if I'm going to keep at it. I'd like to know how you typically discover new posts:

A. Announced on Twitter
B. Announced on Google+
C. RSS subscription feed
D. Repost on another site
E. None. You just visit the site when you feel like it
F. Someone e-mails you a link
G. Announced on Facebook

G. Is just joking. I never post my blog updates on Facebook

Post a comment to share your vote. Thank you!

Read More

A Missing Link of Software Life-cycle Management, with Fries and a Coke

Software Life-cycle Management.  It's a term most often tossed around by drunk vendor reps at conferences and on the expo floor, when shoving brochures in your drunken face as you stagger through the gauntlet of fellow drunken attendees.

In basic, non-intoxicated terms, it refers to the overall management of a software product from the time it arrives in your mail room (or downloaded onto a storage device), through the preparation phase, testing and deployment phase, through the murky update and patch phase, to the upgrade phase and finally: the retirement phase.  It mirrors the human life cycle in some respects, but then again, anyone who's read a Chinese fortune cookie already knew that.  I'm such as genius.  I'm also on my third beer.  In any case...

There are some rather interesting twists in the cycle that can present challenges to modeling a logistical and procedural assembly line automation approach.  These are primarily focused on the naming aspects.  Rather than try to use a lot of multi-syllabic terms and pretend to be clever, I'll just spew it like a college plebe during rush week...

You get a disk with something called "Fubar 2012" made by "Snafu Corporation".  You dig into it and find out it uses a "setup.exe" bootstrap that runs an embedded .MSI installer package.  You manage to extract the .MSI and are able to ride that bitch like a Iraqi prisoner in Abu Ghraib on a Saturday night in the Summer of 2009.  I'm sorry, is it too early for Abu Ghraib jokes?  No disrespect intended.  Let me get back on the train of thought....   The .MSI is named "fb12.msi" and when you install it, it creates a program entry in the ARP list for "Snafu Fubar Enterprise 2012" version "2.12.01".

You pop open your Configuration Manager console and create a "New Package from Definition" and select the fb12.msi.  It reads the manifest and fills out the properties as follows:

Product: "Fubar Enterprise"
Version: 2.12.01
Publisher: "Snafu Corporation"

You modify the Program properties to suppress notifications and all the other usual mumbo-jumbo, add the first DP server, and it looks good.

Then you create a new Advertisement in Config Manager and name it (manually) "Fubar Enterprise 2012" and assign it to a Collection named "Fubar 2012".  You drop a test computer in the Collection and pull the trigger.

You look at the computer and sure enough, the installation is there, and shows up in the ARP list as "Snafu Fubar Enterprise 2012", version 2.12.01, by publisher "Snafu Corporation".

The Configuration Manager client (agent) runs a software inventory scan and reports back an ARP product named "Fubar Enterprise 2012".  The Software Products table receives the entry for the executable itself as "Fubar Enterprise", version 2.12.01, publisher "Snafu Corporation".

Now.  How does the inventory report intuitively "know" that this discovered product is directly associated with the Advertised Package?

It doesn't.

This is where third-party products step in, or, where developers step in (ok, ok, I'll be honest:  they stagger and stumble in) and create a tertiary associative relationship via some application magic.  This is sometimes referred to as creating a "tenuous link", meaning that it's a arbitrary, coerced relationship that must be manually (humanly) established and maintained.

Why does any of this matter?

That's a great question and I'm glad you asked.  I'm even glad that *I* asked on your behalf, and I'm glad to be glad that you might be glad that I'm glad.  Clear as mud?  Ok then.

The reason usually becomes clear when you work in a large enterprise environment, and you enter into a major project with lots of team players which include Project Managers and bean counters.  These sorts of people like to analyze numbers and costs.  They will see all these Advertisements and say "wow! you guys make a lot of packages!  That's awesome!"   Then they will see the inventory reports and say "wow! You guys deal with a lot of installed applications!" and then after few bong loads they will often ask the following question:

"How do you know how many of all these installed applications are installed by your packages?"

Dum-de-dum-dummmmmmm....

It goes way deeper than this of course.  You might already see where this is going (or could go).  I'm currently in a place where it not only "has gone there" but all the way to the other goal line.  We have to produce detailed metrics to assess package-to-install relationships, licensing aspects, upgrade and cost aspects, and .... AND.... match that up to distribution statistics (DP server status indicators) and directly on to installation metrics (successes, fails, waiting, etc.).  In other words: a Soup to Nuts, end-to-end monitoring and reporting system.

We have that now, all that and web-based.  And it lets us manage the process via the web without having to rely entirely on the MMC console apps.  Yes, it began from the seeds planted by Windows Web Admin, but it's as far evolved and removed from that as today's government is from George Washington's time.  I'm patting myself on the back, and I need to stop.  It's unhealthy to do that.  Hold on... I had to take another sip... ok.

Where was I?  Oh yeah.  It's 2012 and while many aspects of our ever-advancing technical world are evolving at a crazy pace, some smaller aspects are left hidden in the cracks.  And these smaller aspects matter.  They will matter even more as regulatory pressure, cost efficiency, and process automation priorities continue to rise.

Think about what parts of your own procedural environment are left to the thought processes of individual employees.  Think about how many intricate, yet vital, links in your automation workflow are not entirely automated.  Those are actually direct indicators of process inefficiencies.  Those are the things we absolutely have to focus on, double-down, and figure out how to formalize them into a conduit that can be automated.  The means of automation are not important.  The crucial aspect is that the process, and each process step or component, is well-defined, and therefore capable of being automated.

Tying up this small, but important, link in the chain of software management is just one example of many.  Think about all the "what-if's" that can play into this and toss a wrench in to crash it like a broken space shuttle.  What about home-grown applications?  What about proxy applications (remember those?  I discussed those earlier and mention them in my book)?  Those are the applications that really don't exist, but we give them names out of convenience and familiarity.  Humans are great a filling in these missing links with our minds.  But our minds are transient.  Business needs to be non-transient in order to survive.  And I need another beer.   Cheers!

P.S. - by the way, that nifty graphic in the first paragraph was created by me using PowerPoint 2010 in precisely 3 minutes, after consuming three glasses of ice-cold Belgian Tripple Ale.  You can do it too.

Read More

Rant No. 42

I'm not on Adam Carolla's level, by any means, but I still have some things that piss me off enough to want to express my frustrations every now and then.  It's also been way too long since my last official rant, so here goes...

Driver's Licenses

It's way too easy to get a license these days.  They're cheap.  The test is simple enough for monkey to pass, even after a case of beer.  The penalties for fucking up are rather minimal (tickets for running stop signs, speeding, and wandering over lanes are relatively cheap).  Even if you happen to screw up enough times to lose your insurance coverage, there are dozens of cheap insurance companies running ads on TV all day and night that will gladly cover you for a few bucks.

The net result?  Nobody gives a shit if they drive like shit.

There's no value in the privilege of driving anymore.  Twenty or thirty years ago, it took a lot longer to get a license because most parents back then didn't hand you a car on your 16th birthday.  You had to (get this, you won't believe me...) SAVE YOUR OWN MONEY to buy one.  My parents were fortunate enough to help me out, but they still made me go shop around and find the right (used) car on my own, which was an incredibly valuable lesson.

Consider this for a moment.  Read it through before you roll your eyes and imagine what it "could" mean:

What if it cost $500 or $1,000 to apply for a driver's license?  Not to be granted one, but just to take the test.  And if you failed the test, you had to pay another $100 for each retake.  I'm not done.

What if you were allowed (3) driving infractions in (5) years before having it suspended for a full year?  I'm talking about things like speeding, running stop signs and red lights, driving wrecklessly, or my personal favorite: tailgating.

Remember that old lesson your grandparents taught you about the value of something earned?  If you're given an expensive toy, you won't protect and maintain it as diligently as if you had to work, save and purchase it yourself?  Ever get pissed off at how people treat YOUR stuff that YOU paid for, but they somehow think is THEIRS to mess with?  Ever had shithead room mates?  Oh yeah, you know what I'm talking about now.  The asswipe that ate the food and drank the beer that you paid for and carried home.

It's the same for anything.  Give someone something and they'll appreciated it, but not as intensely as when they sacrifice themselves to earn it.  It's just basic human nature.

I say:

1. Make license tests MUCH more expensive
2. Make the license tests more difficult to pass
3. Make it much easier to lose your license privileges

The problem with this, of course, is that industry is against it entirely.  There have been legislative efforts in the past to raise the driving age, make the tests more difficult, and make them more expensive, but auto manufacturers and dealers cry foul that it hurts sales, and oil companies whine that it hurts gasoline sales.  Then there's the advocates for the poor, who argue that higher costs favor the wealthy, but most of them ride the bus anyway, so fuck em.  And regardless, it's fewer asswipes on the road and endangering the rest of us who try to get from "A" to "B" safely every day.

I have more rants coming.  Just wait.  I'm just warming up.

Read More

Time to Give Props

With the ever-expanding volume and breadth of information on the Internet today, it's easy to focus on my own thoughts, experiences, ideas, etc.  But I need to give credit to some very worthy people, who's blogs I read daily (RSS feeds are awesome!).  While I'm nowhere near as widely followed as these folks are, I can still shine a light for those that haven't yet discovered their work.  Please check them out as often as you can...

Jimmy Bergmark - JTB World

Jimmy's site covers a lot of topics surrounding the world of Autodesk technologies, as well as FlexLM and FlexNet management.  Tips, tricks, articles, and detailed discussions of a wide range of topics.

Rod Trent - MyITForum

Rod's site is a community actually.  It benefits from a large collective of brilliant people that cover a wide range of Microsoft-oriented infrastructure management.  From System Center products, to Windows Server, to scripting and more.

Johan Arwidmark - Deployment Research

Johan, and his colleague Mikael Nystrom, are two of the most renown people in the world of Windows operating system provisioning.  They focus most on MDT (Microsoft Deployment Toolkit), Configuration Manager OSD, but also on WAIK and advanced tools and topics like DISM, IMAGEX, and much more.  If you work with imaging and desktop/server deployments, you ABSOLUTELY need to check out these guys.

Ralph Grabowski - UpFront E-Zine / WorldCAD Access

For years, Ralph has done an amazing job of delving into the technical and business sides of the engineering and design software world.  He balances both with incredible skill, and without leaving either side in the cold.  One of the most beneficial aspects of his work is that he doesn't favor one vendor or one business model, but strives to remain objective and provide an unbiased view, even when tossing in his own thoughts at the very end.  If you work with CAD/CAM/CAE products or services, you need to read his stuff.

Joe Wilcox - BetaNews

Joe has been around the technology journalism world for a long time.  He has been at BetaNews for a few years and already made his mark with hard-edged articles on current topics that inspire a lot of discussion and debate.  Whether you like the products or vendors he writes about, or not, you will be entertained and enlightened by his writing I'm sure.

Scott Hanselman - Blog

While some might dismiss Scott's work due to being a Microsoft employee, you'd be sadly mistaken and cheating yourself out of some fantastic articles and incredible ideas surrounding software development trends.  Indeed, most of his topics reach far beyond Microsoft or Windows platform issues.  If you like programming in any capacity, check out his blog and see for yourself.

Daniel Petri - Blog

Daniel's site has been around for years, and has grown and amassed an incredible library of articles on almost everything related to Microsoft products, Cisco, Citrix, and VMware, among others.  More recently, he has enlisted more guest writers to help fill out the content and the results are amazing.  If you haven't visited the site, you should.

AppDeploy

If you do ANY work with automating the installation of software, like I do every day, this is a MUST web site to bookmark.  In particular, check out the Package KB library.  Even though it was acquired by Kace, and then by Dell, it's maintained it's original purpose and quality.  I highly recommend it.

I may follow-up with more links in case I forgot any (I'm sure I did).

Read More

The Next Milestone

I finally got word that the project I've been supporting will end February 24th.  I'm not sure what I'll do with respect to putting this sick dog down, again, or when.  So I thought I'd put this up for a vote:

If I get at least 10 responses in favor of keeping this blog active, I will heed the call.  Otherwise, I will set a tentative retirement date of February 25th.

Once again, thank you to everyone who has taken time to read my stuff and provide feedback.  I wish I could make it more focused and relevant to the needs of more people, but alas, I didn't go to journalism school (and wasn't blessed with a particularly sharp brain), but I pretend it pretty well I suppose.  In any case.  I will watch and see what the voting reveals.

Read More

Choosing the Right Data Repository

All you mental freaks out there likely saw "repository" and thought "suppository", but that's ok.  Settle down.  It's not the weekend yet.

This article cooked up in my thimble-sized brain after a string of events at my office.  The issues all circled around having islands of data sitting around in various places, inside of various "containers" and in various formats and structures.  The data in one particular case involves inventory.  But inventory is a big, fat, drippy, soggy bag of goo that has different meanings and different values to a lot of people circled around it like kids at a campfire.  Some want numbers.  Some want names and labels.  Some want locations.  Some want state values (indicators of current status or changes of state).  Some want derivatives, like contract data, support metrics, and other secondary and tertiary cost drivers.

If you put a microphone up to each of these people and ask them where all this data should reside, you will very likely hear a wide variety of answers:

• Spreadsheets
• Database Tables
• XML files
• Visio Drawings
• AutoCAD Drawings
• Compound Documents (Word documents with embedded spreadsheets, etc.)
• Web-enabled reports (web services providers)
• Paper print-outs

And the list goes on and on.

So... who is correct?

As it turns out, when you're in the midst of sifting through what bucket fits the most needs of the most people, it's difficult to see the end of the path in the fog of new requirements.  Until you've met with everyone involved, and discussed what they (a) think they need and (b) what they REALLY need, it's near impossible to avoid choosing the wrong container.  I've been in this business for over twenty-five years and I've seen the smartest MBA, PhD, and senior brains screw it up.  It's hard not to.  The reasons are a-plenty...

1. You can't predict future needs
2. You can't predict future project priorties
3. Sizing the storage requirements is challenging
4. Placing the storage provider is challenging
5. Avoiding proprietary "lock-in" can be challenging

In general, here's what I usually try to follow...

1. Strive for version independence.  Avoid storing in a product where version changes often cause upgrade issues for consumer applications and services.  ADO and ADO.NET (ODBC, OLEDB) are fairly version-agnostic.  Meaning that if you move the tables from SQL 2008 R2 to SQL 2012 there's much less chance of having to recode applications to change the connection endpoint compared with storing in Microsoft Access, Excel or even AutoCAD drawings.
2. Find a "platform-neutral" provider medium.  Client applications are always off the table unless there isn't a choice.  It has to be a "server" application or service.  It has to provide robust access to everyone that needs it, with the least overhead, and the least performance drag.  If every consumer of the data has to have a proprietary application installed in order to access it, you're taking a risky, and often costly direction.  This is why databases are most often preferred, since they offer up access in the most neutral ways and the widest range of applications and uses.
3. Take your time!  Don't let anxious users pressure you into making a quick decision rather than a correct decision.  Just because the floor plan folks want everything in AutoCAD in time to meet their looming deadline doesn't mean that a month later, five times as many users will scream for access to the data via a web services provider medium, or an XML table.
4. Try to leverage what you already have.  If you have Oracle, use it.  If you have SQL Server, use it.  If you have an intranet server with web services enabled, use it.  Try to not build new bridges when others exist unless you can't possibly make do with what you have. Reinventing the wheel is dumb.
5. Enlist an objective team.   Gather folks from your database group, your applications development group, management group, finance group, any group that might even be remotely impacted by what you're trying to accomplish.  You'd be amazed what you can learn from people you didn't think had any interest or involvement in what you'r doing.  Many times they've been down the same road before and can offer valuable insight and advice.  Take it!  Learn from it.  It's ok to meet with the direct consumers, but if you surround yourself with only them, you will be going forward semi-blind.
6. Get metrics!  Don't ever base a purchase decision or a project direction on input from test users that don't back it up with hard numbers.  It's not that you can't trust them (sometimes you can't), but it's that without numbers, there's no way to objectively compare and analysis what's going on.  For example:  I was involved with a project to establish a central data repository for a variety of applications over assorted quality WAN links.  Three of the locations complained about performance problems and pushed HARD to go with another alternative.  It turned out to be a network link configuration problem at the router, and once it was addressed, the performance was perfectly fine.  Had this not been investigated, the alternative project direction would have delayed the entire project for four more months and added 50% more cost.  Metrics are king.

Even if the majority of the consumer-end users are clamoring for going with a platform that fits squarely within their operational environment, try to avoid a knee-jerk response.  I've seen too many projects that followed that direction and everyone realized later that they should have started with something more generic or "external" to their own needs.  The reasons are often tied to extending logical links to other data sources to leverage more powerful automation uses.  

For example, the sales department chose Excel spreadsheets to store all their static tables of rates and tiers for various services and products.  The engineering team would like to link to that in order to improve material and cost estimation, but the spreadsheets are on a server that doesn't allow access to the engineering department.  Furthermore, when they decide to move their spreadsheets to a SharePoint intranet, they realize the format and layout of the data is difficult to use for external linking.  Had they chosen an XML file posted on an intranet server, or used a robust Database host, the data would have been format and layout agnostic and more easily accessible to users without distributed and varied layers of security (NTFS, shares, groups, application-specific formatting, etc.)

All I'm saying is that you need to be cautious and take your time making a decision on where to store data that will be used by a lot of different roles throughout your organization.  It's kind of like placing a watering hole in a vast desert.  Those that are too far will suffer before they can reach it.  Those that show up with buckets that won't fit into the Well are going to suffer too.  Choose the location and configuration wisely.

Read More

Software Deployment Basic Basics: Uninstalls

In my book "Grinding Gears" I discuss the various aspects of performing forensic analysis to support the repackaging of software for unattended, mass distribution.  I also discuss how this plays into performing unattended, mass UN-installations.  Here's the basic basics of where to look and what to do...

Add or Remove Programs / Registry

The list of applications that you see in "Add or Remove Programs" (ARP) is defined in the Registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, and for 64-bit clients it also spills over into HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall. Scan through all the entries, named and GUID labels as well.  Those that have a "DisplayName" value, are what you should see in the ARP list.  When you find the products you're looking to remove, note the "UninstallString" value and move on to the next one.  For "msiexec.exe" values, be sure to replace "/I" with "/X" (or lower case "/x", it doesn't really matter).

Sometimes you'll find references to .EXE files, as well as those which perform bootstrap setups and uninstalls (Autodesk 2009 and later products are well known for this).  In other words, you'll find the product listed multiple times.  Once with the product name, and another (or several) with a corresponding GUID.  Many vendors, Autodesk included, provide documented guidelines for automating removal of their products, which can be very useful.

Other places to look are HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE\SOFTWARE\Classes (aliased) and HKEY_USERS\.DEFAULT.

Files and Folders

The nature of most modern installer utilities is that they will only uninstall what they originally installed.  Basically, the uninstall routine reads a manifest of what was installed, checks to see if it is the identical object, and then removes it.  If the object (file, folder) is new, or has been modified since the installation was completed, it will typically leave it behind.  That means that the folder in which the file resides cannot be removed either.  This is why you often need to do a little extra work to automate a truly "clean" uninstall package.  There are many ways to do this, but one of the most effective ways is to use a script wrapper.

It is important that you always use the vendor-provided uninstall mechanism first, and then follow behind with any required clean-up tasks.  NEVER, I repeat NEVER just delete files and folders without running the appropriate uninstall mechanism first.  Otherwise you may end up with a lot more junk strewn about the computer than you realize.

Hooks and Handles

One of the most common reasons that files and folders cannot be deleted during an uninstall operation is that which I described above.  But the other common reason is that a service or process has one of the files opened "in use" at the time of the uninstall.  If the vendor uninstall mechanism doesn't properly stop related services or terminate related processes, the files will be blocked from deletion.  If you can diagnose relevant services and processes, you can incorporate the appropriate termination commands to allow for a clean uninstall.  The most common commands for this are SC.exe and TASKKILL.exe, but you can also use Sysinternals' "PSSERVICE.exe" and "PSKILL.exe".

Sloppy Work

Many small-time development shops either cannot afford to implement proper packaging tools and processes, or simply don't care.  It's just a fact of life and economics.

Many will build their own ad hoc installer utilities, or give you a .ZIP file to extract and do your own heavy-lifting (moving files, registering DLL and OCX components, adding registry keys, running scripts, making shortcuts), which sucks ass, but again: they can't (or won't) do it for you.  Sad that it's 2012 and this is still not uncommon.

Many will give you an installation package, but the uninstall aspects were forgotten or released untested.  This too can make it a suck-ass experience to mop up behind.

If a vendor hands you a soggy bag of crappy software, you still have an option:  Repackage it.  If you have InstallShield or AdminStudio, you can repackage their crap into a shiny new installer package.  In most cases, you can make an .MSI but if there are prerequisite/redistributable dependencies you might prefer a bundled "SETUP.exe" package.  Either way, you get a cleaner installation package with a reliable ARP interface and the ability to do a clean uninstall as well.  In fact, if you spend a little time with uninstall testing you can incorporate some "Custom Action" tasks into the package to do your own cleanup work without the need for scripting.

Per-User

While most things are fine with "per machine" installation and removal, there are times when you need to seek out items under each user context and delete them.  Files, folders, and Registry keys are most common.  There are several ways to hit this...

• Build a package to delete items on a per-user context and deploy to each user using a per-user advertisement.
• Use a login script
• Use Group Policy Preferences
• Use ActiveSetup packages

Each of these is a world unto its own, so I won't dive into them here, but there's plenty you can find via a Google search that should help point you in the right direction.

Summary

While many products are well packaged for enterprise deployments, many more are not.  This is why so many IT professionals spend so much time shoe-horning applications for mass deployment and mass removal.  The more work you put in "up front" the less you will have to put in later.

Read More

Repackaging Quiz

This is another brief snippet from the quiz/exam/test we use for screening applicants.  Enjoy...

1. Name as many ways as you can think of to repackage a software installation.
2. Explain the differences between repackaging via "snapshot" and "monitoring"
3. Describe as many things as you can that get left behind from a typical uninstall
4. MSIEXEC:  
1. What does /I do?  /X ?
2. What's the difference between /QB and /QN?
3. Which will install for all users?  ALLUSERS=1, ALLUSERS=2
5. What things can be complicated by users not having elevated permissions?
6. What things can be adjusted without elevating user permissions globally?
7. One user can launch an application successfully.  Another cannot.  What questions do you ask?
8. Describe a "layer zero" installation versus "layer one" or "layer two". What products could be involved with each?
9. Describe how Application Virtualization generally works (high-level)
10. List some common prerequisites for many common software products.
11. An Administrator can launch an application, but a non-Administrator user on the same computer cannot. What techniques and tools would you use to diagnose this most effectively?
12. In your own words: what is a DLL?
13. Where is the User Profile folder root on XP, and Windows 7?
14. Where is the Program Files installation root on 32-bit and 64-bit clients?
15. Where is the ARP list in the Registry?  (32-bit and 64-bit clients)

Read More

Blog Status Update

Those of you that read this blog are probably aware I had planned on retiring it back in December, and then fired it back up to help someone with an ongoing beta test project.  That project is still ongoing but will wrap up in a few weeks I'm told.  At that point, barring any monetary offers (I can joke around here), it will most likely mean this will still be retired.  I appreciate the support and feedback from you and I'm glad if I can help you in some way, or just provide meager entertainment value.  In any case, my time is getting more and more squeezed and time for blogging (worse yet, coming up with ideas to blog about) is getting tougher.  I will keep you posted when I know more.  Until then: enjoy the mindless rants and gibberish. :)

Read More

A Basic Package Scripting Exercise

The following is an excerpt from a screening exercise we use to evaluate potential candidates for positions involving software repackaging and deployment.  There's much more to the screening and evaluation, so this is just a sampling.  After looking it over, read my comment at the end.

BEGIN


Exercise 1 - Installation

Create a script (using template A, below) to install a product named "Fubar 2012" using the vendor-provided "fubar12.msi" file.  This installation will be deployed with Configuration Manager 2007, which will use the local SYSTEM account to perform all tasks, unattended, regardless of a (human) user being logged on or not.

Your script will need to perform the following tasks:

• The installation needs to specify the USERNAME property as "IT Services" and the COMPANYNAME property as "Contoso Corporation" during the installation.
• The .MSI installation should create a log file named "cvb_fubar2012.log" in the TEMP folder.  It is important to NOT hard-code the path to the "temp" folder, but use a Windows environment variable instead.
• After the .MSI installation, the script needs to copy a shortcut file named "Fubar 2012.lnk" from the script source directory down to the "All Users" Start Menu, under "Programs\Fubar 2012".  Keep in mind that this will need to work for Windows XP and Windows 7 installations.
• Download a license file named "license.dat" from the script source directory into the application installation folder:   "%ProgramFiles%\Fubar 2012\bin"
• Create a new Registry value under the application registry key path: HKLM\SOFTWARE\FUBAR\2012\Options, named "CheckForUpdates", with a REG_DWORD value of 0 (zero).
• Adjust folder permissions on the installation folder: "C:\Program Files\Fubar 2012" to allow members of the group "Contoso\Domain Users" to have "Change" (modify) permissions

Important:  Remember that when deploying scripts and packages with products like Configuration Manager, you cannot be certain as to where the package will be deployed from.  The deployment system manages the distribution of packages to a network of "Distribution Point" servers.  Therefore, it is important that you never assume the script source path, but use a self-referencing path variable instead, such as "%~dp0" or "%~dps0", etc.

Exercise 2 - Uninstall

You will use a separate script (using template B, below) to uninstall Fubar 2012.   After inspecting the Registry, you determine that the application stores the uninstall reference under the GUID:  {00001111-3ABC-DEFG-1234-0123456789AB}

Your script will need to perform the following tasks:

• Execute a silent uninstall of the .MSI package using the GUID (above), making sure to suppress a restart afterwards
• Handle the scenario when script is run on a client that does not have the application installed (exit / abort gracefully)
• Remove leftover folder and files: "C:\Program Files\Fubar 2012"
• Remove leftover registry keys: "HKLM\SOFTWARE\Fubar"
• Remove the Start Menu shortcut and the sub-folder it was added to (for Windows XP and Windows 7 installations)

Comment:

After fielding this to a long list of candidates, so far, not one has passed with flying colors.  Not one.  This is considered by most packagers to be a "basic level" test.  The best we've come to expect is determining how close to "correct" each candidate is and use that to determine how much (if any) training is required to close the gaps in their skills.

I have to say I'm extremely disappointed in the results our search for candidates within the United States.  We have listings on multiple services, web sites, Facebook, Google+ and Twitter and applicants are just not there.  If the job didn't require on site working in Virginia we'd focus on searching overseas.  I'm still holding out hope.

The other parts we evaluate include working with AdminStudio, InstallShield, troubleshooting file and folder permissions, registry permissions, managing services and processes, user context issues, System Center Configuration Manager (packages, programs, advertisements, collections, status monitoring, troubleshooting, client management, etc.).  After this we evaluate the candidate based on communication skills, professional attitude, courtesy, and so on.  If they don't root for one of our favorite football teams they're definitely eliminated (just kidding).

Template A

@echo off
rem ****************************************************************
rem  Filename..: install.cmd
rem  Author....:  (replace with your name)
rem  Date......: 01/18/2011
rem  Purpose...: install application name
rem ****************************************************************
CLS
SETLOCAL
SET APPNAME=ApplicationName
SET LOG=%TMP%\CVB_%APPNAME%_install.log
echo %DATE% %TIME% installing... %APPNAME%... >%LOG%
echo %DATE% %TIME% source....... %~dp0 >>%LOG%
echo %DATE% %TIME% target....... %COMPUTERNAME% >>%LOG%
echo %DATE% %TIME% windir....... %WINDIR% >>%LOG%
echo %DATE% %TIME% progfiles.... %PROGRAMFILES% >>%LOG%
echo %DATE% %TIME% temp......... %TMP% >>%LOG%
echo ----------------------------------------------- >>%LOG%
rem     perform MSI installation here
rem     echo result to log file
rem     handle failure of MSI installation here (exit/abort)
rem     copy shortcut file to start menu
rem     copy license data file
rem     create registry value
rem     echo result to log file
rem     adjust folder permissions
echo ----------------------------------------------- >>%LOG%
rem     echo exit code to log file
ENDLOCAL
rem     return final exit code here

Template B

@echo off
rem ****************************************************************
rem  Filename..: uninstall.cmd
rem  Author....:  (replace with your name)
rem  Date......: 01/18/2011
rem  Purpose...: uninstall application name
rem ****************************************************************
CLS
SETLOCAL
SET APPNAME=ApplicationName
SET LOG=%TMP%\CVB_%APPNAME%_uninstall.log
echo %DATE% %TIME% installing... %APPNAME%... >%LOG%
echo %DATE% %TIME% source....... %~dp0 >>%LOG%
echo %DATE% %TIME% target....... %COMPUTERNAME% >>%LOG%
echo %DATE% %TIME% windir....... %WINDIR% >>%LOG%
echo %DATE% %TIME% progfiles.... %PROGRAMFILES% >>%LOG%
echo %DATE% %TIME% temp......... %TMP% >>%LOG%
echo ----------------------------------------------- >>%LOG%
rem    perform MSI uninstall here
rem    echo result to log file
rem    handle failure of MSI installation here (exit/abort)
rem    remove shortcut file and app folder from start menu
rem    check for leftover files and folders, remove them if found
rem    remove leftover registry key path
rem    echo result to log file
echo ----------------------------------------------- >>%LOG%
rem     echo exit code to log file
ENDLOCAL
rem    return final exit code here

Read More

Amazon vs Nook vs Me

About once a month I get an e-mail about why I don't publish my books on the Barnes & Noble Nook platform (ePUB format).   The reason is simple: SALES.

I have about a half-dozen books published on the Amazon Kindle platform.  The basis was derived by publishing the same book on both Kindle and Nook and watching the numbers.  To be fair, I included Google as well.  The book was "The Visual LISP Developer's Bible, 2011 Edition".  That was in 2010.  As of February 2012, none have sold on Google, and I've sold a total of 2 copies for the Nook.  Two.  Compare that with 172 for Kindle.  The choice was (is) clear for me.  I'd say it is a "no brainer" actually.

So please, do not ask me to publish on Nook.  It does add time and effort to publish to different formats (they are not the same at all) and each publisher mandates their own policies and tools to contend with.  Amazon is by far the clear winner in the general e-book publishing realm.  Nobody else comes close.  The market numbers are very clear on that, as well as the tiny slice of numbers I see from my own experience.  I am not John Gresham, or Dan Brown.  I have a day job and four kids at home.  It's surprising to me that I have had the time to crank out even one book, let alone six or seven, and I'm not sure I can do any more.  I just don't have the time and it's not really a major source of income.

Please don't ask for a PDF version either.  That's the same as giving it away FREE.  I'm not about FREE anymore.  My time isn't free, as I'm sure your's isn't either.

If you don't own a Kindle, there's still hope:  Use Amazon's FREE online Kindle "Cloud Reader" or one of their FREE reader apps for iOS, Android, Windows, Mac, Blackberry and whatever else.

Read More

Repackaging: Application Deployment Types

It might seem odd to say "what kinds of software" with respect to "repackaging", but there are some very important distinctions.

Deployment-Ready Applications

A "Deployment-Ready" application is one that supports silent installation as well as command-line customization options without the need for additional work or tools.  These are, by far, the best and simplest types of applications to deploy to the masses (aside from deploying shortcuts for web applications).  These are usually .MSI packages, however some .EXE installers will do this as well.

Just as important however is that they also provide a silent UN-install capability.  However, due to the nature of journalized or manifest-oriented installation technologies (like Windows Installer), items which are added or modified after the initial installation are typically left behind after an uninstall.  This is where it helps to wrap uninstalls in script code to handle additional clean-up tasks.

The few situations that require additional work usually involve adjusting security permissions on files, folders and registry keys, but this can be handled easily.  Options include script wrapping and Microsoft Application Compatibility Toolkit (ACT) shims.

Transform Applications

A "transform" application is a logical layer of customization added to an existing .MSI package.  These are relatively easy to build and deploy, and only (very) slightly more work than a Deployment-Ready application.  You can use tools like Wise Package Studio (soon to be defunct), Flexera InstallShield, or the ancient Microsoft utility: Orca.  The net result is a .MST file which contains additional objects and properties that combine with the base .MSI during the installation process.

What a Transform won't do:  Allow you to bundle security modifications to files, folders and registry keys.  For that you either need to repackage again, or use a script wrapper.

Client-Sever Applications

The term "client-server" is pretty old, but in this context I'm referring client-side applications which require specific configuration or activation tasks to be performed on the server-side in order to make the two work together.  This may involve one of the other mentioned application types (deployment-ready, transform, proxy) along with additional tasks to make it all work seamlessly for the end result: an unattended deployment.

Proxy Applications

A "proxy" application is one that (don't laugh) doesn't really exist.  Many of you are probably familiar with this situation/scenario, but just in case, let me explain...

The word "proxy" means "to authority or power to act for another" (Merriam-Webster).  In more contemporary terms (incorporating the long-standing use of such things as "proxy servers"), I would say it's more broadly defined as "an effective substitute".  That's just me and I'm obviously not an English professor.

In many business environments, users tend to apply labels to things based on what the eventual use is, or will be.  For example, you might have a Microsoft Access database with VBA code, forms and reports built in, and this "application" is used to order parts for a particular project or program called "TARFU".  When you have a discussion with any of the users, they will almost certainly call it the "TARFU app", not the "Access database app for TARFU".  So when you are asked to deploy it to users, they will expect to see a desktop (or start menu) shortcut named "TARFU" or something similar.

That's one example, but not really the one I have in mind.

Sometimes the application "TARFU" isn't really an application at all, but rather, a collection of files and components that are required in order to access and utilize a particular web site used for tasks related to "TARFU".  Or, not to wear out the references to Access, maybe it's just the Microsoft Access Runtime with an accompanying database file.  In either case, you would wrap all the necessary pieces up and give them a name.  But what about the listing in "Add or Remove Programs" (ARP)?  What about seeding the installation targets with the required things to support inventory collection and reporting?  How will you identify the installation targets months later?

For example: If you deploy the Access Runtime and a database file, you won't likely see anything called "TARFU" in your inventory reports.

The solution is simple: wrap it with a new name.  The best choice for this would be to repackage it into a new .MSI and force the labeling as "TARFU".  This would not only create the necessary ARP entry, but solve the challenge of inventory reporting and, just as important, support an easy uninstall capability.

Complicating Factors

There are many potential complicating factors that can cloud the simplicity of a deployment. These are the buzz kills of software deployment.  The party poopers.  Among them are...

• Device driver installation and post-configuration
• Special activation tasks
• Per-user installation tasks that need to be applied to all users
• Removing previous versions of the same application before installing the new version
• Importing settings from a previous version into the new version
• Stopping services or processes at specific points during the installation
• Dealing with unusual COM and USB port interfaces
• Seeding files in order to pre-configure security permissions

It can be challenging, both in a good way and in ways that make you scream in anger and throw things.  I've seen packagers call vendors on the phone and vent their anger directly at them.  That's probably the most therapeutic and productive (the vendor gets a taste of what their customers don't like).

What Does This All Mean?

Keep in mind that I never promised to make a point here.  I'm just making broad brush strokes over a very intricate and convoluted artful science.  Ultimate however, what this could be summed up as, is to say that whichever of these types you're handed will generally dictate the level of effort, and hence the time, required to complete the deployment.  And this is what drives most Project Managers completely insane.

Read More

Book Sales Update / What Readers Want

Based on my subjectively constrained statistical analysis, it seems that the focus of AutoCAD readers are still more interested in Visual LISP most of all.  The second most demanded subject is deploying AutoCAD and managing it on a network.  Granted, I am fully aware that I don't have anywhere near the recognition or sales power of people like Ellen Finkelstein, George Omura, or Sham Tickoo.  If they were considered culinary chefs I would be more like a busboy, but that's ok.  I'm just happy to be here.

For those of you that have purchased or borrowed (yes, Amazon Prime members can check out my books for free), all I can say is....

THANK YOU!!!

As always, if you're interested in any of my books, check out my Amazon profile page for more information.

Read More