Group Policy

그룹 정책 성능 최적화

Darren Mar-Elia

한 눈에 보기:

• 모놀리식 GPO와 기능적 GPO
• 그룹 정책 항목 처리 방법
• GP 변경 시 나타나는 현상

"성능 측면에서 볼 때 적은 수의 큰 GPO를 사용하는 것과 여러 개의 작은 GPO를 사용하는 것 중 어떤 것이 유리합니까?"라는 질문을 자주 받습니다. 이 문서에서는 이 질문과 그룹 정책 디자인 및 성능과 관련한 여러 가지 내용들을 살펴보겠습니다. 대부분의 포괄적인 질문과 마찬가지로

이 질문에 대해서도 "상황에 따라 다릅니다."라고 답할 수밖에 없습니다. 회피성 답변처럼 보일 수 있지만 여기서의 제 목표는 초보 사용자나 수백 개의 GPO가 있는 환경을 최적화하려는 사용자 모두가 충분한 정보를 바탕으로 그룹 정책 설계에 대한 결정을 내릴 수 있도록 그룹 정책 처리의 기초가 되는 메커니즘을 설명하는 것입니다.

모놀리식 GPO와 기능적 GPO

우선 GPO를 구현할 수 있는 여러 가지 방법부터 살펴보겠습니다. "모놀리식"과 "기능적"이라는 용어는 설계 방식을 가리킵니다. 모놀리식 GPO에는 여러 영역의 설정이 포함됩니다. 예를 들어 모놀리식 GPO의 경우 관리 템플릿, Internet Explorer 유지 관리 및 소프트웨어 설치 정책의 설정이 모두 하나의 GPO에 포함될 수 있습니다. 이와 반대로 기능적 GPO는 일반적으로 한 가지 일만 수행합니다. 예를 들어 기능적 GPO는 소프트웨어를 설치하는 작업 또는 보안 설정을 적용하는 작업만 수행할 수 있습니다. 하나의 정책 설정만 들어 있는 기능적 GPO를 본 적도 있습니다. 하지만 이는 극단적인 경우입니다. 그림 1에서 각 방법의 장점과 단점을 일부 볼 수 있습니다.

Figure 1 모놀리식 GPO와 기능적 GPO 비교

여기서 볼 수 있듯이 모든 경우에 적합한 방법(모놀리식 또는 기능적)이 무엇인지에 대한 고정된 답은 존재하지 않습니다. 환경에 따라서는 두 가지 모두가 필요할 수도 있습니다. 예를 들어 전체 도메인에 대한 보안 정책을 작성할 때는 기능적 방법이 좋다고 판단할 수 있습니다. 보안 설정만 포함된 하나의 GPO가 있으면 해당 GPO의 제어를 보안 관리자에게 위임하고 다른 사람은 손대지 못하게 할 수 있습니다. 마찬가지로 GP 관리를 OU 관리자에게 위임하고 각 OU에 하나의 모놀리식 GPO를 설정하면 해당 관리자는 한 곳에서 자신의 모든 정책 설정을 관리할 수 있습니다. 이렇게 하면 관리의 복잡성이 줄어들고 특정 OU의 사용자 및 컴퓨터에 대해 작성되는 GPO의 수를 적절하게 조정할 수 있습니다.

그러면 이 높은 수준의 설계 결정 사항은 그룹 정책 처리의 성능에 어떤 영향을 주며 성능에 미치는 영향을 최소화할 수 있도록 GP 설계에 대해 현명한 의사 결정을 내리려면 어떻게 해야 할까요? 그룹 정책 인프라의 성능을 극대화하기 위한 첫 번째 단계는 그룹 정책 처리 방식을 구체적으로 이해하는 것입니다.

그룹 정책 처리 이해

