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!

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.

The Windows XP Dilemma - Part 1

I apologize for not having posted anything of significance in quite a while.  My life has been a roller coaster lately and I haven't had time to focus on writing as much as I used to.  But here goes...

Rod Trent got my attention today when he posted a link to a humorous article about "Top 10 Reasons to Keep Windows XP", over on Windows IT Pro Magazine's web site.  It is pretty funny, and I encourage you to take a break from any serious crap going on around you and read it.  However, I have more to say on this subject, so I also encourage you to continue reading below.  Keep in mind that I'm walking a fine line between end-user and IT professional, as it pertains to my wording.  I may put some of the IT pros to sleep here, but don't worry, I'm going to pour more sauce into it to keep things alive.  Read on....

That said (or written), I had some other thoughts on this Windows XP issue.  Some of which may have been mentioned by others before me, but I will layer my thoughts with my own sauce to make it more tasty.

Why are ANY companies still on Windows XP?  Never mind that there are still more of them are still using (and relying upon) Windows XP than you, or I (or Microsoft) would want to believe.  From my own personal standpoint: If I couldn't afford to purchase a new version of Windows, I would replace it with some flavor of Linux.  Drastic?  Sure.  A bit hyped?  Maybe.  But let me slather some Dave sauce on it here a bit...

I'm sure you've heard enough about how Windows Vista, Windows 7, and Windows 8, all provide better security, reliability, performance and more exciting features, than Windows XP.  I'm sure you've seen the "deals" offered at every retail shop from BestBuy to whomever.  I'm sure you've seen the ads on every web site, from Acer, Asus, Dell, HP, Lenovo, Samsung, and every manufacturer ever imagined.

But, think about this for a moment, as you read this from your Windows XP computer sitting at home, in the office, or some fast food place, or coffee shop:

A Real World Test

In 2007, when I had the luxury of a "testing lab" network at the place I was working at, I decided to see if my suspicions were valid about how vulnerable a "stock/generic" Windows XP Professional installation would be if it were connected "directly" to the Internet.  No firewalls of any kind.  No anti-virus or anti-malware protection of any kind.  Just regular, vanilla, reseller-agnostic version of Windows XP Professional, with Service Pack 2 "slipstreamed" into the base installation.

I repeated this test six (6) times over the course of two (2) weeks.  The same installation process was used on two different pieces of hardware: A Dell OptiPlex GX260 and a Dell OptiPlex GX270.  Those were the standard-issue platforms for all of our corporate employees at that time.  Three (3) installs on each of the two (2) machines (like I said: six tests overall).

The average time it took for someone outside to port scan, probe, identify a hole, exploit it, and install something malicious was 2.5 minutes.  Some took longer.  One was "owned" by an outsider in less than one minute. And this is on relatively slow hardware, by today's standards anyway.

Four (4) of those involved a variant of the most-popular root kit of that time.

The short end of this was that none of the installations could be reliably recovered.  All of them required a completely new re-install, in an isolated or firewalled environment, in order to provide any reasonable assurance of "security".

When Windows Vista was released, I tried the same test, but only on one piece of hardware, repeated twice (2 times).  I couldn't use more hardware, nor could I repeat the test more times, because we were in the midst of being acquired by another company.  The new owners ordered an immediate shutdown, disconnect, and dismantling of the "test lab". NO questions were to be asked.  Just "do it" and do it "now!", I was told.

(Side note: It's a little bit ironic that a week later I was chided for not being able to test a patch before it was to be pushed out in to production.  When they asked me why I hadn't tested it, I said because I no longer had a "test lab".  They asked me "Why" and I said, "Because YOU told me to get rid of it.  Would you like me to print and show you your own e-mail?".  Good times).

Longer story made short:  The tests with Windows Vista went much better, mainly as a result of having (a) a better firewall feature in place, and (b) fewer "attack surfaces" left open by default.  Windows 7  and Windows 8, respectively, have continued on in that direction of battening down the hatches for greater security, while at the same time, making better use of the current hardware capabilities.  The net result is a much better, and much SAFER experience for YOU, your family members and loved ones, your sports teammates, your alumni members, and your business.

