Big News! E-Book Price Reductions!

If you have ever stayed awake long enough to read through any of my books: THANK YOU!

If you've read one or two of them, and wondered if any of the others are any good, well.... now is your chance to explore.

Big News...
Major Pricing Discounts on my E-Books!

Major Discounts will be applied starting this week.  Amazon has to process the price changes, so they may not be posted for another 24-48 hours (from today: July 24, 2013).

If you still see the "Old Price" posted on the Amazon product page, refresh the web page or come back to it until you see the updated prices.

The new prices are shown below.  Read the Q & A below for more information...

Amazon Kindle Publication	Old Price (USD)	New Price (USD)	Discount
Grinding Gears: The Art of Software Repackaging and Deployment Packaging, Testing, Deploying, Uninstalling and Upgrading Software Applications on the Windows platform.  Also covers Configuration Manager, Scripting, Group Policy, and more!	$6.99	$5.99	15%
Why Your Next IT Project Will Fail (and What You Can Do to Avoid It) Why do Projects fail? More specifically: Why do IT Projects fail? Is there a common thread or pattern that exists among failed IT Projects? Is it predominantly a failure of technology; of people; or a failure of both? Are there warning signs that make it easy to spot the causes before they become problems, with sufficient time to correct them? Are there steps that can be taken to correct the problem once it's begun? Are there strategies that can help prevent these potential issues from occurring again?	$4.99	$2.99	40%
The Visual LISP Developer's Bible: 2011 Edition Developing, Testing and Compiling VLISP code for AutoCAD 2011.  VLIDE options as well as tips and tricks.	$7.99	$5.99	25%
The Visual LISP Developer's Bible: 1st Edition The Original. The e-book that started it all for me.	$4.99	$2.99	40%
The AutoCAD Network Administrator's Bible: 2013 Edition Setting up FlexLM and network licensing. Building, Testing and Deploying Autodesk 2013 products (aka "Deployments"), logs, option files, troubleshooting and more.	$9.99	$7.99	20%
The AutoCAD Network Administrator's Bible: 2012 Edition Setting up FlexLM and network licensing. Building, Testing and Deploying Autodesk 2012 products (aka "Deployments"), logs, option files, troubleshooting and more.	$6.99	$4.99	30%
The AutoCAD Network Administrator's Bible: 2011 Edition Setting up FlexLM and network licensing. Building, Testing and Deploying Autodesk 2011 products (aka "Deployments"), logs, option files, troubleshooting and more.	$3.99	$2.99	25%

In addition: Some of my e-Books which were not enrolled in the Amazon KDP Select program, are now enrolled! 

• The Packager's Pocket Reference, 2nd Edition ($5.99)
• Grinding Gears: The Art of Software Repackaging and Deployment ($5.99)
• You're Only as Good as Your Last Mistake ($2.99)

Q & A (Questions and Answers)

How Long will this Discount Offer Last?  These prices will remain in effect until August 10, 2013, or roughly 16 days from when the new prices go into effect.  After that, they will be returned to their previous prices.

Do you need a Kindle to read these?  NO.  You can download a FREE Kindle Reader App for almost any mobile device.  You can also read them in almost any web browser using the Amazon Kindle Cloud Reader.

You can read these, using a FREE reader app, on your iPhone, iTablet, iPod, Blackberry, Android device, Windows device, and more.

What Locations will see these Discounts?  The new prices will go into effect in all markets in which Amazon applies international currency conversions.  If you live or reside in a location which is not handled by their automated currency conversion process,  you will see whatever discount is applied as a derived translation of the U.S. Dollar value, as best as I can figure out. 

The markets which are covered by their automatic conversion process, as of now,  include: The United States, United Kingdom, France, Germany, Spain, Italy, India, Japan, Brazil, and Canada.  For more information, visit the Amazon web site and be sure to drink plenty of caffeine.

What does this "KDP Select" stuff mean?  It means Amazon Prime members can LEND and BORROW those e-books for FREE.  Yes.  For Free!  Ok, well, becoming an Amazon Prime member isn't really "free", but it does give you some pretty darn amazing discounts and cool features you can't get otherwise.

How Many of my e-Books are enrolled in this "KDP Select" program for Amazon Prime members to benefit from?  All of them.  If you find any that are not available for lending and borrowing on Amazon Prime as of July 26, 2013, please post a comment here and let me know!

How do I know which books are written by this same "David M. Stein"?  I've been told there are other "David Stein" authors out there, some with rather interesting tastes in book topics.  Rest assured that I have only written the books you see listed on my Kindle Author's page

Why am I doing this?  It's simple:  I have four kids still living at home, and my car is pretty darn old.  So you can rest assured that while you save money, and stuff your brain with new information, you're also helping a good cause.

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.

The New Book is Out!

For whatever reason, I realized just now that I forgot to post on my blog that my new book is out and available on Amazon.  It just skipped my mind with all the other things going on.

The new book is "The AutoCAD Network Administrator's Bible, 2013 Edition".  It's available now for $9.99 (USD) on Amazon Kindle, Kindle Fire and Kindle Reader apps (including the web or "cloud" reader).  If you are an Amazon Prime member, you can lend and borrow this book, like all of my books, saving you a bit of money in the process and sharing it with your friends and colleagues.

So, what's New?

This edition forced me to revisit both sides of AutoCAD network deployments: The building of the deployment image itself, and changes to the distribution processes incurred from new products and new technologies.  Among these:

• Changes to the AutoCAD 2013 Deployment Tools
• Microsoft System Center Configuration Manager 2012
• Microsoft Deployment Toolkit (MDT) 2012 Update 1
• Active Directory Group Policy Deployments
• Script Deployments:
• VBScript
• PowerShell
• BAT/CMD
• Planning and Deploying FlexLM servers
• Managing FlexLM licenses and options
• Deploying DWG TrueView 2013
• Deploying Design Review 2013
• Troubleshooting Tips

It took me several months to get this one done, but hopefully it was worth it - and I really hope you find it to be helpful and useful as well.  As always, please... PLEASE... post your reviews on Amazon so I, and other readers, can benefit?  Thank you!

Special Thanks:

While I thanked a lot of people within the book, there are some I need to thank again for helping me get it out and available:

• Johan Arwidmark - for generously taking time to review the book and provide corrections, and very helpful comments!  By the way, if you're one of few geeks who aren't aware of Johan, hit Google or Bing, and learn!  If you have any interest in MDT, ConfigMgr, automating software and operating system deployments, and learning about it in a way that's interesting and entertaining, you can't go wrong here.  If you are going to attend Microsoft TechEd, you don't want to miss one of his sessions either.
• Rod Trent - for being supportive and helpful whenever I've bugged him for help.  If you're not aware of MyITForum, go check it out - it's a must-have resource for this kind of work. Trust me!
• Ralph Grabowski - tireless advocate for all-things CAD/CAM and reporting on the state of the industry like nobody else. If you are interested in what's going on in the world of engineering and design automation software technology, check out UpfrontEzine!
• Everyone who follows my boring blabber on this blog, on Google+, Facebook, Twitter, and LinkedIn.  Seriously: Thank you! I don't know why you do, but I appreciate it.
• Last but not least: My amazing wife, Kathy, and my four incredible kids: Rachel, Sarah, Gabrielle and Zachary!
• I'm sure I forgot someone, but don't be upset.

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.

