Tech-Ed 2011, Moving, and Chromebook

On Sunday I'm flying out to Microsoft Tech-Ed in Atlanta, GA for the next week.  It will be an incredibly busy time I'm sure.  But it should be a fun time as well.  I've been working with software technology since 1987 with no detours at all.  I've been working primarily with Microsoft technology since about 2002 or so.  I attended four Autodesk University conferences (Los Angeles, Boston, Philadelphia and Las Vegas) but never a Microsoft conference.  I'm looking forward to this one very much.

On the "Moving" side, it looks like my family and I will be packing up sometime in the next few months and moving to a new place.  Still in Virginia Beach but the actual domicile is not yet determined.  Therefore, when the packing-and-moving time arrives, my blog presence may become scarce.  Just a heads-up (not that it really matters to anyone else, but just in case).

My beta edition Google Chromebook is still kicking.  And speaking of Tech-Ed: I was facing the dilemna of what to bring for taking notes and downloading files, code snippets, etc.  Either the Google Chromebook, or my wife's tiny little Asus netbook with Windows 7.  And the winner of this decision is?…… drum rolll…..   The netbook.

I just can't see myself going to a huge, no scratch that, the HUGEST, Microsoft conference of the year, and pulling out a Google product to do my evil doing.  I might get gang raped in the men's restroom or something.  Imagine being attacked by a pack of MCITP nerds?  Geez.  Just the thought makes me cringe.  So, as goofy and toy-ish the netbook may appear, it does have Windows 7 and can install my favorite code writing apps.  Chromebook lacks a means to do serious code writing, not to mention uploading photos and files from a USB thumbdrive (it has a USB slot, but no way to upload files from it), nor can I synch my podcasts from iTunes to my iPod on it. So the Windows 7 netbook is the winner for me.

Read More

AutoCAD Profiles

What is a Profile?

An AutoCAD "profile" is a named collection of configuration settings.  A Profile may include options that control display, modeling, user interaction, printing and plotting, saving, importing and exporting, units of measurement, and so on.  There are essentially two types of "Preferences" in the AutoCAD environment: Application and Database.  "Database" is another word for "Drawing" in this context, so "Database Preferences" translates into "Drawing Preferences" or configuration settings that are drawing level or drawing-specific.

How are they stored?

They are actually stored as Windows Registry keys under the path: HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R18.2\ACAD-A001:409\Profiles\

The first profile created by default is the "<<Unnamed Profile>>" but as you create new profiles they will be added under the \Profiles\ path as well.

How are Profiles accessed and controlled?

There are several ways to get at profiles.

• From the OPTIONS dialog forms within AutoCAD
• From the Windows Registry
• From exported .ARG files
• From programmatic interfaces like COM and .NET

The first method is pretty simple and self-explanatory. So let's dig into the others.

The Windows Registry is where profiles are stored and maintained.  When you create a new Profile within the OPTIONS dialog, it creates a new sub-tree with the corresponding name and populates it with all the pertinent keys and values to store the profile configuration.

If you export the profile from within the OPTIONS dialog, it creates an .ARG file.  This is actually a .REG file (a Windows Registry export file format), so you can very easily rename a .ARG to .REG and use it like any other Registry data file (import, export, archive, etc.)

The programmatic interfaces for accessing and manipulating profile data are most often via .NET or the older COM interfaces.  Because they are stored in the Windows Registry, ANY other programmatic interfaces that can manipulate the registry can be used as well.  When it comes to leveraging .NET interfaces, you can pretty much narrow that down to Visual Studio tools like VB.NET, C#.NET, PowerShell, as well as ObjectARX®   When it comes to COM interfaces, you can use anything that talks COM.  Some examples include VBscript, Javascript, KiXtart, PowerShell.

Programmatic Access to Preferences

VB.NET

Dim acPrefComObj As AcadPreferences = Application.Preferences

C#

AcadPreferences acPrefComObj = (AcadPreferences)Application.Preferences;

VBA

