After you place the software distribution point servers, you
must configure each server for the software applications that are
accessible to users. Configurations include granting the appropriate
permissions so that users (for user-assigned applications) and computers
(for computer-assigned applications) can gain access to the software.
After you complete the deployment, you cannot change the path to another software distribution point without redeploying the software package. Redeploying software can be quite intrusive to users because it automatically removes the application on computers where the software is already installed. If the software is assigned, it is reinstalled automatically; if it is published, it must be manually selected again for installation by using Addor Remove Programs or by opening an appropriate file type.
Important
Typically, you copy the Windows Installer packages to an intermediate location and then run Setup /a from there to the destination that you want. Alternatively, you can run Setup /a from and to the software distribution share itself. The drawback of this method is that it unpacks the .cab files, and then leaves them on the same share as the Windows Installer package. This method uses space on the share. However, many administrators do this intentionally so that the .cab files are always available from the destination share. This is a matter of preference, or ease of use, and does not affect performance.
When you set up a software distribution point server, be sure to maintain the security of your network by performing the following tasks:
Set the following discretionary access control list (DACL) permissions:
To help you assess the administrative and user requirements in your organization, see "Planning a Managed Environment" in this book. To learn how to create and then link a GPO to a site, to a domain, or to an OU, see "Designing a Group Policy Infrastructure" in this book.
After you complete the deployment, you cannot change the path to another software distribution point without redeploying the software package. Redeploying software can be quite intrusive to users because it automatically removes the application on computers where the software is already installed. If the software is assigned, it is reinstalled automatically; if it is published, it must be manually selected again for installation by using Addor Remove Programs or by opening an appropriate file type.
Important
-
When you create a DFS software distribution point for a new application,
you must specify a different DFS path, regardless of whether the target
software is on the same share. You can then retire software
distribution points for the old software by taking down targets of the
DFS tree while all the new software distribution points of the new
application remain available.
Typically, you copy the Windows Installer packages to an intermediate location and then run Setup /a from there to the destination that you want. Alternatively, you can run Setup /a from and to the software distribution share itself. The drawback of this method is that it unpacks the .cab files, and then leaves them on the same share as the Windows Installer package. This method uses space on the share. However, many administrators do this intentionally so that the .cab files are always available from the destination share. This is a matter of preference, or ease of use, and does not affect performance.
When you set up a software distribution point server, be sure to maintain the security of your network by performing the following tasks:
-
Restrict physical access to the server to the administrators who must physically touch the server.
-
Consider using digital signing. For more information about digital certificates, see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services of this kit.
-
Create the folders for the software on the server that you designate as
the software distribution point, and then make the folders network
shares. For example: \\Server_Name\Share_Name
-
Copy the Windows Installer packages, application executable files, .mst
files, .msp files and .zap files (if used) to the appropriate shared
folders.
-
Set appropriate permissions on the folders.
Set the following discretionary access control list (DACL) permissions:
-
Everyone: Read
-
Administrator: Full Control, Change, and
Read. Grant these permissions only to software deployment administrators
who must add or modify installation packages on the server. Also, limit
access permissions to only those permissions that the administrators
need to do their jobs. Note that administrators who have edit rights on a
GPO effectively acquire local administrator rights on all computers
that receive that GPO to install and remove software, although they do
not become local administrators.
-
You must have software licenses for software that is written by
independent software vendors and distributed by software distribution
points. It is your responsibility to limit the number of users who gain
access to software through software distribution points to the number of
licenses that you own. It is also your responsibility to verify that
you are working within the licensing requirements that are provided by
each independent software manufacturer.
Targeting Software
After you distribute prepared applications to the appropriate
software distribution point servers, target each application to a list
of intended recipients. Recipients can be specified users, groups of
users (such as all members of a certain defined OU), computers, or any
combination of these.
Typically, administrators define the hierarchical structure of the sites, domains, and OUs for Active Directory. They do this based on an assessment of their organization’s business objectives, administrative requirements, and user needs. When you perform your assessment to target software to users and computers, you narrow your scope to the software-based needs of all users in the organization and the administrative requirements for managing the software. It is essential that you consider the Active Directory structure when determining your software deployment strategy.
It is also important that you evaluate each application that you plan to deploy, from the perspective of both the users who need the application and the administrators who will manage it.
Typically, administrators define the hierarchical structure of the sites, domains, and OUs for Active Directory. They do this based on an assessment of their organization’s business objectives, administrative requirements, and user needs. When you perform your assessment to target software to users and computers, you narrow your scope to the software-based needs of all users in the organization and the administrative requirements for managing the software. It is essential that you consider the Active Directory structure when determining your software deployment strategy.
It is also important that you evaluate each application that you plan to deploy, from the perspective of both the users who need the application and the administrators who will manage it.
To assess the administrative requirements and business needs of the users in your organization
-
Identify what software is mandatory for your entire organization and
what software is appropriate for a particular job or business unit.
-
Identify the users who must have specific language versions of the software.
-
Determine whether to assign the software to users or to computers, or to
publish for users. If you assign software to users, decide whether you
want the software to install fully after computer startup, or if the
on-demand approach works better for your users and your network
infrastructure requirements. See "Assigning and Publishing Software" later in this chapter.
-
Identify remote software installation requirements.
-
Determine whether you must customize the software for different parts of the company.
-
Determine how often you will have to update user templates or custom files.
To help you assess the administrative and user requirements in your organization, see "Planning a Managed Environment" in this book. To learn how to create and then link a GPO to a site, to a domain, or to an OU, see "Designing a Group Policy Infrastructure" in this book.
No comments:
Post a Comment