그룹 정책 처리에는 Windows® 및 Active Directory® 인프라의 여러 부분이 관여하는 상호 작용이 복잡하게 얽혀 있습니다. 높은 수준에서 보면 그룹 정책 처리에는 두 가지 부분이 있습니다. 첫 번째는 핵심 또는 그룹 정책 인프라 처리입니다. 이 단계에서 Windows 그룹 정책 클라이언트는 가장 가까운 도메인 컨트롤러에 쿼리를 보내 DC에 대한 연결 속도, Active Directory 계층 구조에서의 위치(즉, 클라이언트가 속한 사이트, 도메인 및 OU) 및 컴퓨터 또는 현재 로그온한 사용자에게 적용되는 GPO를 확인합니다. (이 경우 클라이언트는 Active Directory 도메인에 참가하는 서버 또는 워크스테이션일 수 있음을 유의해야 합니다.) GPO의 목록이 작성되면 다음 단계는 CSE(클라이언트 쪽 확장) 처리입니다. CSE 단계에서는 등록된 각 CSE가 해당 영역에 설정이 구현된 GPO의 목록을 처리합니다. 예를 들어 레지스트리 또는 관리 템플릿 CSE가 모든 경우에 제일 먼저 실행되고 지정된 컴퓨터나 사용자에게 적용되며 그 안에서 레지스트리 정책이 구현된 모든 GPO를 처리합니다.

다음 목록에서는 클라이언트와 도메인 컨트롤러 간의 네트워크 상호 작용을 포함하여 그룹 정책 처리 주기가 진행되는 단계를 자세히 설명합니다. 그룹 정책은 컴퓨터와 사용자 모두에 적용된다는 점을 기억해야 합니다. 따라서 정책이 처리될 때마다(예: 그룹 정책을 백그라운드에서 새로 고치는 동안) 아래 열거한 주기가 컴퓨터와 해당 시스템에 현재 로그온한 사용자 계정 모두에 대해 반복됩니다. 이 두 가지에 적용되는 정책 집합이 서로 다를 수 있기 때문입니다. 이때 Windows에서는 컴퓨터와 사용자에 대해 동시에 처리 주기를 진행합니다. 각 주기는 그룹 정책 엔진 프로세스(Windows 2000, Windows XP 및 Windows Server® 2003에서는 Winlogon 프로세스, Windows Vista® 및 Windows Server 2008에서는 그룹 정책 클라이언트 서비스) 내의 서로 다른 스레드에서 실행됩니다.

GP 처리 절차는 다음 여섯 단계로 구성됩니다.

1. 클라이언트가 사이트의 도메인 컨트롤러에 대해 ICMP(Internet Control Message Protocol) 저속 연결 검색을 수행하여 연결 속도를 확인합니다. Windows Vista에서는 저속 연결 검색에 ICMP가 사용되지 않고 대신 NLA(네트워크 위치 인식) 서비스가 사용됩니다.
2. 클라이언트는 로컬 레지스트리에서 CSE 상태 정보를 읽어 어떤 GPO가 마지막으로 처리되었는지 확인합니다.
3. 클라이언트는 LDAP를 사용하여 Active Directory 계층 구조 내 각 위치의 컨테이너 개체에서 Active Directory의 gpLink 특성을 검색합니다. OU 수준(중첩된 모든 OU 포함), 도메인 수준, Active Directory 사이트 수준의 순으로 검색을 수행합니다. 이 검색 결과에 따라 처리를 위해 평가해야 하는 GPO의 목록을 작성합니다.
4. 그런 다음 Active Directory에서 각 GPO를 검색하여 클라이언트(사용자 또는 컴퓨터)에게 해당 GPO를 처리할 수 있는 권한이 있는지 확인합니다. 버전 번호, SYSVOL에서 GPO의 GPT(그룹 정책 템플릿) 위치 경로 및 해당 GPO에서 구현되는 CSE도 평가합니다.
5. 다음으로 클라이언트는 SMB(서버 메시지 블록) 프로토콜을 사용하여 GPT의 내용을 읽고 gpt.ini 파일에서 GPO의 버전 번호를 가져옵니다. GPC(그룹 정책 컨테이너) 및 GPT의 버전 번호는 마지막 처리 주기 이후 GPO가 변경되었는지 여부를 확인하는 데 사용되는 한 가지 요소입니다.
6. 각 CSE는 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions에 등록된 순서대로 실행되며 마지막 처리 주기 이후 GPO가 변경된 경우(핵심 처리 중에 확인됨)에는 해당 CSE를 구현하는 GPO를 처리합니다. 또한 가능한 경우 각 CSE는 새로 고칠 때마다 RSOP(Resultant Set of User Policy) 데이터를 WMI(Windows Management Instrumentation)에 기록합니다.

