5 Stupid IT Questions - Part 2 - The Electric Boogaloo

It's that time again.  Enjoy...

Question 1 - "I have about 50 to 60 desktops and laptops, and about 10 servers in my AD environment at work.  I don't have a patch management product yet, I currently patch my Windows machines manually or using scripts.  Is there a good reason *not* to use WSUS?"

Answer:  First off, you need to start drinking. Your doctor would agree with me.  I think.  Well, anyhow, if your environment is built on versions of Windows which can be supported by WSUS, then the answer is NO: there isn't a "good" reason to *not* use a free product that at least gets you closer to the goal line.  How's that for a double-double-double negative statement?  I should've been a politician.

Are there better products?  Sure.  For free?  Maybe.  Is WSUS "good enough" for most shops like yours?  Probably.

Question 2 - "My significant-other spends a lot of time reading, studying, and playing in a lab to stay current with his/her career.  Is there anything I can do for him/her?"

Answer: Yes!  Feed them.  Scratch their back.  Rub their feet. Make them laugh.  And most important, feed them some more. They need to be sure to return the favor though.  My wife is amazing, but I have to remember to rub her feet too (she deserves it).

Question 3 - "I have scheduled tasks running on computers which run under the local SYSTEM account, but when they try to execute commands or access resources from remote UNC shares, they are denied access.  What am I doing wrong?"

Answer:  Two things... the first problem is that you're not sending me cash to help me pay my bills.  Just kidding.  Second, you didn't grant sufficient permissions to the share and/or the underlying NTFS folder path.  Remember, the local SYSTEM account runs as a proxy for the computer itself (when operating in a domain context).  So, when it knocks on the door of a remote shared resource, that resource sees the domain computer account in the peep hole.  (you thought I was going to say glory hole, didn't you?  sick puppy you are).

For example, if one computer is "DT1234" and is running a task that requests a connection to server "FS0005", then that server will see "DT1234$" (they append the dollar sign to indicate you paid a lot of money for that license.  ha ha . kidding again).  Actually, if the domain is "constoso.com", then the server sees user "CONTOSO\DT1234$" (NetBIOS name + computer sAMAccountName) knocking at the door.

By default, domain-joined computer accounts are not members of the AD domain "everyone" or "domain users" security groups.  They're not even members of any group (by default) besides "Domain Computers".  Therefore, you need to grant rights on resources to that domain security group, and your domain-joined computers should be able to knock at the door and get some free food.

TIP: a simple way to test local SYSTEM access to remote shares, is to use the "psexec.exe" utility (Microsoft/Sysinternals) with the "/s" option to launch CMD.exe.  Then within the command console, running in the local SYSTEM context, try to connect or query remote resources to see what happens.

Question 4 - "I'm building a custom app/script that helps manage things within System Center Configuration Manager 2012 R2.  It needs to read and write information as well, but it looks like I can do that by ADO and SQL commands, or by WMI and WBEM commands. Which should I use?"

Answer:  (long, long inhale.... get ready, here it comes...)  Okay.  Both.  No, wait.  Neither.  No, wait, that's wrong.  Both.  Sort of.  Hold on.  This may seem a little complicated. And even if it wasn't complicated, I'm a professional, and complicating things is what I get paid to do.  That's not true either.  Just a minute. Okay. So drink up, strap in, or strap on, or buckle up, whatever...

You know how they say "never say never"?  Well, NEVER, yes, that's right, I just said "NEVER", ever write to a System Center Configuration Manager database directly.  All "write" (aka update/insert/delete) operations should be done through WMI/WBEM statements. I'll get to the "why" in a minute.

First things first:  While you absolutely can request information from the database using WMI/WBEM queries, I recommend that you do your read operations directly from the SQL Server database, rather than via WMI/WBEM.  The reason is that they're going to perform faster than WMI/WBEM requests (assuming you know how to form proper T-SQL statements).  More importantly: WMI/WBEM query statements are way more limited than T-SQL as far as what kinds of operations you can perform.  For example COALESCE, TRY_CONVERT and CASE statements, to name a few. And I won't even get into things like DATEDIFF, CAST or SUBSTRING.

Next, the reason you shouldn't push anything into the database directly is that SCCM relies on a delicate, complicated and, let's be honest, confusing-as-hell sequential process for handling change requests.  That is, updates, additions, deletions, and so on.  Each request is queued, prioritized, processed and logged.  The "processed" part involves even more sequential handling with triggers and more logging, and if you go around back, break open the window and climb in the back room, the alarm will go off and the SWAT team will repel down from helicopters and kill you.  Okay, not really.  But it will very likely break your SCCM site entirely.

When you submit requests properly using WMI/WBEM requests, they are like well-trained school kids lining up to go to the cafeteria.  They get their lunches, sit down, eat and smile the whole time.  When you shove them in directly via ADO/ADO.NET, shit will just break. Trust me. If you don't trust me, go ahead and setup a lab environment and kick those tires.  When the air blows out, don't come crying to me.

Finally, or thirdly? -  if you plan on making the same types of requests for information (read operations, that is) and they involve SQL "JOIN" statements, I recommend you create some VIEWs and apply indexing.  SQL will outperform application processing like Stephen Colbert having a debate with your dead cat.  If you've been strapping together messy "SELECT blah FROM whatever LEFT OUTER JOIN something  ON this = that..." and so on, in your script code, STOP!  Do that within the database (or create another database on the same server to pull data for abstraction and aggregation work, etc.).  So, to summarize all that blabber...

READ == Direct from the Database (SQL + ADO or ADO.NET)
WRITE ==  Through the WMI/WBEM interface

If you're thinking which is "faster": COM scripting or .NET scripting (e.g. VBScript vs. PowerShell), it depends on what you're doing, but for most things it's break-even.  The biggest factor will be where the bulk of logic handling and processing is being done:  in the database/WMI request itself, or on the information obtained therefrom.  I can already sense the .NET nerds flipping out right now. Spitting coffee through their nostrils.  Exclaiming "WTF?!!", knocking over their stacks of stale donuts and breaking pencils.   Oh well.

Question 5 - "My company is looking for a good service request ticketing system product. What products would you recommend?"

Answer: None of them.  Or all of them. The problem is that every organization that's existed for more than a few years, has evolved their own internal processes for handling requests.  Staffing varies.  Methods vary.  Resources vary.  The retail products you will try on will almost certainly be like a "one-size fits-all" suit.  Lot's of Velcro straps and adjuster things to help you pull in the tight spots to fit better.  But it's going to feel like that too.

Most off-the-shelf products will expect you to make some concessions with regards to "how" you do things.  That's not always bad, though.  Read up on ITIL, and even if you hate ITIL, it's good to have something to base your processes upon.  That or a suitcase full of drugs and a fast getaway car.  I have no idea what that's about though.

If your environment has implemented ITIL with gold medal effort, you may do really well with almost any off-the-shelf product.  However, I haven't seen an ITIL gold-medal shop in my lifetime.  I've heard stories of them, but I've never seen one.  Kind of like unicorns and leprechauns.

I see two options:  Build your own with whatever tools you have, or buy one and suck it up.  Just be warned:  The bigger your organization (staff and customer numbers), the more work it's going to be, for either direction you choose.  Be cautious of vendors offering "customization" services too.  That's their bread-and-butter.  Am I a bit pessimistic?  Yes.  It's a lot like shopping for document management solutions, or vacation homes.  I wish I could afford a vacation home.  Heck, I wish I could afford to take a vacation.


Th-th-that's all for now, folks.  Have a good week!

It's Time for 5 Stupid IT Questions

You got IT questions? I got stupid answers.  Pull up a chair, sit down, and destroy your precious little mind reading my stupid ramblings for a bit.  What else do you have to do?  Silly Earthling.

(Note:  This is going to be an ongoing series, I think.  It depends on feedback from folks like you)

Question 1 - "In VMware Workstation and VMware Player, it has an option to preallocate the virtual hard drives.  What does this do and why should I consider it?"

Answer: It carves out physical storage space (on whatever drive/disk/volume you have it pointed at) to store the disk .VMDK file before using it the first time.  Like most things in life, there's a trade-off...

On the good side, preallocating space avoids the need to incrementally allocate more space as needed.  The incremental growth usually happens while the VM guest is running, causing some delays and pauses at times.

On the bad side, preallocating space takes up designated storage space which may not be fully-used on the inside (guest VM referencing).  For example, if you specify a 60 GB disk, it will grab 60 (plus a little chump-change space for overhead) right away.  In the end, you may only end up filling 40 GB within the guest machine, leaving 20 (or thereabouts) unused but still occupied on the physical disk.

If space isn't a concern, preallocate it to squeeze a little more performance from your virtual toyland.

Question 2 - "If I want to roll out a new Group Policy ADMX template during production hours, what negative impact would that have?"

Answer: "Would" or "Could"?  The answer depends on several factors.  But starting at step 1:  deploying an ADMX template into an AD environment involves updating the SYSVOL on the first domain controller.  From there it replicates (because domain controllers like to replicate, as nasty as that sounds).

The factors that come into play after step 1 are like a Rubik's cube.  Site link configurations, replication schedules, the size of the ADMX files, the WAN links, the network configuration, the KCC mess in the background, the amount of drugs your engineers consume, the prevailing winds, the high tide, the... whatever.  Hopefully you get the idea.  I would recommend that (after you've tested them in a separate environment of course) that you deploy them during off-peak hours.  If that isn't possible, blame it on the last person to have quit.

