Separated at Birth?

Elena Kagan or Kevin James.  Ask yourself this: Have you ever seen both of them in the same place at the same time?  I didn't think so.

Reset all Local Admin Passwords: The Even-Easier Way

This post will cover another, easy, SUPER-easy, and FREE way to automatically reset the local "Administrator" password on multiple computers in your domain.  This assumes you have at least one Windows Server 2008 domain controller, and at least Windows Vista or Windows 7 clients. 

Even if you still have a Windows Server 2003 AD environment, you only need one 2008 domain controller.  This tutorial is aimed at Windows 7 clients only.  It can be easily adapated to work with Windows XP and Vista clients.  Remember that you need to deploy the (free) Group Policy Preference Client Side Extensions for Windows XP (KB943729), or the Group Policy Preference Client Side Extensions for Windows Vista (KB943729), since it only comes with Vista SP1, and Windows 7.

If you need the Extension for Windows XP 64-bit, click here.

Ingredients:

• Windows Server 2008 Active Directory Domain Controller
• Windows Vista or Windows 7 clients
• A Group Policy Object
• A .BAT script file
• A cup of coffee and a snack
• Some cool tunes in your headphones

Let's get started…

First, create a new Group Policy Object from within the Group Policy Management Console (GPMC).  Name it something like "Local Scheduled Tasks", if you plan on managing scheduled tasks in one bucket.  Otherwise, you can name it something like "Reset Local Admin Pwd" or whatever.  The choice is yours. Relish the freedom.

Right-click the new GPO and select "Edit".

Create the Scheduled Task

Navigate to: Computer Configuration / Preferences / Control Panel Settings / Scheduled Tasks.  Right-click on "Scheduled Tasks" and choose "New --> Scheduled Task (Windows Vista and Later)"

New Scheduled Task (Windows Vista and Later)

Note the Action, Security Options, and "Configure For" settings.

Set the Trigger

I'm using the "startup" trigger.  You can assign a typical schedule as well (hourly, daily, weekly, monthly, etc.) if you prefer.

Actions

The nice part of this is that it doesn't matter if you have created the .bat file yet or not.  You can enter the path and name and then create it, or create it and then configure the scheduled task.  Either way works.  Since the task is more involved than the script, I started with that first.

The Script

The "local_admin_pwd_set.bat" file itself only needs the following code…

@echo off net user administrator <your_password_here> echo Password has been reset >%windir%\temp\adminpwd.set

Note: Line 3 is optional.  I just added that so it creates a log file on the client to help troubleshoot when the script last ran.  Be sure to replace "<your_password_here>" with something clever and difficult to hack.  The coolest aspect is that when you need to change the password on all the computer, just edit this script, save it, and reboot the computers (or wait for the scheduled task, if you chose that route).

Save the .bat file into a (hidden) shared folder.  Grant permissions on the shared folder (NTFS and Share-level) to allow "Domain Computers" to have Read access.  Grant "Domain Admins" Full Control.  Remove "Everyone" and "Users" and "Authenticated Users".

Click "Apply" and "OK".  That's it.

Putting it to Work

Now, if you named the file correctly, and saved it in the appropriate UNC shared folder path, and you applied the correct permissions to it, the next step is to link the GPO to a test OU.

Create a test OU in Active Directory Users and Computers (ADUC).  Move a test computer account into the new OU.  Link the GPO to the new OU.  Wait a few minutes, then restart the test computer and look for the log file to be created afterwards.  Verify the change by logging on in Safe Mode (if the Administrator account is still disabled, as it is by default).

What Can Go Wrong?

• If you use the local "Builtin\System" account to run the task, but forget to grant the "Domain Computers" group read-only permissions to where the .bat file is shared, it won't execute.
• If you leave the "Everyone" group, or "Users" or "Authenticated Users" or anyone besides "Domain Admins" in the permissions set for the shared folder, you may be exposing the password.
• If you have a policy setting in place that enforces password complexity and you attempt to set a password that doesn't comply, it won't work.
• If your users rarely restart their computers, you may want to try another method of running the task such as a recurring schedule, or upon login, etc.
• If the computers are off the network a lot (think laptops), you may want to consider another approach.
• If users are members (direct or indirect) of the local "Administrators" group, they can subvert this and even gain access to the .bat script with very little effort.  DON'T make users into Administrators of their computers!

Final Thoughts

This is not the only way to accomplish this goal.  There are many others.  I've explained a few others previously (on this blog).  You can find shareware and retail products to do this.  You have options.  But, you are not required to spend money to make this work.  For added security, consider wrapping the .bat script command into something more protected, like a compiled .exe, or a tokenized KiXtart script file, even an encoded VBScript or PowerShell file.  Have at it.  Have fun.