Why Continue Using It?

So why do people remain on such an insecure, unprotected operating system?  Two reasons:  Budget (or, lack thereof), and Laziness.

But, there's more to it than just those two excuses.  If you turn off your 1998-2002 era piece of computer garbage (oops, I meant to say "computer hardware", my bad), and run down to a store to buy a new version of Windows for your old decrepit computer, will that take care of it all?

No.

Why not?

Because there's more to it than just the operating system.  There are additional concerns like drivers (programs that help your Windows operating system "see" and work properly with various other hardware gadgets inside and connected to your computer), your software programs, and so on.

(shameless plug: I'm writing another book related to this subject, but you're not required to buy it - psssssst, but doing so would help me feed my four kids, just sayin')...

Situation 1 - Applications

You've been relying upon TurboTax 1998 Edition, Doom II, and Lotus 123 for all your serious work on your old, rusted-out Windows XP machine.  You drive over to BestBuy and discover that Lotus is gone from the shelves; there's only TurboTax Premium 2014 Edition, and the mention of Doom II just makes all of the teen-aged clerks scratch their heads in confusion.  Now what?  You have to buy a  (dum-de-dum-dum-DUMMMM! music goes here) NEW COMPUTER.  Bad news for your bank account.

Situation 2 - Hardware

Those tax forms, spreadsheets, and game stats all had to be printed out on your trusty inkjet printer you bought back in 1999 or 2000.  The Cyan ink jet is dried up solid, so everything only comes out in weird tones and shades, but hey, it still works, right?  At least the gray-scale and all-black prints work okay.  You start looking at a spiffy new printer.  Man!  They sure have added some cool new features since then!  And wow, the prices aren't actually all that bad.  Then you spin the box around and look at that dreaded "System Requirements" disclaimer stuff.  Then you see it: "Windows Vista, Windows 7 or later."

If you had to stop and ask yourself: "They have newer versions of Windows than XP?" just stop right now and go to the nearest bar. I can't help you any further at this point.

If you're still reading, you're probably wondering about why there are new requirements.  It's because with newer operating systems, you get newer features, and those bring newer functions and capabilities.  Those all mean newer tools that have to be used in order for the new gadgets to talk to Windows so they each understand what the other is saying.  Trying to put a 2013 model printer on a 1998 computer setup is like sending a skaterboarder punk kid back to 1882 and dropping them into a courtroom to argue a legal case.  It's not going to work out very well for anyone.

- - - - - - - - - - - - - - -

Coming up in Part 2 - The emergence of Software Repackaging in the world of Windows upgrades and migrations.  The peripheral problems.  The licensing nightmares.  And more!

Computer Accounts vs Service Accounts, Round 3

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/ 

Do as I say...

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.

The Identity Illusion

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).

PSEXEC, Computer$ and SYSTEM Access

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.

Windows Admin Basics: Security 101

\\Server1\e$\FolderA (NTFS):
(local) Administrators = Full Control
(local) Users = Read
(domain) SalesManagers = Modify

\\Server1\FolderSales (Shared: "FolderA")
Everyone = Read
(local) Administrators = Change

User "jdoe" is a member of "SalesManagers" AD security group.  He gets an "access denied" message when trying to save a file into the folder "\\Server1\FolderSales".  Which of the following actions can be taken to allow "jdoe" to save the file into this shared location without requiring "jdoe" to log off and log back onto the domain?

1. Add user "jdoe" to the local "Administrators" security group on Server1.

2. Add the "SalesManagers" domain security group to have Change rights to the FolderSales share permissions.

3. Add user "jdoe" to the "Server Admins" domain security group, which is a member of the local "Administrators" group on every server in the domain.

Domain Service Accounts are STUPID