Dim acadPref As AcadPreferences
Set acadPref = ThisDrawing.Application.Preferences

Visual LISP

(setq objAcad (vlax-get-acad-object))
(setq objAcadPrefs (vla-get-Preferences objAcad))

Windows Scripting Host - VBScript

Because VBScript is external to the AutoCAD application environment, it must first obtain an object instance of the AcadApplication class in order to begin drilling into the internal objects, properties, methods and so on.

Dim objAcad, objAcadPrefs
Set objAcad = CreateObject("AutoCAD.Application")
Set objAcadPrefs = objAcad.Preferences

Programmatic Access to Profiles

VB.NET

Dim acadApp As AcadApplication = CType(Application.AcadApplication, AcadApplication)
acadApp.Preferences.Profiles.ExportProfile("PROFILE_NAME", "C:\test.arg")

This is one way to get at Profiles from within an AutoCAD session environment.

Visual LISP

This is (or these are) another example of getting at Profiles from within AutoCAD.

example: linear expression…

(setq objActProfile (vla-get-ActiveProfile (vla-get-Profiles (vla-get-Preferences (vlax-get-Acad-Object)))))

example: unfactored collection of expressions

(setq objAcadApp (vlax-get-Acad-Object))
(setq objAcadPrefs (vla-get-Preferences objAcad))
(setq objProfiles (vla-get-Profiles objAcadPrefs))
(setq objActProfile (vla-get-ActiveProfile objProfiles))
(vla-ExportProfile objProfiles "Fubar" "c:\fubar.arg")

Windows Scripting Host - VBScript

This is an example of getting at profiles from outside of AutoCAD.

The downside to accessing the Profile collection via a non-object interface is that you don't get the nice object-oriented methods and syntax that make it kind of neat-o to use.  So instead of crawling the object tree, as it were, you have to fetch each entity as a distinct data value.

setq objShell = CreateObject("Wscript.Shell")
path = objShell.RegRead("HKCU\Software\Autodesk\AutoCAD\R18.2\ACAD-A001:409\Profiles\MyProfile\ACAD")
For each folderName in Split(path, ";")
    wscript.echo folderName
Next

Keep in mind that the Wscript.Shell RegRead() method is only useful on the local computer.  But this isn't really an obstacle since you don't really want to access HKCU on a remote computer (you have to first map the user SID to obtain the HKEY_USERS path because HKCU is a pseudo registry hive that exists only under the local user context).  So… you can do it, but you have to ask yourself if it's really the best approach to getting at things on a remote computer.  Why not invoke the interface under the local user context?

PowerShell

$a = get-item HKCU:\Software\Autodesk\AutoCAD\R18.2\ACAD-A001:409\Profiles
$a.SubKeyCount <-- returns the number of profile trees beneath the Profiles path
$a.GetSubKeyNames() <-- enumerates the profile names

The upside to using PowerShell over VBscript is that you can invoke object programming techniques.  This is because $a (in this example) is actually an object instance.  There are other ways to employ PowerShell, so don't think this is the only possible approach (it's barely scratching the surface).

Group Policy Preferences

That's right.  As astounding as it may be, I have long ago recommended Windows admins explore the use of Group Policy Preferences for managing and manipulating computer settings with less effort than scripting typically requires.

But you say "Dave?! How can you suggest we leave scripting out in the cold, starving and dying of neglect?!  How cruel!"

Fair enough.  But once you see how easy it is to create, modify and delete registry keys and values on a bazillion computers, you will look at your old login and startup scripts like the old girlfriend you dumped years ago (and never regretted).

Possibilities

They are almost endless.  For example, using the available tools and technologies, you can rig up a way to automatically reset profiles for classroom settings (if you don't use virtual machines to handle state management).  You can deploy and update a standard profile for specific business groups, locations or for the entire operation.  If a path reference is set in a default profile, but later needs to be changed (and you didn't map it to a DFS target) you can push out a fix using scripts or even a Windows Group Policy Preferences object setting.

Conclusion / Summary / Mumbo-Jumbo Ay Carumbo!