Question 3 - "Will shifting my SCCM environment over to a user-demand, Application Catalog scheme fix all my problems with overseeing software deployments?"

Answer:  It depends.  In general, the answer is "no", it won't fix "all" of those "problems".  Can it lessen your workload?  At best: usually.  At worst:  it will replace one set of problems with another.

Will it eliminate some problems on the whole?  Sometimes.

It depends on how diverse your applications are and how diverse the target platforms are in your SCCM site.  If you support 4,000 products, but they are well-defined in terms of assigning one product+version for each business role, then you will be better off.  If you have a lot of alternatives for the same role/purpose, start drinking and get your Liver in good shape.

The surprise "gotchas" I've seen, or heard about, with handing over the role of installing applications to end users via a catalog shopping-cart concept, have been basically from two general areas.  Each of which breaks down into two more areas:

1. Setting up the catalog
2. Cleaning up messes

The first area (setting up the catalog), involves not only building the catalog, but assigning roles and permissions, but that's the easy part.  Then comes the spaghetti-like enigma of validating product licensing and usage terms, as well as planning out the potential conflicts.  Those are the nasty things like "Product A and Product B cannot exist on the same client or they break things." or "Product A only works with .NET 4.0 while Product B only works with .NET 4.5" and so on.

The second area (cleaning up messes) involves hand-holding users that mistakenly install things and run into problems with them.  Even if you teach them how to remove those mistakes, there are going to be the breaks that require rolling up your sleeves and taking time away from other work.

The secondary issues are delegation reliability, and platform resiliency.  Big words.  I like big words.

The former (delegation) involves how well your delegated staff hold up with handling rights and assignments, as well as tech support issues that arise.  The latter (resiliency) involves how mature your environment is with regards to platform standards and methods for repairing breaks in the assembly line.  How many versions of Windows you support, how many device types, models, vendors, component versions (JRE, .NET).  Good stuff for beer talk.

Question 4 - "Is it more important to have a college degree or a certification when entering the IT field?"

Answer:  My kids' friends and their friends hit me with this question a lot.  Usually after some introductory phrase like "Excuse me, old man?  Can I axe yuze a question about getting a computer job?".

From an entry perspective (first-time job seeker), it depends on what kind of IT job you're aiming for.  If you're looking for a fairly low to intermediate job, such as anything from Tier1/desktop support, to even Systems Admin or Systems Engineer, it helps to have a degree, but it really helps to have a lot of (current/recent/relevant) certifications.

Many entry level IT jobs only require A+, Network+ and Security+ certifications, unless you start getting into VMware or Cisco type stuff (and so on).  Even then, having a Microsoft MCSA/MCSE will help a lot.

If the job your aiming for is "senior research scientist" or "database architect", well, start filling out those college enrollment applications.  It won't hurt to have your CCNA or MCSE/MCwhatever, but most high-level, expert type fields within IT expect more educational background.  And don't forget those Analysts and Project Managers, who may need a mix of schooling and certs like PMP, ITIL, etc.  Just poke around the job postings online and you'll see what I mean. (Not that I've been looking of course, cough-cough.  That's just what I've been told).

Question 5 - "What is the toughest part of getting technology to work well?"

Answer:   People.  It's just human nature to try to pound nails using a wrench.

(Thank you for reading!  Stay tuned for more IT stupidity coming soon...)

Asset Inventory 101 - Myths and Realities

This post is the result of trying to explain IT inventory to multiple people, multiple times, and them still not "getting it".  Rather than wear myself out, which I will probably still do anyway, I plan on pointing them here to read my thoughts on it, and I can then go back to babbling incoherently to myself.  I promised to post a "tech-oriented" article soon, but this is borderline, so nanny-nanny-boo-boo, I'm counting it as tech-oriented.

If you ask me about Inventory, I will ask if you read this article.  If you say "no", I will tell you to read this article and walk away, probably while laughing.  If you say "yes", I will say "go back and read it again", and laugh even louder.

What is Inventory?

Definition...

(noun):  A complete list of the things in a place".

(verb):  the act or process of making a complete list of the things that are in a place : the act or process of making an inventory". - Merriam-Webster's Dictionary

Go back and read that again.  Got it memorized? Okay, let's look at the noun side...

Inventory Science 101

What is "inventory" really?  Basically, it's supposed to be about tracking and reporting what you own, or what you have, and where it's located.  But there's usually a lot more to it than that.  Who's using it.  What it's used for.  Who bought it.  Who pays for it.  How it is configured.  What it's related to, or associated with.

There's also the Manufacturer. Model. Part Number.  Serial Number.  Contract number(s). Department/Division/Sector/Group/Team/Project names and numbers. And let's not forget the abstracts like category, type, family, class, species, and all that.

The goal of inventory, and inventory tracking efforts is, or should be, to confirm existence, disposition and ownership of assets.  The real goal being a financial implication of course.  What do you own?  Where is it?  Who is using it?  What is it used for?  Who's paying for it?  When does it "expire"?

The most common method for gathering and tracking inventory is what is commonly referred to as "input-output differential".  Capture what comes in (purchase order, or birth certificate), what goes out (inventory record audit, or death certificate) and finding the gaps.  The gaps are where the fun really begins.

What happened to it?  Lost? Stolen?  Transgender operation?  Was it really the property of the organization, or was it loaned to them for temporary use?  Was it a demo from a vendor?  The list goes on and on.

Just as a Census tries to verify you're still among the living, breathing creatures, who are paying taxes and adding to landfills... so are the aims of products like Microsoft System Center Configuration Manager, Solarwinds, Tivoli, Kaseya, LabTech, and (cough-cough) several products I've developed in the past as well.