이 프로세스를 자세히 살펴보고 성능에 어떤 영향을 미칠 수 있는지 알아보겠습니다. 우선 포그라운드 처리와 백그라운드 처리 사이에는 차이가 있습니다. 포그라운드 처리는 시스템 재시작 도중 컴퓨터에 대해, 그리고 사용자 로그온 도중 사용자에 대해 수행됩니다. 백그라운드 새로 고침은 기본적으로 90분에 최대 30분의 임의의 값을 더한 시간마다 워크스테이션 및 구성원 서버에서 수행되고, 도메인 컨트롤러에서는 기본적으로 5분 간격으로 수행됩니다. Windows Vista에서는 NLA 기반 새로 고침도 있습니다. 이는 도메인 컨트롤러에 대한 액세스 권한이 부족하여 그룹 정책 처리가 실패한 경우(예: 백그라운드 간격 발생 시 클라이언트가 오프라인일 때) 트리거되는 백그라운드 새로 고침 이벤트입니다. 이러한 구분이 왜 중요할까요? 기본적으로 소프트웨어 설치 및 폴더 리디렉션 CSE와 같은 특정 CSE는 백그라운드 새로 고침 도중에 실행되지 않기 때문입니다. 마찬가지로 로그온/로그오프 또는 시작/종료 스크립트도 백그라운드 새로 고침 도중에는 실행되지 않습니다.

이 프로세스의 1단계에서 필자는 저속 연결 검색 프로세스를 언급했습니다. Windows Vista 이전 시스템에서 이 프로세스는 클라이언트를 통해 ICMP로 도메인 컨트롤러에 ping을 실행하여 가용성과 연결 속도를 확인합니다. 계산된 연결 속도가 특정 임계값(기본값 500Kb/s)보다 낮아지면 저속 연결로 간주되며 소프트웨어 설치, 폴더 리디렉션 및 Internet Explorer 유지 관리와 같은 특정 CSE는 실행되지 않습니다. 이러한 모든 조건은 정책 구현에 대한 예상과 성능에 영향을 미칠 수 있습니다.

성능에 가장 큰 영향을 주는 정책 처리 주기의 측면은 아마 컴퓨터나 사용자에 적용되는 GPO가 변경되었는지 여부를 확인하는 논리일 것입니다. 그룹 정책 엔진에는 GP를 마지막으로 처리한 이후 컴퓨터나 사용자에 변경 사항이 없음을 알리는 기본 제공 최적화 기능이 있으며 이 경우 처리가 수행되지 않습니다. 이러한 방식은 특히 GP 환경이 정적인 경우에는 클라이언트가 정책을 처리하는 데 걸리는 시간에 큰 영향을 줄 수 있습니다. 이제 변경의 요인에 대해 더 자세히 알아보겠습니다.

그룹 정책 변경이 수행되는 시기

그렇다면 그룹 정책 처리의 측면에서 변경을 가져오는 요인은 무엇일까요? 여러 가지 요인이 있지만 가장 확실한 것은 GPO를 변경하면 해당 GPO를 처리하는 클라이언트가 변경을 감지하고 GPO를 다시 처리한다는 점입니다. 그러면 클라이언트는 GPO가 변경된 것을 어떻게 감지할까요? 클라이언트는 GPO 및 클라이언트 내의 버전 번호를 이용하여 감지합니다.

GPO는 Active Directory에서 각 도메인 안의 CN=Policies, CN=System 컨테이너에 저장되는 GPC와 SYSVOL에서 "Policies" 폴더 안에 저장되는 GPT의 두 가지로 구성됩니다. GPO의 각 부분에는 버전 번호가 있습니다. GPC의 경우 이 버전 번호는 GPC 개체의 versionNumber 특성에 저장됩니다. GPT의 경우에는 특정 GPT의 루트에 있는 gpt.ini 파일 안에 저장됩니다. 클라이언트에서는 지금까지 처리한 GPO의 버전 번호 레코드를 사용자 및 컴퓨터별로 레지스트리에 유지합니다. 이 버전 정보는 컴퓨터의 경우 HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History에 저장되고 각 클라이언트의 사용자에 대해서는 HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID of User>에 저장됩니다.

