2.3 Understanding Common GPA Setup Scenarios

A minimum GPA installation requires a GP Repository, a GPA Server, and at least one GPA Console. You must also install a GPA Console in each untrusted domain if you want to manage GPOs in untrusted domains.

Your GPA installation depends on your environment and your GPO change management and security requirements. For more information about GPA components and how they work in relation to your Active Directory environment, see Section 1.2, How GPA Works.

2.3.1 Determining Which GPA Components to Install

You can install GPA components on one computer or on several computers. The primary factors affecting your decision are:

  • Your network environment

  • Whether you are managing GPOs in both trusted and untrusted domains

For more information about how GPA works with your network environment, see Section 1.2, How GPA Works.

The simplest approach is to install all GPA components on one computer, the typical method if you are installing a trial installation. For a production installation, however, installing all GPA components on one computer has limitations and may not adapt well to your actual environment. For production installations, consider installing the GPA components on separate computers.

For example, the GP Repository uses Microsoft SQL Server. Your company may install SQL Server on dedicated server‑class computers and manage these computers with designated SQL Server database administrators. In this case, you may need a SQL Server database administrator to install the GP Repository on one of these computers. You would then use a GPA Console from another computer on the network to connect to the GP Repository.

You must install the GPA Server in a trusted domain of the domain where you install the GP Repository. If you maintain multiple GP Repositories, each GP Repository requires a separate installation of the GPA Server.

If you are managing GPOs in untrusted domains, you must install at least one GPA Console in each untrusted domain. Depending on the number and location of GPA users, you may need to install several GPA Consoles in multiple domains.

2.3.2 Understanding Test Environment Configurations

The GPA architecture provides you with tremendous flexibility in configuration options. The following sections describe common installation scenarios to help you determine the configuration that best suits your environment and GPO management and security requirements.

Configuring Untrusted Test Environments

An untrusted test environment configuration includes your production environment and an untrusted test environment. The test environment, untrusted by the production environment, allows you to work with GPOs before you deploy them to the production environment.

Verifying GPO changes in an untrusted test environment configuration minimizes the number of issues you may face in your production Active Directory environment. For example, users in the test environment cannot accidentally implement GPO changes made in the test environment to GPOs in the production environment using native GPO tools such as GPMC or GPEdit. These tools cannot work with GPOs in untrusted environments.

Although GPA can work with GPOs in untrusted Active Directory environments, setting up an untrusted test Active Directory environment also reduces the risk of making unauthorized changes to GPOs using GPA. A user account must have GPO Creator Owner permissions to modify GPOs. A user account in an untrusted test Active Directory environment is very unlikely to know user account credentials in the production Active Directory environment with these permissions. Test environments and users are purposely isolated from production environments to ensure that no changes made in the test environment can be made in the production environment. For more information about production and test environments, see Section 2.3.2, Understanding Test Environment Configurations.

A typical GPA untrusted test environment configuration includes the GP Repository, a GPA Server, and at least one GPA Console installed in the untrusted test environment. Install another GPA Console in the production environment.

Use the GPA Console in the production environment to import GPOs into the GP Repository. Use the GPA Console in the untrusted test environment to check in, check out, and edit GPOs in the test environment.

NOTE:

  • In an untrusted test environment configuration, you must use a GPA Console in the production environment to import GPOs into the GP Repository. The GPA Console cannot import required information about GPOs, such as any links to Active Directory objects or security filters, from a GPO in an untrusted environment.

  • In an untrusted test environment configuration, you must use a GPA Console in the untrusted test environment where you installed the GP Repository to check out and edit GPOs. The GPA Console uses native Microsoft interfaces to edit GPOs, and these interfaces do not allow the editing of GPOs from untrusted domains.

Use the GPA Server to export GPOs from the GP Repository to the untrusted production environment. This method is the most reliable and secure way to perform a GPO export into an untrusted environment. You can export GPOs from the GP Repository using a GPA Console in either the production or test environment. For more information about using the GPA Server to export GPOs, see Section 2.3, Understanding Common GPA Setup Scenarios.

The following figure shows a basic GPA workflow in an untrusted test environment configuration, including the GPA components used in each step. Domain B represents an untrusted domain in the test environment. Domain A represents an untrusted domain in the production environment.

A high‑level GPO change management workflow using GPA in an untrusted test configuration includes the following steps, which correspond to the numbers in the preceding illustration:

  1. Import GPOs from your production Active Directory environment into the GP Repository using a GPA Console in production domain A.

  2. Check out a GPO, locking it from changes by other users, using a GPA Console in test domain B.

  3. Edit the GPO as needed.

  4. Check in the updated GPO, unlocking the GPO and updating the version number of the GPO.

  5. Analyze the GPO to verify your changes (for example, RSoP analysis), and then approve the GPO.

  6. Migrate the approved GPO to test domain B in the GP Repository.

  7. Export the approved GPO into test domain B in Active Directory.

  8. Analyze the GPO to verify your changes (for example, RSoP analysis or diagnostic reports).

  9. Export the GPO to the Active Directory production domain A using the GPA Server and the Export Only service account for domain A.

Configuring Trusted Test Environments

A simple GPA configuration includes your production environment and a test environment that is trusted by the production environment. This configuration includes a GP Repository and a GPA Console installed in the test environment. This configuration is simpler than an untrusted test environment for the following reasons:

  • You do not need a GPA Console in the production environment to import GPOs into the GP Repository

  • You can perform all GPA operations from a single GPA Console

  • You do not need to use the GPA Server and an Export Only account to export GPOs from the GP Repository into the production environment.

This configuration requires fewer GPA components and allows you to perform all operations, including importing GPOs, from a single GPA Console. However, since the production and test domains are trusted, there is a much higher risk that GPO changes you make in your test environment could also be made in your production environment accidentally. Users in the test environment have credentials that are also trusted by the production environment, so it is much easier for a test environment user to make unintentional changes to GPOs in the production environment.

The following figure shows a basic GPA workflow in a trusted test environment configuration, including the GPA components used in each step. Domain B represents a trusted domain in the test environment. Domain A represents a trusted domain in the production environment.

A high‑level GPO change management workflow using GPA in a trusted test configuration includes the following steps, which correspond to the numbers in the preceding illustration:

  1. Import GPOs from your production Active Directory environment into the GP Repository using the GPA Console in production domain A.

  2. Check out a GPO, locking it from changes by other users, using a GPA Console in test domain B.

  3. Edit the GPO as needed.

  4. Check in the updated GPO, unlocking the GPO and updating the version number of the GPO.

  5. Analyze the GPO to verify your changes (for example, RSoP analysis), and then approve the GPO.

  6. Migrate the approved GPO to test domain B in the GP Repository.

  7. Export the approved GPO into test domain B in Active Directory.

  8. Analyze the GPO to verify your changes (for example, RSoP analysis or diagnostic reports).

  9. Export the GPO to the Active Directory production domain A using the GPA Console in test domain B.

    NOTE:You can install the GPA Server in the test environment and use an Export Only account to export GPOs to your production environment. This modified configuration allows only the Export Only account to make these GPO changes, and enforces a higher degree of security and control over changes to GPOs in the trusted test environment.