Windows Live Writer 14.0.8089.726 Sucks

Yes, it's getting better with each release and update.  Is it "there" yet?  No.  Why does a blog authoring tool have to be so frigging over-bloated for such a simple task?

The Korean War

Growing up in a, no, scratch that, THE most military-oriented location on the planet Earth, period, I have come to know people from every branch of the armed forces, Air Force, Army, Marines, Navy, the Coast Guard, the CIA and NSA and so on.  I won't go into how much I appreciate and respect them and their diligence, as well the sacrifices their families endure, but with all the focus on remembering the Korean War (re: Korean "Conflict"), it made me stop and think back a bit.  This came into greater focus as I drove past the V.A. hospital where my father worked for 33 years and where I spent a LOT of my childhood.  I met more of his patients than I can ever count.  Amazing people.  It had a profound impact on me growing up.

A lot of my friends in Jr. High and High School had parents who were combat veterans of the Korean War, and the Vietnam Conflict.  I emphasize "combat" because there's a huge difference between being a veteran and being a combat veteran.  Some of them had a father imprisoned in Hanoi and I was at one of their homes when they got the phone call that daddy was on a flight heading home.  Talk about being ecstatic.  It was incredible.  I've also been at a home when they got the bad phone call.  I've known people who lost family members, friends, relatives, school mates, etc. in both wars.  I've sat at kitchen tables and listened to some of the dads recount stories also; usually sanitized for my young ears to grasp without freaking out and jumping from a bridge in panic.

But sometimes they would drink just enough to forego the sanitization and just spill their guts.  Sometimes it was general stuff.  Sometimes it was specific, often graphic. Rarely were they funny or light-hearted (there were a few).  But thinking back over the stories I was privy to, none were as bleak, drab, depressing and horrific as the Korean War stories.  I'm not trying to compare or rate them in any way, and I'm obviously only capable of commenting on a small segment of people, but whatever.  I don't claim to be an expert either.  I'm just recalling what I heard and for whatever reason I felt like posting it.

They call it "the Forgotten War" and it should be obvious why.  You rarely hear of it except when there's an anniversary or when a recent event occurs between the North and South.  As much as we've seen effort put into opening up the discussion on post-Vietnam trauma, and post-Gulf War trauma, nothing like that was ever put forth for those that came home from Korea.  They came home to silence.  No protests, no parades.  Nothing.  And those people have quietly tried to deal with that ever since.  I can't imagine the stress they've bottled up.  If you know someone that fought in that conflict, talk to them.

If Offices Were Run Like Construction Sites

After years of working in construction, then college, followed by office-oriented jobs, I've come to realize some interesting comparisons.

• Leaving an empty water jug in the dispenser would be punishable by wedgy
• Leaving 0.5 cups of coffee in the pot and walking away would be punishable by urinating in your cup
• Standing outside taking a smoke break would be punishable by a face smack
• Taking three smoke breaks?  Three face smacks
• Walking off when your lunch is finished in the microwave:  Free lunch for anyone standing nearby
• Whining about the lighting: circle up the coworkers to perform synchronized laughing
• Complaining about being tired: Send employee outside to dig a 100ft long trench, 3 feet deep (no changing clothes either)
• Complaining about parking so far away: Move parking space back 10 spaces for every complaint spoken
• Taking the elevator when you really don't have an excuse: 20 push-ups in the parking lot
• Scheduling more than one meeting per week:  20 push-ups in the parking lot

Putting Round Pegs into Square Holes: Software Project Estimation

Bean counters and programmers

No, it's not a new song by Stone Temple Pilots.  It's a dilemna that puts two diametrically opposed brain chunks in direct contact with one-another, and it rarely turns out well.  Rarely.  I won't say "never", but it's as close to "never" as calculating the Limit as X approaches zero (remember that crap from high school Calculus?).

Why is it such a problem?

Here's why:

Bean Counters work with metrics.  Things that can be defined, bounded, measured and compared.  Units take X amount of time to complete, so Y quantity of X will require Z amount of time to complete.  Easy.  Relatively speaking.  Metric assessments and metric-based forecasting are square holes.

Programmers with in the ethereal.  Solving problems incrementally.  First is the BIG problem (the project or over-arching task).  Then comes the next layer down, which is choosing a platform, language, medium, etc.  Then comes the next layer down, which is choosing the resources and identifying availability. Then comes the (gulp!) architecture and design phase, which, let's face it: is bordering on the "artistic" side more than the technical side.  Then comes the execution phase: writing code, and alpha testing it.  Then comes the beta testing or dog-fooding phase.  Then comes the public or customer test phase.  Reading back through this paragraph, it might become clear that few of these are "well defined" or "bounded" units of anything.  Even worse: they tend to degrade into less-defined entities with barely any bounds at all, as you approach the point of completion.