I have no intention of trying to create an ebook expose to exhause every conceivable way you can get at Profiles, create, rename, modify, delete, import or export them.  I also did not intend to cover every programming language or programmatic option available or possible.  The goal here is to simply show the following:

1. The Preferences and Profiles items are structured and fairly well-defined
2. They are accessible from a lot of different angles using a lot of different tools
3. You have choices and options at your disposal

That said: go forth and hack away.  Just don't call me if you break anything.

Read More

I'm Almost Semi-Famous!

Shaan Hurley asked me to write something for his blog as a guest, so I wrote about the significance of Autodesk announcing support for AutoCAD 2012 on Citrix XenApp.

Read the article here: http://autodesk.blogs.com/between_the_lines/2011/05/autocad-2012-citrix-xenapp.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogs%2Fbtl+%28Between+the+Lines+RSS+Main%29

Thanks Shaan!

And, in case you haven't read Shaan's blog, you should.  He also takes incredible photos of places he travels to, which I highly recommend checking out.

Read More

Counting Grains of…

This one sprang up from a drawn-out conversation about some article that proposed comparing the relative "kill ratio efficiency" of today's U.S. military with that of past conflicts like Vietnam, Korea, WWII and so on.  The article, and a few of the folks in the conversation as well, were convinced that you can somehow assess a meaningful rating of "killing efficiency" by measuring bullets expended versus body counts.

This is utter useless bullshit.

My head was spinning as to where to even begin to blast holes (pardon the pun) in this ridiculous dumbshit logic.  I tried to apply some logical/methodical approach, but my emotional turmoil dragged my brain through a toilet bowl of hostile intentions.  Where was I?  Oh yeah…

Just in case one of you (fine, upstanding readers) out there thinks I'm wrong, hear me out, please?

First off, counting bullets is a myth.  All by itself, that is an insanely stupid concept, and here's why.  Anyone that understands the process of defense supply management knows that during peacetime logistics is not perfect.  Shipments leave one place and often end up in the wrong place, or in many wrong places.  They often end up in different condition or quantity than when they left their origin.  Again - that's in peace time.

In wartime, it's like a Chuck-E-Cheese on a Saturday when someone replaced the soft drink tanks with Red Bull and LSD and sprinkled caffeine pills on the pizza slices.  Ok, that's a little inaccurate.  It's more like sprinkling crushed Viagra pills and caffeine pills on the pizza.

At each step of the way things get touched and quantities change.  Loss, damage and theft claim some.  Then some are used on training (official and bullshit goofing around training).  Then there's the real bullshit like shooting goats, pigs, chickens, trees, abandoned vehicles and buildings.  Some are shot into open sea.  How do you count how many bullets were INTENTIONALLY shot at "bad guys" versus all other things (and reasons) that you can shoot them at?  So if you could somehow (accurately) measure how many stupid-ass things were shot at in Vietnam and also (accurately) in today's theaters of battle, then you would still need to isolate accurate and meaningful numbers for the other aspects.  It's an impossible task.

Here's one example I gave:  So, if John Doe, SEAL team member, uses up a box of 2,000 rounds of ammo practicing on bottle caps at 1000 yards, but then turns around and fires one (1) shot at a bad guy, does that mean his "killing efficiency" is 1:2000?  And how would anyone ever know if 1000 rounds were aimed poorly during a real fire fight or shot at bottle caps?  I don't ever recall a form being filled out for:

___ shot at bullshit

___ shot at bad guys

___ still embedded in the bad guys

Read More

The 50/50 Rule

It's been a long time since I posted some philosophical bullshit, but don't think you're getting off the hook that easily.

I have a thing about the use of the words "rule" or "axiom" or "law".  From a mathematical viewpoint, those imply a certain organic aspect.  That if they are truly framework terms, they must (read MUST) apply under all conditions or they are crap.  Saying that something is a "rule" means it is valid and viable at all times, under all circumstances, and within all reason.  So I have a rule that I call the "50/50" rule.  So far it has held up very well and not been proven false or faulty under any conditions.  So far.  What is it?

