Coming Soon: The AutoCAD 2015 Network Administrator's Bible

It's long overdue.  I'm long overdue as well.  It's been a long time since I've devoted myself to writing anything about AutoCAD or network deployments.  I'm almost done with editing this book and it should be available for purchase on Amazon Kindle very soon.  Remember that you do not need a Kindle device to read Kindle books.  There are free Kindle reader apps for iOS, Android, Windows, Mac, and more.

Here's a summary of topics included:

• Deploying with Scripts: Batch, VBScript, and PowerShell
• Deploying with System Center Configuration Manager 2012
• Deploying with MDT 2013
• Using Task Sequences
• Dealing with Requirements: .NET 3.5, using Global Conditions, etc.
• ADNM
• Deployment Shares
• Network and Client Logs
• Building a Virtual Test Environment with VMware Workstation
• Stupid jokes.  Dumb comments.  Awkward silences.
• And more!

Why PowerShell is a Big Deal (In my own feeble words)

If you've followed my blog for a while (my apologies, of course) you're probably wondering just what the **** I'm aiming for.  That's a fair question, because, to be honest: I really don't know.  It's a venting machine for me, I suppose.

For a long time I ranted on about Autodesk products and AutoCAD customization, then it turned into Autodesk product installation and licensing management, and networks, and then I had an unplanned career change dropped on me from nowhere. I had to make a shift into the "mainstream" IT world and learn Microsoft tools and things entirely different than I was accustomed to. Since then, my professional and personal life has been a blender, tossed into a woodchipper and fed into a meat grinder.  Messy, yes.  A disaster?  That depends on how you define the word.  Blah blah blah, yes, I'm aiming for a point here somewhere, please be patient?  Your call is important to us...

I started playing with program code back in 1986, while working as a drafter in the Marine Engineering field.  That's fancy terminology for designing things that go on ships.  In my case: U.S. Navy ships.  Big. Heavy. Gray.  Smelling like oil. And usually parked in some rather unappealing locations in the worst kinds of weather.  We would go aboard, sketch up stuff, go back to our hotel, eat and drink (okay, mostly drink) and then return to the office and formalize a set of design drawings to accomplish a "retrofit" of something.  A "retrofit" is basically replacing something to improve some aspect of the ship (performance, capability, living conditions, etc.)

After CAD took hold among the DoD world, it took much longer for the mainframe and workstation era to pass and open the door to the PC world, than it did in other industries (i.e. AEC).  It wasn't until around 1987 that the Naval Shipyards would even "allow" the use of AutoCAD for any official drawing contracts.  At first it was only allowed for title sheets, materials lists and anything "non detail design".  Eventually, they gave in and began replacing all the old DEC, Sun and IBM crap with shiny new IBM-PC boxes and much cheaper software.  In all, it saved them enough on budget to buy a small country (they probably did just that).

I got my first taste of "real" programming in 1987 from reading a book on AutoCAD R10 and learning AutoLISP and a little ADS later on. AutoLISP was it.  Even while going to college for my IS degree, and soaking up C/C++, and all that, I couldn't ignore the flexibility and dynamic personality of LISP.  At the time, it was like trying to remain focused on a mail delivery truck while I kept my eyes on the '67 Camaro SS parked on the side.  Not much competition in my mind.  But alas, marketing won and LISP began a slow decline from the 1990's into the mid 2000's.  Microsoft's unstoppable licensing machine eventually mowed down the momentum behind anything besides Visual-This and That.  I can't pick at the technological appeal either, so I'm just whining I suppose.

Soon after the mid 1980's I picked up BAT and KiXtart on the PC side, and Bash/Korn and Perl on the UNIX side (mostly at school).  Then I ran into the database world and began mashing AutoLISP with AutoCAD CAO and ObjectDBX, which dropped me into a rat hole called Visual Basic.  It was fun and lasted me through the mid 1990's very nicely.

Long story short:  I gradually became jaded by every new programming language coming out.  It seemed like yet another attempt to get the junkies hooked on a newer drug and keep the marketing departments employed.  Tech conferences kept shoving one new language or toolset after another and spending tons on spiffy ads and graphics.

I thought PowerShell was just that.

I was dead wrong.

For years, my colleagues would roll their eyes at me, when I'd start pontificating about "Microsoft should __", following my third cup of coffee.  As if anyone in Redmond gives a shit about some annoying guy named Dave out in the redneck state of Virginia.  My usual rants involved the lack of cohesion and consistency among the various command tools.  Things like NETSTAT, NET this-or-that, IPCONFIG, NTDSUTIL, DSGET/whatever, DIR, and then CMD and BAT scripting weirdness.  I kept saying "they need to clean this shit up!" and then I would fade off into a muffled blubbering of incoherent words and slurping coffee (cold and stale, usually).

Even after I jumped on the Monad open preview bandwagon, I didn't get it.

I read articles and still didn't get it.

I bought books and still didn't get it.

I went to Microsoft TechEd 2011 and 2012 and didn't get it. (I did get a few t-shirts though)

