Windows Administration

사용 가능한 OU 구조 설계

Ken St. Cyr

한 눈에 보기:

• 훌륭한 OU 설계의 주요 원칙
• 일반적인 OU 설계 모델
• OU 설계 문서화

올바른 OU(조직 구성 단위) 구조 설계의 중요성과 복잡성을 과소 평가하지 마십시오. IT 부서에서는 간혹 극단적인 방향으로 결정을 내리기도 합니다.

즉, OU 구조에 너무 많은 의미를 부여하거나 그 중요성을 간과합니다. 어느 쪽이건 Active Directory® 모델에 문제를 유발할 수 있습니다.

OU 구조에 너무 신경 쓰면 사이트 토폴로지 계획이나 도메인 컨트롤러 크기 지정과 같은 Active Directory 설계의 다른 영역을 간과할 수 있습니다. 반대로 OU 계획을 미루다 보면 그룹 정책 및 위임에 소홀할 수 있습니다.

이렇게 문제를 방치하는 사람들은 OU 구조는 유연하므로 나중에 변경할 수 있다는 변명을 늘어놓곤 합니다. OU 구조가 유연한 것은 사실이지만 관리자의 입장에서는 OU 구조를 중간에 변경하는 작업이 처음 예상했던 것보다 더 힘들 수 있습니다. 물론 새 OU를 추가할 수 있지만 기존 OU를 정리하기는 어렵습니다.

처음에 OU 구조를 잘못 계획하면 끝까지 나쁜 영향을 미칩니다. 디렉터리에 새 개체가 만들어졌는데 관리자가 개체를 배치할 OU 구조를 잘 모르면 새 OU를 다시 만들거나 적합하지 않은 위치에 개체를 배치하게 됩니다. 두 가지 경우 모두 위험이 따릅니다. 새 OU를 만드는 것은 쉽지만 장기적으로 추적하는 데 어려움이 있습니다. OU를 무분별하게 만들면 OU 구조가 복잡해지고 디렉터리가 문서화되지 않은 상태가 되기 쉽습니다. 반대로 적합하지 않은 기존 OU에 개체를 추가하면 새 개체에 해당하지 않는 정책이 적용되거나 개체에 대한 사용 권한이 의도하지 않은 사용자에게 위임될 수 있습니다.

OU 구조를 설계할 때 염두에 두어야 하는 기본 공식은 "단순성 + 적응성 = 지속 가능성"입니다. 설계가 너무 단순하면 적응성이 떨어지므로 자주 변경해야 할 수 있고, 적응성에 너무 많이 초점을 맞추다 보면 모든 것이 세분화되므로 너무 복잡해질 수 있습니다.

설계를 결정하는 데 도움이 되는 세 가지 주요 원칙에는 그룹 정책, 위임 및 개체 관리가 있습니다. 이러한 원칙에 대해 세 가지 질문을 던져 만들고 있는 OU 구조가 오래 지속되고 조직의 변화에 적응할 수 있는지 확인할 수 있습니다.

1. 고유한 GPO(그룹 정책 개체)를 적용할 수 있도록 이 OU를 만들어야 합니까?
2. 특정 그룹의 관리자가 이 OU의 개체에 대한 사용 권한을 가져야 합니까?
3. 이 새로운 OU를 사용하면 포함된 개체를 관리하기가 쉬워집니까?

모든 질문에 대한 대답이 "예"라면 OU를 만들 이유가 충분히 있습니다. 하나라도 "아니요"라는 대답이 있으면 레이아웃을 다시 검토해 보고 다른 설계가 더 적합하지 않은지 확인해야 합니다. 이 문제에 대해 깊이 논의하고 이러한 원칙을 적용하는 방법을 시연하기 전에 우선 이러한 원칙이 왜 중요한지부터 설명하겠습니다.

원칙 1: 그룹 정책

OU 설계의 첫 번째 원칙은 OU에 적용할 그룹 정책 개체를 고려하는 것입니다. GPO를 사용하면 사용자 및 컴퓨터에 대한 설정을 강제적인 방식으로 구성할 수 있습니다. Active Directory에서 여러 GPO를 정의한 후 전체 도메인, 여러 OU 또는 도메인의 사이트에 적용할 수 있습니다. GPO는 사용자용과 컴퓨터용의 두 가지 범주로 나뉩니다.