Skittles-eating, Mountain Dew swilling, Hot Pockets chomping, video game cranking programmers are the round pegs.  Even worse: they're not even round, not even elliptical, but more of a blob.

Sure, there are books and articles and whitepapers galore, which attempt to apply mathematical concepts to herd this whild team of blind three-legged cats into a lock-step battallion of uniform-wearing solders of productivity.  Clever, huh?  I have my moments (usually after a strong cup of coffee or beer).  It's bullshit.  Pure bullshit.  I've studied a wide-ranging smattering of CMMI and SDLC and ITIL framework subject matter, but almost all of it takes the same view of programming as bean counters take.  The point of failure in all of these is HUMANS.  HUMANS are not well-defined units of anything.  You can measure biometrics and physical aspects of humans, but measureing potential output is damn near impossible.  However….

What works best?  Humans.

The best tool for assessing potential human output is another human.  But that other human must possess two crucial characteristics in order for this to work at all:

1. Experience with the task environment
2. Familiarity with the Human being assessed

Experience is a must.  You have to really understand a significant depth of the project, the tasks, the platforms, the languages, the technologies in which the project will operate and the user environment (you know: the folks that will do their absolute best to break your final product).

Familiarity is the catalyst.  The human who assesses the potential of programmers has to know those programmers very well.  Beyond their ability to answer on-the-spot interview questions like "what would you do if…" or "what's wrong with this piece of program code?", you have to know their personal habits.  Do they shoot the shit all day?  Do they make a lot of mistakes and how do they recover from them?  Do they attempt to recover or blame something else?  Are they a team player?  Do they disrupt others?  Are they a poison pill to the team?  Do they foster cohesion and mentor others?  Are they leaned upon to mentor others (taking away time they have to do their own work)?

Familiarity is damn near impossible to spin-up on demand.  It's not a surge-capacity reactive capability.  You can't just grab a MBA with PMP and CMMI certs and plug them into an existing team and expect them to shit out accurate estimates.  It's not going to happen.  It takes time.

All of the literature I've read from the various process certification groups barely touches on this.  It mentions it, but then moves on to the next metric assessment, like missing a few blades of grass when mowing the lawn.

If you're involved in a software-based start-up, you should insist that the project management team includes at least one person who is familiar with at least a majority of the key developers on the project.  If they really want the project to succeed they will only be too happy to oblige.  If they scoff at this then they're not really looking at long-term success, but simply short-term gain.

Humans.  Experience.  Familiarity.

I've Had Better Days Driving Home

Driving home usually takes me 35 minutes from office parking lot to my driveway.  Today it took an hour and 5 minutes.  I spent 40 minutes standing perfectly still.  Engine off.  Basking in the 100 F "breeze" on the bridge.  Couldn't run the A/C because I was low on gas.

Planning on a Napkin

I've been writing software since the mid 1980's.  I actually started writing code to ease the pain of using someone else's crappy code forced upon us at work by clueless management.

It wasn't until years later that I would go to college and get a formal education and grounding on SDLC concepts, languages, parsing, compilation, refactoring, modularity and OOP stuff.  But along the way I picked up some street smarts (as if nerds really hang out on streets.  you know: outdoors.  where the sun actually shines and people might burn or get eaten by wild animals or something) and it occurred to me during a recent conversation that one habit I've stuck with has never failed me:

Doodle your application designs on paper, with a real pencil.

Don't get any closer to a computer (of any kind) than 50 feet.  Nothing but paper and pencil.  Everything.  ER diagrams, workflows, forms and UI's, APIs and hooks, interface vectors, all of it.  You'll absolutely crumple some paper and build a pile of stupid ideas around the waste basket (after all: nerds are horrible basketball players).  The bigger or more complicated the task, the better this works.  N-Tier client/server apps, web services, desktop apps, mobile apps, API frameworks, web applications, infrastructure automation services, you name it.  Paper and pencil.

This isn't radically new, and it's not even my own idea.  It's been discussed for years, and for good reason: IT WORKS.  There are many examples which discuss aspects such as UI design, overall design approach, templates for specific design aspects, 18 great examples of sketched UI wireframes, and dozens more.  If you typically go from thought to keyboard, try this approach instead.  You might be pleasantly surprised.

Paper and Pencil.