So, in addition to what came in the door, and what is known to have departed, there is now a third status of "what's it doing now?"  Things that can be poked at to verify where and what an asset is, include Active Directory, network monitoring systems, PING, and so on.  An "Asset Manager" job title can often involve a lot of legwork.

What Constitutes "Things" and "Places"?

If we use YOU as a metaphor, then a human being is an inventory asset or item.  The place would be (or could be), your home address.  It could also be your employer's address, or your car (VIN or license plate).

Now, think of all the "things" that pertain to labeling YOU as an entity.  Your birth certificate.  Driver's license.  Voter registration.  Tax bills.  Credit cards.  Bank accounts.  On and on.

Do any of those things GUARANTEE your existence?  No.  Do they confirm you are still among the "living" (I'll leave that for you to decide on the definition)?  No.  They are simply artifacts that help SUPPORT the assertion that you exist.

Metaphorically Speaking:  Computers

Now that we've strolled off into metaphor-land, let's bring it back to the meat-and-potatoes: Computer assets.  Desktops, laptops, tablets, smartphones, appliances, routers, hubs, switches, printers, power supplies, storage units, MODEM's, peripherals of all kinds, you name it.

What is the birth date of a computer?  The date it was purchased?  The vendor warranty start date?  The OS installation date?  The technician-installation date?  If you base it on the OS install date, and you reinstall the operating system, what happens to the birth date then?  Does it fall back to something else?

If you purchase it, and it takes a while to get from the warehouse, to the workbench, to the truck, to the technician to being delivered and setup, which event date are you picking as the "start" or "birth" date of that asset?  Have you consulted your Finance folks about this?  Your attorneys?  You should.

When you record the purchase and deployment of this asset, what then?  Do you track it during the rest of its life?  Do you track the retirement and disposal of it too?  Some places do.  Some don't.  Some are required by law to track some, or all of this.  Which are you required to track?

Just because you "Can", does that mean you "Should"?

If you are an IT person working for someone else (i.e. not self-employed), and you haven't sat down (or consulted with) someone in a legal and/or financial role in your organization, I strongly recommend you do so before embarking on any effort to track and report inventory of any kind.  I cannot stress that enough.

Even if you are self-employed, talk to an accountant or legal advisor about whether you need to track thigns, and what to track.

Some questions to ask:

• What are the tax implications?  
• What are the support contract and cost implications?  
• What are the regulatory compliance implications?  
• What are the IT support implications?  

Did you notice I put IT last in the list?

From my experiences, most businesses track more than they need to, and ignore things they shouldn't ignore as well.

Ah, Yes:  Software

Just when the folks feel good about their grasp of tangible hardware inventory, we open the gates and let the starving lions and alligators into the arena:  software licensing.

Definition:  Software = "the programs that run on a computer and perform certain functions" - Merriam-Webster's Dictionary

What does that mean?  What is a program?  Is that Microsoft Word?  Is that the Snipping Tool or Narrator feature?  Is that .NET Framework 4.5?  Is that Java Runtime?  Is that a DLL or COM file?  Is it a locally stored App-V or ThinApp reference?  Is that a shortcut to a MED-V or remote VDI resource (desktop or application)?  Is that a URL to a web application?  What is it?

What does that mean?

If you query a computer for what software it has installed, where do you begin?  Does it all exist in the Control "Add or Remove Programs" list?  Usually.  But not always.  How about crawling through that icky Registry?  More stuff, sure, but is it easy to parse and understand?  Hmm.  How about crawling the good old file system and parsing through EVERY SINGLE FILE that is known to have an executable capability?

The answer is yes.

Configuration Manager, and products similar to it, often dissect a computer from many angles.

This includes files, folders, the Registry, and my personal favorite: WMI.  Slithering through the various CIM repository stacks can yield all sorts of juicy bits of data about hardware and software.

But... Is this really what you're after?

So you have a product installed.  Now what?  Does that constitute a 'license'?  What is a license?  What kind of license is it?  Per-machine?  Per-user?  Per-CPU?  Per-network?  Per-domain or site?  Per-company?  Open Source?  What?  And what about FlexLM type licensing, where the node doesn't matter as much as the total, concurrent usage limit?

If you have the option to use floating/network licensing for groups of similar products, I always recommend that option if you can afford it.

Software Licensing Audits

If you've ever witnessed a license audit from an external investigation, it's not fun.  They tend to come in one of two flavors:  Vendor and BSA.  If the vendor audits you, that's good.  They want to keep your business, so they will try to negotiate terms to help avoid losing your business, if possible.  If the BSA, or another third-party entity, comes knocking, swallow whatever pills you have left and take a deep breath.  It may very well be an unpleasant experience, as they are paid by levied penalties and have no need to retain your business.

So, while you can get sloppy about hardware inventory, I would not recommend you take the same light-hearted approach to software inventory.  I've seen "settlements" applied that nearly ended a business due to the costs, but thankfully, in none of those situations was I aware or implicated of the neglect prior to the doors getting kicked down.  Don't be one of those businesses.

Okay, so that covers a bit of hardware and software.

Simple as multivariate Calculus and molecular bonding, and clear as mud.

Are you starting to drink yet?  You will.

Summary

If anyone says there is, or should be, "one inventory source" to answer all of these questions, they are brain damaged or stupid.  The desire is noble.  The reality is clear: a singular source of "authoritative" inventory data is impossible.  It has to be derived and reconciled from multiple angles.

Think about that every time you're walking through CostCo, Sam's Club or BJ's and you see a clerk scanning shelves to do "spot check inventory".  If there was one system to track and verify all of it, that wouldn't be required.

Every time I sit in a meeting where some vendor comes in to pitch some magical product to report all of their inventory without any outside help, I look at my shoes, smile and think about my next alcoholic beverage, saying to myself "here we go again..."

Experts Guide to Home and Small Business Wi-Fi

Thinking of buying a shiny, new, extra-double-spiffy new Wi-Fi router at Costco, Sam's Club or Best Buy?  Maybe online?  But maybe you're not really comfortable setting it up yourself?  NO problem.  I'm from IT and I'm here to help.

1. Before you buy a new Wi-Fi router, be sure to try the standard IMNDSICUT process.  That's short for "If my neighbor doesn't secure it, I can use it".  It goes like this:
1. Turn on your mobile device (laptop, tablet, smartphone, etc.)
2. Click the link to search for active Wi-Fi networks.
3. Look for the ones that do NOT have padlock symbol.
4. Try connecting to each one until you get one that works.
5. (tip: Be sure to check for any applicable local, state and/or federal laws that might cause you some concern before doing this.  If you get in trouble, you read this on someone else's blog and my name is Bob)
2. Next, if the above process doesn't pan out and you're a small business, rent space near a Starbucks, McDonald's, or any other retail or fast food chain outlet that offers free wi-fi.
3. Next, if that doesn't pan out, run an ad on Craig's List for a room mate that is good at setting up Wi-Fi networks and also (this is important, pay attention) has a new wi-fi router.
4. If all of the above options fail, you need to buy a new router.

You're all set!  Good luck - and happy wi-fi-ing!

:)

The Blurry World between IT Infrastructure and App Dev

For decades (that sounds really depressing at my age, just saying), the field of Information Technology has been somewhat divided between a world of servers, networks, storage, virtualization, load balancers, firewalls, certificate services, agents and deduplication stuff, and... aaaaaannnndddd, another world of coding, compiling, source control, protocols, algorythms, user-interface design, web standards, mobile apps and lot's and lot's and looooooottttt's of sugary caffeinated stuff with too little sleep.

In simpler terms:  It's been a division between those that build the roadways, and those that build the contraptions that traverse them.

Out of this soup of techno-stuff comes things like Facebook, Google, Angry Birds, Netflix, Windows, iOS, Grooveshark, Twitter, Instagram, AutoCAD, 3DS Max, LinkedIn, World of Warcraft, VPN access to your office, home security cameras that you can watch from your smartphone, XBox and PS4, and, well, whatever it is you're reading this useless crap on.

Stick with me, there's a point to be made, eventually, trust me...

Both sides of this divide have their own logical infrastructure (pardon the pun), from conferences to certification credentials, to college degrees, and user groups and so on.

But more often, "engineers" are stuck between these two worlds.  Remember that old Twilite Zone episode (or was it The Outer Limits?) where the futuristic solder is caught in a spot where half of his body is in a war zone from the 1800's while the other half is being shot at in a war zone from the 2100's?  Okay, I told you I'm pretty old, so just pretend you remember that one. I've found myself in that situation more times than not, between 1996 and today.

These should be familiar job descriptions / titles to you:

• Server Admin
• Backups and Storage
• Network Engineer
• Firewall Services Engineer
• Web Developer
• Software Developer
• Mobile App Developer
• Scripter

But, do any of these sound familiar?

• Software Packaging
• Software Repackaging and/or Sequencing
• Application Virtualization
• Horizontal Services Integrator
• Data Mining and Aggregation (kind of hinges off Horizontal Services)
• Desktop Deployment Specialist (think MDT/WDS/ADK/OSD, etc.)
• Patching Automation
• Web Applications Layering over Server Infrastructure Operations
• Inventory Control

Sure, you can pick these apart and point at certs that address those pieces, but the sum of each bullet (e.g. Inventory Control) doesn't fall so neatly into a single book, classroom or online course, or even a user group.

As a side note, one role that has always made my head tilt sideways is Group Policy modeling.  If ever there were a job that involves everything EXCEPT what the people who almost always perform it are comfortable doing, it's that one.  Logical analysis of software services, layering, Boolean operations, context filtering, decision trees, and "what if" analysis.  Standing at the doorstep of programming, holding a cardboard rose in hand, waiting for the door to open and there's a hot MCSE date ready to go.  Talk about juxtaposed worlds.

Another "for instance", and this is one I'm really familiar with:  Repackaging software.  Desperately trying to shoehorn some poorly-written crap into an environment, using tools like AdminStudio or App-V or ThinApp.  Then wrapping that into Configuration Manager deployments, or deploying into VDI environments.  That bizarre world of making it possible for two application bundles to coexist on a single host without killing each other, or killing other things, through the use of painful customization contortions.  Usually done in the name of making a customer happy, and avoiding the cost of a license upgrade (you know, the new version that was actually MADE to work on the OS version they're trying to make the unsupported version work on).