컴퓨터 정책과 사용자 정책을 모두 같은 GPO에 정의할 수 있습니다. GPO의 사용자 구성 섹션에서는 대부분 사용자가 로그인할 때 표시되는 환경을 정의합니다. 이러한 유형의 설정은 컴퓨터 구성 섹션에도 있지만 이 섹션에는 컴퓨터에 로컬로 로그온할 수 있는 사용자 또는 데이터 암호화 방법과 같은 컴퓨터 보안 관련 설정이 추가적으로 포함되어 있습니다.

GPO를 지원하는 OU를 정의할 때 고려해야 할 기본 사항은 다음과 같습니다. 첫 번째로, 사용자 정책과 컴퓨터 정책을 모두 같은 GPO에 정의할 수 있다는 이유만으로 사용자 개체와 컴퓨터 개체를 같은 OU에 배치하는 것은 그다지 좋지 않습니다. 같은 GPO에 결합하면 GPO 적용 문제를 해결하는 데 어려움이 따릅니다. 루프백 정책이 설정된 경우에는 문제 해결이 특히 어렵습니다.

두 번째로, 많은 사람들이 사이트 수준에서 GPO를 적용할 수 있다는 사실을 잊고 GPO 용도로 사이트 구조를 모델링하는 데 OU 구조를 설계한다는 점입니다. 이것은 지리적 모델로 알려진 OU 설계의 일반적인 모델입니다. 이 모델에 대해서는 이후에 좀 더 설명하도록 하겠습니다. OU 설계에 지리적 모델이 사용된다는 사실은 잠시 잊고, 나중에 설명하겠지만 GPO 적용이 이 모델 구현의 결정적인 이유가 되어서는 안 된다고 생각합니다.

또한 GPO의 관점에서 OU 구조를 생각해 보면 복잡성을 줄이는 것이 목표일 것입니다. OU를 GPO 상속의 흐름에 추가하십시오. OU에 다른 서버와 같은 정책을 필요로 하는 서버가 포함되어 있으면 이러한 컴퓨터 개체를 보다 광범위한 Servers OU에 배치하고 Servers OU 아래에 서로 다른 서버 유형에 대한 여러 OU를 만드는 방법도 고려해 보십시오(그림 1 참조). 이렇게 하면 하위 OU의 각 컴퓨터 개체가 Servers OU의 정책 및 해당 특정 서버 유형과 관련된 다른 정책을 가져오므로 정책 적용이 간단해질 수 있습니다.

그림 1** 서로 다른 서버 유형에 대한 여러 OU 만들기 **(더 크게 보려면 이미지를 클릭하십시오.)

다른 기본 사항은 여러 GPO를 불필요하게 만들거나 연결하지 않는 것입니다. GPO를 사용하면 하나의 정책을 만들어 여러 OU에 적용할 수 있습니다. 이 방식은 유용할 때도 있지만 악영향을 미칠 수도 있습니다. GPO 설정을 변경해야 하는데 연결된 GPO 시스템이 너무 복잡하면 변경 내용을 실수로 잘못된 개체에 적용할 수 있습니다. 링크를 많이 만들수록 정책 범위를 가늠하기 어려워집니다. 마찬가지로 다른 정책과 같은 설정으로 추가 정책을 만들지 말아야 합니다. 이러한 상황이 발생하면 OU 구조를 수정하여 새 GPO 상속 모델을 적용하는 것이 좋습니다.

마지막으로, 사용자 개체 및 컴퓨터 개체에 대해 거의 항상 새 OU를 만들어야 합니다. 기본적으로 사용자 개체와 컴퓨터 개체는 컨테이너 안에 위치하므로 GPO를 직접 연결할 수 없습니다. GPO를 도메인의 사용자 및 컴퓨터 컨테이너에 적용할 수 있지만 상속을 차단하지 않으면 도메인에 있는 모든 사용자 및 컴퓨터에 이러한 정책이 적용됩니다. Windows Server® 2003에서는 rediruser.exe 및 redircomp.exe 도구를 사용하여 사용자 개체와 컴퓨터 개체의 기본 위치를 사용자가 만든 OU로 변경할 수 있습니다.

