UIU Blog

Krack Wi-Fi vulnerability
We at Big Bang have been following the news regarding the WPA2 hack known as Krack (key reinstallation attack).

During the week of October 16, 2017, researchers announced the discovery of a vulnerability which exploits the WPA2 protocol and allows attackers to steal sensitive information from unencrypted communications. It may also allow attackers to inject code (presumably malware) into websites.

"It’s important to keep the impact of KRACK in perspective: KRACK does not affect HTTPS traffic, and KRACK’s discovery does not mean all Wi-Fi networks are under attack."

The list of Wi-Fi vendors/chipset manufacturers is extensive and Big Bang is in the process of searching/monitoring each vendor for updates to their wi-fi network drivers that specifically address the Krack vulnerability. This process is entirely subject to the availability of adequately-prepared drivers by the chipset manufacturers. We anticipate that this update will take place over a lengthy period of time and in fact, may not be realized for those vendors that are out of business, no longer supporting versions of chipsets or are not prepared to update their device drivers.

If you become aware of a wi-fi network driver that specifically addresses the Krack vulnerability and you suspect that we have not yet encountered that driver, please bring it to the immediate attention of Big Bang Support.

Thank you for your patience and assistance.

For additional information, please refer to the following links:
KRACK Vulnerability: What You Need To Know
Key Reinstallation Attacks: Breaking WPA2 by forcing nonce reuse
Here’s what you can do to protect yourself from the KRACK WiFi vulnerability

Upgrade now to the UIU Plug-ins 2.0
Automated driver management for OS deployments with the UIU just got even better!

Big Bang is proud to announce the UIU Plug-ins 2.0. The UIU Plug-ins 2.0 is an upgrade to the existing 1.x versions of the UIU plug-ins for SCCM and MDT and is now available to all UIU customers.

If you are currently using one or both of the UIU plug-ins for SCCM or MDT, please follow the appropriate UIU User Guides to download and install the UIU Plug-ins 2.0. The UIU Plug-ins 2.0 is designed to be installed alongside your 1.x implementation for a seamless upgrade experience.

Once you have installed and verified that your 2.0 implementation is complete, you're ready to remove 1.x from your environment:

  1. Ensure that the UIU Machine Configuration Step has been removed from all Task Sequences. Task Sequences that still have the UIU Machine Configuration Step after the uninstall of 1.x will be unrecoverable without assistance of UIU Support. (Note: The 2.0 plug-ins will utilize the UIU Deployment Configuration Step.)

  2. Note that the 1.x uninstallation process will mandatorily remove files in the original source location! In order to preserve the existing UIU Repository, move the contents of the existing UIU Repository source location to a new UIU Repository source location to be used with the UIU Plug-ins 2.0. The UIU Repository source location is the root folder that contains the x86, AMD64, and Repository folders (some implementations may also contain SQL CE 4.0 and/or Components folders). Leave the empty source location folder there.

    UIU Plug-ins 2.0 Upgrade - Uninstall 1.x

  3. Modify the existing UIU Package in SCCM to use this new source location for use with UIU Plug-ins 2.0.

  4. Uninstall the UIU 1.x from Programs and Features in the Control Panel. When presented with the option to remove package(s), uncheck the box(es) to avoid removing the package(s)—this will allow for the removal of the UIU program files and the now-empty source location folder while preserving the package(s) in SCCM.

UIU Plug-ins 2.0 Upgrade - Uninstall 1.x

Please let us know how we can help, and we look forward to hearing what you think!

HP Laptop Keylogger

The problem

An audio driver, supplied by Conexant for HP, may be covertly logging user keystrokes, creating a security issue.

The driver software apparently monitors every keystroke a user makes due to a "debugging" section of code that was not removed prior to market release. The devices then store the key strokes in an file, unencrypted, on the hard drive.

The audio driver provided by Conexant logs all keystrokes to a file or prints them to the system debug log, where the data, including user credentials, could be easily accessible.

HP reports that "a potential security vulnerability caused by a local debugging capability that was not disabled prior to product launch has been identified with certain versions of Conexant HD Audio Drivers on HP products. HP has no access to customer data as a result of this issue."

HP further asserts that the keylogger in question does not appear to be malicious. "There’s no evidence that the keylogger actually does anything with the keystrokes it captures beyond saving them to your PC."

Impacted HP products are shown in the table at this link: HP Support Communication - Security Bulletin: Conexant HD Audio Driver Local Debug Log

More resources: Ars Technica article: HP laptops covertly log user keystrokes, researchers warn

How to Check if Your HP Laptop Has the Conexant Keylogger

HP laptops released in 2015 and 2016