I've covered this before, but apparently, amazingly, there are people on this planet who do not read my stupid blog.  As if there is anything more important or interesting out there.  Geez.

(Imagine this for just a moment: Rioting in Cairo comes to a halt, as one guy over on the side yells out "Hey!  Check this American idiot blog out!" and the crowds quietly converge around this guy's laptop to read this right now.  Yeah.  It could happen.  Right after the monkeys fly out of my butt).

I've mentioned this topic several times in the past, like here http://skatterbrainz.blogspot.com/2009/02/windows-7-2008-r2-managed-service.html and here http://skatterbrainz.blogspot.com/2008/11/can-you-roll-your-own-management.html and here, but most importantly here http://skatterbrainz.blogspot.com/2008/08/using-system-account-instead-of-domain.html

I feel like a traveling minstrel everytime I have to explain this to someone.  Even more amazing when I have to explain it to a SCCM administrator.  As if they didn't already use this when granting permissions to the MP and SLP role hosts on the System Management OU in Active Directory.

It goes like this:

The local SYSTEM account only has rights to the local machine, by default.  But, what happens when you attempt to access a remote resource using the local SYSTEM account, is that the remote resource sees the incoming authentication request coming from DOMAIN\COMPUTERNAME$ (where "DOMAIN" is your NetBIOS domain name, and "COMPUTERNAME$" is the name of the computer where the SYSTEM account process was initiated).  The "$" suffix is Windows' way of identifying a computer account (as if it doesn't already have enough other ways to know this).

All computers which have been joined to a domain become members of the default group "Domain Computers".  This group is not a member of any other groups by default.  It is not granted any resource accesses either, by default.  It's just sitting there, in case you need it.  Well - YOU NEED IT.

You can go about this in one of three ways:

