From the Book: .NET Framework 3.5, Windows 8 and AutoCAD 2015 Deployments

That title is not long enough.  If I want to provide product titles to Microsoft as a possible side business, I need to make the titles longer.  Like that will ever happen.  Anyhow, this post is based on a part of my recent ebook "The AutoCAD 2015 Network Administrator's Bible", and focuses on dealing with one particular road bump in deploying AutoCAD 2015 to Windows 8.x clients.

Windows 8 and .NET Framework 3.5

If you read through the documentation, one of the requirements for installing on Windows 8.x is to have the .NET Framework 3.5 feature enabled.  This feature is *not* enabled by default.  You can enable it via the Control Panel route, or from a command-line, via a script, or as part of your imaging process using MDT or SCCM as well.  Choices, choices, choices.

Why is this a big deal?  Maybe for you and your environment ,it's not a big deal at all.  But what if you want to deploy AutoCAD 2015 to 500, 1,000 or 10,000 computers, all of which are running Windows 8.1, but not all of them have .NET Framework 3.5 enabled?  Still feel excited about running around to touch each machine?  Even remoting into each one?  How about the time to concoct (or steal) a script to batch enable all of them?  Yes, you can do any or all of these.  The short story is:  There is no "one-size-fits-all" solution.

Option 1 - Scripting and Command-Line

If you don't have the luxury of using MDT or SCCM to do some of your heavy-lifting, you can still make-do with free features provided within Windows itself.  

But before I jump into this I would like to mention that unlike some other .NET Framework versions, 3.5 is a "feature" within Windows 8, rather than a downloaded update or service pack.  The binaries which are required to enable it are already embedded in the "\sources\sxs" folder beneath the Windows home directory.  The challenge tends to be that the contents of that folder within the original installation media, and the final result do not often match.  That's because Microsoft has opted to follow an admirable "reduced attack surface area" approach, which translates into putting the least amount of bits on the client as are needed.  The less code laying around, the fewer potential targets exist to be exploited.

So, how do you enable it?  DISM is one good day.

DISM, or Deployment Image Servicing Management command, is part of Windows 7 and 8.  It actually began life earlier, but has been fine-tuned with each new Windows release.  Among it's many features, are options to enable and disable Windows features. The most-basic form of the command for this topic is:

dism /OnLine /Enable-Feature /FeatureName:NetFx35 /All

However, you may want to tack on a few extra optional parameters (or "switches" as some prefer to say) to provide more control over how it behaves.

/LimitAccess - this option tells DISM *not* to try to reach out to an internal WSUS server to find the source binarines, but instead to look somewhere locally.

/Source - this option tells DISM that you are going to provide a specific path from which to load the source binaries.  Actually, it should read "/Source:" where "" is something that actually contains the correct files, like "c:\temp\sxs" or "\\SERVER1\sharename\files\sxs", etc.

If you're not really familiar with how the "side-by-side" (i.e. "sxs") folder works, and what it means, be careful!  If you are, then ignore the next sentence, but I know you'll read it anyway just to make sure I'm not incorrect and you can't wait to pounce all over me for screwing up.  The "sxs" folder uses special file links to avoid duplicating a lot of redundant bits. This is somewhat like how a .ZIP or .7Z or .TAR file works, in that it tries to reduce the overall amount of disk space used for storing the data.

Anyhow, beyond that, the "sxs" folder contents MUST match the same Windows version and skew that you intend to use them on.  So if you make a "sources\sxs" copy from a Windows 8.1 Professional disk or ISO image, and try to reference it for a Windows 8.1 Enterprise client, it's probably not going to work.  In most cases, it will chug away until around 60-65% and then crash with the error message:

"The source files could not be found."

Bummer. If the folder path is wrong and there are no files at all, that's one thing, but it usually bombs out sooner than 60% of the way through.

Option 2 - Imaging

Other options include bundling the feature (okay, "enabling" the feature) during the Windows installation process.  This is fine for provisioning new computers, or reimaging, but not so ideal for updating computers which are already part of the production environment.  You can however employ parts of MDT or SCCM to deploy to those computers, but that's technically not imaging then, is it?

Even within just one option such as MDT 2013, you have several routes you could take, from using a Custom Command-Line task, to employing a script, to setting a Task Sequence Variable to identify the sources folder path, and then use the Add Roles and Features task to handle the feature.  Who says the IT world is boring, huh?

Option 3 - Deployment Tools

This encompasses things like Packages or Applications within System Center Configuration Manager, as well as other tools like Altiris or what-have-you.  In short, you create a named instruction set that performs the desired tasks, and then target that to a group of computers to execute locally.  In SCCM, that could mean an Application with one or more Program entries, and a Deployment linked to a Collection.  You get the idea.  

It's not rocket science and it's not difficult to do, IF you have the environment up and running already.  The toughest part of these kinds of tools is standing them up.  Once they're operational (if designed and installed correctly), the rest is a matter of "using" the features.

Summary

I cover each one of these in far more detail within my book, and provide screen capture images of each step along the way.  I hope you will consider reading it and thank you for taking the time to read this!