Navigate to C:\Users\Public\ and see if you have a MicTray.log file. Double-click it to view the contents. If you see information about your keystrokes, you have the problem driver installed.

If you do see data in this file, you’ll want to delete the MicTray.log file from any system backups it may be a part of to ensure the records of your keystrokes are erased. You should also delete the MicTray.log file locally to erase the record of your keystrokes.

"To check whether this is happening, download and run Microsoft’s DebugView application (DebugView v4.81) . Look at the DebugView application and press some keys on your keyboard. If the Conexant audio driver is capturing keystrokes and printing them as debug messages, you’ll see many “Mic target” lines, each with a scancode. If you don’t see a MicTray.log file with keystrokes in it and you don’t have any “Mic target” output visible in DebugView, congratulations. Your system does not have the buggy audio driver software installed and running."

How-To Geek article: How to Check if Your HP Laptop Has the Conexant Keylogger


HP has provided software updates for Conexant HD Audio Drivers: HP Support Communication - Security Bulletin: Conexant HD Audio Driver Local Debug Log

If the fix hasn’t been released yet, or you can’t run Windows Update for some reason, you can remove the software that causes the problem. You will need to locate MicTray64.exe or MicTray.exe in Task Manager, right-click it, and select “End Task”. Then delete the MicTray.exe or MicTray64.exe file. This may inhibit some media function keys on your keyboard.

When will Big Bang release a new UIU Driver Database?

(As of May 18, 2017)

UIU Support has acquired the repaired drivers for all available, UIU supported OS's and is testing a new database release at this time. This is our top priority, and please contact us if you'd like notice immediately upon release of this update.

Fix a failed Application Install/Uninstall

So, you’re sitting at your PC (or a customer/user’s pc) minding your own beeswax, just installing an application, or perhaps uninstalling an application when… BAM! Something awful hits the fan! Now the bloody thing is all locked up and not responding to any key strokes or mouse clicks. It won’t even let you open up Task Manager to see what in the hell it might be up to, even though you’re pretty sure that it’s up to absolutely nothing…

Now, invariably, the user was standing, looking over your shoulder, absolutely clueless about the fact that you’re boned and about the fact that you too are absolutely clueless… (No, I’ve never been in that position!)

If you’ve been working with PCs for any appreciable amount of time, any good troubleshooter knows that sometimes, for one reason or another, an install or uninstall will get “borked” and that usually happens at just the wrong moment, of course. Thank you Murphy, for that little gem of a “law”…

What happens during application installation or uninstallation?

Lots of stuff, really: files get copied, registry settings are potentially altered or created, active directory information may be read or altered, schema extensions may be initiated, operating system variables may be set, and Programs and Features registration is typically instantiated. Of course, it varies widely based on application demands and requirements… When, for various reasons, one of the necessary steps for an app install or uninstall doesn’t complete or fails outright, it can leave the app in a state of limbo, inhibiting the required re-installation of the app or, in extreme circumstances, it can inhibit the usefulness of the entire system. At the very least, it leaves administrators with a loss of confidence in the system and a dread that the problem is indicative of future time-consuming troubleshooting.

What can you do when it all goes bad?

I’ve personally used many methods in the past including registry/file scraping where I try to find all references to the app and ruthlessly (albeit recklessly) remove all discovered instances, in a subtle homage to Orson Wells. I’ve also tried clearing temp files and have, of course, resorted to the time-tested “restart and see if that helps” method, usually followed immediately by, “Ok, let’s see if a hard boot helps”. What else? I’ve restored from Restore Points, run OS diagnostics; I’ve even run some very questionable, 3rd party applications to “reset” the registry. Basically, I’ve tried everything short of waving chicken bones, drenched in the blood of the vanquished, under a full moon at midnight on a solstice. I’m saving that one for a really critical situation!

Although some of these solutions have worked some of the time, most of them live in the “60% of the time, it works every time” category. Although there are not hard-and-fast, always effective methods, I’ve been made aware of some interesting tools from Microsoft and, so far, have had success with them. I thought others may appreciate knowing about them.

Microsoft FixIt – Fix problems with programs that cannot be installed or uninstalled

This tool is so simple to execute that I’m having difficulty elaborating, so perhaps for once, I won’t. Suffice it to say that the UI is intuitive.

Download MS Fix It - Fix Problems - Install/Uninstall

Choose desired level of automation:

MS Fix It Troubleshooter

Indicate when the problem occurs:

MS Fix It uninstall install

Select the affected product (this example = uninstall):

MS Fix It select affected program

When the process is complete, you’ll receive a results screen indicating that it was (or was not) able to resolve the problem. It’s that simple.


Microsoft MsiZap

