Client OS deployment & management

In my previous post: Active Directory Design and Network Resource Availability we discuss how your organization’s Active Directory design acts as a central orchestrator for your entire network and what roles you should be utilizing within your organization. In this post: Client OS Deployment & Management, I will be giving you an overview of why you should be using a layered approach for deploying all your Windows operating systems and software applications.

Throughout my career, I have been involved in keeping servers and workstations running at optimal performances and when it comes to end-user computer systems, there is no exception. After all, what IT admin wants to hear from their end-users at the end-of-the-day?

From your typical office systems with a half-dozen of programs to high-performing CAD/CAM engineering workstations – they -ALL- can be deployed from this approach. Here are some of my theories on the best ways to keep a handle on a handful of computers to several thousand computers systems you need to deploy and maintain moving forward.

The first step: create a spreadsheet cataloging all the software you need and how many layers of software will get you to that final stage – this will be your blueprint moving forward and will take the confusion out of all the chaos.

• Determine what software can be installed everywhere. Nowadays, client computer storage is rarely a concern to me – even in regards to solid-state drives. You might be asking yourself “Why do I need GIMP installed on my receptionist’s computer”. The fact is, having more software installed; than not enough software, in my opinion, is much less of a headache than trying to manage “who” has “what” installed. Unused software will sit dormant and only consume a fraction of your storage space.
• Determine what large software programs can be layered on top of the operating system during the MDT deployment process. Programs that should be considered here are generally very large and focus to their specific departments. For example, engineering departments may have Solidworks or AutoDesk Inventor installed while marketing departments will typically get the Adobe Creative Suite installed. Another one I typically will always include here is an administrative installation source for your Microsoft Office products.
• Finally, try and standardize your operating systems and software as much as possible. Avoid having Windows 7, Windows 8, Windows 8.1, and Windows 10 client Operating Systems and multiple versions of Office (i.e. 2010, 2013, and 2016). Our team at Source One Technology is now recommending and deploying Windows 10 Professional in almost every situation. Also, if multiple versions exist for programs like Microsoft Office throughout your office, it’s much better idea to purchase the necessary licensing to have the eligibility for deploying a standard version of Microsoft Office across your organization vs. trying to support multiple versions – having multiple versions will only cost your company time and money in the long run. Sure, end-users will squawk about this one, especially if they are already using a newer version, but the key here is to save money and time. The next time an end-user asks why can’t I use Office 2016, ask them what features their existing version doesn’t have – most likely they won’t have an answer for you.

Once you are done compiling your spreadsheet “a.k.a Deployment Blueprint” consider what your basic operating system requirements are going to be for your WDS/MDT images:

• OS major versions/builds (Windows 7, 8, 10, etc)
• OS Architectures (32-bit/64-bit)
• Pre-installed .NET Frameworks, C++ Runtime components, Microsoft Updates, etc.

Once you have a good spreadsheet to work from, start building your VM’s! My typical approach is building a virtual machine with the operating system and architecture you need, install Microsoft .Net Frameworks and C++ Runtime components, and manually install Windows Updates to speed up the deployment of the initial base operating system.

Once you have this VM built to your specifications, you can then take a snapshot of it and capture it to your deployment server. In past versions of Windows (i.e. Windows 7); I like many other IT pros, like creating monolithic images that contain all the software I wished to push down onto a newly imaged computer. Once this was done a series of MDT or manual installs were done on the more specific computers that needed more specialized software – critical updates for Flash, Java, etc. components were updated via Group Policy deployments.

Nowadays, I prefer to only create the base operating system images that contain Microsoft frameworks and updates. Once the base image is deployed to the computer, Active Directory Group Policies are nearly exclusively used to layer MSI packages on top of the computer. This is completely an optional procedure – you may choose stick to your own methods and continue using the monolithic imaging approach or other software installation managers.

Software and configuration settings deployment considerations:

• MDT post-deployment task for installing large applications (i.e. Microsoft Office, Adobe CS, AutoDesk Inventor, Solidworks, etc.)
• Active Directory MSI software deployments
• Group policy settings for computer objects
• Group policy settings for user objects
• Windows Server Update Services (WSUS)

A little history on MSI deployments:

MSI packages have always been a concern from my other colleagues in the IT field and including myself, but it definitely does not have to be. I have learned over the years to break down large and complicated tasks into smaller manageable tasks and this is how I prefer to tackle the MSI deployment taboo.

There are several tools available to edit and/or create MSI packages. My theory when it comes to the editing and/or creating of MSI packages is to do the absolute bare minimum – I can’t stress this enough. Trying to reinvent the wheel by preforming pre and post system/registry snapshot to capture registry and file changes is very challenging and time consuming in my book. Even if you are very gifted with the Windows registry, the files that are created on the file systems, and all the internal workings of the software you are trying to repackage, I would never recommend this approach.

In my opinion, only the developers of the software should be responsible with this process. Instead, light changes to native MSI (editing shortcuts, etc) and re-packaging native EXE installers within MSI’s is a much safer approach.

Once your packages are built, registry settings and configuration files can be layered on top of the computer via Group Policies to affect what happens when you first launch the program. Once you have all these tools in place, refreshing client computers becomes a breeze. Matter of fact, I frequently will guide end-users through over the phone on how to PXE boot their computer or even better – provisioning a newly purchased computer that needs to be setup without myself being there.

Keep in mind however, critical Windows components (i.e. folder redirection, roaming profiles, etc.) need to be in place prior to obtaining this level of administration. Happy deploying!

Related Articles

Overview: Network Remodeling/Redesigning/Restructuring Services
Part 1: Active Directory Design, Optimization, and Automation
Part 2: Network Resource Availability and Data Integrity