Don't write a word of code on a computer until you've ironed out everything on paper first.  At least a few hours, if not a day, even several days.  After you've worked out the mental challenges, then the modeling challenges, then the material challenges, then the UI design, then the security model, then the data flows, then the bathroom (you will need a bathroom break for sure), then lunch (or dinner), then transfer it to the computer, carefully.

Paper and Pencil.  Try it.

Neat-O Windows Admin Tricks: Automating a Help Desk Web Form

Scenario:

Within your Microsoft Windows Active Directory network environment, you have an intranet web site.  That web site serves up a Help Desk web page for users/customers/losers/idiots/crackheads/ to use for requesting things.  It has a form to fill-out, and when they submit the form, it generates an e-mail or stores the info in a database table (and sends an e-mail), etc. whatever.  But the form has a text box for the user to manually type in the name of their computer and their user name and other general contact info.  You'd really like to have that general contact info, and the computer name info, automatically filled in, so that users/losers don't enter stupid or incorrect information.

What to Do:

This scenario involves two (2) general issues that need to be addressed.  Each of these issues can be addressed in a variety of ways.  I'm only covering one (1) way to address each.

Part 1 - Automating the User Contact information

User information is typically stored in Active Directory.  If you (or whomever) did their job properly, each user account object should have all the pertinent information entered, such as e-mail address, phone number, department, first and last name, location info, etc.  AD information is stored and shared via LDAP and ADSI.  You can leverage built-in LDAP and ADSI features within ASP (or pretty much any COM or .NET scripting platform) to access that information.  An ASP web application can use the following code to query Active Directory for user account information.

The catch?  You have to make sure you enable "Integrated" authentication for your intranet web site in order to capture the user account name in the background.  This is silent and automatic if the visitor's use Internet Explorer.  Otherwise, they will be prompted to provide their domain credentials before accessing the web page (username and password).  I will explain the code shown below just below that.

<% Function UserName() Dim tmp, domain : domain = "mydomain" If Session("username") <> "" Then UserName = Session("username") Else tmp = Trim(Request.ServerVariables("REMOTE_USER")) If tmp <> "" Then Session("username") = Ucase(Mid(tmp, Len(domain)+2)) UserName = Session("username") Else UserName = "" End If End If End Function %>

Part 2 - Automating the Computer Name information

This is only a tiny bit more complicated, but still pretty easy.  Because capturing the visitor's computer name is not nearly as straightforward, you have to try alternate methods.  One method is to capture the remote IP address, and perform some sort of background lookup to find the computer name.  Messy.  Ugly.  Painful.  Another method is a bit more circuitous, but it works very well: create a desktop (or start menu) shortcut which contains the computer name in the URL parameters.  Consider the following URL which would be requested from a shortcut on the desktop of a user working on computer named "Computer123":

URL: http:// intranet/helpdesk/helpform.asp?cn=Computer123

The small catch here is that you will need to make sure your web form can read the "cn=" parameter and transfer the assigned value (e.g. "Computer123") into the form edit box.  If your web form is ASP or ASP.NET, this is very simple to enable.  The example below shows how to capture this value with an ASP web page:

helpform.asp

<% cn = Trim(Request.QueryString("cn"))%> <html> <head> <title>Help Desk Request Form</title> </head> <body> <h1>Help Desk Request Form</h1> <form id="user" method="post" name="form1" action="request.asp"> Your Name: <input type="text" name="user" size="20" value="<%=UserName()%>"/> <br/> Computer: <input type="text" name="comp" size="30" value="<%=cn%>"/> <br/> Details:<br/> <textarea name="details" cols="55" rows="8"></textarea> <br/> <input value="Submit" type="submit" name="btnSubmit"/> <input value="Reset" type="reset" name="btnReset"/> </form> </body> </html>

There are many "easy" ways to create shortcuts, but they usually come down to using the Wscript.Shell object.  If you want/need to deploy a shortcut to a large number of desktops, you may want to consider scripting it.  You can "blast" out the change by running a script from your desktop or from a server, etc.  Or you can make it part of your login script, or deploy it as a package via Group Policy or SMS, SCCM, Altiris, etc.  Whichever way you deploy it doesn't really matter.  You should be able to automate the capturing of the computer name and use that to concatenate a URL text string to use for creating the shortcut target value.  The examples below show how you can do this within a login script (both VBScript and KiXtart flavors are shown).

Which way (script language, utility, etc.) you choose to go doesn't matter as long as it works.  Once you fetch the computer name, you can take that and concatenate the URL string and make the shortcut for the user to click on to access the Help Desk web form.  The script code below will create a shortcut on the user's desktop using the URL example above.

login.vbs

