Showing posts with label software deployment. Show all posts
Showing posts with label software deployment. Show all posts

Wednesday, August 20, 2014

My New Book is Out! The AutoCAD 2015 Network Administrator's Bible

"The AutoCAD 2015 Network Administrator's Bible" covers everything from new features and requirements, to building Network Deployment Shares, to deploying with Scripts, Microsoft Deployment Toolkit 2013, and System Center Configuration Manager 2012. 

There are also tips for working with VMware Workstation as a test environment,  handling .NET dependencies on Windows 7 and Windows 8, and slip-streaming updates and service packs during deployments.


I hope you like it. Please post feedback on the Amazon site to share your thoughts after checking it out? I'd really like to hear from you.

Cheers!

Sunday, August 17, 2014

Coming Soon: The AutoCAD 2015 Network Administrator's Bible

It's long overdue.  I'm long overdue as well.  It's been a long time since I've devoted myself to writing anything about AutoCAD or network deployments.  I'm almost done with editing this book and it should be available for purchase on Amazon Kindle very soon.  Remember that you do not need a Kindle device to read Kindle books.  There are free Kindle reader apps for iOS, Android, Windows, Mac, and more.

Here's a summary of topics included:

  • Deploying with Scripts: Batch, VBScript, and PowerShell
  • Deploying with System Center Configuration Manager 2012
  • Deploying with MDT 2013
  • Using Task Sequences
  • Dealing with Requirements: .NET 3.5, using Global Conditions, etc.
  • ADNM
  • Deployment Shares
  • Network and Client Logs
  • Building a Virtual Test Environment with VMware Workstation
  • Stupid jokes.  Dumb comments.  Awkward silences.
  • And more!

Sunday, May 4, 2014

Windows 7 Desktop to Windows 8 Tablet Migrations: With Fries, a Drink and a Xanax

One of my clients is in the midst of a mildly-frustrating migration to change from a like-for-like computer hardware refresh project, to one that inserts the added dimension (or dimentia) of offering users the option to purchase Windows 8 tablets.

The basics of the environment are this:

  • Active Directory (Windows Server 2012)
  • Windows 7 SP1 Enterprise 32-bit on 99.99% of the desktops and laptops
  • Office 2010, IE8 on most everything, but some smattering of IE11 and Google Chrome
  • Almost no Windows 8 production computers
  • Roughly 1400 distinct software applications
  • Roughly 6000 desktops / laptops / users
All of the Windows 8 tablet devices are configured with Windows 8.1 64-bit edition.  They will also come with Office 2013, IE11, Google Chrome 30-something, and a handful of other staple apps for various doo-hickey things (VLC Player, Adobe Reader, etc.)

Of the approximate 1400 software products in the production environment, roughly 40% are big-name vendors (Adobe, Microsoft, Oracle, etc.).  Another 40% are from lesser-known vendors, but still have a real "support center" you can call into, somewhere.  The last 20% are what some might call "garageware".  Those are the kinds of one-off products which are (more often than expected) "must-have" tools for various department functions.  Those are also quite often duct-taped together by a "vendor" who answers the phone while trying to scoot their noisy cat away from the food dish sitting beside their keyboard.

But all of this is just backdrop to the real issues...