The 50/50 rule boils down to 50 percent given, and 50 percent applied.  In other words, most things in life that qualify as being an "opportunity" actually consist of 50 percent existing conditions combined with 50 percent leveraging.

A person's succes in life is 50/50.  50 percent what they're born with plus 50 percent what they do with it.

A business' success if 50 percent what they have and 50 percent what they do with it.

I thought of this today at work.  I have a habit of pausing to take in the surroundings and try to consider things I normally overlook.  It can be visual, auditory, or just gut feeling.  But today it was about: what is it about the office that makes it a great place to be?

It's a combination of two things, which are EXTREMELY rare to find in one place:

• People who are fun to be around
• People who want to accomplish "new things"

Sounds basic enough.  This isn't really the 50/50 though.  This is actually 25+25 that adds up to the 50 percent of what they have.  Management and workload are what make up the other 50 percent.

You can hire cool, talented people.  But if the management sucks they will soon leave.  If the workload sucks, they will soon leave.  The potential is wasted.  Likewise, you can have great management, a fantastically innovative business idea and all the money and resources in the world.  But if you can't hire the right people to glue it all together, it will also soon fall apart.

After years of shuffling between disperate business cultures and office environments, I have found just how incredibly rare it is to find both of these in one place.  We have a group of people that are sharp, funny and work well together, combined with a management layer that understands not only their value, but what challenges and interests them day to day.  That means they are able to look ahead and chart a path that guides the workload to the workers in a way that is challenging but not dumb or boring.  They also allow them a ton of latitude to come up with their own solutions, as long as they can quantify and prove them at game time.

50 percent great talent, plus 50 percent great management.  Rare indeed.  And the most interesting part of this is that most of the people involved (not all, but most) don't have a lot of outside, comparative experience to gage just how rare it really is.  It's kind of like a girl that's really hot but really doesn't believe she is hot.  I know - that's even more rare.  But you get the idea.  I have to soak this up while I'm able to.  I try to learn from every experience.

Read More

VBScript Bulk Import for MDT 2010

Michael Niehaus had posted a nice blog article on using PowerShell to perform bulk import of computers into MDT 2010.  My near-term project pipeline has me working more with VBscript and ASP than PowerShell, so I needed to figure out a way to port at least a basic portion of Michael's efforts to help with what I was working on.  I didn't go as far into building out a mini-API like he did, but I did manage to get the bare minimum working: bulk computer import.  The script is only built for reading a simple CSV format text file right now, but it could easily be modified to read from XML or Excel or pretty much any FSO or ADO data source.  The script is posted on my download page at https://sites.google.com/site/skatterbrainz/downloads/mdt2010.vbs.txt?attredirects=0&d=1   Read the comments in the heading (including the snooze-fest disclaimer stuff) and kick the tires. Let me know if it works for you or not?

ok, actually, the path that led me to Michael's article was like this:  I downloaded MDT Web Frontend from Codeplex and played around with it.  I emailed Maik Koster about how to make it capable of bulk/batch computer import and he pointed me to Mitch Tulloch's tutorials on MDT 2010 and the one (part 22 actually) on using Michael Niehaus' bulk import PowerShell script.  Phew!  See what happens when you fall down a slippery slope?  Amazing things happen.

Read More

Windows Web Admin build 2011.05.02.001

This will be the last build update for a while I think.  I'm quickly running out of free time and will have to put this on hold for at least a few weeks or a month or so.  This update includes quite a lot of changes and enhancements.  I've added several new Active Directory reports and a new page just for those (like I did earlier with the SCCM reports).  Among the changes:

1. Moved AD reports to their own page

2. Added new AD reports

3. Modifed AD FSMO report to link over to computers report

4. Users report shows icon for "user" versus" contact rows

5. User details now shows GUID values

6. Added Contact details

7. Renamed "Reports" to "SCCM Reports"

https://sourceforge.net/projects/wwadmin/

Read More