This tool is a bit more involved and, I presume, a bit more risky — think of “malware detection programs reminding you that removing some discovered items may result in the untimely death of your OS” risky. The tool removes all Windows Installer information for one or more applications on a PC through the clever use of Product Codes. With command line options, you can also elect to remove rollback information, remove the “In-Progress” key, or even change ACL’s to Admin Full Control.

Download MsiZap

As the command line nature of the application can be a bit unwieldy, I’ve included a link to examples of its use as well. Heads-up! You’ll need to be able to determine Product Codes for applications that you’d like to target. Fun!

Syntax Examples:

MsiZap Examples

That's all for now

In summary, we all have our methods; some of those methods are more sound than others or at least more based in actual computer science and we’ll likely continue to employ what we perceive to have worked for us in the past. That’s great. Here are two more for your arsenal. Godspeed, John Glenn!

But Windows 10 already has all the drivers I need – No, not really. (Again.)

With the release of each successive new Microsoft operating system, from the most recent Windows 8.1 going back to at least Windows 2000, Microsoft tries to tell us the same thing; namely that the operating system already contains all the required drivers for all hardware components on all machines, old and new.

Arguably, with Microsoft's release of each new operating system, new drivers are included in the inbox driver store and can increasingly, successfully avoid initial problems with BSOD, and other common first-run issues. Windows 10 promises to be nothing different.

But here's what you should know. The drivers that do get included in the inbox driver store (native to the OS) are by and large generic drivers or, at the very least, antiquated versions of drivers that are multiple revisions old. While these outmoded drivers may successfully install and control the individual hardware components, interoperability with the operating system and certainly feature richness for that hardware may be impacted or altogether missing. Furthermore, the inbox drivers generally include no access to customization software.

For example, the new Microsoft Surface includes a driver for the Intel HD 4000 graphics chipset which, in fact, is discovered and installed allowing the device to operate. That said, there is noticeable performance increase when using the official, up to date driver from Intel including access to more features native to the hardware relating to frame rate and power saving technology (improving battery life), which may be considered paramount to the usefulness of such a portable device.

Also, on many platforms including the Surface, there is a noticeable improvement to SSD disk access (random and/or sequential reads and writes) when using Intel's AHCI drivers (iastor) over Microsoft's AHCI drivers (msahci).

We have found, (since 2005), that as time progresses, particularly as it extends past the release of the new OS and generally past the release of each successive Service Pack, that the quantity of drivers specific to a released OS/SP (and not included in the inbox driver store) grows substantially up to and shortly following the end of MS Support for that OS.

Microsoft has consistently demonstrated no willingness to deliver updated drivers in a time-critical or comprehensive manner; instead, they have relied upon OEM PC manufacturers (new hardware releases/sales), component manufacturers (existing hardware), and third-party software (regular OS deployments) to provide updated, OS-specific drivers.

So overall, the native inbox driver store will in fact get the associated hardware to operate with rudimentary functionality. But such generic drivers will not allow the machine to take full advantage of the hardware to which they're associated, and represent a potentially significant opportunity lost on a substantial capital business investment.

So, does Microsoft include all of the drivers you need?  Well, again, not really.

New Website for Big Bang and the UIU

Oh, you’ve noticed? We’re blushing.

For those of you that didn’t catch it, our website got a little facelift complete overhaul this past week. In addition to a fresh look and the marriage of the once-separate Big Bang and UIU sites, our new slice of cyber real estate includes improved functionality and brand-new features (with more to come!)

Responsive design for tablets and mobile

In addition to our new desktop site, we’ve added both tablet and mobile versions, so you can browse easily from the device of your choice.

Revised navigation for easy UIU version selection

Whether you are using the UIU Classic (better known as the UIU 4.x to you lifers out there), the new UIU 5, or one of the UIU plug-ins for SCCM or MDT, you’ll find it all here.

Expedited UIU Support case handling

Speed up your support experience with the improved UIU Support request form. Submit the form for your next technical support issue, and a ticket will be automatically generated and sent to our technical support team. You’ll receive an email notification that your case has been received and also get a reference number to include in future emails for speedy handling. Also, please remember to attach any applicable UIU log and setupapi files for faster resolution of your issue.

Online User Guides for every UIU version

Browse the UIU Install and User Guides through each UIU version’s Table of Contents, or go old-school-but-effective with your browser’s built-in search capability.

RSS feed option for UIU Release Notes and UIU Blog

Whether you are an existing customer or testing with the free UIU Trial, you can sign up to receive notifications of industry-related blog posts and news about UIU Updates (you can also, of course, follow us on Facebook and Twitter).

Let us know what you think!

We’re adding new content and features every week, so check back for all-new UIU videos, case studies and additional resources. Let us know what you think below or email us here.