그룹 정책을 처리할 때 컴퓨터 또는 사용자에게 해당되는 모든 GPO의 버전 번호를 검사하여 이를 레지스트리에서 발견된 마지막 주기 도중 처리된 모든 버전 번호와 비교합니다. 현재 GPO의 버전 번호가 다른 경우에는(크거나 작은 경우 모두 포함) 현재 처리 주기 도중 해당 GPO가 처리됩니다. 버전 번호가 같은 경우에는 다른 변경 조건 중 하나가 일치할 때만 처리됩니다. 다른 변경 조건은 다음과 같습니다.

• 사용자 또는 컴퓨터에 적용되는 GPO 목록의 변경(GPO 추가 또는 제거)
• 사용자 또는 컴퓨터의 보안 그룹 구성원의 변경
• GPO에 연결된 WMI 필터의 변경(WMI 필터 추가 또는 제거)

변경 조건 중 일치하는 것이 있으면 클라이언트는 주기 도중 정책을 다시 처리합니다. 하지만 성능에 큰 영향을 줄 수 있으므로 이 프로세스의 세부적인 면을 알아두어야 합니다. 특정 CSE에서 10개 중 1개의 GPO가 변경되었으면 해당 CSE에 대한 모든 GPO를 다시 처리해야 합니다. 처리는 CSE 단위로 수행되기 때문입니다. 하지만 CSE에서는 처리를 제어하는 우선 순위에 따라 정책을 처리해야 합니다. 즉, 로컬 GPO, 사이트에 연결된 GPO, 도메인에 연결된 GPO, OU에 연결된 GPO의 순서로 처리해야 합니다. 이 요구 사항을 감안하여 사용자에게 적용되는 GPO가 10개 있으며 각각 Active Directory 계층 구조의 서로 다른 수준에 연결되어 있다고 가정하겠습니다. 그리고 이 10개의 GPO 각각에서 관리 템플릿 정책 설정 몇 가지를 구현합니다. 이제 관리자가 새 관리 템플릿 정책 설정을 추가하여 도메인에 연결된 GPO를 변경합니다. 그러면 컴퓨터 또는 사용자는 정책을 처리할 때 변경된 GPO의 버전 번호가 마지막으로 처리된 버전 번호보다 크며 따라서 GPO를 다시 처리해야 한다는 것을 감지하게 됩니다. 하지만 GP 처리의 우선 순위를 유지하기 위해 모든 GPO에 적용되는 모든 관리 템플릿 설정을 처리해야 합니다. 따라서 하나의 GPO가 조금 변경되더라도 해당 클라이언트의 성능에 큰 영향을 미칠 수 있습니다.

모놀리식 GPO와 기능적 GPO의 성능 비교

처리 주기와 그룹 정책 환경에 대한 변경이 처리에 어떤 영향을 주는지 살펴보았으므로, 모놀리식 GPO와 기능적 GPO의 비교라는 주제로 돌아가서 각 방법이 성능에 어떤 영향을 주는지 알아보겠습니다.

그룹 정책 버전 관리의 작동 방식 때문에 모놀리식 GPO에는 잘 드러나지 않는 성능 저하 가능성이 있습니다. 그 이유가 명백한 것은 아니지만 그룹 정책 처리 안에 CSE별 버전 관리에 대한 개념이 없다는 사실을 짚고 넘어가야 합니다. 특정 사용자에게 적용되는 세 개의 GPO가 있다고 가정하겠습니다. 각 GPO에서 몇 가지 정책 영역을 구현한다는 점에서 모놀리식 GPO입니다. 예를 들어 각 GPO가 관리 템플릿 정책, 소프트웨어 설치 정책 및 폴더 리디렉션 정책을 구현한다고 가정해 보겠습니다. 이제 관리자가 이 GPO 중 하나에서 관리 템플릿 정책을 변경한 경우를 예로 들겠습니다. 이 변경으로 인해 버전 번호가 증가합니다. 그런 다음 사용자가 그룹 정책을 처리합니다. 관리 템플릿 CSE가 시작되고 GPO 중 하나가 변경되었음을 발견하여 이 세 GPO를 다시 처리합니다.