The point (I told you there was one somewhere in here) is that delving into these murky waters is becoming more and more commonplace.  Particularly where the intersection of custom applications and distribution and management procedures occur.  Once it was Batch, VBscript, KiXtart, Perl and whatnot, now it's PowerShell, and .NET services, and databases, and web services and XML, blah blah.

This "shift" isn't some prediction, it's already begun.  Look at the ways many server admins and engineers are working with scripts across various vertical services stacks. Anytime you are handed tools that allow you to bend and shape the out-of-box toolset to do things which the base product simply cannot do alone, you are stepping into that world.  

How do you put a certification track on that?  How do you quantify the value or potential of that?  How do you quantify the level of expertise in that?   You don't.  You can't.  Because it rolls back around to human interaction and knowing what your colleagues do, and can do, with those tools.  You can try.  Even if you concoct some elaborate exam test to derive a score of how well someone knows a particular coding or scripting language, or even a battery of command utilities.  What would that really produce for you?  If I know ever noun/verb phrase, every method and event, every exit code, does that make me a fantastic problem solver?  Does it mean the solutions I would provide would be better than another person's, who scored lower?

Eventually, this divide will be bridged in a more tangible and meaningful way.  Until then, it exists as a voodoo art, rarely discussed in depth and relegated to a bunch of web sites with narrow focus on the pieces of a blurry whole.

Wine is a good thing.  And so is sleep.  Enjoy!

Hmmm..

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

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

The basics of the environment are this:

• Active Directory (Windows Server 2012)
• Windows 7 SP1 Enterprise 32-bit on 99.99% of the desktops and laptops
• Office 2010, IE8 on most everything, but some smattering of IE11 and Google Chrome
• Almost no Windows 8 production computers
• Roughly 1400 distinct software applications
• Roughly 6000 desktops / laptops / users

All of the Windows 8 tablet devices are configured with Windows 8.1 64-bit edition.  They will also come with Office 2013, IE11, Google Chrome 30-something, and a handful of other staple apps for various doo-hickey things (VLC Player, Adobe Reader, etc.)

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

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