Purchasing Business PCs - 10 things to Consider
When starting a large project, it helps to have all of my thoughts in one place…particularly when making sizable hardware acquisitions. I've in the past made the mistake of focusing so intently on a single goal for new hardware (a Win7 migration, for instance) that I improperly weighted several considerations. I've therefore included below a reasonably complete list of things that I consider when evaluating and purchasing PCs (read including laptops, notepads, etc.) for business use:
1. Cost
Given the general requirements for standard business computing, some PC hardware is simply too expensive. There is a company whose namesake is rather fruity that arguably builds better hardware than its competitors. It's also considerably more expensive. I have found that for its use in general business (graphic design is a notable exception) it is about twice as expensive as relatively comparable IBM hardware models. Let's face it, most of these machines are going to sit there and grind out processes that represent only a small percentage (if we don't count java-based or flash games) of the machine's capacity. 
2. Longevity
You must take into account the business' hardware attrition cycle. Are PCs kept for the standard three year cycle or has that cycle been extended by economic concerns? Perhaps the cycle is shorter due to ever-changing specialized, proprietary software demands. Buy hardware with components in sufficient quantities to ensure that the machines are useful through the end of their cycle, especially those components that are inexpensive. Nobody wants to spend evenings and weekends adding RAM to old machines because an original purchase was unnecessarily chintzy, n'est ce pas?
3. Volume discounts
Depending upon how much hardware you're intending to purchase, buying it piecemeal is always a more expensive proposition over time (duh, right?). When negotiating, be sure to know what the price break points are. It may be less expensive, or at least more economical, to acquire a few extra units at a steeper price reduction.
4. Operating system
Most PCs include an operating system of a specific (typically the most recent) version. You'll want to consider whether or not you can roll-back to a previous version with no additional cost if desired. Or you could try …
5. Volume licensing
Upon the advent of Windows Vista, Microsoft's volume licensing, or more aptly stated, activation model became much more cumbersome. The choice between MAK and KMS is dependent upon many factors, including minimum machine counts (activation thresholds), and the availability of a machine to run the Key Management Service with access to the Internet. Still, volume licensing can save you a ton of headaches if you're using one of the common deployment solutions to deliver ready-to-use PCs to your users. (Here, read all this ©гαϷ: http://technet.microsoft.com/en-us/library/ff793423.aspx).
6. Unintegrated components
Depending upon your business' computing requirements, some hardware is simply unnecessary. You don't need a high-definition graphics card on a PC that will likely only run a browser and a document production suite.
7. Brand loyalty
Let's face it. It's a factor. It may be one established solely based on anecdotal experiences. It's still manages to find a way to remain a factor…Do with that what you will.
8. Quality and reliability
Overlooked more than you'd guess, make every attempt to avoid first year models when possible. Read the reviews; weed out the zealots at the top and the crazies at the bottom. Go for reasonable. Check the manufacturer's knowledge base and user forums for endemic issues.
9. Driver availability and packaging
Some manufacturers do a better job than others with providing a complete set of drivers for each make/model of PC that they produce. However, in their efforts to add their special features and software, the drivers that they provide are often not the most up-to-date. Hell, in some cases, new hardware has been released without making the associated driver set downloadable for weeks afterwards! Perhaps this adds to the experiences that establish (or ruin) brand loyalty?
10. Usability
If the unit (particularly notepads/laptops) is easy to type on/navigate and the display is adequately sized, offering resolutions that are conducive to the eyesight requirements of the individual user, ergonomic issues can be avoided and the unit is more likely to be regularly used. Difficult to use devices are often circumvented.
11. Aesthetics (Look and feel) – BONUS ITEM!
Last, but certainly not least—and arguably the most subjective of all criteria—we can consider aesthetics. The visual appeal of the hardware can actually affect its performance. Small, visually pleasing devices are far more likely to be placed in visible, and therefore better ventilated, locations with adequate circulation, reducing the long-term effects of heat on the internal components.

While it may be technically infeasible to consider all of the variables simultaneously, at least, given full consideration, an administrator can choose which are most important to her organization and set about selecting specific models to pilot in her environment.

Bonne chance et bon courage!

Matthew Burger
Big Bang LLC

Forced to bid out your purchases?

In the case where you are forced to bid out an order of PCs, be a specific as possible with respect to your ACTUAL requirements. If you're not specific enough, you may get stuck with a lower, sub-standard set of machines! For example, specify USB 3.0 (if desired/required) as opposed to simply USB. Otherwise you may be forced to buy machines with USB 2.0 ports when the competing bid comes in less expensive.

5 Steps to Switching OS Deployment Solutions
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…

Drastically Improve Image Deployment for SCCM

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

Considerations for Supporting Student PCs

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.

  • 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.

  • 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?

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 that 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.