소프트웨어 설치 및 폴더 리디렉션 CSE가 실행될 때는 GPO 버전 번호도 확인하여 GPO 중 하나에 새 버전 번호가 있음을 인식합니다. 하지만 버전 번호로는 해당 GPO에서 어떤 정책 영역이 변경되었는지 알 수 없으므로 만약을 위해 세 GPO를 모두 처리합니다. 즉, 모놀리식 GPO 구현에서는 정책의 영역 중 하나를 변경하면 다른 영역에서 처리 작업이 수행될 수 있습니다.

소프트웨어 설치 또는 폴더 리디렉션 정책의 경우 해당 CSE는 실제로 어떠한 작업도 수행하지 않을 수 있습니다. 예를 들어 응용 프로그램을 한번 설치한 경우에는 다시 설치하지 않을 것이기 때문입니다. 하지만 중요한 점은 이 동작이 모든 CSE에 대해 수행될 수 있으므로 모놀리식 GPO를 설계할 때 이를 고려해야 한다는 점입니다. 자주 변경되는 정책 영역이 있을 때는 해당 정책 영역을 다른 정책 영역과 분리하여 구현하는 GPO를 사용하는 방법을 고려할 수 있습니다.

기능적 GPO의 관점에서 보면 성능 고려 사항은 더 명확합니다. 기능적 방법을 사용하는 경우 대개 특정 정책 설정에 대한 GPO가 더 많아지기 때문에 사용자 또는 컴퓨터별로 더 많은 GPO가 생성되며 이는 그룹 정책 엔진이 그룹 정책 처리의 핵심 단계 중에 해당 GPO를 열거할 때 시간이 더 많이 걸린다는 것을 의미합니다. 하지만 다음 섹션에서 설명하듯이 성능에 반드시 큰 영향을 미치는 것만은 아닙니다.

그룹 정책 성능 측정

결론적으로 그룹 정책 인프라의 성능과 관련하여 현명한 결정을 내리기 위해서는 그룹 정책이 실제 환경에서 수행될 때의 성능을 측정할 수 있어야 합니다. 처리 주기에 영향을 줄 수 있는 많은 요소들을 고려하면 그룹 정책 성능의 모델링이나 예측은 거의 불가능합니다. 이런 이유 때문에 GP 처리 성능이 문제가 되는지 파악할 때는 경험적 측정이 최선의 방법일 수 있습니다. 성능 저하의 요인은 무엇일까요? 성능 저하는 그룹 정책 처리가 사용자의 시스템 사용에 영향을 주는 모든 상황입니다. 이런 상황은 조직마다 다를 수 있지만 중요한 것은 문제가 있다는 것을 파악하는 것입니다.

그렇다면 특정 그룹 정책 처리 주기의 길이는 어떻게 측정할까요? 이 질문에 대한 답변 역시 간단하지 않습니다. Windows Vista 또는 Windows Server 2008을 사용 중이라면 이벤트 뷰어 작동 로그를 이용할 수 있습니다. 이벤트 뷰어의 응용 프로그램 및 서비스 로그\Microsoft\Windows\Group Policy\Operational에서 찾을 수 있는 그룹 정책 작동 로그를 통해 처리의 각 단계에 걸린 시간을 포함하여 그룹 정책 처리 주기의 각 단계를 측정할 수 있습니다(그림 2 참조).

그림 2** 정책 처리 시간을 보여 주는 그룹 정책 작동 로그 **(더 크게 보려면 이미지를 클릭하십시오.)

하지만 Windows Vista 또는 Windows Server 2008 환경이 아니라면 정책 처리 시간을 측정하는 메커니즘은 더 간접적인 메커니즘입니다. 이 경우에는 userenv 상세 로깅( support.microsoft.com/kb/221833에서 Microsoft 지원 문서 참조)이 사용되도록 설정하고 파일에서 특정 처리 주기에 대한 타임스탬프를 확인하거나, 클라이언트에서 정책 처리의 시작 및 중지 시간을 나타내는 레지스트리 값을 사용할 수 있습니다. 이 값은 컴퓨터의 경우 다음 위치에 저장됩니다.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}

사용자의 경우에는 다음 위치에 저장됩니다.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}

