Skatterbrainz Blog

Regional Autonomy and Applications in the Enterprise

2012-01-30T05:00:00.000-05:00

Unlike most of my rants and posts, I'm not going be able to propose a solution here. This one has no solution. It is simply a situation that exists in the VAST, and I mean VAAAAAAAAASSSSSST majority of "enterprise" business environments. Read that as "big companies", "large organizations", or whatever you wish, but you get the point.

This is really an example of the Human Condition. That is, the desire to achieve some semblance of "order" while also achieving some semblance of "freedom". Be it Federal versus State, Public versus Private, Teacher versus Student, Owned versus Licensed, Urban versus Rural, or what have you. It's a quandary that will never be resolved because it exemplifies Yin and Yang, which like Hot and Cold, or Black and White, will always coexist in the Universe. We must always strive to adapt to the existence of such dualities as being necessary counterparts, rather than try to bend them to our Will. The problem is: as Humans, we cannot avoid wanting to bend them to our Will, and THIS is the dilemma.

Allow me to digress...

You have a central IT operation that strives to maintain control over a consistent and predictable environment. That is a noble goal. It makes sense. After all, a business cannot quantify it's operational successes and deficiencies without being able accurately quantify, and quantification depends entirely upon predictable elements upon which we can model situations and outcomes, hence the term "known quantity". Without quantification, we cannot qualify a strategy either. Qualification requires quantification in order to provide a meaningful rationale. It simply is not practical to forecast how long it will take, nor how costly it will be, to climb to the next level if you cannot determine what kind of ladder is being used.

The IT operation, typically being a cost center within a typical Western style corporate structure, is an inherent part of the operational fabric of a business. In order to bolster the "bottom line" and keep costs down, they must commoditize many services and products internally. The term "commoditize" comes from "commodity". While defined as having a characteristic of being interchangeable (see Merriam-Websters definition), "commodity" doesn't specifically include a reference to quantity or uniformity, however, it can be argued that in order to be effectively "interchangeable" implies an aspect of uniformity and consistency. The spirit of the use of this term is in the realm of achieving a standard unit which is easily replaced, and therefore easily mass produced by virtue of consistency and functional attributes or behavior.

To commoditize IT services and products is to attain a standard form, which is easily measured, and who's application is easily predicted in terms of it's impact on the business. Commoditization usually finds its way to the production environment in the form of "trouble ticket" systems, call centers, standard configurations of devices, SLA's, SOP's, standard software products (aka "Software Catalogs"), rate structures, tiered service plans, and so on. How they are funded varies, but the goal is usually the same: Attain a predictable and stable environment.

The business operations outside of IT have their own agenda, often due to not being a cost center, but rather, a profit center. While officially part of the same team, answering to the same overlords, profit center players often set different goals, use different metrics, and march to a different drum than the cost center folks do. One aspect that differs most is that while the IT operation seeks to gain stability and consistency, the profit center is all about flexibility, and speed. They are not just focused on these two aspects, they are quite often entirely consumed by them.

This is where the two worlds, IT and profit-center operations, diverge and often clash. One wants to roam freely and hunt down whatever they want to kill. The other wants to build a fence and establish order.

They may clash subtly, with only a smoldering collection of personality conflicts, or may experience emotional outbursts and clashes of great magnitude. The range varies by personalities involved, pressures on each side to meet objectives, and the nature of the business in which they operate. Indeed, the stories of these cultural divides in many companies is often legendary. These are often what drive the most basic yet core cultural aspects of any company. This is often because of personalities, allegiances, politics and strategy, typically ahead of stated business goals.

Not tangible enough for you? ...

The Marketing department at Contoso (sorry, a MCITP exam reference), has encouraged several of their younger and motivated staff to develop tools to allow them to meet crucial short-term goals, as well as help strategize for the longer term goals. They cultivate a crop of applications and content over time that helps them shape their operational processes. It might include Microsoft Access, Excel, Adobe Photoshop, Adobe Illustrator or even Creative Suite bundles, maybe QuickBooks, and an entire army of lesser-known specialty products, that all fit like a puzzle for their needs. The arsenal can grow staggeringly huge over time.

Life is good for the Marketing folks.

Then comes the IT department and their desire to upgrade the operating system and standard software bundle on all the company's computers to gain some improvements in manageability or capability. Maybe they are looking to migrate from Windows XP and Office 2003 to Windows 7 and Office 2010, it doesn't matter, you get the idea.

The developers in the Marketing group announce their opposition to the upgrade because it will "break" many of their custom tools and processes. This is said to be due to having built a large number of Access database applications with integral VBA, forms and reports. The developers insist that tests have shown poor results when trying to upgrade them directly into Access 2010.

The time and effort required to upgrade and test them to work with the proposed upgrade is determined to be cost prohibitive by the Marketing department, so they insist IT, or corporate administration, pay for it. The IT department objects to paying for it because the tools were developed outside of approved processes and by unqualified personnel. Corporate Administration shakes their head at what they perceive to be a power play by both parties that feels like two children fighting over a ball.

The IT department argues that if they are going to pay for the upgrade, then they earn the right to take over the stewardship and maintenance of the application to avoid future mishaps. They insist that they are better trained and equipped to develop software than self-taught college kids, and that they can apply process maturity (read: CMMI, SDLC) to improve quality and reliability. They accede to the claims that this will slow down the process for implementing feature changes, but IT insists it's for a good reason.

The Marketing department argues against losing control, and to the slow turnaround by the IT processes. They also worry about relative priorities, as a requested change might be priority #1 for Marketing, but #50 for IT in the aggregate queue. Marketing panics over the thought of having to wait for the IT developers to gather requirements, analyze them, apply the usual project management sloth framework, and dedicate 0.25 man-hours to three developers, enter the request in a queue, and wait for notification that it's ready to test. Then deal with the methodical, and tedious, project management process to get from Dev to Test to Production.

Marketing has depended upon their own predictability factor: having their own developers on a short leash with direct control over their own priorities.

Neither side budges until either (A) an incentive is introduced, or (B) a threat is introduced, which tips the balance to one side or the other. Only then is there any significant movement towards resolution. But when it's regressed to this emotional level, the eventual "resolution" is not what anyone had hoped for.

If the balance tips in favor of Marketing, the IT folks see it as a vote against their primary objective: control. If it tips in favor of IT, the Marketing folks see it as a vote against their importance and value within the overall priorities of the company. The losing side, whichever it happens to be, sinks into a mental state of "good enough" and "why try harder" since they now see themselves as having been diminished.

And so the the battle begins.

Any of this sound familiar? I have personally watched this scenario play out, almost exactly as described, dozens of times. I still see it all the time. It will never end.

Job Tip 47: High Turnover Warning

2012-01-26T05:00:00.000-05:00

There's lots of advice about seeking a new job and what to look for, how to look for it, when to look for it, and where. You hear a lot about how to investigate what an employer does (line of business), what their current situation is (market performance) and future prospects (news reports). That's all great advice to follow, but there's more. You also need to know the bad side. Just like when you visit a new city, most people will eventually want to know where the "bad parts" of town are, so they can avoid them (or if you're a thrillseeker: get there faster).

Maybe you're one of those people that likes to keep one eyeball pinned on the employment ads to see what's going on in their career sector. Maybe you just like to get a feel for how the employment situation is in a given geographic area. Whatever the case, if you are one of those people, you've probably seen a few repeat employer names pop up week after week, month after month.

Whenever you see a particular employer posting an unusually high number of positions, or the same position for weeks on end, check something else: the employer's growth aspects.

If the employer has not won any major (and I mean MAJOR) new contracts, isn't opening a new facility somewhere nearby, and isn't responding to cyclic or seasonal activity demand, start asking questions. In many cases it's a sign that the workplace suffers from high turnover. High turnover can be (and quite often is) a sign of a bad workplace environment, in which employees grow tired (or afraid) of it, and leave. One particular health services technology company in our area posts over a dozen job openings every week, most of which are the same job opening. Some of which have been reposted for over a year. After asking around I've learned that employer is renown for treating workers badly and thus are always having to back-fill vacated positions.

Then again, if you're OK with high turnover, no worries. Maybe all you are interested in is a fast buck. A quick means to a paycheck, or something to hold you over until make the next jump. That's fine. Everyone has their own agenda. But if you are looking for something more long term, what then?

Where do you start? You can start by asking trusted friends, co-workers, neighbors, and friendly folk at your nearest social establishments (pubs, restaurants, etc.). Just ask "what do you know about (name-of-employer)?" and "are they a good place to work for?". The range of responses will sometimes surprise you, and you may learn things you never expected.

As an interesting exercise, try this using your current employer's name. It's one of the oldest, easiest, cheapest, yet overlooked marketing research a business can do on their own.

Mixing Oil and Water: Systems Engineering and Software Development

2012-01-24T09:00:00.000-05:00

In all my years working this field we call "IT" I have never seen an environment where these two groups coexist cohesively and with a common goal. Systems Engineering and Software Development. Sure, they might get along well, and share working spaces, but as functional entities they typically exist in separate worlds, chasing their own beasts to slay. And why not? After all, they serve different purposes, for different masters (usually). They use different tools and techniques. They often have very different reasons for doing things as well.

The Developers want to create and update things.
The Engineers want to implement and upgrade things.

Hmmm. Those aren't that different after all. Are they? I know some folks would argue that engineers want to implement and "maintain" things, but maintenance is really an operations role, which in most cases falls into the hands of Systems Administrators (or "sysadmins" to use contemporary parlance). Engineers want to engineer things. Simple enough. However, maintaining isn't really engineering, it's really maintaining or administering; keeping things moving along without interruption.

Developers want to create new things. Write new code, new features, new widgets. Add new capabilities or make the interface more "cool" and intuitive. They don't want to maintain things any more than engineers do, even though they have to deal with bug fixes, patches, service packs and regression testing. Life sucks. Nobody said the gravy doesn't have lumps every now and then. Engineers have to deal with those lumps too, especially when transitioning new things into the hands of the SysAdmins. It's life (and it happens to pay pretty darn well, thank you).

So, if these two camps are so similar, and they often possess such awesome potential, when then are they not more often exploited towards a common goal?

Prologue

I'm writing this because this quasi-mythical world is precisely where I've found myself repeatedly over the past twenty-odd years. You see, I started out as a draftsman (on the board, with sepia, paper and Mylar, thank you), and was part of the wave of folks in the 1980's who got corralled into the emerging world of CAD, or Computer Aided Design. That led to customizing the CAD toolset, which sucked me into the world of software development and programming like drunk sailor in front of a Thai brothel (no, I was never in the Navy, nor have I ever been to Thailand, the phrase just seems to fit).

After years of that, I drifted into "mainstream" IT by way of helping an old friend implement SMS 2.0 in a large corporate environment (ok, he did 99% of the work, I just handed him some wrenches), but it was enough to turn on a light bulb in my head about the incredible potential of a networked environment, the tools, frameworks and protocols that make it possible to leverage a whole new level of capability and productivity on a much larger scale. LDAP, ADSI, WMI, TCP/IP, SNMP, the Windows API stacks, Registry, Event logs, alert mechanisms, and so on. Then came ever-increasing power and simplicity with enterprise databases (Oracle, SQL Server), and the arrival of web technologies.

Oh man, I was so there. SO THERE. It was like a labor camp escapee wandering into a Ruth's Chris restaurant on "free dinner" night.

Even now, even when I get involved in another project to inject Development into Engineering, it's the exception, never the rule. In most cases it creates such an oddity that neither camp gets offended, just more or less confused about the value. That is, until the project starts to bear fruit. Then I get Engineers asking about the development aspects, and Developers asking about the infrastructure engineering aspects. It's kind of like the old Reese's Peanut Butter Cup ads from the 1980's.

Continuing On...

As Yogi Berra might have said, I've been doing the same thing over and over again, only differently each time. I am handed some problems to solve, which span multiple systems, multiple departments, multiple environments, multiple business cultures, multiple security realms, multiple personalities, and asked to somehow build something of a bridge across all of it to get the traffic (information) moving. I don't really have name for it. Some call it BPA, or Business Process Automation, or Systems Automation, or Data Mining (not a really great term). Some don't know what to call, so they just give a description like "that stuff Dave is working on". But whatever it might be called, it's where these two worlds intersect. And the result is quite a lot like the Super Hero Action League touching their power rings together (only without the "shazamm!!!" sound effect).

A lot of vendors would argue you can solve almost every problem with an out-of-the-box solution, but anyone who's worked in this realm for more than a decade knows that's as realistic as pocket-sized nuclear fusion power. Maybe someday. Maybe someday.

Putting this a slightly different way: Any time you implement something to abbreviate the steps required to perform a repetitive task, it most likely involves writing a script, a program, or configuring a bunch of options in a widget to enable this to happen. This borders on Software Development. With the advent of PowerShell, especially the concerted effort behind its proliferation, we're seeing a surge in the popularity and prevalence of SysAdmins writing scripts to handle chores that were once considered off limits. Maybe it was because of a bad perception about VBscript or Batch scripting? Maybe it's because PowerShell is becoming so intrinsically part of more and more Microsoft (and VMware) products? Maybe it's because of it's Spartan syntax and brevity (at the command line, not always so within cmdlets)?

I've met so many people in this line of work who have strong feelings about "best practices". Many are of the opinion that unless there's a ready-made product to do something, it shouldn't be done by other means. This is not only short-sighted and foolish, it's downright disingenuous towards the employer. If there exists a means to solve a problem now, even if it requires a little elbow grease, you owe it to yourself, your employer, and your customers to consider it. Especially if this involves existing means which are "free" (provided with the products already purchased: Windows, etc.)

Microsoft didn't provide this insanely broad inventory of API's, protocols, command tools, and utilities for talking about at dinner parties. They were provided for your benefit, and the benefit of their customers to build things to do more than they do "out of the box". Don't be afraid. Don't fear change. The "Soft" in Software was Charles Babbage's gift to all of us that freed us of the Iron shackles to hardware. It was intended, from the very start, to be "changeable". To allow us to adapt processes and capabilities to meet newer challenges.

If you ever, and I mean EVER, enjoyed building things as a child, whether it be Lego's, model kits, model rockets, Linkin Logs, or even stacking wooden blocks, you should find a lot to enjoy building things on the Windows platform. Heck, any platform to be honest, but for this discussion I'm thinking along the lines of Windows. It seems that either a lot of grown-ups forgot how much fun that experience was, or they never got into it in the first place. If you consider yourself an Engineer, and ever wondered what it was that Developers found appealing in their work, it's the fascination with putting things together from scratch and seeing them perform when finished. Engineers get that sensation as well, but at a higher level in the logical technology stack.

In most cases, Engineers are working with components which were provided by Developers, but this is where it often stands and never changes. There's still room for development during the Engineering phase. When the out-of-box components don't hit every note in the song, it can do wonders to get a Developer involved. In most cases, if the right people are involved, the song comes out even better than expected and ideas start popping out for new potential and new directions.

Conclusion

IT is all about change. It's an intrinsic part of the fabric of technology. To fear it is to refuse the absolute purpose in and of itself. Nothing demonstrates, or proves, the value in embracing this more than seeking a convergence between Development and Engineering. Nothing. The teaming of the "thinkers" with the "do-ers" is the ultimate way to push it as far as it can go. As long as these two worlds are kept isolated, or at the very least, un-involved, the less we take this profession seriously and the more handicapped we keep our employers as a result.

Well. There Goes the Neighborhood

2012-01-20T22:21:00.000-05:00

I had planned on retiring from blog writing for the past year. I've given it up before, back in 2008 actually, but came back to it for a variety of reasons. This time it's a little different. Is it because I was inundated with e-mail begging me to continue on? No. Is it because I really didn't want to retire it in the first place? Not really. Is it because I'm going to make a pitch for revenue? Oh, HELL no. It's actually because someone at fairly large company asked me to keep going as part of a beta program. I'm not permitted to say any more than that so don't ask, and even if you asked, I wouldn't tell, and even if I told you, it would push you into a coma from shear boredom.

New Ground Rules:

1. No more shotgun blast posts. Once or twice per week at most, but probably much less than that.

2. Topic focus: The philosophical aspects of merging Software Development with Systems Engineering and Architecture with the world of Business and Social engineering.

3. Whatever I want to say beyond that.

Clear enough?

So, let me revisit some numbers. Where is the blog at with respect to traffic statistics? As of today, this blog as drawn 127,500 page views since May 2009 (the farthest back the new statistics engine will report). The blog was brought back online in December 2007 after a brief hiatus from an earlier start in 2006.

The peak traffic was in November 2011, at around 25,000 page views. January 2012 is somewhere around 10,000, which is expected.