원칙 2: 위임

도메인에서 사용 권한이 위임된 방식과 일관되게 OU 구조를 만들어야 합니다. Active Directory에서 사용 권한이 위임되는 경우에는 사용 권한에 대한 변경이 개체에만 적용됩니다. 따라서 사용자에게 특정 컴퓨터 개체에 대한 모든 권한을 부여하면 해당 사용자는 개체의 특성을 수정할 수 있지만 컴퓨터 자체에 대해서는 관리자 권한이 없습니다.

OU 구조를 설계할 때 유용한 위임 관련 권장 방법을 몇 가지 소개하겠습니다.

사용 권한 상속을 고려하여 설계 예를 들어 계층 1 관리자에게 대부분의 계정에 대한 암호를 변경할 수 있는 권한을 부여하려는 경우, 관리자가 암호를 다시 설정할 수 있는 권한을 가지면 안 되는 특수한 사용자 그룹이 있지만 이러한 관리자에게 해당 계정에 대한 표시 이름을 변경할 수 있는 권한이 필요할 수 있습니다.

두 가지 옵션 중 하나를 선택할 수 있습니다. 첫 번째 옵션은 별개의 두 병렬 OU를 만들고 일반 사용자와 특수 사용자를 구분하는 것입니다. 그러나 이렇게 하면 모든 사용자에 대한 위임 옵션을 변경하려는 경우 두 위치에서 이러한 사용 권한을 변경해야 합니다. 또한 이 옵션은 불필요한 여러 개의 연결을 사용하지 않아야 한다는 정책과 모순될 수 있습니다(그림 2 참조).

그림 2** 별개의 두 병렬 OU 유지 관리 **(더 크게 보려면 이미지를 클릭하십시오.)

또 다른 옵션은 중첩 OU를 만들고 특수 사용자가 포함된 OU에 명시적인 거부 권한을 설정하는 것입니다. 모든 위임 전문가가 명시적인 거부는 사용하지 않는 것이 좋다고 말하겠지만 이 경우에는 최악의 조건 둘 중에서 하나를 선택해야 합니다(그림 3 참조). 별개의 두 OU에 대해 설정을 복제하고 유지 관리하거나 OU 중 하나에 명시적인 거부를 설정할 수 있습니다. 장기적인 안목에서 볼 때는 명시적인 거부를 사용하는 것이 좋습니다.

그림 3** 명시적인 거부 권한 사용 **(더 크게 보려면 이미지를 클릭하십시오.)

AdminSDHolder에 주의 이 예제는 특수 사용자가 모두 관리 그룹(Domain Admins, Schema Admins, Enterprise Admins 또는 Administrators) 중 하나에 속하지 않는 경우 더욱 잘 작동합니다. 이러한 그룹의 계정에 대한 사용 권한은 다루기 어렵기 때문입니다. 이 예제의 목적은 일반 사용자의 사용 권한을 실수로 관리 계정으로 부여하지 않기 위함입니다.

관리자용으로 별개의 OU를 만들면 여기에 위임하는 사용 권한이 보이지 않게 됩니다. 그 이유는 AdminSDHolder 때문입니다. AdminSDHolder는 지정된 간격으로 해당 액세스 제어 목록을 모든 관리자 계정에 적용하는 특수 컨테이너입니다. 따라서 관리 계정에 대한 위임이 변경된 후 AdminSDHolder 컨테이너에서도 변경되지 않으면 변경 내용이 되돌려집니다. 따라서 관리자 계정을 위임에 사용되는 다른 계정과 분리해 놓지 말아야 합니다. 하지만 그룹 정책에 사용되는 관리자 계정과는 분리해 놓는 것이 좋습니다. 이는 여러 암호 정책을 사용할 수 있는 Windows Server 2008에서 특히 유용합니다.

원칙 3: 개체 관리

