Microsoft Surface 3 - Manual (Page 24)

© 2014 Microsoft Page 24
deployment share must be capable of deploying to an entire organization. In other cases, deployment shares may be
only a limited deployment desired for a handful of users or a new set of hardware.
Consider the scenario where a fully developed and implemented solution is available for deploying notebooks and
desktops in the organization, but where a handful of Surface Pro 3 devices are being purchased for select users. With
these new devices comes the need to ensure that as they reach end users they are configured with select settings
required in the organization, but which reflect the new device capabilities, such as touch and Windows 8.1. In this case,
you may need to develop a deployment share specific to this new task and initiative.
If you create a new deployment share, you don’t necessarily need to create new images and configure the deployment
from scratch. If you already have images, applications, driver packs, and packages configured, a new deployment share
can use those by either copying or linking. This prevents needing to recreate the wheel for your deployments.
It would also be possible to copy the all-encompassing corporate share to a separate server and configured as a new
deployment share in which the images, applications, and any other components can be edited, modified, or even
removed without disturbing the production share. In this way, an existing corporate image can be quickly modified to
apply to new systems without affecting a critical production share.
Performance
In large enterprises, the performance of deployment is a crucial consideration. A deployment share improperly located
or configured can result in extended downtime which can translate to work stoppage or loss of productivity. As
deployment shares operate over the network, the same performance factors which affect standard file sharing and
network communication also apply to deployments through MDT. The same solutions also apply.
For example, in a data center environment for Virtual Desktop Infrastructure (VDI), high performance network
connectivity is common to meet the highly demanding nature of the systems in the environment. It would make logical
sense in this scenario to ensure that the Deployment Share for those virtual environments was located in the data
center for optimum performance. However, even if you have a data center deployment share, it may be better to create
a separate deployment share for computers that are in another building or location. The bottom line is that you need to
consider the performance of your network in relation to the location of the deployment shares.
Note: Some VDI solutions, such as System Center Virtual Machine Manager, include the ability to manage the creation
or replacement of virtual machines.
There may also be scenarios in which offline media is the ideal solution, as MDT is fully capable of generating USB or
optical media for physical distribution. Workers who operate remotely from home or contract workers who travel from
site-to-site are two examples of where this might apply. Deployment with offline media is covered in the step-by-step
process in
Chapter 5 .
Security
As mentioned before when discussing isolation, security is another important facet in determining how deployment
shares should be configured. Beyond the simple concept of a fully open deployment share for system administrators
working on the deployment project and another for production users with fully configured security, there are also
scenarios where multiple shares can be utilized to provide granular security for targeted deployments.
For example, an organization could operate a deployment share which is available full time to one select set of users
who might have the need to refresh their systems at will, but only a limited configuration for deployment is available.