While the bigger headaches with XP-to-Win7 migrations circled around UAC challenges, the newer challenges are less dramatic, but no less serious.  Some of the key aspects to consider when reviewing a given software product for use on a tablet device (I'm just picking on Windows 8, but it could be any tablet OS actually), are these things:

1. Does the application sport a UI that is easy to use on a tablet? (i.e. the "UX" aspects)
2. Does the application work well with kinds of touch input "gestures" that a tablet provides?
3. Does the vendor give a shit about tablets, or Windows 8 for that matter?

Go ahead and laugh at #3, but you might be surprised how many would seriously tell you "no".

Now, aside from the aesthetics, there the nuts-and-bolts stuff to consider:

1. Does the application rely on a specific CPU architecture?  Not just AMD vs Intel, but how it pertains to Windows (e.g. "Program Files" vs. "Program Files (x86)", and the wonderful Registry hive "WOW6432node" stuff)
2. Does the application rely on specific browser interfaces?  Will it work as well with IE11 as it does (or did) with IE8?
3. Does it rely on a particular Microsoft Office version?

But wait... there's more!!!

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

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

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

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

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

IT Catastrophes: Triage and Compression with Fries and Coke

Triage (noun)
(b) the sorting of patients (as in an emergency room) according to the urgency of their need for care

Compression ()

The state of being compressed (re: reduced in size or volume, as by pressure)

(source: Merriam-Webster online dictionary)

This is another one of my silly-brained IT monologues about subjects which are rarely discussed.

What I'm talking about is a loose comparison and contrast with these two words as they relate to medical and technology fields.  It is however a very real subject (or subjects) for those of us who occasionally deal with critical outages, especially those which involve things like:

• Highly-Available Hosting Services (think: Google, Microsoft, Facebook, etc.)
• Mission Critical Systems (think: Defense, Lifesaving, etc.)
• Service Level Agreements (the dreaded SLA's)

It's kind of funny how most businesses feel their operations are "mission critical" or "highly-available", when they're being subjective.  From an objective view however, it's not always as "critical" when things go "down" for a few minutes; even a few hours.

By the way: Compression, as it pertains to this article relates to the compression of time in which you have to operate in.  The time between a failure and sufficient restoration of services.

When dealing with a system outage in a truly "critical" environment, the first steps are pretty much the same as what an Emergency Medical Technician (EMT) would have to consider:

1. What exactly is not working?
2. How serious is the impact?
3. What is known about what led to this outage?
4. How long has it been down?
5. How much time is left?

You were probably thinking of the Who, What, Where, When, Why and How sequence.  I kind of tripped you up with two What's and three How's.  (Technically, #4 could be a "when", and #2 could be a "who" or "where", but whatever).  Let's move along.

With regards to a human, the general rule of thumb is 4-6 minutes, total.  That's about how long the brain go without Oxygen and still recover.  Compression CPR is usually the first course of action to sustain blood flow; keeping the remaining oxygen-rich blood reserves moving through the brain.  Enough pseudo-medical blabbering.  The main point is that there is a "first-course of action" to resort to in most cases.

What aspects are shared between a medical outage and an IT system outage?

• There are measurable limits to assessing what can be saved and how
• There are identifiable considerations with regards to impact on various courses of action
• Techniques can be developed and stored for more efficient use when needed
• Steps can be taken to identify probable risks and applying risk mitigation

With regards to a system-wide outage, the general rule of thumb is not so clear-cut as the 4-6 minute rule.  It truly varies by what the systems does and who (or what) it supports.  Consider the two following scenarios:

Scenario 1

The interplanetary Asteroid tracking system you maintain is monitoring a projectile traveling at an extremely high velocity towards planet Earth.  The system "goes down" during a window of time in which it would be able to assess a specific degree of variation of its trajectory.  The possible margin of error from the last known projected path could have it hit the Earth, or miss it by a few hundred miles.  The sooner the system is back on line, the sooner a more precise forecast can be derived.

Every hour the system is offline, the margin of error could potentially be re-factored (and reduced) by a considerable amount, possibly ruling out a direct hit.  The best estimate of a direct impact places the date and time somewhere around one year from right now.  Your advisers state that it would require at least six months to prepare and launch an interceptor vehicle in time to deflect or divert the projectile away from a direct Earth impact.

Scenario 2

Your order-tracking system for MySuckyShoes.com is down and customers are unable to place orders for new sucky shoes.  Your financial manager estimates that during this particular period of the year, using past projections, combined with figures collected up until the outage, every hour the system is offline, you are losing $500,000 of potential sales revenue.  The system has reportedly been offline for two hours.  So far, that's $1 million bucks.

Which of these scenarios is more critical? 

Answer: It depends

What are the takeaways from each scenario?

• How long do you have to restore operations before things get really bad?
• Having the time window defined, what options can you consider to diagnose and restore services?
• How prepared are you with regards to the outage at hand?
• What resources are at your disposal, for how long, and how soon?

In the first scenario, you have roughly six months to get things going.  Odds would be generally good to assume you can restore services sooner than that, but what if the outage was caused by an Earthquake that decimated your entire main data center?  Ouch.

In the second scenario, the margin would depend on the objective scale of revenue your business could withstand losing.  If you're Google, a million dollar outage might be bad, but not catastrophic.  If you're a much smaller business, it could wipe you out entirely.

What's really most important (besides the questions about what systems are down, why, when and how) is knowing what the "limits" are.  Remember the 4-6 minutes rule?  SLAs are obviously important, but an SLA is like a life insurance policy; not like a record of discussion between the EMT in the ambulance with the attending physician back at the hospital ER.  One is prescriptive and didactic.  The other is matter-of-fact, holy shit, no time to f*** around.

QUESTION:  When was the last time you or your organization sat down and clearly defined what losses it can absorb and where the line exists whereby you would have to consider filing for bankruptcy?

Is your IT infrastructure REALLY critical to the business, or just really important?  In other words: could your business continue to operate at ANY level without the system in operation?

Forget all the confidence you have in your DR capabilities for just a minute.  Imagine if ALL of your incredibly awesome risk avoidance preparation were to fail.  How long could you last as a business?  At what point would you lose your job?  At what point would your department, division or unit fail?  At what point would the organization fail?  Or do you think it's fail-proof?

Config Manager Contusions: Finding Advertisements Pointed at Active Directory OUs

If you have a large "enterprise" environment, which has System Center Configuration Manager in it, and it's been in place for a long time, you could have a rather wide sprawling infrastructure, replete with Collections that point to things you completely forgot about.  Case in point: Collections based on Query rules which point at AD Organizational Units (OU).

So, when one of your engineers asks the respectable question: "Do we push any apps at computers in OU ", you're left scratching your head about how to compile a layer of potential Group Policy software installations with another layer of potential Configuration Manager Advertisements.  Say hello to one more Rubik's cube of the IT world.

Thankfully, Microsoft spent just enough time on their SQL back-end for Config Manager to make a lot of chores surprisingly simple with just a few minutes poking around in SQL Management Studio.

Here's one example to demonstrate how to identify which Collections are built on query-rules that point at AD OUs, and (AND) which have Advertisements pointed at them...

[T-SQL Query]

SELECT 
    v_Collection.Name, 
    v_Advertisement.AdvertisementID, 
    v_Advertisement.AdvertisementName, 
    v_CollectionRuleQuery.QueryExpression
FROM v_CollectionRuleQuery INNER JOIN
    v_Collection ON 
    v_CollectionRuleQuery.CollectionID = v_Collection.CollectionID 
INNER JOIN dbo.v_Advertisement ON 
    v_Collection.CollectionID = v_Advertisement.CollectionID
WHERE (v_CollectionRuleQuery.QueryExpression LIKE '%SYSTEM_OU_NAME%')
ORDER BY AdvertisementName

[/T-SQL Query]

Once you start scratching the SQL surface, it's hard to stop.

Stick Shift or Automatic: Software Deployment by the Numbers

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

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

What am I talking about?...

Manual versus Automated Software Product installation, and Repackaging.

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

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

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

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

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

Quasi-Scientific Analysis

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

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

Paying the Bill

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

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

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

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

I haven't even mentioned:

• Time spent deactivating old licenses
• Time spent activating new licenses
• Time spent dealing with device drivers
• Time spent dealing with custom network interface settings
• Time spent on the phone dealing with vendor support:
• Large vendor: waiting on line, listening to 70's pop music, interlaced with endless repeats of ads for their other products, like their "new cloud services".  awesome.
• Small vendor: waiting for guy (company owner/programmer/tester/web admin/support rep) to move his cat off the desk so he can flip through his paper stack to find your purchase order.
• Impact on end-users while they wait for the tech to do their work
• Impact on production from unexpected conflicts with other line-of-business products which are only discovered after the installation because there was no lead-time testing afforded.

In situations where a previous version had to first be uninstalled before performing a new install of the later version (usually because the vendor didn't want to take the time to handle this within their new installation package) the time ranges increase to around 2 hours to 2 hours 30 minutes.

Simple:  35 - 50 minutes

Complex:  120 - 150 minutes

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

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

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

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

Are you starting to see where this is going yet?

Sanity Check Time

Now, let's crank this puppy through ONE cycle of repackaging effort and see how this spews out the other end of the meat grinder.

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

Total time spent:  5+15+30+1+10 = 61 minutes.

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

Things I didn't include:

• UAT problems resulting in having to go back and make adjustments and retesting
• Pre-flight deployments to verify conflicts in production on a limited subset of computers.
• Next-day support calls for incidental one-offs like machines being offline or a service was stopped or an application was open and had a lock on a file that prevented the Advertisement from completing successfully.
• Cats walking across keyboards and causing a BSOD.
• Who knows what else.

Taking those things into account, the ranges can jump from 60-80 minutes for a simple scenario to 2 hours, for just a simple repackaging effort like the one Fubar 2014 involves.  

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

Think of "mission critical" applications, where the time window to get them into production, with 99.999% success rate, is only an hour or two, end to end, over 20,000 or 30,000 computers.  That's not fiction.  There are industries where this is not uncommon, and they rely heavily on this methodology to ensure:

• Highest probability of success
• Consistent and predictable results
• Minimized impact on production operations
• Optimum transparency of all moving parts (think reporting and monitoring)

Steak Dinner Anyone?

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

The cheapest scenario in the first example was $2,850.

The most expensive scenario in the latter example was $1,442.

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

That's Not All

Billy Mays homage:  Now, if you go with the repackaging and automated deployment scenario, you have a mechanism in place that does the following for you without ANY additional cost:

• Provides automatic self-healing of deployments, to cover situations where a targeted computer is replaced or reimaged with a fresh Windows configuration.
• Provides simple, effortless scalability for future growth.
• Provides a robust auditing and reporting trail for accountability and compliance.
• Provides fault tolerance
• Provides coverage during non-production hours.

Still think that thumb drive is the way to go?  Hmmmm?

Dave's Top 10 Windows Command-Line Goodies

I'll admit it, I like geeky "Top 10" lists.  The irony of saying "Windows" and "command-line" in the same sentence also fits nicely with how my wobbly brain works, so I couldn't resist.  While scripting is obviously in a class of its own with regards to flexibility, scale and so on, the built-in tool set provided within Windows 8 (and Windows Server 2012) is still worthy of some healthy respect.

The commands listed below are some that I use quite often, and by that I mean pretty much every day. On a typical day I will have two CMD consoles open, a PowerShell ISE console and at least one or two instances of some code editor application like TextPad or Visual Studio Express.  Regardless, I will often jump back to one of my CMD consoles to do something that involves one of the items mentioned below.  Maybe there's a few in here you haven't tried yet.

1. CMDKEY

I use this for managing my credential mappings between my laptop, my home domain environment, my various "work" environments, and TS/RDP environments.  To list saved credentials, use "cmdkey /list".  You can narrow down the list to one target, such as a server you connect to by SMB or RDP named "fubar", by typing "cmdkey /list:fubar".  To add a new explicit mapping, such as connecting to server "fubar" from your tablet which is not part of the same domain or workgroup, use "cmdkey /add:fubar /user:dave /pass:p00rb@$taRd".  For more information about this command, type "cmdkey" and press Enter.

Example: save login credentials for domain server "serverXYZ" from your workgroup laptop...
cmdkey /add:serverXYZ /user:dave /pass:Ih@teP@$$wordZ

2. WINRS

This is another command I find extremely helpful.  There are a few times where it doesn't shine as brightly as I'd like, but that's rare.  One such example (and don't let this put you off) is invoking a utility like "SendSchedule.exe" on a remote box, even when the associated XML config file is in the appropriate location.  You just get nothing.  Again, this is not worth tarnishing this powerful utility.

What does it do?  Magical stuff.  That's what.  It's basically a remote shell wrapper, and lets you execute tasks on the remote computer as if you're on that remote computer.  So if you have a script, say "dosomething.ps1" sitting in the c:\stuff folder on serverXYZ, and you're on your laptop named "dingy8", you can open a command console (or PowerShell console) and type:

winrs -r:serverXYZ powershell.exe c:\stuff\dosomething.ps1

Then watch the results unfold as if you were logged onto serverXYZ and running the script directly.

There's way more to this command than I can possibly blurt out here, so try "winrs -?" to begin exploring.

3. PUSHD and POPD

This one has been around almost as long as me.  Same for its cousin: popd.  The pushd command creates a temporary "ad hoc" drive mapping to a specified share.  So if just need a drive letter, under the context of whatever the command console is running as, just type "pushd " and bang! you have a Z: drive and it's the current drive as well.  So why does this do any better than "net use"?  Well, to disconnect "net use" you have to use "net use" again and provide some more key strokes.  In some cases, you forget and leave the drive mapped even after repeated logins.  The pushd command only lasts until you either log off (or "sign out" in Windows 8 parlance), or use "popd" to release any pushd mappings.

Example: map a temp drive to share \\serverXYZ\stuff --> pushd \\serverXYZ\stuff

4. SC

The sc command is another golden-age oldie that provides command-line control over the Windows Services environment.  SC allows you to stop, start, create, delete, and modify Windows Services.  Nuff said.

Example: Check on the status of the WinRM service --> sc query winrm
Example: Stop the WinRM service -->  sc stop winrm
Example: Change WinRM startup to manual -->  sc config winrm start:demand

for more information, type "sc /?"

5. SCHTASKS

Like the sc command, this is one is a counterpart to a common GUI tool.  This one provides management features for Scheduled Tasks (hence the abbreviated name: "SCHeduled TASKS").  You create, delete, modify, list, export and import scheduled task jobs with incredible detail and control.  In many cases, it's easier to shove a command string using schtasks through a shell operation from within a script, than to use the direct API alternatives like WMI and .NET, but it depends on your circumstances of course.

Example: List all scheduled tasks on remote computer "Abc123": schtasks /s abc123 /query
Example: Run task "doit" on remote computer "abc123":  schtasks /s abc123 /run /tn doit

6. SHUTDOWN

Ah, this is a most powerful, yet most simple command tool.  Almost as flexible as "psshutdown" and some other third-party tools, it lets you request or "force" a shutdown, logoff or restart of a remote computer, as well as the local computer.

Example: Restart remote computer "abc123" in 30 seconds --> shutdown -m abc123 -r -f -t 30
Example: Restart "abc123" with a custom display message to the current users...
shutdown -m abc123 -r -f -t 30 -c "IT rulers are kicking you minions off in 30 seconds!"

7. REG

If you haven't heard of this command already, you might have guessed that it has something to do with the Registry.  Yep.  This cool gadget provides command-line capabilities for reading, writing, importing and export registry keys and values and a little more as well.

Example: Display installed apps...
reg query hklm\software\microsoft\windows\currentversion\uninstall /s

Example: Import a .reg file
reg import regfile.reg

Example: Import a .reg file into 32-bit view on a 64-bit computer:
reg import regfile.reg /reg:32

8. ROBOCOPY

Oh boy.  What can I say about this command that hasn't already been said?  Once you get used to it, xcopy and the like will be flushed down the drain for good.  Powerful.  Flexible.  Simple.  Incredibly useful.  And it was one command I was happy to see rolled into the base operating system configuration, where it was once relegated to Resource Kit add-ons.

One scenario I use this in quite often is wrapping in a .bat script to synchronize remote project folders to a central location, and then invoke the 7-Zip command-line interface to archive the backup content into .zip files and offload them to attached or removable storage.  For me it's just another redundant redundancy of backups, in addition to server backups, DropBox, Google Drive and One Drive.

Example: backup only .vbs and .ps1 files which are newer than those already backed up, or added since last backup, from \\server123\stuff to d:\archives\scripts...
robocopy \\server123\stuff *.vbs *.ps1 d:\archives\scripts /xo /s

One interesting aspect to robocopy is showing the "help" information.  On older versions, "robocopy  /?" or "robocopy /???" and get very different results.  However, on Windows 8 and Windows Server 2012 both options were merged to produce the same results.

9. MSG

This sneaky little turd hijacked the old "net send" command like a stealthy ninja.  Not quite a easy to implement due to the choke collar placed on the messenger service since Windows XP was taken out in a boat and shot in the head (GodFather homage).  I wrote a blog post some years back on nothing but how to implement msg in a Windows 7 environment and enable the plumbing using a GPO.

If you don't have a GUI IM product in use, such as Communicator or Lync (same thing, different lipstick), and don't have an IRC app in use, this is another means to annoy your coworkers.

Example: tell my son Zach to get to bed, while he's uploading guitar demos at his computer in his bedroom...  msg zachary /server:zachspc /v "bed time dude!"  (the /v option says to wait for him to click the 'ok' button to indicate he read it).

10. MSTSC and MSRA

Holy crap, these are powerful and offer everything from really simple/basic/easy usage to up arguably complex yet powerful usage.  MSTSC is the Remote Desktop utility.  So instead of navigating the Start Menu or Start Screen for Remote Desktop, and entering a computer name to access, you can invoke it from a command-line aspect.  It also offers command-line options for dealing with multiple monitors (/span and /multimon), shielding credentials (/restrictedAdmin) and invoking a preconfigured connection file.

Example: Remote into serverXYZ -->  mstsc /v serverXYZ

MSRA is the command-line counterpart to Windows Remote Assistance.  There are ton of options for this command (type msra /? for a list of them), but /offerra is the most commonly used of them.

Example: Initiate a Remote Assistance offer to the user on computer "fubar5"...
msra /offerra fubar5

You can go crazy with msra and invoke email invitations, password protection on assistance offers, and much more.

Conclusion

There are obviously many more command-line tools available on Windows 8 and Windows Server 2012 I could have included.  Some that come to mind, which I also use quite often, include MSIEXEC, WEVTUTIL, WBADMIN, WMIC, OPENFILES, FTYPE, DRIVERQUERY, REGINI and FINDSTR.  I won't argue that there aren't better alternatives outside of what comes built into Windows, even many that are "free", but it's nice that these still exist for times when you need them.

Cheers!

Walking the Walk

Quick post before I unplug and go comatose for the evening:  Tomorrow, when you get to work (or if you're in a different time zone and it's daylight right now) try this on:

1. Write down all of the key functions your IT group performs.  AD accounts, software deployment, patching, server provisioning, backups, storage management, cloud integration, etc. whatever.  List them out.
2. Identify the role(s) which relate to each of them:  Account Managers, App Packagers, App Deployers, Server Managers, Cloud Administrators, etc. whatever.
3. Assign actual names to those roles.
4. Compare that mapping with reality.  Grade yourself on a 100 point scale by checking off how many roles/people are actually assigned accordingly with what you are already doing today.

Let me know your score, what scale your environment is (small, medium, ginormous, etc.) and which country you're based out of.  Just curious how we all rate ourselves.

G-night!

Nerd Hobbyist: A 10 cent Web Interface on AD LDAP Queries

The Goal

Provide a web interface (web page) to create, save and execute Active Directory LDAP queries within a domain environment.  This version is predicated on using ASP, rather than ASP.NET.  This is sad and unfortunate, but it works.  I plan to post an update to this using ASP.NET, focused on "zero-cost" as the main constraint (i.e. no purchases required beyond the base operating system stuff).

Also, rather than just posting the code, I'm going to describe the process and the steps.  Otherwise, you will do the lazy thing (like I would) and just ignore my rambling and download it.  Then I'd get a ton of emails from you asking why something didn't work as you expected.

Can this be accomplished by other means?  Absolutely.  Are those other means easier to implement?  Maybe.  Are those other means cool?  Maybe.  Does Dave care?  Not really.

As for ASP: if you one of those folks who are already turning your nose up at this choice, note that there are still a shit-ton (that's a real number, trust me) of web pages still being served up via ASP, even on Microsoft web sites. So: nah-nah-nee-boo-boo.  So, for now, relax, drink up and enjoy my little bus stop cooking show.  Cheers!

The Ingredients

• An Active Directory network environment (preferably 2008 domain-level or higher)
• An IIS host (physical or virtual, server or client version).
• A dedicated AD account for use with executing the queries.
• A database for storing your precious LDAP queries in.
• A tablespoon of ASP (vbscript) code and your favorite text/code editor application.
• A few cups of coffee

The Recipe - Database Cookie Dough:

1. If you don't have a SQL Server database server at your disposal, then install SQL Server Express (2012 is preferred, or whatever is the newest and shiniest).
2. Create a database (preferred, to keep it separate from other databases).  Suggested name: adqueries.
3. Create a table in that database.  Suggested name: reports.  Figure 1 (below) shows a variation on this with some additional columns.
4. Create the following minimum columns:  ID, ReportName, Comment, QueryText
5. Make ID type = Int, Identity(1,1) and primary key (not null).  Make ReportName type=varchar(255) (not null), Comment type=varchar(255) (null), and QueryText type=varchar(255) (not null).
6. Grant permissions to the database and the table for however you prefer your spiffy web app to interact with it.  Integrated Security is fine, as is SQL security with an internal SQL account.  You can use text-book "role" based access management, but whatever you do, just make sure to grant access within SQL Server to allow that account to make a remote connection.

Figure 1 - Example Table Structure

For purposes of saving time, go ahead and manually stuff a few example reports/queries into the table.  That way when you finish your coffee and the first page (see below) you will have some sample rows to validate your web site interface to the database.

Figure 2 - Sample reports

Example queries/reports could be some really basic stuff like:

• Report 1
• ReportName= "Computers - Windows Server 2012"
• Comment = "Domain computers running Windows Server 2012"
• QueryText = "objectCategory='computer' and operatingSystem='Windows Server 2012*'"
• Report 2
• ReportName = "Computers - Windows 8"
• Comment = "Domain computers running Windows 8.x"
• QueryText = "objectCategory='computer' and operatingSystem='Windows 8*'"

The Web Sauce:

1. Create a folder on your chosen web host.  This can be a Windows 7 or 8 computer, or a Windows Server 2008...2012 computer.  As long as it's a member of your target AD domain.  Suggested path/name: c:\inetpub\wwwroot\adqueries.
2. Create a web site virtual folder linked to that shiny new folder.  It can use anonymous authentication if you feel comfortable with that, or do as you please.  If it works and doesn't cause the FBI to kick your door in and shine red LASER dots on your forehead, you will probably be alright.  Suggested site name: adqueries.
3. Optional (but preferred): Convert the virtual folder into an IIS application.  Assign a domain account for the application pool process context.  That account should have rights to query whatever it is you want to query.  It does NOT have to be a domain administrators member, or anything that serious.  Click the "Test Connection" button to ensure it works.
4. You will likely need a minimum of 4 code files:
1. A main page which provides a list of saved LDAP queries, each of which are hyperlinked to a "run-query" type of page.  Suggested name: default.asp
2. A "run-query" type of page.  Suggested name: report.asp
3. A code library page, which will be included in each of the other pages (centralized code stuff).  Suggested name: my_asskicking_codestuff.asp.  Include it in the other pages using the standard top-line import method: (#include file=_my_asskicking_codestuff.asp)
4. A form page for adding new, or editing existing, queries.  It should have text boxes for the following properties at a minimum (add more if you like):
1. Report Name [textbox]
2. Report Comment / Description [textbox]
3. LDAP query code statement [textarea] or [textbox]
   suggested name: reportedit.asp
5. OPTIONAL: You can code the form-page (mentioned above) to serve as both the "add new" and "edit" pages if you like, or make separate pages.  It doesn't matter as long as you're happy and it gets your mo-jo humming along.  For example: reportnew.asp, reportedit.asp
5. Drink your coffee and start coding it up.

The First Query

1. Here's an easy one:  objectCategory='computer' AND operatingSystem='Windows 8*'.  If you actually followed my suggestion earlier, then you'll want to try a new one, like 'Windows 7*' or whatever.  Keep mind you can make queries to search for almost anything: user accounts, groups, contacts, printers, shares, etc.
2. Drink more coffee

The ASP Stuff

I wanted to avoid this, but I suppose I can't totally ignore it.  I can ignore my neighbors (they ignore me anyway) but code is hard to ignore.

The code library file:

• Needs to include some basic stuff like variable definitions and Const definitions, which identify such things as ADSI values, ADO values, the name of your SQL Server and Data Source Name (DSN), and so on.  Example below:

     '------------------------------------
     ' comment: ADO and ADSI enumerations
     '------------------------------------
     Const ADS_SCOPE_SUBTREE = 2
     Const E_ADS_PROPERTY_NOT_FOUND = &H800500D
     Const adOpenForwardOnly = 0

     Const adOpenKeyset = 1

     Const adOpenDynamic = 2

     Const adOpenStatic = 3

     Const adLockReadOnly = 1

     Const adLockPessimistic = 2

     Const adLockOptimistic = 3

     Const adLockBatchOptimistic = 4

     Const adUseServer = 2

     Const adUseClient = 3

     Const adCmdText = &H0001

• The ADSI/OLEDB connection stuff:  The standard interface between script code and Active Directory (for LDAP queries) is through an OLEDB provider.  For more info on this, check out http://msdn.microsoft.com/en-us/library/windows/desktop/aa746517(v=vs.85).aspx 
• Take this example (credit: ActiveExperts.com: link) and use it to test by running it in a CMD console using RUNAS to verify the AD account you intend to use will work properly.
• Adapt the VBscript code (above) to ASP by changing the wscript.echo methods to Response.Write (be sure to enclose the string results in HTML tags to format it properly).
• Test it via your web browser.

Yes.  I know you can do this with ASP.NET and Visual Studio Express, but if you're still working with ASP, like millions of other Earthlings, you still have options (and free web blogs).  If you REEeeeeeeaaally want some actual code, let me know (post a comment below).

Now.  If you'll excuse me, I need to go pass out on my bed. Namaste.

Let's Talk About Software Repackaging. Mmmm kay?

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

Why?

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

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

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

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

Clarification Time:  To Package or Repackage?

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

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

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

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

Skills?  What Skills?

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

• Experience with Windows Installer (command syntax, logging, exit codes, troubleshooting, etc.)
• Experience with InstallShield EXE packages (silent commands, answer files, etc.)
• Experience with a repackaging product like AdminStudio, InstallShield or Wise Installer (if that's still around).  Familiarity with other, similar products doesn't hurt, but those AdminStudio and InstallShield are the most desired.
• Windows Event Logs.  The ins and outs. Exporting.  Searching. Filtering, etc.
• Windows Environment Variables (%username%, %computername%, blah blah)
• Windows Path Assignments (%windir%, %appdata%, all that mess)
• NTFS File System aspects: ACLs, SACLs, DACLs, etc.
• ACLs with regards to the Registry
• The Registry (know it.  love it.  live it.)
• Windows Services (configuration, status monitoring, troubleshooting)
• Familiarity with Security Contexts (what accounts are running what things, etc.)
• Lot's and Lot's and Lot's of scripting experience: BAT, VBscript, Javascript, KiXtart or PowerShell.  Others will help, but mostly BAT, VBscript and PowerShell.
• Familiarity with Group Policy Objects and how they are processed on a computer.
• STRONG familiarity with Windows command-line tools: REG, REGSVR32, CACLS/XCACLS, REGINI, SET, SHUTDOWN, LOGOFF, SC, NETSH, PING, NSLOOKUP, and START.  All the newer stuff helps too, like WMIC, WEVTUTIL, DSQUERY/DSGET
• PSTools.  In fact, if you don't know who Mark Russinovich is, you're not getting hired. Sorry.
• Orca
• ROBOCOPY and all of it's drippy goodness.
• Familiarity with Virtual Machines (VMware Workstation, Hyper-V, Xen, blah blah) for testing and rollback, etc.

Absolutely Most-Basic Skills:

• Making a Windows Installer Transform
• Making a SETUP.EXE response file (.iss file)
• Basic script skills:  If/then/else, loops, etc.
• Command Tools:
• Querying and modifying folders, files and Registry keys and values
• Manipulating security permissions on files, folders and Registry values
• Stopping and starting Services
• Restarting a computer (local or remote)
• Using Process Monitor (and why)
• Using TASKLIST or PSLIST effectively (and why)
• MSIEXEC command syntax (seriously!  double-seriously actually)

Double Extra Bonus

• Familiarity with deployment automation products like Microsoft System Center Configuration Manager. Particularly: the creating, maintaining and troubleshooting of:
• Collections (and queries)
• Packages and Programs
• Applications (SCCM 2012)
• Advertisements
• Maintenance Windows
• Group Policy Preferences. Item-Level Targeting (aka WMI Filtering). Blocking and Inheritance, sequence ordering, RSOP, blah blah.
• Deep understanding of the differences between snapshot capturing and snapshot/monitoring captures.
• MDT (Microsoft Deployment Toolkit) and ADK tools
• Logon, Logoff, Startup and Shutdown scripts
• Active Setup
• Application Compatibility Toolkit (ACT) and building shims (know what shims are also)
• DISM
• Using and Mounting ISO and WIM files

Will you have to use all of these all of the time?  No.  Will you need to use these a lot?  Maybe.  But the more familiar you are with this list the better you will be at planning, preparing, developing, testing and deploying application packages.

Triple Extra Double Bonus

• Great customer relation skills.
• Being able to have a sincere conversation with users who have almost zero understanding of the effort you put into making things work for them which appear to be effortless.
• Great note-taking skills
• Patience, especially when sitting through long meetings
• Following-up on things (customer responses, meetings, reports, etc.)
• Prioritizing (projects, tasks and personal tasks)
• Scheduling (personal and group/team events)
• Sticking to your guns
• Developing a deep and loving relationship with coffee or tea
• Developing a deep and loving relationship with beer, wine and/or liquor
• Being consistent, dependable, and on-time
• Focusing on documentation and organization of notes and materials
• Having the ability to calm down panicked users/managers during a crisis and methodically gathering the facts to diagnose the problem properly.

Toughest Challenges?

• User Acceptance Testing (UAT)
• Vendor Tech Support discussions (or email threads).  Especially the kind where you ask for help and they promise to "get back to you" and never do.
• Customers who insist they CANNOT function without that MS-Access 2003 "application" or the entire company will fold and close. (bonus points for FoxPro 9 apps)
• Hours and hours of reading the most excruciatingly boring manuals.
• Hours and hours of searching web sites for troubleshooting tips for that one niche app "Fubar 1997" that won't seem to work on Windows 8.1
• Decaf coffee, and Ice Cream-flavored store brand coffee.
• Bowls of sugary junk food sitting around for weeks on end.
• Hours of conversation with coworkers who are either (A) uber-religious or (B) uber-atheist, and neither can wait to remind you just how awesomely correct their views are.
• Recaps of last nights sports event or draft picks, especially those incredibly important fantasy league trade discussions.
• Listening to arguments over which sport is the toughest or which TV show is best, or which car is fastest or which asshole has the toughest job and most difficult customers.
• Tearing off in a panic to the closest restroom, ripping off your clothes quickly, sitting down, letting loose, closing your eyes, exhaling slowly, and then opening your eyes to discover there's no toilet tissue.
• Traffic (except for you lucky assholes that work from home)
• Cold, stale coffee... but only if it already has that white fuzzy mold on it.  Otherwise it's just fine.

The Yellow Brick Road

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