OU에서 개체 관리를 활용해야 합니다. 개체를 같은 OU에 그룹화하면 일괄 변경을 수행하기 쉽습니다. Active Directory 사용자 및 컴퓨터 스냅인을 통해 여러 개체를 선택하여 특정 특성을 편집할 수 있습니다. 따라서 개체 그룹에 대해 정기적으로 특성을 변경해야 하는 경우 이러한 개체 그룹이 같은 OU에 있으면 작업하기 쉬워집니다.

또한 스크립트를 사용하여 업데이트하는 경우에도 특히 유용합니다. 스크립팅 언어를 사용하면 하나의 OU에 있는 모든 개체를 열거하고 이러한 개체를 하나씩 처리하기가 매우 쉬워집니다. 각 개체를 하나씩 검색하고 수정하는 방법도 있습니다. 관리하기 쉽도록 같은 OU에 개체를 배치하기만 하면 매주 불필요한 작업을 수행하는 시간을 절약할 수 있습니다.

개체 관리에 유용한 다른 방법으로는 형식에 따라 다른 OU에 개체를 분리해 놓는 방법이 있습니다. 프린터 개체 또는 게시된 공유에 대해 별개의 OU를 만들면 OU의 다른 개체에 대한 관리 작업을 수행할 때 이러한 개체를 따로 제외시킬 필요가 없습니다. 이 방법은 같은 OU에 사용자 계정과 컴퓨터 계정을 함께 그룹화하지 않는다는 방침과도 일맥상통합니다.

모델 선택

이제 OU 설계의 원칙에 대한 설명을 마치고 일반적인 설계 모델 몇 가지를 더욱 자세히 살펴보겠습니다. 여기에서 설명하는 모델은 극히 일부에 불과하며 여러 개의 모델에 대해서도 작업할 수 있습니다. 각 모델에서 원하는 부분을 선택하여 사용자의 특정 요구 사항에 맞는 하이브리드 모델을 직접 만들 수 있습니다.

작은 규모에서는 어떠한 모델에 대해서도 성공적으로 작업을 수행할 수 있겠지만 기업이 성장함에 따라 환경을 제어할 수 있는 범위가 줄어들 수 있습니다. 따라서 적합한 테스트 환경에서 처음부터 모델을 철저히 테스트하십시오. 또한 OU 구조도 처음에는 쉽게 변경할 수 있지만 시간이 지날수록 변경하기가 점점 어려워진다는 사실을 잊지 마십시오.

단순 모델

단순 모델이라는 이름은 거의 평면적으로 유지된다는 사실에서 따온 것입니다. 이 모델에서는 높은 수준의 OU 몇 개에 대부분의 개체가 포함되어 있습니다(그림 4 참조). 이 모델은 대개 IT 조직의 규모가 작고 부서가 많지 않거나 사람들이 여러 역할을 수행하는 소규모 기업에서 사용됩니다. 성능 저하를 막기 위해 Microsoft에서는 하위 OU를 15개로 제한하지만 필자는 10개로 제한할 것을 권장합니다.

그림 4** 높은 수준의 OU 몇 개에 대부분의 개체가 포함된 단순 모델 **(더 크게 보려면 이미지를 클릭하십시오.)

인적 자원 담당자와 지급 담당자가 동일인이라면 인적 자원 부서와 지급 부서에 대해 별개의 두 OU를 만들 필요가 없습니다. 단순 모델에서는 모든 사용자 개체를 하나의 큰 Accounts OU로 그룹화하거나 기본 Users 컨테이너에 유지할 수 있습니다. 그래도 사용자 개체는 컴퓨터 개체와 분리해야 합니다.

이 모델의 경우 한 단계 더 나아가 서버에서 워크스테이션을 분리하는 것도 좋습니다. 그런 다음 최소한 WMI(Windows® Management Instrumentation) 쿼리를 사용하는 GPO를 정의할 필요 없이 서로 다른 그룹 정책을 적용하여 워크스테이션 또는 서버를 필터링하여 제외시킬 수는 있습니다.