Function ComputerName() Dim objShell Set objShell = Wscript.CreateObject("Wscript.Shell") ComputerName = objShell.ExpandEnvironmentStrings("%computername%") End Function url = "http:// intranet/helpdesk/helpform.asp?cn=" & _ ComputerName() cap = "Help Desk Request Form" Set wshShell = CreateObject("Wscript.Shell") Set objFSO = CreateObject("Scripting.FileSystemObject") strPath = wshShell.SpecialFolders("Desktop") scPath = strPath & "\" & cap & ".url" If objFSO.FileExists(scPath) = False Then Set objShortcutURL = wshShell.CreateShortcut(scPath) objShortcutURL.TargetPath = url objShortcutURL.Save Set objShortcutURL = Nothing End If

 

login.kix

$url = "http:// intranet/helpdesk/helpform?cn="+@wksta $cap = "Help Desk Request Form" $wshShell = CreateObject("Wscript.Shell") $strPath = $wshShell.SpecialFolders("Desktop") $scPath = $strpath+"\"+$cap+".url" if exist($scPath) = 0 $objShortcutURL = $wshShell.CreateShortcut($scPath) $objShortcutURL.TargetPath = $url $objShortcutURL.Save() $objShortcutURL = 0 endif

Putting it All Together

Duct tape, Elmer's Glue, staples, chewing gum, rubber bands… ok, you should now have a "helpform.asp" file sitting on your web server and shared from an IIS site on the server which has integrated authentication configured (do not enable any other authentication options).  Then you would have either a "login.vbs" or "login.kix" login script file.  Target that using Group Policy or simply send a link to the script to one of your test users (aka minion guinea pigs) to test out.  The script should be executed under the user context, not the system context, so it can grab the user information and computer information as well.

Now, when a user logs on, it will create a shortcut on their desktop to "Help Desk Request Form" which contains the URL shown in RED above (except with their actual computer name filled in, instead of "Computer123").

When the user launches the shortcut, it requests the URL along with the computer name.  The ASP form reads the "cn=" parameter to fetch the computer name.  The ASP form also uses the ServerVariables collection to fetch the user account name.  You can modify the **** out of this to suit your needs/whims, etc.  Read the following disclaimer however. – Cheers!

IMPORTANT DISCLAIMER:

Test this in an isolated NON-PRODUCTION environment before attempting to use it in a real production environment.  There is no warranty or guarantee of ANY KIND WHATSOEVER provided for this information, either explicitly or implicitly.  I assume no responsibility or liabilities for any stupid shit dumbass crap, loss of data, downtime, anger, resentment, hostility, depression, angst, mood swings, etc., that may occur as a result of what happens if you don't test it thoroughly before letting it lose on your network.

Is XML "Better" than TXT?

I'm sure there are other articles that discuss and explain this topic, but I searched Google and couldn't find any that hit the nail on the head the way I wanted it hit. 

