UIU Blog

So, you're thinking about switching OS Deployment Solutions. Congratulations! You're in for a serious amount of work not only choosing a solution, but also in planning, configuring, organizing and executing the little monster. Sure, some solutions are easier than others, yet all solutions require much more effort than you think. If you're thinking, what are you talking about? This stuff is easy…, I probably can't help you. You'll figure it out, I'm sure.

STEP 1 –
First, ask yourself, Why am I doing this? Seriously, unless you're hoping to solve a mission-critical problem with respect to OS deployment, it likely won't be worth it, regardless of the foundation of your reasons; be they political, financial, technical, talent-level or fear based. Be honest and go into the process knowing the actual reasons, it'll help you most when you're attempting to choose between the various offerings out there. Side note: If the reason is purely political, you probably need to suck it up and get it done and the rest of us out here in the Interwebs will feel appropriately bad for you. We know…

STEP 2 -
When choosing a new OS deployment solution, you'll need to know what your critical requirements are. What combination of features, available add-ons or plug-ins, integration within your environment, usability, security, delegation of responsibilities and learning curve (just to name a few) meet the needs of not only your organization, but also of your staff. Make a spreadsheet and fill it out or find one on the web, or if you have an extraordinary memory for really boring details, make one in your head! (I don't recommend the latter…) Start by assuming that you're a noob and go from there. The biggest mistakes we professionals often make are assuming that we know how everything works.

STEP 3 -
Once your new OS deployment solution is chosen, planning begins. Prepare for a lot of time to be spent making sure that you know all of the technical limitations of your chosen solution. These limitations may cause you to scrap an iteration of your plan (or several iterations). If you're considering the actual reasons that you chose the solution, you'll scrap a few as you learn the caveats. Whatever time you set aside for planning, a good rule of thumb is to double it, at least. Planning covers:  solution installation (with required, supporting network services such as WDS/PXE, multicasting switches, etc.), network infrastructure requirements and resources, target machine topography, technical staff training, and end-user training (where applicable), etc.


STEP 4 -
Next comes configuring the solution. There are undoubtedly systemic parameters that must be verified if not set, either within the solution or on the network resources that will support it (or both, likely). Organize the deployment methodologies. Determine which method or methods you'll use, (e.g. PXE vs. bootable media, etc.) and exactly what hardware you'll be deploying to, neatly organized into interlaced groupings. Don't solely consider the new hardware that you've got in your lab, but also consider the hardware that's been deployed into your production environment, especially that ancient machine in accounting that has specialized software on it, developed by one guy in his basement, long dead, and it just works, so we don't touch it. Perform the laborious task of discovering and researching the implications of EVERY parameter available in the solution, (assuming that you didn't do so prior to making the choice), as these can often either save your backside - or kick it.

STEP 5 -
Finally, execute the solution, preferably in a test lab or at least in a segregated environment at first, work out the bugs (hello, forums…), and then pull the proverbial trigger when you're satisfied. If you were diligent, you'll undoubtedly be a proud and happy camper (after some beverages). If not, well… You know the drill.

 

Unsolicited Advice:

• Choose an OS Deployment Solution that can handle Application package deployment as well.


• Choose a solution that can allow you to create small, specialized groups on which unique or at least highly customized OS images may be employed.


• Choose a solution that will meet the anticipated future growth needs of your organization.


• Train your staff on the solution! Train the hell out of them!


• Use PXE, it's awesome…


• Open Source usually means no organized support effort. Factor that in…

If you considered this post to be overly alarming and elect to ignore it, good luck. If you agree with its basic tenets or elect to take it with a grain of salt, that's cool too. Either way, it has hopefully prompted you to consider a couple of things more seriously and my only hope is that it helps you in your decision somehow. You're welcome, and I'm sorry that there's no Easy button…