Welcome to the UIU Blog



Industry Insights, Product Updates, Support Tips & Tricks, and all things related to Automated Driver Management.

 
Automated Driver Management with the UIU Logo

 
Home >> Blog

About the UIU Blog



The UIU Blog is brought to you by Support, Development and Management at Big Bang LLC to provide industry news, product development and updates, support cases, release notes, and discussion of OS Deployment and the Universal Imaging Utility.

We would appreciate your comments and suggestions.

If you have a UIU Support issue, please email Support at support@bigbangllc.com or call us at 414.369.5020.



Subscribe

Share

Visit

Subscribe to UIU Blog Via Email   Subscribe to UIU Blog Share UIU Blog via Twitter   Share UIU Blog via Google Plus   Share UIU Blog via LinkedIn   Share UIU Blog via Stumbleupon Visit the UIU Facebook Page   Visit the UIU Youtube Page


Recent Comments

"@Tobias - thanks for the comments - we probably didn't spell it out clearly enough in the last sentence of the "What MDT and WDS bring to the Table" section, but we agree - ZTI and other user-driven methods DO require System Center." Read more
by Nathaniel Bauer on The Sometimes Confusing Relationship Between WDS and MDT

"Good post sir." Read more
by Jeff Stokes on So Which Is It - ImageX or DISM?

"I think you made a mistake here. MDT does not support ZTI or ZeroTouch installations. Only LiteTouch. For a ZTI SCCM is required, but still you can manage to run the installation with at least one single click - so almost totally automated. But still ..." Read more
by Tobias on The Sometimes Confusing Relationship Between WDS and MDT



Posted by: Nathaniel Bauer on 6/24/2014 | 0 Comments
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.

 “Planning without action is a daydream. Action without planning is a nightmare.” – Japanese proverb

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”…


Posted by: Nathaniel Bauer on 5/22/2014 | 0 Comments

If you work in a Microsoft System Center Configuration Manager (SCCM) environment, you are familiar with the major challenges you face during the deployment process within SCCM's native Operating System Deployment (OSD). First, you have to locate drivers for specific hardware components, then organize and package them. Next, you need to create a task sequence to advertise to a hardware-specific collection. If any errors present themselves along the way, you have to start again from square one.

On paper, it sounds easy, but in reality, when you consider how many different hardware configurations are scattered around your company, it quickly becomes an overwhelmingly complex and time-consuming process. It’s a process that’s necessary only because none of the native Microsoft tools features a driver database, which makes locating and managing the correct drivers a manual (and burdensome) process.

Streamline your deployment process with the UIU for SCCM

We can take the headache out of OSD through a fully integrated plug-in that safely and smoothly enhances and streamlines your existing SCCM 2007 or 2012 environment. Our Universal Imaging Utility allows SCCM administrators to easily advertise any UIU-configured task sequence to any collection of computers, regardless of manufacturer or model.

All you need to do is create a new, or modify an existing task sequence with the UIU Machine Configuration step, and you've completely eliminated driver packages from the process. During deployment, the UIU real-time discovery tool ascertains the onboard hardware, locates the correct drivers, and incorporates them with the image deployment, ensuring that only the most appropriate drivers are staged. By using only the  latest and most appropriate drivers, the UIU makes sure that every machine boots properly after every deployment.

The driver database
Drivers are always the lynchpin to any successful deployment, and a pain to manage. The UIU contains a fully vetted and updated driver database that validates and maintains over 2,000 business-class drivers and 40,000 Plug-n-Play Ids for supported Windows operating systems. And the database can be set up to update automatically. Because the UIU completely automates driver management, it eliminates the need for SCCM administrators to locate, manage, and package driver files.

The UIU enables IT departments to save considerable time and money by delivering a hardware independent image to any PC.

- Learn more about the UIU for SCCM or request a Free Trial


Share this post

Share UIU Blog via Twitter   Share UIU Blog via Google Plus  Share UIU Blog via LinkedIn   Share UIU Blog via Stumbleupon
Posted by: Nathaniel Bauer on 5/13/2014 | 0 Comments