1. For resources that need to grant access to all domain computers, just grant the "Domain Computers" group the appropriate access.
2. For resources that need to grant access to one specific computer, just grant the Computer$ account explicit access (although, this technically breaks the AGUDLP or ADLGUP methodology, or whatever.  I live by it, but don't ask me to say it right)
3. For resources that need to grant access to a specific collection of computers, create a security group (Global or Universal, whatever) and grant access to the group

Sounds easy - Right?   That's because IT IS EASY.  EASY as taking a dump after eating a pound of Chinese food and a box of laxatives.  You'll wonder why you EVER bothered making stupid domain accounts to run scheduled tasks, backups, launch services, etc.  Then you'll smack yourself in the face realizing you don't need to manage passwords anymore either.

Please.  Give it a try.

Are we really THAT f-ing pathetic?

One of my customers, who happens to run an extremely tight ship, just also happens to have a GPO that configures UAC to run at the top-most level (always prompt).  When I first encountered this, I was a little surprised, even startled a bit.  But I quickly adjusted and moved on.  After six months of working within that environment, I realized how useful and beneficial that really is.  In fact, I realized that after the first week.  Maybe the first day.  But when I described this situation to my colleagues outside of this environment, I saw the same reaction from each and every one of them: shock and dismay.

Really?

I'm always curious as to the rationale behind decisions, views, opinions, so I dive into this one head first.  The reasons completely blew me away.  First off, I would offer the benefits, which are simple yet powerful:

• Optimum protection against malware and accidental screw-ups
• A continuous "Run As" prompt that works well with NOT EVER LOGGING ON AS AN ADMIN

That last one comes directly from the mouths of EVERY SINGLE security handbook from UNIX to Windows and all systems in between.

Yet, the main reason they don't like this?

• It's too much of a pain

Really?

What pain?

"Constantly having to type in my credentials. ugh!"

Wow.  We've become so f-ing pathetic that we can say to others, with a straight face, that TYPING is a "pain" or "tiring" or "cumbersome", etc. ?  Ho-ly crap!  I started out in my tax-paying employment life working in the trades.  Insulation, steel, painting, construction, roofing.  Then I moved on to paint delivery, and a ba-zillion other stupid (yet incredibly enlightening and educational) jobs before tripping over a pothole and falling face-first into the IT world.

When I hear some whiney-ass IT person say that TYPING is painful, difficult, tiring, or annoying, I want to smack them in the head with a pipe wrench and a roofing hammer.  To me, this is like standing in a room full of Marines, prepared to deploy to a war zone, and crying on their shoulders that I broke a nail and therefore cannot accompany them on their mission.   Wow.  Just wow.  Just f-ing wow.

Grow a pair.  Do your job correctly/properly, or find another career path where whining is not only allowed but expected.  You know, like political service.

Alias Schm-alias

An old colleague and friend of mine "Dave" (not me, I swear) e-mailed me with some interesting info that he thought might be worth sharing.  This is regarding the command alias data file used by AutoCAD 2010 and AutoCAD Mechanical 2010.  More importantly: the DIFFERENCES between them.

AutoCAD 2010 apparently uses a file named "alias.pgc", stored in the folder path %ProgramFiles%\AutoCAD 2010\Express.

AutoCAD Mechanical 2010 uses a file named "alias.pgp", stored in the folder path %ProgramFiles%\Autodesk\ACADM 2010\acadm.

But that's not all!

In his environment at work, "users" do not have Administrator rights.  EVER*.  It's prohibited by policy (as it damn well should be everywhere on the planet Earth).  Users therefore cannot edit their own command aliases while the files reside in those locations.

*SIDE NOTE: If you can't make your Windows client environment work without granting users Administrator rights you have NO idea what you are doing.  There are no exceptions.  Violators will be waterboarded, beaten, tasered in the groin and trampled with ice climbing boots.  Any questions?  Good.  I didn't think so.  Now… back to the story…

So, normally Dave does what most experienced packagers/administrators do: run a CACLS process on the file or folder to make it behave normally for a "user" login.  The problem is that AutoCAD Mechanical 2010 wants to create a temporary lock file, while the alias.pgp file is being modified.  This is only a small challenge since CACLS works fine on files AND folders. 

However, it presents a dilemna wherein opening the permissions to the entire folder defeats the intentions of having user security levels in the first place.  This, by proxy, violates Microsoft Windows XP Compatability tenants.  I presume such practice on Windows 7 would violate those as well.  But I'm not an attorney.  I just make fun of them when they're not around.

So, now he's faced with two CACLS processing chores:

CACLS "%programfiles%\AutoCAD 2010\Express\alias.pgc" /e /c /g users:c

CACLS "%programfiles%\Autodesk\ACADM 2010\acadm" /e /c /g users:c

Aside from the path names, can you see the difference?  One ends with a file name, the other does not.  That means the second statement applies to the entire folder and all of the files within it.  Wag of the finger!

Here's a Software Development 101 tip:  If you are developing software to install on Windows clients, and you're not making it with something clever like Microsoft ClickOnce, App-V, ThinApp, XenApp, or whatever, make sure that anything a "user" can modify will allow a "user" to modify it. 

While some vendors make no distinction between "user" and "administrator" (aka "admin"), the rest of the brain-enabled world does.  I'm not picking on Autodesk, they get enough picking on. They're actually one of the better vendors out there.  There are many who, shall I say, write crap code, and leave us IT pukes to deal with shoe-horning it into real-world environments.

Old Topic / New Thoughts: Special User Accounts

You have scheduled tasks and services running around like 3-legged blind cats with collars made of catnip.  They've been drinking Red Bull all day also.  Not good.  Now one of the suits walks in with a folded up magazine about "Cutting Edge IT" he lifted from the seat pocket on his red-eye flight from Vegas.  He says: "You boyz, listen up! I read that you best be a-changin them there passwords on them there service accounts.  Y'all hear?!"  And after a short pause with no sound, you all start back to work as if he never entered the room.

Ok, I needed a mental break.  On to something more serious:

You changed a password and now shit is breaking.  Or even more tedious is that the account keeps getting locked because something out there in the depths of space is still trying to use it and getting the gas-face from AD.  You could start the manhunt for where the problems are coming from.  You can query AD for which DC handled the offending request that locked the account.  You can query all computers in the Forest or Domain for scheduled tasks, services, DSNs, auto-runs, and so on.  Fear not there are three easy "options" to mitigate this crap:

1. Create a new account.  Disable the old account

2. Restrict the account to only specific computers

3. Use machine accounts (aka "SYSTEM")

I prefer option 3 for everything.  Like killing ants with a Gatling-style howitzer.  But that's just me.  As for option 1, it'll leave a mess behind, that's for sure.  But the problem will eventually be solved.  However, it will only work its way out if you combine it with option 2.

Option 2 is really what you should have been doing all along.  A funny little trick we used to do waaaay back to **** with co-workers was to get on our computers in the morning, and enter the user ID for the co-worker and fat-finger the password (intentionally) enough times to lock the account.  Then chuckle, sip some coffee and log in normally and wait for the yelling from across the room.  Good times. 

Funny: maybe (to me it was), but this is actually a serious problem.  A very serious problem. It means with a casual query of AD (very simple for any user to do) I can guess some of the critical account names and intentially lock them and disrupt business processes.  This is kind of like that guy in the new All State commercials with the band-aid on his face going around causing problems like Mr. Murphy himself.  Option 2 above helps mitigate this vulnerability from being exploited and hitting your sensitive operations accounts.

Option 3 not only mitigates a sneaky prank attack like that described above, but it also removes the need to monkey with stupid passwords.  I mean - seriously - this is 2010 and we're STILL having to stop everything to change passwords - modify scheduled jobs - edit config files and DSN's - fix Dr. Asswipe's PHd hard-coded stupid-ass application (the guy in accounting who insists on writing his own apps and smokes a pipe, you know the guy), and STILL get any work done?  Seriously?!  We've gone NOWHERE.  Our forefathers would be crying in their colonial beer mugs.

Can You Spot the Difference?

I've had some IT folks swear that there is no functional difference whatsoever between these two.  No, I am not referring to the date stamp values (created/modified/accessed).  I can say with confidence that I have seen this little difference cause SCCM packages to fail, Group Policy deployments to fail, logon and startup script installations fail, and cause my morning to fail.  I strongly recommend clearing that little button before sending your file into the Cuisinart® also known as "the network environment".

Happy TSA Friday!

Note:  If you look back in not-too-distant history, you'll find plenty of examples where someone ended a safety study into a particular food additive, or a particular experimental drug, giving it a surprisingly unsubstantiated approval, and then suddenly takes a high-profile job within the company making those products.  It's happened at the FDA many times.  It's happened with the FAA, the NIH, the DOE, and it's practically a daily occurrence within the DoD.  And in every case: the news ignores it.  Nobody hears about it. Nobody cares.

And now it happens again with Michael Chertoff, and again: nobody (aside from Ron Paul) seems to care?  We are the dumbest fucking idiots on this planet.  We feed our kids shit that hasn't been thoroughly tested by people only looking to get a new job and bigger salary.  We hand our elderly and our babies medicines which have not been thoroughly tested, or worse: have been proven to cause known problems but are suppressed from public awareness, simply to allow some inspector or director to take a job at the pharmaceutical firm for a big raise.  Wake up!  Stop taking this shit at face value!  You have a brain.  Use it.

The Achilles Heals of Technology

We’ve definitely come a long way.  Enormous strides, year over year.  But some pains remain in our way of getting to the ideal operational efficiencies:

Allocation – It’s still hit-or-miss with so many variant species of installers.  Some products throw components on a computer like a blind drunk person with a shotgun having a spastic seizure.  The CoApp project is probably the best idea to come along since the dawn of Windows.  Sadly, it will probably be ignored by Microsoft. (yes, I know it’s derived from Linux and open source, shadddup!)

Permissions – There’s still too many stupid-ass vendors making crappy products that “require” the users to have Administrator rights.  HIRE NEW PROGRAMMERS you idiots!!  It’s not that friggin hard.  Lock yer shit down!

Licensing – I can’t even count how many variations vendors use today for controlling where their products can be installed and used.  License files.  Registry keys.  Services.  Hardware “dongles”.  Static keys.  Derived keys.  Concurrent acknowledgement services (think FlexLM and FlexNet) and on and on.  If only there were a real “standard”.

Isolation – App-V, ThinApp, XenApp, SVS, etc. are all fantastic ideas.  Where the **** are they?  Yes, I know they’re “available”, but so is medication for dying children in the poorest of places.  The problem is (a) it’s too expensive, (b) difficult to deploy, and (c) still too complex to manage for the laymen of the world. Until this technology is bundled into the core OS products, we will have to suffer with DLL conflicts, shared services, side-by-side assembly caching, versioning, re-basing, redirection and bullshit packaging hacks.  Come on.  This is 2010, right?

Layers – It’s still too friggin complicated to use MDT or OSD or SysPrep or imagex or whatever to build and deploy large numbers of computers in an automated fashion.  Drivers are a pain in the ass.  Custom tweaks are still cumbersome.  Task sequences are nice but still quirky.  The whole process needs to be thought through from scratch and simplified.

Let’s play “Guess WTF?”!

Why would I set this network to use the following User Account Control (UAC) configuration?  What are two good reasons for doing this?

If nobody guesses or makes crude comments and tasteless jokes, then I will have to step in and take care of the dirty work myself.  Hey, it is Friday after all.

Software Packaging Tip: Adjusting Permissions

If you work within an environment where “users” are actually “users” and not Administrators of their computers, you will likely run into situations where some applications won’t function properly because the user doesn’t have permissions to modify the contents of certain folders or registry keys and values.

There are two basic tools for handling this and they’re both free and very easy to use, whether you prefer Wise, InstallShield, or good old fashioned scripting:

CACLS.exe (for files and folders)

REGINI.exe (for registry keys)

I won’t bother going into a lot of detail on these, because there’s tons of info already on the web for both of them, but they work and they work well.

In Wise, for example, you can edit your package to add a “Custom Action” to invoke either command.  CACLS is much easier to use because you just need to specify the file or folder you wish to modify, and then specify who gets what permissions to it. 

Example:

CACLS <path> <options> <user/group>:<permission>

CACLS “c:\acme” /T /E /C /G Users:C

The example above grants members of the local group “Users” the “Change” permission to C:\ACME and all sub-folders and files beneath it.  Keep in mind that if you need to specify a group name that has spaces in it, you need to wrap the name in double-quote (as shown below):

CACLS “c:\acme” /T /E /C /G “Domain Users”:C

There’s a good reference for this command at http://ss64.com/nt/cacls.html

REGINI on the other hand expects a file to be specified as the input to dictate which registry keys get what permissions.  Thankfully, with REGINI in particular, you can wrap all of it inside a script that writes its own input file.  With Wise you can then use the “Execute VBScript from Embedded” and wrap the .VBS file into the package itself.

Example:

regFile = “c:\windows\temp\reg.txt”
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set f = fso.OpenTextFile(regFile, 2, True)
f.WriteLine “HKEY_LOCAL_MACHINE\Software\ACME [1 5 7 11 17]”
f.Close
Set oShell = CreateObject("WScript.Shell")
oShell.Run "regini " & regFile, 8, true
f.Delete

This little bit of script creates the input file “reg.txt” in the TEMP folder beneath C:\WINDOWS, then uses the shell object to run REGINI.exe with the file input.  When it’s finished, it deletes the input file.  I adapted it from http://support.microsoft.com/?kbid=237607  so I can’t claim original authorship.  That other version is nice because they use the GetTempName method to generate a random filename instead of a static name, but that’s just fascinating for people with no life, like myself.

You can also do this very simply with a .BAT or .CMD script…

@echo off
echo HKEY_LOCAL_MACHINE\Software\ACME [1 5 7 11 17] >%temp%\reg.txt
regini %temp%\reg.txt

The point is: you have options. And “free” options are always nice.

My final parting advice: NEVER give user administrative rights to their computers.  It’s an admission of failure.  Find out what specific things need to be opened up and do it selectively, and carefully.  If you don’t have time to do that, do you have time to mop up the mess they create from installing a dozen shareware applications, two dozen worms, trojans and viruses (or virii?)?  Saving time now may end up costing you five times that later.  When users bitch and moan (that’s what they do best, right?) push back.  Demand that they identify WHY they absolutely need admin rights.  Find out what things they need to modify, and WHY and then work from there.  Don’t just give them the keys and let them go.  That’s insane.  This method works fine. I do it all the time and so do hundreds of other IT folks.

Meet the New Boss: Same as the Old Boss?

I love how people open their mouths to swallow anything and everything "their party" shovels into it. They close their jaw, chew on it for a while, swallow hard, and smile with joy, maybe even begging for more shovels of shit to swallow.

So a few years ago, the Bush administration was hauled out into a tomato bashing over the AT&T eavesdropping discovery. All the left-wing nutballs went into orgasmic spasms about how the right-wing nutballs were playing big brother and invading our privacy. The NSA and FBI were lambasted but ultimately it was laid at the doorstep of the administration's zeal over post 9-11 paranoia.

Today the news is about the Obama administration pushing for new measures to make it easier for government to implement "Internet wiretaps" to eavesdrop on cell phones (even Blackberries), email, instant messages, etc. So far, not a peep from the left-wing crowd. All is good. It seems it's not what is being done, but who is doing it. It seems that the entire Federal government is now vastly, HUGELY, more trustworthy and ethical since a new figurehead arrived in town. Wow!  I’m picturing that scene from Blazing Saddles.

What a smokescreen.  Politics is nothing more than a game of shiny objects to distract the idiots from realizing they’re being fisted.  There’s nothing new here.  Same story, different faces doing the talking.

Swiss Cheese Security

Which of these network environments is safest from malicious damage?

Site A:
- web mail sites are blocked
- social networking sites are blocked
- cd/dvd-rw drives are not controlled
- usb devices are not blocked or encrypted

Site B:
- web mail sites are not blocked
- social networking sites are not blocked
- cd/dvd-rw devices are automatically encrypted or blocked (if not encrypted)
- usb devices are automatically encrypted or blocked (if not encrypted)

Ok, and for added entertainment, see if you can pronounce the title of this article out loud ten times as fast as you possibly can (without screwing it up).

Reset Administrator Password on all Domain Computers

There are a lot of ways to do this.  There are free utilities, retail products, and scripts galore, but there’s also a dirt-simple and effective way:

1. Create a shared folder on a domain member server (domain controller, file server, doesn’t matter)
2. Restrict permissions on the folder and share so that ONLY the “Domain Computers” group has READ access.  Grant the “Domain Admins” group full control.
3. Create a .BAT script with the code below and save it in the shared folder as “adminpwd.bat”
4. Using Group Policy, assign a “startup script” to point to the UNC path and script filename, link it to the appropriate OUs in Active Directory.  (I strongly suggest using a new test OU and move just a few computers into it to test at first)
5. Reboot your computers and verify the change is executed.

@echo off
net user administrator <new_password>

(where “<new_password>” is replaced with the actual password)

Bonus:

• Create another shared folder called “Logs” or whatever and configure it so that Domain Admins have full control and “Domain Computers” have Change/Modify on NTFS and share permissions



• Add a second line to the .BAT file to write a log file using a redirect (see below) to the shared “logs” folder.  Then you can watch the progress pile up in one place.

@echo off 
net user administrator <new_password> 
echo Password updated >\\servername\logs\%computer%.txt