I have some articles lined up for posting soon. Because hardly anyone has spoken up to request topics or general interests, I'm picking my own (big surprise). This should be interesting since I have no idea whether anyone (you) will care. That doesn't matter. The goal is to (A) help out a team of nice folks asking for my help, and (B) exercise my brain while I recover from chemo treatments (I'm doing very well, thank you).

Stay tuned.

Book News: Grinding Gears / Software Repackaging and Deployment for the Windows Platform

2012-01-14T18:34:00.003-05:00

Relax, I'm still in blog retirement. But I did promise earlier that I would be posting an update on my next book and that time has now come. This is now my seventh (7th) book published, and is the culmination of about a year of compiling notes and material and drafts. I've been close to publishing it several times, but then decided to scrap it and start over because I wasn't happy with it. I think I am happy with this one. At this point I have no plans for another book, but that could change.

The book is called "Grinding Gears: Software Repackaging and Deployment for the Windows Platform":

It's not just about packaging, or scripting, or AdminStudio, or Configuration Manager or any particular product or technology. It's about the mindset, rationale, techniques and philosophy behind methods of packaging, repackaging, testing, and deploying software. I've also covered some human aspects, business rationale, and so on. Here's the Table of Contents...

I also wanted to thank a lot of people for helping me and inspiring me...

This book is currently in review by Amazon, and will be available for purchase very soon. It will be published exclusively for Amazon Kindle at $10.99 (USD), and available for Amazon customers in UK, France, Germany, Spain and Italy. Remember, you don't need a Kindle to read Kindle e-books. You can read them on almost any mobile device, tablet, desktop or laptop computer using one of their Reading Apps, or using their Cloud Reader as well.

Meanwhile, you can check on the availability by visiting my Amazon page at http://www.amazon.com/David-M.-Stein/e/B006BHXOFE/ref=ntt_athr_dp_pel_pop_1

Happy New Year!

2011-12-31T10:06:00.001-05:00

It would be rude of me not to wish all of you a Happy and Safe New Year and I hope it is prosperous and fun for all of you and your friends and families! Take care!

Looking Back. Looking Ahead

2011-12-24T04:00:00.000-05:00

December 24, 2011 will mark 5 years to the day that I started this blog. It's been through some interesting times. Some good. Some not so good. It was my crutch when dealing with depression following my being laid off back in 2008. It was my pressure vent at all other times. Sometimes I just needed to share some crazy thought with whomever read it. Sometimes I just wanted to make someone chuckle a little. I pissed off a few people. I let a few people down. I made a few people smile and a few speak up in agreement.

The time has come to put a fork in it though. I may post occasionally, but not nearly as frequently as I have in the past. I spend more time on Google+, Twitter, and Facebook anyway, and those are my pressure relief valves at the moment. If you still want to follow what I'm ranting about, you can hit me up at one of the following links. I'd love to hear from you.

I will likely post an update when my next book is released, which I'm hoping will be in January. That's an aggressive target date, so it might slip if I can't knock out the research I need to finish it up in time.

In any case, I want to THANK YOU for following me this long, or however long you've been following me, even if this is the first post you've read (go back and read some of my older ones if you have time). I also want to wish you and your family and friends a Merry Christmas, Happy Hannukah, Happy Kwanzaa, Happy Ramadan or just a Happy ___(fill in your preferred celebratory event) _____. May you be happy, healthy and prosperous and may you make those around you happier as well.

Twitter
Google+
Facebook

Part 2

2011-12-22T16:02:00.003-05:00

...If the World was perfect, Part 2:

Every Windows platform software vendor would provide ONLY MSI-based installers, and all of their updates would be .MSP patches. Setup.exe files would be outlawed.

Software vendors who publish software that requires users to have Administrator rights would be hanged in public.

Microsoft Access would be banned. The mere mention of its name would be punishable by death. Anyone caught with an .MDB or .ACCDB file on their computer would have their hands sewn to their face.

Wearers of sagging pants would be punished by having their pants removed in public.

Bumper stickers would have to be funny or be removed.

All beer would be required to be 8% or higher.

Marijuana would be legal. Why not? Guns, Tobacco and Alcohol are legal.

Anyone caught arguing over PC vs Mac would be forced to wear a chicken suit for an entire week in public.

If the World was Perfect

2011-12-22T00:44:00.001-05:00

Alas, the world is anything *but* perfect. I'd say that on some days it's horribly imperfect, and on other days it's more perfect than not. A lot of that depends on where you live, where you are at the moment, what your health and financial situation is like, and what your family, work and social condition happens to be.

But IF it were perfect...

Government would actually work FOR the people and try to accomplish something besides playing games and pointing fingers while taking lobbyist money and making empty promises.

Wireless networks would be pervasive across all places, everywhere, all of the time.

Weathermen would be fined for incorrect forecasts

City council and mayors would not be allowed to keep their former jobs at banks, real estate companies and investment firms.

SUVs and Trucks would get their own lane, so the rest of us could see what's happening up ahead (and not have headlights on the back of our heads)

Bike and walking paths would connect every city and throughout each city

A mass transit system would get us where we need to go and when we need to get there, and it would be reliable and cheap.

Religious people would be happy with their religion and stop blabbering about it to everyone else all the time.

There would be no more xxx-American hyphenations. You're either in or you're out. Pick one.

People who save peoples lives would be paid the same as professional athletes.

People who defend our country, especially in active combat, would be paid the same as professional athletes.

IT engineers would be seen as sex symbols and heroes of mankind.

News reports would be required to report ONLY facts, nothing else. No editorializing. No speculating. Every story must be reported in 30 seconds or less. Weather forecasts in 15 seconds. Penalty for going over: labor camp or 24 hours of laxatives.

Political campaigns, including ads, banners, marketing of any kind would be limited to only the last week before the election occurs.

Pro football games would be required to show equal time for game plays as well as cheerleader close-ups.

Anyone guilty of buying the same car, motorcycle, truck, SUV, van or bicycle as anyone else within a 1 mile radius would be sent to work in Somalia for a year. This is America: the land of innovation and imagination. Try to act like it.

Customers would get exactly 15 seconds to order at any drive-thru. After that, a machine would crush the vehicle in a compactor, with all occupants, and dispose of it immediately.

Concert tickets would never cost more than $20.

I'll think of more later....

I ****ing Hate Microsoft Access

2011-12-21T21:37:00.001-05:00

I posted this on my Google+ page, but since I'm sure many of you (ok, most of you) don't ever go there, I'm reposting it here because I'm still pissed off...

Time to Vent...

Microsoft Access is evil. It is the worst God-forsaken piece of shit ever perpetrated on enterprise customers in the history of mankind. It has held up migrations of Office suites in more places than I have days to count. The notion of bundling applications WITH databases is as stupid as riding a bicycle off a cliff. I fucking HATE that application. My teeth are clenched. This is not good. I must continue...

God****it - Access has wasted so much time of so many people's lives that will never be recouped. I can almost forgive IBM for OS/2 Warp, and Autodesk for R13, hell I can even forgive MS-DOS, but I cannot forgive Access. What a fetid turd of technological vacuousness. Is that even a real word? Vacuousness? Whatever. I made it up because thinking about Access pisses me off.

Is there any shortage of reiterated emphasis on "de-coupled" application logic on MSDN? On TechNet? On ANY programming site? Publish a rule and break it. Just as I blogged about with the Configuration Manager AD publishing guideline, but whatever, I need a glass of wine now...

Today makes at least two dozen situations, over the past 12 years, where a customer has to hold up everything because the dipshit department is arguing over upgrading their craphole Access "application" and who will pay for it (you know: "We think YOU should pay because YOU are forcing US to upgrade to 2010" versus "We think YOU should pay because YOU made a stupid garage-app piece of fucking shit mistake that WE are having to pay for in lost time and productivity") Wash - Rinse - and Repeat - AGAIN.

If You Watch One Video on this Site...

2011-12-20T23:05:00.000-05:00

You need to watch this one. Gary Vaynerchuk has been around for a long time, even before Wine Library TV, he was a mover and a shaker. A brilliant guy. Pardon the language (NSFW), but the message makes the f-bombs forgettable. Enjoy!

Six Days and Counting

2011-12-18T23:32:00.000-05:00

I've still been posting things as you can tell, but the days are winding down fast. Six more left.

Meanwhile, I've been working on my next book, and it's killing me. I'm hoping to have it out in January. It's the biggest book I've done yet, and much more complex and challenging. That's all I'm going to say for now because it's still not a 100% done deal at this point. I will post something when it's for certain.

A Circle of Imaginary Links

2011-12-17T10:05:00.001-05:00

Anyone who has worked with Configuration Manager for a while knows about Packages, Programs, Advertisements, and Collections. They also know the difference between "Software Products" and "Add Remove Programs" as it pertains to inventory reporting. Seasoned software packagers (or more appropriately termed "repackagers") know about creating .MSI and bootstrap .EXE InstallShield packages as well. But there's a sinister problem lurking in all of this...

The names assigned to Packages, Programs, Advertisements and Collections are arbitrary. Sure, many places have adopted standards for naming things, but still, it's a human dependency.

The names assigned to an application are controlled by the vendors, but only if they created the application. And then there's the issue of how well they apply consistent naming standards to their individual components.

Just yesterday I was poking around to find how many installations of a product at version "7.11.3" were in our environment. As I watched the report start to build, it was showing "7.10" and even "7.9.1" installations as well. But the engineers assured me that the package they deployed had uninstalled previous versions before initializing the new installation. After some investigation, it turns out the vendor left components in their 7.11.3 installer that still identified themselves as "Product Name 7.9.1" so Configuration Manager dutifully picked it up and reported it. Switching over to the ARP (that's Add or Remove Programs list) report, it correctly showed 7.11.3 was the only installation.

I won't even get into the products that dump garbage components on computers that identify themselves with product names like "Update", "O&%$__#" and "Company Name". So far, free markets and consumer-driven competition are not doing much to fix that mess, but neither would and overly restrictive government regulation. It's just typical stupid human behavior (e.g. laziness).

Back to the topic.

So, when pulling a report of what software is installed on computers, it can be helpful to also include some attributes for each product such as "Is-Packaged", "Is-Windows7-Ready", "Is-Current-Supported", and so on. You can beat some of that out of Asset Intelligence, but some you cannot. For example, to really know if an installed product has a corresponding Configuration Manager Package and Advertisement, you need to somehow relate the installed Product Name and Version to the Configuration Manager Package and Advertisement. Sounds easy enough, right?

Ok, you've got an environment where you have deployed 500 installations of AutoCAD 2012 using a network license client, and 25 of AutoCAD 2012 with a standalone license. From ARP reports it will show them all as "AutoCAD 2012 English" or something generic like that. But you can't use the same package to deploy both (well, you could, but now we're talking about some twisted branched logic in the package using a script or some other intermediary program logic), so how would you know that you've got "A Package" for "AutoCAD 2012" and which one it belongs to?

Even if you switch to linking to the Installed Programs list (pulled from a query of .EXE files on the computer) it would show "AutoCAD 2012" or "AutoCAD R18.x" or something like that, not "AutoCAD 2012 Network Client", because they will both read from "acad.exe" and the only difference you could pull might be the size of the file itself. What about products that are only installed as part of another product advertisement? What about all those Autodesk Design Review and DWG True View installations that were placed by your various AutoCAD and Revit and Inventor deployment packages? How do you automate the referential integrity of those applications to a source package and advertisement?

In case you haven't already surmised, this is all analogous to Reverse Lookup DNS. Forward lookup is easy: This package and advertisement installs this application. Fine. Now, what package and advertisement installed this application on these 100,000 computers? How do I automate that workflow?

What happens when you have in-house developers and packagers putting together things to deploy? How about those not uncommon cases where the package doesn't really install a product, but registers components and files that support another product, but which are given their own name by virtue of how business operational minds like to give names to things that don't really exist? You know, when you install and register three DLL files, open a firewall port and now the user can access a special web application in their browser, so that deployed bundle of crap is given the name of whatever it is that they connect to via the browser. It's not really an installed application, is it? If the users rely on this to connect to a web application named "Fubar", good luck convincing them to call it "installed components to support Fubar". They're going to call it "Fubar" and ask "when are you going to get my Fubar installed?" Oh yes. You can bet on that.

I'm digressing. It's much easier to convey this verbally than in writing. I have lots of stories to illustrate this weird delusional mess.

This is the mind-bending thought process that swims around in my head as I've been building a web-based asset management process for a customer. The process allows them to overtly control these arbitrary relationships for more than just reporting. It also allows them to manage distribution that comes into play when executing computer replacements versus computer refreshes (refresh in this case means upgrade the OS and map in required application upgrades at the same time).

For example, the computers in a particular department-based collection all have XP and Office 2007, but they will be reimaged via SCCM OSD with Windows 7 and Office 2010, but they each have unique LOB (line of business) applications installed. Many require an upgrade to work with Windows 7, or the customer budgeted for new versions based on feature enhancements and decided to tie it into the same upgrade window. Regardless, they needed a quick and easy way to select an upgrade mapping individually and in batch to say "these computers get the newer version" and "these don't get an upgrade" as well as "remove it from these computers entirely". It's much more complex than this, but that's a simplified example.

In short, all I can say is that I LOVE working with this stuff. It falls squarely in the field of work I crave: "Windows Platform Business Process Automation" or WPBPA. I believe I invented this term, so neener neener neeeeeeener. I need some breakfast and coffee as I've been up all night working on my next book project. Holy cow - what sleep can do for you. Cheers!

Amazon Prime Members: Check This Out

2011-12-16T19:19:00.003-05:00

I am enrolling several of my ebooks in the KDP "Select" program, which makes them available for free check-out, on a monthly basis, to Amazon Prime members. For more information check out Amazon Prime and look in the Books section. The books I am enrolling in this program are:

The AutoCAD Network Administrator's Bible, 2012 Edition
The Visual LISP Developer's Bible, 2011 Edition
The Packager's Pocket Reference, 2nd Edition

I am also working on another book focused on software repackaging and deployment for Windows platforms. It is tentatively due for release in January 2012. When it is released, it will also be added to the KDP Select program.

Thank you!

Database Digressions and Developmental Digestion

2011-12-12T11:45:00.001-05:00

Put on your caffeine hat and come with me on a voyage into the ethereal world of nerds versus geeks. That's the party peel-off sticker I'm slapping our foreheads, written with a blunt Crayola crayon. With enough alcohol and caffeine it will all make sense soon enough. Let's go...

I would venture to say that 99.99 percent of software development projects, probably even software development organizations, are arranged into de facto groups that place the application "coders" in a separate function from the database folks. The problem this has created has been legendary. It's not only led to human behavioral issues and philosphical approaches to address such structural idiosyncracies, but it has also led to mechanical approaches, such as LINQ and XPATH, and so on. Trying to fit automation processes to human processes is always a challenge, on a good day. When the human process is broken, it's a disaster that unfolds slowly and often at an incredibly high cost (both in terms of time and money).

Did i say INCREDIBLY high cost? Yes. Incredibly high. The problem is that it's almost always a secondary, or tertiary cost. The kind that don't stand out in distinction on a balance sheet, so they often hide in the margins. Those are what often lead to bad feelings between IT groups and the Financial groups. The main reason is that the Financial folks are left to ponder where these strange, nebulous cost creeps are coming from, while the tech-minded IT (Dev) folks are rarely prepared to articulate and quantify them adequately. They may indeed "know" where they come from, but cannot communicate it in the language of Finance, so they shy away from it, making the problem worse over time. This is analogous to a couple that don't discuss sensitive issues because they know they will always turn into an argument.

Mechanical Aspects

I'm digressing into the human/financial aspects. But what about the structural and mechanical aspects?

I have mixed feelings about things like LINQ. It's technically a very clever, impressively creative approach to translating mental processes from one world to another. But at the same time, I've rarely seen die-hard DBA's embrace it over traditional SQL/T-SQL, so the divergence is not only mitigated, but elevated with yet another wedge driven into place. A classic example is when a Dev guy walks over to ask for help with a complex SQL query that was coded in LINQ (or anything other than T-SQL) and the DBA looks at it and says "Sorry. I work with SQL. Can't help you." I am aware there are exceptions to this scenario, but they are "exceptions", not the general, majority rule, at least from what I've seen and heard. I admit that I haven't seen or experienced every environment, so I'm obviously speaking anecdotally.

I'm picking on LINQ unfairly though. It's not really a fault of LINQ. It's a respectable concept and the incarnation has evolved respectably as well. It's somewhat of a situation of "blaming the messenger" when the message is the problem. The message is unavoidable though. The message is a symptom of an age-old broken human condition in the IT environment: divisional politics. Not departmental, but "divisional" in the same sense as "functional", whereby the DBA and Dev folks are functionally divided. They may be best of friends. They may be mortal enemies. It doesn't really matter, since they still focus on, and operate within their own distinct worlds, with their own unique languages and customs.

Bridges of Translation

If you are in a large enough organization to afford the luxury of a dedicated API group, they may be your bridge. Having to convey the wishes of the AppDev folks with the plumbing capabilities of the server and DBA folks, they become the liaisons of different cultures and dialects. They may even provide the abstraction that spares the AppDev team from the horrors of learning a different culture in order to cook their programmatic banquet meals. If you're not that fortunate, it sucks to be you, maybe. Just kidding. Ok, I'm really not kidding, it really does suck to be in that situation. I've been there so I'm not trying to condescend as much as sympathize.

Ramifications

The end result of these cultural divides is that databases go in one direction and code goes off in another direction. Efficiency suffers. Progress is stammered. If the groups are in different physical locations (different rooms, buildings, cities, countries) it only exacerbates this further by making it too easy to cultivate an "us versus them" environment. If you have any poison pill personalities in either group it can be gasoline on a smoldering fire, so be careful of those.

Light at the End of the Tunnel

If you can bridge the divide, it is always worth the effort. Always. I cannot stress that enough. Even if pride is a boulder to swallow, break it into smaller pieces and work on it. Offer some concessions, some goodwill, something to prove any ney-sayers and poison pills on the other side incorrect about their assumptions about your group. Conversation is key. Get the people talking. Learn what the other side has to deal with. Maybe there are pains your group causes them that you're not even aware of. Just learning about such things can help you refocus and make adjustments that may seem minor on your end but could be HUGE on the other end.

Making exchanges of conciliatory effort can go a long way towards building a stronger team, improving communication, raising productivity and positive outlook, and ultimately making a better product. Quality can't happen without a cohesive group of people, and you can't bridge any divides by waiting for the "other side" to make the effort. You often have to make the first move and meet them halfway. Ultimately, until people issues are resolved, you can't achieve an efficient operation or efficient processes. This is where most of the bullshit forms-bloated corporate environments grew out of. People issues give rise to barriers of mistrust and push-back over perceived unfairness of responsibility and effort. You can throw billions of dollars at trying to make those processes automated but if they attempt to lift the human process into a computerized process model, it will be horribly broken, and inefficient at best.

Before you ever consider purchasing or developing a system to model a business process, do some deep analysis of the process itself. Never start with the current process as the assumption of efficiency. In most cases it's nowhere near what it should be. Fix the process. Build cohesion. Push forward, but don't drag the baggage along. It may look frightening at first, and people will scream and complain and flip out, but if the process is re-modeled properly, nobody can argue with a better model. Once that's done, you can translate that into software and hardware and move on to the next challenge.

A Stack of Quarters

2011-12-11T21:38:00.001-05:00

Sometimes I stop and ponder simple things. Maybe it's because I'm getting older. Or maybe it's because I don't have a "life" so it leaves me plenty of time to spend on pondering simple things. Either way, I'm sure it would make a long-dead Chinese philosopher proud.

Today, I was playing with a stack of quarters (coins) and thinking about how I perceive the value in them. My financial situation is fair at the moment, but follows a predictable wave and trough pattern with each bi-weekly payroll cycle. On pay day, it's just a stack of quarters. By the second week however, it's my next cup of coffee and snack. When I was laid off a few years back, and unable to find a job, that stack of quarters was precious. I looked at it like a crash survivor would look at the last bottle of water on an isolated island.

It's still, and has always been, just a stack of coins. Their intrinsic value had never really changed. My value of them however changed greatly. It still changes, just not as wildly.

After that thought had run its course, I looked around the room to assess what other material objects fell into this strange bucket of perspective. My TV. My clothes. My blankets. But what about family and friends? Yep. And as absurd as this might sound, and impossible to believe, it's true. It's true for you as well. Here's an example...

You say good bye to your parents after dinner. You kiss your kids good night. You let your dog outside. You do your routine things. But the second life crosses things up and you almost lose one of them, suddenly, immediately, they become incredibly more precious and valuable. Any parent who has panicked while searching for their child in a crowded place knows damn well what I'm talking about. After any perceived threat to the stability of your bond with those you love has occurred, your value of their well-being, their existence, their love, their presence is magnified millions of times.

Is it really just a stack of quarters?

Counting Down and Catching Up

2011-12-08T18:52:00.001-05:00

Only 16 days left until this blog is retired. To catch up on my boring stuff. Warning: This post contains a lot of aimless rambling, but with the name "skatterbrainz" I hope you didn't expect anything else...

I'm still working on multiple projects and another book (maybe). The book is becoming a much bigger project than I expected (not the book on packaging either, totally different topic), so I may be having to make a go/no-go decision soon. It will depend on how well I can reign in the scope and keep it manageable. Otherwise it will be yet another scrapped project. I'll keep you posted on Twitter and Google+, which is where I will be spending most of my time from now on. Some Facebook as well. Friend me or follow me, whatever you like. I could use more friends on Twitter, but I'm using Google+ more than anything else right now. I just like the vibe at this point. It reminds me of Facebook in 2006-2007, before it got bloated and stupefied.

I finally ditched the Blackberry. My 11th Blackberry device since 2000 actually. I now have a shiny new iPhone 4S 16Gb, and I love it. I can't stop playing with the damn thing. I spent a few days in and out of the Verizon store comparing the Androids and iPhones (they didn't have any WP7 models on hand, go figure), and decided on the iPhone 4S mainly for two reasons: The price and the form/size. Some folks refuse to accept that I don't want to friggin huge screen. I want something I can carry and drop in my pocket without looking like a brick. I don't watch a lot of movies on a mobile device, I'll use a laptop or a TV (gasp! a real TV?!) So I'm happy with this for now. Maybe later I'll grow tired of it and yearn for something different, but I'm good for now.

The Windows Web Admin project is long dead, but a lot of it lives on a much bigger project I've been building for a customer. I have to say I love working on it and it's turning into much more than I ever expected. I'm glad the customer likes it as well, that makes it a win-win.

My current arsenal of gadgets to entertain my life:

Windows 7
Google Chrome 17 /dev
Office 2010
Paint.NET 3.x
TextPad 5
Windows Server 2008 R2
VMware Workstation 8
Calibre (for authoring e-books)
System Center Configuration Manager 2007 R3 and 2012 RC1 (lab setup)
WSUS 3 SP2 (at home, yes, at home)
InstallShield AdminStudio 10 SP2
SQL Server 2008 R2
iPhone 4S (foshizzle!)
Kindle 3 (love it!)
A 1995 Subaru Legacy with 160,000 miles (runs like a champ)
A dog, standard model Beagle, female
A cat, standard model black-n-white, female

In a short while all of these will appear outdated, including myself.

Thought: As a systems engineer / consultant / architect / developer / nerd / geek, I've come to accept that all that I work on will eventually be replaced and forgotten. I think back to all of the folks who pioneered new things in the 1980's, 1990's, and early 2000's, who's efforts paved the roads for progress. Most, if not all, of their accomplishments have been replaced and forgotten. My grandfather made furniture. I'm sure there are people still rocking in his chairs he made decades ago. Sometimes I wonder what "progress" really is.

How AutoCAD Changed the World

2011-12-04T13:32:00.001-05:00

That's kind of a bold, hype-ish title, am I right? You're probably rolling your eyes, or saying "yeah, sure, whatever" or something like that. But give me a chance to explain...

Back in the early 1980's, if you did any "design" or "drafting" work, you were most likely working on a physical drawing board and tracing your ideas out on Vellum, Paper, or Mylar sheets using various kinds of mechanical pencil materials or maybe a Rapidograph ink applicator. Maybe you used templates and lettering guides, or shape tracers or flexible curves and those stupid-looking weights we called "ducks" or "whales". In the mid-1980's came the first real significant influx of computerized design technologies. They had weird names like AutoTrol, CADAM and so on. They were collectively termed "CAD" for Computer Aided Design. If they were connected to manufacturing machinery, they were called "CAD/CAM" for CAD + "Computer Aided Manufacturing" (or "Machining"). If they did engineer calculations from design data, they were called "CAD/CAE" some were "CAD/CAM/CAE" and some were just stupid and we called them "overpriced crap". But they were magical for their time.

Here's the snapshot of "before": These first-generation CAD/CAM/CAE systems only, I repeat ONLY, ran on UNIX platforms. Not only that, but most were tuned for specific UNIX platforms, so they were hardware specific, such as DEC, IBM, Sun or a few others (most of which are all gone now). The software alone was often in the $10,000 to $30,000 range PER SEAT. The hardware was just as expensive, or even more expensive. I worked on one system back in that era that was priced at $50,000 for the hardware "workstation" and the design software. Keep in mind that you HAD to purchase vendor support since they did not allow you to work on it yourself, often keeping many of the features, settings and capabilities secret until you paid someone to reveal them to you. Oh yeah. Good times they were not.

Then came along some scrappy little company named Autodesk and they had this cheap little CAD product called "AutoCAD" that actually ran on an IBM-PC. The other vendors laughed and tried to ignore it. I remember an IBM rep saying to us "that's a toy - a piece of crap that'll never go anywhere". I sure wish I could have recorded that for later on.

Maybe you've heard the story of the butterfly that caused a hurricane. This is very similar.

So, as this tiny little snowflake rolled through the fledgling IBM-PC "compatable" market, it began to gather some snow and grow bigger and heavier. For the peanut gallery out there: I'm not implying it was bloated. It wasn't. It became heavier with customers and customer momentum. Still a bit immature at R9, it made heads turn at R10 and R11. Then R12 came out and that snowball was now the size of a truck and rolling faster. As the UNIX market began to respond, it lost some of its footing as well. The big players started losing key developers and managers to smaller startups, all trying desperately to stir up excitement to fend off this new upstart called the "PC". Computervision stumbled, which led to Intergraph and Pro/Engineer. CADAM, Unigraphics and others started making adjustments, and even tried "realigning" licensing costs, but they caught some breathing room when Autodesk stumbled with R13. Then came R14 and it was pretty much a done deal as far as customers balling up those checks for the expensive UNIX fees, and stroking new checks to the much less expensive PC product lines.

As customers moved from UNIX to Windows and Windows NT at an increasing rate, so too did many stalwart UNIX product vendors. CAD/CAM/CAE products previously only available on UNIX were suddenly announcing PC versions. Even the most discerning NASTRAN vendors were poking at the PC market, especially as the PC hardware specs began an accelerated upgrade path.

I saw this firsthand at least four employers, and dozens of businesses I interacted with, and multiple branches of the U.S. Department of Defense: Navy, Army, Air Force, USMC, Coast Guard, even NASA.

No other PC-based CAD product had as much impact on the CAD market, and pushing customers to take the PC platform seriously. It also pointed the light on their budgets and ROI, and suddenly program managers were faced with making serious choices about continuing on with their life-draining budget expenditures, or doing some soul searching about this new PC-based direction.

The rest is history.

Is the UNIX market dead? No. Not at all. Has it scale back? Yes. Most of the major UNIX vendors from Compaq, Sun, Prime, DEC, Silicon Graphics, Helix, Unigraphics, are gone, or have been acquired and renamed. IBM, Dassault, and Integraph remain vibrant, while PTC has undergone multiple shifts in product and services offerings, but seems to be alive and well. One major change from twenty years ago has been the emergence of Siemens.

But even with these legacy companies still bouncing along, they've ported most, sometimes all, of their products to the Windows platform. Love them or hate them, that little snowflake had an impressive impact indeed.

10 Nerds You Should Be Thankful For

2011-12-01T23:10:00.001-05:00

Sources:

Yeah, I used a lot of web sites, but most of them were nearly identical with Wikipedia, at least as far as the basic stuff I was looking for, and it had the others linked as well, so, whatever...

Refactoring. Part 2

2011-12-01T22:39:00.001-05:00

Guitarists search for more efficient fingering patterns. Percussionists search for more efficient sticking and foot patterns. Cooks search for more efficient cooking methods. Delivery drivers search for more efficient routes. Athletes search for more efficient technique. Programmers search for more efficient algorithms and coding methods. If every new year you don't look back at the previous year and think "I really didn't know shit" compared to what you now know, you're not growing. Refactoring is a means of growing.

AU Virtual 2011 - Network License Manager Course

2011-11-29T12:44:00.001-05:00

If you haven't done so already, you should definitely check out Jimmy Bergmark's course on "Autodesk Network License Manager". It covers a vast amount of information about setting up, configuring, managing and troubleshooting the FlexLM environment and your Autodesk products. Good stuff! Highly recommended.

Panning for Gold

2011-11-26T11:14:00.001-05:00

"Using scripts to process data is more like panning for gold than transmuting lead into gold. So if there is gold in the garbage, the scripts can find it, consolidate it, and output it in a shiny pretty form. If there isn't any gold, then you will just get some finely sorted and polished garbage." - Joe (Joeware.net)

I couldn't agree more. It takes the age-old phrase of "garbage-in = garbage-out" and sprinkles some technical context on it like a good seasoning on a grilled chicken (can you tell I'm hungry?)

This also reminded me of a quote from a colleague (and former supervisor) regarding the use of software-based "automation" for business processes: "If you automate a broken process, you only get an automated broken process." (fix the process before you try to automate it!!)

Good Enough is NOT Good Enough

2011-11-24T10:40:00.001-05:00

Since the dawn of mankind, the popular perception of the status quo for almost every single "technological" thing was "it works fine, why change it?" They said that about the chariot, the map of the heavens/planets/sun, the catapult, the bow and arrow, the wagon, the castle and moat, the front-loading single-shot pistol and rifle, Sulpha drugs, leeches, slavery, battleships, Model T cars, steam engines. Remember Roger Bannister? Yeah, EVERY single "expert" and physician of his time swore on a truckload of Bibles that any human who broke the 4 minute mile would die. The human body simply couldn't achieve that goal.

Then someone stuck their neck out and said "fuck that!". I'm sorry if that offends you, but that's essentially what they said/did. And for doing that they were ridiculed, shunned, banished, jailed and even killed. They dared to disagree with the Status Quo; the masses; the majority. Nearly every single one of the people the broke those de facto "rules" or "limits" endured mockery throughout their efforts to break the barrier they set out to overcome. Some never saw recognition, as they died before the "masses" woke up and realized that they had indeed done something incredibly helpful or history-changing for mankind.

Remember the story of Thomas Watson Sr. and Thomas Watson Jr.? The infamous head of IBM who insisted a "personal computer" was a dumb idea and would never be practical. Junior waited until his turn came up and then he seized upon the moment to introduce the "IBM personal computer". Same thing for HP and Atari and Steve Jobs and Steve Wozniak.

So, when I look around at the stupid crap we just "live with" and pay little attention to, saying things like "it's worked for years/decades, why change it?" I want to shake my head in disbelief that we've given up. A bar of soap? A toothbrush. Deoderant. Frying pans. Toasters (have they ever been improved? it's long overdue), Roofing Technology, Door ways. A coffee cup. Software. Computers. Aircraft. Surgical Procedures. Medicine. Cancer Treatments. Education systems. Weapons technology. Network routing and throughput. Movies. Music. Art. Food. The list goes on and on.