OU 구조를 광범위하게 유지하면 좋은 점 중 하나는 Active Directory 검색이 빠르게 실행된다는 것입니다. 개인적으로는 하위 OU를 10개 이상 사용하지 않도록 권장합니다. 이 모델에서는 개체를 매우 세부적으로 제어할 수 없지만 소규모 기업에서 개체를 관리하는 경우 그렇게까지 세부적으로 제어할 필요는 없을 것입니다. 따라서 대규모 기업에서는 이 모델을 제대로 사용하기 어려울 수 있지만 소규모 조직에서는 매우 유용하게 사용할 수 있습니다.

지리적 모델

지리적 모델에서는 지역별로 별개의 OU를 만듭니다. 이 모델은 IT 부서가 분산되어 있지만 여러 도메인을 운영하는 데 비용을 들이지 않으려는 조직에 가장 적합합니다(그림 5 참조).

그림 5** 지역별로 OU를 구분하는 지리적 모델 **(더 크게 보려면 이미지를 클릭하십시오.)

애틀랜타, 볼티모어 및 시애틀에 사무실이 있다고 가정해 봅시다. 각 사이트에서 자체적으로 사용자 및 컴퓨터를 관리하면 위임의 개념을 도입할 수 있습니다. 그러나 시애틀 사용자가 교육을 받기 위해 볼티모어에 오면 계정이 잠깁니다. 볼티모어의 IT 담당자는 이 사용자 계정에 대한 사용 권한을 위임 받지 않는 한 이 사용자를 도울 수 있는 방법이 없습니다. 볼티모어에서 오전 8시이면 시애틀에서는 오전 5시입니다. 즉, 시애틀 사무실에 도움을 요청하려면 몇 시간 기다려야 할 수 있습니다.

일부 다국적 기업에서는 "태양을 따르는" 모델을 사용합니다. 즉, 지원 부서 호출이 현재 영업 시간인 표준 시간대에 위치한 사이트로 전달됩니다. 이렇게 하면 각 사이트에서 24시간 지원 부서를 운영할 필요는 없지만 필요한 경우 계정 잠금을 해제하는 등의 지원을 위해 야근 직원을 배치할 수 있습니다.

이 모델을 사용할 경우 지리적 위치에 따라 별개의 OU를 만드는 것이 운영 요구 사항에 적합하지 않을 수 있습니다. 모든 사용자 OU의 각 지역 지원 부서에 대해 별개의 사용 권한을 위임해야 합니다. 그러나 사이트에 자체 IT 부서가 있으면 지리적 모델이 조직에 적합할 수 있습니다.

또한 지리적 모델은 도메인 운영 방식의 특성상 단일 도메인에서 사용하기 어렵습니다. 도메인은 다른 도메인과 서로 다른 보안 모델을 갖는 경향이 있습니다. Microsoft® Exchange 같은 엔터프라이즈 응용 프로그램을 보면 이러한 사실을 확실하게 알 수 있습니다.

애틀랜타의 Exchange Server에는 다른 메시지 정책이 정의되어 있을 수 있지만 기업의 모든 Exchange Server에는 같은 GPO가 적용되어 있을 것입니다. 이 경우 Exchange Server를 지역별로 별개의 OU에 배치하면 여러 OU에 같은 GPO를 불필요하게 연결하게 될 수 있습니다. 위임의 관점에서는 Exchange Server용 컴퓨터 개체에 실제로 고유한 사용 권한이 필요한지 Exchange 관리자에게 문의해야 합니다. 대부분의 경우 컴퓨터 개체를 지리적 OU로 분리해 놓는 것은 그룹 정책에 따른 용도일 뿐 위임을 위한 용도는 아닙니다.

형식 기반 모델

형식 기반 모델에서는 용도별로 개체를 분류합니다(그림 6 참조). 마지막으로 만든 사용자 개체가 일반 사용자 계정을 위한 것인지, 관리 계정을 위한 것인지 또는 서비스 계정을 위한 것인지 묻는다면 형식 기반 모델에서는 이러한 개체가 각각 별개로 취급됩니다.

