Driver management, Application management – Microsoft Surface 3 User Manual

Page 26

Advertising
background image

© 2014 Microsoft

Page 26

Driver Management

As the Microsoft Deployment Toolkit is able to manage drivers independently of the operating system image, there is a

separate section for Drivers in each deployment share. In some scenarios, like a share designed only to deploy to one
make and model of computer, you can simply place the available drivers in this section and MDT will automatically
select the most up to date applicable drivers for use at the time of deployment.

Note: It is not recommended to leave the drivers section of the deployment share unorganized. Even for a single make

and model of computer, different drivers may be required for different environments, such as Windows PE and
Windows 8.1. It is always recommended to organize drivers by make/model and operating system.

A deployment share might be used to deploy to many makes and models of computers, or the drivers for a make and

model might have incompatibilities with the boot environment. It is recommended to organize your drivers into folders,
based on make/model of computer, then by operating system. Within the Drivers section of the deployment workbench
folders can be created in which to organize the available drivers and Selection Profiles can be created that target these
folders under certain conditions, such as the use of a specific Task Sequence or when certain variables are met.

Selection Profiles are governed by simple configuration files in which a set of components can be selected and

identified. Through them the process of selecting application sets, driver sets, and packages can be greatly simplified
and automated.

For more details about downloading and configuring Surface Pro 3 drivers and firmware, see

Chapter 3

and

Chapter 6

.

Application Management

Similar to the way drivers are managed, MDT can manage the deployment of applications separate from the operating

system image. In order to allow MDT to manage an application, the installation files must first be brought into the
deployment share by selecting New Application and specifying the installation files and the commands which apply to
the installer. It is also possible to deploy files which are located outside the deployment share, such as if an application
installer repository already exists on the network. This is covered in more detail in the

Importing Applications section of

Chapter 5

.

As outlined in the

Considerations for Images section later in this chapter

, it is highly recommended to allow MDT to

manage as many applications as possible. The reference image should contain only the applications that will never
change because they cannot be easily altered after the image is created. For example, you would not build an image
with the latest version of Adobe Flash or Oracle Java required for browsing an internal site, because when deploying to
another set of computers in the future, you may discover newer versions of those frameworks have become available.
When the applications are managed by MDT, you can simply add the updated applications and remove the outdated
ones to ensure the latest versions are deployed.

MDT also supports post-deployment only task sequences that facilitate application deployment and operating system

configuration. Through these task sequences, the operating system is not re-deployed, but applications can be installed
on systems which did not originally receive them. MDT is not a full-fledged application deployment solution as it does
not provide management of the deployed systems or applications. For that you would need to implement System
Center Configuration Manager. With that said, MDT does support applications to be installed in a base image. Whether
this type of configuration is in the best interest of your environment is dependent on the applications in your
organization.

Advertising