값은 FILETIME 형식으로 저장되며 일반 날짜 및 시간으로 변환해야 합니다. 또한 필자가 만든 무료 유틸리티인 GPTime.exe(gpoguy.com/tools.htm#GP_Time_Utility에서 다운로드 가능)를 사용해도 같은 정보를 얻을 수 있습니다.

Windows Vista 또는 Windows Server 2008을 사용하지 않는 경우 userenv 로그에 액세스하여 각 정책 처리 주기에 걸린 시간에 대한 귀중한 정보를 얻을 수 있습니다. 예를 들어 그림 3에서는 그룹 정책 처리의 핵심 단계 중 일부를 보여 주는 userenv 로그 일부를 볼 수 있습니다.

그림 3** userenv 로그의 일부분 **(더 크게 보려면 이미지를 클릭하십시오.)

로그 파일의 각 줄에 타임스탬프가 포함되어 있는 것을 볼 수 있습니다. 그룹 정책 처리 주기의 핵심 부분은 "ProcessGPOs: Starting user Group Policy (Background) processing..."과 같은 내용이 표시되는 이벤트가 발생할 때 시작됩니다. 처리 주기의 CSE 부분은 "ProcessGPOs: Processing extension Registry."라는 줄이 보이는 시점에서 시작됩니다. 이 로그와 로그 안의 타임스탬프를 사용하여 정책 주기의 각 부분에 걸린 시간을 확인할 수 있습니다.

성능에 대한 전체적인 관찰

userenv 로그 파일을 충분히 살펴보았으면 패턴을 찾아보기 시작합니다. 정책 처리에 소요되는 시간을 예측할 수는 없지만 특정 처리 주기에서 시간이 걸린 부분에 대한 관찰을 시작할 수는 있습니다. 예를 들어 정책 처리 이벤트 도중 정책 변경이 처리되고 변경 때문에 CSE가 작업을 해야 하는 경우에는 GP 처리의 핵심 부분에 걸리는 시간은 일반적으로 CSE 부분에 비하면 훨씬 짧습니다.

대부분의 CSE는 처리의 핵심 부분보다 오래 실행되는 작업을 수행해야 하기 때문에 대부분의 정책 영역에서도 마찬가지입니다. 여기서 가장 많은 비용이 드는 작업은 Active Directory 및 SYSVOL에 대한 쿼리입니다. 예를 들어 핵심 처리에 걸리는 시간과 Microsoft® Office 설치를 실행하는 소프트웨어 설치 CSE에 드는 시간은 비교할 수 없을 정도입니다. 하지만 마지막 주기 이후 아무것도 변경되지 않은 정책의 일반적인 백그라운드 새로 고침의 경우 처리 주기의 핵심 부분에 걸리는 시간은 CSE 부분에 걸리는 시간과 거의 같습니다. 한 가지 예외는 레지스트리 정책 처리입니다. 특정 사용자 또는 컴퓨터에 대한 수십 또는 수백 개의 레지스트리 정책 설정이 있는 경우가 아니라면 이 처리는 속도가 꽤 빠릅니다.

또한 사용되지 않기 때문에 GPO의 컴퓨터 쪽 또는 사용자 쪽이 사용되지 않게 지정하더라도 정책 처리 성능에는 거의 영향을 미치지 않습니다. 정책 쪽이 사용되지 않는 경우 유일한 오버헤드는 이를 확인하기 위해 Active Directory를 쿼리하는 것이며, GPO의 해당 측면에 대해 CSE가 구현되었는지 여부를 확인하기 위한 쿼리와 동일한 쿼리를 수행해야 해제 옵션을 볼 수 있습니다. 어느 한 쪽을 해제하는 효과는 무시해도 좋을 정도입니다.

최적의 GP 성능을 위한 설계 제안

그룹 정책 처리 성능의 여러 측면을 살펴보았으므로 이제 성능에 직접 영향을 줄 수 있는 몇 가지 설계 권장 사항을 소개하겠습니다. 이는 다음 네 가지 핵심 사항으로 요약됩니다.

1. GPO를 자주 변경할 때는 한 CSE에 대한 변경이 모든 CSE의 처리에 영향을 줄 수 있다는 점을 염두에 두십시오. 예를 들어 레지스트리 정책을 자주 변경할 계획인 경우, 변경 발생 시 다른 CSE도 처리되지 않도록 레지스트리 정책을 기능적 GPO(레지스트리 정책만 수행하는 GPO)에 넣는 것이 좋습니다.
2. 몇 개의 GPO가 많다고 판단할 것인지 결정할 때는 정책 처리가 변경 도중에만 수행되며, 소프트웨어 설치, 폴더 리디렉션 또는 많은 레지스트리 정책이나 큰 파일 또는 레지스트리 트리에서 권한 설정과 같은 "고비용" CSE에 대부분의 시간이 소요된다는 것을 염두에 두십시오. 핵심 처리 도중 Active Directory에 GPO 목록을 쿼리하는 데 걸리는 시간은 처리 주기 중 가장 작은 부분일 경우가 많습니다. 따라서 특정 사용자에게 30개의 GPO가 적용되지만 레지스트리 정책을 자주 변경하지 않는 경우의 처리 시간은 정기적으로 고비용 CSE를 실행하는 5개의 GPO 처리 시간보다 짧습니다. 이러한 GPO는 자주 변경되기 때문입니다.
3. 정책 처리 성능을 확실하게 저하시키는 동작은 피하는 것이 좋습니다. 예를 들어 GPO가 변경되지 않았더라도(컴퓨터 구성\관리 템플릿\시스템\그룹 정책 아래) CSE를 강제 처리하도록 정책을 설정할 수 있습니다. 하지만 이렇게 하면 각 주기 도중 예상 정책 처리 시간이 더 길어집니다.
4. Windows XP 및 Windows Vista에서 빠른 로그온 최적화를 사용 중지할 때의(컴퓨터 구성\관리 템플릿\시스템\로그온\컴퓨터 시작 및 로그온 시 네트워크가 초기화될 때까지 항상 대기에서 정책을 사용으로 지정하여) 장단점을 잘 고려하십시오. 이 정책이 사용되도록 설정하면 포그라운드 처리가 비동기에서 동기 방식으로 전환됩니다. 즉, 사용자가 컴퓨터 및 데스크톱의 제어권을 가져오기 전에 컴퓨터와 사용자 정책의 실행이 완료되어야 한다는 것을 의미합니다. 하지만 소프트웨어 설치 및 폴더 리디렉션 정책이 적용되기 위해서는 두 번 이상의 다시 시작 또는 로그온을 요구하는 문제가 해결되기 때문에 유용할 수도 있습니다.

요약

그룹 정책 처리 성능을 정확하게 측정할 수는 없지만 몇 가지 조사를 통해 성능 문제를 완화시킬 수 있는 대안을 설계 프로세스에 도입할 수 있습니다.

처리 주기가 작동하는 방식과 시간이 많이 소요되는 부분을 이해하면 성능 문제 추적의 긴 여정을 시작할 수 있습니다. Windows Vista 또는 Windows Server 2008 작동 로그(이전 버전의 Windows에서는 userenv 로그)를 사용하여 처리 주기에 대한 측정 정보를 얻을 수 있습니다. CSE 처리의 다양한 특성과 CSE 관점에서 볼 때 정책의 변경 요인을 염두에 두십시오. 또한 변경이 많은 동적 환경에서는 모놀리식 GPO보다는 기능적 GPO가 적합하다는 점을 기억하십시오. 하지만 근본적으로는 그룹 정책은 Windows 환경을 더 쉽게 관리할 수 있도록 돕기 위해 설계된 기술입니다. 따라서 그 무엇보다도 비즈니스 요구 사항을 염두에 두고 그룹 정책을 설계해야 한다는 점을 유념해야 합니다. 여기서 언급한 몇 가지 성능 동작을 알아두면 이러한 목표를 달성하는 데 도움이 될 것입니다.

Darren Mar-Elia는 Microsoft 그룹 정책 MVP이며 유명한 그룹 정책 사이트인 www.gpoguy.com의 제작자이자 Microsoft Windows Group Policy Guide(Microsoft Press, 2005년)의 공동 저자이기도 합니다. 또한 SDM Software, Inc.의 CTO이자 설립자입니다. 문의 사항이 있으면 Darren@gpoguy.com으로 연락하십시오.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..