그림 6** 기능에 따라 개체를 그룹화하는 형식 기반 모델 **(더 크게 보려면 이미지를 클릭하십시오.)

대부분의 경우 정책별로 사용자 개체를 다르게 분류해야 합니다. 대부분 사용자 계정 유형에 따라 정책이 달라집니다. 잘못된 사용의 예로 서비스 계정을 사용하여 컴퓨터에 로그온하는 것을 허용하는 경우를 들 수 있습니다. 서비스 계정 암호는 일반적으로 많은 사용자들이 공유하므로 한 사용자가 서비스 계정으로 로그온하면 정확한 신원을 파악할 수 없습니다. 문제가 발생하면 이벤트가 발생한 시각에 로그인한 사용자를 추적하기가 힘듭니다. 이 예제에서는 대화형 로그온을 방지하도록 서비스 계정에 대한 정책을 설정해야 합니다. 이 방법은 그림 3에 나와 있는 계층 모델에 적합합니다.

이러한 장점과 더불어 GPO 상속을 사용할 수 있습니다. 예를 들어 모든 사용자 개체에 대한 정책을 나타내는 모든 사용자 정책을 사용할 수 있습니다. 또한 모든 사용자 정책을 기반으로 하는 서비스 계정용 정책을 구분하여 사용할 수 있습니다. 이러한 접근 방법을 통해 서비스 계정에 다른 모든 계정과 같은 기본 정책 집합 및 특정 로그온 제한을 사용할 수 있습니다.

이 방식은 GPO 상속 대신 사용 권한 상속을 사용하는 위임의 경우에도 효과적입니다. 계층 2 관리자에게 계층 3 관리자 계정을 제외한 모든 계정에 대해 암호를 다시 설정할 수 있는 권한을 부여하려는 경우, 평면적인 OU 구조에서는 사용자 계정이 있는 각 OU에 대해 사용 권한을 위임해야 합니다. 그러나 계층 구조가 있는 형식 기반 모델에서는 계층 2 그룹에 Accounts OU에 대해 "암호를 다시 설정"할 수 있는 권한을 부여한 다음 계층 3 OU에서 단순히 사용 권한을 상속 받지 않거나 암호 다시 설정에 대한 계층 2의 명시적인 거부를 설정할 수도 있습니다.

이 방법은 컴퓨터 개체에 대해서도 효과적입니다. 서버와 워크스테이션을 구분하고 서로 다른 정책을 적용할 수 있습니다. 그런 다음 서버를 기능별로 세분화할 수 있습니다(그림 1 참조). 이러한 설계에서는 모든 서버에 영향을 미치는 Servers OU에 대해 높은 수준의 정책을 설정하고 각 하위 수준의 OU에 개별 정책을 설정할 수 있습니다.

예를 들어 MOM(Microsoft Operations Manager) 서비스 계정이 있다고 가정합니다. 이 계층 모델을 사용하여 MOM GPO를 만든 후 MOM Servers OU에 적용할 수 있습니다. 그런 다음 해당 GPO 내에서 MOM 서비스 계정에 서비스로 로그온할 수 있는 권한을 부여할 수 있습니다. 이 작업은 해당 OU의 MOM 서버에만 적용됩니다. MOM 서버는 여전히 높은 수준의 Servers OU에서 Servers GPO를 가져오지만 MOM OU에서 연결된 특수한 MOM GPO도 가져옵니다.

설계 문서화

Active Directory 환경에서 발생하는 수많은 변경 작업에도 전혀 문제가 발생하지 않는 OU 구조를 설계할 수 있다면 매우 좋겠지만 OU의 동적 특성을 추적할 수 있는 방법이 필요한 순간이 반드시 있습니다. 추적할 수 있는 방법이 없으면 환경에 대한 제어 능력을 급속하게 상실하게 됩니다. 변경 사항이 있으면 OU를 추가하거나 삭제해야 하므로 모델이 세 가지 기본 원칙을 지키면서 설계 모델을 계속 추구하는 데 필요한 작업에 대한 명확한 지침이 있어야 합니다. 이것이 바로 설계 문서화가 중요시되는 이유입니다.

