Shiny New AutoCAD, Same Old VLISP

I'm beyond the point of crying over the demise of Visual LISP.  A once-mighty development platform with an impressive following (and one-time unrivaled volume-king of content), now relegated to bleeding out on the scrap heap of soon-to-be forgotten languages.

When John Walker chose LISP as the core extensible language for AutoCAD, he did so on the basis of its inherent dynamic polymorphic nature.  Recursion and chameleon-like characteristics made it as fluid and flexible as a the T2 walking through the mental hospital metal bar gate (without the pistol, of course).

What Autodesk is ignoring is potential. There is and always has been potential within the Visual LISP world to grow the language as a standalone platform. It could be used for so much more than CAD purposes. Even DCL could join in on the ride beyond the walls of Fort AutoCAD.

Once unfamiliar programmers got used to working with lists and functions like mapcar, apply and lambda, who knows where it could lead?

Read More

Autodesk Product Feature Codes (FlexLM), versions 2010 to 2014

I had to look-up feature codes for Autodesk products to verify some of our FlexLM license files today and figured I'd share the fruits of my vegetating brain work.


Autodesk 2010: http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=13219652&linkID=12305695

Autodesk 2011: http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=15224763&linkID=13806469

Autodesk 2012: http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=17288427&linkID=9243099

Autodesk 2013: http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=18708301&linkID=9242258

Autodesk 2014: http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=21374698&linkID=12305695

Enjoy!

Read More

Biography Template - Male

Introduction

The purpose of this document is to provide a fill-in-the-blank form for creating a biographical write-up while keeping the reader interested and alert.  Just copy and paste the content below into your favorite text editor, and replace the FIRSTNAME, MIDDLENAME, and LASTNAME entries with yours, and you're ready to hand it to any prospective employer or government official.  It's that easy!

Let's Begin...

[INSERT PHOTO HERE] FIRSTNAME MIDDLENAME LASTNAME was born to parents Melvin Shanghai Sukimbo, from Cuba, and Shi-Shi Von Uteristein, from Afghanistan, while living in the small Italian village of Ombwata Kickbutti, on the Eastern shores of Chad.

At the age of two, FIRSTNAME learned to speak fourteen languages, and read and write six more.  Upon entering the first grade, he had mastered multivariate Calculus and factored all of the prime numbers, when he stayed home from school with a mild case of Herpes and Ebola.

By the time FIRSTNAME had entered Middle School, his family had to relocate to Australia to avoid his paternity suit with four Elementary School teachers and the assistant principal.  The suit was eventually dropped when the five plaintiffs mysteriously turned up in an old, rusty, solar-powered wood-chipper somewhere in the lawless gang-ruled neighborhoods of Ulaanbaatar, Mongolia.

Prior to graduating High School, FIRSTNAME earned a scholarship to John C. Holmes University, for his exceptional work curing Cancer, AIDS and his invention of Teflon-coated undergarments.  While studying for PhD thesis, FIRSTNAME co-founded the multi-billion dollar corporation Gasious Clay, manufacturing scent-controlled automated Halon systems for office restrooms.  He sold his interests in that company and spent the next few weeks studying to earn his IT certifications.  By the end of the month, he had earned MCP, MCSA, MSCE, MCSD, MCDST, MCITP, and MCT certifications.  

Within a week after his Bar Mitzvah, FIRSTNAME earned his Cisco CCNA and CCNE certifications. Before his 19th birthday, he won the IronMan competition in France, handily defeating the reigning world champion Moses Van Roidshot.   In fact, FIRSTNAME set a new record for lifting and carrying 500 lbs of concrete blocks across a 100 yard obstacle course, walking on his hands, with the weight suspended from his penis by braided steel cables.

At his next position as the Mexican Ambassador to Somalia, FIRSTNAME solved all of the same problems your company is just now having to deal with.  This makes him the perfect candidate for CEO of your organization, even if you currently do not have a position titled as "CEO". You could do a lot worse, and you always have.

Read More

How to Not Suck at Scripting, Part 1

I hear this ALL OF THE TIME from IT guys who have somehow not caught the script-writing bug: "I wish I knew how to write scripts". Usually it's followed by a deep breath, a sigh, and staring off either up into the ether, or down at the ground.  I'm here to tell you how you can find that bug, and make it bite you in the ass. This is Part 1 of a 2-part article.  This part will focus on the "why" aspects.  Part 2 will focus on the "what" and "how" aspects.