Autodesk Network Deployment Strategies

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

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

Background

Let's start with a model:  Fictional Corporation

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

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

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

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

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

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

Situation

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

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

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

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

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

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

Question 1: What Happened?

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

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

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

Question 2: How to Fix This:

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

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

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

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

Best Answer?  ____

FlexLM License Servers

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

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

What's the Easiest way to accomplish this change?

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

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

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

Best Answer?  _____

Slow Autodesk Network Deployments?

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

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

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

Network Site Link Speeds

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

NIC Configuration Settings

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

Concurrent Utilitization: Server

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

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

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

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

Concurrent Utilitization: Network

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

Client Integrity

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

Client Activity

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

More

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

And Finally...

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

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

Tools and Links

WindowsNetworking.com - Troubleshooting Network Issues

Advanced Network Adapter Troubleshooting for Windows Workstations

WireShark (the de facto diagnostic tool)

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

Sysinternals Networking Utilities

Sysinternals Process Utilities

Books by Mark Minasi at Amazon

Network Diagnostics and Tracing in Windows 7

NETSH commands for Windows 7 and Windows Server 2008 R2

MSIExec Exit Codes in Script

I could have left off the "in Script" part, but whatever.  Since I'm talking about this in the context of scripting I suppose it fits.  If you do any packaging (or more accurately: re-packaging) of software installations, you should bookmark Microsoft Support Article 229683.  This article provides a useful index of MSIEXEC exit codes and what they represent.

There are a few that should look familiar, but some of you may not be aware of them.  The longer you work with deploying software (and software uninstalls), especially via script, the more likely you will encounter these particular exit codes at some point.  There are others that pop up, but these tend to be the most common...

0 (zero) - represents "good", or "no errors".  In general, an exit code of zero indicates a successful completion.  Does this mean that the task REALLY completed successfully?  No.  It means that whatever was the last step of the task returned an exit code of 0 to whatever was watching it (i.e. the Configuration Manager client).  I have seen plenty of crappy vendor installation packages fail and return a zero code.  I've also seen respectable vendor packages do this (a major CAD vendor's network deployment which fails when trying to install .NET 4 and DirectX in the silent bundle, in a particular version of their product line, would return 0).  For most simple tasks (an individual msiexec or setup.exe operation) a zero exit code is fairly reliable, but as I always say: TEST, TEST, TEST, and then TEST AGAIN.

3010 - "a restart is required to complete the install"

This is similar to zero, except that it also indicates that a system restart is required in order to complete the task successfully.  If you are running multiple step tasks, and any one of the tasks returns a 3010 exit code, and you are suppressing restarts throughout, make SURE you execute a restart at the very end.  In addition, if you are using a product like Microsoft System Center Configuration Manager, you need to modify the Program to indicate that the program will restart the computer when finished running.  This is especially important if the program is a script.

1605 - "this action is only valid for products that are currently installed"

This exit code applies to uninstalls and indicates that the .MSI or GUID specified in your script to run as an uninstall (e.g. /x) is not actually installed.  It may also indicate a corrupted installation, whereby there are in fact bits of the product installed all over the place (files, folders, shortcuts, registry entries, DLL registrations, .NET assemblies, etc.) but the required references to tell Windows that the product is in fact installed are broken or missing.  If you are building this into your script, make sure that if you fire off an "msiexec /x blah-blah-blah" statement that returns 1605, to also follow behind that with additional checks for remaining pieces to clean-up.

1633 - "this installation package is not supported on this platform"

As you might have guessed, this means that an attempt was made to install an MSI package on a non-supported platform (i.e. operating system version or service pack level).

1632 - "the temp folder is either full or inaccessible"