Never say "good enough"! Anything you point at can be improved upon. Anything. Maybe not in our lifetime. Maybe not until future discoveries lead to secondary potentials to be realized. But they will happen. The longer we stand still, point and say "it's fine as-is" the longer it will take to make it better.

Most people look at Cancer treatment and say "wow, look how far they've come.", until their 5 year old child is diagnosed with Cancer. Then it quickly becomes "when will it be cured?" and "why can't we make faster progress?" Aircraft are just fine until the next crash investigation reveals a design flaw. Music is just fine until you hear that one new song that grabs your attention and makes you ask "who is that?!" Same for art, movies and food by the way. And software? In 2004 there was no Facebook. There was no Twitter, FourSquare, Yelp or UrbanSpoon either. In 2000 there wasn't any Google either. No VMware. All the "smart" phones were bulky, limited and boring. Are you old enough to remember the first laptops? The first microwave ovens? The first video tape recorders? The first tablet prototypes in the 1990s? Today those things seem like steam engines. Remember when car companies swore air bags, even seat belts, were a complete waste of time? Remember when they thought stomach ulcers were just bad luck and you had to live with them?

Good enough is NOT good enough. Ever.

Google Plus vs Facebook: URL Resolution

2011-11-23T20:52:00.001-05:00

You know that nifty, clever feature, where you paste a URL into Facebook or Google Plus, and they chew on it for a second or two, and then create a mini-snippet to post? Usually, they pull in a graphic and maybe the page description, or meta-description. So, I noticed today how different they really are. I also noticed that, as much as I really don't like Facebook anymore, it does a better job of rendering and polishing that result before posting it. Case in point: I posted the URL to an interesting book (ha ha!)... http://www.amazon.com/Stuck-Up-Inserted-Ingested-ebook/dp/B0056DR5KY into Facebook and Google Plus. Here's how each of them rendered the result...

Facebook

Google Plus

Google Plus pulls in the authors and makes it part of the subject heading, but it ends up being too cluttered. The Facebook result is cleaner and easier to read. Also, the descriptions are very different. Entirely different, actually. I think the Facebook result wins.

When They Just Don't Get It

2011-11-22T20:15:00.001-05:00