As an educational institution in the age of ubiquitous computing, decisions need to be made regarding the technical support of any individual student’s hardware and/or software. There are many factors that must be considered prior to establishing a policy with regard to the same. These include, but are not limited to, hardware purchasing, standardization, support commitments (how far to troubleshoot before re-imaging), deployment and logistics - and let’s not forget network security.


How do we support student PCs? Or shouldn’t we?
As with everything else, there are reasons for and at least an equal quantity of reasons opposed. Without pretending to know all of the intricacies of every type of institution and give advice on what to do, I’ll simply offer up some points  for consideration.

Assumptions:
•    All students have PCs/laptops.
•    All institutions offer some form of network-based computing resources, ranging from 
      web pages (public or internal) to direct network connectivity.

Considerations:
•    Is PC computing required for curricula execution?
•    Is hardware supplied by/through the institution?
•    Is software supplied by/through the institution?

In the case where hardware is supplied by the institution, cost and tuition issues aside, efforts can (and should) be made to limit the selections of make/model and operating system. Uniformity enhances standardization, reduces security vulnerabilities, leverages purchasing discounts, and reduces logistics and support costs.

Student-supplied hardware could represent any make/model and could be in any state of vulnerability/security risk at any given time.

The case where an institution recommends or requires students to supply their own hardware, the problems change face a bit. For example, a criterion that enters the equation is whether the institution insists on providing an OS/Software image for the student computing population. Therein lie software (incl. OS) licensing as well as compatibility and version control issues. That’s a topic for another day…

How is this different from supporting PC Lab machines or staff PCs?

All student PCs are mobile (or at least we’ll assume/consider them to be as such). As student machines may be inaccessible by network administration services at any given time for any reason and without notice, we need to consider them to effectively be considered as mobile even if they may be traditional desktop/mini-tower models.

Simply put, PC Lab machines are not only under the control of some institutional entity, they are also static; they don’t move around. Desktop policies can be set, physical access can be gained at will, and visual inspections can be performed with regularity. Staff machines, although they may be mobile, are still firmly under control and policies and standards apply, whereas student machines are very often an unknown and frequently present not only security vulnerabilities but also logistics and maintenance issues. How can the institution be sure that updates are regularly applied? How can the institution be sure that the machine is not infected with a digital pathogen?



Student Supplied

Institution Supplied

Config Controlled

Support Staff monitoring/configuration

No worries, lock it all down!

Uncontrolled

Wild, Wild West - Rely on serious security infrastructure

Institution mandated protocol



If student-“maintained” machines are to be let anywhere near an institutional network, great care should be taken to mitigate threats, not just before they infect a network resource, but also after this has inevitably occurred. In addition to the standard anti-virus and anti-malware software, strategies such as the employment of “honey pots” or “ghost armies” can misdirect and distract would-be hackers, allowing more time to detect the intrusion and respond to the threat.

Let’s face it, support of multifarious machines with questionable levels of security and significant limitations on institutional control is looming if not already upon us.
How do we protect our network resources from the risk of infected student machines?

Is standardization an option? If so, use it heavily. Mandate that all student PCs have anti-virus/anti-malware installed and updated in order to gain access to network resources. Ensure that all public or Lab PCs have AV/AM enabled on all removable devices. Keep AV/AM as well as operating system patches up-to-date!

As it’s not a matter of “if” but “when”, have a lockdown protocol and practice it. Employ advanced misdirection strategies as discussed above. There are or will soon be both appliance and software implementations available to make it easier to instantiate.

How about break/fix?
Some institutions provide break/fix services; I would wager, however, that most insist the student take care of their PC issues on their own. This, in my opinion is strictly a liability/cost vs. service/value proposition. If the intention is to provide such a service on non-institutional machines, have the necessary waivers in place and, for the love of Homer, provide adequate training for your technicians.

That said, as institutions become more and more dependent upon PC computing to execute their curricula, they may be compelled to assist students with hardware/software problems in order to maximize the effectiveness of the application of same.

I hope that this is received as helpful and has provoked some thought. Please feel free to send constructive feedback.



Share this post

Share UIU Blog via Twitter   Share UIU Blog via Google Plus  Share UIU Blog via LinkedIn   Share UIU Blog via Stumbleupon
1 2 3 4 5 6 7 8 9 10  ...  Go to Page:  


    Login