Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 59 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
59
Dung lượng
2,2 MB
Nội dung
I n Chapter 9, “Deploying Applications,” you learned about the various application deploy- ment technologies that Windows 7 and Windows Server 2008 R2 provide. In this chapter, you learn more about the actual process of deploying applications using these technologies. ■ Design a delivery or deployment strategy. ■ Lesson 1: Deploying Applications Using Group Policy and SCCM 2007 ■ Lesson 2: Deploying Applications Using RDS To complete the practice exercises in this chapter, you must have the following: ■ A computer running Windows Server 2008 R2, which you have congured as an Active Directory Domain Services (AD DS) domain controller, and on which you have installed the Remote Desktop Services (RDS) role with the Remote Desktop Session Host and Remote Desktop Web Access role services. ■ The Microsoft Deployment Toolkit 2010 installation le (MicrosoftDeployment Toolkit2010_x64.msi or MicrosoftDeploymentToolkit2010_x86.msi) that you down- loaded in the practice for Chapter 3, “Creating and Managing System Images,” or any Windows Installer package le with an MSI extension. Contents Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Lesson 1: Deploying Applications Using Group Policy and SCCM 2007 . 392 Deploying Applications Using Group Policy 393 Creating Software Installation Policies 397 Deploying Applications Using SCCM 2007 402 Lesson Summary 415 Lesson Review 416 Lesson 2: Deploying Applications Using RDS . . . . . . . . . . . . . . . . . . . . . . . . 416 Overview of RDS Deployment 417 Understanding RDS Deployment Options 418 Deploying RemoteApp Applications 418 Packaging RemoteApp Applications 420 Lesson Summary 425 Lesson Review 426 Chapter Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Chapter Summary 427 Key Terms 427 Case Scenario 428 Suggested Practices 428 Take a Practice Test 429 Using Application Deployment Tools real World E Deploying Windows 7 to your desktop workstations is a complicated enough task, as you have learned in earlier chapters, but in most cases, workstations require more than the operating sys- tem to provide users with the tools they need to do their jobs. The workstations must provide users with access to applications, and administrators provide them with that access by devising an application deployment strategy. ■ Deploy applications using Group Policy Software Installation. ■ Deploy applications using SCCM 2007. Lesson 1: Deploying Applications Using Group Policy and SCCM 2007 Deploying applications using Group Policy has the advantage of requiring no special infra- structure beyond that of AD DS, which most enterprise networks already have. When compared to a manual installation of an application on a workstation, Group Policy deployment provides users with quick access to the software they need, with a minimum of interaction. Administrators might not trust end users to perform a manual installation of a complex application unaided, but end users can usually complete a Group Policy installation with no special assistance. As discussed in Chapter 9, Group Policy application deployment is package-based. To deploy an application in this manner, the application must be in the form of a Windows Installer package le with an .msi extension. Some application developers—and particularly Microsoft—supply their products as package les or provide package les on the application installation disks. For applications that do not include package les, your only recourse if you want to deploy them using Group Policy is to create the packages yourself. This requires an external utility because Microsoft does not include any package creation tools with Windows or with its applications. A variety of third-party tools are available, with varying capabilities, some of which are free and some commercial. A few of these package creation tools are listed in Table 10-1. Windows Installer Package Creation Utilities Visual Studio 2010 Microsoft http://www.microsoft.com/visualstudio/en-us/ Advanced Installer Caphyon, Ltd. http://www.advancedinstaller.com InstallShield Flexera Software http://www.exerasoftware.com/products/ installshield.htm Wise Package Studio Altiris/ Symantec http://www.symantec.com/business/package-studio WIX Toolset Microsoft http://wix.codeplex.com/ MSI Package Builder Emco Software http://www.emco.is/products/msi-package-builder/ features.php Using Application Deployment Tools exaM tIp A Windows Installer package le is a relational database that contains one or more products, with each product consisting of a number of features and one or more components. The component is the smallest unit that the Windows Installer engine can install. For example, a single .msi le might contain two products: an application in 32-bit and 64-bit versions. Each product might contain several features, which are the different programs that make up the application, with each feature having multiple components. The Windows Installer wizard interface typically displays the various features, as shown in Figure 10-1, enabling the user to select which ones to install. The Windows Installer wizard interface Windows Installer packages contain instructions that dictate how the installation process proceeds on the target computer. A package can include an interactive preinstallation phase, in which the end user can select a location for the application and the features to be installed, among other options. Packages can also be congured to install the application with no inter- action, either because the optional parameters are specied on a command line—a method called quiet mode—or because the default installation parameters are precongured in the package itself. Lesson 1: Deploying Applications Using Group Policy and SCCM 2007 Note The process of deploying applications to Windows 7 workstations using Group Policy involves the following three main components: ■ Software Installation in an extension to the Group Policy Management Editor snap-in, which appears by default whenever you edit a Group Policy object. Administrators use the extension to create Software Installation policies, which specify the packages to be deployed and contain settings that dictate how the workstations install the applications. ■ The Windows installation engine that reads the contents of Windows Installer MSI les and follows the instructions contained therein to install, maintain, or remove applications. All Windows server and workstation versions since Windows 2000 include Windows Installer, and associate the engine with the .msi le name extension. ■ The Windows 7 and Windows Server 2008 R2 com- ponent on which applications published using Group Policy appear. Users can install applications deployed to this control panel as needed. In Windows versions prior to Windows Server 2008 and Windows Vista, this component was called the Add Or Remove Programs control panel. The Software Installation extension is a component that uses Group Policy to associate packages with specic AD DS objects. AD DS then functions as a delivery service that deploys advertisements for the packages to specic computers and users on the network. After it’s there, the Windows Installer engine on the receiving computer processes the MSI package, executing the instructions it contains to install the application. Every Group Policy object has two Software Installation policies, one under Computer Conguration and one under User Conguration, as shown in Figure 10-2. Computers in the AD DS domain apply Computer Conguration policies when they start up, and User Conguration policies when a user logs on to the domain. Using Application Deployment Tools Software Installation policies in a GPO The Software Installation extension supports two types of package deployment, as follows: ■ The Software Installation policy creates an advertisement that, in the case of a user policy, adds the application to the target computer’s start menu, and can also associate specic le name extensions with the application. When the user launches the application for the rst time or opens a le associated with it, the system accesses the MSI le from the network and uses Windows Installer to perform the installation. The package advertisement follows the user to whichever computer she uses to log on. You can also assign packages to computers, in which case the installa- tion occurs automatically when the system starts. ■ The Software Installation policy creates an advertisement, which it stores in AD DS, and which adds the application to the Get Programs control panel in Windows 7 or Windows Server 2008 R2 (or the Add Or Remove Programs control panel in earlier versions). This enables the user to select the program for installation or removal at any time. You can publish a package only to users; the Computer Conguration policy does not support the publish option. Table 10-2 lists some of the questions you should ask when deciding the type of deployment you should use. Lesson 1: Deploying Applications Using Group Policy and SCCM 2007 Software Installation Deployment Options After the deployment, when is the software available for installation? After the next logon After the next logon The next time the computer starts. How does the user install the software? By using the Get Programs control panel By accessing the application from the Start menu or a shortcut The software is installed auto- matically when the computer reboots. If the software is not installed and the user opens a le associated with the software, does the software install? Yes (if auto-install is turned on) Yes Not applicable; the software is already installed. Can the user remove the software by using the Get Programs control panel? Yes, and the user can choose to install it again Yes, and the soft- ware is available for reinstallation No. Only an administrator can remove the software. The steps involved in creating Group Policy Software Installation policies are as follows: 1. Plan an AD DS strategy. 2. Create a software distribution point. 3. Congure Software Installation defaults. 4. Create Software Installation package policies. 5. Congure Software Installation package properties. When planning a Group Policy application deployment, you must review your organization’s software requirements and compare them to your AD DS organizational structure and your available Group Policy Objects (GPOs). With this information, you can determine how you want to deploy your applications. Then create a test environment to determine exactly how you want to assign or publish software to your users or computers. Using Application Deployment Tools Some of the basic strategies for Group Policy software deployment that you should consider are as follows: ■ Create organizational units (OUs) based on software management, rather than security, needs. This strategy enables you to target applications to the appropriate users. ■ Deploy software close to the root of your AD DS domain. Deploying software high in the domain hierarchy makes it easier to provide all of the users in an organization with access to an application. This reduces administration because you can deploy the pack- age using a single GPO rather than having to re-create the object in multiple containers deeper in the AD DS hierarchy. ■ Deploy multiple applications with a single GPO. In organizations where users share the same core set of applications, this practice reduces administration overhead by enabling you to create and manage a single GPO rather than multiple GPOs. Also, the user logon process is faster because a single GPO deploying multiple applications processes faster than multiple GPOs each deploying one application. ■ Publish or assign applications only once to a given group of users or computers. Deploying the same application in multiple congurations is sometimes necessary to support different types of users. However, you should avoid deploying multiple copies of the same application in such a way that users are forced to decide which version they need. Instead, adjust your deployment strategy wherever possible so that each conguration is delivered only to the users and computers that need it. A software distribution point is a location on a shared network drive on which you store the packages you intend to deploy using Group Policy. When you create a Software Installation policy, the package you specify is not actually stored in the AD DS database. The GPO con- tains only a pointer to the package’s location. Therefore, the package must be accessible, not only to the computer where you are running the Group Policy Management Editor, but also to the computers and users who are to receive it. You can create multiple distribution points or a single distribution one for all of your pack- ages as long as you create separate folders for each application and each version. Congure the share and NTFS permissions so that administrators have Read and Write access to the distribution point. Users need only Read access. The Properties sheets for the Software Installation folders in Group Policy Management Editor contain conguration settings that apply to all of the package policies you create in that folder. Some of the settings establish defaults for parameters you can customize on individual policies, as shown in Figure 10-3, while others enable multiple applications deployed by the same GPO to coexist. Lesson 1: Deploying Applications Using Group Policy and SCCM 2007 The General tab of the Software Installation Properties sheet For example, the File Extensions tab, shown in Figure 10-4, enables you to establish priorities for the le associations created by the deployed applications. If you install two applications that both create associations for the same le extension, you can specify which one of the applica- tions should launch when a user opens a le with that extension. The File Extensions tab of the Software Installation Properties sheet Using Application Deployment Tools When you browse to the Software Installation folder under Computer Conguration or User Conguration, right-click it, and select New | Package from the context menu, you must rst browse to the software distribution point you created and select the package le you want to deploy. After you do this, the Deploy Software dialog box appears, as shown in Figure 10-5, in which you can specify whether you want to assign or publish the package. When you deploy a package to computers (as opposed to users), the Published option is unavailable, and if you select the Advanced option, the package’s Properties sheet appears. The Deploy Software dialog box cautIoN Double-click a policy package (or select the Advanced option in the Deploy Software dialog box) to open its Properties sheet, as shown in Figure 10-6. On the Deployment tab, you can switch between Assign and Publish, as well as congure the following parameters: ■ Select this check box to use the application precedence for le name extensions as determined on the File Extensions page of the Software Installation Properties sheet. When you deploy the package to computers, the check box is selected and grayed out because the applica- tion is installed automatically by default. [...]... Remote Desktop Session Host The core service running on the server, hosting individual applications and full desktops Remote Desktop Session Host is a role service that is part of the Remote Desktop Services role on Windows Server 20 08 R2 servers ■ Remote Desktop Connection The client program running on the workstation Remote Desktop Connection is included with all of the current versions of Windows. .. 1 0-1 4 Lesson 1: Deploying Applications Using Group Policy and SCCM 20 07 CHAPTER 10 4 07 Figure 1 0-1 4 The Reporting page of the New Package Wizard 11 Click Next to accept the default settings The Security page appears, as shown in Figure 1 0-1 5 Figure 1 0-1 5 The Security page of the New Package Wizard 12 Click Next to accept the default settings The Summary page appears, as shown in Figure 1 0-1 6 4 08. .. the windows appear to the user just as they would if they were running the application locally ■ Deploying a full RDS desktop is basically a matter of installing the Remote Desktop Services role on a Windows Server 20 08 R2 computer with the Remote Desktop Session Host role service, and then installing the applications you want to share ■ RDS works by running applications on a Windows Server 20 08 R2... MicrosoftDeploymentToolkit2010_x64.msi or MicrosoftDeploymentToolkit2010_x86.msi file, select the file, and click Open The Deploy Software dialog box appears 5 Select the Advanced option and click OK The Microsoft Deployment Toolkit 2010 Properties sheet appears 6 Click the Deployment tab 7 Leave the Published option selected and clear the Auto-Install This Application By File Extension Activation check box 8 Click... process can be quite complex With SCCM 20 07, creating packages is a relatively straightforward process, but installing the SCCM infrastructure is complicated and expensive Deploying Applications Using SCCM 20 07 Chapter 9 discussed how you can use SCCM 20 07, in cooperation with Microsoft Deployment Toolkit (MDT) 2010, to deploy Windows 7 workstations on an enterprise network You can incorporate applications... provide users with access to a full RDS desktop Clicking RD Session Host Server Settings in the Action pane opens the RemoteApp Deployment Settings dialog box, as shown in Figure 1 0-2 7 Figure 1 0-2 7 The RemoteApp Deployment Settings dialog box When you select the Show A Remote Desktop Connection To This RD Session Host Server In RD Web Access check box, a Remote Desktop icon appears on the Web page as... Remote Desktop Session Host, the core service running on the server; Remote Desktop Connection, the client program running on the workstation; and Remote Desktop Protocol, the communications protocol that connects the Remote Desktop Connection client to the Remote Desktop Session Host service on the RDS server ■ RemoteApp delivers individual applications to clients in separate windows There is no RDS desktop. .. stored 6 In the Run drop-down list, specify whether you want the program to be visible as it runs 7 In the After Running drop-down list, specify whether the client system should restart after the installation is completed 8 Click Next The Requirements page appears, as shown in Figure 1 0-1 9 Lesson 1: Deploying Applications Using Group Policy and SCCM 20 07 CHAPTER 10 411 Figure 1 0-1 9 The Requirements... issue by delivering individual applications to clients in separate windows There is no RDS desktop involved; the windows appear to the user just as they would if they were running the application locally Users do not run the Remote Desktop Connection client to access RemoteApp applications; instead, they use a desktop icon provided by an administrator, or they click an icon on an intranet Web page Users... single session RemoteApp is therefore no less efficient than a full remote desktop, when it comes to the hardware resources it consumes on the RDS server Deploying RemoteApp Applications Deploying a full RDS desktop is basically a matter of installing the Remote Desktop Services role on a Windows Server 20 08 R2 computer with the Remote Desktop Session Host role service, and then installing the applications . versions since Windows 2000 include Windows Installer, and associate the engine with the .msi le name extension. ■ The Windows 7 and Windows Server 20 08 R2 com- ponent. Remote Desktop Web Access role services. ■ The Microsoft Deployment Toolkit 2010 installation le (MicrosoftDeployment Toolkit2010_x64.msi or MicrosoftDeploymentToolkit2010_x86.msi) that you down- loaded. discussed how you can use SCCM 20 07, in cooperation with Microsoft Deployment Toolkit (MDT) 2010, to deploy Windows 7 workstations on an enterprise network. You can incor- porate applications into