While the bigger headaches with XP-to-Win7 migrations circled around UAC challenges, the newer challenges are less dramatic, but no less serious.  Some of the key aspects to consider when reviewing a given software product for use on a tablet device (I'm just picking on Windows 8, but it could be any tablet OS actually), are these things:
  1. Does the application sport a UI that is easy to use on a tablet? (i.e. the "UX" aspects)
  2. Does the application work well with kinds of touch input "gestures" that a tablet provides?
  3. Does the vendor give a shit about tablets, or Windows 8 for that matter?
Go ahead and laugh at #3, but you might be surprised how many would seriously tell you "no".

Now, aside from the aesthetics, there the nuts-and-bolts stuff to consider:
  1. Does the application rely on a specific CPU architecture?  Not just AMD vs Intel, but how it pertains to Windows (e.g. "Program Files" vs. "Program Files (x86)", and the wonderful Registry hive "WOW6432node" stuff)
  2. Does the application rely on specific browser interfaces?  Will it work as well with IE11 as it does (or did) with IE8?
  3. Does it rely on a particular Microsoft Office version?
But wait... there's more!!!

If you're supporting a shop that's large enough to care about things like this, you could fall within the general realm of having to care about this as well:  Licensing Models.

Let's say you have 1,000 desktop computers running Autodesk's infamous AutoCAD 2014 (okay, you're probably still on an older version, trying to squeeze budgets as usual).  Maybe you were smart enough to install them using the provided deployment toolkit, and you opted to use a network license server (e.g. "Flexnet" or "FlexLM").  You did some analysis and figured out that only 75% of the licenses were in use at roughly 90% of a typical work week, so you purchased 750 licenses.

Now you show up at a Monday morning meeting, wearing a clean shirt, toting your notepad, pen and a steaming hot cup of coffee.  You're in the midst of enjoying a nice, long swill of that caffeinated goodness, when one of the managers across the room says that she wants to replace 500 of the desktops with Windows 8.1 mobile tablets and run AutoCAD as well.  Now you've got coffee stains all over your clean shirt and on the arm of the poor guy next to you.  What a bummer.

Did you remember to configure "license borrowing" on your server?  Did you plan for the possibility of such a large number of licenses possibly going off into the wild, for who knows how long?  Will that 750 number still work for this new direction? 

Things to make you rub your chin and say "hmmmmmm...."


Thursday, March 20, 2014

Stick Shift or Automatic: Software Deployment by the Numbers

No.  I'm not trying to promote sales of any books/ebooks, not even my own (cough-cough).  I am about to dive into a murky subject that many Windows-environment Systems Administrators and Systems Engineers have a very tough time understanding.  And, as if that wasn't enough, I would venture to bet that very, very, veerrrrrrrry few Business Analysts, Project Managers and executive management folks have even a basic grasp of this subject.

The irony of this is that this is about as fundamental to any medium-to-large scale IT environment as bricks are to building a big house.  But even a small business can benefit from this, so don't scoff and walk away just yet.

What am I talking about?...

Manual versus Automated Software Product installation, and Repackaging.

Two things which fit together like peas and carrots.  Or hookers and politicians.  Or Florida and hurricanes.

Yes.  It's 2014, and from what I can tell there is a frightening number of so-called "technology professionals" that sincerely believe that there is little or no difference in terms of cost or quality between these to approaches.  These two diametrically-opposed approaches, that is.  In fact, many think that manual installations are cheaper, even when dozens of installations are involved per product.  I am not joking, nor am I exaggerating.  Please read on.

Most of them, if fed enough beer, or Xanax, would bet their retirement interest on the assumption that the differences between these two are as close as driving a vehicle with stick-shift versus an automatic transmission.  That this is a monolithic, linear-scale, pound-for-pound comparison.

It's a good thing for them that the retirement interest on their fortunes is almost invisible to their overall balance sheet.  A few zeros can get lost in all that green I'm sure.  When you dig into the real numbers, the comparison is about as close as a boxing match between Mike Tyson on his "best day ever" and Richard Simmons after getting a root canal.

All kidding aside, let's do some math. mmkay?

Quasi-Scientific Analysis

Let's say product "Fubar 2014", from a well-known vendor, is required by 500 of your employees in order to "do their assigned job duties".  You have a minimum wage minion whip out a stopwatch and begin timing the installation on the first five computers.  The minion tallies up the results and hands it to you. It goes something like this:

  1. Technician walks over to computer "123" in building 42, up on the 3rd floor, in room 112 and sits down. Time spent getting there by foot/bicycle/car/private jet/yacht or teleporter is, on average, 5 minutes.
  2. Technician then logs on and opens Windows Explorer. 2 minutes (waits for initial profile setup)
  3. Navigates to central file server share on the network (Active Directory domain environment) to locate the folder containing Fubar 2014 setup files and related files.  1 minute.
  4. Navigates to "prereqs" subfolder to install individual products which are required before installing Fubar 2014:  Java  Runtime 1.5 (vendor says it can't work with 1.6 or later), then Apple Quicktime 7.1, Adobe Flash Player 11.5 (Fubar 2014 won't work with version 12), and a few other items.  10 minutes.
  5. Double-clicks on Fubar 2014 "setup.exe" file to launch main setup. Clicks Next on the Welcome page.
  6. Accepts default for installation target folder path, clicks Next
  7. Checks the EULA terms and enters a license product key.  Clicks Next.
  8. Waits for installation to complete. 8 minutes.
  9. Goes back into Windows Explorer and right-clicks on a folder under C:\Program Files\Fubar to open the Properties form.  Modifies the NTFS permissions to allow members of the local "Users" group to have Modify/Change permissions on that folder and all sub-folders.  This is required since the users do not have local Administrator rights, so UAC has been a problem.  This has been known to resolve the problem, so your tech goes ahead with the routine modification.  5 minutes.
  10. Tech goes into Windows Services and disables a service that Fubar 2014 uses to check for periodic updates, which users cannot install without elevated permissions, so this is a standard practice at your shop to disable it.  2 minutes
  11. Tech opens REGEDIT, navigates down to HKEY_LOCAL_MACHINE\Software\Fubar\Fubar 2014\Settings\ and changes the value of "autoupdate" from 1 to 0.  1 minute.
  12. Tech reboots computer, and waits for login screen to log back on.  2 minutes.
  13. Tech logs back on (1 minute or less) and launches Fubar 2014 to confirm it works.  While still opened, Tech navigates into settings to change the option (Tools / Options / Data) to set the "Default library location" to a central UNC server path where all the users share templates and common items to maintain standards.  2 minutes.
  14. Tech closes Fubar 2014 and logs off.
  15. Tech goes on to next location and repeats this process.
Paying the Bill

If you kept track of the time spent above, that's 5+2+1+10+8+5+2+1+2+2 or 38 minutes.  That's without ANY interruptions or unexpected problems.  And that's assuming the computers are relatively new and performing well.

In reality, from tests I have witnessed over the past 5 years alone, in various enterprise environments from 5,000 to 50,000 computers, the average time to perform an installation of this magnitude is roughly between 35 and 50 minutes.  

When performed during business hours with people around in close proximity, the times averaged 45 minutes to 1 hour.

When additional problems had to be resolved, such as missing updates, recovering disk space, removing conflicting components, that range increased to around 1 hour 20 minutes to 1 hour 50 minutes.  

I haven't even mentioned:
  • Time spent deactivating old licenses
  • Time spent activating new licenses
  • Time spent dealing with device drivers
  • Time spent dealing with custom network interface settings
  • Time spent on the phone dealing with vendor support:
    • Large vendor: waiting on line, listening to 70's pop music, interlaced with endless repeats of ads for their other products, like their "new cloud services".  awesome.
    • Small vendor: waiting for guy (company owner/programmer/tester/web admin/support rep) to move his cat off the desk so he can flip through his paper stack to find your purchase order.
  • Impact on end-users while they wait for the tech to do their work
  • Impact on production from unexpected conflicts with other line-of-business products which are only discovered after the installation because there was no lead-time testing afforded.
In situations where a previous version had to first be uninstalled before performing a new install of the later version (usually because the vendor didn't want to take the time to handle this within their new installation package) the time ranges increase to around 2 hours to 2 hours 30 minutes.

Simple:  35 - 50 minutes
Complex:  120 - 150 minutes

In beancounter English: that's a range of roughly 1 hour to 2-1/2 hours.

Repeat this times 500 and you get anywhere from 316 hours (simple) to 1125 hours (pain in the ass).

Multiply that times the technician labor of say, $9/hour (you're a cheap bastard, after all), and that equates to roughly $2,850 to $10,120 of labor.  For ONE software installation.

I'd guess you probably have more than a few products that would be handled this same way across your organization.

Are you starting to see where this is going yet?

Sanity Check Time

Now, let's crank this puppy through ONE cycle of repackaging effort and see how this spews out the other end of the meat grinder.
  1. Software Package Engineer (hereinafter SPE) opens a CMD console within a guest virtual machine (VM) running inside of VMware Workstation or Microsoft Hyper-V (take your pick).
  2. Navigates to folder where Fubar files are stored.
  3. Launches setup.exe -r and completes a normal setup process.
  4. SPE grabs the resulting setup.iss file from C:\Windows and copies it into new folder along with the original setup files.  5 minutes total by now.
  5. SPE opens a text/code editor and loads a template script to enter some lines to handle checks for prerequisites like JRE, Silverlight, Quicktime and so forth.
  6. SPE enters code to invoke the setup.exe with setup.iss and redirect the output to a new log file.  Total of 15 minutes by now.
  7. SPE saves script and puts all the files into the new deployment source folder.  SPE launches a separate VM, which is configured to match the configuration of the computers in use by employees who will be getting the installation.  SPE runs the install using a command shell to ensure it runs "silent" and requires no user interaction whatsoever.  Total runtime, including launching the VM and logging on is now around 30 minutes.
  8. SPE emails or IM's the designated customer SME (that's subject-matter-expert) who was nominated to be the "test user" and asks them to log into the VM using Remote Desktop and kick the tires.  Time spent contacting the customer about 1 minute.
  9. SPE moves on to work on other packages or tasks while waiting for customer to respond and attempt the testing (parlance: User Acceptance Testing, or "UAT")  No time expended by SPE during this period by the way.
  10. Customer gives the package "two thumbs-up!" and the SPE moves it into staging for production deployment.  SPE creates a new "Application" in System Center Configuration Manager 2012, creates a resource Collection with the computers to be targeted, and assigns the Application to the Collection using an Advertisement.  10 minutes (he's drinking decaf this morning)
  11. Advertisement is scheduled to run after hours, avoiding impact on production time against the customer staff who will receive the new installation.  SPE does not have to wait for the installation because it is scheduled to run on its own, so he/she checks on it the next morning.
Total time spent:  5+15+30+1+10 = 61 minutes.

I realize I said "he" a lot, but "she" could do just as well obviously, so that's irrelevant.

Things I didn't include:
  • UAT problems resulting in having to go back and make adjustments and retesting
  • Pre-flight deployments to verify conflicts in production on a limited subset of computers.
  • Next-day support calls for incidental one-offs like machines being offline or a service was stopped or an application was open and had a lock on a file that prevented the Advertisement from completing successfully.
  • Cats walking across keyboards and causing a BSOD.
  • Who knows what else.
Taking those things into account, the ranges can jump from 60-80 minutes for a simple scenario to 2 hours, for just a simple repackaging effort like the one Fubar 2014 involves.  

In the "real world" some products can be much more difficult to repackage and may consume days or weeks of development and testing in order to get a rock-solid package into production.  Those are rare, but even then, EVEN THEN, the savings when calculated across hundreds or thousands of computers, spread across multiple locations, states or continents, can be well worth the effort.  

Think of "mission critical" applications, where the time window to get them into production, with 99.999% success rate, is only an hour or two, end to end, over 20,000 or 30,000 computers.  That's not fiction.  There are industries where this is not uncommon, and they rely heavily on this methodology to ensure:
  • Highest probability of success
  • Consistent and predictable results
  • Minimized impact on production operations
  • Optimum transparency of all moving parts (think reporting and monitoring)
Steak Dinner Anyone?

So, this SPE makes $75,000 a year in USD, roughly $36/hour, and spent an hour building this simple package.  That's $36 to deploy one product to 500 computers over one evening without asking any users to step away from their computers during work hours.  

The cheapest scenario in the first example was $2,850.
The most expensive scenario in the latter example was $1,442.

Even if the SPE had to devote an entire week to one product, or roughly 40 x $36 = $1,442, that's a LOT CHEAPER than a $9/hour tech running around to 500 computers, or 10 x $9/hour techs running around to 50 computers each.

That's Not All

Billy Mays homage:  Now, if you go with the repackaging and automated deployment scenario, you have a mechanism in place that does the following for you without ANY additional cost:
  • Provides automatic self-healing of deployments, to cover situations where a targeted computer is replaced or reimaged with a fresh Windows configuration.
  • Provides simple, effortless scalability for future growth.
  • Provides a robust auditing and reporting trail for accountability and compliance.
  • Provides fault tolerance
  • Provides coverage during non-production hours.
Still think that thumb drive is the way to go?  Hmmmm?


Thursday, February 6, 2014

Let's Talk About Software Repackaging. Mmmm kay?

For some unknown reason, there seems to be a noticeable uptick with regards to business interest in this thing called "software packaging".  It's often bundled with "/software deployment" or "software repackaging".  The problem seems (to me, anyway) that the more I talk with folks, the more it seems they have it wrong.  Really wrong.


Why?

Part of the problem is that, akin to software development, the aspects of the job role involve a VERY broad set of skills and experience.  Many of which are unrealistic to expect in a typical "IT" role.  The folks that do this work rarely planned to do it.  They fell into it.  Some like it.  Some do not.  But it is one rare place in the contemporary IT engineering world that crosses almost every discipline from tier 1 level to network engineering, Infosec, application development, systems administration, Active Directory, imaging, and years of basic troubleshooting injected with steroids and caffeine.

The other part, and it's a crucial one: There are NO certifications to quantify this role whatsoever.  Having an MCTS or MCP helps.  So does MCITP/MCSA/MCSE or MCSD or even MCSE/Desktop.  So does A+, Network+ and Security+.  So does a VMware VCP.  But if you're thinking of listing all of those under the "Required" or "Preferred" skills section: good luck.

I bet you may be thinking: "But, Dave, most modern apps are easy to deploy."  That's true.  Usually.  But the problems are not with most modern apps.  It's with dragging along the suitcase of legacy crap that most large-scale enterprise organizations still contend with.  They have oddball requirements that require an assortment of oddball products.  Those oddball products range from obscure garage-ware, to in-house "home-grown" crap, to stuff retired or replaced years ago by a vendor that no longer exists.  Add to that many products which were developed for Windows NT or Windows XP, but have no modern counterpart to use for running on Windows 8.

That leaves you with app-virtualization (App-V, ThinApp, XenApp, etc.) or some VDI infrastructure muscle (Remote App, Citrix and XenApp, etc.).  If you have those tools to use, great.  If not, you may be cracking open this dusty old book of repackaging.  Eye of newt. Tongue of toad.  Mmmm.

Clarification Time:  To Package or Repackage?

Software Packaging is the process and practice of building a new installation bundle for a software application.  The most common result is the age-old "setup.exe", but is more commonly being produced as a .MSI package file.  It may also include accompanying binaries, either compressed internally, or provided in sub-folders, etc.  A vendor-provided installation is one of the most common examples of a "software package".

Software Repackaging is the process and practice of taking a software package and modifying it to provide a reconfigured/customized installation package.  Examples include creating a MST (transform), a setup wrapper, a script, task sequence, Group Policy Object, or even embedding it within an OS image.

Why do I bother trying to explain these stupidly-confusing terms?  Because 99.99999999% of recruiters, IT managers, and housewives don't have a clue about what the differences are.

In short:  A Software Package is like a car bought from a local dealership lot.  A Software Repackage is like taking that car to the chop shop to install custom NOS, traction control, dash controls, roll cages and cloaking devices (okay, I made that up).  Hopefully, that makes it more understandable for you.



Skills?  What Skills?

What ingredients does a decent software packager/repackager require to cook up a good career soup?

  • Experience with Windows Installer (command syntax, logging, exit codes, troubleshooting, etc.)
  • Experience with InstallShield EXE packages (silent commands, answer files, etc.)
  • Experience with a repackaging product like AdminStudio, InstallShield or Wise Installer (if that's still around).  Familiarity with other, similar products doesn't hurt, but those AdminStudio and InstallShield are the most desired.
  • Windows Event Logs.  The ins and outs. Exporting.  Searching. Filtering, etc.
  • Windows Environment Variables (%username%, %computername%, blah blah)
  • Windows Path Assignments (%windir%, %appdata%, all that mess)
  • NTFS File System aspects: ACLs, SACLs, DACLs, etc.
  • ACLs with regards to the Registry
  • The Registry (know it.  love it.  live it.)
  • Windows Services (configuration, status monitoring, troubleshooting)
  • Familiarity with Security Contexts (what accounts are running what things, etc.)
  • Lot's and Lot's and Lot's of scripting experience: BAT, VBscript, Javascript, KiXtart or PowerShell.  Others will help, but mostly BAT, VBscript and PowerShell.
  • Familiarity with Group Policy Objects and how they are processed on a computer.
  • STRONG familiarity with Windows command-line tools: REG, REGSVR32, CACLS/XCACLS, REGINI, SET, SHUTDOWN, LOGOFF, SC, NETSH, PING, NSLOOKUP, and START.  All the newer stuff helps too, like WMIC, WEVTUTIL, DSQUERY/DSGET
  • PSTools.  In fact, if you don't know who Mark Russinovich is, you're not getting hired. Sorry.
  • Orca
  • ROBOCOPY and all of it's drippy goodness.
  • Familiarity with Virtual Machines (VMware Workstation, Hyper-V, Xen, blah blah) for testing and rollback, etc.
Absolutely Most-Basic Skills:
  • Making a Windows Installer Transform
  • Making a SETUP.EXE response file (.iss file)
  • Basic script skills:  If/then/else, loops, etc.
  • Command Tools:
    • Querying and modifying folders, files and Registry keys and values
    • Manipulating security permissions on files, folders and Registry values
    • Stopping and starting Services
    • Restarting a computer (local or remote)
  • Using Process Monitor (and why)
  • Using TASKLIST or PSLIST effectively (and why)
  • MSIEXEC command syntax (seriously!  double-seriously actually)
Double Extra Bonus
  • Familiarity with deployment automation products like Microsoft System Center Configuration Manager. Particularly: the creating, maintaining and troubleshooting of:
    • Collections (and queries)
    • Packages and Programs
    • Applications (SCCM 2012)
    • Advertisements
    • Maintenance Windows
  • Group Policy Preferences. Item-Level Targeting (aka WMI Filtering). Blocking and Inheritance, sequence ordering, RSOP, blah blah.
  • Deep understanding of the differences between snapshot capturing and snapshot/monitoring captures.
  • MDT (Microsoft Deployment Toolkit) and ADK tools
  • Logon, Logoff, Startup and Shutdown scripts
  • Active Setup
  • Application Compatibility Toolkit (ACT) and building shims (know what shims are also)
  • DISM
  • Using and Mounting ISO and WIM files
Will you have to use all of these all of the time?  No.  Will you need to use these a lot?  Maybe.  But the more familiar you are with this list the better you will be at planning, preparing, developing, testing and deploying application packages.

Triple Extra Double Bonus
  • Great customer relation skills.
  • Being able to have a sincere conversation with users who have almost zero understanding of the effort you put into making things work for them which appear to be effortless.
  • Great note-taking skills
  • Patience, especially when sitting through long meetings
  • Following-up on things (customer responses, meetings, reports, etc.)
  • Prioritizing (projects, tasks and personal tasks)
  • Scheduling (personal and group/team events)
  • Sticking to your guns
  • Developing a deep and loving relationship with coffee or tea
  • Developing a deep and loving relationship with beer, wine and/or liquor
  • Being consistent, dependable, and on-time
  • Focusing on documentation and organization of notes and materials
  • Having the ability to calm down panicked users/managers during a crisis and methodically gathering the facts to diagnose the problem properly.
Toughest Challenges?
  • User Acceptance Testing (UAT)
  • Vendor Tech Support discussions (or email threads).  Especially the kind where you ask for help and they promise to "get back to you" and never do.
  • Customers who insist they CANNOT function without that MS-Access 2003 "application" or the entire company will fold and close. (bonus points for FoxPro 9 apps)
  • Hours and hours of reading the most excruciatingly boring manuals.
  • Hours and hours of searching web sites for troubleshooting tips for that one niche app "Fubar 1997" that won't seem to work on Windows 8.1
  • Decaf coffee, and Ice Cream-flavored store brand coffee.
  • Bowls of sugary junk food sitting around for weeks on end.
  • Hours of conversation with coworkers who are either (A) uber-religious or (B) uber-atheist, and neither can wait to remind you just how awesomely correct their views are.
  • Recaps of last nights sports event or draft picks, especially those incredibly important fantasy league trade discussions.
  • Listening to arguments over which sport is the toughest or which TV show is best, or which car is fastest or which asshole has the toughest job and most difficult customers.
  • Tearing off in a panic to the closest restroom, ripping off your clothes quickly, sitting down, letting loose, closing your eyes, exhaling slowly, and then opening your eyes to discover there's no toilet tissue.
  • Traffic (except for you lucky assholes that work from home)
  • Cold, stale coffee... but only if it already has that white fuzzy mold on it.  Otherwise it's just fine.
The Yellow Brick Road

I've tried several times to get an effort off the ground to offer training in this regard, but there doesn't seem to be much public interest.  Developing a cohesive and coherent training outline is a challenge, but my colleague Chris DeCarlo and I have worked pretty hard to build a decent syllabus.  We've even developed a faux exam to cross-exam hapless victims (aka prospective applicants).  Maybe things will change.  But for now it seems there's a nail waiting for the right hammer to come along.

Wednesday, February 5, 2014

BPA. Again? Yes. and THIS time with Fries and a Drink

The Challenge

Your tech staff wants to be able to swap-out existing desktop computers with the least amount of administrative overhead.  Basically, they want to be able to walk up with a new computer, unplug the old one, plug in the new one, turn it on and walk away.  The stuff on the existing computer should magically end up on the new computer (sans all the usual personal crap that shouldn't be stored on a local computer in the first place).

What are these "stuff"?  Applications, default/initial configuration settings, printer mappings, Outlook profile settings, etc.

The Tools at Hand

Active Directory (Windows Server 2012), Group Policy, System Center Configuration Manager (2007, but that's for another discussion), SCCM OSD+MDT+ADK+Coffee, SQL Server 2012, ASP (yes, the sticky, smelly old classic kind), Packaged Software (already loaded into SCCM), a tablet running Windows 8.1 and a bluetooth barcode scanner.  Also, a van, a hand-truck, appropriate weather-oriented clothing, hydration substances and a fully-loaded firearm (okay, not for all situations).

Options

Options are good.  This is just one option.  One that I am fortunate to be working with actually.

If the computer is mapped into the appropriate collections within Configuration Manager, and managed and monitored via logical memberships and dispositional relationships (Active Directory Security Groups, Active Directory Organizational Unit location), you're in what NFL fans would call "the Red Zone".

The Binding Adhesives:

  • Assuming that the existing computer finds its way into a functional or organizational related Collection within SCCM, you have a means for aiming things at it by function and/or organization (sector, department, division, business unit, etc.)
  • Assuming that the existing computer has things configured via Group Policy, it is likely grouped under a logical OU environment.
  • Assuming it is targeted via either query-based Collections (handy), or direct-membership Collections (a little more work but still handy) you have another means for aiming things at it in a logical manner.
  • Assuming, and this is a reach for some environments, but very common in others: you have barcode labels on assets that are relational to their AD account names, oooh.  You are in very good position to throw a touchdown now.
The Process Walk-Through
  • Technician arrives at customer location with new computer, already imaged with a generic, standard "load" (Windows, Office, base applications, etc.) and joined to AD in a generic OU. It also has a functional SCCM client agent.
  • The technician gets the existing barcode and the new barcode values.  Enters them into a web form (from the computer itself or from a third device, such as a tablet or phone).  Hit "submit".  Swap-out the hardware, reconnect, power up the new stuff and run off with the old stuff.
In the background:
  • The data is queued (in a relational database, such as SQL Server) for the "old" and "new" computer names.  Since both already exist in AD and in Configuration Manager...
  • A scheduled, or triggered, task invokes a script that queries the database for pending items (those which have not been swapped out yet)
  • Step 1 is fetching the "old" computer information:
    • AD OU
    • AD Security Groups
    • AD account description property (if desired)
    • AD account location property (if desired)
    • SCCM direct-membership Collections
  • Step 2 is taking action:
    • Move "new" computer into correct OU
    • Add "new" computer to same AD groups
    • Add "new" computer to same SCCM direct-membership Collections
    • Update AD account properties (description, location, etc. if desired)
    • Disable "old" computer AD account
    • Remove "old' computer from AD security groups
    • Move "old" computer AD account to special OU (for GPO management aspects)
    • Update asset inventory tracking database (operational status, if relevant, etc.)
    • Force a restart of the "new" computer (to force GPO updates, SCCM client policy polling and discovery updates)
  • Step 3 - mopping up
    • No process model is without exceptions:  manual installations, special device installation, white-glove stuff, etc.
Suiting Up

All of this is not only possible, it's not that difficult with the right planning and testing.  I'm currently using ASP on IIS from an internal Windows Server 2012 box.  The queue is managed in SQL Server 2012.  The script process uses VBscript, but will soon be ported to PowerShell.  The interfaces are COM, WMI, SWBEM, ADO and LDAP/ADSI.  All are very common building blocks in Windows environments.

When was the last time you played with a Lego kit or one of those car/ship/aircraft model kits?

Repeat after me: "It often comes with headaches, but I usually love what I do for a living."

:)

Monday, January 27, 2014

Dastardly Dissections: PowerShell and Software Deployment Dabbling

I was turned onto PowerShell several years ago, but like most music that I've held onto, it took awhile to grow on me.  Until I had one of those "a-HA!" moments, which was just this past week.  I have to give a double-extra "thank you!" to folks like Jeffery Hicks and Don Jones (among many others), as well as all the folks who patiently help others on sites like StackOverflow and Microsoft TechNet.  If I had that much patience I'd be a therapist.


The Meat and Potatoes

I wanted to find a balance between efficiency and reusable code structures.  Ever since I was forged in the fires of LISP programming by an incredible guru named Brad Hamilton, I've sought to make my code as refactoringly refined and reusable as possible.  It should work like a Lego block, as he once mentioned to me.  Another word he used was "organic".  It should work and feel like it grew out of nature, not like a 7-legged cat trying to climb an ice mountain.

Much of what you will see below (and soon-after stab your own eyes out with a plastic fork, out of the sheer horror of it all) is my own personal seasoning.  I like to put a nerdy block-style heading at the top, followed by a group of related custom variable assignments, and then start to work destroying any sense of productivity soon after.

In a nutshell: I define some variables to identify the product, the installer file, the source path, the target path that the installer creates on a typical client, and then move on.

The next part checks if the file is already present, indicating a previous installation was already completed and then exit if that's the case.  If not found, go ahead and run the installation and return the exit code.

(Updated 1/28/2014: line in red below replaces the line just above it.  Ensures script calls installer from the same location / path)

[powershell-begin-ugly-code]

#------------------------------------------------------------
# filename...: install-orca.ps1
# author.....: David M. Stein
# date.......: 01/27/2014
# purpose....: install Microsoft Orca using PowerShell 3
#------------------------------------------------------------

# comment: define variables and assignments

$appName = "Microsoft Orca"
$msifile = "orca.msi"
# $srcPath = "\\appserver3\utils\microsoft"
$srcPath = Split-Path -Parent $PSCommandPath
$path32  = "C:\Program Files (x86)\Orca\orca.exe"
$path64  = ""

$f1 = get-location

write-host "info: searching for existing installation of $appName..."
if (test-path -Path $path32) {
  write-host "info: $appName is already installed (aborting install)"
  $retval = 5000
} else {
  write-host "info: installing $msiFile....."
  set-location $srcPath
  write-host "info: working path is $srcPath"

# comment: the following line may wrap incorrectly in a browser...
  $retval = (start-process msiexec.exe -ArgumentList "/i $msifile /qn" -Wait -PassThru).ExitCode

  switch ($retval) { 
    0    {write-host "info: success"} 
    3010 {write-host "info: success (reboot pending)"} 
    1603 {write-host "fail: I hate 1603. A useless error code!"}
    1605 {write-host "skip: target application was not found (uninstall abort)"} 
    default {write-host "fail: uh-oh? exit code is $retval"}
  }
 
  set-location $f1
  write-host "info: installation complete."
}
exit $retval

[powershell-end-ugly-code]


Why exit with code number 5000?  Good question. I wanted to be able to filter in on that via System Center Configuration Manager, especially through direct T-SQL queries and BI reporting.  I tend to "live" in the SQL Server environment more than anywhere else for some reason.  It feels like wandering around a big-volume hardware store on a quiet night.

If I treated an existing install as a "failure" or exception, I would have to assign a non-zero result code.  I could consider it a "success" and return 0 (zero) as well, but then I wouldn't be able to query for unnecessary attempts in my production environments.  Artificial flavoring has its uses.

To invoke this from an non-Powershell state, I fire off the command string as follows...

powershell -File install-orca.ps1

Then I can fetch the result implicitly via the command pipeline or explicitly by interrogating %errorlevel% via the CMD shell interface.

Ripping It Out Again

So, what about the Uninstall flip-side of this?  Let's try this out...

[powershell-begin-stupid-code]

#------------------------------------------------------------
# filename...: uninstall-orca.ps1
# author.....: David M. Stein
# date.......: 01/27/2014
# purpose....: uninstall Microsoft Orca using PowerShell 3
#------------------------------------------------------------

# comment: define variables and assignments

$appName = "Microsoft Orca"
$guid    = "{85F4CBCB-9BBC-4B50-A7D8-E1106771498D}"
$path32  = "C:\Program Files (x86)\Orca\orca.exe"
$path64  = ""

$f1 = get-location

if (test-path -Path $path32) {
  write-host "info: $appName is installed.  Uninstall it now..."

  # comment: the following line may wrap incorrectly in a browser also...

  $retval = (start-process msiexec.exe -ArgumentList "/x ""$guid"" /qn" -Wait -PassThru).ExitCode

  switch ($retval) { 
    0 {
        write-host "info: uninstallation was successful."
        write-host "info: removing leftover files and folders..."
        Remove-Item $path32 -Recurse
      }
   3010 {write-host "info: success (reboot pending)"} 
   1605 {write-host "info: target application was not found (uninstall abort)"} 
        default {write-host "fail: exit code is $retval"}
  }
 
} else {
  $retval = 0
  write-host "info: $appName was not found on this computer (abort uninstall)"
}
write-host "info: completed"
exit $retval

[powershell-end-stupid-code]


A few notes on the example above:

  1. First, you may notice the additional code to remove leftover files and folders.  That's because it's not uncommon to find leftover files and folders after a "successful" uninstall.  The reasons are many, but in short: just clean them up if needed.  
  2. Second, if the installation was not found, I force a 0 return value here.  I could have also forced something like 5001 or 6000 or 227001 or whatever (as long as it's not in conflict with known result codes used by other apps or processes).  I chose 0 because I'm tired and sitting in a realllllllly comfortable chair right now.  Too lazy to use a longer value.
  3. I could have used Test-Path to find the Registry Key instead of a folder and file.  That would work as well, and the example would look instead something like the following...

Test-Path "HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{85F4CBCB-9BBC-4B50-A7D8-E1106771498D}"

(note that I had to wrap the path in matching double quotes; otherwise it tries to evaluate the { and } as code).

If you're not familiar with Windows Installer methods (e.g. msiexec syntax), that's okay.  That means you're probably "normal".  I'm not.  You can invoke an uninstall using "/x" and provide a specific .msi package file, or you can locate the associated application GUID from the Registry (see HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall, or for 32-bit apps on a 64-bit client, like Orca, refer to HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall) and use that as well.  Below is a screen capture of REGEDIT showing the key and value on my cheap laptop...


Find the "UninstallString" value and grab a copy to inspect.  The irony is the "/I" prefix, which denotes "Install", but you can ignore that.  Almost every product entry will have an "UninstallString" value and it will almost always contain "Msiexec /I{blahblahblah}".  For an uninstall operation, you replace "/I" with "/X" (upper or lower case, doesn't matter), and move on.  It's the rest of that string that matters.  That's the GUID, and it is usually pretty reliable for use with msiexec to uninstall a known product entry.

More Mindless Notes:
  • You may encounter cases where you do NOT want to delete leftover files and folders (I didn't even mention leftover Registry keys and value, did I?).  Just comment that line and you're good to go.
  • You may need to stop services in order to perform some tasks.  You can use the Get-Service cmdlet or Stop-Service.  To remove a service, you can use the ancient SC.EXE command (under \Windows\System32) to invoke the Delete method.  Just don't forget that it may require a reboot.
  • Be careful to validate every exit code before assuming anything other than 0 (zero) is "bad".  3010 for example is good.  In some contexts (is that proper English?), the exit code 1605 could be considered "good" as well.
  • I'm NOT a PowerShell expert.  I'm still learning and very possibly farther behind on this stuff than you (in which case you're probably not reading sentence because you already left this page to find what you are really looking for).  I hope I'm not the smartest guy in the room.  That's a boring proposition to consider.  I'd rather be learning.
Namaste.

Thursday, January 9, 2014

The Angry Admin: Time for a Rant about Naming Conventions

If you work with network administration of ANY kind (file and print services, directory administration, web applications, software deployments, etc.), pay attention:

Take a moment to review how you name things.

Devices: Servers, Desktops, Laptops, Tablets, Mobile Devices, Printers, Printer Pools/Groups.

Resources:  Software Packages, Log Files, Folders, Shares.

Active Directory: User Accounts, Security Groups, Contacts, Group Policy Objects, WIM Files, Forests, Domains, Sites and Subnets, Site Links.

SCCM: Packages, Collections, Advertisements, Task Sequences, Boundaries, Catalog Descriptions.

All of it.  EVERY F-ING THING.

Then, ask yourself this:  If I had to manage 50,000 of EACH of these things, what would make it easier to filter out and find things by logical grouping?


  • By type or category (desktop, laptop, high-end vs cheap-crap, servers, physical vs. virtual)
  • By organizational entity (department, division, group, sector, team, project, etc.)
  • By security role (admins, users, special roles, etc.)
You might laugh this off or smirk, but om-f-ing-g:  this comes back to bite the living shit out of more people than I can count.  If I had a dollar for every time I've heard an SE, SA or whatever say "damn.  I wish I would have named this stuff like ____." I would be retired and living on a tropical island.  My own island.  With my own castle and airplane and an armada of jetski's to go with it.

Just do it.

Monday, January 6, 2014

Dastardly Dissections: When Scripting is just one Tool, not a Whole Tool Box

(Note: This may be the first of a new series of blognostications I'm thinking of calling "Dastardly Dissections".  If I maintain my motivation, and caffeine intake, I will strive to use real world examples where technology was used to solve problems.  Other than the kinds of technology that blow things up, that is).


For many IT folks, or folk, as they say in places I've never been, this may step into the murky, sticky muddy waters of borderline sacrilege, but give me a chance.  I know a lot of scripters, script-kiddies, skittles-munching, bong-drinking coder geeks like to think of scripts as the holy grail to solving all IT challenges.  And for many situations they can be very well-suited to that purpose indeed.  But for me, I find it more interesting when script code plays the part of Mr. Glue (okay, Ms. Glue is fine too), and helps bind the forces of the technoverse into harmony.  Kind of like magical fiber in the ethereal digestive tract of the processing world.  Um, yeah.

Case in Point:  Crapware needs a Crutch.

IT folks who get their fingers all sticky with repackaging and deployment should be well familiar with less-than-ideal packaging chores.  One that comes to mind (and, NO, I'm not going to name the vendor or product.  Mainly out of pants-wetting fear of law suits), is a software application that comes with a digital signature pad.

Those are the kinds of detachable devices where you whip out a plastic pen-like thing, often with an attached cable thing, which is then grasped by the authoritative human with firm, yet shaky hands to apply a soon-to-become-extinct thing called a "handwritten signature".  I'm told people used to actually scribble words using their own hands to indicate who they are (or were).  Amazing!  I wonder how long it will be before it's commonplace to have a chip implanted at birth.  Moving along...

Ok.  I'll get to the point.

First Challenge:  The software probes for the peripheral signature pad device connection and determines the COM port assignment.  From that it writes a new .INI configuration file (yes, this is supposedly "Windows XP compliant, and they say, that it should work fine on Windows 7).  It does this the first time it is plugged in and always uses that port from then on (as long as the SAME device is attached to the SAME computer with the SAME operating system configuration).

Bigger challenge:  The customer purchased roughly 400 of these things.  They need to be handed out to the field-workers, who each have a laptop running on Windows 7 Enterprise SP1.  They rarely connect directly to the organization network, and they need to be able to plug these things in, and use them, while in the field.  That means they are most often NOT on a VPN connection or connected to the Active Directory domain environment. But, that's not all!

Bigger than Bigger challenge:  The INI file is created in, and will only work from within the C:\WINDOWS folder (e.g. %WINDIR%).  That means UAC is giving them the big face-smack of security each time.  KaBlam!! Thwack!  Kazowwy!  sorry, no more of that...

What to do?

Well, here's ONE way that happens to work:
  1. Perform a "manual" installation of the crapware application, or as some might call it: crapplication.
  2. Plug the device in.  Wait for the UAC bitch-slap.
  3. Provide the suitable credentials to allow the crap-device to talk to the crapplication and update the crappy INI setting.
  4. Save a copy of the INI file.
  5. Locate the line which stores the COM port setting.  Replace the value (e.g. "CrappyComPort=COM3") with a unique string value (e.g. "CrappyComPort=ZZZZZ") and save the copy.
Example of copied INI "template" file...

[Tablet]
TabletComPort=ZZZZ
TabletType=0
TabletLCDMode=0
TabletModel=Crap_VR549
...

Now, using (insert dramatic entrance music) script code, you pull on the chains of the old "DEVCON" command-line utility to probe for the device and COM port.  Write the results to a text file (redirect or whatever you prefer).  I'm sure you can probe it using WMI or crawling the Registry as well, but since I like old commands, because I'm also old, I go that route.

[updated 1/7/2014]
As for the specific DEVCON syntax (thanks to Chris for this by the way)...

    devcon.exe" hwids *FTDIBUS* >>"%Windir%\CrapWare\devcon_dump.txt"

Next, using script code, open and parse the DEVCON output file to get the COM port number.  Then open the copied INI file, read in the guts, replace the "ZZZZ" (or whatever you chose to use) with the "COMx" value, and write it back out to the C:\WINDOWS\crapplication.INI file, all under a suitable elevated user context (i.e. SYSTEM, would be fine), and let her rip!

Example of the DEVCON dump file...

FTDIBUS\VID_0403+PID_6001+A983498VX\0000
  Name: USB Serial Port (COM4)
  Hardware ID's:
    FTDIBUS\COMPORT&VID_0403&PID_6001
1 matching device(s) found.


Special thanks to my colleague and coworker extraordinaire: Chris.  Because, he is extraordinary.  And as they say, the difference between ordinary, and extraordinary, is that extra bit.

The dastardly code...

[beginnen der codenhauzen]

'****************************************************************
' Filename..: crapplication.vbs
' Author....: INSERT YOUR NAME HERE UNLESS IT BLOWS UP (then use another name)
' Date......: 01/05/2014
' Purpose...: parse text file to obtain desired value, win the prize!
'****************************************************************
Option Explicit

Dim scriptPath, strTemplate, objFSO, objFile
Dim strLine, strPart, pos, strComPort, ts, t1
Dim objINIsource, strNew, strAll, objShell

t1 = Timer
scriptPath = Replace(wscript.ScriptFullName, "\" & wscript.ScriptName, "")

strTemplate = scriptPath & "\crapware.ini"

Const inputFile  = "c:\windows\temp\devcon_dump.txt"
Const outputfile = "c:\windows\crapware.ini"
 
Const ForReading = 1
Const ForWriting = 2
Const TristateUseDefault = -2
Const TriStateTrue    = -1
Const TriStateFalse   = 0

wscript.echo "info: devcon file == " & inputfile
wscript.echo "info: output file == " & outputfile
wscript.echo "info: template == " & strTemplate

strComPort = ""
' comment: read the COM port from the devcon output file...
Set objFSO  = CreateObject("Scripting.FileSystemObject")
On Error Resume Next
Set objFile = objFSO.OpenTextFile(inputFile, ForReading)
If err.Number = 0 Then
 Do Until objFile.AtEndOfStream
  strLine = Trim(objFile.Readline)
  pos = InStr(strLine, "(COM")
  If pos > 0 Then
   strPart = Trim(Mid(strLine, pos))
   ' comment: should return "(COMx)"
   strPart = Replace(Replace(strPart, "(", ""), ")", "")
   ' comment: should be left with "COMx"
   strComPort = Replace(strPart, "COM", "")
  End If
 Loop
 
 objFile.Close
 
Else
 wscript.echo "fail: error (" & err.Number & ") = " & err.Description
End If

wscript.echo "info: current COM port: " & strComPort
' comment: open and suck-in all text from the template file...
Set objINISource = objFSO.OpenTextFile(strTemplate, ForReading, False)
strAll = objINIsource.ReadAll()
strNew = Replace(strAll, "TabletComPort=ZZZZ", "TabletComPort=" & strComPort)

' comment: get the vendor's crappy ini or make a new one...

On Error Resume Next
Set objShell = CreateObject("Wscript.Shell")

wscript.echo "info: searching for default ini file... " & outputfile
Set objFile = objFSO.GetFile(outputFile)
If err.number <> 0 Then
 err.Clear
 wscript.echo "info: ini file not found. creating new one..."
 wscript.echo "info: creating new file: " & outputfile
 Set ts = objFSO.CreateTextFile(outputfile)
 If err.Number <> 0 Then
  wscript.echo "error: " & err.number & ": " & err.Description
  Set objFSO = Nothing
  wscript.quit err.Number
 End If
 wscript.echo "info: waiting for a second. why rush things?..."
 objShell.Sleep 1000
 Set objShell = Nothing
 ts.Write strNew
 ts.Close
 wscript.echo "info: file created successfully!"
Else
 err.Clear
 wscript.echo "info: deleting old file... " & outputfile
 objFSO.DeleteFile outputfile, True
 wscript.echo "info: creating new file... " & outputfile
 Set ts = objFSO.CreateTextFile(outputfile)
 If err.Number <> 0 Then
  wscript.echo "error: " & err.number & ": " & err.Description
  Set objFSO = Nothing
  wscript.quit err.Number
 End If
 ts.Write strNew
 ts.Close
 wscript.echo "info: file updated successfully!"
End If
 
Set ts = Nothing
Set objINISource = Nothing
Set objFSO = Nothing
Set ts = Nothing

wscript.echo "info: completed."
wscript.echo "info: runtime is " & Round(Timer - t1,2) & " seconds"

[terminaten der codenschnitzel]


I know what you're thinking: My variable names suck and my error handling methods could use some improvement.  I could also stand to cut back on some bad dietary habits, but ultimately, someone has to feed the worms.  You're also probably upset that I didn't do this in PowerShell, which I could have, but I'm too lazy tonight and I have to be up early for work tomorrow.

So, assuming the devcon output file has the right output, and the scripts are run under an administrative context, it works pretty well.  The users can plug the device in and life is good.  If bolted together properly it can be deployed via System Center Configuration Manager as an advertisement, or posted in the Application Catalog for self-install.

Next time I might delve into a scenario for converting VBscript into ASP for interfacing with Active Directory, WMI/WBEM and Configuration Manager via a web browser.

Cheers!

Tuesday, December 10, 2013

Stupidity for Sale: Just in time for Christmas!

My next Book is about to be unleashed on the delicate eyeballs (and earballs, for those are visually challenged?).  A year in the making.  Countless lives lost (not mind, at least not yet anyway).  Wars have begun and been ended.  Eons and ice ages have come and gone.  Meanwhile, one lone clueless idiot remained steadfast and diligent, okay, hungry and broke too, but steadfast sounds better, and a work of wonderful wonderfulness was born.



It's kind of like squeezing out a technological nugget of knowledge into a big round ceramic bowl of learning, spiraling down into the minds of yearning minds, eager to absorb it all and wipe up the remains with total abandon.  Uhhhh..  Wait a minute.  That didn't come out right.  No wait. That didn't sound right either.  Oh never mind.

In a word: This. Is. Quite. Possibly. The. Stupidest. Book (okay, eBook). You. Will. Ever. Read.
But it's worth it.  Trust me.   Your mind will forever be changed.

What do I blabber about this time?  MSIEXEC. WUSA. PKGMGR. VBscript. BAT/CMD. PowerShell. WMI. Active Directory. Exit Codes.  Event logs. WEVTUTIL.  EVENTCREATE. SCHTASKS.  And an army of other nerdgasmic acronymical command names that are sure to impress that MBA CTO with the PHD in PMP. But most importantly, I finally had to attach the NSFW helmet and do battle with the concept of "crapware" and why we repackage things at all.

Seriously.  I decided it was time to test the boundaries in a way Frank Zappa did when he asked that prolific question: "Does humor belong in music?".  Okay. Does humor belong in IT?  I think so.  Every Monday morning staff meeting proves it.  I hope you enjoy it.

Stay tuned.  Go here for more of my stuff.

I really need to stop drinking coffee at night.

Wednesday, December 4, 2013

What is a Computer or Software Asset?

Is it a physical entity, or is it a virtual or logical entity?
Is it tangible, or is it an idea?
Is it a record of it being purchased?
Is it a box or envelope containing physical materials?
Is it a record of being on "the wire"?
Is it what YOU have a record of, or the what the VENDOR has a record of?
Is it an account in a directory database?
Is it an associated number in an inventory tracking database table?
Is it what was purchased or what is being used?
Is it what is being used or what was assigned?
Is it something you own or is it something you have a license to use?
Does it belong to the company or a person?

If you find 500 installations of a software product on your network computers, does that constitute 500 licenses?

If you purchased 500 laptops, and only have inventory reporting data for 400 of them, does that mean you own 500 or 400?

If you disposed of 1000 desktops but their accounts still exist in Active Directory, does that mean you still are using the licenses associated with them?


Monday, November 25, 2013

A Sample of Stupidity - For a Limited Time Only!

A few, non-contiguous pages from my forthcoming book on Software Repackaging.  I really would like your honest feedback on what you see so far, as well as suggestions on what you'd like included in the final version.

Adobe PDF file is available for download at the following URL...

https://drive.google.com/file/d/0B-FpG7_P5WX6VklSa3g2U3M4a00/edit?usp=sharing


Thank you!  Dave

Friday, November 22, 2013

What is a Software License?

Is it what you've purchased? (aka.  What the purchasing department tracks via a Purchase Order)

Is it what you've installed? (aka. What your inventory software detected)

Is it what's being used? (aka. What your license manager or reporting tools are showing)

Is it a document that defines what, how many, and where you "should" have installed the product? (aka. An SLA or license key file)

Is it a definition of what you are allowed to do with the product?  (aka. A license agreement document)

Is it a bundle of products, or a single product?

Is it a standalone license, or a "floating" networked, pool of licenses?

Is it just an idea, or is it a tangible entity?

Can you hold it in your hands, or does it only exist as an arrangement of electrons?


Sunday, September 8, 2013

Exam 2013-0824 - Software Packaging, Repackaging and Deployment

The following exam consists of 5 questions pertaining to the field of "software repackaging and deployment" within a Microsoft Windows environment.  Each question may have one or more answers (multiple choice).  You have 15 minutes to complete it.  Good luck!


1. You've been assigned a request ticket to repackage and deploy a product to several computers within your network environment.  The ticket states that there are no binaries from which to build the package, and you must contact the vendor to continue.  You call the vendor and state your objectives.  The vendor replies that you cannot have a copy of their binaries because they don't trust anyone to handle them without pirating them, and that only they can perform installations for each computer.

Which of the following should be your first choice of action?

A. Reach through the phone and bitch-slap the representative with both hands.
B. Laugh hysterically and tell them to "never mind", because you already downloaded a copy from Pirate Bay.
C. Hang up. Close the ticket with a comment stating the vendor is on cheap drugs.
D. All the above.

2. You deployed a bootstrap package to execute a "per-user" installation of a product which was originally packaged as a "Click-Once" installer, onto a group of Windows 7 computers.  You are now told to remove that application and install a different application.  You discover that many of the target computers were shared among multiple users, who each launched the installer and have used it extensively.

Which should you do first?

A. Hire a hitman to kill the vendor.
B. Hire two hitmen and a hitwoman to kill the vendor.
C. Start smoking heavily.  If you already smoke, then smoke more heavily.
D. Look for a job outside of the IT world.

3. Your manager makes a comment during a staff meeting to the effect that "all MSI package installation deployments are the same, and simple as dirt!".  You should...

A. Remain motionless while thinking of your family, starving and crying at home around the bare dinner table, because you reacted properly and choked that person out, instead of ignoring it.
B. Ask the person, "so, when are you taking that job on by yourself?"
C. Yawn and continue working on your Fantasy Football roster from your mobile phone.
D. All of the above, in any order you desire.

4. A different manager insists that virtualization is the cure-all for deploying and managing client applications.

A. You raise your eyebrows.
B. You raise your eyebrows.
C. You raise your eyebrows again.
D. All of the above.

5. Which of the following command syntax examples will install the "fubar2014.msi" package, apply a transform named "tarfu.mst" during the installation, capture the log output into the user's "temp" data folder, do all of this silently, and keep your coffee warm throughout:

A. msiexec /i fubar2014.msi /qn TRANSFORMS=tarfu.mst /l* %temp%\fubar2014.log
B. msiexec /i fubar2014.msi /qb! TRANSFORMS=tarfu.mst /l* %appdata%\fubar.log
C. msiexec /install fubar2014 /quiet /norestart TRANSFORMS=tarfu.mst /lvao %appdata%\fubar.log
D. None of the above.


Be honest, did you scroll down here first and cheat?  Seriously? I hope not.  That would be even worse than failing it without cheating.


answers:

1. D
2. C
3. D
4. D
5. D

Monday, August 26, 2013

10 Questions: with Jerry Milana

Jerry Milana

Introduction

(Note: I apologize for the unusually long introduction, but it's not fluff, trust me)

If you have been among the lucky ones able to attend any of the annual Autodesk University conferences, over the past two decades, you're probably well aware of some names of people that speak on topics such as customizing AutoCAD, Civil 3D, Map 3D, or who push the envelope of products like 3DS Max or Mudbox.  You may have attended sessions on programming, or using advanced features, anything to help you get to a higher level of productivity at your job or hobby.

The presenters, like Autodesk's products, cover a wide range of industries.  From architectural and civil engineering (AEC), to scientific research, to car and motorcycle racing teams, to Hollywood studios, and everything in between.  Some of the names have been legendary, like Lynn Allen, Shaan Hurley, Dave Espinoza-Aguilar, Robert Green, Scott McFarlane, Owen Wengerd, Kean Walmsley, and many others.  In many sessions, you could find one legendary Autodesk employee, quietly sitting near the front, soaking up what the speaker was saying or demonstrating: Jerry Milana.  He would never consider himself legendary, however.

I thought it was kind of funny how later in the day, when he would be conducting his own session on Packaging and Deployment, or License Services and License Management, so many attendees would point and nod, making a comment about how they saw him sitting in the crowd at other sessions.

Between 1989 and 2004, I was often supporting anywhere from 500 to 2,000 computers which were primarily used for AutoCAD design work.  I really depended on either (A) what the vendor provided, or (B) custom scripting and packaging tools, in order to automate the chore of installing that many copies of a product, and the updates and patches, and the next version upgrades.

Of all those products, no vendor put as much work into making their products easy to prepare and deploy to large numbers of computers than Autodesk.  With each successive release, they have continued to improve the features and reliability of their deployment utilities, setting a standard for others to emulate.  Indeed, I have seen quite a few imitations from other vendors, inside and outside of the CAD-related world.  This is a good thing.  And we owe a lot of this to the vision, persistence and efforts of Jerry and his team.

If you think Jerry's insights are only "CAD-related", think again.  The issue of licensing, and license management, will impact nearly every software product in one way or another.

Jerry Milana - System Integration and Software Asset Management Consultant

The Questions

Dave:  Most people outside (and probably inside) of Autodesk know your name as it pertains to the world of deploying and administering Autodesk products on a network. Things like FLEXlm licensing, deployment packages, and so on. When did you first step foot into "that world" if you will and how did it come about?

Jerry:  I worked for a reseller. My specialty was mid-range and PC connectivity and cross platform networking. One day the owner handed me a box of AutoCAD 2.1 and asked me to take a look at it since I had a design background. I said it looked pretty good and soon found that I could use AutoCAD to get in the door of customers to then sell them integration services.

Dave:  What do you feel is the most misunderstood aspect, from the customer side of things, about "network licensing" of software products?

Jerry:  It’s so easy to get things just running customers often miss the finer and much more complex aspects of a licensing implementation. This results in underutilization of assets, exposure to compliance violation and reliability issues.

Dave:  Where do you see world of software licensing in five or ten years? Drastically different, or just incremental changes?

Jerry:  For cloud customers things are already drastically different and the software industry is driving more and more in that direction. As some offerings become exclusively cloud offerings we will see more changes. 

As much as the software industry would like it, I doubt everything will move to the cloud. Even here I think we will continue to see a move from perpetual to term based licensing which will drive changes in licensing. I think (and hope) that we will see hybrid solutions where applications and data are not in the cloud but licensing and associated software asset management is cloud based. 

Of course, there will be private cloud implementations which will drive changes in licensing business models and supporting technologies.

Dave:  I know that one of your passions is skiing and being in and around snow, particularly in beautiful places like Northern California and Colorado. Could you ever see a scenario where your two worlds could cross (software and skiing)?

Jerry:  Who knows, it wouldn't be the first time in my life that hobby and work merged. As it stands now I am a volunteer ski patroller doing both downhill (Alpine) and cross country (Nordic) patrol. It would not surprise me if I end up doing some consulting work for some of the larger resorts and their holding companies.

Dave:  According to your public profile, it would appear that you are either partially or fully retired from the world of software engineering and support services. Are you still involved with technology-related strategic initiatives at Autodesk or elsewhere?

Jerry:  Humm, I better work on my profile. I have been doing independent software asset management and assessment consulting since the beginning of the year. I do some work for Autodesk and for other customers. My business has grown by word of mouth. I am an ADN member and will be speaking at Autodesk University again this year.

Dave:  Do you still travel much? Are there places besides NorCal and Colorado you like to visit?

Jerry:  Yes I still travel a lot for business and pleasure. I enjoy returning to old favorites such as New York, Detroit, Rome, London, Perth, Auckland and Seoul where I have friends and always look forward to visiting new places. I really enjoyed skiing Whakapapa on the north island of New Zealand; it was all about being there on that volcanic hill.

Dave:  If a teenager approached you about choosing a future career path, either in the IT-related world, or something else entirely, what would you recommend to them?

Jerry:  I would tell them to pursue what they are good at and like to do. I have enjoyed my career in the software/IT industry but I see so many people forcing themselves to do this work and are bad at it. I feel we should all strive to be happy and add value to the world; our jobs and hobbies should support this goal.

Dave:  If you were somehow put in charge of Autodesk back in, say, 2005-2010 time frame, and given "absolute control" over all strategic decisions, would Autodesk look (a) about the same as it does today, (b) a little different, but not radically different, or (c) radically different than it looks today?

Jerry:  This one I respectfully decline to comment on.

Dave:  What would make your "perfect breakfast" selection as far as food and drink?

Jerry:  Fresh squeezed OJ and a few espressos.

Dave:  If you could recall anyone from history who has long-since passed on, and have five minutes of time to talk with them, who would it be and what would you ask them?

Jerry:  No brainer, it would be Professor Einstein. If we are talking 5 minutes relative to us at rest on a fixed point on the planet earth; I doubt we would be able to scratch the surface on the things I’d like to discuss. I would start with the validity of our understanding of the propagation of light.

Conclusion

Thank you for reading this interview! I hope you enjoyed it as much as I have.  For more information and resources related to Jerry, please explore the links below.  Thank you!

LinkedIn Profile - Jerry Milana
AU 2004 Photo Album

Wednesday, July 24, 2013

Big News! E-Book Price Reductions!

If you have ever stayed awake long enough to read through any of my books: THANK YOU!

If you've read one or two of them, and wondered if any of the others are any good, well.... now is your chance to explore.


Big News...
Major Pricing Discounts on my E-Books!


Major Discounts will be applied starting this week.  Amazon has to process the price changes, so they may not be posted for another 24-48 hours (from today: July 24, 2013).

If you still see the "Old Price" posted on the Amazon product page, refresh the web page or come back to it until you see the updated prices.

The new prices are shown below.  Read the Q & A below for more information...





Amazon Kindle Publication Old Price (USD) New Price (USD) Discount

Grinding Gears: The Art of Software Repackaging and Deployment

Packaging, Testing, Deploying, Uninstalling and Upgrading Software Applications on the Windows platform.  Also covers Configuration Manager, Scripting, Group Policy, and more!
$6.99 $5.99 15%

Why Your Next IT Project Will Fail (and What You Can Do to Avoid It)

Why do Projects fail? More specifically: Why do IT Projects fail? Is there a common thread or pattern that exists among failed IT Projects? Is it predominantly a failure of technology; of people; or a failure of both? Are there warning signs that make it easy to spot the causes before they become problems, with sufficient time to correct them? Are there steps that can be taken to correct the problem once it's begun? Are there strategies that can help prevent these potential issues from occurring again?
$4.99 $2.99 40%

The Visual LISP Developer's Bible: 2011 Edition

Developing, Testing and Compiling VLISP code for AutoCAD 2011.  VLIDE options as well as tips and tricks.
$7.99 $5.99 25%

The Visual LISP Developer's Bible: 1st Edition

The Original. The e-book that started it all for me. 
$4.99 $2.99 40%

The AutoCAD Network Administrator's Bible: 2013 Edition

Setting up FlexLM and network licensing. Building, Testing and Deploying Autodesk 2013 products (aka "Deployments"), logs, option files, troubleshooting and more.
$9.99 $7.99 20%

The AutoCAD Network Administrator's Bible: 2012 Edition

Setting up FlexLM and network licensing. Building, Testing and Deploying Autodesk 2012 products (aka "Deployments"), logs, option files, troubleshooting and more.
$6.99 $4.99 30%

The AutoCAD Network Administrator's Bible: 2011 Edition

Setting up FlexLM and network licensing. Building, Testing and Deploying Autodesk 2011 products (aka "Deployments"), logs, option files, troubleshooting and more.
$3.99 $2.99 25%

In addition: Some of my e-Books which were not enrolled in the Amazon KDP Select program, are now enrolled! 


Q & A (Questions and Answers)

How Long will this Discount Offer Last?  These prices will remain in effect until August 10, 2013, or roughly 16 days from when the new prices go into effect.  After that, they will be returned to their previous prices.

Do you need a Kindle to read these?  NO.  You can download a FREE Kindle Reader App for almost any mobile device.  You can also read them in almost any web browser using the Amazon Kindle Cloud Reader.

You can read these, using a FREE reader app, on your iPhone, iTablet, iPod, Blackberry, Android device, Windows device, and more.

What Locations will see these Discounts?  The new prices will go into effect in all markets in which Amazon applies international currency conversions.  If you live or reside in a location which is not handled by their automated currency conversion process,  you will see whatever discount is applied as a derived translation of the U.S. Dollar value, as best as I can figure out. 

The markets which are covered by their automatic conversion process, as of now,  include: The United States, United Kingdom, France, Germany, Spain, Italy, India, Japan, Brazil, and Canada.  For more information, visit the Amazon web site and be sure to drink plenty of caffeine.

What does this "KDP Select" stuff mean?  It means Amazon Prime members can LEND and BORROW those e-books for FREE.  Yes.  For Free!  Ok, well, becoming an Amazon Prime member isn't really "free", but it does give you some pretty darn amazing discounts and cool features you can't get otherwise.

How Many of my e-Books are enrolled in this "KDP Select" program for Amazon Prime members to benefit from?  All of them.  If you find any that are not available for lending and borrowing on Amazon Prime as of July 26, 2013, please post a comment here and let me know!

How do I know which books are written by this same "David M. Stein"?  I've been told there are other "David Stein" authors out there, some with rather interesting tastes in book topics.  Rest assured that I have only written the books you see listed on my Kindle Author's page

Why am I doing this?  It's simple:  I have four kids still living at home, and my car is pretty darn old.  So you can rest assured that while you save money, and stuff your brain with new information, you're also helping a good cause.