The Basic Basics

First off, before I get into the enumerated list, I have to explain what is this thing we call "script-writing" or "scripting".  A "program" or "application" generally implies, or denotes, program code that has been compiled into a new binary file that can be executed by the operating system, or by another (aka "host") application.  A "script", on the other hand, is generally *not* compiled into a new (i.e. binary, hex, octal, whatever) file, but left "as-is" in the original "source code".

Source Code is the stuff you type with your own sweaty, trembling Red Bull-infused hands.  If you use something like Windows Notepad to open a program file, and you can actually spot words or phrases in your native language (e.g. English, German, etc.) it's probably either source code or script code.  If you open it in Notepad and it looks like the following crap, it's probably compiled code.

MZ
(*&(#*$)@&)#($*@&#$*&^(000011100-11)!00*!&^0010010101100011100(*&@#][}{}\?<>??::^!@~&^%&^0111011010101001]]]

The simplest giveaway is the file name extension.  I'm not going to back to 101 level stuff here, but you should have a clue that .EXE files are programs or applications, while .BAT, .VBS, .JS, .PS1 and .PY are usually script files.

One important thing to remember is that while there are many scripting languages, they are all basically serving a common purpose:  providing a low-cost, low-complication resource for system admins to automate tedious or repetitive tasks.  Sure, some languages offer more robust features for certain tasks than others, but in the end, it's a matter of matching up the tools for the jobs.

This discussion dovetails a bit with my recent post titled "Why Every SysAdmin Should Learn to Write a Script", however, this one will go in the direction of establishing a few basic technical ground rules.  Stay tuned for more... :)

Read More

Another Book Announcement and More!

I've just published another book!  Yes! I know exactly what you're thinking:  "What the...? Why do they let him keep doing this?!  Have they no mercy upon our eyeballs?!"

Well, in the interests of science, humanity, environment and the ever-pressing need to keep gasoline in the tank of my car, I've decided it was time to pull together as many of the mindless stories I could from my old-as-dirt years working in the world of IT.  That was a very long run-on sentence.  My high school English teachers are probably rolling over in their graves right now.

There's also quite a lot of blabber about how I got into the world of IT and how I swam through the sea of CAD into the ocean of Infrastructure Management and Software Development. It really is fascinating.  Not how I got into IT, but the fact that I could construct a sentence that almost sounded coherent.  Wow!

What's this New Book All About?

The new book is called "You're Only as Good as Your Last Mistake".  Sub-titled "25 Years of Boneheaded Reflection and Stupid IT Stories to Dull your Senses".  It's a blending of a little biographical nonsense, some seriously pretentious pontification, some articles adapted from my blog (this blog), and stories about things going bump in the electronic night. I suppose it could be called a BioTechieHumorFailDisasterFest.  Uhhh.  Yeah.

It's available on the Amazon Kindle store in every country where Amazon can sell books (US, UK, France, Germany, Italy, India, Japan, Spain, Canada and Brazil, as far as I know).

Here's the GOOD NEWS!

• It's only $2.99 (USD) and whatever that translates to in other currency
• Don't have a Kindle?  No problem.  You can download a FREE Kindle Reader app for iPhone, Android, Blackberry, Windows Phone, Windows XP/Vista/7/8, Mac OS, and ...
• You can read Kindle books online in almost any web browser using the Kindle Cloud Reader!
• If you are an Amazon Prime member, you can "borrow" eBooks, including all of my eBooks, for FREE!

What's the Catch?

• I only ask a small favor:  It's a BIG favor for me, and a small effort on your part, but I really would appreciate honest reviews of my books.  If you've purchased, or borrowed, any of my eBooks and actually read them (without pausing in the middle to stab yourself in the eyeballs with a fork), please go to the Amazon web site for the book(s) you've read and submit your opinion on them?
• You can start at my Author Profile page to make it easy.
• Thank you!

Sample: "Where it All Began: From Doritos to Digital Ships"

"Chronologically it's weird, because some of those jobs were in parallel with others.  For example, in that maze of titles I managed to fit in roughly five good years of rock and jazz band, but whatever. I also weaved in about ten years of artwork (painting, drawing, squishing clay stuff around, and so on) which never earned me more than "Hey man, that's cool!"  I remember responding a few times with "Cool enough to buy?", and the response to that being something like "Yeah! By somebody.", but somehow "somebody" could never be found. 

Sometime in early 1984, Mark, one of my brothers stoned friends, walked into our kitchen while I was maniacally inhaling a bowl of Fruit Loops (my favorite cereal at the time).He stopped at the doorway to exclaim "I got a job, dude!" to which we all replied with stunned silence.  I decided to inquire, saying something intelligent like "Oh yeah? What?"  

He explained that he was hired as a "Naval Designer" at a local Naval engineering firm, and went on to indulge us in this magically mysterious thing called "benefits", and something even more interesting, called a "salary". If I hadn't grown up in a Navy town (okay, a Navy "region"), I would have assumed a "Naval Engineer" designed belly-button replacements or something. 

Most of what Mark said was really fascinating, even though I could barely hear his muttering over my own cereal-chewing noise.  The best way to describe him is to think of someone who looks, sounds, and acts a lot like Jeff Spiccolli (Fast Times at Ridgemont High), only not as funny, has a mustache and wears glasses, coming in and telling you he was hired at an engineering firm.  You get the idea. 

Somewhere towards the end of my bowl of cereal Mark said something that perked my ears up.  I think it was something he mentioned about there being more positions needing to be filled, and that they paid pretty well. As it turned out, there were roughly twenty openings for "Drafting Apprentice" jobs, so I ran down and applied.  After a short interview ("Can you hold a pencil, boy? Alrighty! You is hired!"). 

I was finger-printed, scanned, questioned, photographed, probed and stamped with a badge and told to show up at 7:30 AM the following Monday.  That led to five or six years of my work as a Drafter/Designer in the U.S. Naval engineering field." 

Sample above (C)2013 David M. Stein, All Rights Reserved. May not be reproduced or copied, transmitted, in whole or in part, for any purposes or derivative use, without explicit written consent of the author (me). And let's face it: If you're so desperate that you'd consider copying this literary fast food schlock, well, you may need some serious medication already.

Read More

Automation Potential - If Only...

After years (too many to count, or even want to count actually) of working in the IT field, I've come to realize that 99 percent of what holds back businesses, schools, organizations of all kinds from achieving even minor automation benefits from the tools they already have at their disposal is their own lack of leveraging some of their most basic features.  If only...

1. The "Managed By" field for User accounts were populated consistently in Active Directory (AD).  
2. Computers were named consistently with respect to function and disposition using parse-able syntax.
3. The "Location" field were filled out consistently for Computers, and Printers in AD.
4. The "Description" field were not only paid a little attention, but used consistently in AD.
5. A little time were set aside to clean up File shares and storage folders.
6. A basic set of tools were included in the base image of every desktop and laptop computer.

Filling out the 'Managed By' field for user accounts makes it easy to generate automatic organization charts using Visio or other chart tools.  With Visio you can not only automate the org charts, but automate publishing to an intranet location.  The "managed by" association can also be used to automate workflow operations in all sorts of applications, such as System Center Service Manager.

Note: Even if you don't use Exchange or any internal e-mail system, filling out user account fields makes it easy to automatically generate look-up tools for finding employees by name, location, title, department, and more.

When computers are named with a parse-able syntax, it opens the door for all sorts of automation tricks.  From automatic naming processes during MDT and OSD provisioning, to Group Policy targeting (WMI-filtering, etc.), to scripting, to inventorying, to whatever.  A parse-able name is one that is constructed by concatenating codes that represent specific attributes.  

For example "SVDB10012" might represent "Server", "Virtualized", "Database Role", asset number "10012".  Another example might be "DNVA4034" to represent "Desktop computer", "Norfolk, Virginia office", asset number "4034".  The potential code schemes is limitless, as long as you don't violate DNS or WINS naming limitations.

One customer I've worked with uses a scheme similar to the following (modified to protect the innocent, of course):

Device Code: 

D = Desktop
L = Laptop
T = Tablet
M = Mobile device / Smartphone
S = Server

Functional Code:

P = Physical
V = Virtual
C = Cloud hosted

Location Code:

NN = Office location code (numbers or letters)

Asset Code:

nnnnn = 5-digit asset number assigned in inventory and purchase tracking system

Additional "codes" might include organization (division, department, etc.), project or program association, security category (classified, non-classified), regulatory compliance scope (SOX, HIPAA, etc.), shared usage (kiosk, conference room, etc.), infrastructure role (telephony, scanning, CAM operations, etc.), and so on.  You can use these codes to control script behavior, Group Policy filtering applicability, OSD task sequence automation, AD queries, inventory reports, and on and on.

Whether you use Symantec Ghost, MDT, Configuration Manager OSD, or some other tool to prepare, maintain and deploy a "standard" operating environment for your desktops, laptops and tablets, don't forget to include some basic tools to help with troubleshooting and even client-side automation.  Some suggestions might include a few Sysinternals utilities, Trace32 or CMTrace log viewers, Intel or AMD processor diagnostic tools, and so on.  You don't have to do this if it doesn't benefit you, but if you discover that you've been copying certain apps or files to computers each time you troubleshoot problems, you might want to consider making those items part of the standard installation.

I'm not suggesting that you should immediately run out and start doing these things.  I am only suggesting that you stop and think carefully about how you are managing things now, and what you could do to make it possible to automate certain tasks later on as a result of the work you put in up front.  If you make some small changes now, it can open up incredible potential later on for automating tasks that otherwise can be very difficult and time-consuming.

Read More

Why Every SysAdmin Should Learn to Write a Script

I'm a bit overdue for a perceptual conceptual brain-twisting deep-dive article, and caffeine seems to always push me in that direction, so it was time.  And besides, I've been torquing my brain to the limits working a huge article series for 4Sysops on Troubleshooting Configuration Manager clients.  On top of that I'm in the final throws of my next book, and no shortage of "real" work at the office to contend with, and trying to maintain sanity with four kids still at home, and well, it'll be worth the wait, but I may need a stiff drink when it's wrapped up.

So, without further adieu...

Why the Title?

There's no shortage of articles, blogs and whatnot that tout the "benefits of scripting and coding" for anyone who spends time on a computer.  Okay, maybe they're mostly aimed at those who earn a paycheck spending time on a computer, but that's okay too.  Most of the articles I've read however seem to focus on the benefits of automating common tasks, as well as extremely difficult or complex tasks.  That's fine also, but there's more to it than that.  Much more.  To me they're kind of missing the main point:

Writing a script teaches you a particular way of thinking.

Sure, automating tasks pays pretty well, but there's more to be gained by an everyday computer technician from learning to write even the most basic script. One of the main reasons, indeed THE reason, that I chose the title for this article has nothing to do with automating tasks at all. Let us drink the Kool Aid of digression and digress with me for a bit, mmkay?...

A Different Kind of Thinking

Writing software code, whether it's to be compiled or interpreted, involves a process of thought.  Granted, there are some variations of the thought process as it pertains to a particular programming language, as well writing functional, procedural or object-oriented code, but the process itself; the process of telling the computer to perform certain actions, remains.  It's a logic process.

If This is True: Do That  /  Otherwise: Do something else...

Disregarding semantics for a moment, the flow of logic is roughly the same whether you work with C++, JavaScript, LISP, Python, Ruby or whatever.  Picture the following example scenario:

Task: Instruct a Robot to retrieve a box of cereal from a cabinet on the other side of the room.

That sounds easy, right? "Hey, robot.  Get me the box of cereal."

But the robot doesn't move.  It needs to be told:

• where to go
• how to get there
• what exactly to retrieve
• how to actually retreive it
• where exactly to go next
• how to go to the next location
• when to perform each step

The only basic questions it doesn't absolutely need to ask are the who and why aspects. For now, anyway.  Let's ignore the possibility that it's a super-advanced robot that understands these things. Let's instead go with a robot that was just born and has to be taught like a baby human would.  These steps come with a few qualifying pieces as well:

• where to go: relative to current location
• how to get there: walk, roll, crawl / turns, ascentions (climbs),descentions, and distances
• what exactly to retrieve: which object(s), means for identifying or locating
• how to actually retreive it: grasp, slide, push, pull, tip, scoop / carry, store, clutch
• where exactly to go next: relative to current location
• how to go to the next location: walk, roll, crawl / turns, ascentions (climbs),descentions, and distances
• when to perform each step: now/immediate, x minutes/seconds from now/from previous step

It should make you pause for a moment and begin breaking down the sequence of tasks in detail:

1. Turn [n] degrees to your [right/left]
2. Move forward approximately [x] feet and stop
3. Turn [n] degrees to your [right/left]
4. Move forward approximately [x] feet and stop
5. Raise arm upward to [x] degrees from default position
6. Extend arm forward [x] inches
7. Grasp cabinet handle
8. Pull grasped handle, swing arc to [left/right] until door is opened [x] degrees from starting position
9. Release handle
10. ...

You get the idea.  Those of you that have actually programmed machines like this already know that I'm glossing over a lot of detailed steps in between.  This is actually the basis for how a programming language is developed: step by step, nouns and verbs. Then come the adjectives (gently, loud, etc.), until the language is matured enough to accomplish the general class of tasks it was intended to address.

Side Note: When asked "what is the best programming language?" the answer is: "There is no such thing as a 'best programming language'".  Every language is better at some particular tasks than others.  A programming language is a tool.  A tool is a means for accomplishing one or more tasks. Each tool is conceived and built to address a particular set of tasks.   

Contextually, some languages are "better" to master with regards to job opportunities or specific projects.  From a technical point of view, the concept of "better" depends on specific comparisons of individual features as they align with a set of specific tasks which are to be accomplished.  The more general or multi-purpose capability a particular tool becomes, the less specialized it becomes at the same time. 

That was a lot of mumbo-jumbo, sheesh.

You may start letting your mind wander into additional challenges, like navigating stairs, odd angles, and so on.  Hopefully another thought crossed your mind: How much we, as human beings, take for granted this little stuff.  Imagine what someone fighting through physical therapy has to deal with as they learn to walk or speak again following a major injury.

In most respects, this way of thinking forces you to shoehorn your intentions into the mouth of the beast we call a computer. The point is that when you're forced to structure your thinking in someone else's terms, it also forces you to think more clearly about what it is you're trying accomplish.

In many respects, it forces you into a serialized or sequential mode, even if your goal requires solving parallel processes.  You have a Start and a Finish.  A beginning and an end.  Initialization and termination. An Alpha and an Omega (for you religious folks, a little humor, pardon me). Regardless of having to contend with seemingly random or asynchronous sub-tasks, the overall context has (or should have) a defined start and end.  If you're looking to run a program that just goes off and does a bunch of unrelated things; does a lot of unrelated and undefined things, and never ends, that's been done already: It's called politics.

Let's put this into somewhat of a "real world scenario" for a  moment. A

Example: Finding all Files in a Folder that Contain a Particular Text Value or Numeric Pattern

This is a very common task indeed.  Whether it's finding documents that contain a reference to a particular contract number, or data files that contain a numeric pattern, or sales records with a particular date, log files that include a specific name or code, the logic for pursuing the answer is pretty much the same.  What differs is the trivial stuff like formats, locations, and the periphery like environment and concurrency limitations.  I say "trivial" in the sense that those are relatively less important than the primary goal being sought.  I'm fully aware that in many cases those so-called "trivial" extraneous things can become the biggest headache to deal with.  Okay, enough blabbering from me.  Let's dissect this creature...

What are we trying to accomplish here?

1. We need to identify what we are looking for: ____
2. We need to identify where to look for it: ____
3. We need to identify what to do when we find it: ____

There are millions of other things we can do, and may need to do, in addition to these basic questions, but in most cases these are the three most important questions to answer.  You could boil them down into two primary categories: Target and Action.  What is the target and What action do we take on it (or because of it)?

For this example, we'll keep it simple and go with the following parameters:

Find all instances of the text value "CNX-10114025" within all of the documents contained in the Folders located on server FPS0025 under the shared folder root of "Contracts".  The target UNC path then becomes "\\FPS0025\Contracts".  Maybe a quick inspection of the folder structure reveals that there are nested folders which will need to be scanned, as well finding that there are an assortment of file formats to be found:

• Microsoft Word, Excel, of various versions (.doc, .xls, .docx, .xlsx, etc.)
• ASCII Text (.txt)
• XML files
• HTML source files
• PowerShell scripts (.ps1)

You probably stared at that list and immediately began to think through the process for opening, reading, and parsing each file type.  You're already staring at the trees, let's get back to the forest.

Here's what you should have thought:

1. Access the root folder
2. Look for files in the root folder
3. Check each sub-folder
4. Look for files in each sub-folder
5. Check for the next level of sub-folders
6. Look for files in each sub-folder
7. Wash. Rinse. Repeat

An average programmer or scripter (script-writer? script-kiddie? I can never figure out what the proper term is anymore) would get to step 4 and immediately blurt out "Recursion, bitches!" and then quiet down after realizing they just upset everyone else in the library.  I happen to be sitting at a table in our "central" public library actually, so that's why I made that connection.  I haven't blurted out anything yet though.

Forget recursion for the moment; stay focused on the forest.  The trees will come later.  And, yes, I know that the preceding sentence is completely illogical, let's keep moving along...

Are you seeing the process yet?  If you're following along with my mindless rambling, you're probably nodding in confirmation of understanding that you have to think it through in an orderly fashion.  The key here is "orderly" (i.e. sequential.  serialized.  linear).

Side Note: Yes, I know that there are non-linear, amorphous, parallel and even polymorphic/non-linear/parallel problems to be solved, but this is Dave 101 and that course isn't until next semester (if ever).  Context is everything.  The context here is: how does writing a script benefit a systems administrator who's never considered writing a script before now.

Pseudo-Code to the Rescue

Most programmers will have likely put there head into both hands and moaned at reading that line above.  The prevailing view of pseudo-code is that it's for beginners.  Noobs.  Training-wheels.  And in some respects that's true, but it works. No reasonable programmer or scripter can argue that writing pseudo-code is detrimental to anything besides (A) their ego and (B) their time.  I've seen it used by some of the best and brightest programmers when conditions were sufficiently warranted.  What did that mean?  I mean that when faced with an incredibly complex task to accomplish, pseudo-code can help map out the primary steps and it can bring clarity to the major components of the impending code to be written.

What is Pseudo-Code Anyway?

Rather than explain it, I'll just show it:  First, here's a chunk of actual program code...

If Not amx_InstallRegKeyExists ( regKey3 ) Then
   dPrint "info", 0, "AMX is not installed. Proceeding with install sequence."
   If Not amx_PreReqsFound ( arrReqIDs ) Then
      dPrint "info", 0, "Installing AMX prerequisite components..."
      p1 = amx_InstallMissingPrereqs ( arrReqIDs, False, vbMinimized )
   Else
      p1 = True
      If amx_InstallSequence ( arrAppIDs, False, vbMinimized ) = True Then
         p2 = amx_InitRebootSequence()
      Else
         dPrint "error", Err.Number, Err.Description
      End If
   End If
Else
   dPrint "info", 0, "AMX is already installed. No action required."
End If

Now, let's write that in pseudo-code:

1. If application "AMX" is NOT already installed (then...)
1. install prerequisite software items
2. install AMX application
3. check that everything installed properly
4. reboot the computer
2. Otherwise (else...)
1. nothing to do, exit cleanly

That's it.  Pure and simple. Now, the question you may ask is "Hey, dumbass: where do I buy a book on this 'pseudo-code' programming language?".  You don't.  You can't.  There's no such official programming language by that name.  It's a term used to describe the writing of program instructions in human-readable terms. It's like a "faux diamond", "pleather jacket", or an "honest politician". It's "fake". The word "pseudo" means "not actually, but having the appearance of...", or fake, so you get the picture.

Master or Commander?

Am I saying that you need to spend a lot of time mastering the art of writing scripts?  No.  I'm only suggesting that learning how to write even one script successfully will help you in the long run.  It's sort of like walking a mile in the computer's shoes.  I'm not going to trick you and deny that writing scripts isn't both addictive and lucrative.  The more you write the more tasks you'll think of to use them on.

Pointers

Some of the sites I look to for help and inspiration when working on new scripts (if I don't have code laying around from twenty years of tinkering with it):

• Microsoft TechNet Script Center
• PowerShell.com
• Rob van der Woude
• PowerShell Code Repository
• ss64.com 
• Dr. Scripto's Script Shop (Microsoft)
• MSDN VBscript Language Reference
• MSDN ADO Code Examples
• ActiveXperts.com

Read More