Then I read a few blog posts by Jeffrey Hick, Jeffrey Snover, and Don Jones and a few others.  And then after studying for some MCITP/MCSA exams, it hit me like a train:  THIS is what I was begging for.  Granted: It hasn't reached the goal line yet, but damn if it hasn't made it a long way down the field.  In fact, from my poking and inspecting, I would dare to say it's in the Red Zone and there's still plenty of time on the clock. (sorry to all non-Football fans, I feel you - but I couldn't think of a better analogy this late at night).

I've been dragging ASP, BATch, VBscript and COM around like a two-year old child with a dead pet on the other end of a worn leash.  Thinking it was still alive and wanting to go play outside.  Now I know what that smell was.

I'm in.  My focus from here on out will be to deprecate my use of anything besides PowerShell and ASP.NET.  If your eyes are rolling in pity right now, I apologize.  I'm really late to the party, so I have a lot of drinking to catch up on.

Namaste.

Knowing Which Seeds to Water

(Warning: I've had some coffee today)

In The Beginning

In 1990, at the age of 26, I worked as a drafter for a small Naval engineering firm in Virginia.  It was my third job in the field of naval design, and I was assigned to work in the Piping Systems Division with maybe two dozen others, in support of contracts for overhauling U.S. warships.  It was during this time that PC-based CAD entered the foray in the defense industry.  ThisCAD and ThatCAD were everywhere, but AutoCAD was the eventual, and clear winner.  Until then, everything with "CAD" in the name wasn't even considered unless it ran on UNIX-powered hardware.

While learning to use this new "AutoCAD" tool, I tripped over something and looked down to realize that inside this little product was a shiny gem called "AutoLISP".  A customization programming tool, built right into the product!  Having tinkered with CMD and Batch scripting for MS-DOS and Windows, I was addicted from that moment on to programming.  Mainly because it made it possible to draw and "create" visible objects on the screen, rather than a bunch of numbers and text.

After a few weeks, I built some menus, functions (or "routines", as they were often called then), and eventually wrapped them in dialog forms and prettier stuff.  After sharing them with my coworkers, I began to get feedback and ideas started coalescing like a tropical storm into a hurricane.  The momentum continued to build and within a few months I had a complete "design package" for automating much of the tasks involved with creating and validating engineering and design drawings for piping systems.

Auto-Something-or-other

Not long after that threshold was crossed, I spread out into HVAC systems, and eventually into the other primary system groups involved with nautical engineering: Structure, Outfitting, Machinery, Electrical and Electronics.  Then it was on to building the top of this strange pyramid:  Notes, References, Sheet Formats, Materials Lists, Tables, and so on.  In much the say a Lego kit ends up becoming a city with elevated monorails and skyscrapers around a kid's room, I ended up gluing in data files, database tables and views, symbol tables, icon files, drawing parts (block inserts, XREFs, etc.).  Building on top of what a predecessor from our New York office had started, it became an entirely new animal.

My boss was supportive, as was the Department Manager, and the Division Manager.  But once it cleared the cloud layer, things got less clear.  I never asked for a raise or a promotion, oddly enough. All I asked for was the approval to tap a few key "power users" in each department to form a "team" to help improve this automation tool even further and faster.  Silence.

In 1996, I was contacted by a much-larger company, a nearby shipyard, to take on a newly created role of "AutoCAD Systems Manager" for an entire Division.  That meant a lot of things at once for me:  Automating the deployment (installation), configuration, maintenance and licensing of AutoCAD and AutoCAD Mechanical Desktop to roughly 1,300 users.  There were other Divisions, but they were tied to UNIX products and rebuffed any consideration of anything that ran on a scruffy PC. This offer also meant I'd take over licensing administration (i.e. FLEXlm), and my prized role: Customization.  Oh yeah, it also meant a considerable pay increase and better benefits, but customization was what I had my eyes on the entire time.

Project: Mariner

Within a few months of that new job, I began building an entirely new suite-based, collection of design automation tools to run on AutoCAD and MDT for Piping, HVAC, Mechanical, Hull-Structure, Hull-Outfitting, Electrical, and Materials.  This new beast grew a beard and a deeper voice and eventually was named "Mariner".  A fitting name I thought.  I sure get wrapped around the axle when it comes to choosing a name for software projects, but that's for another story.

This process continued to grow and I was allowed to form an unofficial "team" to help maintain and improve it as well. Once again, I never asked for a raise or promotion, but things seemed to progress much more easily.

Sometime in late 1999, this shipyard began contracting in designers from local firms to handle the capacity of work going on.  The contractors were required to learn this new abstraction layer, so I embarked on developing a training guide, a training course and even was authorized to issue training certificates for completion of the training.  Seriously, they printed some 1400 books with color graphics and sturdy permanent binder edges.  Nifty stuff!

Project: ShipWorks

In early 2000, one of the contractors asked if they could license this "Mariner" product to use back in their offices.  The rationale at the time involved a lack of physical space at the shipyard to bring in any more contractors, while the workload continued to rise.  I approached the corporate overlords, their legal masters and the contracts department gurus and soon there was a "first-ever" licensing contract produced to allow their "partners" to use this product.  Until then, no other such vehicle had existed, or so I was told.  Then, I inquired about approaching Autodesk or some other (no defunct) software vendor, to help take it to the next logical level: external marketing.  There was interest from nearly all of the outside contracting firms, as well as several software vendors.  The company said: "NO.  We are not a software development company."

Growing tired of the lack of management support, I accepted an offer to work for a local Autodesk product reseller.  I submitted my two-weeks notice and packed my belongings to move on to yet another employer.  On my last Friday, I received a phone call from the contracting firm that had initially approached our company about licensing Mariner.  They heard I was leaving and they counter-offered and, me being stunned and shocked, I accepted it.  I went to that new employer and, again, started development on a totally new product, incorporating all of the lessons-learned from the Mariner project.  This animal grew into something called "ShipWorks".  Much to the chagrin of Autodesk, it was not ever intended to run on Solidworks, nor was it ever attempted.  Still, they were obviously not too happy about the "works" suffix.  Just an odd side note now, I think.

That leg of my journey into the software technology world is where I officially transitioned from a mostly-engineering environment into a mostly-IT environment.  I absorbed managing Windows Server, SMS and Configuration Manager, WSUS, RIS and WDS and a whole bunch of other weird things that I found interesting and helpful, and which helped cut costs and make for a better computing environment.

In this new role, I was given a team, management support, resources and things finally to be on a good track.  Then in 2007, the company was sold and split apart.  I ended up bouncing to a consulting firm, which lasted about three months, when the economy tanked, and I had to make ends meet doing side work for a few months before crawling on my knees back to the shipyard and beg for my job back.  They graciously accepted.

From here on, I haven't touched AutoCAD much at all.  Most of the work I've done since involves things like ASP or PHP, along with SQL Server, Oracle, Active Directory, SMS or Configuration Manager, Inventory systems, Service Request systems, and so on.  Basically, gluing things together horizontally with a big bucket of sticky web application goo.

Looking Back

Every one of the places I've worked at, I've built something custom to help them operate more efficiently and tried to make the users happy with the results.  In every case, my immediate supervisors were very supportive.  In every case, when it went above my immediate supervisors things got shaky and less reaffirming.  The support and reinforcement began to vaporize the higher I went.

The Takeaway

Over the past twenty-odd years, I've seen more potential wasted because someone decided a project was not worthy of basic consideration.  Not even giving it a second thought.  The results could have been astoundingly helpful for a lot of people and businesses.  Too quick to judge, was always the culprit to killing the dream before it could begin to take shape.  I'm writing this today because I still see this happen too often, in too many places.

If you have a lone developer, or a small team of developers, within your business, official or not, and they are actually producing useful things, support them.  Especially if they don't ask for monitory compensation, but they simply want to see that management cares and wants to help them push it further.  Maybe it's outside of your "core business" comfort zone.  Maybe you never considered your business to include this mysterious thing called "applications development".  Try making it work anyway.  You say you have "gut instincts" for business, well, use them.  You might be amazed what good can come from it.  I'm not suggesting you rubber-stamp every app-dev project without checking on it's merits.  Verify and validate them all.  But just don't reject them simply because they involve "application development".  That's an unforgivable crime of business.

Cheers.

10 Questions: with Shaan Hurley

Shaan Hurley

Introduction

If you've used AutoCAD, or any flavor thereof, in the past ten years, you should have at least heard the name: Shaan Hurley.  Unless you just dabble with it, and don't really try to push it anywhere close to its limits.  If you've even leaned against it enough to make it squeak a bit, you should know his name.  If you went to any of the Autodesk University (AU) conferences in the past two decades (sorry, not trying to date anyone here) you HAVE to know his name.  If you attended them and don't recall his name, you're either braindead, or spent your entire week there in a bar.

Shaan is synonymous with AutoCAD customization.  I tried to summarize it with all sorts of words, but that's about the best and most succinct combination of terms I could muster.

At AU 1997 in Los Angeles, I ran into Shaan, in person, for the first time.  It was a weird situation, after several strangers (i.e. people I had never met or known beforehand) had approached each of us, separately, and made some comments to the effect that there was some animosity between us.  As far as I knew, there was none.  Mainly since I had never met Shaan before and my online conversations with him were very limited and technical in nature.  So, long story short: We saw each other from across a huuuuuuge expo floor area, and cautiously walked to a midway point.  The conversation, as I recall, went something like this:  "Um. Hi Shaan." "Um, Hi Dave".  "How are you?" "Good! How are you?" "Good!" followed by some chuckling and relief.

I've always respected Shaan, and what he's meant to the world of CAD/CAM software engineering and design.  As you'll see in the questions below, he's very much customer-focused; always thinking about the products from the user's point of view.  Without that, I can't imagine where the entire industry would be today, let alone Autodesk, or even "PC-based" CAD features.  Anyhow, I hope you enjoy this (I sure did)!

The Questions

Dave: When did you first put your hands on AutoCAD? What were you doing with it (project-wise)?

Shaan: It is a little blurry but I believe it was around 1989/90 and AutoCAD R10 or R11. I was using it to design a pressure vessel for a pharmaceutical company. It was pretty intimidating at first to draw the drawings so that the fabrication shop would not come back in the office and yell at me.

Dave: What was the first programming language you learned?

Shaan: Here we go into the way way way the hell back time machine, I learned to program using BASIC on a terminal writing a game back in high school. It was a surfing game and based on your choices it would generate your next moves in the surfing tournament or you were heckled for hitting the pier, hit the rocks, or got caught in a fisherman's line. The limit on the amount of programming, debugging and gameplay was limited to how much paper you had in the terminal. There was no monitor just a monster terminal comprised of a keyboard constructed of pig iron that consumed reams and reams of paper and for it computing it was connected to the schools mainframe. This was a long time ago, but after the punch card era of computing.

Dave: If you had to sum up what AutoLISP is (or was), as well as what it means (or meant) to you, personally, how would you describe it?

Shaan: I stumbled across AutoLISP in desperation after scripts were just not powerful enough to do what I wanted them to do. I am so glad I found and learned AutoLISP as it saved my day and sanity so many times. I remember looking at all the Hot Tip Harry code and figuring out how others were using it. Being able to automate my AutoCAD work saved me time and allowed me to focus on other things. An example was the layout of large tubesheets for heat exchangers with complicated tube pitches and patterns. It could take a few days manually to layout the tubesheet and of course change during design always happens and adds even more time. When I write a LISP routine to layout the tubesheets I took what was days and reduced it to less than a minute and a I had a detailed layout drawing.

Dave: Which airport is your favorite to pass through? Which airport makes you dread traveling through it?

Shaan: My favorite for sheer awe of the architecture is Shanghai's Pudong airport. Not only can you arrive on a MAGLEV train at high speed, but the architecture of the terminals main area is amazing and the super reflective floors makes it even more amazing (Flickr Link). As for my least favorite airport that is difficult these days as there are so many poor airports whether they be hard on the eyes as a throwback to the 1950's or have perfected the art of making travel painful and a truly broken process. I think one of my least favorite would be a tie between Chicago O'hare as I always seem to get delayed there or have to walk or run from the furthest two points in the entire airport in the shortest amount of time. Orlando's airport drives me crazy just due to the sheer number of crying kids with Mickey Mouse ears on their heads and having just spent a week of nothing but junk food and sugar.

Dave: If you hadn't gone into the world of architectural/engineering design and CAD, what do you think you would be doing for a living today?

Shaan: Don't laugh Dave, at first I wanted to be a marine biologist. Yes, be paid next to nothing and spend 10 years of my life on a desert island studying some obscure jellyfish or sea creature. Of course that was my dream job and instead I fell into growing my hair long and playing guitar bands then having to find a real job like so many others. I am not kidding, about 1 out of 5 CAD software related people I know said they started in a band. How do you think we always have Autodesk employee bands at AU? A bad injury caused my dreams of being a famous rock and roll star to fall flat into reality and I started working in the steel fabrication industry and eventually becoming a mechanical designer.

Dave: Where do see the CAD industry in ten years from now?

Shaan: I think the industry will still be there as engineers, architects, designers and such will still need a way to take what is in their minds eye and put it to a form where others can build it. What form CAD actually is may be a difficult prediction but I think remote software whether on the public or private cloud will most certainly be a part of it allowing more computational power to be scaled and managed instead of limited to each workstation on each desk. I do hope as a recovering designer that we find technology that allows us to make the process of getting the design ideas from your mind to a digital form such as a drawing or model much easier, and no I am not suggesting a USB port in the skull. In  my days of design work, I had the design all built out in my mind and had to remember all the CAD system commands and process in order to translate it to a drawing. I always wanted a way to limit or remove the worrying about the CAD process in design and just allow the design and ideas to flow. 

Dave: What is your favorite, or most relied-upon, freeware or open-source utility?

Shaan: There are so many I rely on, but perhaps FileZilla is near the top of my list currently working with so many files on remote servers at work but in my personal life the open-source fav is VLC.

Dave: Favorite continent to travel to?

Shaan: These are not continents but islands. I love South Island New Zealand, but it is tied with Japan for the many of the same reasons the people and the tranquility.

Dave: If you were given absolute control over any Fortune-500 company for a week, which would it be and what changes would you request?

Shaan: First order would be to make my one week extended to permanent, yes who wouldn't try that move as that is like given a wish and making the wish for unlimited wishes. Second would be to encourage employees to always consider the customer first and foremost and get to know them even the bean counters should know a company's customers and what your product or service means to them and their companies. If the customer needs are always considered and you keep close to them and have their trust, then success and profitability should follow as you will know what your customer’s needs are and what to make.

Dave:  Favorite breakfast food selection?

Shaan: Coffee.

Conclusion

I hope you enjoyed this interview as much as I did.  I have to say that it made a four hour layover in Charlotte NC seem like fifteen minutes.

Links

Between the Lines (blog)
Twitter
Facebook
Google+
Flickr Photostream

10 Questions: with Jerry Milana

Jerry Milana

Introduction

(Note: I apologize for the unusually long introduction, but it's not fluff, trust me)

If you have been among the lucky ones able to attend any of the annual Autodesk University conferences, over the past two decades, you're probably well aware of some names of people that speak on topics such as customizing AutoCAD, Civil 3D, Map 3D, or who push the envelope of products like 3DS Max or Mudbox.  You may have attended sessions on programming, or using advanced features, anything to help you get to a higher level of productivity at your job or hobby.

The presenters, like Autodesk's products, cover a wide range of industries.  From architectural and civil engineering (AEC), to scientific research, to car and motorcycle racing teams, to Hollywood studios, and everything in between.  Some of the names have been legendary, like Lynn Allen, Shaan Hurley, Dave Espinoza-Aguilar, Robert Green, Scott McFarlane, Owen Wengerd, Kean Walmsley, and many others.  In many sessions, you could find one legendary Autodesk employee, quietly sitting near the front, soaking up what the speaker was saying or demonstrating: Jerry Milana.  He would never consider himself legendary, however.

I thought it was kind of funny how later in the day, when he would be conducting his own session on Packaging and Deployment, or License Services and License Management, so many attendees would point and nod, making a comment about how they saw him sitting in the crowd at other sessions.

Between 1989 and 2004, I was often supporting anywhere from 500 to 2,000 computers which were primarily used for AutoCAD design work.  I really depended on either (A) what the vendor provided, or (B) custom scripting and packaging tools, in order to automate the chore of installing that many copies of a product, and the updates and patches, and the next version upgrades.

Of all those products, no vendor put as much work into making their products easy to prepare and deploy to large numbers of computers than Autodesk.  With each successive release, they have continued to improve the features and reliability of their deployment utilities, setting a standard for others to emulate.  Indeed, I have seen quite a few imitations from other vendors, inside and outside of the CAD-related world.  This is a good thing.  And we owe a lot of this to the vision, persistence and efforts of Jerry and his team.

If you think Jerry's insights are only "CAD-related", think again.  The issue of licensing, and license management, will impact nearly every software product in one way or another.

Jerry Milana - System Integration and Software Asset Management Consultant

The Questions

Dave:  Most people outside (and probably inside) of Autodesk know your name as it pertains to the world of deploying and administering Autodesk products on a network. Things like FLEXlm licensing, deployment packages, and so on. When did you first step foot into "that world" if you will and how did it come about?

Jerry:  I worked for a reseller. My specialty was mid-range and PC connectivity and cross platform networking. One day the owner handed me a box of AutoCAD 2.1 and asked me to take a look at it since I had a design background. I said it looked pretty good and soon found that I could use AutoCAD to get in the door of customers to then sell them integration services.

Dave:  What do you feel is the most misunderstood aspect, from the customer side of things, about "network licensing" of software products?

Jerry:  It’s so easy to get things just running customers often miss the finer and much more complex aspects of a licensing implementation. This results in underutilization of assets, exposure to compliance violation and reliability issues.

Dave:  Where do you see world of software licensing in five or ten years? Drastically different, or just incremental changes?

Jerry:  For cloud customers things are already drastically different and the software industry is driving more and more in that direction. As some offerings become exclusively cloud offerings we will see more changes. 

As much as the software industry would like it, I doubt everything will move to the cloud. Even here I think we will continue to see a move from perpetual to term based licensing which will drive changes in licensing. I think (and hope) that we will see hybrid solutions where applications and data are not in the cloud but licensing and associated software asset management is cloud based. 

Of course, there will be private cloud implementations which will drive changes in licensing business models and supporting technologies.

Dave:  I know that one of your passions is skiing and being in and around snow, particularly in beautiful places like Northern California and Colorado. Could you ever see a scenario where your two worlds could cross (software and skiing)?

Jerry:  Who knows, it wouldn't be the first time in my life that hobby and work merged. As it stands now I am a volunteer ski patroller doing both downhill (Alpine) and cross country (Nordic) patrol. It would not surprise me if I end up doing some consulting work for some of the larger resorts and their holding companies.

Dave:  According to your public profile, it would appear that you are either partially or fully retired from the world of software engineering and support services. Are you still involved with technology-related strategic initiatives at Autodesk or elsewhere?

Jerry:  Humm, I better work on my profile. I have been doing independent software asset management and assessment consulting since the beginning of the year. I do some work for Autodesk and for other customers. My business has grown by word of mouth. I am an ADN member and will be speaking at Autodesk University again this year.

Dave:  Do you still travel much? Are there places besides NorCal and Colorado you like to visit?

Jerry:  Yes I still travel a lot for business and pleasure. I enjoy returning to old favorites such as New York, Detroit, Rome, London, Perth, Auckland and Seoul where I have friends and always look forward to visiting new places. I really enjoyed skiing Whakapapa on the north island of New Zealand; it was all about being there on that volcanic hill.

Dave:  If a teenager approached you about choosing a future career path, either in the IT-related world, or something else entirely, what would you recommend to them?

Jerry:  I would tell them to pursue what they are good at and like to do. I have enjoyed my career in the software/IT industry but I see so many people forcing themselves to do this work and are bad at it. I feel we should all strive to be happy and add value to the world; our jobs and hobbies should support this goal.

Dave:  If you were somehow put in charge of Autodesk back in, say, 2005-2010 time frame, and given "absolute control" over all strategic decisions, would Autodesk look (a) about the same as it does today, (b) a little different, but not radically different, or (c) radically different than it looks today?

Jerry:  This one I respectfully decline to comment on.

Dave:  What would make your "perfect breakfast" selection as far as food and drink?

Jerry:  Fresh squeezed OJ and a few espressos.

Dave:  If you could recall anyone from history who has long-since passed on, and have five minutes of time to talk with them, who would it be and what would you ask them?

Jerry:  No brainer, it would be Professor Einstein. If we are talking 5 minutes relative to us at rest on a fixed point on the planet earth; I doubt we would be able to scratch the surface on the things I’d like to discuss. I would start with the validity of our understanding of the propagation of light.

Conclusion

Thank you for reading this interview! I hope you enjoyed it as much as I have.  For more information and resources related to Jerry, please explore the links below.  Thank you!

LinkedIn Profile - Jerry Milana
AU 2004 Photo Album

Shiny New AutoCAD, Same Old VLISP

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

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

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

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

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

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


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

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

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

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

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

Enjoy!

Dear CEO's: Be Careful with that Cloud PR Stuff

Jimmy Bergmark posted an interesting item on Google Plus about some quotes from Autodesk CEO Carl Bass regarding the future of Cloud services.  The quotes were posted on Ralph Grabowski's World CAD Access web site...

"There are a lot of applications that will [still] be done on the desktop. Whether Autodesk does it or not, I can't think of a single function that won't necessarily be done in the cloud." - Carl Bass, CEO of Autodesk

As Jimmy commented...

Asked whether there was some resistance by Autodesk users to make the move as fast as the company is making the switch he said that people are already living in the cloud with their personal applications and that there are somewhat different issues for them.

"Foremost in people's mind is security, privacy, reliability, confidential information. Some of those concerns will fall by the wayside."

Here's the rub I have with folks like Carl (not with Jimmy, he's a genius):  When it comes to Public Relations (aka "PR") these guys are making a HUUUUUUUUUUGE mistake and it is already having a detrimental impact on their business.  Let me itemize, if I may...

1. Understand the difference between a PUBLIC Cloud and a PRIVATE Cloud!
   
   I'm not going to spoon-feed you here.  That's what Google and Bing are for.  But, when the CEO doesn't understand how f***ing important this distinction really is, how can anyone beneath them fully grasp the importance of it as well?
   
2. Be prepared to explain that difference to your customers
   
   Every single time a CEO/CIO/CTO/CxO opens their mouth and says with a smile "We're going to the cloud!  Come along with us!" it scares the living shit out of their customers.  Why?  Because they translate that directly into the following:
   
   A. The products are moving into a Public Cloud platform
   B. Customer data is going to move into someone else's sandbox
   C. Customers will lose at some control (possibly even intellectual property rights) over their content
   D. More points of failure will be inserted between the Cloud point and the customer point
   E. The more points inserted in the middle, the more likely potentially interrupting business operations
   
   Rather than saying "Cloud", make damned sure you elaborate on what your vision and execution plans are for both Cloud types.  Reassure your skiddish customers that they will have an option to retain all the control over their operations and content that they currently have, while having the additional (potential) benefit of leveraging the Public Cloud for (possible) cost savings.
   
3. Make SURE your products are fully-aligned with both Cloud platforms
   
   A lot of products are being shoe-horned and relabeled to become "Cloud" products/services.  IT administrators and power users can smell that a mile away.  Don't assume your customers are idiots, that's a dangerous place to go.  This is especially true for larger customers (enterprise-level corporate shops, the kind that tend to buy subscription pricing contracts to leverage volume discounts).
   
   If you (Mr./Ms. CEO) are sincere about pursuing Cloud services, on both Public and Private environments, break out your cattle prod and put the fear of God into your chain of command to insure they design, and execute, a strategy that natively works in a real Cloud environment on both environments (public and private).
   
   If you really don't intend to support Private clouds, don't fake it.  But also be prepared for a tougher hill to climb when it comes to winning over big-shop customers.

I'm sure all the CEO's of the world read my blog and will take this to heart.  So by the time you've read this, all will be corrected and working fine.

P.S.  Follow Jimmy Bergmark at JTB World.  Follow Ralph Grabowski at UpFront eZine, and World CAD Access

Book Update

I posted some gibberish a few weeks ago about another book project.  Well, I'm getting close to wrapping it up, so I thought I'd go ahead and blabber about it in case anyone has anything they'd like to comment on or any topics they'd like to see included in it.

The book is titled: The AutoCAD Network Administrator's Bible - 2013 Edition

I know: Not very creative or clever.  However, this is not a typical dust-off and rehash book.  I've been painstakingly re-writing it from start to end.  Some of the major changes included in this book:

• AutoCAD 2013 network deployments
• Design Review 2013 deployments
• DWG TrueView 2013 deployments

In addition, I've updated the deployment vector scenarios and included much more detail for each...

• Deployments with System Center Configuration Manager 2007
• Deployments with System Center Configuration Manager 2012
• Deployments with Active Directory Group Policy
• Deployments with Microsoft Deployment Toolkit (MDT) 2012
• Deployments with VBScript, CMD / Batch script, and PowerShell

There's still the familiar topics, which have been updated for the current product versions as well...

• Troubleshooting Tips
• FlexLM License Server architecture and implementation considerations
• Software Deployment strategies
• Tools:  Sysinternals, XCACLS, REGINI, MSICUU, REG, etc.
• Client Performance Optimization

As I've said before, if you have any particular ideas or topics you'd like to see included, post a comment and let me know.  I'm getting close to finishing it, but I'd still hold off for a good suggestion.  I'm looking forward to wrapping this project up so I can focus on my family and day job more as Fall sneaks into Virginia.

Cheers!

Another Book

So, I had posted something about trying out a "different" kind of book several months ago.  I ended up scrapping that idea because I'm not up for that challenge (nor do I really have the time).

I have decided however, that I will do a follow-up to the AutoCAD Network Administrator's Bible, based on AutoCAD 2013 but this time mix in System Center Configuration Manager 2012.  I'm still dipping my toes into ConfigMgr 2012, so it will be interesting to see where it leads.

I any case, I am open to suggestions for topics or examples to cover in this book.  If you have something you'd like me to include that relates to the planning, deployment and administration of Autodesk products in a network environment, drop me a line at ds0934 (at) gmail (dot) com, and be sure to use the subject line "Book Suggestion" so my spam filters don't kill it immediately.

AutoCAD and Where I'm At With It Today

For some reason I get e-mails fairly often asking if I'm still "working with AutoCAD".  The answer is actually "yes", but with some qualification of the answer.  In any case, here's a brief summary of the twisted path I've taken with respect to my involvement with Autodesk products.

In short, I started out using AutoCAD, then customizing AutoCAD, then (now) deploying and maintaining AutoCAD.  Actually, replace "AutoCAD" with "Autodesk Products", because I'm dealing with Map 3D, Inventor, Civil 3D, Raster Design, Maya, 3DS Max, and more.

Strap yourself in, drink plenty of coffee, because this is going to be one of THE most incredibly boring stories you will ever read.  Don't say I didn't warn you...

The 1980's

I started around 1984 as a draftsman (now called, more politically-correct: a drafter or draftsperson), at a Naval Engineering and Design firm working on contracts involving overhaul/retrofit of U.S. Navy ships.  At that time, I was working with plastic media on Mylar film.  Occassionally with pencil or Rapid-o-graph ink on Sepia, Vellum or blue-line paper. I used to run my own blue-line prints too.  All the good stuff: a parallel bar (aka "drafting machine) with cable guides, tri-scale bar, French curve templates, flexible guides, various templates, erasers, erasing fluid, coffee, junk food, and the ubiquitous Sony (cassette tape) Walkman blasting some horrifically bad 1980's music at dangerously high volume directly into my ears.  Those were good times.

Somewhere around 1985 I was introduced to a mainframe piece of shit CAD system named AutoTroll.  I thought it sounded like a robotic creature that lived under a bridge.  I've said many times before that those days were filled with overpriced, under-powered crap products that today's AutoCAD can easily out-perform at 1/100th the price tag.

As the 1980's progressed (or degressed, depending on how you view it), we expanded into more types of design work: oil drill rigs, special-purpose nautical equipment, land-based facilities (buildings), and so on.  The work followed the economy and what was going on around the world at the time.

The 1990's, part 1

After moving to my third job in the field of Naval Engineering and Design (ok, most of those firms preferred "Naval Architecture, Engineering and Design" but I ran out of breath before getting through that), I was put through training, and began using Intergraph VDS (along with EMS, PDU/PDM) where I developed 3D models of U.S. Naval ship portions.  We never modeled an entire ship because it wasn't what we were contracted for.  Our role was overhaul/retrofit of spaces, systems, and components.  The hull form modeling was left for other companies at that time.  I moved from Intergraph to Microstation, to AutoCAD R10.  R10 was the first version I worked on.

At this point, the U.S. Navy would only allow AutoCAD to be used for "non-design" work.  Sounds confusing, doesn't it?  What that meant, was that the title sheet, bill of material, notes, and references, could be handled with AutoCAD, while the "detail design" of systems, spaces and components had to be done with one of our ever-growing arsenal of UNIX-based CAD garbage.  It was painful and frustrating. We requested over and over that the Navy reconsider, but they were adamant (and slow).

The 1990's, part 2

Soon after the Navy approved the use of AutoCAD for general systems design, we dove into with both feet and pretty much left the UNIX design tools behind for good.  We still maintained some content with them, but we migrated/translated content to AutoCAD on every opportunity we got.  It was a good move.

My employer hired a fairly-sharp MIT graduate to develop custom extensions for AutoCAD to help automate the design process for each major discipline, which back then meant: Piping, HVAC, Electrical, Electronic, Hull Design, Hull Outfitting, and Scientific/Engineering.  My area was in both Piping and HVAC systems and component design.  However, we had a fairly good rotation program, so I got to work for a period of time in each of the other departments and learned about their worlds quite a lot.  I'm sure the grammar and syntax in that previous sentence is somehow wrong, but whatever.

So, this MIT guru was a major player in the world of LISP and C++ so they dangled a big paycheck in his face and he went to work.  The results were incredible, BUT... he was contracted out of our San Francisco office, who only worked on Chevron contracts at that time. So all of his automation tools were built for that, rather than U.S. Navy ships.  That made for some frustrating work.  Our East coast teams requested features for our type of work, but we were rebuffed and ignored.  That led me to pick up a book and learn AutoLISP and DIESEL/MNU programming on my own.  I stayed late after work every night and practiced and tinkered.  Soon I began to review the MIT guy's code and make small changes to suit our needs.  That led to making more changes, and eventually just making my own set of automation tools.

Once my supervisor saw what I was doing, he asked me to push faster and get some tools ready for our department to start using.  Once I got that going, other departments asked me to do the same for their design needs.  It grew from there.  I was with that employer for about ten years.

The 1990's, part 3

A job opened up at a large defense contractor in the area (no names) looking for someone to lead the effort to implement their first "AutoCAD design environment".  I jumped at the chance and was soon involved with implementing it on their first Windows NT 3.51 LAN as well (they were on WFWG and Novell to this point, aside from the dozens of UNIX LAN's scattered around).  That meant I was put through training courses on Windows NT, and various Microsoft technologies.  Soon after, I was moved into the double-role of Windows LAN Administrator and AutoCAD Administrator for a user base of around 3,000 (that one location had over 18,000 employees, 9,000 of which were daily computer users, so I dealt with roughly a third of them).

One of the major tasks I was handed was to recreate the design automation tool development results from my previous job.  This was much bigger scale and required a more serious approach to handle the complexity of the environment, the more rigorous expectations, more focus on performance and stability, and dealing with a tiered security access control environment as well.  That meant building tools so that certain people could access higher-level features than others based on their designated role in the organization.  It was a very interesting time for me.

This was also when I began my college education in Information Science.  So I was getting a brain-full of new ideas from school and work at the same time.  My head somehow didn't explode.  Oh yeah, I was also dabbling with Cold Fusion CFML and web site development.  Fun times.

The early 2000's

After I graduated college, I left for yet another new job.  This time however, my balance of customization versus administration was shifted from roughly 70/30 to around 50/50.  I had picked up skills in Microsoft SMS 2.0 while at the previous job, and SMS 2003 was in early development at the time (I was working on the beta program by invite from a close friend, very lucky indeed).  My emphasis was at first on rebuilding a newer generation of design automation tools, but once that was done and in production, I shifted my focus towards deployment and administration.  I was also pegged to lead our company-wide migration from Windows NT 4.0 to Windows Server 2003 and Active Directory.

That meant more training, more lab time, and more use of VMware than I ever expected.  The migration went very well and I began wearing a Microsoft hat more than an Autodesk hat.  The hours I spent with Visual LISP, VLIDE, menu editing, customizing profiles, building deployments and dealing with license servers, were fading.  My new goodies were then Active Directory, Group Policy, SUS, then WUS, then WSUS, SMS 2003, then Configuration Manager 2007, VBscript, Javascript, WMI, ADSI, LDAP, COM and so on.  I also began working more with ASP web development and SQL Server backend data management.  This soup of stuff began to intertwine and soon I was building web apps that interfaced with all of these things to help manage and see what was going on throughout the environment.

All of this ramped up more when we were hit over the head with SOX compliance, and ISO certification.

As for my involvement with Autodesk products:  From 2000-2003 I was still heavily involved with customization.  I had joined ADN with a team of four others, and acted as our ADN administrator.  We went to a lot of Autodesk University conferences and we had a lot of fun.

From 2004-2006, I was building deployments, creating custom menus and profiles, dealing with FLEXlm license services, lots of phone calls with Autodesk involving technical support or licensing or contracts and purchases.  I had shifted the role of ADN lead and development lead, over to one of my team members.  He took off with it and pushed into .NET development with ObjectARX and it was awesome to see the baton passed to such an eager group who ran with it in the right direction.

I worked with Autodesk products from version 2000 and 2000i (remember that?), through 2007.

In 2007, our company was sold and split and I left for a small consulting firm.  That didn't last long, as the economy went off a cliff and they closed our fledgling office in early 2008.

After getting laid-off, I went back to the big defense contractor I worked for in the 1990's.  This time it was all about packaging and deployment of applications in general.  I shared Autodesk product duties with my buddy Dave (another Dave), but we also dealt with dozens of products from other vendors.  Our team of 14 supported over a thousand products for the organization.  It was a busy place indeed.

I left that job for another consulting firm in 2010, focusing on Microsoft platform technologies. I now had my MCITP 2008 certification and was finally diving into that world head-first.  I still bring my development skills and bag of tricks along because it always comes in handy.  I still believe that a developer in the systems engineering world has a leg up.

Late 2000's and Today

From 2008-2010:

• Building and customizing  Autodesk  network deployments (v. 2008 through 2010)
• Implementing and managing FLEXlm and FlexNet Manager services and reports
• VBscript, KiXtart, CMD scripting
• Packaging applications with Wise Package Studio and Wise Script for Altiris deployments
• Building web applications to track and report applications inventory and licensing
• I wrote a book or two for Amazon Kindle
• I joined Facebook in late 2006
• I started this blog early 2007, killed it and started it back up again

From 2010-Today:

• Building and customizing Autodesk network deployments (v. 2010 through 2013)
• Deploying "deployments" with System Center Configuration Manager
• Packaging applications with InstallShield and AdminStudio
• VBscript, PowerShell, CMD script development
• Working with MDT 2010, WSUS, Group Policy
• Building web applications to track and report all sorts of things
• I wrote a few more books for Amazon Kindle
• In early 2012 I tried to retire from this blog, but that didn't last

So, there it is.  My story, or at least part of it.  The tedious and excruciatingly boring part.  I hope it helped you get to sleep.  Cheers!

Disabling InfoCenter in AutoCAD 2013

Owen Wengerd has done it again.  He's updated his free utility for killing InfoCenter for AutoCAD 2013.  Get it here: http://otb.manusoft.com/2012/03/turning-off-infocenter-in-autocad-2013.htm?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+obox+%28Outside+The+Box%29

Autodesk Revit 2012 and Configuration Manager 2007: Win7 vs XP

While packaging Autodesk Revit 2012 Architecture Suite for mass deployment (via Microsoft System Center Configuration Manager 2007 R3), I encountered a problem where Windows 7 clients installed just fine, but Windows XP SP3 clients did not.  The error was 1603 or 1619, but the client log did not indicate any more specifics.  I ran the installation  (deployment) manually (interactively) and it worked fine on both platforms, but through Configuration Manager 2007 R3 it would not successfully install on Windows XP SP3 clients.  At all.  Ever.

Until...

It's an old trick that sometimes works, and in this case it did:

Within the Package, under the Program properties settings, on the Environment tab, check the option...

"Allow users to interact with this program"

It now installs on Windows XP SP3 clients as well as Windows 7 clients.

How AutoCAD Changed the World

That's kind of a bold, hype-ish title, am I right?  You're probably rolling your eyes, or saying "yeah, sure, whatever" or something like that.  But give me a chance to explain...

Back in the early 1980's, if you did any "design" or "drafting" work, you were most likely working on a physical drawing board and tracing your ideas out on Vellum, Paper, or Mylar sheets using various kinds of mechanical pencil materials or maybe a Rapidograph ink applicator.  Maybe you used templates and lettering guides, or shape tracers or flexible curves and those stupid-looking weights we called "ducks" or "whales".  In the mid-1980's came the first real significant influx of computerized design technologies.  They had weird names like AutoTrol, CADAM and so on.  They were collectively termed "CAD" for Computer Aided Design.  If they were connected to manufacturing machinery, they were called "CAD/CAM" for CAD + "Computer Aided Manufacturing" (or "Machining").  If they did engineer calculations from design data, they were called "CAD/CAE" some were "CAD/CAM/CAE" and some were just stupid and we called them "overpriced crap".  But they were magical for their time.

Here's the snapshot of "before":  These first-generation CAD/CAM/CAE systems only, I repeat ONLY, ran on UNIX platforms.  Not only that, but most were tuned for specific UNIX platforms, so they were hardware specific, such as DEC, IBM, Sun or a few others (most of which are all gone now).  The software alone was often in the $10,000 to $30,000 range PER SEAT.  The hardware was just as expensive, or even more expensive.  I worked on one system back in that era that was priced at $50,000 for the hardware "workstation" and the design software.  Keep in mind that you HAD to purchase vendor support since they did not allow you to work on it yourself, often keeping many of the features, settings and capabilities secret until you paid someone to reveal them to you.  Oh yeah. Good times they were not.

Then came along some scrappy little company named Autodesk and they had this cheap little CAD product called "AutoCAD" that actually ran on an IBM-PC.  The other vendors laughed and tried to ignore it.  I remember an IBM rep saying to us "that's a toy - a piece of crap that'll never go anywhere".  I sure wish I could have recorded that for later on.

Maybe you've heard the story of the butterfly that caused a hurricane.  This is very similar.

So, as this tiny little snowflake rolled through the fledgling IBM-PC "compatable" market, it began to gather some snow and grow bigger and heavier.  For the peanut gallery out there: I'm not implying it was bloated.  It wasn't.  It became heavier with customers and customer momentum.  Still a bit immature at R9, it made heads turn at R10 and R11.  Then R12 came out and that snowball was now the size of a truck and rolling faster.  As the UNIX market began to respond, it lost some of its footing as well.  The big players started losing key developers and managers to smaller startups, all trying desperately to stir up excitement to fend off this new upstart called the "PC".  Computervision stumbled, which led to Intergraph and Pro/Engineer.  CADAM, Unigraphics and others started making adjustments, and even tried "realigning" licensing costs, but they caught some breathing room when Autodesk stumbled with R13.  Then came R14 and it was pretty much a done deal as far as customers balling up those checks for the expensive UNIX fees, and stroking new checks to the much less expensive PC product lines.

As customers moved from UNIX to Windows and Windows NT at an increasing rate, so too did many stalwart UNIX product vendors.  CAD/CAM/CAE products previously only available on UNIX were suddenly announcing PC versions.  Even the most discerning NASTRAN vendors were poking at the PC market, especially as the PC hardware specs began an accelerated upgrade path.

I saw this firsthand at least four employers, and dozens of businesses I interacted with, and multiple branches of the U.S. Department of Defense: Navy, Army, Air Force, USMC, Coast Guard, even NASA.

No other PC-based CAD product had as much impact on the CAD market, and pushing customers to take the PC platform seriously.  It also pointed the light on their budgets and ROI, and suddenly program managers were faced with making serious choices about continuing on with their life-draining budget expenditures, or doing some soul searching about this new PC-based direction.

The rest is history.

Is the UNIX market dead?  No.  Not at all.  Has it scale back?  Yes.  Most of the major UNIX vendors from Compaq, Sun, Prime, DEC, Silicon Graphics, Helix, Unigraphics, are gone, or have been acquired and renamed.  IBM, Dassault, and Integraph remain vibrant, while PTC has undergone multiple shifts in product and services offerings, but seems to be alive and well.  One major change from twenty years ago has been the emergence of Siemens.

But even with these legacy companies still bouncing along, they've ported most, sometimes all, of their products to the Windows platform.  Love them or hate them, that little snowflake had an impressive impact indeed.

AU Virtual 2011 - Network License Manager Course

If you haven't done so already, you should definitely check out Jimmy Bergmark's course on "Autodesk Network License Manager".  It covers a vast amount of information about setting up, configuring, managing and troubleshooting the FlexLM environment and your Autodesk products.  Good stuff!  Highly recommended.

If This Were a Perfect World...

I tried to get my voice heard by Autodesk for much of the period between 1996 and 2006, but eventually I just gave up.  I'm not trying to badmouth them or anything.  The reason is simple: they're just too big to hear a tiny squeak anymore.  I was going through some old e-mails and notes from discussions I had with AE's at Autodesk University in 1997, 1998, 1999, 2000, 2002, and 2004 (the last year I attended).  Here's a summary of ideas I put forth into the vacuum of space...

1. Upgrade Visual LISP IDE (VLIDE) to have a more modern interface and license OpenDCL to make it on par with VBA for dialog design. (2003)
2. Restore network licensing for AutoCAD LT (2004)
3. Standardize on ONE format for all software updates (preferrably .MSP) (2009)
4. Standardize the Network Deployment wizard to make nothing but MSI components, no stupid .exe (yes, I'm talking about FARO). (2009)
5. Fix the .NET 4 and DirectX silent install problem when pushing a network deployment through Configuration Manager advertisements. (2009)
6. Include the NetBIOS name of computers that register standalone activation when sending the e-mails to the contract license owner (help customers nail thieves on their own) (2005)
7. Figure out what to do with Raster Design.  Some customers deploy it with AutoCAD, Mechanical, Map 3D, and so on.  The licensing gets confusing at times. (2008)
8. Buy Vital LISP from Basis Software and replace AutoLISP with it (they were already closing the deal when I suggested it, so I was late to the party on that one) (1997)
9. Merge Mechanical Desktop with Inventor or just kill MDT and keep Inventor but make your mind up! (again, they were already executing the plan before I thought this up, although they took their time finishing up) (2000)
10. No more spread-out AU locations per year, do it in one location (1998, Boston, horrible)

AutoCAD: PURGE, AUDIT, RECOVER, Repeat...

I know I said I wasn't going to write any more AutoCAD-related articles, but this was sparked by a recent client visit, so I felt it was worth revisiting.  I've mentioned the AutoCAD PURGE command before, but it needs to be revisited.

Something that is very unique to the world of CAD is the extent to which content is reused.  More than any other class of application:  word processing, spreadsheets, databases, desktop publishing, even more than photographic and illustration applications.  CAD shops around the world routinely insert library content from years of accumulated work.  Everything from the smallest items to sheet borders, to complex 3D components and entire compound assemblies.  Content is king, and CAD content is the king of kings.

But there's a problem.  Along with the visual attributes there is an entire world of non-visual baggage that comes along with every reused chunk of content.  Layers, dimension styles, text styles, linetypes, shapes, extended data (xdata) and xrecords, are just a typical brush stroke of examples of things that often sneak in with each library part insertion.

But wait: There's more!

Along with the legacy visual, and sinister non-visual stuff, there's the often overlooked issue of inconsistent and inaccurate data structures.  I'm talking about the DWG format itself.  With each release of AutoCAD, for example (I'm sure this is applicable to other CAD products), there are improvements to the methods and processes for detecting errors in the data format and correcting them.  Some of the tools in AutoCAD that help with this are AUDIT and RECOVER.  There's also WBLOCK and DXFOUT, and other methods/tricks, but you get the idea.  The problem is that rarely do CAD managers or anyone else take the time to comb back through years of old DWG files to run these tools and clean them up.

Most often what happens is we get into a habit of inserting content, exploding it, erasing what we don't need, then running PURGE and saving.  At least run AUDIT when you do that.  If you don't, you risk corrupting the new drawing, or at the very least you'll bloat it to death.  File size is not something to ignore.  The bigger the file, the slower it copies and the slower it gets backed up.  It also takes longer to open and longer to save, especially across a network connection.

AUDIT (fix errors)
PURGE (nested)
PURGE (nested) again
AUDIT (fix errors) again
SAVEAS (new dwg file) replace the old dwg file

I haven't bothered to search, but I'm sure there are at least a few products available for helping to batch process drawing files for you.  Even if you can't afford to purchase one, you could build something using LISP, VSA, ObjectARX, VBscript, Javascript, KiXtart, PowerShell, or just two sticks and a bucket of mud.  Whatever the case, don't ignore this.  Just because you ran AUDIT and PURGE on those old drawings back when you used AutoCAD R14 or 2000, doesn't mean they can't still contain errors and junk that AutoCAD 2012 would find and correct.

What if AutoLISP were Unleashed?

Way back when, (a completely meaningless phrase of course), Autodesk had the audacity to introduce a radically new concept into a software product: Extensive Programmability.  They did that using DIESEL, AutoLISP, and the MNU file.  They could have just dropped a “here-you-go-take-it-as-is” product without any meaningful customization features or tools, but they didn’t.  Autodesk instead decided to empower their customers, enabling them to extend and reshape their products to suit their own needs.  This simple decision had a profound impact on their customer base, as well as product sales. Indeed, it created an entire community and industry that otherwise wouldn’t have existed.

I’ll spare you the regurgitated history stuff, you can look that up online.

There is something that has been ticking around in the back of my head for a long time:

   What if Autodesk had ported the AutoLISP platform outside of AutoCAD?

Keep in mind that this was in the 1980’s, and Java didn’t yet exist, neither did .NET.  The most popular “cross-platform” scripting toolset at the time was Perl (and ActivePerl). Most AutoLISP programmers I knew between 1988 and 1995 were always wishing for more OS features, many of which were made possible through third-party tools like Robert McNeel’s DOSlib. There were also many that begged for a better dialog programming toolset, which was later made possible by OpenDCL, another third-party product.

Autodesk however had other desires.  They were starting to drink the Microsoft Kool-Aid, and decided to drop LISP at the altar and run off to Vegas with VBA.  After all, she was hotter and wore thongs and high heels at the time.  Then when VBA put on a few pounds and started wearing sweats around the house without make-up, they ran off to Bangkok with the svelte .NET, along with a crate of condoms and a case of Bud.  LISP was left in the alley, panhandling for spare change, needle tracks were starting to show on her arms.  AutoLISP was swapped with Visual LISP, which remains to this day, but is ignored in much the same way as Middle Class workers are in America.  The world of AutoCAD customization now belongs to ObjectARX, or so we're told.

I won't go into the flaws with this mindset of ObjectARX over LISP, but I know that I'm not alone in feeling it's a huge mistake to ignore Visual LISP they way it's been ignored thus far.

But what if?  What if not only had they continued to breathe life into Visual LISP, but they had made it possible to run AutoLISP code from a dedicated script engine from outside AutoCAD?  I'm talking about much like was/is possible using ActivePerl, KiXtart, CMD or VBScript.  Imagine the power that thing could’ve unleashed for LISP programmers.  I can only imagine the potential it could have had for much more than batch processing of DWG files.  Granted, the constraints of AutoLISP capabilities would have required a significant amount of expansion, which was in short supply after the acquisition of Vital LISP® was renamed Visual LISP®.  It was as if they had adopted a 3 year old child who spoke an unknown language, so they left him alone in the toy room with the dog, tossing food on the floor, and quickly shutting the door.

Imagine the potential of combining the file system features of DOSlib with the dialog building features of OpenDCL with powerful intrinsic functions like (mapcar), (apply) and (lambda).  In case you need a poke in the brain: Remember that LISP is built for recursion and that file systems are perfect for recursive operations.  Not just file systems either, but any data source.

The basic tenants were fairly unimpressive: a script engine that is ported to various “present day” platforms (Windows, OSX, Linux) which executes the same code the same way. Gee.  That sounds a bit like Java.  That also sounds like .NET, sort of, maybe more like Project Mono.  But those two platforms weren't even concepts in 1990.  In any case, you get the idea.  That is, if you’re still awake and reading this far.  I’m guessing few of you have read this far without falling asleep or moving on to something more interesting.

Alas, this idea was never on the table, officially, so it never could’ve become reality.  Never mind that there haven't been any meaningful updates to VLIDE or Visual LISP in years.  I'm still a pie-in-the-sky person, and I'm often given to dream crazy things.

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