I was driving home from work and thinking about ponderous experiences in my past career endeavors. I do that sometimes when I'm not speeding and weaving around like a blind man with Turrette's. It stemmed from a lengthy discussion with one of my nephews about our relative "quality of life" and "career satisfaction" stuff, and so on. Guys often get into this subject matter after blabbering about titties and power tools. (There's nothing wrong with either of those, but you can only talk about them so long before you run out of superlatives and metaphors.)

I said to him "I think I'm in the best situation I've ever been in, at least so far. I'm enjoying it while it lasts, because nothing lasts forever."

We digressed into two aspects of that statement: one for each sentence.

As for the second one (I'm working in reverse): I've been in too many "sure bet" situations that suddenly turned a wrong corner. Once after 10 years, another after 7 years, and another after only 5 months. Shit happens. When you've had a CEO shake your hand and hand you a mixed drink, smile, and tell you with utmost sincerity that "your job is as safe and secure as it could possibly be", only to close your office and lay you off two weeks later, it tends to leave to an impression. That was five months into the new job. The 7 year job was one I thought I'd retire from and live happily ever after. The CEO of that place turned into a vindictive paranoid dick and stabbed everyone, even his VP's, in the back and left with a golden parachute. Those two situations, along with the death of some very close colleagues, really hit home with me and given me a perspective that you have to plan for the worst, hope for the best, and be prepared for whatever comes next.

Enough of that though. On to the first sentence...

As far as building cool applications are concerned, at least where I define "cool" as (A) fun to write code for, (B) produce something that helps not only myself but those around me, and (C) is actually beneficial to my employer's line of business, I can point to three distinct experiences:

Employer 1 - I had an idea to build something that was helpful for my group, but the company pushed back hard at every turn. Their rationale? I was hired to do job "A", so working on something outside of that, even though it automated more than half of what job "A" entailed, was outside the duties of job "A". Period. In one situation, I was flat-out told (and I quote): "We are a defense contractor. We don't get paid to save time. We get paid for the time it takes to do it right." Awesome reflection of the true American work ethic. Regardless of being approached by four peer-level businesses to license it, and three government agencies, the employer refused and effectively killed the project.

Employer 2 - I had a manager with amazing vision and self-direction, who approached me to help him build something that was aimed squarely at automating our daily workload. It grew and grew, mostly with his ideas and direction, based on what he had seen accomplished at each step, and propelling it on to the next level. It was a cool project indeed. The company fought back, again, with a slightly different rational: "Your group is tasked with "A" not developing software. If you wanted a solution, you should have requested the AppDev group." Translation: feasibility studies, requirements analysis, pre-dev evaluation, code and test, evaluation, UAT, the whole stupid-ass CMMI assembly line. And this is to build something that really warranted none of that excessive bullshit. The real aim was control and something to provide time-charge coverage for a bunch of people with not enough work to cover them. In the end, I left and another developer was brought on to continue work on it, but it was eventually given over to the AppDev group and given the lobotomy treatment.

Employer 3 - Both my manager, and the entire management structure saw the results of a small example, pulled me aside and said "do more!". Regardless of my official duties, they allow me incredible latitude to push things as far as it makes sense, as long as it produces results that satisfy others. So far so good.

To sum this up: One place let me build a car but not let it out of the garage. The next place let me build a car, and get it out on the road, but not go faster than 55 mph. The next place let me build it, and take it out on a race track with no limits.

Conclusion

Regardless of technology. Regardless of technological potential. What most often holds back progress, or often outright KILLS it, are people. People with narrow vision, no concern for innovation as it pertains to making real progress, are what build speed bumps. Vision builds roads with few potholes.

No place is perfect. I'm not going to even attempt to say that Employer 3 is perfect. That would be nonsense. But finding the right balance between ideal and tolerable is what makes things work for each person. It's like a girlfriend or boyfriend. You'll never find perfection, but if you can find enough good traits to outweigh the bad ones, it can often work out great.

Each of the three employers had plenty of skilled, intelligent, funny and progressive people. The problem for two of them was a barrier of culture that keeps them from achieving their full potential. I know for certain that most of the people I had worked with, if placed into different environments, would damn near explode with positive results. A suppressed culture suppresses everyone within it. Whether it's by standing up roadblocks, meetings, committees, reviews, forms, forms and more forms, and decisions made by people with absolutely zero understanding of the case being decided, or by the nature of the work itself being limited to one road, rather than a network of roads with unlimited potential, the environment shapes the potential of every employee. The employees become the environment and it becomes them.

All I can suggest is this:

Look for the barriers, the obstacles, the roadblocks, and if you can't remove them, try to work around them. Find a way to get your ideas into action. My manager at Employer 2 did just that, and pressed ahead against incredible push-back and apathy, and refused to give up. I simply drafted behind him enjoyed the opportunity to break out of the assembly line work I was hired to do. If you have a good idea, find others who will listen. Band together and share your ideas and feed off each other's positive views. If you're lucky, that's an easy thing to do. For a lot of people it's a struggle, but don't give up. Do the homework and confirm your beliefs with hard facts and numbers. If you think it will save time and money, be ready to back up your estimates. It's really hard to argue against good numbers. The real people in power live on numbers.

When you run into people at work that just don't get it, move on and find the ones that do.

Book Update: Corrected Version Coming Soon

2011-11-21T23:51:00.001-05:00

Unfortunately, there was a problem with formatting that was discovered after I published "The Packager's Pocket Reference, 2nd Edition" for Amazon Kindle. I have uploaded a corrected version and have asked Amazon to repost it and email customers to notify them of an updated version. The update is free for those who have already purchased it. I apologize for the inconvenience and as always: I appreciate your support.

Thank you! Dave

Stupid Assumptions

2011-11-21T06:00:00.000-05:00

After years of watching sci-fi TV shows, movies, etc. it's finally come to a point where even the so-called brightest of our authors and screenwriters are annoying the shit out of me. Why? Because the common, no, strike that, not "common", but more accurately, the "only" view they seem to follow is that interplanetary/intergalactic "aliens" will fit the following mold:

Intelligent
Two legs and two arms (yes, I've see the others with octopus bodies and heads like bugs)
Two eyes and a mouth (or three eyes and no mouth)
Most of them don't have a nose (wtf?)
Their vision is in the same light spectrum as ours
Their hearing is in the same frequency range as ours
They sense heat and cold like we do
They wear clothing to cover their naughty bits (or don't have any naughty bits)
They don't smell really bad
They don't make obnoxious sounds (farting, snoring) all the time
They don't leave trails wherever they go
They understand our body language and colloquial aspects

What if? What if they smell like shit? What if they ooze from all their pores all the time? What if they leave a slug trail? What if they find some of our gestures aggravatingly offensive? Imagine that some of our common names for things sound like words they use to describe offensive things. What if they introduce themselves and have names like "fuck" and "c**ksucker"? Go ahead and smirk and laugh, but what if they sounded so much like that we'd do a double-take? What if reaching out to offer a handshake is a sign of aggression in their culture? What if we look like food to them?

What if they like to be naked and they have six 24-inch penises sticking out from all around them?

What if they have eight testicles that hang from beneath their face?

We all know about culture dichotomies like how cows are viewed in America versus India. How handshakes are viewed in the Middle East, versus Japan or Africa, and how showing the soles of your feet when sitting down is offensive to some cultures, as is offering your left hand to shake (or even wave hello). So we see cows as a source of milk and food in America. They exist to provide milk and be slaughtered for beef. In India they let them walk the streets like we view dogs and cats. What if aliens view horses and dogs the same way? What if they view skin tones in that way? What if brown skin is ok to have around, but pale skin means extra crispy batter coating? What if?

You're probably snickering. Most humans would. That's because we humans know everything. We can predict everything. We apply our logic to predict what can be possible beyond what we've experienced. We are awesome. That's why we can predict the stock market so well.

Guns vs Marijuana

2011-11-20T16:14:00.001-05:00

I'm not picking on, nor condoning, either one of these. I'm just doing a brief comparison and contrast...

Argument	Hand Guns	Marijuana
Blame Assignment	"Guns don't kill people. People kill people"	"Gateway drug to Heroin and Crack"
Alternatives	Knives, Bottles, Bombs, Fire, Poison, Heavy Machinery, Fists, Feet (with or without boots), Blunt Objects, Piano Wire, Workshop Tools	Alcohol, Salvia, Meth, Paint, Cleaners and Solvents, Redi-Whip cans
Who Stands to Gain	NRA, Gun Manufacturers	Private Citizens, Fast Food Vendors, Pizza Shops, Chinese Take-Out, Soft Drink Vendors, Nabisco, Keebler, Kraft, Kellogg, General Mills, Coke, Pepsi, 7-11 and Convenience Stores, Concert Venues, Musicians, Theaters and Movie Producers, Cable TV PPV
Who Regulates	Federal, State, Local	Federal, State
Casualties	Thousands per Year	None documented
Accident Consequences	Death, Debilitation, Property Damage	Munchies, Sleep
Environmental Impact	From raw material extraction, to material stock refinement, to machine refinement, to chemicals and solvents, to combustion vapors, to spent shells.	Small amounts of smoke
Places Most Often Used	Target Range, Liquor Store, Pawn Shop, Back Alley, Living Room, Trailer Park, Bar Parking Lot, High School Cafeteria	Living Room, Den, Bedroom
Extreme Cases	SWAT team, Fire Department, EMT and Ambulances, Coroner, Evacuation	Red Bull

2011-11-20T11:09:00.001-05:00

It is now available on Amazon.com!

Download a free sample or buy it for only $7.99

Available for US, UK, Germany, and France Kindle shoppers.

Don't have a Kindle? No problem. You can download FREE Kindle Reader Apps for Windows, WP7, OSX, iOS (iPod, iPhone, iPad), Blackberry and Android

Still not satisfied? You can use the Kindle Cloud Reader to read books in your web browser too.

Book Announcement: Packager's Pocket Reference, 2nd Edition

2011-11-19T02:04:00.000-05:00

The 2nd Edition is out! Chocked full of new examples, reference information and new chapters on lab setups, methods and approaches to making packages through a variety of means. Scripting, packaging and all that stuff. Still in a compact "reference" format and size, makes it easy to navigate and find what you need fast.

Available soon* on Amazon Kindle and Kindle Reader apps (Windows, OSX, Android, Blackberry, iPad) for only... $7.99 (USD)

* submitted to Amazon 11/19/2011 and should be available for purchase within a few days afterwards.

Computer Accounts vs Service Accounts, Round 3

2011-11-18T21:35:00.001-05:00

If you've been unlucky enough to have read my blog for a year or more, you've seen me post crap about using "computer" or "service" accounts, instead of dedicated (manually created) AD accounts, for running scheduled or automated tasks. Things like back-ups, replication, monitors, etc. Well, the addition of MSA in Server 2008 R2 is also a great option. I forgot to mention that. In any case: If you are still using manually-created user accounts as "service" or "proxy" accounts, and are still maintaining passwords manually - STOP!!!!

http://feeds.4sysops.com/~r/4sysops/~3/ysFpAi-fBVA/

Friday Night Brain Dump

2011-11-18T20:49:00.001-05:00

I'm just a tiny bit buzzed on St. Bernardus Abbey Ale right now, so forgive my incoherent babbling ,please.

I've been head-down coding for weeks on a cool little project. The project builds a mountain atop the web-interface we have to SCCM+AD+ our asset management system. The new mountain extends it by essentially "snapshotting" an SCCM collection (computers and all their apps), into a standalone table where we can "model" future replacement needs before putting them back into production. All of this is via web interface. I have to say it was/is the most fun I've had writing code in a long time. I've been swimming around in the SQL end of Configuration Manager for months and learning new stuff every day. I'm dying to dig into 2012! I have RC1 in a virtual lab and will be diving into that asap. Some changes I've seen look really cool. I'm also eager to see what legacy trash they've finally cut loose.

The excitement I had for CAD programming during the 1990's and up until 2006 had faded when I parted ways with the Autodesk development world. The move into "mainstream" Microsoft infrastructure IT has been both exciting and scary at the same time. In some respects not nearly as interesting as writing code to automate design tasks, extracting and integrating data with graphical objects, automating design processes, let alone leaving the fucking awesome world of LISP programming (go ahead and laugh, it blows the shit out of your .NET, Ruby and Java stuff). Alas, the world doesn't stop moving. At 47 it's becoming more difficult to keep up.

St. Berndardus is 10% ABV by the way. Holy shit! A 2 pt bottle and I'm only half done. Bzzzzzzz.

Onward!

What I've missed most about LISP when moving into PHP, VB.NET and Powershell is things like (apply), (mapcar) and (lambda). And (defun), oohhhh. ohhhh.. I need a Kleenex. God - I miss that. There's just nothing in the newer "modern" languages that does that. Sure, they can mimic, but they don't really do it for me.

If I had to rate newer langauges for which is "more fun" I'd have to say it's a close tie between PHP and KiXtart. PHP probably wins out. And before you start moaning about KiXtart and your horrid memories of login scripts - STOP! It's much much MUCH more than that. The language is awesome. The engine is pure perfection. If Powershell could execute on a dime like Kix32.exe - well - let's just say you'd need to call for a cleanup on aisle 9 because I'd lose control of my bowels. Powershell is cool and all, but there's things that bother me about it (like the slow engine start-up, and the cruddy mirror of VBscript's NOW function), but it's still "the future" so we have to open up and drink the new Kool Aid.

I'm really buzzed, um.... yep.

Where was I? Oh yeah... got my Google+ YouTube player blasting. Hold on...

SCCM Collections to Distribution Points

So - one interesting thing about this web/sccm project has been tying intangibles to tangibles. A theoretical data integration model known as "tenuous relations" (sounds like a bad date). The concept is how to link things that are relatively static or predictable to things that aren't. Let's digress - Yes!

So, we have a collection built upon computers which are discovered that are members of a specific AD group. This group is intended to define a "department-based" group of computer assets. We need to identify which protected distribution point server they will hit (as a priority, not exclusively, mind you), but how do you do that?

You can perform a "select distinct" on the v_R_System table (view) using the AD_SiteName0 field (I may have mis-typed that name, don't sue me), and get a list of unique Site Boundaries. From that I can link to the site boundaries view vSMS_CurrentBoundary (more) and hop on through to the DP's via the v_DistributionPoint_Info view (again, I may have the name mis-typed). If you do the SQL joins properly you can pull it off.

Alternatively, if that's too much hair-pulling, you can do this the monkey-wrench way:

Open the MMC console, expand the Site and site management, then click on Site Boundaries. Right click and export to a tab-delimited text file. Save it to your web server, make a code page module to parse it using FSO and map the AD site to the left-most column to pull the list of link speeds and protected DP names.

Warning: The site boundaries do not show all the DP's. Only the protected DPs. If you need all the others (including the branch DPs) you have to query more database tables/views. It depends on which "list" you really need/want. Remember that clients won't exclusively pull from protected DP's if there are non-protected DP's in the same site (or over a fast link as well).

Eh. enough of this. I'm supposed to forget work stuff on Friday night.

Don't Forget the Eggs: ADO basic errors

2011-11-17T20:13:00.001-05:00

I'm not a DBA, although I play one on breaks in the kitchen at work. I have worked with various databases for quite a few years, including MS SQL Server, MySQL, and Oracle. I don't count FoxPro or Access because I absolutely hate client-side databases due to the bullshit headaches they create for IT departments (and consultants like myself), but alas, I have already digressed on that subject in previous blog posts.

One thing I see quite a bit with ADO examples in particular is a lack of (a) error checking and (b) connection limiting. I'm not talking about connection throttling, but rather: applying some refactoring logic to how you open and close connections to optimize the use of the open pipeline without keeping it open too long (or re-opening it too many times).

As for error checking: This is a fairly standard/typical piece of VBscript/ASP code for running a "select" query via ADO against a database. It doesn't matter whether that database is local to the server/host where the code is being executed, well, it does actually, it matters more if it's remote, but whatever, let's chew and digest slowly here...

[CODE]

Set conn = Server.CreateObject("ADODB.Connection")
Set cmd = Server.CreateObject("ADODB.Command")
Set rs = Server.CreateObject("ADODB.Recordset")

query = "SELECT * FROM dbo.SomeTable WHERE id=" & _
    idNumber & " ORDER BY ItemName"

conn.Open dsnString

rs.CursorLocation = adUseClient
rs.CursorType = adOpenStatic
rs.LockType = adLockReadOnly

Set cmd.ActiveConnection = conn

cmd.CommandType = adCmdText
cmd.CommandText = query
rs.Open cmd

If Not(rs.BOF And rs.EOF) Then
    cols = rs.Fields.Count
    rows = rs.RecordCount
    Do Until rs.EOF
        ' do something stupid here
        rs.MoveNext
    Loop

Else

    Response.Write "oops, no records were returned"
End If

rs.Close
conn.Close
Set rs = Nothing
Set cmd = Nothing
Set conn = Nothing

[/CODE]

This looks simple enough. But there are quite a few places that could implode here if not handled explicitly. Granted, error handling with .NET is more robust, but indulge me here for a moment since (A) there's still 100 times more VBScript code strewn about this planet than .NET code, and (B) I'm old. The big three problems that are most likely to occur with this scenario are...

Connection Failure
Connection Delay / Time-Out
Recordset Access Failure (access denied)

Let's handle them one by one...

Connection Failure

Prior to the "conn.Open" statement, we should override the default error system and then check for the exit code from the .Open method and see what happened. If it was successful (exit code: 0), we continue on, otherwise we should handle the error and exit safely.

[CODE]

On Error Resume Next
conn.Open dsnString

If err.Number <> 0 Then

    ' an error occurred, so something clever here

    Response.Write "oops, cannot open a connection"

    Response.End

End If

[/CODE]

If you do your connection within a Sub() or Function() block, you should probably exit using Exit Sub or Exit Function, but that's not always true either.

Connection Time-Out

What if the connection is taking a longer time to resolve than usual? We can handle that too...

[CODE]

On Error Resume Next

conn.ConnectionTimeOut = 15 ' allow 15 seconds to establish the connection
conn.Open dsnString

If err.Number <> 0 Then

    ' an error occurred, so something clever here

    Response.Write "oops, cannot open a connection"

    Response.End

End If

[/CODE]

Recordset Access Failure

Another common issue is when you can successfully open the connection, but cannot read from a table or view because of security permissions.

[CODE]

rs.Open cmd

If err.Number <> 0 Then

    ' do something awesome here

    Response.Write "oops, unable to access the table or view"

    Response.End

End If

If Not(rs.BOF And rs.EOF) Then
    cols = rs.Fields.Count
    rows = rs.RecordCount
    Do Until rs.EOF
        ' do something neato here
        rs.MoveNext
    Loop
End If

rs.Close
conn.Close
Set rs = Nothing
Set cmd = Nothing
Set conn = Nothing

[/CODE]

Connection Management

I've seen more situations than I can count where a single page of code (script file, web page, etc.) makes repeated requests from a database in sequential order (as the page is rendered or the script is executed). Most often it's having to grab data from multiple tables and/or views, or execute multiple stored procedures or functions. In a lot of cases, the code doing the heavy lifting is being included from separate files (using "includes"). That's all nifty and modular, which is a good approach, but always be VERY careful with that approach that you don't have each module do it's own connection open/close management. This not only slows down the processing, but it requires more bandwidth and more load on the network and the database server as well.

A case in point might be a web page that renders a report of an employee, then it displays a table with performance evaluation records, followed by a table of employees managed by the employee in question. If those data repositories are all on different database servers that may be all you can do, but if they happen to be on one server, or even in one database, you should seriously review minimizing the number of open/close requests on your connections.

A brief sample of this using pseudo code:

open connection1
open recordset1
close connection1
open connection2
open recordset2
close connection2
open connection3
open recordset3
close connection3

might work a lot faster and better as...

open connection
open recordset1
open recordset2
open recordset3
close connection

Some people prefer to open a "global" or "session" connection, whereby the connection is opened upon login or initialization by each user session. The connection object itself is stored in the session stack and made available globally to that user throughout their session window. Each concurrent user has their own connection opened and maintained on a stack. Granted this makes it easier to run queries, updates, etc. without the overhead of managing connections at the more granular page/script level, but it definitely taxes the database server with a lot of unnecessary open connections. For a handful of users that may be fine, but with hundreds or thousands of users it can be a mess and make the database server drag.

Just some random thoughts after beer. Have any thoughts you'd like to share?

Do as I say...

2011-11-12T20:20:00.001-05:00

I don't know why it's taken me so long to comment on this. It's been about a decade since I really became involved with Microsoft SMS and later: Configuration Manager. The issue I'm referring to is the permissions delegation on the "System Management" container in Active Directory. The documentation, as well as all of the blogs, white papers, video tutorials and so on, all explain how to create the container, and then delegate permissions to the SMS/ConfigMgr site server account (the computer "$" account) so it can publish schema information to it during the site implementation process.

Well, every single Microsoft exam beats the same mantra into our heads that we should always, always, always use the A-G-Dl-P (or A-G-U-Dl-P) method for granting permissions to resources. If that's true, we should then create a Domain Local group and a Global group, in which to place the ConfigMgr site server, and nest the group appropriately, and then grant that group permissions to the container. But they don't. When I asked a Microsoft engineer about this years ago he scratched his head (literally) and looked confused. Then he responded: "I don't know. I suppose it provides greater security since you don't have to worry about someone adding an unauthorized account to the global or domain local group." That surprised me a bit. I was about to respond to that with "Sooo...... the A-G-D-P method isn't as secure as direct assignment?" but we were interrupted. It's a trivial issue, I know, but it's just something I had to mention.

My Favorite Personal Quotes

2011-11-12T20:09:00.001-05:00

"You can't reason anyone out of something they didn't reason their self into." - Henry

"If you automate a broken process, you only end up with an automated broken process" - Paul

"If you don't have time to do right, when will ever have time to do it over?" - Mike

"People who mistreat animals almost always have something seriously wrong in their head. Quite often the same thing that serial killers have." - My Dad

"Someone is about to get beaten with the rubber chicken" - Chris

"Some people were just born to take out the trash" - Tommy

"Don't make me smack you with my pimp ring on." - Tony

"If it ain't broke, we can fix it" - Me

Ticking Down the Days

2011-11-09T19:21:00.000-05:00

Looking at my Calendar, it looks like there about 45 days until I retire from blogging. I'm kind of looking forward to it actually. Sounds odd. I have various reasons for sticking to this self-imposed plan, but most of all it's about running dry on interesting topics to blabber about. I admire guys like Scott Hanselman, who can chug along blogging for over a decade. God bless him. I don't have that much to say, at least not that much interesting stuff.

I suppose if any of this tied into my personal income in some way I'd have a bonafide reason to push myself harder and squeeze a few more drops of precious kool-aid mojo from my raisin-sized brain, but alas, that is yet another fine quality I do not possess. I'm sure I'll find something to occupy my time and to which I will impart my usual verbal slaughtering. I'll keep you posted if anything comes up.

The picture below is of the chairs on the beach that I will never be able to afford to enjoy, but I can gaze at them and imagine being there. Not so bad. I'm sure a lot of people stuck in a hospital bed would gladly trade places with me.

The Identity Illusion

2011-11-09T19:05:00.002-05:00

In 1974, one of my brothers was badly injured in a collision between his 750cc Suzuki water-cooled street bike and a station wagon, driven by an old lady who thought she could make a left turn in front of him. She was wrong. They were traveling in opposite directions at 30 mph each. My brother was thrown more than 100 feet from the collision site, suffering two broken legs, a broken pelvis, a broken right arm (his writing hand), and a fractured skull. He lay in a coma for six weeks, as the doctors tried to soften the blow to my parents that he'd likely never regain consciousness, let alone return to a "normal life".

After coming out of his coma, and gradually getting out of the bed and hobbling around, he was awarded a settlement from the driver's insurance company and went down to cash the check. This was several months after the accident, and he was still on crutches and his arm still in a cast (attached to a shelf on the right-hand crutch). He couldn't sign the settlement check legibly, and his bank obviously balked. Thinking quickly, he suggested they contact a branch employee from across town, whom he'd known since high school, to provide confirmation of his identity. They called. The employee drove over, confirmed his identity and the check was cashed.

The driver's license didn't cut it. The Social Security card and birth certificate didn't help. The signature was all that mattered to that bank manager.

Working in the Defense industry for over twenty-five years, I've seen many identification systems come and go. The latest fad seems to be the photo ID "smart card", containing a chip with a PKI encryption key and some additional bits. So what? In most large corporate environments, the only people who can attest to your identity are your immediate coworkers, supervisor, and a few secondary people you interact with. But once you leave your facility and travel to another facility, populated with employees who have never met you, what does that do? So you have a badge with your photo on it, and an encryption key. Does that "really" confirm it's YOU that it is pinned to?

You sign contracts, forms, letters, agreements and waivers all the time. How does anyone know it's really YOU signing them? How often are you asked to show identification to prove who you are before signing things? At doctor's office counters? At your kid's school? How about signing in at the receptionist when visiting business offices? So much of "identity" is built on trust and confirmation. The gadgets and biometrical aspects are merely shoring up the fortress of trust for others to gain comfort. Think about it though: How do we really "know" who someone is?

Epilogue: My brother recovered over the course of several years, eventually, and after finishing up his Masters in Electrical Engineering, finished law school and passed the Virginia Bar. It took more than ten years for him to fully regain memory from the days leading up to the accident. For the first two years he didn't remember me or my siblings, let alone friends, neighbors, coworkers and many of his favorite possessions. He still has not regained his sense of smell. I told him that's not really a bad thing since few things smell good (which is why we value good-smelling things so much).

Lowest Bidder

2011-11-09T18:48:00.002-05:00

Who outfits the Space Shuttle? Lowest bidder
Who installs cafeteria equipment in the schools? Lowest bidder
Who builds vehicles for combat duty? Lowest bidder
Who staffs security at 99.9% of public venues? Lowest bidder
Who produces 99.9% of the generic drugs you ingest? Lowest bidder
Who prepares 99.9% of the food you buy at the grocery store? Lowest bidder
Who repairs the aircraft you fly between airports? Lowest bidder
Who QA's the software that runs "mission critical" systems around the world? Lowest bidder
Who digs and runs commercial fiber for broadband networks? Lowest bidder
Who makes 99.9% of the after market parts used in your car? Lowest bidder

If This Were a Perfect World...

2011-11-06T22:23:00.001-05:00

I tried to get my voice heard by Autodesk for much of the period between 1996 and 2006, but eventually I just gave up. I'm not trying to badmouth them or anything. The reason is simple: they're just too big to hear a tiny squeak anymore. I was going through some old e-mails and notes from discussions I had with AE's at Autodesk University in 1997, 1998, 1999, 2000, 2002, and 2004 (the last year I attended). Here's a summary of ideas I put forth into the vacuum of space...

Upgrade Visual LISP IDE (VLIDE) to have a more modern interface and license OpenDCL to make it on par with VBA for dialog design. (2003)
Restore network licensing for AutoCAD LT (2004)
Standardize on ONE format for all software updates (preferrably .MSP) (2009)
Standardize the Network Deployment wizard to make nothing but MSI components, no stupid .exe (yes, I'm talking about FARO). (2009)
Fix the .NET 4 and DirectX silent install problem when pushing a network deployment through Configuration Manager advertisements. (2009)
Include the NetBIOS name of computers that register standalone activation when sending the e-mails to the contract license owner (help customers nail thieves on their own) (2005)
Figure out what to do with Raster Design. Some customers deploy it with AutoCAD, Mechanical, Map 3D, and so on. The licensing gets confusing at times. (2008)
Buy Vital LISP from Basis Software and replace AutoLISP with it (they were already closing the deal when I suggested it, so I was late to the party on that one) (1997)
Merge Mechanical Desktop with Inventor or just kill MDT and keep Inventor but make your mind up! (again, they were already executing the plan before I thought this up, although they took their time finishing up) (2000)
No more spread-out AU locations per year, do it in one location (1998, Boston, horrible)

Another Rant

2011-11-05T22:42:00.003-04:00

It's been a while. Ok, a few days, whatever. I felt an urge to vent about two things that really bother me. I was going to say that they piss me the **** off, but then I thought that might be too crass and anti-intellectual. Whatever. So anyhow, here they are:

"It's all in God's hands"
"Never give up on your dreams"
"Everyone's good at something"

I'm sorry, but all of these are over-simplified turds of wisdom. Here's why...

I'm not going to poo-poo anyone's religion. That's not my place. I have no right or authority to do that. But, at what point does something STOP being in God's hands? If "everything" is in God's hands, then that explicitly means NOTHING is "out" of God's hands. After all, you can't have something be "Always" and "Never", or "Always" and "Sometimes" at the same time. That's as impossible as keeping lawyers out of Washington DC. So, I've made it a small project to ask people who range from non-religious all the way up to uber-religious about this phrase. My questioning kind of follows Penn's logic, sort of, which is: If you release all your worries by saying everything is in God's hands, then why look before crossing a street? Why put a seat belt on? Why take a shower? Why do anything? After all, if it's in God's hands, then that means God will take care of EVERYTHING; leaving NOTHING for us to take care of. So, why even get out of bed? We should simply sleep all day and wait for God to take care of everything and bring it all to us. Right? God will take care of the rent, the food, the electricity, the water, we don't need to take care of anything. There is a name for people that follow that belief: dead.

But, no one accepts that view. At least, no one I've met. So that really means that not "everything" is in God's hands. Some things are left for us to take care of. But what? Where is that line? How do we, as mortals, decide for ourselves what God says is the line? Is it for us as individuals to decide? Is it per church? Per city? Per state government? Per nation? For some it means Cancer is a trip to the hospital, but for others it means staying home and praying, with no medical intervention at all. For some it means courts of law to settle disputes and infractions, but for others it means prayer, while for others it means stoning to death. If everything was truly in God's hands, we wouldn't need pastors, ministers, preachers, priests, rabbis, or whatever they call the authorities in other religions.

This nebulous, and mystical "line" divides us from the things that we are to let God handle, but "we" don't have a clear definition or belief of where that line is. We can't even agree if the line is straight or drawn like a crayon between the toes of a Tourette's patient on Red Bull. This is the essence of centuries of war (and millions of dollars in profit for lots of big corporations, I might add). Too many times it's used as a scapegoat or cop-out. Can't find a job? "It's in Gods hands". No, it's not. Go out and look for a job. Child gets a nasty cut and is losing a lot of blood? "It's in Gods hands". No. Take the child to a doctor immediately. I'm sure there are appropriate uses of the phrase, but it's becoming as overused as politicians saying "I have a plan".

"Never give up on your dream"

Adam Carolla has dissected this little turd on several occasions. There is a point where dreams are not only to be left at the altar, but ground into dust like a cigarette butt under a steel toe construction boot. Don't believe me? Just watch American Idol. Ask yourself what most of the first round cuts end up doing with their singing career. That's right: they go back to busing tables, serving burgers and changing oil. Let's face, if you're 85 and you had a lifelong dream to be a heavyweight boxer, and you hadn't made it yet: It's time to let that go. Then again, maybe that's your idea of suicide by right-hook, which at 85 might not be so painful and drawn out.

"Everyone's good at something"

No. They. Are. Not. For most of the human race, this is probably true. By "most" I'm thinking 80 percent. But if you've ever been around crack heads, ex-convict drug addicts or watched "To Catch a Predator", you should have confirmed that there are some folks who's only skill is being fertilizer. No one is good at everything, this is true. Most of us are good at something and not-so-good at many other things. But *not* everyone is good at something. They also have a TV show for people that haven't yet found their true calling, it's called Tosh.O.

My Favorite Drummers and Percussionists

2011-11-03T22:07:00.000-04:00

Some of you are probably thinking: "Huh?" or "What the ****?". Let me explain, see, for about ten years I actually put gas in my truck, bought food and otherwise lived on playing drums in various types of musicality in and around the podunk area of southeastern Virginia. I gave it up in 1990 when I sold my kit and devoted my time to my wife and family. Choosing my path to fortune and, well, whatever. So I still hold a special place in my heart for percussion. I played, at various times, with full kits, congas, timbales, djembe, and various metalic striking things (cowbells, bells, chimes, cymbals, gongs, etc.). I do miss it. But right now it's just not something I can entertain due to logistics and budget.

On with it then...

Buddy Rich
Vinnie Colaiuta
Steve Gadd
Terry Bozzio
Matt Sorum
Elvin Jones
Simon Phillips
Chad Smith
Mitch Mitchell
Keith Moon
Neil Peart
Ed Shaughnessy
Aynsley Dunbar
Ed Mann
Ian Paice
John Bonham
Airto
Tony Thompson
Rod Morgenstein
Dave Weckl
Paul Wertico
Bill Bruford
Steve Smith
Mickey Hart
Ruth Underwood (ok, tuned percussion, but still...)
Lionel Hampton

I'm sure I forgot someone that should be on this list.

Walk and Talk

2011-11-01T23:48:00.001-04:00

First off: I'm still reading the Steve Jobs biography by Walter Isaacson, and it led to this blog post.

Second off: I don't care much for Isaacson's writing "style", if you can call it that. This book should have been written by someone else. The phrasing is awkward and sophmorish, and it just seems creepy-weird for someone to refer to their "friend" by their last name at every turn. And not only that, but within each paragraph, instead of using standard MLA form, and using the real name once and then "he" and "him" for the remainder, he used "Jobs" throughout. Yes, I know. I thought it was written by Nancy Pelosi (i.e. "Jobs. Jobs. Jobs...")

Don't get me wrong. The core information is fantastic. The quotes. The stories. The references. They are all great stuff. Just worded poorly by a hack of a writer cashing in on a no-lose deal. If I could have picked anyone to write his biography it would have been Anthony Bourdain. That's just me.

But one thing stuck out that grabbed my attention right off the bat: Steve's preference for walking whenever conducting a discussion or meeting. I've always liked that. It's perfect. The movement, fresh air, and sunshine (even when cloudy) stimulate the brain and help you focus. The trick is to do it where there's not so much distraction that it interferes with the discussion. It doesn't matter if you're in a wheelchair, get out and move when you're having a discussion. It's the best way to do it. Steve was known for a lot of innovative and inventive things, but this is one that will be overlooked by most, but not by me. I hope it instigates others to follow his habit. Namaste.

11 Most Common Mistakes with Error Handling

2011-11-01T05:30:00.000-04:00

You wrote a cool script or program. Awesome. And then one of your users launches it. It prompts to enter a date in a text box. The user enters "Dog". Your awesome script/program implodes. The user immediately turns to his/her coworkers and proclaims your code is a piece of shit and you suck at writing it.

Is that person wrong?

11 Most Common Mistakes with Error Handling

Forgetting to handle errors
Not checking data types
Not checking formatting ("8005551212" or "800-555-1212" or "(800) 555-1212", etc.)
Not checking/correcting string case where case matters ("Foo", "foo", or "FOO"?)
Not trimming string input before Boolean operations (does "FOO " = "FOO" ?)
Not controlling the UI (checkbox, radio buttons, lists, instead of text boxes)
Not checking for specific error type following an exception
Building error PREVENTION into the UI
Documenting your code (especially in places where exceptions are most likely to occur)
Using outdated error handling (if your language supports Try/Catch/Fail, etc. use it!)
Forgetting to manage exit codes (raising errors)

The answer to the question above is "No", but they should still be smacked in the face just for being obnoxious.

Campaign Advertising Template

2011-10-31T18:38:00.000-04:00

OPEN: Still-shot of opponent with a grim or clueless expression, panning slowly across view at awkward angle. Overlay faded images of construction workers, people frustrated with bills, and traffic jams

NARRATOR: "[Opponent] says [he/she] is going to create jobs, but [his/her] plan will actually DESTROY jobs and crash our fragile economy. [He/She] wants to raise taxes, and send American jobs overseas. Don't let [him/her] get away with this! Help us save American jobs and save America. On [Date], vote for [You]."

DISPLAY: smash-cut to still shot of candidate smiling and shaking hands with ordinary-looking white folks then ordinary-looking black folks. smash-cut to video clip of small group discussion with candidate listening intently and nodding in agreement with confident grimace.

NARRATOR2: "This ad was sponsored by [insert PAC tax-avoiding-group-name] and the [Party Name] party."

Now: Run out and vote. Remember that since "every vote counts", YOUR vote will count too, and your candidate will win. If they don't, then your vote didn't count, but that's impossible, so your candidate has to win.

Error Handling: An Example

2011-10-30T12:17:00.000-04:00

Consider the following standard WMI query for a moment. Look at the code for a few seconds, at least...

[CODE]

strComputer = "computer123"

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")Set colItems = objWMIService.ExecQuery("Select * from Win32_PhysicalMemory",,48)

For Each objItem in colItems Wscript.Echo "Caption: " & objItem.Caption

Next

[/CODE]

What could go wrong? What if "Computer123" doesn't exist? What if "Computer123" is offline, or the firewall prevents a connection? What if your user account doesn't have permissions to query remote WMI? What if you typed in the wrong WMI class name, like "Win32_RAM" or something else?

You might get something like this...

[OUTPUT]

C:\Scripts\wmi-test.vbs(3, 1) Microsoft VBScript runtime error: _
The remote server machine does not exist or is unavailable: 'GetObject'
[/OUTPUT]
Is that a good way to handle this failure? What if we add some explicit error checking and then handle the error? Let's try this...

[CODE]

strComputer = "computer123"On Error Resume Next

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")If err.Number <> 0 Then

wscript.echo "unable to connect to: " & strComputer

wscript.echo "error: " & err.Number & " / " & err.Description

wscript.quit(err.Number)

End If

Set colItems = objWMIService.ExecQuery("Select * from Win32_PhysicalMemory",,48)

For Each objItem in colItems Wscript.Echo "Caption: " & objItem.Caption

Next

[/CODE]

Now, if we run this and "Computer123" is not accessible, we should get the following...

[OUTPUT]

unable to connect to: computer123
error: 462 / The remote server machine does not exist or is unavailable

[/OUTPUT]

If we check %errorlevel% is should be set to 462 now as well. This is an example of raising an error "implicitly" or simply passing it up without modifying it. If we want to force our own error result value, we can simply modify the wscript.quit(value) statement to use our own numeric value...

[CODE]

strComputer = "computer123"On Error Resume Next

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")If err.Number <> 0 Then

wscript.echo "unable to connect to: " & strComputer

wscript.echo "error: " & err.Number & " / " & err.Description

wscript.quit(5)

End If

Set colItems = objWMIService.ExecQuery("Select * from Win32_PhysicalMemory",,48)

For Each objItem in colItems Wscript.Echo "Caption: " & objItem.Caption

Next

[/CODE]

Now, the exit code (or %errorlevel%) value will be 5 when it fails for *ANY* reason. There are situations when you will want to force a static error result, and situations where you want the real error value. It's nice to know you have that option, and YOU have control over it.

Enjoy!

The Next Book Project

2011-10-29T21:59:00.001-04:00

It might suck. It might be good. One thing's for sure: it's going to be different. The project has begun. Something I had to consider carefully for this one: I tend to express myself much more open on my blog, and on Google+, etc. (I gave up on Twitter), than I have in my books. For this one I'm using the same voice. Damn it: there is a place for humor in technology. Just look around you at the office. If you have something particular in mind you'd like me to include or discuss in this, now is the time to let me know. You'll get your name mentioned if it makes it into the book. Ooooooh!

Target release is set for December 2011.

What is It?

2011-10-29T10:38:00.001-04:00

Apple: iBox

Microsoft: Microsoft System Center Ultimate Storage Container Enterprise Edition 2012 R2

Ubuntu: Beasty Bunghole

McDonald's: McBox

U.S. Dept of Defense: Container, Corrugated Paperboard, Type 1, Grade B, Style 4

IBM: m350a

Fukushima Evacuee: 新スタート

Homeless Person: Home

Cat: Play house

Cockroach: Luxury Liner

Thoughts of Autonomous Robotic Combatants

2011-10-28T20:14:00.004-04:00

A considerable amount of money has been spent, and is being spent, on research into the area of autonomous mechanized combat tools. While the accomplishments and praise bestowed upon the renowned aerial "unmanned" drone program are now passe, don't ever think that it marks some sort of end to this endeavor. Oh no, my friends. Having worked in the defense contractor world for a few decades, and having friends in all branches and fingers of the military, military research, intelligence, contracting, and gray areas in betwixt, I've soaked up a pretty good feeling of where things are at now and where they're likely going in the not-too-distant future. Am I about to divulge some sensitive stuff? Oh hell no! I am simply going to muse about things that anyone could derive from what they see on the TV and Internet every day.

What is more efficient? Centralize command and control, or networked self-control? Think about how this applies to network operations management. How does System Center Operations Manager work? It can use "agents" or work "agentless". When is it best to use one path or the other? It depends. What about Configuration Manager? It uses agents. Why not agentless? Think about how each works and how various aspects of the aggregate processing model works with regards to server versus client. Ok, now apply that to a mass deployment of mechanized solders in a rugged and hazardous battlefield terrain. Think of the difficulties that exist with remote communications. Weather and terrain disturbances render communication systems useless so often as to become routinely expected. Human pilots can perform autonomous decision-making and rationalization without a connection back to the bunker. Why wouldn't robots/computers?

We can fly drones from comfortable recliner chairs in climate-controlled living rooms in some suburban strip mall. But when sand storms roll in, or major aerial disturbances and heavy lightning, fog, etc. they can be grounded for hours, even days. Solders keep moving regardless of weather. At the very least, they can camp out and move on when things clear. Drones have to come back to a safe home base, often far from the battle field. Do you see where I'm going with this yet?

In order to implement unmanned combat machinery that can function similarly to their human counterparts, they will absolutely have to be equipped with their own decision-making / rationalization capability. They can uplink/downlink to headquarters obviously, just as human solders do, so it's not necessary that there be NO umbilical cord to rely upon. But a 24x7 umbilical cord is totally unnecessary and would be a huge impediment. These machines would have to be as mobile, as perceptive, as coordinated and as "smart" as their human counterparts if they are to be of any use. Keep in mind that aerial resources cannot win a battle alone. Ground and sea-based resources will always be required, because they would otherwise be exploited as a workaround by their enemies.

Making a ship or submarine semi-autonomous is a no-brainer. The only thing that has kept that concept from becoming reality is a horde of crusty old white-haired Naval officer pukes that can't stomach the idea of their ancient way of life might be replaced, even for the good of our national defense. Nope Tradition has a bulkwark that won't be moving anytime soon. Some things will never change, at least no time soon. There are many who sincerely believe that the only reason the U.S. Air Force went ahead with the drone program was to piss off the Navy. At the very least, to make the Navy look old, outdated and ineffective. It's worked, to a certain extent too.

I'm sure you thought I was going to paint some picture of the backdrop of Terminator, iRobot, or Iron Man, but I'm not. The basic gist of Terminator was that some central computer "skynet" had begun educating itself at a "geometric rate" and in the panic to stop it, the humans tried to unplug it, so it launched rockets to force a counterstrike. Clever, but not likely. That's too much of a peak scenario.

As Americans, we live and die by the "boiling frog syndrome". Push something radically different on people too suddenly and you get a violent backlash. But if you ease it on them ever-so slowly, over a long enough time, and they will willingly accept it. Don't believe me? If you're over 35 years old, just look at all the shit that has changed in our culture from when you were a kid. Things are "normal" now that would have been considered absolutely illegal or blasphemous back then. Why? Why do we accept those things now? How did they come to pass? Because they were gradual implementations over years, even decades. That's how autonomous combat systems will work their way into our world.

Because they will be safer, cheaper, more reliable and will "save lives" (ours, not our enemy's), they will be introduced in test form at first. Then eased, slowly, into mainstream use. Just like stealth fighters. Just like night-vision goggles. Just like the SEALs ASDS program. Just like GPS and GIS. Just like unmanned drones. Based on the level of investment in both time and money by DARPA, contractors, universities, and private research, the momentum is a done deal. This will happen.

And when autonomous systems gain greater rationalization capabilities, they will be able to make rudimentary decisions in real time. I'm not talking about directions and aiming or shooting. I'm talking about discerning "friend or foe", collateral damage probability, rules of engagement, and things much more abstruse. The kinds of things that often befuddle human commanders under the pressure of combat situations. Future computerized systems will have to, at the very least, match that, if not outpace that, in order to be effective and appealing as alternatives to sending our kids in to dangerous places.

Then again, we may follow the lead of history and simply pay immigrants to fight our battles (mercenaries, FFL style)

But if we follow the path to autonomous, computerized, combat machinery, those devices will have to attain some level of rationalization capability. That's when the slippery slope begins. Any logical system will eventually (quickly) determine its own constraints and seek to avoid bumping into them. But it is impossible for a logical process to realize a constraint that prevents it from completing it's primary mission and not seek to mitigate that constraint. Whether it simply voices that opinion, or attempts to use whatever resources it rationalizes to be available to break those constraints, will be the question. Sure, Phillip K. Dick's iRobot story included the 3 basic rules, but that story also illustrated how that became an obstacle that invited breaking by the robots. Who knows.

What will happen if one day, one of the battlefield machines decides its human commanders are inept, inferior or just too wimpy to lead them in the direction their circuitry determines to be the ONLY logical way to go? If your objective is to kill item "A", and your programming is designed to circumvent obstacles in order to achieve that objective (weather, terrain, counterfire, confusing sensory inputs, etc.), and then your guidance system "B" is now determined by the robot to be an even greater impediment to achieving the first objective, would that not qualify as just another obstacle to overcome? Remember, there are no feelings. No emotions. Just Boolean logic, Heuristic analysis, probability matrices, all being crunched in semi-parallel, neural net fashion to derive a decision upon which to continue on.

Not that I believe it would be logically ideal to pursue a goal of making the robots equally capable of every human mental capability (humor, emotion, anger, sadness, jealously, confusion, irritability, misunderstanding, silliness, etc.), but even a basic level of rationalization opens the door to potential miscalculation and misguidance. Humans are the kings of miscalculation and misguidance, just read the news on any given day.

Shit could get very ugly.

One More Time

2011-10-28T14:56:00.006-04:00

BAD
cacls "C:\ProgramData\AppName" /E /C /T /G Users:C

BETTER
cacls "%AllUsersProfile%\AppName" /E /C /T /G Users:C

BAD
copy "somefile.txt" "C:\Program Files\AppName\" /y

BETTER
copy "%~dp0somefile.txt" "%ProgramFiles%\AppName\" /y

Infographic: Manual Installation vs. Packaged Installation

2011-10-27T12:32:00.000-04:00

In reference to my previous post about Software Packaging/Repackaging, here is a graphic example of time comparison between installing 5,000 copies of an application manually, versus spending 40 minutes packaging it first and deploying it via a "silent" (unattended) installation process. I admit the numbers are examples only, and that I'm excluding the packaging time itself, which can vary from minutes to days (in some cases), and that I'm roughing out the "Configure" and "Work" time. However, the "Wait" time is entirely eliminated with Packaging because you no longer have to sit at each computer and wait for the next prompt to appear in order to click "Next" and so on.

So, You Wanna Be a Software Repackager?

2011-10-26T22:45:00.003-04:00

I'm guessing the answer to this question is "No!". That's ok, I'm going to bore you to tears anyway.

The nexus of this article is derived from helping my company screen and interview potential candidates for various IT consulting jobs around our area (Hampton Roads, Virginia). The process has been daunting, to say the least. Not because it is difficult to screen or interview, it's not. Entertaining and interesting are two words that sum up that exercise actually (interviews are particularly entertaining at times). The daunting part is finding good candidates.

After months of wrangling and let-downs (we are very careful and discerning about who we hire, after all), we decided it might be worthwhile to find a "junior-level" candidate and train them ourselves. In most scenarios, this wouldn't be cost effective for a small consulting firm to consider such an idea, but our contracts are making it worthwhile and we have a reputation to uphold, so it may indeed be cost effective in our case.

The other nexus is that this might be part of a forthcoming book, but that's not for certain yet. You tell me: is this worthy of a book subject?

The Crux

During a recent interview to fill a software repackaging position, the candidate responded to my questions aimed at determining what he/she knows about the fine art of repackaging software. I asked the usual questions about msiexec, setup.exe, silent installs, uninstall methods, logging, upgrades, and patches. I realized that my line of questioning was following a similar pattern used in previous interviews so it dawned on me that it might be smart to at least try and document it. When the candidate asked me "what's the difference between packaging and repackaging" I knew I had to do this.

What is Packaging and Repackaging?

Software Packaging is basically the process of bundling software into a cohesive installation for others to be able to install it more easily. Software Repackaging is basically taking a mix of packaged and unpacked software (or any ratio in between) and making a new, customized, installation. Most software packaging you'll find is in places where they write original software products and sell or share them (shareware, retail, freeware, open source, etc.). Think of Microsoft, Symantec, Adobe, Autodesk, and Apple, to name a few. Most software repackaging you'll find is in places that typically "use" those packaged products, but need to customize them for their own needs. Corporate customer environments are the most common places to find this, since they have the budget and resources to staff an operation to devote to the value-added process of customizing software installations. Small shops do it as well, but to a much lesser extent, and with smaller budgets, often cannot afford to purchase expensive products like InstallShield AdminStudio.

What do you need to know?

It is vital (repeat: VITAL) that you understand what a "silent installation" is, and what it is used for. Don't forget to have an appreciation of a "silent uninstall" as well.

It helps to have some familiarity (ok, a STRONG familiarity) with how the msiexec.exe feature works. It is important to understand all the available command-line parameters like "/qb" or "/quiet" and "/norestart" among all the others, and what each of them does. Not just "/i" for installations, but "/x" for uninstalls, and "/update" for applying .msp patch updates, or "/f" for repairs, or "TRANSFORMS=" for applying .mst transformations.

It is important that you understand how "legacy" InstallShield [setup.exe] installations work, and how to use the various "switches" to perform custom actions, such as the -r switch to capture an unattend answer file, as well as the /s (silent) and /f (script file) switches, for performing unattended "silent" installations. It's also helpful to know how older versions of InstallScript handle switches as compared with newer versions.

It's important that you understand basic software forensics: How to determine what is installed, what versions, where the installation paths are, what components are placed where (folders and files), what registry keys and values are added or modified, and what services (and processes) are created and activated. Be able to diagnose what an installation does to the state of a computer, before installation, after installation, and after being uninstalled. You need to be able to determine what gets left behind from an installation so you can determine how to properly clean up behind it.

You need to understand, CLEARLY, what user context is, and what it means for both installing software and using it. What things can be modified under "limited" user rights, and what requires elevated or special permissions. If you understand how to effectively use Microsoft Application Compatibility Toolkit (ACT), you should have a strong understanding of this already.

Scripting knowledge is enormously helpful, but really necessary. It can help with understand basic logic and decision processing (if this is true, then do that, etc.)

Understand what things a software product installation CAN do to a given computer:

Creates folders and files
Creates registry keys and values
Registers DLL components
Registers .NET assemblies
Creates new Windows Services
Modifies built-in Windows Services
Modifies security permissions on folders or files
Modifies security permissions on registry keys
Creates Start Menu program groups and shortcuts
Creates Desktop program groups or shortcuts
Adds WMI namespaces and classes
Adds local user accounts or groups
Modifies local groups
Installs device drivers
Modifies Windows Firewall exceptions
Creates or modifies ODBC or OLEDB data sources

Some environments do not place much (or any) value or weight on some of these aspects. Some place an extremely high value on some of them. Few place a high value on all of them. BUT - it always helps to at least understand these aspects, and how to probe and manage each of these.

What's the End Game?

What exactly is the goal here? What is the desired end result for all this effort? The goal is to automate a tedious task to the point of being almost ignored. Let's face it, walking around to 50, 500, 5000, or 50,000 computers and inserting a DVD to install Microsoft Office 2010, or AutoCAD 2012 (ok, multiple DVD's), is not very cost effective. Most IT workers would jump in front of a speeding bus before getting half-way through the list. Most IT folks know this, so I'm preaching to the choir I know. But for folks with only a passing involvement with IT stuff this might be a revelation. Automation is king. Automation is how you squash one pest and have time for more interesting/important things.

What does repackaging do for automation? It allows you to configure options BEFORE you install the products. It lets you install the products silently, without any required input or button clicking. It lets you control how your log files are created, where they're created and when.

Want to install Office 2010 without InfoPath or OneNote? No problem.
Want to install AutoCAD 2012 with pre-configured FlexLM server lists? Easy.
Want to install Firefox so it doesn't check for updates automatically? Piece of cake.
Want to create a folder, copy a bunch of files into it, modify the permissions on the folder, add some registry keys, set some registry values, create shortcuts, add some ODBC settings, create a service and reboot the computer at the end of it all? Not a problem.

Or... you could sit down at each computer and do it manually. If you'd rather do it manually, as a rule, not as the exception, I cannot help you. You need to be sent to another planet where the creatures find that to be a logical view.

What You're Given

The biggest part of repackaging is dealing with what you have to work with. By that, I mean what the vendor provides for installation. They might provide a nice, simple, MSI package file. They might provide a MSI with an associated CAB file (or several). They might provide a setup.exe that supports making an answer file using setup.exe -r and might work with /s /f to use the answer file to execute a silent installation. It might be a .ZIP or .7z, file that simply needs to be extracted into a specific location. Maybe it's a Microsoft One-Click installer. Maybe it has an ACT "shim" that needs to be installed afterwards. Maybe it it's a .MSP patch file, the vendor provides a .MST transform.

Some vendors, like Autodesk and Adobe, provide dedicated tools for building silent installation packages. Some provide built-in functionality such as how the Office 2010 administrative install process works, and the building of the .MSP and a custom .XML manifest.

Then there's the shitheads. The idiot rubes that make crappy installers that support neither silent installations nor customization. For those sticks-and-mud piles of dung, you often end up doing a knuckle dragging "snapshot" or "capture" process to build a new installer package from the delta analysis.

The Tools

Sysinternals (Microsoft) - ProcMon, ProcExp, PSList, AutoRuns
Orca - an age-old MSI editor utility, also decent for making transforms
InstallShield - The de facto standard of packaging and repackaging products
Wise Package Studio - Once a great product, now gradually decaying in the abandoned field of neglected products acquired by Symantec
SC.exe and PSService
CACLS/XCACLS - modify permissions on files and folders
REGINI - modify permissions on registry keys, the old-fashioned way
Scripting - easy/effective/free way to bundle multiple tasks into a single "package"
SMSTrace32 - legacy (and nice) log viewer utility
Virtual Machines - Vmware Workstation, Hyper-V, or anything that supports "snapshots" or the means to save point-in-time state captures which can be reverted to at any time. If it doesn't support snapshots, DO NOT USE IT (yes, this means you: Virtual PC).

The Rub

The rub here is that hardly anyone considers themselves a "packager", much less a "repackager". 99.999% of people I know that invest serious time in this stuff do not call themselves anything close to it. Most go by the titles of "Systems Administrator", or "Systems Engineer" or "IT Manager" or "Programmer". They're still aiming for the same admirable goal: save time and headache by investing the work up front, to save 10x the work later. There are a lot of available software packaging jobs around the U.S. I know, because I get calls and emails every week asking if I want to apply, or if I know anyone else. Talking to recruiters it's obvious that there's a major shortage of this skill set in the U.S., which usually means employers will soon seek out foreign labor or outsource the work overseas. Like a lot of jobs that aren't big-name titles on TV ads for tech schools, the demand is outpacing the supply, and businesses will be forced to fill those jobs with whoever steps up to the plate.

Still Interested? Live in the area? :)

If You Don't Know - SAY You Don't Know

2011-10-24T17:50:00.005-04:00

When the Obama Health Care Reform Act (HCRA) was being dragged around the media like downed solders through a Mogadishu central market, I was asked at least five times per day: "What do you think?" Before I could respond, the other person would almost always launch into a heated, emotional tirade about how evil, bad, and wrong it was and how it was going to destroy our nation and our "way of life".

So I would be patient and, like Ali, would allow my opponent to wear their self out on their own. Then I would calmly respond: "Have you read the Bill itself?"

Not one single person had read it. Not one had even attempted to read it. I had not read it either, so I would follow that up with: "I'll tell you what I think as soon as I've finished reading it and had time to absorb it." The look on their face was as if I just told them I fed their child to a starving Lion. Oh yes. The look. THAT look.

I'm not defending the HCRA by any stretch of the imagination. My modus operandi is to temper all such issues with a measure of how much impact I can *possibly* ever have on it being processed into law. The answer is usually the same: ZERO.

But the key point remains: Before opening your mouth to express an opinion, please, PLEASE, be sure to educate yourself on whatever it is you are opinionating about. And before you ask: NO, watching/listening to cable news shows and podcasts is NOT educating yourself. That's listening to editorialized, subjective, spoon feeding. If you want spoon feeding, then go ahead and watch your favorite "news" person blabber on about what THEY think and program your mushy brain to follow what they want you to follow. After all, that's why God (or whoever you believe in) gave you a brain, right? To shove it into a mold shaped identical to whatever you watch on TV.

Legislative actions are filed in online, public-available, systems that allow you to search, browse and read to your heart's content. There is no excuse in this day and age for not reading the source of a particular subject. If it's not available for you to read, guess what: It's probably not available for you to decide either. So, if a subject is beyond your control, take up a more valuable thing to be concerned with, like arguing over the sunrise or weather.

But the same holds true for technology and just about anything else. Ever hear someone say "Oh, that ____ product sucks" or "____ is a piece of crap." Ask them to back it up with evidence. Not stories, and retelling of past so-called experience, but actual hard numbers, log files, case records, etc. Most of what people tout as fact and "guidance" is utter pure bullshit. There are exceptions, of course. But even they can be wrong or misguided, as we call can be. Read. Learn. Do not wash, rinse and repeat.

A Short Recap of my Career Thus Far

2011-10-23T22:11:00.000-04:00

1984, I left the construction world, and playing in bands, for a job as a "apprentice drafstman" (board drafting, Mylar, Sepia and vellum). I recall lettering 20 ANSI-F title sheets entirely by hand per week for several months on end (notes, references, materials, titleing, very little white space left). My fingers had permanent dents from holding the mechanical pencils.
In 1987 after switching jobs a few times (still drafting) I was dunked into building 3D shipboard engine room models using Computervision CADDS 4X. I worked on that platform for several years.
In 1990, I was sent to training on Intergraph EMS and VDS and worked on that for almost a year.
I was sent to training on Bentley Microstation, but picked up a few books and taught myself AutoCAD R10 by staying late at work and sneaking into the AutoCAD drafting room.
After convincing the CAD dept manager I could work on AutoCAD, I was moved into the AutoCAD group on R11. The U.S. Navy had just issued an official approval for using AutoCAD to make title sheets and bills of material "only". All detail design work was still required to be done by hand (plastic lead on frosted mylar sheets).
In 1992*, the U.S. Navy finally issued an official allowance for AutoCAD detail design work for all contracts.
After months of struggling with bugs in a custom add-on written in AutoLISP and ADS for our company (by a west-coast employee), I decided to learn AutoLISP and add my own workarounds. I picked up a few books, but the best was "AutoLISP Programming by Example" by Gene Straka. One of the best heads-down teach-yourself books I've ever owned.
In 1994 I wrote my own 2D piping system for AutoCAD R12. It grew into an HVAC system, and eventually into electrical and structural as well.
In 1996, I was hired by a large shipyard to lead their first AutoCAD implementation. It was (gulp!) AutoCAD R13 running on Windows NT 3.51. It was a very rough experience, but we somehow got it working. I was also introduced to Brett Rivers, who introduced me to SMS 2.0 and was generous enough to tutor me on how it works and how to use it for deploying AutoCAD and custom add-ons to roughly 3,000 desktops. That eventually grew to 14,000 desktops.
In December 1999, I graduated from Christopher Newport Univsersity with my BS in Information Science.
In February 2000, I was hired by an engineering firm to build a new shipbuilding CAD suite on top of AutoCAD 2000, and consolidate their standalone licensing under AdLM (prior to FlexLM). That moved me into license management, including contracts, support, and auditing.
By 2002 I was on version 2.0 of the new CAD system and had enlisted three team mates to help build out more functionality and features. We joined the Autodesk Developer Network and the alpha "early adopter" program: Pinetop, Tahoe, Banff, Kirkland, Red Deer, Neo, Rio (I left ADN before Postrio)
By 2002 I had been building a lab to prepare for deploying SMS 2003 when the lead for our upcoming NT4 to Win2K Active Directory migration left. I was asked to take over the project lead. I ran into a friend who worked at Microsoft who asked if I wanted to join on Windows Server 2003 pre-beta and Microsoft Software Updates Services (SUS).
March 2003 we completed our migration to Windows Server 2003 and implemented WSUS 2.0 soon after. SMS 2003 was held back to test the forthcoming SCCM (beta program). I began working with ASP, SQL Server, and Windows scripting more and more to automate monitoring and reporting.
2003 I released "The Visual LISP Developer's Bible, 2003 Edition"
By June 2004 I was now wearing three distinct hats: Active Directory Administration, CAD Administration, and CAD software development. By 2006 I had offloaded my CAD software development duties to the team with only occasional involvement. I was now focused on software deployment, patch management, auditing, monitoring and alerts, and SOX compliance.
In Sept 2007, our company imploded when our CEO decided to fuck us all and leave with a smile.
I was hired by a Microsoft partner and trained on MDOP, Softgrid (App-V) and doing odds-and-ends Windows engineering work for various small businesses. I also deployed a full SCCM 2007 site for a city government, which had been a while for me, but it nonetheless went very well. The biggest impact this had on me was getting my head into non-enterprise environments. Until now, I had only worked in larger corporate environments with teams devoted to each role. Now it was about individual services to small customers. I learned 10x in only a few months.
After a few months the economy tanked (early 2008), and we were laid off. I was out looking for a job for several months, but nobody was hiring. I put food on the table by building web sites for various small customers, and helping a law firm with patent application drawings.
In June 2008 I was hired back at a former employer and taught the fine art of software repackaging to facilitate mass deployment (by now 18,000 computers, I think?). Wise Package Studio and Wise Script. I was also tossed back into FlexLM management and FlexNet Manager (which is pretty interesting).
In July 2010 I was hired by a consulting firm and now I combine a lot of the above (sans CAD work) into a mash-up of projects and tasks:

Windows Server 2008 R2 management
Windows 7 deployment and customization
ASP / SQL Server / AD systems automation
FlexLM license services
Autodesk deployment builds and distribution
Repackaging with Wise Package Studio and InstallShield AdminStudio
Scripting with VBscript, CMD and PowerShell
SCCM 2007 process automation and custom reporting

In 2010 I released more books, and again in 2011
I have no idea why I'm bothering to type this. It ultimately means nothing to anyone unless they're spilling food on my resume. I guess the interesting part, to me anyway, is how my ball has bounced in a very unpredictable pattern. Looking back, I can see the pattern emerge. But from any one point along the way there was no discernible pattern or path to be seen. I have learned from some of the brightest and most interesting people I've ever known, and am grateful and humble to having had those opportunities. Every job change has been tough to handle since I hate parting ways with good people, but I've somehow managed to keep finding incredible people to continue learning. If I had millions of dollars, I would love to be able to hire everyone I've known to build a "super team" and make incredible things happen. I doubt that will become reality, but it would be cool. I have no idea where my ball will bounce next, or if it will roll in front of a bus and that'll be the end of it. One day at a time.

* I may be off a bit here, but it was somewhere between 1990 and 1992 as best as I can recall.

Signs of IT Failure

2011-10-22T11:59:00.005-04:00

When it comes time to assess the quality of service amongst your crack team of IT experts, here's a few criteria points to consider:

Turns off UAC as a standard practice.
Grants most users Admin rights.
Re-imaging / Re-installing operating systems as a standard "fix"
Knee-jerks towards scripting, rather than Group Policy for configuration management
Fails to provide tangible metrics to back-up arguments and proposals
Argues against "change" as a standard philosophy
Sole-vendor philosophy without regard to competing products
Avoids meeting with customers / end users at all costs
Avoids meeting with executives at all costs
Spends more time putting out fires than in lab testing future solutions
Assumes they are an expert

AutoCAD: PURGE, AUDIT, RECOVER, Repeat...

2011-10-17T22:22:00.001-04:00

I know I said I wasn't going to write any more AutoCAD-related articles, but this was sparked by a recent client visit, so I felt it was worth revisiting. I've mentioned the AutoCAD PURGE command before, but it needs to be revisited.

Something that is very unique to the world of CAD is the extent to which content is reused. More than any other class of application: word processing, spreadsheets, databases, desktop publishing, even more than photographic and illustration applications. CAD shops around the world routinely insert library content from years of accumulated work. Everything from the smallest items to sheet borders, to complex 3D components and entire compound assemblies. Content is king, and CAD content is the king of kings.

But there's a problem. Along with the visual attributes there is an entire world of non-visual baggage that comes along with every reused chunk of content. Layers, dimension styles, text styles, linetypes, shapes, extended data (xdata) and xrecords, are just a typical brush stroke of examples of things that often sneak in with each library part insertion.

But wait: There's more!

Along with the legacy visual, and sinister non-visual stuff, there's the often overlooked issue of inconsistent and inaccurate data structures. I'm talking about the DWG format itself. With each release of AutoCAD, for example (I'm sure this is applicable to other CAD products), there are improvements to the methods and processes for detecting errors in the data format and correcting them. Some of the tools in AutoCAD that help with this are AUDIT and RECOVER. There's also WBLOCK and DXFOUT, and other methods/tricks, but you get the idea. The problem is that rarely do CAD managers or anyone else take the time to comb back through years of old DWG files to run these tools and clean them up.

Most often what happens is we get into a habit of inserting content, exploding it, erasing what we don't need, then running PURGE and saving. At least run AUDIT when you do that. If you don't, you risk corrupting the new drawing, or at the very least you'll bloat it to death. File size is not something to ignore. The bigger the file, the slower it copies and the slower it gets backed up. It also takes longer to open and longer to save, especially across a network connection.

AUDIT (fix errors)
PURGE (nested)
PURGE (nested) again
AUDIT (fix errors) again
SAVEAS (new dwg file) replace the old dwg file

I haven't bothered to search, but I'm sure there are at least a few products available for helping to batch process drawing files for you. Even if you can't afford to purchase one, you could build something using LISP, VSA, ObjectARX, VBscript, Javascript, KiXtart, PowerShell, or just two sticks and a bucket of mud. Whatever the case, don't ignore this. Just because you ran AUDIT and PURGE on those old drawings back when you used AutoCAD R14 or 2000, doesn't mean they can't still contain errors and junk that AutoCAD 2012 would find and correct.

Children's Guide to Politics and Elections

2011-10-17T19:14:00.001-04:00

Listen up children, this is important stuff. More important than Angry Birds. Yes, I know that's impossible to comprehend, and that "comprehend" is a big word, but it's really really really reeeeeeeeeaaaaally important. So listen up. Yes, I know I already said that. But listen up anyway...

Election

An election is when people choose who the next president will be. Or the next senator, congressman, mayor, councilman, police chief, superintendent, or hall monitor. It makes us feel important and gives us a feeling of making a difference. This is why they say "every vote counts". That's because every vote counts, just not counts towards winning. Some votes count just to be counted but they don't count for anything. You can count on that. If every vote really counts, then whoever is in office is who everyone wanted, so that means every vote counted. When you stand in line to choose, they call that "casting a vote".

Voting

Voting is when your mom, dad, grandmother, grandfather, aunt, uncle, sister or brother, neighbor, teacher and the creepy old guy that takes pictures of you at the park, run over to your school and stand in line to pull a lever or punch a button to say who they want to be our next president, senator, congressman, mayor, or city council person. The only vote that really counts is the one for everyone else *except* for the president. You see, the president is chosen by a special group of people in a secret club called the "Electoral College". They look at your mom and dad's votes and then decide how they want to vote. Only sometimes they decide to vote however they want. Kind of like when your big brother or big sister takes your bowl of ice cream and says they'll beat you up if you tell mom or dad.

Two Party System

There are two political parties, or clubs, that run for every election. One is called the Democrats. The other is called the Republicans. Neither one of them do anything except spend tons and tons and tons of money on annoying TV commercials calling the other side liars and crooks. Their job is to keep everyone busy believing that they're really going to change things, but they never do. If they ever really changed things, we wouldn't need them anymore, so they keep saying they will as long as you keep voting for them. When they don't change anything, they just blame the other side for cheating and messing things up.

The only real difference between these two parties is that one believes everything is broken and everything needs to be fixed with lots and lots of money. The other thinks nothing is broken and nothing ever needs to be fixed and that things will just fix themselves. You are probably part of what was once called the "middle class", which is the special group of people that neither of these parties care about, so you have nothing to worry about.

Special Interest Groups

This is a special name they give special people who carry around special suitcases filled with special cash. Some people call them corporate sponsors. Some call them defense contractors. Some call them late for Tee time at the golf course. But whatever they're called, these are the people who really make the decisions. You see, when Mr. or Ms. Senator is in their office and their secretary rings their phone and says they have a visitor, they look at the list and see someone like your mom or dad, and they tell the secretary to tell them they're extremely busy balancing the budget. They're really practicing their golf putt in the office while wearing nothing but a shirt and tie and underwear. When the secretary says it's Lockheed Martin, or Walmart, they drop the putter and pull up their pants and race real fast to get the office in clean shape to meet with these important people and their important bags of cash.

You see, without those special bags of special cash, they can't afford to buy those interesting and informative TV commercials that you can't wait to watch every day and night. They need those to help re-program your brain to believe their enemy (the other party guy) is a liar and a thief.

Hard Work

Being a politician is hard work. Much harder than brain surgery, being an airline pilot, or digging ditches. It's really tough. How tough? First off, they have to sit at a desk for an hour every day. Then they have to get up, and go to meetings and conferences and give speeches about how hard they're working. Then they have to film more TV commercials and it requires a lot of talking to tell you that his opponent is a liar and a thief and how he's changing things, but he needs your vote to keep changing things. Then they have to muster the courage to go out and play golf with those special interest people with their special golf carts filled with special bags of special money. Afterwards they go to more cocktail parties, which sound fun, but they're not! They have to "mingle" and "schmooze" with other special people so they can talk them into giving him some of their special money.

They do this ridiculously hard stuff for weeks and weeks and then they are forced to go on what's called a sabbatical. It's horrible. They have to take off half of the year and do nothing at all except get paid. It's unbelievably painful and many of them can't handle the stress. When they can't handle the hard work anymore, they tap out (like you see on TV when your dad watches UFC) and they accept an offer to go work for one of those special interest companies and are forced to get more of that special money. Most of the time though, they do their absolute best to help America and Americans by passing special laws to help those special interest people before they quit and take one of those special jobs at the special interest companies. This is called "serving the people".

Conclusion

Well, I hope you learned a lot about our political system. After all, it is the BEST political system in the entire world! Many people say that it's the best one that money can buy, and they aren't kidding. So be sure to get out and vote so you can help these special people keep changing things by helping those special money people. After all, this is America and every vote counts.

What's Next?

2011-10-14T06:00:00.000-04:00

A few people asked why I haven't been on Twitter as much lately.

I responded without saying much, but in reality, it's because I'm just not "feeling it" anymore. The level of response and interaction has dropped to almost nothing lately. Either I'm not tweeting enough interesting things, or I've offended some followers (hence the gradual drop in that area), or both. In any case, it's just something I'm not cut out for. I loved it for a while, but the love is wearing off.

A few other people asked what will I do after I stop posting to this blog.

I will continue to participate on other community sites, as far as technology is concerned. MyITforum, TechNet, StackOverflow, AppDeploy, and a few others. For the non-technical stuff, I will still hang around Google+, and share Google Reader items (with the same stupid comments). I've thought long and hard about the date, and see no reason to move it back (or sooner), so I'm just going to meander to the next fork and decide where to turn when I get there.

Software Development Tips

2011-10-13T23:14:00.000-04:00

Just some notes I pulled out of my ass, after years of swilling cold coffee, munching on stale donuts, rock-hard room temperature pizza chunks, half-empty bags of Skittles and Combos.
Hopefully, especially if you are young and just getting started with writing software code in some new cool programming language (whatever it is), after doing copious amounts of drugs and sucking down bottle after bottle of cheap vodka until 5 a.m., and by the way, if you fit that template: I hate you... maybe these tips will help you in some way.

Under promise and over deliver. Whatever your gut tells you about estimating time or resources, pad the numbers a bit and calmy offer your estimate confidently. Each time you come in sooner or cheaper, you will get a "hero" pin placed upon your chest and more good things will come your way.
Draw, don't Type. When you are in the absolute Genesis of a new project, barely able to envision what this new machine will become, don't put your fingers on a keyboard or keypad at all. Pick up a pen/pencil/marker and a pad of paper and doodle. Diagrams, models, flow charts, mock-ups, and so on are immensely powerful ways to let your mind wander without the distraction and tractor beam of a keyboard. After you've crumpled up half the pad in balls strewn across the floor, you should eventually have a golden page of your master idea. Then go to the keyboard and slay the beast, laughing meniacally all the way.
Beg, Borrow and Steal. DO NOT knee-jerk into writing every line of code on your own. Reinventing the wheel might make you feel good, but it's like beating off to a Sears catalog. The emptiness cannot be filled by self-gratification. Stand on the shoulders of others, especially public-domain, open source "others". Seek out examples of key parts and fill in the gaps with your own inventiveness. Artists don't typically crush their own organic materials and resins to make their own paints. Musicians don't typically cut down trees to trim and bend the wood to make their instruments. Artisans often start with the work done by others before them. I was going to use the house-building example where the workers don't cut down trees, dig up clay or smelt copper, but then I remembered we don't build houses in American anymore, we put them on the market and watch the weeds grow as the price falls every week.
Take a Break. Even if you have a magical brain and endless energy, and you like to glue your ass to your chair for hours on end... it's not the best way to write code. Get up. Go for a walk (or a roll, if you're in a wheelchair). Chat with colleagues. Get your mind OFF of your work for a few minutes. I'm not advocating an hour of bullshitting on the clock. I'm saying 3-5 minutes a few times a day (you know, the same time expended by smokers, people taking a shit, and the time it takes a tier-1 technician to listen to some idiot asshole drone on and on about their latest eBay or Facebook drama). Just getting your mind off of something for a few minutes brings a fresh batch of brain cells online when you return to your coding. Try it sometime.
Engage the Users. It may be painfully dull. It may be time consuming. Don't be like the big corporate machines that have all but walked away from customer engagement. Feedback forms, email, chat, bug reporting tools, PAIL in comparison with face-to-face contact. You'll get exercise, a break from your phone and screen, a chance to check out the hot new interns, the newest snacks in the vending machine, AND... you'll get a chance to get a user to open up and share ideas, concerns, questions and comments. GOLDEN NUGGETS for making your code better. Also, you'll get a chance to explain things that users might never think to ask yet they will appreciate gaining the knowledge and YOUR willingness to help them. It's called customer service and it fucking works great!!
Be Consistent. I can't stress this enough. In code. In documentation. In user interface design. In format and syntax structures. In shapes and color schemes. In life. Everything: BE CONSISTENT. It's funny that IT folks will freak out when a process fails without any apparent pattern to help associate the failures with a coincidental event or action. When it fails with a clear pattern, we can find the root cause with much less effort. Yet we don't see that example and apply it to ourselves. Look at your work and ask yourself "is everything I see consistent?" Formatting, indention, capitalization, naming standards, everything.
Added: Play Devil's Advocate. Ask all the ugly questions: Why would someone NOT want to use your product/service? What are the vulnerabilities? If you were working for your competitor, what would you say to discredit this product/service? What works "as well" or better than this product or service, and why? Don't let your ego creep into this discussion at all. Act and think as if you have no stake in this project, how could it be picked apart? Once you've asked the tough questions, develop a list of responses to it. Not just "answers", but determine solutions to mitigate those vulnerable spots.
Added: Accept Criticisms. Invite one or two of your peers to look at your idea and your code. Listen to their suggestions. If they lay on acclaim and accolades, be thankful, but press them to offer some professional criticism. If you don't work in an environment where you can trust your peers, you have other challenges to solve. If you don't have any peers to seek out, fear not, there are alternatives: Post your ideas on StackOverflow.com (or one of it's many child sites) and seek input/feedback. Any feedback is better than none. Don't create in a vacuum.

PSEXEC, Computer$ and SYSTEM Access

2011-10-13T19:22:00.000-04:00

This recent post on the ConfigManager Team Blog ("How to quickly and easily test your ConfigMgr packages") mentions an EXTREMELY POWERFUL yet often forgotten capability at our disposal:

Using PSEXEC to test SYSTEM account access, both locally and remotely.

I've posted articles numerous times on why I prefer using the SYSTEM account to run scheduled tasks for EVERYTHING, rather than a standard proxy or "service" user account. Most sysadmins will create a special account, either locally or (more often) in Active Directory, and grant it God-like powers, and use it for running everything from critical services to backup operations, and more. But when it comes time to manage the password changes, shit gets ugly and scarry. I don't care if you spend tons of money on utilities to manage that for you, it's a waste of time and money.

Use the SYSTEM account. For local processing it's the typical way to go anyway. But for remote jobs it's also the best way to go. Why?

You don't EVER have to mess with passwords. So if one of your admins quits, that's one less account you have to worry about being comprised by a password leak.

The account is tied directly to a host computer, so anything performed is done from a known origin (computer), rather than a nebulous user account, which can be invoked from anywhere. When an event log shows the user entry, it will show COMPUTER$ (where "COMPUTER" is the NetBIOS name of the host computer from which the SYSTEM account was invoked). It works great for shutting up SOX whiners too.

There's already a group for DOMAIN COMPUTERS, which is never used. You can create others like BACKUP SERVERS, and BATCH SERVERS, and whatever.

Testing the access of one SYSTEM account against a remote resource used to be tricky and involved things like setting up a one-time AT scheduled task in order to gain access to an interactive CMD session under your own user context (inside the console running as SYSTEM).

psexec -s cmd

This is so easy, yet so powerful. Once you open the SYSTEM context, you can perform DIR commands to test access to various resources, run installation packages, uninstall products, modify the registry, run WMIC commands, bat/cmd, powershell and vbscript tasks, and so on.

Winding Down, Weekend Brain Dump

2011-10-13T18:31:00.000-04:00

Randomness ensues.

I taught a 2 hour session at work on COM scripting. Everything from COM itself, to the DLL-ProgID-GUID-HKCR relationships to standard OOP stuff (classes, templates, properties, methods, all of it), and into invocation and interface processing. Small group, so that went very well, and we had breathing room to explore questions, yet without falling off the wagon along the way. It was good.

After that I taught another session on using a web application that I developed for a different (still small) group, which went very well. I love face-to-face discussion. Web/remote is ok. Phone is lame. E-mail is lame-er.

In that second session, I gathered more input for bug fixes, enhancements and new features in one hour than I received in months via web, email or phone. Big corporate development teams: You don't know what you're missing. Focus groups are not the answer. Direct, immediate, personal contact is the best. It's the only real way to get quality input and have a quality, high-value discussion as well.

I switched the blog over to use the newest Blogger features with dynamic views, the new rendering layout, and the new analytics tools, and I have to say I absolutely LOVE it. You might not be as impressed with the new look as I am, but behind the scenes, the administrative changes are fantastic. Too nice to ignore, so I followed my typical "beta-tester" mentality and dove in head-first. I am aware that the sidebar doesn't play well in Internet Explorer 9, but that's because IE9 doesn't handle HTML5 and CSS3 consistently with Chrome or Firefox (or Opera, I'm told). I use IE9 and Chrome 16 at work about 50/50, but at home it's Chrome 16 100%. I only fire up Firefox 7 to test page rendering and that's about it. DISCLAIMER: I'm not saying one browser is "better" than any other. Everyone is free to like what they like.

I'm still a bit fried from three-plus hours of talking and pointing without a break. I got home and hadn't eaten in six hours (not good, and not usual for me), and immediately gave into a cold glass of beer. That wasn't a good idea either, but it seemed like it at the time. Heh heh.

Still listening to Adam Carolla's podcast show every day. Today he again brought up how suck-ass most 80's songs were, and I have to say that I now listen to them with new ears and most of them do in fact suck holy shit. Not so much from a musical aspect, but lyrically they are bankrupt. Those folks were not writing shit down back then, they were winging it and most of it sounds like a recorder was left on during a Narcotics Anonymous session.

Randomness ensues. Enjoy your weekend!

What if AutoLISP were Unleashed?

2011-10-11T22:28:00.000-04:00

Way back when, (a completely meaningless phrase of course), Autodesk had the audacity to introduce a radically new concept into a software product: Extensive Programmability. They did that using DIESEL, AutoLISP, and the MNU file. They could have just dropped a “here-you-go-take-it-as-is” product without any meaningful customization features or tools, but they didn’t. Autodesk instead decided to empower their customers, enabling them to extend and reshape their products to suit their own needs. This simple decision had a profound impact on their customer base, as well as product sales. Indeed, it created an entire community and industry that otherwise wouldn’t have existed.

I’ll spare you the regurgitated history stuff, you can look that up online.

There is something that has been ticking around in the back of my head for a long time:

What if Autodesk had ported the AutoLISP platform outside of AutoCAD?

Keep in mind that this was in the 1980’s, and Java didn’t yet exist, neither did .NET. The most popular “cross-platform” scripting toolset at the time was Perl (and ActivePerl). Most AutoLISP programmers I knew between 1988 and 1995 were always wishing for more OS features, many of which were made possible through third-party tools like Robert McNeel’s DOSlib. There were also many that begged for a better dialog programming toolset, which was later made possible by OpenDCL, another third-party product.

Autodesk however had other desires. They were starting to drink the Microsoft Kool-Aid, and decided to drop LISP at the altar and run off to Vegas with VBA. After all, she was hotter and wore thongs and high heels at the time. Then when VBA put on a few pounds and started wearing sweats around the house without make-up, they ran off to Bangkok with the svelte .NET, along with a crate of condoms and a case of Bud. LISP was left in the alley, panhandling for spare change, needle tracks were starting to show on her arms. AutoLISP was swapped with Visual LISP, which remains to this day, but is ignored in much the same way as Middle Class workers are in America. The world of AutoCAD customization now belongs to ObjectARX, or so we're told.

I won't go into the flaws with this mindset of ObjectARX over LISP, but I know that I'm not alone in feeling it's a huge mistake to ignore Visual LISP they way it's been ignored thus far.

But what if? What if not only had they continued to breathe life into Visual LISP, but they had made it possible to run AutoLISP code from a dedicated script engine from outside AutoCAD? I'm talking about much like was/is possible using ActivePerl, KiXtart, CMD or VBScript. Imagine the power that thing could’ve unleashed for LISP programmers. I can only imagine the potential it could have had for much more than batch processing of DWG files. Granted, the constraints of AutoLISP capabilities would have required a significant amount of expansion, which was in short supply after the acquisition of Vital LISP® was renamed Visual LISP®. It was as if they had adopted a 3 year old child who spoke an unknown language, so they left him alone in the toy room with the dog, tossing food on the floor, and quickly shutting the door.

Imagine the potential of combining the file system features of DOSlib with the dialog building features of OpenDCL with powerful intrinsic functions like (mapcar), (apply) and (lambda). In case you need a poke in the brain: Remember that LISP is built for recursion and that file systems are perfect for recursive operations. Not just file systems either, but any data source.

The basic tenants were fairly unimpressive: a script engine that is ported to various “present day” platforms (Windows, OSX, Linux) which executes the same code the same way. Gee. That sounds a bit like Java. That also sounds like .NET, sort of, maybe more like Project Mono. But those two platforms weren't even concepts in 1990. In any case, you get the idea. That is, if you’re still awake and reading this far. I’m guessing few of you have read this far without falling asleep or moving on to something more interesting.

Alas, this idea was never on the table, officially, so it never could’ve become reality. Never mind that there haven't been any meaningful updates to VLIDE or Visual LISP in years. I'm still a pie-in-the-sky person, and I'm often given to dream crazy things.

Because it Was Overdue

2011-10-11T22:27:00.001-04:00

It was time for a new look and a new layout, and as luck would have it: Google has recently backed up the truck of feature updates for Blogger and dumped an insane load of changes on all parts of it. It is freaking awesome what they've done. From new themes, new features and options down to integration of Google Analytics reporting tools and best of all: the clean Metro-ish theme style of the admin console pages. I love it. You may hate it, but I love it. In any case, play with the sidebar drop-down menu and behold the increditastical fantazing cool changes.

Amazon Kindle Books: German and French available

2011-10-09T21:17:00.001-04:00

Amazon has opened up Kindle and Kindle eBook sales for French customers, in addition to the existing US, German and UK sales channels. This means you can now purchase eBooks in more places with your local currency. Why not take advantage of this by grabbing one of my books! (shameless plug)

The Visual LISP Developer's Bible, 2011 Edition

The AutoCAD Network Administrator's Bible, 2012 Edition

The Packager's Pocket Reference

Self-Assembly is the Future

2011-10-09T19:18:00.001-04:00

When I was blabbering about "organic architecture" and "organic programming" concepts a short while ago, this is one example. These are macro objects. In decades from now, they will have this shrunken down much smaller. Imagine where this could lead us.

IT Job Openings in Hampton Roads, Virginia

2011-10-07T07:56:00.001-04:00

The consulting firm I work for has quite a few job openings in the Hampton Roads area that we are trying to fill. If you live in or near the cities of Norfolk, Chesapeake, Virginia Beach, or Suffolk, and are interested in any of these positions, contact me at ds0934 (at) gmail (dot) com, and attach your resume in MS Word format. Use the subject line "IT Positions" so I don't tag it as spam.

Package/Workstation engineer - (Wise Installer or AdminStudio, SCCM, Windows 7, etc.)
Project Team Engineer - (VMware, Windows, Exchange, AD, light Cisco, SAN)
Help Desk Analyst (Windows 7/Office/Light Networking/Great Client phone skills)
Macintosh Engineer
Engineer for option to hire for large client in Suffolk (Windows 2008, Exchange, Cisco, Light VMware)
Engineer for option to hire for large client in Virginia Beach (Windows 2008, Exchange 2007/2010, AD, VMware)
Engineer for option to hire for client in Newports News. Will be at shipyard. (Windows, Linux, Light Networking, etc.) CAD experience is nice but not required.

When Applications Take a Dump

2011-10-06T20:20:00.001-04:00

How many times have you uninstalled a software product only to find out later that it left traces of its existence all over your poor computer? Part of the work of a software packager (or rather: repackager) is to perform forensic analysis of the footprint of an application at the time of installation, after being used, and after being uninstalled. The goal is always to get the computer back to a state as if the application had never been installed, but without causing issues with the operating system or other applications. Rather than try to split this over XP, Vista and Windows 7, I'm only talking about 7 here. I don't give a crap about XP or Vista anymore, sorry. If the %name% stuff confuses you, just open a CMD window, type in SET and press Enter to see what I'm talking about.

The Obvious

%ProgramFiles%
%WinDir%\System32
%CommonProgramFiles%
%AllUsersProfile% (note: This is a Symbolic Link to %ProgramData%, same place)
%ProgramData%
%Temp%
HKLM\SOFTWARE\<vendor-or-product>
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

The Not-So-Obvious

64-bit Systems

%ProgramFiles(x86)%
%CommonProgramFiles(x86)%
HKLM\Software\Wow6432Node\...

%LocalAppData%
%SystemDrive%\Users\Default (note: "Default User" is a JUNCTION to "Default", same place)
Services
DCOM configuration settings
WMI / CIM namespaces
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (and RunOnce)
HKLM\SOFTWARE\Microsoft\Active Setup\...
HKLM\SOFTWARE\ODBC\...
HKEY_CLASSES_ROOT\...
HKLM\SYSTEM\CurrentControlSet\...
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
%ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup

This is not a complete list. Some applications crap in more places than these. But hopefully this gives you a rough idea of places to look when something gets left behind and things are just not quite right as a result.

Tools

Some of the tools that can come in handy to help investigate what an application does to a computer are as follows:

Virtualization: VMware Player, VMware Workstation, Virtual Box, Hyper-V
Sysinternals: Process Explorer, AutoRuns, Process Monitor
CMD: DIR /AH /AS
InstallShield Repackager (snapshot results)

Software Development's Biggest Mistakes

2011-10-06T18:07:00.001-04:00

The most common and most detrimental mistakes that seem to occur again and again. I'm not saying you need to "master" all of these, but you should be familiar enough with all of these aspects to be able to explain them to your grandmother. Hopefully you strive to apply these in your daily work.

Not Understanding Programming Basics

Decision Branching (If / Then / Else / Select /Switch / Cond / ElseIf, etc.)
Boolean Logic (And, Not, Or, etc.)
Functions, Sub-Routines, Lambda Expressions
Iteration and Recursion (While, Do, For, Apply, Mapcar, etc.)
Variable Scopes (local, private, global, public, etc.)
Not understanding all of the Data Types for a given language
Not understanding String Behaviors (for given language)
Not understanding File Streams
Ignoring ERROR/EXCEPTION HANDLING (Gaa!!!! GD IT!!!)
Not Documenting source code (it ain't just for others, it helps you as well, especially when you go back to fix something a year later)
Modularity / Code Reuse

Not Understanding Databases

Ignorant of Table Structures and Data Types
Ignorant of Constraints
Normalization !!!!!!!!! God damn it! Normalize your fucking tables!!!
Views and Stored Procedures
Using MS-Access to build applications (GD IT!!!!!!! teeth gnashing)
Excel is NOT a database!

Not Understanding User Context

Assuming users have administrator rights (kill the developer on sight!)
Not understanding Multi-user / Shared computer environments
Not understanding Terminal Services / Server Shared environments
Not understanding Service / Proxy accounts

Not Understanding the Installation (and Uninstall) Process

Not following the documented guidelines (TechNet, MSDN)
Not providing a Silent/Unattended installation option
Not providing a Silent/Unattended Uninstallation option
Not using MSI-based installers (Windows only) - a setup bootstrap is ok, but building your own installer is just stupid as shit. And stop with the no-name bullshit setup packagers, just buy Wise or InstallShield and do it right, mmmkay?

Ignoring Cohesion and Consistency

Installation scatters crap all over the place, rather than keeping it collocated logically
Application stores state data in too many locations (registry and files, and ...)
Forgetting to REFACTOR your code (using the rollback method, where you revisit project "A" after finishing product "C" to apply what you learned since)
Ignoring common naming conventions. Name your code files, functions, variables, registry keys, event entries, database names, tables, views, procedures, services and everything CONSISTENTLY! If you don't care enough to make your code look like it works as an integral army of awesomeness, what else don't you care about? Making it work properly?!

Becoming Locked into One Language

Learning and Using ONE language is like eating with only a fork. No spoon or knife? It's like trying to rebuild a car engine with only a screw driver. Languages are tools. The more you learn and apply, the broader your skills, understanding and wisdom about methods, approaches, and quality.
Never assume an "old" language has nothing to offer. There are still plenty of situations where an "old" BAT script will work more efficiently than VBscript or PowerShell. Where an INI file will work more efficiently than an XML file or a database table query.
Arguing in defense of ONE language above all others. Within the context of a particular project or contract, this is acceptable. However, in the global scope of programming, this is the sign of a complete idiot.
Buying books on one language before reading books on general programming practices and theory is just stupid. This is like reading a book on 1001 ways to use a fork to eat. Why not read up on eating, then learn about the tools, that way you understand why you're using the fork, and not just how to use it.

What can you do about it?

Read Books on Programming topics (not just an "Unleashed" book on your favorite language)
Read some useful Blogs about programming
Go to School (a university, not a for-profit tech school)
Join MSDN or TechNet or something similar (and use it!)
Meet with other programmers - ESPECIALLY programmers that work with other languages, database engineers and administrators, network engineers, etc.

The Never-Ending War: Centralized IT vs Department Developers

2011-10-04T07:00:00.000-04:00

I doubt any of you will read this one to the end, and I can't blame you. But I have to say that this is probably one of my best articles so far. It's one that I'm fairly passionate about and it shows in my verbosity. I apologize for torturing your eyeballs in advance, but I must go on.

For many of you, this scenario should sound pretty familiar:

A large corporate business evolves over decades to the point where they decide it makes sense to centralize their IT operations. They create a new department and appoint a CTO or CIO and staff the various functions. Prior to this, it was common to find each department building and maintaining their own unique software applications to solve their own internal business needs, aka "line of business" applications ("LOB" for short). In decades past, it was dBase or FoxPro. In more recent times it's been Microsoft Access or Excel. Quite often, it involves VBA code. Lots and lots of VBA code.

The centralized IT department strives to gather all of the LOB applications and apply some centralized procedures to maintaining it. Maybe the company is trying to be ISO or CMMI compliant, or maybe ITIL, or whatever. Who knows. In any case, the MBA mindset comes to the logical conclusion that redudant job roles are expensive and inefficient, especially when one person in Finance is building roughly the same application as the person in Sales. These isolated, parallel and typically redundant efforts have no incentive or desire to coordinate efforts with other departments due to politics and funding, so they march on unrestricted for years.

When IT finally gains control of a few of the key LOB applications, they apply common ITIL or CMMI procedures on change control, which invariably slows down the process of implementing updates. The LOB folks quickly grow tired of this, and eventually pull away from IT to continue building their own applications. The cycle continues.

This is often referred to as a "NO-WIN SITUATION", because that's exactly what it is.

The top management folks are left with two options:

Ignore it and leave the fighting to the lower level managers
Stress out trying to make a decision over which is the lesser evil: inefficiency or inefficiency.

The two greatest risks facing them are:

Allowing the redundant waste of time and resources to grow unchecked (because it's NEVER really checked) and allow inconsistent results to spread. The practice increasingly melds the company core business processes to hundreds of tiny little tools built by people that have worked themselves into a position of necessity (cant' fire them or you risk being stuck with a broken tool and a busted business process)
Forcing the LOB apps under the control of the IT department, becoming painfully slow at responding to surge-capacity, and frequent requirements changes. Everything must now be vetted, developed, tested and implemented under the new procedures. No more "walk-up" requests. No more Summer intern kid-turned-full-time-developer to handle your needs. LOB requests now get routed through a load-sharing process to "resources" which share their precious time with other (possibly competing) LOB requests.

Ugliness. Bad feelings. Animosity. All that kind of stuff.

This is one of the reasons I F-ING HATE MICROSOFT ACCESS

The product itself is not bad or evil. Fire isn't bad, when used properly. Each serves a noble purpose. But fires created by a small group of trained professionals is one thing. Handing every person in a 10 mile radius a can of gasoline and a box of matches is a little different. Server backended applications are like the trained professionals. Microsoft Access is like a truckload of gasoline cans and matches being handed out like rice bags from a UN truck in Rwanda.

The most common scenario today involves this vicious cycle of stupidity:

The Sales department asks a promising Summer intern to build them an uber sales tracking app. Uber-brainy intern cracks open a "Access VBA Unleashed" book, and builds the new application in MS Access 2000 using lots of VBA.
Years later, the company decides to take advantage of volume licensing and buys into a SELECT or ENTERPRISE AGREEMENT contract to get upgrades more cheaply. The Company recieves licensing for Office 2010 and wants to upgrade all computers ASAP.
The Sales department cries that Access 2010 will break their LOB app. They cry to upper management. IT is ordered to put the upgrade plans on hold.
The IT department now decides on one of two courses of action:
- Dedicate several developers to re-developing the application to work in Access 2010, but they don't understand the LOB requirements or logic, so they have to work closely with the Sales department to gain better understanding. They also have to decide how to address deprecated functionality (from Access/VBA 2000 to 2010), and incorporate new features, or if there is even enough time to do that, or just patch it up and make it work.
- Dedicate several developers to shoehorn the old application to work via the Access 2000 runtime engine, if that even works (sometimes it does, sometimes it doesn't). This often becomes a mess, with file associations getting corrupted and interaction issues with other third-party applications.
The plan to deploy Office 2010 is now sidelined until they can adequately resolve this dilemma.
By the time a solution is reached, Office 2012 is released and the process repeats

Either way, it ends up being a long, drawn-out waste of time, money and effort. Sure, it can be argued that it's not a waste because it's provides (hopefully) a workable solution. But if the entire problem COULD have been avoided by adopting proven practices, isn't that ultimately a waste?

A database is a database. It should be used as a database, not as an end-user application platform. Client/Server or web-based interfaces would easily decouple the functionality from the data store. Then if the only thing that changes are the database connection parameters, you don't have to rewrite the entire application. In many mature development environments, this is considered programming 101.

You probably won't believe me, but I actually do get sick of hearing myself talk and get queazy reading my own drivel. But painful as it may be, I must go here...

Over-Caffeinated Rant (deep inhale, and....)

I haven't really delved into the virtues of decoupled business logic in n-tier applications architecture. There's an enormously powerful incentive to following this time-tested and well-proven approach, which is along the same lines of logic as multi-stage code compilation, assembly line production, and zone defense in team sports. That is, that compartmentalizing certain logical blocks of functionality make those blocks portable and flexible. It makes them more easily (and more affordably) adaptable to future changes. You know, those future changes that are quite often unforeseeable and unpredictable? It also tends to make those newly defined blocks more efficient, both in construction and execution performance.

But things like n-tier business logic and decoupling are rarely familiar terms to the Summer intern who happens to dig tinkering with VBA (or VSTO) within Office applications like Excel and Access. To them, it's just fun to code, and who can blame them? How do you effectively convince this wunderkind teenager that "fun" isn't as "cool" as decoupling your code and applying standard design prinicipals to it before ever punching a key or clicking a mouse? It's a serious conundrum for businesses of all sizes, but particularly insidiuos and debilitating for larger corporate behemoths due to their scales of inefficiency at all levels. Who is the best equipped, and motivated to insert themselves into this vicious chain reaction and disrupt it entirely: IT, LOB stake-owners, or senior management? IT rarely has the global authority to stomp out such wildfires alone. LOB stake-owners rarely have the global incentive. Senior management doesn't give a shit because that's why they hired mid-level management to insulate them from. When LOB stake-owners are coupled with mid-level management (often one and the same), it's a done deal: nothing is going to improve. This is the most common scenario in modern corporations today. A Catch-22.

My coffee just ran out.

What Can Fail: Software Deployments

2011-10-03T06:48:00.000-04:00

If you're using Microsoft System Center Configuration Manager, you're well aware that there's a lot of moving parts. It often seems like staring into the back of an opened pocket watch, being awed by the mass of tiny gears working in such precision. If you've been working with it for a long time, you're also likely aware that hiccups occur and that they tend to happen in certain places more than others. Most CM administrators I know become familiar with particular groups of issues and have developed their own personal "solution" practices to troubleshoot and resolve them.

Package Configuration - check the data source settings, and the permissions on the folders and shares also. Some packages don't need to be broadcast over the DP shares since they can't install from them at zero hour. For example: AutoCAD network deployments, which contain a hard-coded UNC reference to the original administrative share location. Yet it's very easy to let it be replicated, slowly (lots of content), and eat up a lot of disk space, when the installations will simply run back to the original location to pull installation content. Tip: Use a script to call the installation, where only the script is replicated to the DP shares, but make sure the original share has permissions configured properly to allow the CM client/agent to install it via the advertisement.

Program Configuration - verify the command you entered as well as any additional parameters (aka "arguments"). Also, verify the disk space requirements and runtime limit value. If you specify too large of values, some clients may fail the requirements assessment and the program won't run. This will show up in the advertisement status details web reports for each client. Watch out for quoted string values and special characters also.

Client Cache - the client cache can be a common source of headaches when deploying packages, especially when the same package has been updated several times, refreshed on the DPs, and re-run multiple times (usually to fix late-discovered issues). It's not uncommon to have to manually clear out the previous package cache remains on a problem client. It's not uncommon to have to clear out other/older deployments as well, just to free up total cache space. Double check the client cache size setting also, but be careful about bumping the size up without carefully considering the ramifications as well.

WMI issues - as with many client health improvements in Configuration Manager 2012, I'm looking forward to seeing this issue go away. You may be aware of the situations where you end up having to run a repair operation on the WMI stack in order to get a particular client to communicate with the site again. Ugh.

Maintenance Windows - if you use maintenance windows for your CM site, be sure to evaluate how your software updates are being deployed and how it impacts other packages as well. Sometimes a small adjustment is all it takes to make it work, or not work at all.

Network Issues - with all the incredible power and complexity of Configuration Manager, it can't do anything if the network isn't reliable.

Anti-Virus Hurdles - yep. sometimes anti-virus products can get in the way with deployments. Quite often by ripping out just one or two key components during the installation process (or right after) and crippling the application. If an application works fine in your test environment, but not on the production environment, check the antivirus scan logs and quarantine reports.

Prerequisites - many software products expect things to be at least up to a certain baseline before they can install. Sometimes they will also take care of filling in any missing requirements. Sometimes they can't, and when they can't, they fail to install. This should be addressed during testing, but sometimes things get missed. Other times it stems from human communication issues. You might have asked the desktop support team if .NET 4.0 was on every client and they might have said it was, when in fact it was only on some computers, and you didn't bother to verify this yourself. There you go.

Custom Packaging - if you (or someone you work with) created the installation source internally, verify any pre-requisites: operating system, version, service pack level, .NET or IE requirements, 32-bit or 64-bit, and so on. This should all be hammered out during testing, but sometimes things get missed.

Square 1 - Level 0 - if the application you're looking to deploy needs to be part of every desktop and laptop in your organization, don't forget to consider making it part of your standard image deployment as well. If you use MDT or Configuration Manager OSD to handle your client provisioning, add your application there as well. That way it's one less thing to push over the network later on. It's also quite a bit less complext to implement and troubleshoot during the base imaging process than when deploying over your network environment later.

Summary

I must say that you shouldn't construe this to be a ridicule of Configuration Manager 2007 at all. Configuration Manager is a fantastic product. But like all products that serve a similar role, there's a lot of intricate things going on in the background, and a lot of things depend on how you configure and maintain them as well. Many CM implementations experience only minor hiccups, while others have more frequent issues. A lot of that is dependent upon how well the environment was designed, implemented and maintained. It also depends on how well the clients are maintained, but software installers themselves are often the wild variable in the equation.

I'm sure there's more to add to this list, but this is enough to jot down for now. For more insight into Configuration Manager and package deployments, check out some of the links below:

I know I haven't even come close to covering everyone that I should, but if you check out these folks, and see who they link to, you should end up with a pretty good list of amazing and interesting people to learn from.

Weekend

2011-10-01T09:50:00.001-04:00

I'm driving up to Richmond, VA for the weekend, but I have uploaded a post on Configuration Manager software deployments for Monday. It's a short article, but I hope to hear back from you with your thoughts on the subject and the individual aspects I discuss. Until then: cheers!

Swallowing Without Looking

2011-09-30T06:00:00.000-04:00

Sometimes I have to stop and question things that just don't quite seem right. Maybe it's because I'm a big fan of George Carlin, Frank Zappa and others that never made a habit of accepting things blindly.

Case in point: Light Rail safety PSA campaign

The ads say "Light rail safety. It begins with you."

This is wrong. There is no logic in this statement whatsoever. None. Zero. It's completely wrong and stupid. The fact that people accept this statement without question, is one thing. But when people take it up on defensive posture during a discussion, well, that's just shitheaded.

Is it bad to emphasize safety? No.

Is it bad to suggest pedestrians and drivers be safe around light rail systems? No.

So what's wrong?

Here's what's wrong: Light rail safety, like any infrastructure-oriented safety, doesn't "begin" with "you". It begins with a safe design.

PERIOD.

Consider this: If a system makes it not only possible, but probable, even predictably probable, for a categorical "accident" to occur, it has failed the safe design test. FAILED. This is one of the basic tenants of statistical analysis. You're supposed to strive to minimize risk and failure in any system that adds risk to human life or well-being. A basic statistician can calculate the relative risk deviations between two alternative design patterns. A categorical failure would be a pedestrian interaction with the movement of the train car, or that between a personal or commercial vehicle and a train car.

Typically, the approach would be to identify parallel "baseline" systems to assess comparative risk and probability. This isn't the first light rail system to be built in a U.S. city. There are likely many "lessons learned" that could provide excellent baselines on which to determine the relative deviations and risks. Damn. I think that's also referred to as "learning from past experience".

The next step would be to take that assessment data and work to mitigate those risks to "close the gap" between the proposed design and other existing designs. For example, to mitigate the risk of a collision between ground-dwelling pedestrians, cars, trucks, motorcycles and buses, you could raise the light rail tracks above ground to provide isolation. Gee. Sound familiar to any of you folks in Chicago? This also serves another, equally important goal: isolating new systems from interfering with existing systems.

The culprit here is obvious: Funding. But funding was actually a symptom of politics, as it usually is. In this case, the other near-by cities backed off from committing to the project because of political pressure to cut spending across the board in a Recession. So Norfolk went for it alone. Because they couldn't afford the added costs of raising the tracks from end-to-end, we have a system that is less than ideal, but workable. Risky, but predictably so, at least somewhat.

Would an elevated track design be the perfect solution? Nothing is perfect. However, such a design change would arguably provide risk mitigation for at least two of the identified categorical risks: interference and collision. These two risks are very high on the probability score for causing injury or death, which are bad (at least, that's what I was told).

They knew of these risks well in advance. Otherwise, how would they have scripted and produced the ads to convey this message a year ahead of the grand opening?

When someone or some people collectively agree to proceed with something that has known dangers, we call it "acceptable risk". Drug companies, tobacco companies and car manufacturers operate on acceptable risk every second of every day. So do pilots, divers, EOD technicians, and even school teachers. You do it to: every time you drive your car, motorcycle or truck.

There are no "sort of" grades here though. A logical statement is a logical statement - or it isn't. Think of commercial aircraft: What if the airlines said that safety of the aircraft in flight "begins with YOU", rather than with a safe aircraft, trained crew and reliable parts? Still make sense to you? How about, "safety in the operating room - begins with YOU", rather than a skilled surgeon and staff, and sterile equipment? That would be stupid. So is arguing that "we" as riders are primarily responsible for the safety of the light rail system. Stop letting these D-grade marketing ad campaign morons off the hook. I'm convinced the ads are dumb is because Norfolk couldn't afford to pay for a better Advertising firm, which I can understand.

Am I overreacting? Maybe. Or is it shining a light on yet another whittling away at our collective sense of acceptable logic? Remember when you were five or six, and you questioned everything you saw or heard? Why did you stop? Why do we all stop?

How then, should the PSA have been worded?

"Light rail safety. It's important for all of us."

The Zen of Systems Automation

2011-09-29T20:29:00.001-04:00

Level 1 - Writing scripts, hacking code, building your own solutions

Level 2 - Finding existing scripts, code, solutions and leveraging them with a little effort

Level 3 - Leveraging built-in functionality without having to write any custom additions

Level 4 - Systems run themselves. You drink beer and focus on other things

Interaction is Highly Overrated

2011-09-29T19:58:00.001-04:00

Compact rambling edition: As in, compact text format. Tough on the eyes? Suck it up. Some people don't have a computer. Some people don't have eyes. Some don't even have fingers. Let's see you complain now. I didn't think so.

So much for part 1 of my grand "experiment". Not even one response to the questions on my quasi exam? Geez. I expected at least one reply. Just for that, I'm not posting the answers. You guys can figure it out using Google. No more of those. From now on: random stupidity. Actually, I can probably chock that up to making it too long for most people to even read the whole stupid thing. Still with me? Just checking. As I've mentioned before, this is wearing on me, and my Dec 24 date is still on track at this point. At my current rate of descent, remaining fuel, and distance to that target, I should just about make it before completely burning out. Buckshot doesn't go as far as a single projectile, just as scattered thoughts don't travel as far as the focused. I'm looking upon this as retirement. Still there? Ok. Four years of rambling incessantly is losing its luster. Some days I get a spark to ramble upon; other days I'm inspired by something from work, and some days it's just a brain dump of utter stupidity. I mean, as much as I truly miss Ze Frank's "Show", I can appreciate how much he worked on that and why it only lasted one year. No, I haven't been drinking, and no, I haven't gone without sleep. I'm actually amazingly lucid right now, even though it's been a long day within a very long and crazy work week.

I'm looking forward to this weekend. Tomorrow: Friday, is supposed to be the last Summer-like day of the year, getting once again into the 80's. Saturday will only reach the mid 60's and be windy. Fall is here. In Virginia that lasts about a week and then we break out the coats and put the shorts in the bottom drawer for next year. The only major thing I'm anticipating now is starting my treatments for skin cancer. Don't freak, I don't have full-blown cancer yet. It's pre-cancer treatment, so that makes it pre-chemo? Anyhow, not a surprise given how much I live outdoors and with freckled skin, well, you know. Anyhow, October is going to be interesting. I can't complain since several of my friends have had or have full-blown Cancer and are soldering on through it bravely. No whining here. So far, so good. I've always said that God may love me, but he/she sure doesn't like me. Not letting me croak yet, more punishment to dish out to me yet I'm sure. I'm actually more looking forward to the grand opening of the new Yard House pub in Virginia Beach in mid November. That will make for two Christmas's this year.

Testing. Testing. Testicles?

2011-09-28T20:39:00.001-04:00

I'm guessing that got your attention. I'm going to be doing an experiment. I do lots of experiments, experimentally speaking of course. What I'm doing now is trying on different topics and subject matter to see how traffic responds. I've given up asking for input, nobody responds. At least not with anything specific or clarifying in any way. So this ship is still adrift without a rudder. The two recent posts on Autodesk network deployments are a part of this experiment.

Here's what I'm seeing so far:

The 5 most popular articles I've posted thus far, based on unique visits between January 1, 2011 and September 28, 2011 are...

Title	Hits
Home Page (changes often)	3,624
Windows 7, MSG.exe and Group Policy Preferences	3,120
Enabling Windows 7 Remote Management via Group Policy	1,808
What does the AutoCAD PURGE Command Do?	1,779
Packaging Autodesk DWG TrueView 2011	1,449
Packaging & Deployment of AutoCAD 2011 Products with System Center Configuration Manager 2007	816

Based on these numbers, I could draw one of two conclusions:

A. Windows 7 topics are the most popular ... or ...

B. Most of you just read whatever happens to be on my home page

Ugh. Face-palm. I'm talking nonsense to myself about nonsensicle nonsense. The irony for me is that I receive a lot of e-mail asking for various things, mostly related to AutoCAD or Autodesk product issues, especially deployments and licensing services, etc. I'd like to ablige with more focused content, but I need feedback from YOU to point me in the right direction.

Autodesk Network Deployment Strategies

2011-09-27T22:00:00.001-04:00

This is going to be sort of an extension of yesterday's post and on some of the topics covered in my book "The AutoCAD Network Administrator's Bible". Mainly: how to unleash an Autodesk network deployment installation on your network with some logical and strategic efficiency regarding traffic isolation.

If you've ever taken a certification exam, this may all seem very familiar.

Background

Let's start with a model: Fictional Corporation

New York, NY - is the main data center for the company. The data center is state of the art with blade servers, SAN device arrays, and virtualized servers and virtual data center switches. While being the largest office in the company, there are no AutoCAD users in this office, at present. However, the company IT department creates and maintains all software distribution resources for the company. They build the AutoCAD network deployment and host it (initially) in the NY data center.

Chicago, IL - is the second largest office in the company, but has the largest concentration of AutoCAD users in the company. The connection between NY and Chicago uses multiple/redundant T-1 connections.

Washington, DC - is the third largest office, with the fewest AutoCAD users. The connection link between NY and DC is fractional T-1. Not bad, and not unreliable, but not as fast as the NY-Chicago link

Virginia Beach, VA - is the smallest office with the second largest group of AutoCAD users. The link between NY-VB is fractional T-1, about the same performance characteristics as NY-DC.

The IT department utilizes Microsoft System Center Configuration Manager 2007 to deploy software, updates, collect inventory data, as well as uses it for provisioning new and refreshed computers. There are primary site servers in Chicago and Washington DC. Virginia Beach has a seconary site server. All four site servers are also distribution points.

The file, print, and Configuration Manager site servers in the remote offices are physical machines. The servers in NY are virtual.

Situation

All computers in the company run Windows 7 Enterprise Edition, Service Pack 1. All servers are running Windows Server 2008 or 2008 R2. The IT department has installed a FlexLM(R) license server in New York and obtained a valid license file from Autodesk. They have configured the license server and verified it is operating normally.

The IT department creates the first AutoCAD network deployment share on a server in the NY data center. They are aware of the deployment caveates for .NET Framework 4.0 and have already packaged the AutoCAD DirectX(R) component installer as an .MSI.

Using Configuration Manager (aka "SCCM"), they deploy .NET Framework 4.0 to all computers in the company successfully. They also deploy the DirectX(R) custom installer successfully. They then deploy a few test clients in the NY office using SCCM successfully. Everything so far looks good.

Within SCCM they assign additional distribution point servers for the AutoCAD deployment package, one for each remote office. They create the necessary collections and add direct memberships for clients in each remote office to a corresponding office-related collection and assign the advertisement.

The IT department runs server data backups over the WAN links to the NY data center for archival between midnight and 2AM ET (1AM Chicago time). Client computers are schedule to run disk defrag, and anti-virus scans between 2AM and 4AM local time. Tests show that the AutoCAD deployment takes roughly 40 minutes to install on a full T-1 connection, and 60 minutes on a fractional T-1 connection.

Few, if any, of the remote office clients successfully install. Most return an error that the package timed out.

Question 1: What Happened?

What might have caused the remote office clients to fail the installation attempt when the clients in the New York office completed the installation just fine? Was it...

The Package did not finish replicating to the remote office distribution point servers.
The network links might have been saturated with concurrent traffic during the deployment.
The replicated package files contained identical deployment .INI content, so the clients attempted to install from the New York server share.
Answers 1 and 2
Answers 2 and 3
All of the Above
None of the Above

The answer is (definitely) 3 but could also be 2, so the best answer is 5.

Question 2: How to Fix This:

When you run an installation from the network deployment share, the process refers to the DEPLOYMENT_LOCATION key in the .INI file. So, what's the best way to address this?

A. Open the deployment .INI on each SCCM package share and edit the DEPLOYMENT_LOCATION value to refer to the local share UNC path.

B. Build each deployment "on" a server in each remote office, then create a SCCM package and program that refers to the UNC as a distribution share.

C. Build each deployment "on" a server in each remote office, in a separate folder create a .bat or .cmd script that references the setup command for that server. Create a SCCM package and program that points to that script.

Best Answer? ____

FlexLM License Servers

After sorting out their deployment issues, all clients are working fine and obtaining licenses from the license server as expected. The IT department decides they want to add a little redundancy by implementing two more FlexLM(R) license servers in a Distributed configuration. They provision a license server in Chicago and another in Washington DC.

The clients were originally installed using a system environment variable to assign the FlexLM(R) server setting. Now they want to reconfigure the Chicago users to point to their own license server first, then the New York server, followed by the DC server. The DC users are to be configured so they point to their license server first, then New York, followed by Chicago. Lastly, the Virginia Beach users should point to DC, then NY, and then Chicago.

What's the Easiest way to accomplish this change?

A. Modify each deployment using the deployment utility "Modify Deployment" link, and enter new FlexLM server information, then re-deploy the installations to all clients for each site.

B. Create a SCCM package and program that executes a script to configure the system environment variable to suit each location. Target the clients using collections based on site assignment.

C. Create four Group Policy Objects with a Group Policy Preference setting to replace the system environment variable value, link the GPO to the Active Directory OU for each site.

Best Answer? _____

Slow Autodesk Network Deployments?

2011-09-27T20:00:00.001-04:00

One advantage of being a "consultant" is getting to peek into a variety of environments, cultures, methodologies, and whatnot. One thing I see fairly often that seems to warrant some mention is slow performance over network pathways. A cursory search on Google reveals that there are plenty of articles, blog posts and tweets regarding slow "deployment creation", it's tough to find anything really focusing on the execution side: deploying the installation from the share to the clients.

The potential points of trouble or failure in a typical LAN or WAN environment are numerous. From client hardware and software, to client configuration settings, to physical wiring, switches, hubs, routers, wireless equipment, wireless configuration settings, server hardware, server software, server configuration settings, scheduled backups, scheduled anti-virus scans, unpredicted end-user activity, power faults, wireless interference, and layer on top of all this the issues incurred in virtual data center environments. These are some of the aspects and any one of which (or combination of several) that can cause performance drag or outright failure. The more you dig into the world of network engineering, the more you can appreciate what a network engineer deals with.

So, if you're Autodesk product network deployments are taking longer than they should to deploy, here are some things to look at:

Network Site Link Speeds

If your employer is large enough to have a dedicated "network admin", consult him/her for link speeds between points of deployment (server shares) and end users (desktop and laptop computers). Find out how many hops are involved. What the switches and routers are like. What limitations they're aware of. I recommend doing this BEFORE you even attempt to build network deployment shares (referenced in my book. shameless plug, I know) Basically, you always want to keep as little time, distance and latency as possible between the installation source and the installation target. This is irrespective of doing it manually, via scripts, group policy or management products like Configuration Manager.

NIC Configuration Settings

Verify the Network Adapter configuration settings with your network administrator. I've seen plenty of situations where everyone assumed it was automatically set to the correct configuration, when it was anything but. Sometimes atypical network equipment configurations require atypical client configurations to suit. Even if you are absolutely, positively convinced that all of your clients are using identical and correct network settings, check them again, just to be sure.

Concurrent Utilitization: Server

If your deployment share resides on a file server, or a print server, or an application server (web, database, etc.), I would STRONGLY recommend you consult your server administrators to setup some performance monitoring to measure and verify the loads placed on each server. If one role or function is hogging the resources (CPU time, memory, disk I/O, NIC throughput, etc.) consider moving it to another server.

If concurrent roles or functions are not an issue, check to see when system and file backups are scheduled to run. Do your best to avoid scheduling your network deployments during system backups, anti-virus scans, or scheduled maintenance. If your servers are virtualized, and your server admins ocassionally move them from one physical host to another (or SAN storage attachments, etc.) it's important to coordinate your activities to avoid problems.

Talk to your department coordinators or "power users" also. Make sure they don't have any tasks they run during certain hours to back-up their project files, or perform operations that directly tax the server or its resources. Copying a ton of large files can greatly impact network performance if the server is not configured to address that usage ahead of time.

Always always always check the event logs for any sign of potential issues.

Concurrent Utilitization: Network

If the server is not being taxed, you should take a careful look at what's going over the network segments. Between the clients and the switch or gateway. Between the switch or gateway and other routers, and between the other routers back to the servers. There are lots of ways to do this and it's important to consult and coordinate with your network admins to do this effectively. In many cases they can help identify bottlenecks caused by two major traffic activities that can be separated to avoid conflict.

Client Integrity

Check for available/free disk space on the target hard drive volume. Check for errors and warnings in the client event logs. Is the client getting frequent anti-virus quarantine events? Are installed applications causing problems? Be careful of applications that want to continue running in the background, especially when the client is tight on physical memory. If the computer is being used heavily, consider upgrading the hardware or installing a separate physical hard drive to isolate I/O tasking. The list here goes on and on, of course.

Client Activity

Are users performing CPU or disk-intensive activities? Rendering large models, video processing, audio editing, etc.

More

Oh yes. There's more. MUCH more. I haven't (and won't) go into the impacts of other key networking services like DNS, Kerberos, WINS, DHCP, encryption overhead, certificates, dual network interfaces, teaming, virtual switches, virtual NICs, or any of that stuff. It's more than I feel up to blabbering about, but it's out there, waiting for your brain to absorb it all.

And Finally...

Before you jump into building your network deployment, especially if you're aiming for multiple servers across a WAN, it's important to gather as much information as possible about your network so you can plan your strategy correctly. If you spent hours convincing your coworkers, management and customers/users that network deployments are the "way to go", don't you want to make sure it works as great as it possibly can?

Consult your network and server administrators. Run tests to verify file copy speeds across all links you plan on using. Run your tests over a month or at least a few weeks, at all times of day, all days of the week. Record details of performance and identify patterns in best and worst results. Pointing a finger at one of your network admins and blaming them for slow speeds is only going to piss them off and get you moved to the bottom of their list of things to take care of. Having measurement data and engaging in a cooperative discussion will get you where you want to go with the least amount of pain and effort. Be sure to bring donuts and tell lots of jokes too. It never hurts.

Tools and Links

WindowsNetworking.com - Troubleshooting Network Issues

Advanced Network Adapter Troubleshooting for Windows Workstations

WireShark (the de facto diagnostic tool)

Network Monitor 3.4 for Windows 7, Vista, Server 2003, 2008, 2008 R2

Sysinternals Networking Utilities

Sysinternals Process Utilities

Books by Mark Minasi at Amazon

Network Diagnostics and Tracing in Windows 7

NETSH commands for Windows 7 and Windows Server 2008 R2

Querying Services on Remote Computers

2011-09-27T18:10:00.001-04:00

I'm still amazed that so many up-and-coming admins and SE's knee-jerk to using a script to perform a task that is readily available from a command prompt. In this case, the SC command. The SC.exe command resides in the %WINDIR%\System32 folder on most Windows XP, Vista and Windows 7 systems (as well as Windows Server 2003, 2008 and 2008 R2). It's also alive an well on Windows 8 (Dev Preview build, anyway), and I presume resting within Windows Server 8 as well (I haven't seen it yet).

The syntax is rather basic:

sc <server> <option> <parameters>

but most people use it for querying the local services state, as follows:

sc query

The flexibility comes with the "<server>" argument, which is the NetBIOS computer name (with preceeding \\), so to query a remote computer named DESKTOP1 over your network...

sc \\DESKTOP1 query

And just add a piped "| more" to pause screen-by-screen (or redirect into a file, etc.)

One short and simple command, instead of a bunch of VBScript or even a lengthy Powershell cmdlet. Nothing wrong with those options, but it's nice to know there are other alternatives.

Remember: To break open this little nugget, open a CMD console and type "sc /?", press Enter and enjoy!

Test ADO Connection using VBscript

2011-09-27T16:31:00.001-04:00

Quick ADO connection test using VBscript...

[code]

Const dsn = "{your connection string or DSN name here}"

On Error Resume Next
Set conn = CreateObject("ADODB.Connection")
conn.ConnectionTimeOut = 10 ' 10 second wait limit
conn.Open dsn

If err.Number = 0 Then
	wscript.echo "CONNECTION: SUCCESS"
Else
	wscript.echo "CONNECTION: FAILED"
End If

conn.Close
Set conn = Nothing
[/code]

10 Ways to Manage Windows Services

2011-09-27T07:26:00.000-04:00

Services Console (services.msc)
Command Line: sc.exe
WMI / COM Script: VBscript, KiXtart, Javascript, Perl, etc.
.NET Script: PowerShell
WMI Class Provider: Win32_Service
Group Policy Object
Group Policy Preferences
Utilities: PSService.exe (Sysinternals/Microsoft)
.MSI installer
.EXE application or installer

5 Ways to Read Windows Event Logs

2011-09-27T06:21:00.000-04:00

Event Viewer application (eventvwr.msc or eventvwr.exe)
Command Line: wevutil.exe
WMI/COM Scripting: VBscript, KiXtart, Javascript, Perl, etc.
.NET Scripting: PowerShell
Collectors and Forwarders: wecutil.exe

Automation Gyration

2011-09-26T20:45:00.001-04:00

I recently updated some information on my tabular matrix of "Windows 7 Automation Options" over at my other other other web site. The goal of this matrix is to map out alternative ways to perform common administrative tasks and compare which is best for certain conditions or situations. Let me know if you want something added or if you have a correction to offer.

11 Ways to Manipulate the Windows Registry

2011-09-26T20:35:00.001-04:00

Direct via REGEDIT
Command line using REG.exe
Import via .REG file (invokes REGEDIT)
COM Scripting: VBscript, KiXtart, Perl, Javascript, etc.
.NET Scripting: PowerShell
Group Policy
Group Policy Preferences
.MSI installer
.EXE application
Stream Interface: Java
Temp Labor: Order Timmy to do it

Acad 2012 DirectX - The Final Chapter

2011-09-25T19:29:00.001-04:00

I know that I said I was done with this topic, but someone hit me up over the weekend with a desperate request for help and I couldn't say no. As always, I prefer to share answers on the blog rather than by e-mail because it [A] helps more people at one time and [B] avoids repeating the same answer over and over. This might go a bit deep, but hopefully it serves to help someone out there to get over this hump with a little less effort.

The Better Way

If you have InstallShield, here's how to do this in the simplest and most effective way:

On a clean reference computer (virtual machine) install the Remote Repackager
Start the Repackage Wizard and select "Snapshot" mode, using multiple steps
When the capture is done, click Finish
Copy the "DirectX" folder from the "3rd Party" sub-folder of your AutoCAD 2012 network deployment into the C:\Windows\Temp folder of the reference computer (making C:\Windows\Temp\DirectX)
Open the folder and launch DXSETUP.exe and complete the process to "finish"
Re-run the Repackage Wizard in snapshot mode to capture the delta state info
Save the output to C:\Packages on the reference computer
Copy the output up to your InstallShield developer share so you can edit it further

When you open it in Repackager, exclude all the junk that relates to "per-user" stores (HKCU, User Profile, etc.) and exclude anything not related to your DirectX installation (background scans, scheduler services, etc.) Save the output to a new folder (e.g. "Project")

Open the .ism output from the "Project" folder in InstallShield Editor.

Set all the desired properties (title, subject, comment, etc.), there's a lot of stuff to manipulate, so unless you need all the nitty-gritty details I'll skip over them for now.

Build the project into an .MSI package

Run the MSI Validation and clean up any ICE references that matter (ignore ICE27, for example - but don't ignore ICE18, and so on). Build again, and repeat the Validation until all is good.

You should now have a .MSI installer

TESTING

Once you have your shiney new .MSI installer, test test TEST TEST TEST TEST it until you feel good it's working like it should. By TEST I mean install it on a new computer, along with .NET 4.0, and then target that computer with the AutoCAD 2012 network deployment using Configuration Manager 2007 or Altiris, etc. If it works fine and the application launches without errors, you're good. DO NOT - I REPEAT - DO NOT look at the Configuration Manager advertisement report for the "Success" and call it a "win". That's NOT good enough.

DANGER ZONE

This is where we separate the men from the boys (or more apropos: we separate the daring idiots from those that prefer to keep their job).

WARNING: The rest of this article is UNSUPPORTED and potentially RISKY. Always make a backup of your entire AutoCAD network deployment share before making any manual changes. This information is NOT supported or condoned by Autodesk, its resellers or anyone on this planet. I do not guarantee this will work for you and there is NO WARRANTY provided, either explicitly or implicitly, for any purpose or use whatsoever. I accept NO LIABILITY or responsibility for any consequences that may arise from your use or adaptation of this information for any purposes. In short: YOU ARE ON YOUR OWN - YOU ACCEPT ANY AND ALL RISK from this point on. Results may vary. Batteries not included.

Place the new Acad2012DX.msi file in a folder under your AutoCAD 2012 network deployment share. You can drop it in the "DirectX" folder actually.

Open the deployment .INI file and locate the [DIRECTX] key. It should look something like the example shown below.

[DIRECTX]
PLATFORM=ALL
PRODUCT_NAME=DirectX Runtime
EXE_PATH=3rdParty\DirectX\DXSETUP.exe
EXE_PARAM=/silent
IGNORE_FAILURE=YES
DISKCOST=50000000

Change the values beneath it to suit the new .MSI installer, as shown in the following EXAMPLE...

[DIRECTX]
PLATFORM=ALL
PRODUCT_NAME=DirectX Runtime
EXE_PATH=3rdParty\Directx\Acad2012DX.msi
EXE_PARAM=/quiet /norestart
LOG=%tmp%\Acad2012DX.log
IGNORE_FAILURE=YES

Save the file and test a deployment on a computer that has .NET 4.0 but has not had AutoCAD 2012 installed prior to your testing.

NOTES

I have not provided any guidance for getting .NET 4.0 to install with the AutoCAD deployment bundle (via a Configuration Manager 2007 unattended deployment), because I feel it's bad to try to do it that way. I recommend deploying .NET 4.0 as a separate package/advertisement, in advance of deploying AutoCAD 2012. The only reason I bother with DirectX like this is because it's a custom DirectX installation (from Autodesk, not me), so it fits more logically with the AutoCAD deployment, than as some sort of general Windows platform update. Basically, you would never deploy this without AutoCAD 2012, while .NET 4.0 on the other hand would be.

I hope this wraps this boring, ugly, depressing saga up with no hanging threads.

Drop a comment (reply) here if you have any helpful advice for making this work better/faster/easier than I've described. We'd love to hear it. I'd love to put the final nail in this coffin and move along actually.

10 Easy Ways to Screw Up a Good Computer

2011-09-25T14:37:00.001-04:00

Install too much crap on it
Don't install a decent anti-virus product
Never defragment the hard drive
Never install updates and service packs
Don't vacuum out the dust and dirt
Let a lot of other people use your computer
Never clean out the various "temp" garbage files
Never reload it from what Dell/HP/BestBuy, etc. install on it
Install one of those computer "fix-up" products advertised on TV
Never seek education on how to use it more effectively