Microsoft의 Windows Server 리소스 키트에는 문서화 가이드가 있습니다. 이러한 가이드는 사용하고 있는 구조가 그다지 많이 변경되지 않는 견고한 프레임워크인 경우에 유용합니다. 그러나 대부분의 조직에서는 자주 변경되는 매우 동적인 구조를 사용합니다. 따라서 OU 구조를 올바르게 문서화하고 동적 환경을 지원하는 데 필요한 중요한 몇 가지 팁을 소개합니다.

모든 정보가 관련되어 있는지 확인 용도가 분명한 문서를 작성하는 것이 중요합니다. 별로 관련 없는 정보가 너무 많이 포함된 조작 설명서를 너무 많이 작성하면 중요한 자료를 찾기 힘듭니다. 문서화를 위한 문서 작업이 되지 않도록 주의하십시오. OU의 액세스 제어 목록에 대해 모든 OU 또는 모든 ACE(액세스 제어 항목)의 개체 수를 포함하는 것이 실제로 필요합니까? OU 문서화의 경우 다음 정보만 있어도 충분합니다.

• OU 이름
• 간략한 설명
• 만든 사람 또는 추가 정보나 변경 사항이 있을 때 연락할 담당자
• 만든 시간

업데이트하기 쉽게 작성 복잡한 Microsoft Word 문서를 장황하게 업데이트해야 한다면 업데이트를 입력하는 작업이 더욱 싫어질 것입니다. 곧 많은 양의 업데이트를 한 번에 입력할 예정이라면 소소한 변경 사항은 당장 입력하지 않아도 좋습니다. 하지만 이러한 소소한 변경 사항은 잊어버리거나 미뤄둔 채 아무 것도 하지 않는 경우도 많긴 합니다. 따라서 문서 업데이트 작업은 매우 쉽고 지루하지 않아야 합니다. 대부분의 경우 간단한 Microsoft Excel® 스프레드시트에 열만 몇 개 작성하는 것으로 충분할 것입니다.

개체 자체에 설명 달기 OU 개체에는 설명을 입력할 수 있는 설명 특성이 있습니다. 설계 문서에 설명을 작성하는 것보다는 다른 사람들이 OU의 용도를 쉽게 알 수 있도록 설명 특성에 설명을 입력하는 것이 좋습니다. 자세한 정보를 포함해야 하면 설명 특성에 간략한 설명을 입력하고 자세한 정보는 OU 문서에 포함하십시오.

문서화 자동화 OU 구조의 내용을 텍스트 파일, Excel 스프레드시트 또는 HTML 파일로 수집하는 스크립트를 작성할 수 있습니다. 이 스크립트는 매일 밤 예약 작업을 통해 실행할 수 있습니다. 또한 OU의 설명 필드에 있는 설명을 통합하는 경우에도 매우 유용할 수 있습니다. 이렇게 하면 설명 특성의 내용이 파일로 수집되므로 자동으로 항상 최신 상태의 OU 구조 전체를 문서화할 수 있습니다. 기존 문서를 덮어쓰는 대신 스크립트를 실행할 때마다 새 파일을 만들면 시간의 흐름에 따른 OU 구조의 변화를 기록으로 남길 수 있습니다.

필요한 순간이 오기 전에는 잘 작성된 OU 구조 문서화의 중요성을 실감하지 못하는 관리자가 대부분입니다. 그러다가 어느 날 새벽 3시에 실수로 삭제된 다른 OU가 더 있는지 찾아내려면 복원하는 방법밖에 없게 됩니다.

이러한 일이 발생하지 않도록 미리 대비해야 합니다. 이 글을 읽은 후 즉시 OU 문서화를 시작하고 업데이트를 담당할 사람을 지정하시기를 바랍니다. 규칙에 따라 문서 업데이트 작업을 쉽게 해놓으면 이를 유지하는 일은 더욱 쉬워질 것입니다.

Ken St. Cyr는 IT 업계에서 경력 10년차의 Microsoft 컨설턴트입니다. Ken은 Active Directory 기반 디렉터리 솔루션을 초창기부터 설계 및 구현해 왔습니다.

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