When Does Driver Injection Make Sense?

Over the years I've generally stayed with a specific piece of advice when performing driver injection when deploying Windows images using Microsoft Deployment Toolkit or System Center Configuration Manager. You start with the expanded driver files and import them while removing drivers that are not relevant to the platform you are deploying. Then you deploy the operating system with driver injection to see which drivers successfully install then remediate the remaining by installing them manually and using a tool such as Driver Magician to export the drivers for import into Configuration Manager. Or you might need to make silent installations of the OEM driver installers that get installed as packages via the task sequence after the Windows operating system has been applied.

All of these techniques generally works well with the exception of storage and network drivers because if Windows PE does not have network or more importantly storage drivers that work with your hardware you won't be able to image the machine. If you look deeper you might realize that there is even more that needs to be considered when deploying drivers with your Windows operating system. For example the most obvious issue is the front end software a driver might have to perform tasks such as further configuring the behavior of the device to updating the device software on a regular basis. For example some of my users using a high end display setup may want the advanced configuration control panel for their device that would not be offered if we did simple driver injection. A perfect example would be the NVIDIA control panel below.

Of course automatic updates might not be desireable in an enterprise but the advanced features may be something to consider. Off the top of my head I've seen the following types of devices use additional software to enhance the driver experience.

• Mouse / Pointer
• Keyboard 
• Display
• Printer / Scanner / Multifunction Printer
• Trusted Platform Module Chip
• Network Adapters
• Bluetooth
• Sound Devices

Further to that there are some installers that expose more information about the device via WMI and the driver installer creates the related classes. The reason this might be of importance is if you are using client management software such as System Center Configuration Manager to collect hardware inventory data of your deployed systems.

What I am trying to recommend is that you take a closer look at how you build your systems and determine if deploying the driver itself gives the user the experience they need and satisfies the system administrator's requirements rather than just injecting as much as possible. The network and storage drivers will need to be initially injected if Windows PE cannot communicate with the devices out of the box but where you go from there should be done with some care rather than following some hard and fast rules.

Azure RemoteApp & App-V: Cloud Service vs Resource Manager

I've been playing around with Azure RemoteApp and App-V in Azure to find a nice little limitation that I think is a huge design consideration. Lately I've been deploying my virtual machines with Azure Resource Manager because it is the future platform and it offers many features not available in the Azure Cloud Services model. The main attraction to me is network security groups where I can essentially configure a network level firewall for different systems in Azure. But more importantly is the Resource Manager Templates, these allow you to build environments in Azure that can be exported to templates so that they can be easily provisioned for development, test and production environments.

The issue I wish to discuss is about a limitation many of you may not be aware of unless you try to deploy RemoteApp and require connectivity to servers in Azure Resource Manager. The first limitation is that the Azure RemoteApp servers must reside on a different virtual network than the servers provisioned using Azure Resource Manager. There can be no sharing of VNet address space between models. The most interesting part is that these virtual networks do not communicate to each other by default which creates the most challenging piece of the problem.

In order to provide connectivity between virtual networks you will need to implement a VPN between virtual networks. This means your bandwidth between networks will be constrained to 100 megabits (basic and standard) to 200 megabits (high speed) depending of the gateway you are using inside of Azure.

If you are deploying App-V Management Servers in Azure and want the best performance I would recommend that you deploy those virtual machines using Cloud Services for the short term. You may also want to keep this in mind with the supporting application infrastructure because the gateway could get congested with that traffic as well.

Here are some links as to help you with configuring the VPN if you need to pursue this architecture.

Connecting classic VNets to new VNets

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-arm-asm-s2s/

About VPN gateways

https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-about-vpngateways/