Gp'de remote desktop hakkındaki user

To minimize the number of GPOs that you must have to install the software applications in the environment, it is recommended that you set the GPOs to publish a number of related applications. For example, if you determine that when users install Microsoft® Project, they typically also must have Microsoft® Visio® drawing and diagramming software. Therefore, it makes sense to combine these two applications in a single GPO. By logically grouping applications, you can reduce overall administration and management costs.

An alternative to grouping applications is to create a separate GPO for each application you want to manage by using Group Policy. By creating separate GPOs, you have more flexibility because the application of GPOs is more specific. However, the number of GPOs that are assigned to each client is higher. More GPOs leads to slower start and logon and times. However, the number of settings in each GPO is the most important factor because processing each .adm file requires a set amount of time, regardless of the number of settings that the file contains.

In small organizations, it is not uncommon to see more than 100 different applications. In large multinational organizations, the number can be significantly higher. It can be difficult and time-consuming to manage all these applications by using a separate GPO for each application. However, if it ever becomes necessary to delete or disable an application installation Group Policy, deploying the applications in separate GPOs can prevent massive removals and reinstallations of the applications if the applications fall out of management scope (for example, if the client computer or user is moved to another organizational unit). Administrators must balance the benefits of this approach from the point of view of both administrators and users.

When you create GPOs for software deployment, it is recommended that you do the following:

• Create separate GPOs for administrators, based on their roles, to simplify administrative delegations. However, these administrators must communicate with each other about the applications that they are deploying to avoid affecting each other’s installations and creating unnecessary network traffic.
  
  
• Use GPOs to match applications to users and the tasks they perform.
  
  
• Assign or publish a package only once per GPO. For example, assign Office XP to the computers that are affected by a GPO, but do not assign or publish it to users who are affected by the same GPO.
  
  
• Minimize the number of GPOs that you create because the overhead for processing each GPO increases user logon time. Network performance is much better if you use a single GPO that deploys 100 applications than if you use 100 targeted GPOs. Take advantage of GPO inheritance to distribute the application throughout your organization. If necessary, use security descriptors, such as Access Control Entries on the GPO for finer control over who receives the software.
  

Note

• The depth of OUs has very little effect on client processing time per GPO. However, a deep OU hierarchy can significantly complicate the troubleshooting process. For more information about inheritance and security descriptors, see "Designing a Group Policy Infrastructure" in this book.
  
  
  
  
  • Place GPOs that assign or publish software applications as high as possible in the organizational unit structure. This makes it easy to give all users or computers in an organization access to an application. It also reduces administration because you can use a single GPO to assign or publish an application, instead of re-creating that object in multiple containers that are lower in Active Directory.
    
    
  • Plan ahead for removal when you initially deploy the software. If you want the application to be removed when a GPO is no longer applicable, select the Uninstall this application when it falls out of the scope of management option. You can configure this option on the Deployment tab in the Properties dialog box. Right-click the managed software in Group Policy, and then click Properties.
    
    
  • Specify application categories. When you use categories, it is easier for users to find applications in Add or Remove Programs. You can configure this option on the Categories tab in the Properties dialog box. Right-click the managed software in Group Policy, and then click Properties.
    

Important

• Security Group filtering is not recommended because the final effect of filtering is difficult to predict before deployment or to analyze afterward. Although using this method might seem simple at first — one GPO can be used for everyone, with certain settings excepted for certain groups — it is difficult in practice.
  

The impact of advertisement scripts on startup and logon time   Evaluate the size of each advertisement script of every application that you assign. The size of the script can vary dramatically, from 1 kilobyte (KB) to 200 KB (typical) to 700 KB (very large application suites). Windows XP Professional advertises all assigned applications each time a user logs on. This does not generate network traffic, but it does require the client computer to process Windows Installer each time a user logs on. The first time that applications are assigned, the target must load and process the advertisement scripts for each new application. After this, each time the target user logs on, Windows Installer reprocesses the downloaded scripts for every assigned application to verify that these applications are properly configured. Typically, published applications do not affect user logon time. Therefore, it is not a problem to publish applications to a large number of users, regardless of whether they need the applications right away. The exception is when you publish an upgrade to an application that is already published or assigned. The operating system retrieves this publication data from Active Directory during the logon process. The effect this has on users is not as significant as the effect of assigning nonessential applications. It is best to assign only necessary software.

You can see the size of application management files by opening the applications folder or the scripts folder in Sysvol. These folders are located in the user folder or the computer folder of your domain controller. For example:

\\Server Name\Sysvol\Domain Name\Policies\GPO GUID\User\applications

-or-

\\Server Name\Sysvol\Domain Name\Policies\GPO GUID\Computer\Scripts

Caution

• Never edit or open the files in these Sysvol folders. Doing so can damage the application scripts and affect every client in the GPO. Always perform all necessary edits by using Group Policy Object Editor.
  

The way you use Group Policy to manage software depends on your network infrastructure, administrative hierarchy, and the business requirements of your organization. Many large organizations have a central IT administration that has delegated authorization. Others have either strictly centralized or decentralized IT groups. Regardless of how your IT administration is organized, you must communicate with software administrators at all levels of the domain hierarchy so that all software administrators know what software each other assigns, publishes, or removes at each level. The administrative tasks that other software administrators perform at other levels of the domain hierarchy can affect how you scale Group Policy to deploy and manage software at your level.

When you apply Group Policy settings high in the domain structure, you can reach more users than if you apply settings at a lower OU level. You also decrease application administration for the same application. You can filter user groups lower in the Active Directory hierarchy to avoid giving all users all the applications that you deploy by using Group Policy.

If an application is assigned at the domain level, all users in the domain receive that application. Administrators at the domain level manage applications that are deployed at that level. By managing applications at the domain level, you relieve administrators in the OU levels beneath it from having to manage them.

Figure 8.5 illustrates how you can assign software to users and computers by applying GPOs at the domain level, and how that software assignment is inherited by the associated OUs by default.

Figure 8.5   Assigning Application-Based GPOs at the Domain Level

Important

• Administrators cannot control installation order. Although the Group Policy user interface displays the list of applications alphabetically, installation order is based on the order in which the applications are added to the GPO. However, you can create launch conditions in the .msi package so that a particular software package is not installed until a condition is met. For example, you might specify that a dependent package is not installed unless the application it requires to operate correctly is installed.
  

While you are planning your Group Policy deployment to meet the needs of your users, note the needs of multinational users. Multinational corporations share information and collaborate on a worldwide basis. Before Windows 2000, the operating-system support and the files generated with an application in one language were not necessarily compatible with a file that was created by the same application in a different language. However, in Windows Server 2003, you no longer have to apply, track, and maintain a different service pack and tool and application set for each localized version. You can now assign or publish the same software to every user or computer in the company, regardless of location.

Table 8.4 shows the conditions that the software installation extension of Group Policy must verify to determine whether to install an application on a computer that runs Windows 2000 or a later version of the operating system.

Table 8.4   Application Installation Conditions to Verify