So if this is old hat for you, I apologize, but you can always move on and read something else (http://www.peopleofwalmart.com) if you prefer.

 

So, the question is: "Is XML better than TXT?"

The short answer is: NO.

The long answer is: IT DEPENDS.

XML, or extensible mark-up language, is a tag-based format for presenting textual information.  XML files can be created on one system and used or "consumed" by a completely different system, since the syntax and structure are fairly well defined and understood.  This is not to say there isn't any ambiguity about HOW you employ XML, there most certainly is.  The science of XML is pretty straightforward.  The art of XML is not.  There is a huge amount of potential variation in how you can put XML to work just within the context of the file or "stream" structure itself.  Elements versus Attributes, for example, and to what extent you mix the use of them proportionally.

But what about the 10,000 foot view?  When does it make more sense to use traditional TXT formatting instead of the newer XML tag formatting?  Consider the following example:

Scenario 1:

You need to export a list of user accounts from a computer system and import it into a database which resides on a different network entirely.  The only information you need to collect is the user ID (aka "username") and the "full name" of the user.  Due to various environmental and procedural factors, you must transport the information by file, no direct stream or socket connection is permitted.  You must export the information, save it to a file, copy the file to storage media, and transport the media to the remote system for import.

Digression 1:

You could do this with XML in several ways.  You could do this with TXT in a few ways also, but the most common ways are either comma-separated value format (CSV) or tab-delimited format.  You could also employ a standard INI format, but I've left that out of this discussion (for now, maybe another future discussion).  Here's a few examples...

Option A - XML Elements

<useraccounts>
  <useraccount>
    <userid>412553</userid>
    <fullname>John Doe</fullname>
  </useraccount>
  <useraccount>
    <userid>555010</userid>
    <fullname>Susan Jones</fullname>
  </useraccount>
</useraccounts>

Option B - XML Elements with Attributes

<useraccounts>
  <useraccount userid="412553" fullname="John Doe"/>
  <useraccount userid="555010" fullname="Susan Jones"/>
</useraccounts>

Option C - Plain Old TXT, CSV format

412553,John Doe
555010,Susan Jones

It should be pretty obvious in this scenario that option C is the most compact, and therefore requires the least overhead (storage, transport, time, etc) to use.  But this is only one scenario.

But something else to consider is the overhead of "consuming" this data on the receiving end.  In most cases, you must rely upon a special API for validating, parsing and extracting information from within XML streams and files.  On a Windows computer, this usually involves something like .NET, the MSXML API, or XMLHTTPRequest or something like that.  A TXT file however, requires much more meager resources to reach into files, such as the FileSystemObject object within the WSH API.  The net effect of resource consumption is insignificant on small files or small numbers of files, but when you're parsing milllions or billions of them at a time, for long periods, the overhead can add up to something to keep an eye on.

Scenario 2:

Same basic operation, but now you need to gather quite a few more pieces of information for each user account. Now you've been asked to get information such as company, department, phone numbers, email addresses, job title, manager name, group memberships, and so on.

Digression 2:

I will go ahead and say that in this scenario, it might make more sense to use an XML format, with a mix of elements and attributes.  The reason is that you can tie collection-based information together much more "logically" with XML tag nesting and attributes than you can with "flat" text structures.  Consider the following:

Option A - XML Elements and Attributes

<useraccounts>
  <useraccount id="412553">
    <fullname>John Doe</fullname>
    <department>Administration</department>
    ... (more elements)...
    <groups>
      <group name="Domain Users"/>
      <group name="Corp Admin"/>
      <group name="Project Managers"/>
    </groups>
  </useraccount>
  <useraccount id="555010">
    <fullname>Susan Jones</fullname>
    <department>Sales</department>
    ... (more elements) ...
    <groups>
      <group name="Domain Users"/>
      <group name="Corp Sales"/>
    </groups>
  </useraccount>
</useraccounts>

Option B - TXT / CSV format

412553,John Doe,Administration,GROUPS=Domain Users+Corp Admin+Project Managers
555010,Susan Jones,Sales,GROUPS=Domain Users+Corp Sales

Breaking it Down - This is a bit deceiving.  While the TXT option looks more compact, it will become a friggin mess once the list of group memberships gets to be large or the group names are long.  In addition, you will lose ground in the resource overhead battle once you start having to sub-parse each line and break out the groups and check for special/odd characters in the group names. I chose an arbitrary syntax obviously.  You could devise any one of an infinite possible ways to format your user accounts within the TXT realm.  However, the payoff comes when you can leverage the XML tools at hand to quickly extract the groups collection from each user.

What if the platform on which you export this data is Windows, but the platform on which it will be imported is UNIX or AIX or Linux or whatever?  You can't count on being able to quickly setup a process for understanding a custom one-off TXT structure/syntax when you don't know it in advance, or you have to be able to accept it from hundreds of remote and inconsistent platform environments.  As the consumer, you tell the folks providing the data that it must be in a particular format, correct?  I hope so.  After decades of struggling to establish standards, not only within a common organization (employer, government agency, etc.) but between organizations (customer vs supplier, government vs private sector, etc.) the appeal and affordability of XML should be obvious.

Conclusion

So, again, I repeat myself: XML is better in some cases.  TXT is better in some cases.  If the data is not very verbose or complicated, and can be presented well using a "flat" structure, then a TXT format may work very well.  If the data is verbose, interrelated with nesting or sub-groups, it may work best within an XML structure.  There are a million variables to factor into almost any project or task which involves moving information between disperate environments.  The point is to never knee-jerk and just do everything one way.  Look at each situation, size it up, and make your decision based on the facts and your best judgement.

Way Too Familiar

I'm So Tired of Half-Assed Work Passing as "Good"

Whether it's Facebook's constant gyrations that keep leaving bugs and quirks in every nook and cranny, or the CSS model, or Apple's iTunes and iPod devices, or Ford and GM automobiles, I'm just sick to death of everyone giving them a passing grade when there's so much bullshit.  We've become so accustomed to the bullshit level that we think it's normal now.  Cheap, thin, plastic dashboards with flimsy fixtures and awkward anti-ergonomic controls and indicators.  Inconsistent API models.  Devices that have predictable problems.  All of this shit we're just getting used to as being "OK".

It's NOT OK.

Folks: Hold these dipshit’s feet to the fire and DEMAND better results.  Our grandparents sure did.  They didn't buy cheap shit.  They wouldn’t stand for it.  That's why their stuff lasted.  You think anything you purchased in the past 5 years will last long enough to pass down to your kids or their kids?!  Hell no!  Maybe SOME furniture could qualify.  But none of the electronic junk we have now will last that long, and it's not even supposed to.  We know that.  Everyone knows that cellphones have a limited lifespan.  Cars have a limited lifespan.

Look, my grandfather drove his old Ford Galaxy to over 250,000 miles by just "taking care of it" rigorously.  He NEVER overhauled the engine or transmission.  It was built to last.  Same goes for one of my old neighbors and his 1953 Oldsmobile.  Some of those cars ended up in backyards with weeds growing around them, but they didn't rust out to nothing.

Yes, there have been some improvements like air bags, GPS, crumple zones, collapsable steering columns, radial tires, and so on.  But the overall product doesn't last as long.  It's disposable.  We're a disposable culture.  Everything is throw-away and we’re just fine with that.  But the unintended side-effect is that we’re also just fine with shoddy quality.  No, wait a minute, let me qualify that quantification gyration a bit:

It’s not that things are just shoddy.  They’re designed to be sufficient for a specific lifetime.  After that they fall apart.  You have to baby the hell out of most products to keep them in top shape even up to their expected point of death.  Beyond that and you have to adopt a whole new religious practice to keep it looking and working good.  Engineering is getting that granular folks.  Engineered lifespan is a valuable commodity in today’s industrialized markets.  This is especially true if the lifespan plays into a revenue model that ties in with some sort of overarching service (think cell phone features, iPod, digital cameras).

But getting back to my original thought, which is that in some respects there is shoddiness throughout the products and we’re just blind to it from overexposure.

Cases in point:

Facebook – The Notes feature is quirky as hell.  Create a “Draft” and save it, but don’t publish it.  Then leave it and try to get back to it.  You can’t.  Not unless you start another Note and cancel it, and THEN you get a link to “Drafts”.  How many ways can you get to parts of your personal profile?  Shouldn’t one be enough?

Twitter – I think it should just make the stupid whale image with the “oops, sorry, our shitty-ass crap-app is overloaded again – try later” as the default home page.  Everytime some lame-ass code-nerd tries to snob me with some bullshit pitch about Ruby being superior, I just point to Twitter and scream like Sam Kinison.

iPod Nano – PIECE OF SHIT.  Period.  I somehow ended up with five (5) of these f-ing pieces of trash.  All from different sources (two direct from Apple.com), and at different times.  They lock up constantly. The “shuffle” is as predictable as a political speech.  Apple gets a free handjob pass from the fanboy crowd because it’s hep to have anything with a Cupertino fruit symbol on it.

Live Messenger – Oh my God.  Forget the chat aspect, IF you can find the chat space behind all the cluttery over-bloated buttons and ads.  Move that shit out of the way and let me chat gd-it!

Apple Update – NO – I DO NOT WANT SAFARI ON MY WINDOWS DESKTOP!!!!!!  Stop shoving it in my face!!!

Symantec – Just please, put down the crack pipe and stop bloating out your code to death.  Soon it will require a Cray SMP with 40 terabytes of memory just to load your “Security” product suite.  The only way it makes a computer secure is by rendering it unresponsive, so even bad code can’t get a slice of that CPU.

Autodesk – Please, I beg you, listen to me for one second: there are many of us (you know, those people called “customers”) that (a) do not want to wait for WsCommCntrl.exe to stop hogging the CPU in order to get working in AutoCAD and get the boss off our backs, and (b) don’t have time or company policy allowance to participate in your Customer Improvement Program.  Let us TURN THAT SHIT OFF PERMANENTLY!  Stop burying it in places intended only to make it difficult to disable it.  It aggravates the shit out of us and it’s really tiresome.  If you want to know what we think, pick up the phone and call us.

Adobe – Really?  Seriously?!  Are you kidding?!  You charge HOW MUCH for Acrobat Professional?  Holy f-ing cow!  To make fancy PDF files.  I suppose you’re ok with charging $100 per square of toilet paper in your company restrooms too?  And why is PhotoShop so expensive?  Do you read?  People are actively looking for cheaper alternatives and they’re actually finding them.  I’d be worried if I were you.  Get real.  Drop your ridiculous pricing.

Google – Can you please put a consistent interface on your vast array of web products?  I mean, seriously.  How many engineers do you employ?  How much do you spend on the infamous cafeterias and daycares? Can you spare a few bucks to clean it up a bit?  Maybe get things out of “beta” in less than 5 years.

Microsoft – R2?  What’s that?  Windows 7, Windows Server 2008, IE9, Expression 4.  Hey, how about forming a committee to tackle the problem with version numbering?  Which is it: a number or a year?  And does every product really need 11 syllables?  System Center Operations Manager?  System Center Virtual Machine Manager?  Can we dispense with the “System Center” prefix?  And while you’re at it, how about cleaning up the mess your developers have made with things like MSXML service packs, and .NET updates?  IT folks are struggling to package and push that stuff to thousands of computers.  You could help us out a little.

Mobile Apps – Don’t tell me how “mobile” is going to overtake the desktop when your stinky mobile apps still don’t have all the features or options I have with the crusty old web desktop version. Facebook and Twitter for mobile devices still cuts your hands off when you need to do certain things.  Shouldn’t a mobile app be AT LEAST equal to it’s web counterpart?

And, speaking of AT LEAST: what happened to the idea that an “upgrade” should never take a step backwards?  Why do so many upgrades seem to quietly remove something we had in the previous version?

Let’s go back to making QUALITY code, ok?

This Week in the News (Slightly Moderated Version)

Cadmium-Tainted "Shrek" glasses at McDonalds (Collect them All!)
comment: those darn Chinese. Melamine is so passé. Cadmium is the new Lead.

"Furious" Obama, joins "Sullen" Obama and "Giddy" Obama (collect them all!
comment: yeah, he's going to single-handedly fix it all

Activists Vow to Continue Dying, Because They Have Nothing Better to Do
comment: if you walk into a fight, you might get hit

MLB Imperfectly Perfects it's Imperfections on Perfection?
comment: can you say "instant replay"?

The Lorena Bobbitt method might just work after all?
comment: snip snip

If at First You Don't Succeed, Rip em Off Again!
comment: forgive and forget, but don't forget to tithe on your way out

Test Your Broadband Service

The FCC is teamed with SamKnows to collect statistics from all ISP’s using customer membership data.  Find out more here: https://www.testmyisp.com/

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

Kicked in the Nuts: Many Borrowers Getting it from Both Sides

I must apologize in advance for this one.  I promised my next post would be positive, uplifting, maybe even jovial. But a “man in the street” segment on one of the lame-ass cable news channels ticked me off and I have to vent.  Next one will be more jovialistic.

Begin:

I've had it with the narrow-minded bullshit talk from economic “gurus” about homeowners defaulting because they either "overborrowed" or "couldn't afford" their house in the first place.

Hello?  Anyone out there still actually reading the news?

There is this thing called UNEMPLOYMENT.  That's right.  It's basically a tally of those folks who WERE working a steady job, but are now NOT working.  The VAST majority of that tally consists of persons who were laid off.  A HUGE portion of them were from downsizing.

So, using the rationale I hear from the suit-wearing pundits on Fox, MSNBC, CNBC and CNN, they are saying that those people should have known they were going to get axed and shouldn't have bought a house at all, or should have bought a $50,000 shack when they were pulling down a $100,000 income.  Yeah.  That makes sense.  We’re all just a bunch of idiots.  I mean after all, YOU obviously know when you're going to be downsized, right?  So, why did YOU buy that nice house or condo then?

In fact, I've actually seen this entire concept debunktified (my own word, you like it? ha ha) on CNBC and MSNBC and Fox.  Whenever they have a "panel of experts" on to blabber about how the economy tanked, and what needs to happen to "fix it", they invite the most flaky person to represent the homeowners.  Then they use them as the entertainment punching bag.  That person will TRY to suggest that maybe a lot of the borrowers didn't buy too much of a house for their income, or that they weren't late on their payments, but were just caught off-guard by a sudden lay-off.  And that a lot of those unlucky folks happen to live in places where there is NO other employment (think Michigan, Arizona, Tennessee) and so on. That person might as well walk into a redneck bar and ask if anyone wants to buy a Toyota pick-up and a CD of Kanye West to go with it.  They commence to mocking and verbal beating and all the brainwashed viewers cheer them on like it’s a football championship game.

I know quite a few people in this boat.  They were fine and doing well until they got downsized.  Now as they struggle to keep up on their mortgage, support their families, and pay their other bills, they get to enjoy the constant bombardment with insults, mockery, blame and harrassment, all focused on THEM being the cause of the problem.  "Yeah, Mr. Homeowner!  It's YOUR fault!  You should've known you were going to be axed, and you shoulda bought a cheaper house ahead of it!"

So, to all those "pundits" like Larry Kudlow, Squawk Box goons, and all you conservative financial gurus that smirk at the thought of someone NOT having a country club membership: F-OFF.