I've seen this error when an overzealous sys-admin ran a scheduled task/script to clean out "temp" folders and also removed the temp folder itself.  I've also seen it (less often) when the security permissions on the temp folder are changed from their default configuration (whether it be the Windows\Temp folder, or the user's individual temp folder).

As a follow-up on 1605: if you are creating a script to run via Configuration Manager to uninstall an application, and you get this exit code, you might want to override the return value.  As an example, rather than raising the %errorlevel% value (option [1] below), return an explicit zero (option [2] below)...

[1] exit %errorlevel%

[2] exit 0

Someone asked me recently about why I would recommend this. It's simple: if you are deploying an advertised uninstall program, and it runs on a client that doesn't have the installed application, it may return 1605, which means "not installed, move along", which technically isn't a failure and should not return a "failed" result to Configuration Manager.  If it runs on a client where it isn't applicable, it should bail out and say it was successful, or you can use another explicit exit code and have a better/clearer picture of how many actually ran the uninstall.

1622 - "error opening installation log file"

If you like to use logging options with MSIEXEC, make sure the log output path is valid, and that the permissions allow for creating and updating the log file under the context by which the package is installed (or uninstalled).  This will often return a 1622 exit code.

1608 - "unknown property"

This exit code indicates an invalid property parameter was passed in the command line.  The most common cause of this is fat-fingering.  For example, when specifying "INSTALLLEVEL", but you leave out one of the "L" characters (e.g. "INSTALLEVEL") it will blow up with a 1608 exit code.

The single most important takeaway from this is that if you use scripts with deployment systems like Configuration Manager, you need to be careful to not only watch for exit codes, but watch for how you are raising the results up to the Configuration Manager agent.  In most cases, raising the explicit exit code is best, but there are times where you may want to override it (such as 1605).  Scripting is like a giant box of Lego(R) blocks, allowing you to build incredible things.  But you need to make sure the towers and bridges you build with them don't crash under their own weight.

Scripts Calling Scripts, and So On...

I tried to come up with a clever title, but I just finished a grueling bike ride in the heat and humidity, followed by cold beer and pizza, so my brain is not on the clever channel right now.  But here goes...

I recently got a few e-mails about my recent post about running script packages from Configuration Manager and how to handle return exit codes.  Rather than dive into the syntactical minutae, I think a conceptual overview is in order.

Basically, when one thing calls another thing, and that second thing calls yet another thing, there are a variety of issues that come into play when it comes to the calling thing getting a "result" from the thing it calls.

When you create a Package and Program in Configuration Manager (or Altiris, Tivoli, wtf), which runs a .MSI installation file, it automatically invokes msiexec to do the heavy lifting on the client.  When msiexec runs the .msi (and/or .msp, or .msi + .mst, etc.), msiexec handles the return value by evaluating the execution process as it progresses.  If it bombs out, you get back an exit code that is "non zero" (remember: in most cases, a zero value indicates "success").

When your package/program executes an .EXE, the CMD/explorer shell process handles the resulting exit code.

In both msiexec and .exe situations, the handlers (msiexec and cmd/explorer) pass the result exit code back to whatever called them (i.e. Configuration Manager agent).

When you call a script, it introduces a "sort of" proxy situation.  The script handler (cmd for .bat or .cmd scripts, kix32.exe for .kix or .kx scripts, powershell for .ps1 scripts, or wscript.exe or cscript.exe for .vbs or .js scripts, and so on...) does not automatically "raise" the exit code from a scripted task up to the calling process (Config Manager agent).  Instead, the handler will return an exit code based on whether or not the script itself completed or not.  If, within the script code, you forcibly raise an exit code, it will respect that and pass that value up the stack to the calling process.

So, let's give an example:

1. You make a Config Manager Package and Program that calls a .CMD script
2. Inside the .CMD script you execute a msiexec /I <filename.msi> /quiet /norestart
3. The .msi installation fails with exit code 1604
4. The .cmd script returns 0 to the Configuration Manager agent (e.g. "success")

Why?  Because the .cmd completed successfully even though the msiexec task failed.

What to do?

The specifics of how to "raise" an exit code depend on the scripting language being used.  For .cmd and .bat script, use the EXIT statement followed by the value you wish to raise to the calling stack.  You can give an explicit value, such as 33, or you can pass the %errorlevel% value, which will temporarily hold the value of the last error.  If you check for the %errorlevel% immediately after the msiexec execution, you can capture the value, and then raise it accordingly.

Here's a short example:

@echo off
msiexec /I "%~dp0fubar.msi" /quiet /norestart
if %errorlevel%==0 (
   echo installation successful >>%logfile%
) else (
   if %errorlevel%==3010 (
      echo installation successful [reboot pending] >>%logfile%
   ) else (
      echo installation failed [exit code: %errorlevel%] >>%logfile%
      exit %errorlevel%
   )
)

The 10th line is where the exit code is raised to whatever is calling this script.  So if the msiexec process fails with error 1619, it saves that value in the CMD %errorlevel% variable.  Then in the script, we pass %errorlevel% up using the exit command.  When it fails, and the script passes the value back to the Configuration Manager agent, it reports back to the site server that it failed with error 1619.  All is well in the Universe.

What happens when a vendor's wonderful setup.exe doesn't properly return an expected exit code when it fails?  What?!!!! (insert 1980's vinyl album scratch sound here)

Did I just say that vendors might actually have produced less-than-perfect installation packages?  Is this even possible?  OH NO HE DIDN'T!!  OH SHIZNIT!  OH SNAP-STICK!  What now?

Yes.  Unfortunately, the ugly, brutal truth is that there are many, many, many such pieces of fecal matter labeled as "installation" files or packages.  Some come from widely-known, huge, corporate vendors, while a larger number come from smaller shops where they feed chained wild monkeys bags of Skittles and Kegs of Mountain Dew and whip them with Chinese egg noodles until they produce installer files.

What to do?

You have to get creative and wrap their crap in some script to perform additional checks and double-checks, and raise your own custom errors.  I call this a "crap wrap", because it wraps crap.

FWIW: I have my own definition of "crap installer" >>> Any installer that is not a 100% pure MSI file is crap.  Period.  I f-ing hate setup.exe, and setup.exe bootstrap installers.  NullSoft is crap also (silent installations are ok, but silent uninstalls are horrifically f**ked).  And anyone who sells you a .zap file should be shot on site (I'm not including those of you that have to make your own .zap files, we share the same pain). 

I make one exception to this rule: self-contained applications.  Things like Sysinternals' PSTools, where you don't really "install" anything, you simply copy/download the .exe and it's ready to go.  I wish more apps were that well-packaged actually.  Imagine if Autodesk provided Inventor 2012 as a self-contained application that required NO installation process.  OMG.  I would need a Kleenex.  (don't even try to suggest App-V or ThinApp as being in this category, they are not).

In any case, back to the subject:

When one thing calls another, you need to examine what each down-level process returns up the stack, as it were.  Using a virtual machine environment is great for this, as is using the good-ole CMD shell to perform command line diagnostics along the way.

I'd go on longer, but I'm out of brain power right now... I need more pizza.

Calling a URL from WinPE / DaRT Environment

So maybe you find a need to call a URL from a WinPE or DaRT session (yes, I know, DaRT is a modified WinPE), but without IE or a browser you find it a challenge.  Fear not.  There are options at your disposal.

Option 1 is to install a light-weight browser into your WinPE bundle, like Bart’sPE did/does.  Firefox is a fairly common choice for that, but if you can get another browser to do that you have that option.

Option 2 is to invoke the XMLHttp object via script.  You can do that with VBscript since wscript/cscript components are part of WinPE and DaRT.  The nice thing about this is with XMLhttp, you essentially have a browser but without the GUI.  You call URL's and even fetch (i.e. "scrape") the return HTML results if needed (I do that a lot and may post some examples soon).  A command-line browser, sort of.

Here’s an example of option 2 – calling an ASP page with parameters…

url = "http://myserver.domain.com/loginfo.asp?c=Workstation123&os=Windows7&ts=Enterprise32b"
 
On Error Resume Next
Set ohttp = CreateObject("Microsoft.XmlHttp")
oHttp.open "GET", url, False
If err.Number <> 0 Then
    wscript.Echo "fail: unable to open remote URL for asset number!"
    wscript.Echo "fail: error is " & err.Number & " / " & err.Description
Else
    oHttp.send ""
    textData = oHttp.responseText
    wscript.echo "info: completed"
End If

If error-checking isn't your cup of tea (or Four Loco), you can leave off the code from line no.4 to the end.  The meat of this is lines 2 and 3 actually.  Just create the object instance and call the .open method.  That boils down to just the following...

url = "http://myserver.domain.com/loginfo.asp?c=Workstation123&os=Windows7&ts=Enterprise32b"
 
Set ohttp = CreateObject("Microsoft.XmlHttp")
oHttp.open "GET", url, False

Deploying AutoCAD with MDT 2010

In my latest book I discuss the various ways to automate the deployment of Autodesk products throughout a Windows network environment.  Among these is "imaging".  This is essentially where you automate the process of loading the base operating system, drivers, updates, and a set of "standard" applications on a new computer before delivering it to the user.  If you're using a network-licensed version of an Autodesk product and the majority of your users use the product, then adding it to the base image might make sense in your environment.

Microsoft provides a free application called Microsoft Deployment Toolkit, or MDT, for creating custom imaging configurations for your various needs.  This can range from various hardware models (drivers and utilities) to various user functions (role-based configurations for various departments or skillsets).  It is also the required component for deploying imaging services within System Center Configuration Manager 2007, where it rolls up into what is known as the Operating System Deployment (OSD) feature.  MDT employs a variety of components and toolkits such as WAIK (Windows Automated Installation Kit), .NET framework and so on.  For more information about MDT visit the Microsoft TechNet MDT web site.

MDT uses a "task sequence" process that allows you to create a custom chain of events to install and configure everything you need on each computer.  Think of it as being kind-of like a giant BAT script, but with a very robust GUI environment to work with.  You configure which operating system, which service packs and updates, which drivers, which settings to customize, and which applications.  You also configure the order in which these things are executed.

Why would you want to use MDT to deploy Autodesk Network-Licensed Products?

It can save on product network traffic overhead compared with pushing the installations out to computers in the environment.  You can easily segment and isolate network traffic between the MDT host server and the workbench where the computers are imaged.  This keeps the traffic off of your production routers and switches, thereby avoiding slowing down your users even during peak production hours.

Why would you NOT want to do this?

This is a bit tricky, and often subjective, but you have to consider how many licenses of the Autodesk product you have available (FLEXlm), compared with how often you max out usage, compared also with what percentage of your total computer user population could use a license at any given point in time.  An example might be if you have 500 computers/users, but only 100 AutoCAD licenses.  If 150 of your employees are potential AutoCAD users, especially frequent users, you may experience the dreaded "No available licenses / try again later" scenario.  If you are in this scenario, then putting AutoCAD on every desktop and laptop might only exascerbate the problem by making it too easy for even casual users or curious folks (non-users) to attempt to launch AutoCAD.

The missing piece

Assuming you're not worried about the downside described above, and you wish to pursue adding this into your base image process, what do you need to do?

You need to create a Deployment share for AutoCAD.  This is not to be confused with the "Deployment Share" referenced within MDT.  That's a different deployment share.  You have to create a network deployment share for the Autodesk product and create the deployment for the product to publish into that share.  This is done from the installation media main setup interface.  You will need to follow the same basic process as if you were creating a deployment for SCCM.  You should make sure you include the installation of .NET Framework 4.0 before the task sequence item that installs the Autodesk 2012 edition of your products.  You may also need to (separately) package the DirectX components.  Last but not least, you need to make sure your command-line for installing AutoCAD includes the /I /Q and /W parameters (as shown in the NAG, or Network Administration Guide).  If you forget the /W parameter, the installation will not pause the Task Sequence until it finishes, and will then create a problem where the next step begins execution before the AutoCAD installation is even partially completed.

If you build a proper AutoCAD Deployment and configure the Task Sequence within MDT properly, you should have a smooth process for including it in all of your newly imaged, or re-imaged computers before delivering them to the end-users.

Cheers!

Another Packaging Tip for AutoCAD 2011

This was posted on the Autodesk DWG TrueView discussion forum by user GTVic on 12/20/2010 in response to an ever-growing thread on doing silent installs of DWG TrueView (and spilling over into AutoCAD 2011 it seems):

I have my AutoCAD 2011 scripted deployment working. Here are the changes I made:

 

First, you have to use the "-for-GPO.msi" file with the deployment MST file. I ignored GPO.mst because it was in a different folder and had an old date and only set one property ADSK_SETUP_EXE=1.

 

With the GPO MSI you will properly install the english version 0409 instead of 0000 and then the subscription and service packs will be able to detect that AutoCAD is installed.

 

For the language pack you need to include a property INSTALLDIR=C:\Program Files\Autodesk\AutoCAD 2011\. I also added ADMIN_INSTALL=YES but I don't think that is needed.

 

The Civil Object Enabler requires the same INSTALLDIR property.

 

If you want AutoCAD to be able to update the Hardware Graphics Card database xml file for a user without admin rights you have to make the following folder writeable: C:\ProgramData\AutodeskRendering\PTXML.

Thoughts on Denver, the VA, and Mass Deployments

I kind of chuckled right after I typed the title line above.  I still have a middle school brain most of the time, so I'll leave it to you to figure out what alternate meaning that could have.

I've been fighting a Cold after I worked myself down on lack of sleep trying to get the book published.  I never learn.

Denver and the VA

I recently finished up a conference call with the Department of Veteran's Affairs.  They kindly asked if I would mind joining the call to answer a few questions about deploying Autodesk products with System Center Configuration Manager.  The call was fairly quiet, with many pauses waiting for the next person to chime in.  There wasn't a hard-written agenda of any kind, just a general topic, so we just went with the flow.

Now, this is the part where some of you might be thinking: "oh, here he goes bragging about his book and saving the world".  But in all honesty, I have no such delusions.  I was pleasantly surprised by the e-mail invite.  I have deployed to 5,000 computers in a single site, and 2,600 computers in 22 geographically dispersed sites, but these guys are well beyond that.  Yes, I was humbled.  I probably would have declined had it not been for the following key aspects:

• It was the VA
• The invite came from the Denver office
• I was home with a Cold, sleeping all day, and awoke only minutes before the call started

Those of you that know me pretty well, also know that my father was a VA physician for 30+ years.  He retired from active duty in the Navy to work for the VA in 1957.  He passed away just a few months before retirement, after happily devoting his life to caring for veterans.  They were his extended family.  I cannot describe it with any other words. When my parents separated, I was in first grade, and he managed to secure living quarters on the Hampton, VA grounds while working as the Domiciliary Chief, and later as Chief of Staff.  I would spend weekends with him there and met many of his patients, other doctors and staff members.  In addition, my mother and father were from Denver, and there is a whole other, albeit distant and detached, branch of our family out in Colorado and parts of the southwest.  I simply couldn't decline this offer.

They have a fairly familiar environment and scenario: multiple, independent regional IT operations, each trying to race to find the cure for what ails their IT woes.  When one group breaks ground on something, they share with the others.  At least, that's what I could gather from our short conversation.  Each one supports a large number of customers and computers.

Unsung Heroes

Since I've been working for a municipal government IT operation, I can now see things from a different perspective.  One that few outside of this "world" can accept as even a remote possibility. That is, that there is a HUGE emphasis placed on efficiency and squeezing every drop from an ever-shrinking budget.  Most of the public at large is firmly convinced that government operations are drinking the finest champagne and eating caviar for lunch every day.  Au contraire!  Not only do most government IT operations have to "get by" with meager resources, they are constantly being forced to cut, cut, cut and cut again.  If you don't work in that environment, you cannot imaging the pressures it brings to bear on people struggling to meet regulatory demands, customer needs and just trying to keep all the gears meshed and moving properly.

I used to get upset when I overhear people make proclamations about how wasteful government operations are.  I'm sure there are some, but I can attest from personal experience that government IT endeavors are last in line for preferential treatment and funding.  They often get no credit for making things work (and they make things work very well), while getting the first fingers pointed at them when something fails.  A laptop left in the open by a government worker? IT gets blamed.  Someone opens an email virus and files get filched?  IT gets blamed.  Workers get caught surfing porn sites?  IT gets blamed.   Software gets packaged, staged and deployed to a million computers around the country? (crickets chirping…)

Now I just sigh and say "fuck it".  It's not worth trying to fight that battle.  You might as well charge into a redneck bar on a Saturday night and tell them "Ford sucks! Toyota rules!".  Their minds are made up and closed.  Don't bother.

Call of Duty

Anyhow, what are the challenges most LARGE SCALE software deployments face?

• Packaging & Testing
• Deployment Staging
• Deployment Execution

I'll leave out the ancillary stuff like license servers, licensing, and custom add-ons for now.  These three bullets are enough already. Right?  I mean, I know quite a few people who immediately think about drinking as soon as you mention the word "deployment".  Or as one colleague likes to say: "gentlemen: it's time to pucker your sphincters and get to work!"

Packaging & Testing

As it pertains to building deployments, packaging (or re-packaging) and testing them: it varies widely from one product to the next.  There simply is very little consistency in some respects.  I have to commend Autodesk for putting a lot of effort and emphasis on achieving consistency and simplicity across their products as it pertains to building deployments.

Testing

My testing, actually, the testing procedure we use at work (I didn't invent this by any means), is as follows:

1. Manual install from the source share to a test client (VM)
2. SCCM deployment to a test client (VM)
3. SCCM deployment to a physical client = UAT phase

After UAT (user acceptance testing, aka "customer acceptance") is completed, then we go to the next phase.

Deployment Staging

This is where you decide how and where (and when) you will get the package setup to make it ready to do the actual deployments (deployment execution).  For SCCM environments, this usually involves Distribution Points or Distribution Shares, as well as deciding (ahead of time) how you will tackle slow links, Branch DPs and Branch Caching (Windows 7 clients) and how the SCCM client will interact (download and run, or run from DP, fall-back on download/cache for slow links, etc.).

Advanced shops put a lot of work into automation of the staging process all by itself.  This may include clearing client caches or adjusting cache settings, pre-configuring branch cache options, BITS adjustments, adjusting maintenance windows (with respect to expected execution time of the package), phased scheduling and so on.  I'm not saying "un-advanced" shops don't do this.  I'm saying "advanced" shops put more dedicated time into these aspects independent of the staging and execution phases.

Disclaimer: I'm NOT an expert on SCCM concepts.  I have deployed SCCM sites.  I use SCCM daily at work.  But for a holistic view of SCCM concepts I would strongly recommend MyItforum.com or Microsoft TechNet, etc.

Deployment Execution

Deploying 50 targeted installs at once is usually not a big deal, unless your network is struggling already.  Even then, you can usually pull the trigger after hours or on a weekend, so as to avoid hurting anyone's feelings.  Going beyond a (relatively) small number of targets in a single "push", and you will want to plan for phasing the deployments.  Each environment has their own unique challenges and constraints, so there's no general guideline here.  Do whatever works for you and doesn't break things or create more work (unless you work on NMCI, in which case creating more work is part of the plan - just kidding).

Don't forget to include your FlexLM licensing environment when adding installations or moving them around.

Packaging DirectX 9.0c as an MSI

As promised (or threatened, or whatever), here's my secret recipe for packaging Microsoft DirectX 9.0c June 2010 collection into a single, well-behaved, chewing with closed mouth, sits-up-straight, says "yes ma'am!" MSI package so it can be wrapped up with Autodesk products and pushed through SCCM without imploding and causing mass casualties in far-flung lands.  Ok, it's not that secret.  I did figure it out on my own, but no sooner had I patted myself on the back than I discovered others had already crossed the minefield with all their limbs intact.  So, for what it's worth…

1. Download DirectX 9.0c Redistributable
• Example (June 2010): http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=3b170b25-abab-4bc3-ae91-50ceb6d8fa8d
2. Extract files from download (example: to C:\DX9)
3. Open Wise Package Studio (WPS)
4. Create a new Project for “Repackage for Windows Installer” (leave “Vendor Package” empty)
5. Click “Edit Package”
6. Select “Files (under Feature Details)
7. Select the Source (extraction) folder, then select \Windows\Temp in the lower panel, and click “Add Contents” (adds the “DX9” folder under “\Windows\Temp”)
8. Select the “MSI Script” tab and select the tab “Execute Deferred”
9. Click on the “InstallFinalize” action (near the bottom)
10. Double-click the action “Execute Program from Installed Files”
1. Enter a Custom Action Name: “RunSetup”
2. Executable File (click browse, select DXSETUP.exe)
3. Command Line Arguments: /SILENT
4. Select the “Properties” tab, set Processing to “Synchronous, Ignore exit code”
5. Click OK

11.   Press [F7] to compile and provide a name (ie. “DirectX90c_June2010.msi”)

Packaging and Laziness

Some people have asked me: "Dave (that's me), why are MSI installers better?"

That's a great question.  The answer is: because they just are.  Next question?

I mean, really, do I need to explain why?  Answer: No.

Seriously, I'm not going to rip open this topic and try to explain why they are better, because so many other folks have already done that for our benefit.  I suggest http://en.wikipedia.org/wiki/Windows_Installer for a general overview and links to dive in deeper if you want.

But whatever.  What…evs…. (sing that like a high pitched soprano)

There are ways to get an MSI even when your dope-smoking idiot vendors decide it's not worth their time to make one for your benefit.  Imagine that?  A vendor doing something to benefit their customers?!  Holy ****ing ****!  Anytime you encounter a vendor who doesn't give a shit about making an MSI for you it means one thing: They don't have any competition.  And that means they desperately need competition.  Anything, I repeat ANYTHING that does not have competition gets lazy, fat and stupid.  It doesn't matter whether it's a product, a technology, a type of plant, a species of animal or a TV show.

And why is this?

Because human nature is to be lazy.  Sure, we all know some irritating bastard that gets up at 4:00 AM to go running and still gets to the office at 5:30 and stays late.  That bastard will be dead by 50 from stress, so just relax and continue on being your lazy fat self.  What's that? - You don't buy my statement that human nature = laziness?  Then why are you sitting and reading this insignificant crap?  You should be out climbing mountains, finding cures for disease or at least fixing your house or car.  That's right, you know it - we're all lazy.  IT folks are the laziest.  We hate to work, so we write scripts, download utilities, and generally find ways to make things work without having to babysit them 24/7.

MSI packages are the laziest and yet most reliable way to install and (just as importantly) uninstall a software product.  If you have a clean, properly developed MSI package, you only need to know two basic things to get the job done:

msiexec /i <vendor-bongload.msi> /quiet /norestart

msiexec /x <vendor-bongload.msi> /quiet /norestart

Can you spot the difference between the two lines above?

Once you have those worked out you can drink more beer and watch more TV.  But life isn't that easy is it?  Nope.  Vendors don't just rip bongloads, they huff paint cans.  That's why they produce crappy setup.exe files and online installers that are painful to package and deploy to multiple computers.  Even worse, you call them for help, and they act like you're a bill collector seeking payment, rather than a customer to be serviced.  I vaguely remember when vendors actually TRIED to provide customer service.  Good times.  Good times (can you hear the harmonic trailing off in the distance, heavy reverb, dark alley, beer cans…)

This is why I general abhor small developers.  Some are great, and are very attentive to customer satisfaction.  But most are full of shit, obnoxious as an emancipated 12 year old, and just want the sale profit and nothing more.  Even worse than even worse is how the big vendors are adopting a "go-fuck-yourself" customer service approach. Push-button call menus, long waits, pay-per-incident calls, and offshore reps who can't understand any basic problems (let alone simple English).

Ahh, I digress (I do that when I'm drinking IPA's, sorry)  *burp* (pardon me)…

Oh yes. How to get MSI packages out of crap installers.  There are several ways:

• Try to open the .exe in WinZip or 7-Zip and extract the guts.  This sometimes works very well.  Many times it doesn't.
• Run the setup.exe and let it sit at the first Welcome form.  Then dive into your %temp% folder and look for extracted goodies.  Copy them out and see if they can be run by themselves.
• Use a setup capture utility like Wise or InstallShield to snapshot the acid-infested processes those heroine smoking developers have shoved at you during one of their convenience store robberies, and try to wrap that horrific mess into a MSI.  This is like stuffing an acid-tripping, crack-smoking aligator into a flimsy tin trash can and slapping a lid on it with duct tape.  Be careful.
• If all else fails, try setup.exe /S or /SILENT or /Q or /QUIET or /SMS or /THIS_SHIT_SUCKS_ASS or /BUY-PLAN-TICKET-TO-VENDOR-OFFICE-TO-CHOKE-CRACK-SMOKING-OBNOXIOUS-DEVELOPER
• or, just find another product and don't do business with that first vendor ever again. Ever.  Never.  As in never ever never ever ever never again.

I mean, really, this is 2010 folks.  Say that out loud, ok?  Say it. "This is 2010!"  It's the 21st century and we still have comatose paint-huffing Justin Bieber fan skateboarders writing code that drives big corporate tasks.  Is this how far we've come?  Holy crap!  We need to start a movement.  A real movement, not just a bowel movement.  A movement to evict these cough-syrup drinkers from the back alleys of software development and restore that former reputation they/we had for making customer-oriented products and services. 

This is where I would normally spill my thoughts about what Microsoft should do to reign in this insanity, but the Softards only care about shareholders and I'm not a shareholder, so, alright, I'll shut up.

Oh and in case you're wondering just what those developers you deal with really look like, here's a behind-the-scenes photo…

Autodesk Network Deployments and SCCM 2007

I hear from some of you a lot of the same issues, and rather than responding individually (because I don’t really have enough time, sorry), it might be better (more efficient, of broader benefit) to respond here.

When you build a network deployment for an Autodesk product, it builds a folder tree and populates the files needed to install each client.  But due to one particular aspect of how it builds the deployment you have to be very careful of one thing:

You cannot use replicated SCCM Distribution Points to disseminate the deployment package to multiple servers over multiple sites.

The reason is simple: In the deployment .INI file is a key named DEPLOYMENT_LOCATION, which has an assigned value that points back to the UNC path of the deployment tree itself.  It’s self-referencing.  If you copy the tree, and run the setup.exe, it will refer to the install source key value and therefore always pull everything else from the original location.

Example: Let’s say you build the deployment on a server in New York, and you have offices with AutoCAD users in Los Angeles, Seattle, Tokyo, London and Berlin.  And let’s say you have a robust System Center Configuration Manager 2007 hierarchy that lets you deploy packages from one location to all the others using the standard WAN replication mechanisms in SCCM.  The package gets copied to the DP servers in each of those locations.  The advertisements points to the program on the local DP server and runs.  As soon as it kicks off, it will start pulling files from the New York DP server.

How to resolve this?  Don’t use the DP server replication process.  Create your own DP shares and copy the deployments manually and then edit the .INI key value to suit each server location.  Here’s another article that references this as well http://web.me.com/microdev/iWeb/docs/netopts/wp4-portable-deployments.pdf

Running ADO Queries from within WinPE

I was asked to figure out how to make a script to do the following:

1. Query WMI for the Win32_BIOS.SerialNumber property
2. Connect to a remote data source using ADO
3. Query a “table” (view, etc.) for matching SerialNumber
4. Return the adjacent “AssetNumber” for the row
5. Build a BIOS/CMOS import file
6. Run the HP BIOS import utility to flash the BIOS with the new ID and other custom settings

However, there’s a few problems I encountered, which led me to a nice solution:

problem 1 – MDAC (and ADO) are not installed in WinPE 3.0 by default.  You have to run the winpe-mdac script to install it.

problem 2 – MDAC in WinPE does not behave exactly the same as it does in a “normal” Windows environment.  Some ADO properties are not supported, some methods do not return the same results, etc.

problem 3 – Security context.  The WinPE session is not part of a domain scope yet, so it’s like trying to connect from a workgroup computer to a domain resource.  It can be done, but you have to keep that in mind, especially if you are accustomed to using UNC path references within DSN-less connections.  Doh!

problem 4 – The MDAC behavior varies by what type of data source you are connecting to.  For example: connecting to SQL Server or LDAP may work fine, but connecting to a TXT, CSV or Excel XLS or XLSX may act “strange”.

Solution: FileSystemObject

Ta Da!!!

Yep.  The good ole FSO works great.  Here’s how:

• Save the data to a standard “flat-file” (I prefer tab-delimited ASCII text)
• Use FSO to read the file
• Parse each line to Split() on tabs
• Check the desired array index (i.e. table column value) and fetch the adjacent index (adjacent column value)

And the bestest best better news?  It’s more efficient anyway:

• The VBscript file for reading a text file is half as big as the same for reading an Excel spreadsheet using ADO.
• For text files up to 1000 lines the performance is nearly identical
• Our text files would rarely exceed 50, since that’s how many they image with multicast at any given time.

The code:

'****************************************************************
' Filename..: sn2computer.vbs
' Author....: skatterbrainz.blogspot.com
' Date......: 10/26/2010
' Purpose...: read comments below
'****************************************************************
' comment: this script is intended to be executed from within a _
' comment: sccm osd task sequence as part of an overall desktop _
' comment: image deployment process. it depends on the task seq _
' comment: for mapping drive Z: to the appropriate UNC share.
'----------------------------------------------------------------

Const strDataFile = "z:\deployments\computers.txt"

'----------------------------------------------------------------
' comment: constants and variable defs
'----------------------------------------------------------------

Const ForReading = 1
Const ForWriting = 2
Dim objFSO, objFile, strLine, arrRow, computerName
Dim objWMI, colItems, objItem, serialNum : serialNum = ""

'----------------------------------------------------------------
' comment: query WMI for BIOS system serial number
'----------------------------------------------------------------

Set objWMI = GetObject("winmgmts:\\.\root\CIMV2") 
Set colItems = objWMI.ExecQuery("SELECT * FROM Win32_BIOS",,48) 
For Each objItem in colItems 
	serialNum = Trim(objItem.SerialNumber)
Next

If serialNum = "" Then
	wscript.Echo "fail: unable to query serial number from BIOS!"
	wscript.Quit(1)
End If

'----------------------------------------------------------------
' comment: look-up computer asset number using serial number
'----------------------------------------------------------------

Set objFSO  = CreateObject("Scripting.FileSystemObject")
On Error Resume Next

wscript.Echo "info: opening data file..."
Set objFile = objFSO.OpenTextFile(strDataFile, ForReading)
If err.Number = 0 Then
	Do Until objFile.AtEndOfStream
		strLine = Trim(objFile.Readline)
		If strLine <> "" Then
			arrRow = Split(strLine, vbTab)
			If arrRow(0) = serialnum Then
				computerName = arrRow(1)
			End If
		End If
	Loop
	objFile.Close
	If computerName <> "" Then
		wscript.Echo "info: computer name found! --> " & computerName
	Else
		wscript.Echo "fail: computer name not found"
	End If
Else
	wscript.Echo "fail: unable to open data file for input"
	wscript.Quit(2)
End If
 
'----------------------------------------------------------------
' comment: open bios import data file and replace computername
'----------------------------------------------------------------

' <<<
' ...code for opening bios data file, replacing name, updating
' file contents and saving file - goes here...
' >>>

'----------------------------------------------------------------
' comment: finish up
'----------------------------------------------------------------

Set objFSO = Nothing

'----------------------------------------------------------------
' comment: sccm osd task sequence takes care of running hp bios _
' comment: import utility after this script is finished running
'----------------------------------------------------------------

Dear Microsoft App-V Folks:

If you were really serious about putting this gem of a product to widespread use, you would get busy doing the following:

1. Make the client free to download for all Windows 7 users

2. Make App-V available like Hyper-V currently is (licensing and cost)

3. Initiate a vendor partnership program to offer incentives to provide sequenced applications, maybe as part of a subscription "Fast-Track" advantage program.

4. Actually get behind the whole program instead just paying lip service.

Thank you!

Yours truly: Tired software packagers of the world

Teaching Pigs to Sing (and scripts to make pretty logs)

Today is Friday, and OMFG the weather is increditastical here in sunny Virginia Beach, Virginia!  Going outside feels like having someone rub your scalp and sing pretty songs in your ear.  Yeah, I can’t concentrate on anything else, but… I must.

I had a walk-up request to package MapInfo Pro 10.0 today.  But not just by itself (because that would’ve been too easy, and you can’t have “easy” on a Friday), it had to include another application called “ADAM” and then copy down a whole folder tree of content files and make a shortcut to one of them on the “All Users” Start Menu as well.  It turns out the whole bundle is aimed at installing the “ADAM” software bundle for MapInfo by Deccan International.

The vendor (Pitney-Bowes, and don’t even ask why the **** Pitney-Bowes bought MapInfo.  It makes as much sense as eBay buying Skype, but oh well, onward…) provides a setup.exe, a setup.msi, and a data1.cab file.  They also provide a nice installation guide with tips on running the setup.exe unattended by feeding in arguments using the ancient InstallShield method (you know: setup.exe /v”a bunch of crap here”), but the problem with those is that they’re ill-behaved when strung together in a sequence because they often don’t wait to finish before releasing their “mutex” (go look that one up.  It’s ok.  I’ll wait…).  Are you back?  Ok, so the better option, in most cases, is using the .MSI file and making a transform (.MST) to stuff in the arguments more efficiently.

So, I fired up Wise Package Studio, consumed a coffee, ate a trail mix bar, and made a transform for the installation that inputs the “USERNAME”, “COMPANYNAME”, “PIDKEY” (serial number) and “ACCD” (activation code).  No problem.

You can use Orca instead of Wise Package Studio, or InstallShield, if you prefer.  As long as you can make and edit the .MST it doesn’t matter.

Time to setup the deployment folder structure.  I placed it on a server share named “Packages”, under a root folder named “Deccan”, then copied the MapInfo Pro 10.0 “Disk 1” files into a sub-folder called “MI_PRO\Disk1”.  Then I copied the ADAM installation files under a sub-folder under “Deccan” named “ADAM” and another folder created for “CADAnalyst” under “Deccan”.  The structure looks like this…

\Server\Packages\Deccan\…
-MI_PRO\Disk1
-ADAM
-CADAnalyst

I placed the .MST file into the “Disk1” sub-folder, next to the .MSI file it relates to.

I then created two script files:  setup.bat, and makeshortcut.vbs

Setup.bat simply runs the .MSI with the .MST transform in “quiet” mode.  Then it runs the ADAM .MSI installation, and downloads the data files and makes a shortcut using a call to the makeshortcut.vbs (vbscript) file.  But I also wanted this to generate a self-describing log file so I could backtrace any problems or check on progress, etc.  The “echo” command is simple enough, and I add %DATE% and %TIME% to make a standard “timestamped” log entry output.

However, VBScript uses a completely different format for showing a full date, so I had to beat that into shape with a hammer (see the makeshortcut.vbs script at the end).  I needed the output from both to merge into one log file and look consistent.  That’s just me.  Maybe you don’t care that much, which is fine.  I care about a lot of stupid things.

@echo off
01. rem ****************************************************************
02. rem  Filename..: setup.bat
03. rem  Author....: Guess Who? (skatterbrainz.blogspot.com)
04. rem  Date......: 10/08/2010
05. rem  Purpose...: install MapInfo 10 + ADAM + CAD Analyst files
06. rem ****************************************************************
07. CLS
08. SETLOCAL
09. SET LOG=%TMP%\mapinfo10_setup.log
10. echo %DATE% %TIME% initializing script [test_setup] >%LOG%
11. echo %DATE% %TIME% source = "%~dps0" >>%LOG%
12. echo %DATE% %TIME% target = %computername% >>%LOG%
13. echo %DATE% %TIME% tmp = %tmp% >>%LOG%
14. echo ---------------------------------------------- >>%LOG%
15. echo %DATE% %TIME% installing MapInfo Pro 10... >>%LOG%
16. msiexec /i "%~dps0MI_PRO\Disk1\MapInfo Professional 10.0.msi" TRANSFORMS="%~dps0MI_PRO\Disk1\MapInfoPro10_1.mst" /quiet /norestart
17. echo %DATE% %TIME% completed / result code = %errorlevel% >>%LOG%
18. rem ----------------------------------------------
19. if exist "c:\Program Files\Deccan International\ADAM.mbx" (
20.     echo %DATE% %TIME% ADAM has already been installed >>%LOG%
21. ) else (
22.     echo %DATE% %TIME% installing HPC ADAM ... >>%LOG%
23.     msiexec /i "%~dps0ADAM\ADAMsetup.msi" /quiet /norestart
24.     echo %DATE% %TIME% completed / result code = %errorlevel% >>%LOG%
25. )
26. rem ----------------------------------------------
27. if exist "c:\Program Files\Deccan International" (
28.     if exist "c:\Program Files\Deccan International\CADAnalyst" (
29.         echo %DATE% %TIME% the CADAnalyst folder was already created >>%LOG%
30.     ) else (
31.         echo %DATE% %TIME% downloading data files for CAD Analyst... >>%LOG%
32.             xcopy "%~dps0CADAnalyst\*.*" "c:\Program Files\Deccan International\CADAnalyst\*.*" /s /y
33.         echo %DATE% %TIME% download complete... >>%LOG%
34.     )
35. ) else (
36.     echo %DATE% %TIME% error / target folder Deccan International not found! >>%LOG%
37.     exit /b 1
38. )
39. rem ----------------------------------------------
40. if exist "%allusersprofile%\Start Menu\Programs\CAD Analyst.lnk" (
41.     echo %DATE% %TIME% shortcut already exists >>%LOG%
42. ) else (
43.     echo %DATE% %TIME% creating a start menu shortcut for cad analyst .mbx file... >>%LOG%
44.     cscript /nologo %~dps0makeshortcut.vbs "N=CAD Analyst" "T=c:\Program Files\Deccan International\CADAnalyst\CAD Analyst.MBX" "L=2" "W=c:\Program Files\Deccan International\CADAnalyst" "D=CAD Analyst" >>%LOG%
45. )
46. echo %DATE% %TIME% installation complete! >>%LOG%
47. ENDLOCAL
48. exit /b %errorlevel%

The %errorlevel% variable is used to capture and display the result code of the last-run command, which is “msiexec” in each case.  Then I force a script “exit” using the /b option and a return code that is non-zero if an error occurs.  If all proceeds along fine and finishes properly, the %errorlevel% result code at the very end should be zero (0).  Most deployment tools see zero as “good” or “no errors occurred”.

Then comes the makeshortcut.vbs script, for making the shortcut.  I could have downloaded some utility .exe to call instead, but I prefer making my own stuff so I know who to blame when it explodes or implodes.

'****************************************************************
' Filename..: makeShortcut.vbs
' Author....: Guess Who? (skatterbrainz.blogspot.com)
' Date......: 10/08/2010
' Purpose...: create a shortcut
'****************************************************************
Dim objArgs, fso, oShell, i, arg, scName, scTarget
Dim scFolder, scCaption, scLoc

Echo "info: makeShortcut.vbs --> processing inputs..."
Set objArgs = WScript.Arguments
If objArgs.Count = 0 Then
    Echo "error: incorrect number of arguments supplied"
    Echo "-- example..."
    Echo "-- makeShortcut.vbs ""N=name"" ""T=target"" ""W=folder"" ""D=description"" ""L=loc"""
    wscript.Quit(1)
Else
    Echo "info: " & objArgs.Count & " arguments were provided"
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set oShell = CreateObject("Wscript.Shell")
    For i = 0 to objArgs.Count - 1
        arg = objArgs(i)
        Select Case Ucase(Left(arg,2))
            Case "N=":
                scName = Mid(arg,3)
            Case "L=":
                Select Case Right(arg,1)
                    Case "1":
                        ' all-users desktop
                        scLoc = oShell.ExpandEnvironmentStrings("%allusersprofile%") & "\Desktop"
                    Case "2":
                        ' all-users start menu / programs
                        If fso.FolderExists("C:\ProgramData\Microsoft\Windows\Start Menu\Programs") Then
                            ' check for windows 7 client first
                            scLoc = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs"
                        Else
                            ' default to assuming windows xp client
                            scLoc = oShell.ExpandEnvironmentStrings("%allusersprofile%") & "\Start Menu\Programs"
                        End If
                    Case "3":
                        ' current user desktop
                        scLoc = oShell.ExpandEnvironmentStrings("%userprofile%") & "\Desktop"
                    Case "4":
                        scLoc = Mid(arg,3)
                End Select
            Case "T=":
                scTarget = Mid(arg,3)
                If fso.FileExists(scTarget) Then
                    Echo "info: shortcut target has been verified"
        	Else
                    Echo "error: shortcut target could not be found!"
                    wscript.Quit(2)
                End If
            Case "W=":
                scFolder = Mid(arg,3)
                If fso.FolderExists(scFolder) Then
                    Echo "info: shortcut working folder verified"
                Else
                    Echo "error: shortcut working folder could not be found"
                    wscript.Quit(3)
                End If
            Case "D=":
                scCaption = Mid(arg,3)
        End Select
    Next
    If scFolder = "" or scTarget = "" or scName = "" or scLoc = "" Then
        Echo "error: insufficient arguments provided"
        wscript.Quit(4)
    Else
        Echo "validating shortcut parameters..."
        Echo "-- name     = " & scName
        Echo "-- target   = " & scTarget
        Echo "-- path     = " & scFolder
        Echo "-- location = " & scLoc
        Echo "-- caption  = " & scCaption
        On Error Resume Next
        Set oShortcut = oShell.CreateShortcut(scLoc & "\" & scName & ".lnk")
        If err.Number = 0 Then
            Echo "info: creating shortcut..."
            oShortcut.TargetPath = scTarget
            oShortcut.WorkingDirectory = scFolder
            oShortcut.IconLocation = scTarget & ",0"
            oShortcut.WindowStyle = 1
            oShortcut.Description = scCaption
            oShortcut.Save
            If fso.FileExists(scLoc & "\" & scName & ".lnk") Then
                Echo "-- shortcut has been created"
            Else
                Echo "-- failed to create shortcut!"
            End If
        Else
            Echo "-- access denied to the specified location!"
        End If
    End If
End If
 
'----------------------------------------------------------------
' comment: echo runtime progress
'----------------------------------------------------------------
 
Sub Echo(s)
    wscript.Echo DosDate() & " " & s
End Sub
 
'----------------------------------------------------------------
' comment: format date stamp to match DOS %DATE% %TIME% format
'----------------------------------------------------------------
 
Function DosDate()
    dn = Left(WeekDayName(WeekDay(Now)),3)
    mo = PadLeft(Month(Now), "0", 2)
    dd = PadLeft(Day(Now), "0", 2)
    yr = Year(Now)
    x = mo & "/" & dd & "/" & yr
    DosDate = dn & " " & x & " " & FormatDateTime(Now, vbShortTime) & ".00.00"
End Function
 
'----------------------------------------------------------------
' comment: pad string on left side with char to requested length
'----------------------------------------------------------------
 
Function PadLeft(sVal, ch, max)
    Dim tmp
    tmp = Trim(sVal)
    Do Until Len(tmp) = max
        tmp = ch & tmp
    Loop
    PadLeft = tmp
End Function

Together, these run the installations, copy the files, make the shortcut, create a nice log, save the girl, kill the bad guy, and free the hostages, with rolling credits at the end and sweet theme music.

Now I can check the “mapinfo10_setup.log” under the %TEMP% folder path to see what’s going on.  Note that when you deploy this as a SCCM package, it runs as the local account “NT_AUTHORITY\SYSTEM” (aka “SYSTEM”), so the %TMP% and %TEMP% paths are C:\WINDOWS\TEMP (or %WINDIR%\TEMP).

I’m done.  Beer time folks.  It’s a tough job, but someone’s gotta do it.