이벤트란 무엇인가? 서버 입장에서 이벤트라면 ‘모든 것’을 의미한다. 사용자가 네트워크에 로그온 한 것도 하나의 이벤트이고, 서버에서 특별한 서비스가 시작한 것도 이벤트고, 누군가 어떤 자원에 접근한 것도, IP Address의 충돌이 발생한 것도 하나의 이벤트이다.

서버의 경우는 상대적으로 수많은 서비스들이 동작하고 있고 네트워크에서의 다른 사용자들의 접근도 다양하게 이루어지는 만큼 끊임없이 동작하고 있으며 그만큼 뭔가 맞지 않아 삐걱거리는 경우도 잦고, 또한 서버가 현재 겪고 있는 문제점이 있다면 빠른 시간내에 문제를 발견하고 해결해 주어야만 안정적인 서비스들을 제공할 수 있게 될 것이다.

서버는 이러한 일련의 이벤트가 발생할 때마다 이벤트의 성격별로 로깅(로그에 기록하는 작업을 말함)을 하고 관리자는 이벤트 뷰어라는 도구를 통해서 상태를 점검할 수 있다. 서버를 부팅시켰을 때 간혹 아래의 <그림11-52>과 같은 메시지를 받게 되는 경우가 있다.

이러한 메시지를 받았을 때 관리자는 관리도구에 있는 이벤트 뷰어의 도움을 받아야 한다. 관리도구à이벤트 뷰어를 실행하거나, 컴퓨터 관리도구에서 접근할 수도 있다. 또는 실행창에서 “eventvwr”를 입력하여 접근할 수도 있다.

이벤트 뷰어를 열면 왼쪽패널에 이벤트의 종류별로 로깅된 것을 확인할 수 있다. 예제화면에서는 응용프로그램 로그, 보안로그, 시스템로그, DNS Server로그가 있다. 처음 3가지는 모든 시스템에서 기본제공되는 이벤트들이고 DNS Server로그는 DNS서버가 동작하는 시스템에서만 제공되는 이벤트로그이다. 추가로 시스템이 Active Directory가 올라가 있는 도메인 컨트롤로라면 Directory 서비스 로그와 파일 복제 서비스 로그도 찾아볼 수 있다. 오른쪽 패널에는 로깅된 이벤트의 리스트를 보여주는데 자세히 보기 위해서는 원하는 이벤트를 더블클릭하면 된다.

이벤트를 더블클릭하면 <그림11-54>와 같은 화면을 보여주는데 여기서 몇가지 정보를 알 수 있다. 이벤트ID가 4301라는 것과 이벤트가 발생한 시간, 이벤트에 대한 구체적인 설명을 해 주고 있다.

이벤트는 <그림11-55>에서 보여지는 것처럼 3가지 유형을 가진다. 경고(!), 정보(i), 오류(x)로 나뉘는데 경고는 생길 수 있는 문제점에 대한 알림이고, 정보는 특정 서비스가 시작되었다거나 하는 등의 말그대로 정보를 주는 것이고, 오류는 서비스가 멈췄다거나, 디바이스의 오류가 발생하였다거나 하는 문제점을 알려준다.

관리자들이 가장 관심을 가져야 할 메시지는 ‘오류’메시지이다. 색깔부터 빨간색으로 표기되고 있어 사실 기분나쁘다. 늘 파란색의 ‘정보’메시지만 로깅된다면 좋겠지만 이 시간에도 당신의 서버는 수없이 많은 이벤트를 기록하고 있을 것이다. 그렇다면 이러한 메시지가 발생했을 때 어떻게 대처해야 할까?

해결하고자 하는 메시지를 더블클릭해서 자세한 정보로 접근한다. 이벤트ID와 더불어 구체적인 설명을 해 주고 있는데 이 설명만으로 이벤트가 발생한 원인을 파악할 수 있다면 좋겠지만 대부분의 경우는 그렇지 못하다. 이때 이벤트ID를 통해서 마이크로소프트의 Support 사이트를 통해서 검색을 해 보면 상당부분은 이벤트의 발생원인과 해결방법등이 기록된 기사들을 찾을 수 있다. http://support.microsoft.com나 http://www.eventid.net에 접근하여 이벤트ID를 입력하여 검색해 본다. 검색결과가 나오지 않으면 설명중에서 핵심단어를 검색할 필요가 있다. 자주 하다 보면 검색사가 될 것이다. 가장 빠른 해결책이 될 것이니 지겹지만 그렇게 접근해 볼 필요가 있다.

다음의 화면은 <그림11-56>에서 http://go.microsoft.com/fwlink/events.asp 링크를 클릭한 화면이다. 간혹 쉽게 해결책을 제시해 주기도 한다.

필자 개인적으로는 Google검색을 활용한다. 일반적으로 필요로 하는 대부분의 문제에 대한 원인 및 해결방법은 Google을 통해서 찾을 수 있었다. 해결이 되지 않아 Q&A사이트나, 마이크로소프트를 통해서 지원을 받고자 할때는 그림에서 동그라미로 표기된 부분인 ‘복사’버튼을 이용한다. 복사한 다음에 E-mail이나 게시판에 붙여넣기 하면 이벤트 전체를 상대방에게 알려줄 수 있다. 당신의 컴퓨터를 열고 복사버튼을 누른뒤 메모장에 붙여넣기를 해 보라. 무엇을 말하는지 알 수 있을 것이다.

또한 이벤트로그를 필터링 해서 볼 수도 있다. 원하는 카테고리별로, 혹은 시간대별로 로그를 필터링해서 원하는 정보를 찾을 수가 있다. 관리콘솔의 왼쪽패널에서 원하는 로그를 선택하고 마우스 오른쪽 클릭하여 ‘등록정보’로 접근한다.

필터탭을 선택하여 필터링을 설정하면 원하는 결과를 얻을 수 있다. <그림11-58>의 ‘일반’탭에서는 로그 크기 등을 결정할 수 있는데 기본적으로 이벤트 뷰어에서 저장하는 로그 크기는 512KB로 설정되어 있다. 간혹 서버를 처음 셋업하고 “로그가 꽉 차서 더 이상 로그를 기록할 수 없습니다.”라는 에러 메시지를 받게 되는 경우가 있는데 이때는 이벤트 뷰어 도구를 이용하여 로그를 비워주거나 로그 크기를 키워줄 필요가 있다.

까만색 화면 하면 DOS를 떠올리는 독자들이 있을 것이다. 그 시절 우리는 컴퓨터에서 사용하는 프로그램, 시스템 환경설정 등을 하기 위해 Autoexec.bat Config.sys와 같은 파일을 이용했던 것을 기억할 것이다. Windows에서 역시 이러한 파일이 사용되었으며 Win.ini, System.ini 등의 정보파일들도 환경설정과 관련된 파일이다.

윈도우 서버 2000 & 2003에서는 시스템의 환경설정을 위해서 이러한 파일들을 사용하지 않는다. 시스템, 하드웨어, 소프트웨어 등의 모든 구성을 레지스트리(registry)라고 부르는 데이터베이스에 저장하는 방법을 사용하고 있다. 우리가 TCP/IP등록정보를 열어서 시스템의 IP Address를 변경했다거나, 오피스XP라는 새로운 어플리케이션을 추가했다거나, 화면을 1024*768로 변경했다거나 하는 등의 모든 작업을 했을 때 이 결과는 레지스트리에 반영된다. 시스템은 부팅을 할 때 이 레지스트리로부터 설정을 읽어서 화면에 보여주고 제어하는 방식으로 동작하고 있다.

이해를 돕기 위해 다음을 확인해 본다. 레지스트리 편집도구인 regedt32.exe 를 실행창에서 입력해서 레지스트리를 연다.

“HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows NT > CurrentVersion” 을 순서대로 찾아가 보라<그림11-44>.

레지스트리 편집기에서 왼쪽패널에 보이는 것이 “키(Key)”이고 오른쪽 패널에 보이는 것이 “값(Value)”들이다. 오른쪽 패널에서 몇가지 정보를 찾아볼 수 있는데, 우리에게 익숙한 내용이 많이 보일 것이다. RegisteredOwner 라는 값을 찾아서 더블클릭한다.

<그림11-45>의 예제에서는 ‘wonsuk’이라는 문자열 대신에 ‘Song won suk’을 입력하여 변경하였다. [확인]을 눌러서 변경사항을 저장한다. 그 다음에 바탕화면의 ‘내 컴퓨터’의 등록정보나, 윈도우탐색기를 열고 도움말 메뉴의 “Windows 정보”를 클릭하면 레지스트리를 통해서 바꾼 설정을 확인할 수 있다. 처음 OS를 설치할 때 입력했던 사용자 이름을 직접 레지스트리를 편집함으로써 변경한 것이다.

사소한 것 하나를 확인해 봤는데, 이렇듯 레지스트리는 시스템의 처음부터 끝까지, 결국 모든 내용을 담고 있는 하나의 데이터베이스라고 할 수 있다.

이러한 레지스트리를 잘 관리하는 일은 매우 중요한 일이다. 위의 과정을 그대로 따라해 본 독자라면 조금 까다롭다는 생각이 들 것이다. Windows 라는 이름의 OS는 ‘인터페이스가 무척 쉽다’라는 것이 큰 특징중의 하나인데, 이렇게 원시적으로 일일이 레지스트리를 찾아다니며 모든 작업을 해야만 할까? 라는 의문이 생긴다. 정답은 ‘아니오’이다.

실제로 관리자가 레지스트리 편집기를 띄워서 직접 값을 추가한다든지 변경하는 일은 레지스트리 관리작업에 있어서 아주 일부분에 지나지 않는다. 물론 관리자라면 이것의 사용방법에 대해서는 알고 있어야겠지만 레지스트리를 해부(?)하려는 노력보다는 Windows 시스템에서 하드웨어, 소프트웨어 등의 각종 설정에 대한 흐름을 이해하는 편이 더 나을 것이다.

그렇다면 어떻게 이 레지스트리를 관리하는 것일까? 그것은 바로 우리에게 너무나 익숙한 ‘제어판(Control Panel)’이다. 제어판이라구? 뜻밖의 답이라고 생각될 수 있겠지만, 우리는 제어판을 통해서 시스템에 관련된 거의 대부분의 설정을 할 수 있다는 것을 잊는 경우가 많다.

바탕화면에서 ‘내 컴퓨터’아이콘의 등록정보를 열면 ‘시스템 등록정보’가 뜨게 되는데 이것은 사실 제어판에 있는 하나의 설정이다. 또, 바탕화면을 마우스 오른쪽 클릭하고 등록정보를 열면 ‘디스플레이 등록정보’가 열리는데 이것 역시 제어판의 일부일 뿐이다. 바탕화면의 다른 것들도 마찬가지이다. 인터넷 익스플로러 아이콘의 등록정보를 열어서 ‘인터넷 옵션’을 수정한다거나, 네트워크 환경의 등록정보를 열어서 프로토콜을 추가하고, IP Address를 변경하는 등의 작업을 한다거나,,, 이 모든 작업들은 결국 제어판을 건드린다는 것을 의미한다.

제어판에서 무엇이든지 설정을 변경하면 그것은 결국 레지스트리의 데이터베이스를 변경하는 효과를 가지게 된다. 이렇듯 제어판이라고 하는 도구는 레지스트리를 관리하기 위한 간접적인 관리도구인 셈이다. 제어판을 통해서 할 수 없는 작업들은 레지스트리를 직접 편집해야 하는 경우도 있는데, 그때 그때 필요한 경우에 찾아서 작업할 수 있을 것이다.

레지스트리를 건드릴 수 있는 또 다른 방법은 어떤 것이 있을까? 또, 당신이 관리하는 시스템이 한두대가 아니라 많은 수의 시스템의 레지스트리를 관리해야 한다면? 그때 바로 정책(Policy)이 사용될 수 있는데, Active Directory와 연계하여 그룹정책(Group Policy)를 사용하면 효율적으로 도메인의 전체 사용자 및 컴퓨터에 대한 레지스트리를 간접적으로 변경하는 효과를 주기 때문에 유연성 있는 관리방법을 제공한다. 그룹정책에 대해서는 14장에서 자세히 다룬다.

지금까지 레지스트리가 관리되는 방법에 대해서 이야기했다. 이 레지스트리를 직접 관리하는 경우를 위해 간단한 사용방법에 대해서 알아본다.

레지스트리 편집기는 2가지가 제공된다. Regedit.exe와 Regedt32.exe 가 있는데, regedt32.exe를 권장한다. Regedit.exe는 Windows 9x 에서 사용되는 편집기인데 Windows Server 2003에서도 제공되고 있다. 데이터베이스는 동일하다. 편집기는 이 데이터베이스를 건드리는 도구일 뿐이니까. Regedit.exe는 레지스트리를 Key와 Value, Data등으로 검색이 가능하여 상대적으로 검색기능이 좋은 편이다. 그렇지만 레지스트리의 권한설정이나, 읽기 전용모드가 지원되지 않기 때문에 Regedt32를 사용하는 편이 좋다.

레지스트리 편집기를 실행하면 레지스트리 데이터베이스가 열린다. <그림11-47>와 같은 화면을 얻을 수 있다.

레지스트리는 계층구조로 되어 있다. 윈도우 탐색기의 구조와 아주 유사하다. 가장 크게 나누면 5개의 서브트리로 구성되어 있는데 각각이 하나의 창을 이루고 있는 것을 알 수 있다. HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT, HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, HKEY_USERS라는 이름을 가진 5개의 서브트리가 있다. 이것을 C: D: 등의 루트폴더로 이해하면 쉽다.

뭐가 이렇게 복잡한가 싶지만 사실 그렇지만은 않다. 구분지어 본다면 HKEY_CURRENT_USER, HKEY_USERS는 시스템에서 로그온 하는 사용자에게 주어지는 설정을 담은 레지스트리이고, 나머지는 로그온하는 사용자와는 상관없이 시스템 자체에 주어지는 설정을 담고 있다. 예를 들어서 우리가 컴퓨터에서 TCP/IP설정을 변경했다면 이것은 로그온 하는 사용자와는 상관없는 시스템 설정이 변한 것이다. 이것들은 HKEY_LOCAL_MACHINE 이라는 서브트리에 저장되는 정보이다.

5개의 서브트리중에서 관리자가 직접 이 레지스트리 편집기를 통해서 작업을 하는 대부분의 경우는 HKEY_LOCAL_MACHINE 서브트리에서 이루어진다. 줄여서 “HKLM”이라고도 부르는 이 서브트리의 이름은 기억을 해 두기 바란다. 다른 서브트리의 경우는 직접 편집기로 편집하는 경우는 극히 드물다.

각 서브트리마다 키(KEY)들이 존재하고, 키 아래에는 서브키들이 있다. 최종적으로 가장 아래에 위치한, 윈도우 탐색기를 예를 들면 파일에 해당하는 값(VALUE)이 오른쪽 패널에서 펼쳐진다. 이 값들은 저마다 고유한 데이터를 가지고 있게 되며 데이터의 형식에 따라서 5가지 데이터 타입으로 구분할 수 있다.

레지스트리에 특별한 값을 하나 추가하는 작업을 예제로 알아보자. 당신은 Windows Server 2003를 테스트중이다. 시스템을 재시작하는 일을 반복해야 하는데 그때마다 로그온을 하기가 번거로워 자동으로 시스템에 로그온 하는 방법을 찾다 보니, 레지스트리를 직접 수정하면 가능하다는 것을 알게 되었다. HKLM > Software > Microsoft > Windows NT > CurrentVersion > Winlogon 키(KEY) 아래에 ‘AutoAdminLogon’이라는 값(VALUE)을 추가하고 ‘REG_SZ’데이터형식으로 “1”이라는 데이터를 입력하면 된다고 한다. 작업을 해 보자. 같은 방법으로 DefaultPassword라는 값(Value)을 추가하고 'REG_SZ'데이터형식으로 '실제 패스워드'를 데이터로 입력한다.

먼저 레지스트리 편집기를 열고, 값을 추가하고자 하는 키까지 찾아서 이동한다<그림11-48>

값을 추가하고자 하는 키를 클릭한 상태에서 편집메뉴의 ‘값 추가’를 선택한다.

‘값 추가’화면에서 ‘값 이름’에는 AutoAdminLogon이라고 입력하였다. 조금이라도 틀리면 원하는 대로 동작하지 않는다. 데이터 형식은 REG_SZ 를 선택했다. 역시 이것도 형식이 다르면 해당 값은 의미가 없다.

값 이름’을 지정한 후 [확인]을 누르면 ‘문자열 편집기’가 나온다. 문자열에 ‘활성화’를 의미하는 레지스트리 데이터인 ‘1’을 입력하고 [확인]을 눌러서 작업을 마친다.

<그림11-51>을 보면 AutoAdminLogon이라는 값(VALUE)가 추가된 레지스트리를 볼 수 있다.

서버의 하드디스크는 ‘관리’되어야 한다. 당신의 회사가 서버로서 PC급의 시스템을 사용하는 것이 아니라 전용서버제품을 구입하여 사용한다면 보다 좋은 선택이라 할 수 있다. 그만큼 비용의 측면이 감수되어야 하지만 보통의 경우 투자한만큼 만족할 만한 성능과 안정성을 보장하기 때문이다. PC급의 시스템을 사용할 때도 적은 투자비용으로 최대의 안정성을 확보하기 위해서 디스크를 효율적으로 관리하는 방법을 찾아보자. 또, 이러한 기술은 윈도우 서버에서 제공되는 소프트웨어적인 기능이기는 하지만 전용서버에서 하드웨어적으로 지원되는 것과 기술적인 측면은 별 차이가 없는 만큼, 이론적으로도 알아둘 만한 내용이다.

디스크를 사용하기 위해 먼저 파티셔닝을 하게 되고, 논리적인 몇 개의 영역으로 나눠서 디스크를 사용하게 되는데, DOS시절에는 어차피 디스크 크기가 커 봐야 1기가도 되지 않았기에 디스크 하나에 파티션 하나만 사용해도 충분했다. 점점 하드디스크의 크기가 커지면서 2개 이상의 파티션을 사용하게 되었고 파티션은 주(Primary) 파티션과 확장(Extended) 파티션이라는 2가지로 구분이 되었다. 첫번째 잡히는 파티션이 주 파티션이 되고 하나의 디스크에는 하나의 주 파티션만 있을수 있다. 주 파티션에 시스템이 부팅하는데 필요한 영역을 담을 수가 있다. 일반적으로 C: 로 사용되는 것이 그것이다. 확장 파티션에는 논리 드라이브라는 이름으로 원하는 만큼 드라이브를 추가하는 것이 가능하다. 그래서 정확히 표현한다면 디스크의 파티션은 ‘주 파티션’과 ‘확장 파티션 내의 논리파티션’이라고 나눌 수가 있겠다. NT부터는 이러한 주 파티션이 하나라는 제한이 아닌 최대 4개까지 생성하는 것이 가능해졌다. 하나의 디스크당 최대 4개의 주파티션을 생성할 수 있다. 혹은 3개의 주파티션과 1개의 확장파티션을 가지는 것도 가능하다. 하나의 디스크에서 5개 이상의 파티션을 필요로 한다면 반드시 후자를 따라야 한다. 하나의 확장파티션을 만든 다음에 그 안에서 논리드라이브를 만드는 방법을 이용해야 한다는 것이다.

Windows 2000부터는 기본디스크로서 시스템의 디스크를 관리하는 것뿐만 아니라 동적디스크로 디스크를 업그레이드하여 ‘볼륨(Volume)’단위로 디스크를 관리할 수 있게 해 준다. 기본디스크로 사용하는 것에 비하여 동적디스크는 디스크확장의 효율성, RAID1, RAID5등으로 디스크 오류제어의 효율성 등을 제공한다.

11-3-1-1. 디스크 관리 도구

DOS나 Windows9x에서 디스크를 관리하기 위해서 Fdisk 를 사용해 본 경험이 있을것이다. Windows NT계열의 OS에서는 디스크관리를 위한 특별한 도구가 제공된다. ‘컴퓨터관리’ 관리콘솔을 통해서 접근할 수도 있다<그림11-7>. 그러나 그것보다는 ‘시작à실행’창에서 diskmgmt.msc 라고 입력해 보자. 그러면 ‘디스크 관리’ 도구가 뜨는 것을 확인할 수 있을 것이다<그림11-9>

이 디스크 관리도구를 통해서 여러가지 정보를 살펴보고 추가작업을 할 수도 있다.

현재 이 시스템에는 하드디스크가 하나있고(디스크0), CD Rom 드라이브 2개가 있다.(CDRom0, CDRom1) 디스크0 는 현재 기본디스크로 설정이 되어 있으며 파티션이 3개가 있는데 C:는 주파티션이고, 일부 영역은 확장파티션으로 구성이 되어 있다. 확장파티션에는 D:라는 하나의 논리 드라이브가 잡혀 있고, 마지막에 7M의 공간은 파티션이 나누어져 있지만 C: D:와 같은 문자열이 할당되지는 않았다. 폴더의 형태로 마운트되어 있는 것이다. 마지막에 있는 ‘새 볼륨’에 마우스 오른쪽 클릭해 보니 몇가지 메뉴가 눈에 띈다. ‘파티션 활성화’를 통하여 Active Partition으로 지정할 수도 있다. 이것은 주 파티션으로 나뉘어 있을때만 가능한 작업이다. 위에서 주 파티션만 시스템 파티션이 될 수 있다고 한 것을 기억하라. D:와 같은 드라이브 문자를 변경할 수도 있으며, 새롭게 포맷을 한다거나, 파티션을 삭제하는 작업들도 가능하다. 구체적인 설명은 하지 않겠다. 인터페이스가 간결하여 쉽게 알 수 있을 것이다.

11-3-1-2. 파티션 관리하기

중요한 내용 하나를 정리하고 가자. 하나의 디스크에 생기는 여러 개의 파티션이 있는데 시스템은 이 파티션마다 번호를 붙여서 각 파티션을 구별하게 된다. 디스크, CPU, 메모리, 확장슬롯 등이 0번부터 번호가 시작되는 것과는 달리 파티션 번호는 1번부터 시작된다. 파티션1, 파티션2… 와 같은 형식을 말한다. 파티션 번호를 붙이는 방법은 디스크마다 별도로 주파티션을 1,2,..등의 순서대로 할당한 다음에 논리드라이브 3,4,.. 의 순서로 정의된다. 순서가 뭐가 중요할까 싶기도 하지만 이것 하나 때문에 시스템이 부팅이 되지 않는 상황까지 생기기도 한다. 잘 정리하자. <그림11-10>을 예로 들어보자.

<그림11-10>의 디스크0을 보면 파티션이 3개로 나뉘어 있는 것을 알 수 있다. 주파티션인 C:와 확장파티션내의 논리드라이브인 D: 그리고 폴더에 마운트된 주 파티션으로 나뉜 볼륨 하나가 있다.  파티션 번호를 붙여보면 첫번째 파티션인 C:는 1번, D:는 3번, 맨뒤의 7M 영역이 2번이 된다. D:가 먼저여서 2번인것처럼 보이지만 뒤의 영역이 주파티션으로 만들어져 있으므로 그것이 2번이 되고, 논리드라이브인 D:는 3번이 할당되는 것이다.

디스크1번을 보면 E:와 F:가 있다. 이들은 각각 디스크1번에 있어 파티션 1번과 파티션 2번을 차지하고 있다. F:는 NT가 설치되어 있는 부트파티션이다. 그 뒤로 2개의 영역이 더 보이는데 이것은 아직 파티션이 구성되어 있지 않기 때문에 파티션 번호가 할당되지 않는다. 이들 2개의 영역을 살펴보면 서로 다르다는 것을 알게 되는데, 그림에서 세번째 영역으로 보이는 1.56GB의 공간은 확장파티션 안에 있는 빈 영역이고, 마지막의 2.93GB의 공간은 아예 할당되지 않은 공간이라고 되어 있다.

위의 상황에서 당신이 만일 확장파티션의 빈공간인 세번째 영역에 G:를 생성했다고 한다면 그 G:의 파티션 번호는 3번이 된다. 기존의 E:와 F:의 파티션 번호에는 영향을 미치지 않는다<그림11-11>

하지만 할당되지 않은 빈공간인 네번째 영역에 G:를 생성하면 상황은 달라진다. 파티션 번호가 할당되는 것이 논리드라이브보다는 주 파티션이 우선하기 때문에 G:가 2번이 되고 기존의 F:는 2번 대신에 새로운 파티션 번호인 3번이 할당되게 되는 것이다<그림11-12>

이 결과로 시스템은 부팅할 때 기존의 파티션2번을 찾아서 부팅을 시도하지만 새로운 드라이브가 생기면서 WINNT 폴더를 담고 있는 파티션이 3번으로 변경되었기 때문에 부팅프로그램은 부팅에 실패하게 된다. 이 경우 부팅시 이러한 위치를 지정해 주는 파일인 boot.ini 에 올바른 파티션 번호를 수정해 주어야 한다. 시스템파티션의 루트에 있는(일반적으로 C:) boot.ini 파일을 살펴보면 파티션 번호를 확인할 수 있다. (boot.ini는 숨김, 시스템 속성을 가지고 있는 파일이므로 기본적으로 보이지 않는다. 폴더옵션을 변경하거나 실행창에서 “notepad c:\boot.ini”를 입력하여 파일을 열어본다.) 그러한 파일의 변경을 자동으로 수행하지 않기 때문에 이러한 파일의 사용법등에 대해서는 뒤에서 다시 설명하도록 한다.

11-3-1-3. 동적 디스크로 업그레이드하기

보다 효율적인 디스크관리를 위해서는 동적디스크를 사용한다고 했다. 단일 하드디스크를 가진 시스템에서는 특별한 필요성을 찾지 못하지만, PC를 회사의 서버로 사용하고 있는 경우라면 가급적이면 2개 이상의 하드디스크를 장착하고 동적디스크로 업그레이드를 하면 전용서버 부럽지 않은 하드디스크 관리를 할 수 있다.

<그림11-13. 동적디스크로 업그레이드 과정1>	디스크 관리도구에서 디스크의 정보를 나타내는 부분을 마우스 오른쪽 클릭하고 ‘동적디스크로 업그레이드’를 선택한다.
<그림11-14. 동적디스크로 업그레이드 과정 2>	동적디스크로 업그레이드 할 디스크를 선택한다.
<그림11-15. 동적디스크로 업그레이드 과정 3>	업그레이드할 디스크의 목록을 재 확인하고, [업그레이드]버튼을 클릭한다.
<그림11-16. 동적디스크로 업그레이드 과정 4>	이전버전의 OS로는 부팅할 수 없다는 경고메시지이다. 그냥 해 보는 소리가 아니다. 주의해야 할 것이다.
<그림11-17. 동적디스크로 업그레이드 과정 5>	동적디스크는 기본디스크와 디스크 관리방법이 달라진다. 기존의 파일시스템은 볼륨이라는 새로운 단위로 변경되게 된다. 파일시스템을 분리시킨다는 메시지가 나온다. [예]를 누른다.
<그림11-18. 동적디스크로 업그레이드 과정 6>	과정은 모두 마쳤다. 시스템을 재시작하면 업그레이드가 완료된다.

11-3-1-4. 단순볼륨 (Simple Volume)

가장 기본적인 볼륨이다. 아무런 추가설정이 필요없는 단일볼륨을 일컫는다. 기본디스크의 파티션과 차이가 없이 D: E: 등의 문자열을 할당하거나, 폴더에 볼륨을 마운트시키는 것이 가능하다. 이 단순볼륨은 스팬볼륨을 이용하여 공간을 확장하거나, 미러볼륨을 구성할 수 있는 기본적인 하나의 볼륨이 된다.

11-3-1-5. 스팬볼륨 (Spanned Volume)

동적디스크를 사용하면 몇가지 새로운 기능을 구현할 수 있다. 첫번째로 스팬볼륨에 대해서 살펴보자. 스팬볼륨은 이전 버전에서 ‘볼륨셋’이라고 불리웠던 기능이다. 한마디로 설명하면 디스크 공간을 효율적으로 써 보자는 것이다. 기존에 파티션을 잡아서 사용하고 있었는데 공간이 부족할 때 스팬볼륨을 사용해서 파티션을 확장할 수 있다. 또한 2개의 디스크가 있었는데 하나는 200MB, 하나는 300MB가 남았다고 가정했을 때 2개의 공간을 각각 D: E: 형태로 사용하지 않고 500MB 전체를 하나의 D:로 잡아서 사용하는 것이 가능하다.

하지만 공간을 효율적으로 쓰는 것은 가능하지만 스팬볼륨의 멤버로 되어 있는 디스크중 하나만 손상이 되어도 해당 파티션은 쓸 수가 없다는 단점이 있어서 현실적으로 서버에는 권장하지 않는 방법이다. 추가로, 스팬볼륨은 시스템파티션이나 부트파티션에는 구현될 수 없다.

예제를 통해서 스팬볼륨의 구현과정을 알아보자.

<그림11-19. 스팬볼륨 생성과정 1>	예제에서는 디스크0번과 1번, 2개의 디스크를 가진 시스템을 보여준다. 디스크0번의 할당되지 않은 4.31GB의 영역을 마우스 오른쪽 클릭하고 ‘볼륨 만들기’를 선택했다.
<그림11-20. 스팬볼륨 생성과정 2>	볼륨종류를 살펴보면 단순볼륨, 스팬볼륨, 미러볼륨, 스트라이프 볼륨이 활성화되어있고, RAID-5 볼륨은 비활성화되어 있는 것을 볼 수 있다. 이어서 설명을 하겠지만 RAID-5볼륨은 최소 3개의 물리적인 디스크가 필요하므로 비활성화된 것이다.
<그림11-21. 스팬볼륨 생성과정 3>	‘디스크 선택’화면에서 왼쪽의 ‘사용 가능한 모든 동적 디스크’에서 스팬볼륨을 구성할 디스크를 선택하고, 크기를 선택하여 [추가>>]버튼을 눌러서 오른쪽으로 선택되도록 한다. 예제에서는 디스크0번에 200MB, 디스크1번에 200MB로 총 400MB의 볼륨을 구성하였다. 두개의 디스크의 사이즈는 같지 않아도 무방하다.
<그림11-22. 스팬볼륨 생성과정 4>	다음부터는 파티션을 생성하는 과정과 차이가 없다. 드라이브 문자를 할당하거나, 하나의 폴더에 볼륨을 마운트시킬 수 있다.
<그림11-23. 스팬볼륨 생성과정 5>	원하는 파일시스템으로 볼륨을 포맷한다.
<그림11-24. 스팬볼륨 생성과정 6>	작업이 완료되었다.

11-3-1-6. 스트라이프 볼륨 (Striped Volume)

스트라이프 볼륨은 디스크 I/O(Input/Output) 성능개선을 위해서 제공된다. 자료에 따르면 단순볼륨에 비해 스트라이프 볼륨은 30% 정도의 입출력 성능 개선효과가 있다고 한다. 디스크에 데이터를 기록하는 방식 자체가 다르다. 현실적으로 일반PC에서 사용하는 IDE나 EIDE등의 컨트롤러 타입의 경우는 큰 성능의 증가를 보기는 어렵지만 대부분의 서버제품군에서 사용되는 SCSI 컨트롤러 타입의 경우에는 제대로된 성능향상을 제공한다. 그런 이유로 서버제품에서는 SCSI를 주로 사용하고 있는 것이다.

스트라이프 볼륨을 구성하면 디스크순서대로 데이터를 기록하는 것이 아니라, 64KB단위씩 평행하게 데이터를 병렬로 써 나가게 된다. 예를 들어 두개의 디스크로 스트라이프 볼륨을 구성했다면 첫번째 디스크에 64KB만큼 데이터를 기록하고, 다음엔 두번째 디스크에 64KB단위로 데이터를 기록한다. 다시 첫번째 디스크에 데이터를 기록하기 시작한다. 이렇듯 반복해서 2개의 디스크를 번갈아가면서 기록하기 때문에 입/출력 성능을 높여줄 수 있게 되는 것이다. 에서는 최소 2개에서 최대 32까지의 디스크를 스트라이프 볼륨으로 구성하는 것이 가능하다. 시스템파티션이나 부트파티션에는 구현될 수 없는 방법이다.

이러한 스트라이프 볼륨은 디스크 입/출력 성능을 높여줄 수 있다는 큰 장점이 있지만 역시 하드디스크의 물리적인 오류에 대해서는 아주 민감하다. 스트라이프의 멤버로 된 디스크중 하나만 손상이 되어도 전체 스트라이프 영역의 데이터를 읽을 수가 없게 되기 때문에 소프트웨어적인. 즉 서버 자체적으로 제공되는 스트라이프 볼륨은 현실적으로 사용을 권하지 않는다. 이론적으로만 이해하자. 그렇다면 서버에는 어떠한 기술들을 사용해야 할까? 기본적으로 서버에 요구되는 사항은 디스크중 하나의 디스크가 손상이 되었을 경우에도 오류를 극복(Fault-Tolerance)할 수 있는 방법이 필요한 것이다. 이러한 요구를 위해서 마이크로소프트는 RAID (Redundant Array Independent Disk) 기술을 지원하고 있다. 다음에 소개되는 미러볼륨과 RAID-5볼륨이 바로 그것이다.

11-3-1-7. 미러 볼륨 (Mirrored Volume)

하드디스크의 물리적인 결함을 극복할 수 있는 방법은 어떠한 것이 있을까? 어떤일이 있어도 하드디스크가 결함이 생기지 않도록 한다? 좋은 방법이지만 현재로서는 그런 기술은 없다. 그렇다면 다음으로 생각할 수 있는 것은 하드디스크를 ‘하나 더’ 가지는 방법이 있다. 바로 하드디스크를 중복해서 사용함으로써 데이터를 2중으로 가져 가겠다는 것을 뜻한다. 그러한 방법이 바로 ‘미러 볼륨’으로 구현된다.

미러볼륨의 주된 사용용도는 시스템파티션과 부트파티션이다. 시스템파티션은 보통 C:를 일컬으며 부트파티션은 OS가 설치된 폴더가 있는 파티션을 가리킨다. 하나의 디스크에 OS를 설치했을 때 당신은 시스템의 건강을 위해서 지속적으로 서비스팩을 패치하고, 알려진 바이러스를 탐지할 수 있는 도구도 설치했으며 마이크로소프트 웹사이트로부터 지속적으로 핫픽스를 통해서 버그를 패치하고 있다. 하지만, 그런 노력에도 불구하고 하드디스크가 망가지는, 어찌보면 어이가 없을수도 있는 일이 발생한다면 그런 노력은 허사가 되고 만다. 물론 백업된 데이터가 있고, 시스템을 재설치하면 될 일이겠지만 그렇게 하기에는 많은 시간과 수많은 사용자들의 원성을 살 수 밖에 없을것인데 미러볼륨은 간단히 문제를 해결해 줄 수 있다. 동일한 설정, 동일한 데이터를 가진 또 다른 디스크 하나에 복제를 떠 놓겠다는 것이다. 말 그대로 “디스크 미러(거울)”이다.

그렇게 하면 안심이다. 하나의 디스크가 망가졌어도 동일한 내용을 담은 디스크가 하나 더 있으므로 즉시 관리자는 미러된 디스크로 시스템을 재 시작시키면 시스템이 부팅되는 정도의 시간만 있으면 정상적인 서비스를 계속하도록 유지할 수가 있다. 잘 돌아가는 시스템이라고만 생각하면 디스크는 분명히 낭비가 될 수도 있지만, 디스크 하나 더 장착하는 비용으로 믿을만한 서버가 된다면 훌륭하지 않은가? 그것도 수천, 수억원 대의 전용서버가 아니라 고작 1,2백만원 정도의 PC로써 말이다.

미러 볼륨은 2개의 디스크를 필요로 한다. 지금 당신의 서버가 단일디스크를 가진 시스템이라면 당장 디스크를 하나 더 장착하자. 아주 간단히 구현할 수가 있다. 예제를 통하여 캡처한 그림을 참고한다.

<그림11-26>을 보면 디스크0번부터 디스크2번까지 3개의 디스크를 가진 시스템이라는 것을 알 수 있다. 디스크0번의 C:는 시스템 파티션인 동시에 부트파티션이다. C:에는 Windows Server 2003이 설치되어 있다. 먼저 미러볼륨을 구성하기 위해서 디스크 3개를 모두 ‘동적 디스크’로 업그레이드를 해 두었다. 업그레이드 방법은 “11-3-1-3. 동적 디스크로 업그레이드하기”에서 설명하였다.

미러볼륨을 구성하기 위해서 먼저 미러를 구성할 원본이 되는 볼륨을 마우스 오른쪽 클릭하여 ‘미러 추가’를 선택한다<그림11-27>.

미러볼륨이 될 복제대상 볼륨을 지정해 준다. 예제에서는 디스크1번에 만들겠다고 설정했다. [미러추가]버튼을 클릭한다.

볼륨을 미러했다는 메시지가 나온다. 아직 끝난 것은 아니다. 중요한 것은 ‘미러 디스크에서 부팅할 수 있게 하려면 boot.ini 파일에 적절한 항목을 추가하라’는 메시지이다. Boot.ini 파일이 시스템이 부팅할 때 필요로 하는 “OS가 설치된 폴더”의 위치를 알려준다. 이 파일에 만일 원본볼륨을 담고 있는 디스크가 물리적으로 손상이 되었을 때 동일한 내용을 복제해 둔 미러볼륨을 통해서 부팅을 할 수 있도록 boot.ini 파일에 그러한 경로를 추가하라는 것을 의미한다.

<그림11-30>은 <그림11-29>의 메시지에서 보여주는 것처럼 boot.ini파일을 편집한 그림이다. Boot.ini 파일은 텍스트 파일이다. 메모장으로 열어 볼 수 있는데, 맨 아래의 한줄이 편집된 내용이다. 하이라이트된 부분을 바로 위의 줄과 비교해 보면 rdisk(0)이 rdisk(1)로 바뀌었고, Microsoft Windows 2000 Advanced Server 뒤에 “(Mirror)”이라는 문구가 추가된 것을 알 수 있다. 이제 이 시스템에서 부팅을 하게 되면 당신은 부팅시 이 두가지중 하나를 선택하도록 요구받게 될 것이다. 리스트중 두번째를 선택하면 첫번째 디스크의 원본볼륨을 통해서 부팅하는 것이 아니라, 두번째 디스크의 미러볼륨을 통해서 부팅을 하게 된다.

위의 사항들을 잘 이해했다면 한가지 의문이 생길 것이다. Boot.ini 파일이 위치해 있는 곳이 C: 였는데, 디스크0번이 손상된 상태에서 이 파일에 접근을 못하는 것이 아닌가? 맞다. 그렇게 된다. 그래서 미러볼륨으로부터 시스템을 부팅시키기 위해서 ‘부팅 디스켓’을 생성해야 한다. 부팅 디스켓 생성에 대해서는 이번장의 후반부에서 소개되는 “부팅 디스켓 만들기”를 참고한다.

<그림11-31>은 작업을 마치고, 시스템이 미러볼륨을 구성하는 과정을 캡처한 화면이다. 64%라고 진도를 보여주는데, 이 과정에서 원본볼륨이 완전하게 미러볼륨으로 복제가 일어난다.

미러볼륨이 완성되었다. 디스크 1에도 5GB크기의 C:가 생겼다. 윈도우탐색기를 통해서 들여다 보면 단지 C: 로만 보일 뿐이다. 하지만 C:에 새로운 데이터를 저장하면 그때는 실제로는 두 개의 디스크에 동시에 데이터가 쓰여지게 된다. 디스크0번이 망가지더라도 걱정이 없다. 완전한 복제본인 디스크1이 있으니까.

더 이상 미러볼륨을 원하지 않는다면 미러볼륨을 해제하는 작업으로서 간단히 관계를 끊을 수 있다.

이것은 데이터 손실이 발생하지 않는 작업이다. 다만 미러가 제거되었으므로 더 이상 복제가 일어나지 않을 뿐이다. 독립적인 2개의 볼륨이 되는 것이다.

11-3-1-8. RAID-5 볼륨 (Stripe Set with Parity)

RAID-5볼륨은 스트라이프 볼륨의 연장선이라고 할 수 있다. 앞에서 스트라이프 볼륨의 장점은 디스크 입/출력 성능의 향상을 가져온다고 했는데, 하드 디스크의 물리적인 오류에 민감하다는 제약이 따른다고 했다. 그것을 해결하기 위해서 패리티(Parity)라고 부르는 특별한 비트를 디스크에 저장하게 되었다. 스트라이프 볼륨의 장점을 살리면서 디스크의 오류까지도 해결하겠다는 것이다. <그림11-34>을 보면서 설명한다.

<그림11-34>의 예제에서는 3개의 디스크로 구성된 RAID-5 볼륨을 보여준다. 디스크 3개를 평행하게 배열하고 이들은 각각 64KB 단위씩 스트라이핑이 구성된다. 스트라이프1부터 시작해서 데이터를 기록해 나가는데, 3개의 디스크에 모두 데이터가 기록되는 것이 아니라 2개의 디스크에만 데이터가 기록되고 나머지 하나의 디스크 공간에는 2개의 디스크의 데이터를 계산한 값이 기록된다. 이 값을 가리켜서 Parity라고 부른다. 이때 계산방식으로는 Xor연산[1]이 사용된다. 계산방법이 중요한 것이 아니라 이것을 이해하는 것이 중요하다.

위의 예제에서 RAID-5 볼륨을 구성하고 처음 데이터를 기록한다고 가정을 해 보자. 그때 데이터는 디스크1의 처음 스트라이프1에 기록되고, 다음에 디스크2의 스트라이프2에 기록된다. 디스크0에는 디스크1과 디스크2의 데이터를 Xor연산을 통하여 계산된 값. Parity 비트를 기록하는 것이다. 두번째 스트라이프에서는 디스크0과 디스크2에 데이터를 기록하고 디스크1에는 패리티, 세번째는 디스크0과 디스크1에 데이터를 기록하고 디스크2에 패리티, 이런 방식으로 디스크를 기록해 나간다.

그렇다면 어떻게 되는가? 디스크가 3개이지만 실제로 1/3에 해당하는 하나의 디스크 공간만큼은 데이터가 기록되지 않기 때문에 디스크 낭비라는 생각이 들 수도 있을 것이다. 하지만 하드디스크의 물리적인 오류가 생겼을 때 이 문제를 RAID-5 볼륨은 해결할 수 있다. 3개의 디스크중 하나에 결함이 발생하더라도 다시 원본데이터를 계산해 내는 것이 가능하기 때문이다. 어떻게? 위의 예제에서 디스크1번이 손상되었다고 가정했을 때 관리자가 할 일은 새 하드디스크를 넣고 “RAID-5 볼륨 재구성”이라는 메뉴만 관리도구에서 돌려주면 시스템은 원본 데이터를 복구해 내게 된다. 이때의 방법은 처음 데이터를 기록할 때와 차이가 없다. 순수한 데이터만이 아닌 데이터를 기준으로 특별한 원칙하에 패리티 비트가 기록되어 있기 때문에 가능한 것이다.

스트라이프 볼륨이 3개의 디스크에 전체를 데이터만 기록했던 것과 비교해서 디스크 낭비, 상대적인 쓰기 성능의 저하 등을 가져올 수는 있지만 서버에서는 무엇보다 데이터를 보호하기 위한 방법으로서 RAID-5가 사용될 수 있다. 디스크 입/출력의 성능을 요구하는 DB서버, 파일서버 등의 서버를 구축할 때 최상의 솔루션을 제공할 수 있을 것이다.

필자가 캡처한 예제를 통하여 구현과정을 살펴보자.

예제에서는 디스크3개를 가진 시스템을 보여준다. 이미 C:는 미러볼륨으로 구성되어 있고, 디스크0,1,2 에는 각각 916MB, 32GB, 18GB의 남은 공간이 있다. 이 디스크들로써 RAID-5 볼륨을 구현할 때 만들수 있는 최대크기는 얼마나 될까? 스트라이프의 동작원리를 이해하면 정답이 나온다. 스트라이프 볼륨을 구성할 때는 디스크의 각 볼륨이 동일한 크기로 구성이 되어야 한다. 당연히 위의 상황에서는 가장 작은 크기에 맞춰질 수밖에 없을 것이다. 그래서 916MB*3=2,748MB가 구현할 수 있는 최대사이즈가 된다. 하지만 이것도 전체사이즈가 되지는 않는다. 실제로 데이터가 들어갈 수 있는 공간은 패리티가 차지할 공간을 제외한 2/3이 된다. 즉 916MB*2=1,832MB가 데이터가 된다. 

<그림11-35. RAID-5 볼륨 구현과정 1>	할당되지 않은 빈 공간을 마우스 오른쪽 클릭하고 ‘볼륨 만들기’를 선택한다.
<그림11-36. RAID-5 볼륨 구현과정 2>
<그림11-37. RAID-5 볼륨 구현과정 3>	RAID-5 볼륨도 활성화 된 것이 보인다. 물리적인 디스크가 3개 이상이므로 활성화되는 것이다. RAID-5 볼륨을 선택하고 [다음]을 누른다.
<그림11-38. RAID-5 볼륨 구현과정 4>	‘디스크 선택’화면에서 왼쪽의 ‘사용 가능한 모든 동적 디스크’에서 디스크0,1,2를 선택하여 [추가>>]버튼을 눌러서 선택되도록 하고, 아래쪽에 크기를 결정해 주어야 한다. 3개의 디스크는 동일한 크기로만 구성될 수가 있다. <그림11-38>의 예제에서는 900MB를 선택했다. ‘총 볼륨 크기’가 1800MB만 나타내고 있는 것을 주목한다. 900MB*3=2700MB이지만 1/3인 900MB는 패리티 비트가 차지할 공간이므로 크기에 포함되지 않은 것이다. 최대크기는 916MB임을 보여 주는데, RAID-5 볼륨을 구성하는 디스크중에서 가장 작은 여유공간에 맞춰서 만들수 있음을 보여준다.
<그림11-39. RAID-5 볼륨 구현과정 5>	나머지 과정은 다른 볼륨 생성과 차이가 없다. 드라이브 문자열을 할당하거나 폴더에 볼륨을 마운트 시킬 수 있다.
<그림11-40. RAID-5 볼륨 구현과정 6>	기본적으로 NTFS 파일시스템으로 포맷하도록 선택되어 있다. 서버에서 NTFS를 사용한다는 것은 기본적인 일이다. 그대로 [다음]을 클릭한다.
<그림11-41. RAID-5 볼륨 구현과정 7>	거의 모든 작업을 할 때마다 항상 마지막에서는 당신이 선택했던 작업들을 요약해서 보여주는 화면이 나온다. 한번쯤 들여다 보라. 실수를 막을수 있을 것이다.

이제 마법사를 마쳤다. <그림11-42>에서는 RAID-5 볼륨으로 구성된 E: 가 생성되고 있는 것을 보여준다. 29%가 진행중이라는 과정을 볼 수 있다.

더 이상 RAID-5 볼륨을 사용하지 않으려면 볼륨을 삭제하면 되는데, 주의할 점은 볼륨을 삭제하면 데이터는 날아간다는 것이다. 전체 데이터를 안전하게 백업을 받은 후 볼륨을 삭제해야 할 것이다. 같은 관리도구를 사용하여 볼륨을 제거할 수 있다<그림11-43>.

우리는 컴퓨터를 처음 사면 디스크를 ‘파티셔닝’작업을 통해서 나누고 데이터를 기록하기 위한 공간을 만들기 위해 ‘포맷’이라는 작업을 한다. 어떤 방식으로 포맷을 하느냐에 따라서 지원되는 기능이 달라지기도 하는데, 마이크로소프트는 FAT(File Allocation Table)과 NTFS(NT File System)을 지원한다.

FAT는 FAT16이 기본적으로 사용되었었고, Windows 95 OSR2 버전부터 지원하기 시작한 대용량 파일시스템을 지원하는 FAT32를 통하여 기능이 강화되었다. 그것과는 별개로 NT버전의 경우는 NTFS라는 NT만의 파일시스템을 지원한다. NTFS역시 NT4.0에서 사용되던 NTFS v.4 가 있고, Windows 2000에서부터 지원되는 NTFS v.5 가 있다.

결론부터 말하자면 NT기반의 서버제품을 사용하고자 할때는 필수적으로 NTFS파일시스템을 채택해야 한다는 것이다. NTFS를 사용하지 않고서는 ‘보안’이라는 요건을 충족시키기가 어렵다. 시스템의 안전을 고려한다면 반드시 NTFS파일시스템이 필요하다고 할 것이다. 또한 Active Directory, RIS(원격 설치 서비스)등이나 일부 어플리케이션 등은 설치시 NTFS파티션을 요구하는 경우도 있다. 그만큼 NTFS의 필요성을 강조하는 것이다. NTFS v.4에 비하여 NTFS v.5에서는 디스크할당량으로 사용자별 디스크 공간제한, EFS (암호화 파일 시스템; Encryption File System) 등의 향상된 기능을 지원한다.

윈도우탐색기를 열고 드라이브 문자열(C:, D:, E: 등)을 마우스 오른쪽 클릭하고 등록정보를 열면 파일시스템을 확인할 수 있다. 또한 ‘컴퓨터 관리’도구의 ‘저장소à디스크관리’를 클릭하면 확인이 가능하다<그림11-7>

FAT파일시스템으로 OS를 셋업한 후 NTFS로 전환하려면 CONVERT 명령어를 사용할 수 있다<그림11-8>

Convert /? 를 이용하면 사용법에 대해서 보여준다. 예제에서는 “convert g: /fs:ntfs”라는 명령을 이용하여 g: 를 NTFS 파일시스템으로 변환하였다. 현재 OS가 사용하는 시스템파티션(보통 C:) 이나 부트파티션(OS가 설치된 파티션=winnt폴더가 있는 파티션)의 경우는 “단독 엑세스 권한이 없기 때문에 즉시 변환이 되지 않고, 부팅시 변환할거냐”는 메시지를 보여준다. 그렇게 하면 재부팅시 파일시스템이 변환되는 것을 확인할 수 있다. C:와 D: 2개의 파일시스템을 FAT에서 NTFS로 변환하고자 한다면 가급적 한번에 하나씩 수행할 것을 권한다. 동시에 여러 개의 변환작업을 하고나서 시스템이 부팅이 되지 않는 것을 종종 보았다.

시스템 사양, 어플리케이션 호환성 등의 이유로 아직 많은 기업에 Windows 9x이 남아있긴 하지만 지금은 클라이언트PC의 OS도 Windows 2000, Windows XP등 NT계열 시스템들이 주종을 이루고 있다. OS에 따라 클라이언트용, 서버용 등을 구분하기는 하지만 클라이언트용이라고 하더라도 네트워크는 반드시 필요하며 상당부분 서버의 역할도 수행할 수 있는 기능을 가지고 있다.

네트워크 환경에서 많은 사람들이 정보를 공유하고, 서로간의 하드디스크, 프린터 등의 자원을 공유하기 위한 방법인 네트워킹이 빠르고 안정적으로 동작하는 것은 요즈음의 OS가 가져야할 기본적인 사항이다.

여기에서 한가지 생각해야 할 일이 있다. 이렇듯 네트워크에서 컴퓨터가 자원을 공유하는 용도로 사용이 된다면 "보안"이라는 단어를 떠올리지 않을 수 없다. 적법한 사용자에게 최선의 서비스를 제공할 수 있어야 하지만, 그렇지 못한 사용자에게는 접근을 거부하게 하는 조치를 취해야만 안정적인 시스템운영을 할 수 있을 것이기 때문이다. NT는 이러한 기능을 제공하기 위해서 자신의 자원에 접근하게 할 사용자들을 생성하고, 이들의 리스트를 유지한다. 이 리스트를 가리켜서 디렉토리(directory)라고 부르며 이 디렉토리를 저장하는 공간을 디렉토리 데이터베이스라고 부른다. 그리고 디렉토리 데이터베이스에 저장되는 하나 하나의 개체(object)를 가리켜 계정(Account)이라고 부르는 것이다. 예를 들면 사용자 계정, 컴퓨터 계정 등이 그것이다. 한 컴퓨터에 앉은 누군가가 서버에 있는 파일에 접근을 하고자 한다면, 그 컴퓨터를 사용하는 사용자계정이 서버의 디렉토리 데이터베이스에 존재해야 접근할 수 있게 된다는 것을 의미한다.

네트워크에서 누군가가 서버에 연결을 하고자 할 때 사용자 계정을 사용하게 되는데 이때 접근하는 사용자가 관리자가 생성해 준 진짜사용자가 맞는지를 판단하는 방법으로 ‘암호’라는 것을 사용한다. 이렇게 서버가 특정 사용자에 대해 진짜 사용자가 맞다고 판단해 주는 것을 인증(Authentication)이라고 한다. 네트워크에서 컴퓨터 대 컴퓨터 간의 통신에서는 그 컴퓨터를 쓰는 사람은 뒷전에 있기 마련이다. 그러므로 설사 회사의 직원이 아니라도 제3자가 직원의 사용자 계정을 도용하여 제시하고 올바른 암호만 사용한다면 믿을 수 밖에 없는 노릇인만큼 암호에만 의존하는 대부분의 현재 상태에서 네트워크 보안에는 다소 아쉬움이 남는 것이 현실이다. 그런 이유로 보안이 보다 중요시되는 곳에서는 단순히 암호만 사용하는 것이 아니라 스마트카드, 지문인식시스템 등의 추가적인 보안인증을 구현하고 있다.

윈도우 서버를 관리할 대부분의 관리도구는 “컴퓨터 관리”도구에 포함되어 있다. <그림11-1>

얼핏 살펴봐도 상당히 많은 관리메뉴가 보인다는 것을 알 수 있다. 이 ‘컴퓨터관리’라는 이름의 관리도구는 여러 개의 관리메뉴가 통합된 환경을 제공한다. 공유폴더, 사용자, 그룹, 이벤트, 성능, 경고, 디스크관리 등의 기본적인 관리업무를 수행하고자 할 때 당신은 이 관리도구를 사용하게 될 것이다.

계정을 추가하는 작업을 해 보자. ‘컴퓨터 관리’ 관리콘솔의 왼쪽패널에서 ‘로컬 사용자 및 그룹’을 확장하면 ‘사용자’와 ‘그룹’이라는 두개의 메뉴를 확인할 수 있다<그림11-2>

사용자를 클릭하면 오른쪽 패널에서 기본적으로 생성되어 있는 사용자 계정(Built-in User Account)들을 확인할 수 있다. Administrator라는 계정이 보인다. 이 계정이 마이크로소프트의 윈도우 서버에서 사용되는 마스터계정이다. Unix에 root, Netware에 supervisor가 있다면 윈도우에는 Administrator가 있다. 위에서 설명했듯이 누구든지 올바른 암호만 제시한다면 여러분의 시스템은 제3자를 당신. 즉 관리자로 판단하고 모든 것을 허용하고 말것이다. 일반 계정도 마찬가지지만 특히 관리자계정에 복잡한 암호를 사용해야 하는 것은 당연한 사실이다. 대문자, 소문자, 특수문자, 숫자 등을 포함하여 12자리 이상의 보다 강력한 암호를 할당할 필요가 있다. 그것도 완전하지는 않다. 최소한 45일정도마다 한차례씩 암호를 변경해 주어야 할 것이다. 또, Administrator계정을 클릭하고 마우스 오른쪽 버튼을 이용하여 ‘이름 바꾸기’를 선택한 다음 계정의 이름을 변경하라. Administrator를 그대로 사용하는 것은 의도하지 않은 사용자에게 시스템의 마스터계정을 그대로 드러내 주는 일밖에 되지 않는다.

Guest 계정도 보이는데, 기본적으로 이 계정은 비활성화되어 있다. 가급적이면 활성화시키지 말것을 권장한다. 기본적으로 Guest계정의 암호는 공백의 문자로 설정되어 있다. 이 계정을 활성화시키면 디렉터리 데이터베이스에 계정을 가지고 있지 않을 사용자까지도 서버에 접근이 가능해 진다. 다수의 사용자가 파일서버에 접근하도록 허용하기 위해서 Guest계정을 열어놓는 경우가 있지만 보안상 좋지 않다. 혹 실수로 Guest계정이 활성화되는 경우를 대비해서 Guest계정에 복잡한 암호를 설정하는 것도 좋은 방법이다. 나중에 기억이 안 나면 어쩔꺼냐구? 당신은 관리자 아닌가!

‘사용자’에서 마우스 오른쪽 클릭하여 ‘새 사용자’를 선택한다. <그림11-3>의 사용자 계정을 생성하는 화면이 열린다.

‘사용자이름’항목이 바로 사용자계정에 해당한다. 이 계정으로 사용자는 해당 시스템에 로그온을 하고 네트워크에서 이 계정을 이용해서 계정이 생성되어 있는 컴퓨터에 원격으로 접근하는 것이 가능해 진다. 전체이름은 계정에 대한 구체적인 이름을 기록해 놓는다. 계정만으로는 어떤 사용자인지 판단이 어렵기 때문에 관리적인 측면을 고려한 것이다.

아래부분에 ‘다음 로그온할 때 반드시 암호 변경’옵션이 기본으로 체크되어 있음을 확인한다. 이 옵션이 체크되어 있으면 계정이 생성되고 해당 사용자가 처음으로 이 컴퓨터에서 직접 로그온을 할 때 암호를 바꿀 것을 디렉터리 서비스로부터 요구받게 된다. 처음 로그온할 때 암호를 변경하면서 로그온을 성공적으로 하고 나면 이 체크박스는 자동적으로 해제된다. 사용자로 하여금 자신의 암호는 자신이 직접 생성하도록 할 수 있는 좋은 옵션이다. 그 이후에는 관리자라고 하더라도 사용자의 암호를 알 수는 없다. 다만 관리자는 언제든지 관리도구를 통해서 사용자의 암호를 변경할 수 있기 때문에 암호를 관리할 수 있을 뿐이다.

‘로컬 사용자 및 그룹’중에서 ‘그룹’을 클릭해 본다. <그림11-4>

그룹에도 기본적으로 생성된 여러가지 계정(Built-in Group Account)들이 보인다. 이 그룹은 사용자들을 조직하여 보다 원활한 관리를 도와준다. 중요한 것은 관리자가 사용자 계정을 생성하거나, 백업담당자가 백업을 하거나, 사용자들이 로그온을 할 수 있다거나 하는 것들에 대한 권한(User rights)은 사용자계정 단위가 아니라 그룹계정에게 할당되어 있다는 것이다. 예를 들어 Administrators는 관리자그룹인데, 이 Administrators 그룹은 관리자로서 할 수 있는 모든 작업들이 부여되어 있다. 그리고 그룹의 멤버는 그룹이 가진 권한을 그대로 상속받게 된다. 그렇다면 새로운 사용자를 만들고서 그 사용자를 Administrators 그룹의 멤버로 구성을 한다면? 그 새로운 사용자도 관리자가 된다는 것을 의미한다.

시스템에 주어진 권한은 “시작à관리도구à로컬 보안 정책”을 열고, “로컬정책à사용자 권한 할당”을 열어보면 오른쪽 패널에서 확인할 수 있다. 수 많은 정책들이 시스템에서 특별한 작업을 할 수 있는 권한의 목록과 이 권한이 부여된 사용자와 그룹을 보여준다. 물론 이 인터페이스를 통해서 권한설정을 할 수도 있다. 홍길동이라는 사용자에게 시스템 백업의 권한을 준다거나 하는 것을 말한다.

<그림11-4>에서 이번에는 ‘그룹’을 마우스 오른쪽 클릭하여 ‘새 그룹’을 연다. <그림11-6> 그룹이름이 ‘그룹 계정’에 해당한다. 예제에서는 SysManagers라고 입력했다. 그룹을 생성한 목적이나 이 그룹의 멤버쉽등에 대한 정보를 ‘설명’에 기록해 두고(필수사항은 아니다.) 이 그룹의 구성원을 추가해 준다. 당연히 사용자 계정은 먼저 생성이 되어 있어야 한다.

처음 그룹계정을 생성할 때 사용자계정을 추가할 수 있고, 나중에 같은 관리도구를 이용하여 새롭게 사용자를 추가할 수도 있다.

이번 장에서는 Windows Server 2000과 2003을 기준으로 관리업무에 필요한 몇가지 사항들에 대해 정리해 본다. Windows Server 2000 & 2003은 Windows NT계열의 제품군에 속한다. NT라는 OS는 기본적으로 Windows 95,98등의 9x계열에 비해서 여러가지 측면에서 다르다. 가장 큰 차이점이라면 네트워킹이라는 측면에서 차이점을 찾을 수 있을 것인데, 그러다 보니 네트워크 환경에서 시스템을 사용하기 위해서 필요한 몇 가지 기능들이 필수적으로 제공된다. 윈도우 서버를 단순히 사용자 입장에서 워드 프로그램을 실행한다거나 하는 데스크탑의 용도에 대해서는 따로 다루지 않을 것이다. 수 많은 기능중에서도 네트워크를 위해서 사용될 서버로서의 측면에서 알고 넘어가야 할 기능에 대해서 공부해 보자.

Active Directory에 대해 컨설팅과 강의를 하면서 Active Directory를 도입하려는 기업들과 수강생들의 고민과 관리상의 현실적인 어려움들을 반영하려고 노력했지만 턱없이 부족하다. 이번 장을 통해서 기능적인 측면보다는 Active Directory 구축과 관련하여 전체적인 흐름을 이해하고 감을 잡았으면 하는 바램이다. 이글을 읽은 독자가 도메인 환경 구축을 하기 위해 어떻게 접근해야 할 것인지 전혀 감이 오지 않는다면 필자의 부족함 때문일 것이다. 하지만 ‘한번 해 봐야겠다’는 생각을 가지는 독자가 있었으면 좋겠다. 회사에서 Active Directory를 도입하면서 어려운점, 잘 안풀리는 부분, 도입을 완료한 후 관리상 문제점들, 이러한 사항들은 필자와 함께 고민해 보았으면 한다. 다른 페이지도 마찬가지겠지만 도메인 구축에 관련된 이번 장은 계속 업데이트 될 것이다. 거기에 여러분들의 회사환경을 추가하여 조금씩 완성도가 높아지는 모습이었으면 하는 것이 필자의 욕심이다.

14-2-8. 사용자들을 도메인으로 로그온하도록 구성

도메인이 생성되었으면 사용자들이 도메인으로 로그온을 할 수 있도록 모든 컴퓨터들의 설정을 바꿔줘야 한다. 사용자들의 시스템을 새롭게 설치하면서 도메인으로 참여하도록 구성할 수도 있다. 설치와는 별도로 사용자들의 시스템을 어떻게 도메인에 참여시켜서 도메인으로 로그온 할 수 있도록 구성할 것인지 접근해 보자.

사용자들이 어떠한 OS를 사용하는지에 따라 다르다. Windows XP는 그 설정에 있어서 Windows 2000 과 동일하다. 하지만 Windows 9x 계열의 OS는 조금 다르다. Windows 9x 계열의 OS는 기업네트워킹 환경에서는 사용할만하지 않다고 생각한다. Active Directory를 구축하는 많은 기업들이 Windows 9x의 경우 Active Directory에 포함하지 않고 있다. 도메인에 참여시켜서 얻을 수 있는 특별한 장점이 없다는 이유에서이다. 장점보다는 보안을 고려한다면 단점이 더 많다고도 볼 수 있다. 하지만 Windows 9x도 도메인에 참여시키는 방법을 잠깐 다루어보도록 하겠다.

먼저 총 4대의 서버중 2대를 도메인 컨트롤러로 구성하였고, 나머지 2대의 서버 역시 도메인으로 합류시켜야 한다. 이것은 클라이언트의 설정과 다를바가 없다.

14-2-8-1. 멤버서버 구성 (Windows 2000, 2003, NT, XP)

‘멤버서버’라는 용어는 도메인 컨트롤러는 아니지만 도메인에 멤버로 참여한 서버를 지칭한다. ‘독립실행형 서버’로 설치된 컴퓨터가 멤버서버가 됨으로써 도메인의 Active Directory에 접근이 가능하고, Active Directory의 사용자계정이나 그룹계정들에게 자신의 공유폴더, 공유프린터 등의 자원을 사용할 수 있도록 권한설정을 할 수 있는 환경이 갖춰진다. 그렇지 않으면 도메인을 구축한다는 것이 무의미해 질 것이다.

서버차원이 아니라 클라이언트 입장에서는 도메인에서 도메인 컨트롤러에 생성된 자신의 계정으로 네트워크에 로그온을 할 수 있어야 한다. 그래야만 도메인의 계정정보를 통해서 여러 서버에 접근이 가능해 지기 때문이다. 그러기 위해서는 먼저 클라이언트가 사용하는 컴퓨터는 도메인의 멤버가 되어야 한다.

IT관리자 입장에서는 사용자계정은 Active Directory에 생성을 했고, 그룹정책에서는 다양한 설정을 구성해 두었지만 관리대상인 컴퓨터가 도메인에 가입하지 않는다면 무용지물이다. 그런 이유로 Active Directory 인프라가 구축되는 과정은 ŒActive Directory서버구축 계정관리 Ž클라이언트의 도메인 참여를 포함한다.

도메인에 참여하고자 하는 모든 클라이언트 컴퓨터는 내부DNS서버(정확히 말하면 Active Directory의정보를 담고 있는 DNS서버, 일반적으로는 Active Directory서버)의 IP Address를 사용하도록 TCP/IP설정이 되어야 한다. DHCP를 사용하고 있다면 DHCP서버에서는 사용자들이 내부DNS서버를 사용할 수 있도록 옵션을 구성해 준다.

<그림14-70. 멤버 서버 설정 1>	예제의 화면은 Windows XP Professional에서 접근한 것이다. 바탕화면의 ‘내 컴퓨터’를 마우스 오른쪽 클릭하여 ‘등록정보’로 접근하였다. 제어판의 ‘시스템’을 열어도 같은 화면이다. 전체 컴퓨터이름이 raincoat 로 되어 있고 workgroup이라는 작업그룹에 속해 있다. 도메인으로 가입시키기 위해 [변경]을 누른다.
<그림14-71. 멤버 서버 설정 2>	소속그룹 항목에서 ‘도메인’을 선택하고 도메인 이름인 windowsnetwork.msft 을 입력한다. 이 컴퓨터를 도메인에 가입시킬 권한이 이는 사용자의 이름과 암호를 묻는다. 정보를 입력해 주면 잠시후 화면과 같이 ‘Windowsnetwork.msft 도메인 시작’이라는 메시지가 나온다. 이제 raincoat 는 도메인에 가입되었고 시스템을 재시작하면 도메인 로그온이 가능한 변경된 로그온 화면을 만나게 될 것이다. (만일 도메인이 없거나 연결할 수 없다는 에러메시지를 만난다면 DNS서버를 확인해야 한다. DNS서버에 도메인 컨트롤러의 SRV레코드와 A레코드가 등록되어 있지 않다면, 혹은 사용자의 컴퓨터가 엉뚱한 DNS서버를 사용하고 있다면 도메인으로의 변경작업을 진행될 수 없다.
<그림14-72. 멤버 서버 설정 3>	Active Directory를 확인하면 도메인에 참여하는 컴퓨터의 기본컨테이너에 해당하는 Computers에서 raincoat의 정보를 찾을 수 있다. 드래그앤드롭을 이용하여 윈도우네트웍스/임직원/컴퓨터OU로 개체를 이동시켰다.
<그림14-73. 멤버 서버 설정 4>	간혹 멤버로 구성작업이 완료되고 나서도 사용자 컴퓨터의 정보가 DNS서버에 동적업데이트가 되지 않는 경우가 있는데, 그 때는 DNS서버가 문제가 없다면 클라이언트 컴퓨터에서 <그림14-73>과 같이 ‘도메인 구성원 자격이 변경되면 주DNS접미사 변경’옵션이 선택되어 있는지를 확인한다.
기본적으로 독립실행형 서버는 FQDN을 사용하지 않는다. Raincoat 등과 같은 평면적인 이름을 사용하고 있는데, 도메인의 멤버로 참여하게 되면 자동적으로 도메인의 이름을 주DNS접미사로 사용하도록 구성된다. 그래서 전체이름이 raincoat.windowsnetwork.msft 의 형태가 되는 것이다. 그러면 이 정보는 DNS서버의 windowsnetwork.msft 영역에 업데이트가 되게 되는데, 만일 위의 체크상자가 해제되어 있다면 예전이름 형태로만 남아 있게 되고 DNS서버에서는 raincoat의 정보를 찾을 수 없다.
<그림14-74. 멤버 서버 설정 5>	DNS관리콘솔을 통해서 Bluepro 의 정보가 DNS에 업데이트 된 것을 확인해 보았다.
위의 작업이 완료되면 이 컴퓨터는 도메인의 사용자계정으로 로그온 할 수 있다. 하지만 사용자가 도메인의 사용자 계정으로 자신의 컴퓨터에서 로그온을 하고 나서는 자신의 컴퓨터에서 할 수 있는 작업이 그리 많지 않다는 것을 알고 의아해 할 것이다. 그것은 도메인의 사용자계정이 자신의 컴퓨터에서 가지는 지위가 ‘일반 사용자’에 해당하기 때문이다. <그림14-75. 클라이언트 도메인 참여후 로컬 그룹멤버쉽 수정>

클라이언트 PC의 컴퓨터 관리도구를 이용하여 로컬 Admininstrators 또는 Power Users 그룹에 도메인의 사용자 계정을 추가해 주어야 한다. 만일 Power Users그룹의 멤버로 추가하였다면 사용자는 자신의 컴퓨터에서 로컬 Administrators 그룹을 관리하는 작업, 가입한 도메인에 탈퇴 등을 제외한 대부분의 작업을 할 수 있게 된다. Administrators 그룹에 추가하였다면? 두말할 필요가 없다. 말 그대로 도메인의 사용자 계정은 클라이언트PC에서 로그온하여 관리자로 취급된다.

이상으로 도메인 참여작업을 진행해 보았다. 도메인으로 가입하는 과정에서 도메인 참여, AD에서 개체의 이동, 로컬 그룹멤버쉽 수정 등 몇가지 작업이 진행됨을 알 수 있다. 많은 수의 PC에 대해 동일한 작업을 수행해야 하는 관리자로서는 부담스러울 수 밖에 없다. 더불어 한가지 고려할 사항이 있다. 사용자가 도메인에 가입하기 전 사용하던 프로파일 (바탕화면, 즐겨찾기, 단축아이콘, 환경변수, 내문서의 위치, Outlook 설정 등)이 있었을 텐데, 도메인에 가입하고 도메인의 계정으로 로그온을 하면 새로운 사용자의 프로파일이 생성되는 만큼 사용자에게는 당연히 약간의(?) 거부감과 불편함이 따르게 됨이 일반적이다. 그런 이유로 Active Directory인프라를 구축하는 많은 기업들은 클라이언트 컴퓨터를 도메인에 참여시키기 위해 써드파티 ‘도메인 이행 전용도구’를 이용하여 작업을 진행하고 있다. 이들 도메인 이행 도구들은 도메인 참여, 관리자가 희망하는 OU에 컴퓨터 개체 생성, 로컬 그룹멤버쉽 자동설정, 사용자의 기존 프로파일을 도메인 계정으로 마이그레이션 등의 클라이언트PC를 도메인에 참여시키면서 필요한 서버측과 클라이언트측의 이행관련 업무 자동화를 지원하고 있다.

14-2-9. Windows 9x – 도메인으로 로그온하도록 구성

Windows 9x에서 도메인으로 로그온을 하도록 구성해 보자.

<그림14-76. Windows 9x 계열 컴퓨터 구성 1>	<그림14-76>은 Windows ME에서의 로그온 화면이다. 예제에서는 blue라는 계정으로서 로그온을 하고 있다. Windows 9x OS에서는 로그온이 필수적인 것은 아니다. [취소]버튼을 누르면 로그온 하지 않고도 시스템의 바탕화면으로 접근하는 것이 가능하다. 하지만 그렇게 했을 경우에는 클라이언트 서비스(workstation Service)가 시작되지 않기 때문에 네트워크 상에 자원에 접근하는 작업은 할 수 없게 된다. Windows NT 기반의 시스템을 사용하기 위해서는 반드시 로그온을 해야 하는 것에 비하면 커다란 차이점이다.
<그림14-77. Windows 9x 계열 컴퓨터 구성 2>	바탕화면의 네트워크 환경을 마우스 오른쪽 클릭하여 등록정보로 접근한다. 바탕화면에 네트워크 환경 아이콘이 나오지 않는다면 제어판의 네트워크 아이콘을 눌러서 접근할 수도 있다. 등록정보를 열면 <그림14-77>의 화면이 열린다. 설치된 네트워크 구성요소 창에서 'Microsoft 네트워크 클라이언트'를 확인한다. 만일 보이지 않는다면 [추가]버튼을 이용하여 설치를 해야 한다.   Microsoft 네트워크 클라이언트를 클릭하고 [등록정보]를 누른다.
<그림14-78. Windows 9x 계열 컴퓨터 구성 3>	클라이언트 등록정보 창이 열렸다. '로그온 확인'항목이 있고, 기본적으로는 'Windows NT 도메인으로 로그온'항목의 체크상자가 비워져 있다. 체크를 하고 아래쪽의 Windows NT 도메인 란에 도메인의 NetBIOS 이름을 입력한다.
<그림14-79. Windows 9x 계열 컴퓨터 구성 4>	시스템을 재시작하고 나면 <그림14-79>와 같은 로그온 화면을 볼 수가 있다. 사용자 이름과 암호 뿐만 아니라 '도메인'명을 입력할 수 있는 박스가 추가되었다. Windows 9x계열에서의 도메인 이름 입력상자는 Edit Box이다. 기본적으로는 위에서 입력한 도메인명이 나오지만 다른 이름으로 수정도 가능하다는 것을 의미한다.

이 책에서 Windows 9x의 설정에 대해서는 거의 다루지 않았다. 만일 회사에서 Windows 9x OS를 도메인 환경에서 사용해야 하는 경우라면 필자의 홈페이지 (http://www.secure.pe.kr ‘강의실’의 기타 섹션에서 ‘도메인환경에서 Windows 9x 클라이언트 관리’) 를 참고하라.

14-3. 도메인 환경에서의 서버

독립실행형 서버로 설치된 컴퓨터가 멤버서버로서 도메인에 참여하고 나면 어떤 것이 바뀌었을까? 가장 큰 차이점은 Active Directory로의 접근이 가능해 졌다는데 있다. 이들 서버들도 도메인 컨트롤러는 아니지만 분명히 자신의 디렉터리 데이터베이스를 가지고 있다. 이것을 특별히 ‘로컬 디렉터리 데이터베이스’라고 부른다. 도메인컨트롤러의 그것을 ‘글로벌 디렉터리 데이터베이스’라고 구분한다면 차이점을 이해할 수 있을 것이다.

도메인의 도메인 컨트롤러가 가지는 디렉터리 데이터베이스의 사용범위는 도메인내의 어떠한 서버라도 사용이 가능하지만, 도메인의 멤버서버가 가지는 디렉터리 데이터베이스의 사용범위는 오직 자신의 서버에서만 사용이 가능하다. 이렇듯 ‘로컬’이라는 용어는 항상 제한적으로 사용된다.

도메인에 참여한 서버는 네트워크에서 파일, 프린트 서버, 데이터베이스 서버, 메일서버 등 여러가지 용도로 사용된다. 중요한 것은 더 이상 이들 서버에서는 로컬 사용자 계정을 만들지 말아야 한다는 것이다. 도메인의 A라는 사용자에게 프린팅을 할 수 있는 권한을 주기 위해 ‘컴퓨터 관리’도구를 열고 자신의 로컬 디렉터리 데이터베이스에 A라는 사용자 계정을 생성할 것이 아니라 도메인의 Active Directory에 접근하여 A라는 사용자를 찾아서 자신의 자원을 쓸 수 있게 권한만 주면 된다. 물론 이것은 한가지 예제일 뿐이다. 실제로 서버의 자원에 권한설정을 할때는 사용자 단위보다는 그룹 단위로 권한설정을 하는 것이 좋다.

이렇듯 계정관리는 중앙에서 집중적으로 (도메인 컨트롤러에서만) 이루어져야만 제대로 된 도메인 모델을 유지하는 것이 가능하다.

14-4. 도메인 환경에서의 클라이언트

클라이언트들은 Windows 9x계열 (95,98,ME)인지 아니면 Windows NT계열(NT, 2000, XP)인지에 따라서 환경이 달라진다. 하지만 그러한 기본적인 물리적인 문제보다도 현실에서 가장 관건이 되는 부분은 클라이언트 컴퓨터의 관리주체가 시스템 관리자인지, 아니면 컴퓨터 사용자인지의 문제이다. 관리자 입장에서 시스템을 잘 관리할 수 있는 가장 좋은 방법은 사용자들에게 최소한의 권한만 부여하는 것이다. 사용자들이 자신의 컴퓨터에서 제어판에 접근하지 못하도록 제한하는 것만으로도 네트워크에, 그리고 사용자 컴퓨터에 있어서 상당부분의 문제점을 줄여줄 수 있다. 이를테면, 사용자 임의로 소프트웨어를 설치한다거나, 웹브라우저의 보안설정을 임의로 바꾸거나, IP Address 설정을 바꿔서 통신상의 문제점을 일으킨다거나 하는 문제는 원론적으로 통제할 수 있다.

하지만 현실적으로 사용자들의 요구는 너무나 다양하며 또한 그들은 이미 시스템에 대해서 상당한 지식을 가진 사용자도 많기 때문에 위와 같이 구성을 한다면 거부반응이 만만치 않을 것이다. 회사가 정책적으로 회사에서는 사용자들이 임의로 아무런 소프트웨어도 추가할 수 없으며 오직 업무를 위해서만 컴퓨터를 사용하도록 완전한 통제가 되지 않는 이상 관리자가 시스템을 제한하는 것은 한계가 있기 마련이다. 직원규모 100명 이내의 중, 소규모 회사라면 더더욱 그러할 거라는 생각이다. 사용자들은 옆자리의 동료에게 자신의 컴퓨터에 있는 파일을 함께 쓰기를 즐겨하며, 여전히 인터넷으로부터 새로운 프로그램을 다운받아서 설치하고자 시도할 것이다.

이러한 회사실정을 고려하여 먼저 생각해야 할 것은 회사의 물리적인 네트워크 환경을 바꾸는 작업이다. 공용네트워크와 개인네트워크를 분리하여 기본적으로 외부 인터넷에서 내부 네트워크에 접근이 어렵도록 막는 것이다. 그리고 사용자 시스템에 대한 관리자 계정은 회사의 시스템 관리자만이 가져야 한다. 다만 사용자에게는 도메인의 사용자 계정에 대해서 로컬 컴퓨터의 Power Users 그룹의 멤버가 되게 함으로써 대부분의 작업을 할 수 있게 하지만, 사용자가 자신의 시스템의 Administrators 그룹에 대해서는 접근하지 못하도록 제한을 할 필요가 있다. 추가로 그룹정책을 이용하여 사용자의 작업을 적정 수준에서 제한하는 것은 꼭 필요한 작업이다.

NT시절의 시스템정책에서 한층 향상된 기능을 제공하는 Active Directory의 그룹정책은 참으로 대단한 능력을 보여준다. 도메인환경에서 다수의 컴퓨터, 다수의 사용자들에 대한 대부분의 관리 및 지원기능을 그룹정책 하나를 가지고 자동화시키고 있는 것이다. 이러한 그룹 정책을 잘 사용하는 것은 관리자의 업무부담을 상당부분 줄여줄 수 있다.

그룹정책을 적용할 수 있는 Active Directory 구조단위는 사이트, 도메인, OU이다. OU(조직단위)는 그룹정책을 적용할 수 있는 최소단위이다. 만일 당신이 특별한 부서에 대해서 제어판에 접근을 제한한다거나 바탕화면에 특정 그림을 넣어준다거나 하는 등의 작업을 하고자 한다면 이들 특별한 부서의 구성원들을 하나의 OU에 저장하고 이 OU에 대해서 그룹정책을 정의해 주는 것으로 해결할 수 있다.

그룹정책이 어떻게 구성되는지 기본적인 용어를 먼저 정리해 보자.

도메인 수준의 그룹정책을 열어보기 위해 Active Directory 사용자 및 컴퓨터 관리콘솔을 열고 도메인 이름을 마우스 오른쪽 클릭하여 ‘속성’을 클릭했다.

그룹정책 탭을 열었다.  기본적으로 Default Domain Policy 라는 이름의 그룹정책이 보인다. 아래의 2가지는 필자가 추가한 그룹정책이다. 이 그룹정책을 설정하는 인터페이스를 유심히 들여다 보자. 상속성 및 충돌을 명확히 이해하는데 꼭 필요하다. 아래의 <그림14-21>에 구체적인 사항을 그림으로 정리해 보았다.

그룹정책을 구성하는 요소는 그룹정책개체(GPO), 그룹정책 컨테이너(GPC), 그룹정책 템플릿(GPT)로 나뉜다. 먼저 그룹정책개체(GPO)는 사용자, 컴퓨터 계정등과 같이 Active Directory에 하나의 개체로 저장된다. <그림14-21>의 예제에서는 Default Domain Policy, 사용자들 대상 그룹정책, 컴퓨터 대상 그룹정책 이라는 이름의 세개의 그룹정책 개체가 Active Directory에 저장되어 있는 것을 보여준다. 그룹정책 컨테이너는 그룹정책 관리 인터페이스에 해당하며, 이것은 도메인, OU, 사이트 등에 그룹정책 개체를 연결하는 인터페이스 역할을 한다. 이렇듯 그룹정책 개체와 컨테이너는 별개로 봐야한다. 여기서 생성하는 그룹정책 개체는 다른 OU에서도 자신의 컨테이너에 링크시키는 작업을 통해서 가져다 쓸 수도 있다.

마지막으로, 각 그룹정책 개체들에 대한 실제구현에 관련된 정보는 Active Directory가 아닌 Sysvol 이라는 폴더에 저장한다. 이것을 가리켜서 그룹정책 템플릿(GPT)라고 한다. Active Directory를 설치할 때 Sysvol 폴더의 위치를 지정했던 것을 기억할 것이다. 그곳은 그룹정책에 관련된 스크립트 파일 등 물리적인 저장소 역할을 하게 된다.

도메인에 두 대 이상의 도메인 컨트롤러가 있다면 그룹정책 개체는 Active Directory복제를 통해서 전파가 되고, Sysvol 폴더의 그룹정책 템플릿은 NTFRS (NT파일 복제 서비스)를 통해서 전파가 된다.

또한 그룹정책은 기본적으로 상속성을 가지고 있다. 도메인의 그룹정책은 OU에 속한 모든 사용자 및 컴퓨터에 적용되고, 상위OU에 설정된 그룹정책은 하위OU에 상속된다.

<참고> 그룹정책의 충돌 및 상속성의 수정   그룹정책의 충돌 및 상속성을 이해하기 위한 한가지 예제를 들어 보았다. <그림14-22. 충돌 및 상속성의 이해를 위한 예제>   임직원OU에 속한 사용자가 도메인으로 로그온 했을 때 어떠한 정책이 반영될 것인지 생각해 보자. 기본적으로 그룹정책은 상속성이 있으므로 GPO1, GPO2, GPO3, GPO5 가 반영된다. 그룹정책의 세부항목으로 보자면 ⑥번을 제외한 ① ② ③ ④ ⑤ ⑦ 정책이 반영되게 된다. 그런데 정책을 들여다 보면 정책간에 일부 항목이 충돌이 발생한 것을 알 수 있다. 먼저 윈도우네트웍스OU의 그룹정책 컨테이너에는 GPO2, GPO3 이렇게 2개의 그룹정책 개체가 링크되어 있다. 이 두 정책의 항목 중에서는 ‘시작 메뉴에 실행메뉴 제거’라는 항목이 상충되고 있다. GPO2에서는 시작메뉴에 실행메뉴를 제거하도록 설정해 놓고서 GPO3에서는 시작메뉴에 실행메뉴를 제거하지 않도록 설정하고 있다는 것이다. 이렇듯 하나의 컨테이너에 있는 여러 그룹정책이 특별한 항목에서 충돌이 생겼을때에는 우선순위가 있다. 기본적으로 위쪽에 있는 정책이 보다 우선시된다. 그룹정책 메뉴에서 [위로], [아래로] 버튼을 이용하여 우선순위를 바꿀 수도 있다. 그래서 이 경우 임직원OU의 직원이 로그온 했을때는 GPO3의 정책보다는 GPO2의 정책이 우선순위가 있어서 시작메뉴에서 ‘실행’창은 제거된다. GPO2의 항목이 반영되는 것이다.   또 다른 하나의 충돌도 발생하고 있다. GPO1의 ‘제어판 접근 허용않음’ 항목과 GPO5의 ‘제어판 접근 허용’항목이다. 이 경우 사용자는 기본적으로는 자신이 속한 OU에 가장 가까운 쪽 정책을 적용받는다. GPO1이 비록 도메인 수준에서 설정된 그룹정책이지만 GPO5의 항목이 최종적으로 적용되는 것이다. GPO1 그룹정책 자체가 적용되지 않는 것이 아니라 GPO1의 그룹정책중 충돌이 발생하는 항목만 적용이 안 되고 나머지 모든 항목은 상속이 된다. 결국 실제로 임직원OU에 속한 사용자가 로그온 했을 때 최종적으로 적용받는 항목들은 ① ③ ④ ⑦ 정책이 반영된다. 이것이 상속성과 충돌이 발생했을때의 기본동작이다.   다음에는 이러한 상속성과 충돌발생을 몇가지 옵션을 통해 수정이 되는 것을 알아보자. 예제에서 임직원OU에서는 상위로부터 상속되는 그룹정책을 더 이상 상속받고 싶지 않다면 상속을 거부할 수 있다. 이 설정은 그룹정책 컨테이너 차원에서 이루어진다. <그림14-21. 그룹정책의 구성 이해>에서 ‘정책의 상속을 금지’ 옵션이 그것이다. 임직원OU의 그룹정책 컨테이너에서 이 옵션이 체크되어 있다면 임직원OU에 속한 사용자가 로그온했을 때 받게 되는 정책은 ⑦번 항목인 ‘제어판 사용’뿐이다. 도메인 수준의 정책이나 상위OU의 정책은 상속거부되어 적용이 되지 않는다. (Block Inheritance)   지금까지 보면 결국 도메인에서 설정한 정책보다 오히려 하위OU수준에서 설정한 정책이 반영이 되었는데, 어떻게 보면 우스운 일이 아닐 수 없다. 하부조직에서 상부의 명령에 불복하는 꼴이 되었으니 말이다. 그런 이유로 ‘무시안함(No Override)’이라는 또다른 옵션이 제공된다. <그림14-32>에서 보면 이 ‘무시안함’ 옵션은 그룹정책 컨테이너 차원에서의 설정이 아니라 그룹정책 개체별 설정이라는 것을 알 수 있다. 아래와 같이 설정되었다고 가정하자. <그림14-23. 상속성의 수정>   결론부터 말하자면 이 경우 임직원OU에 속한 사용자가 로그온했을 때 적용받는 정책은 ① ② ⑤ 번 정책 항목이다. ‘무시안함’옵션은 정책간에 같은 항목에서 충돌이 발생했을때는 사용자 측에서 보다 가까운 쪽 정책을 적용한다는 기본설정도 무시한다. 그것보다는 ‘무시안함’옵션이 설정된 정책이 우선시 되는 것이다. 윈도우네트웍스OU에서 GPO2는 임직원OU의 그룹정책 컨테이너에 ‘상속금지’가 설정되어 있기 때문에 상속이 되지 않지만, GPO3는 ‘무시안함’옵션이 활성화 되어 있기 때문에 역시 상속이 된다.   마지막으로 알아볼 것은 그룹정책의 필터링이다. 도메인의 모든 사용자에게 같은 정책을 할당하고 싶지만 특별한 사용자나 그룹에게는 반영하고 싶지 않다면 2가지 방법이 있다. 그러한 사용자나 그룹만 모아서 새로운 OU를 만든다음 이 OU에는 정책을 할당하지 않는 것이 첫번째이고, 두번째 방법은 해당 그룹과 사용자에게만 그룹정책이 적용되지 않도록 퍼미션 설정을 하는 것이다. 후자가 보다 유용한 방법이다. 이것을 그룹정책의 필터링이라고 부른다. 이것 역시 그룹정책 개체단위로 설정할 수 있다. 하나의 예제를 보자. 그룹정책 컨테이너를 열고 필터링 하고자 하는 정책을 클릭한 다음 [속성]을 눌러서 ‘보안’탭을 연다.   <그림14-24. 그룹정책 필터링>   기본적으로 그룹정책은 Authenticated Users 그룹에게 ‘그룹정책 적용’이라는 사용권한이 허용되어 있다. <그림14-24>에서 보는 바와 같이 그룹정책이 적용되지 않게 하고 싶은 사용자나 그룹을 추가한 다음 ‘그룹정책 적용’사용권한을 ‘거부’에 체크해 주면 된다. 예제에서는 ‘송용하’라는 사용자가 그룹정책을 받지 않도록 하고 있다. 마이크로소프트의 보안설정구조에서는 항상 ‘허용’보다는 ‘거부’가 우선한다. 비록 ‘송용하’라는 사용자는 Authenticated Users 그룹에 속해 있기 때문에 그룹정책을 허용받게 되지만 명시적으로 자신의 계정에게 ‘거부’가 주어져 있기 때문에 그룹정책을 적용받을 수 없다. ‘송용하’를 제외한 모든 사용자들은 여전히 그룹정책에 적용받게 된다. 이러한 필터링은 당연히 그룹에게도 적용할 수 있다.   <그림14-23>에서 만일 GPO1 그룹정책에서 임직원OU의 ‘송용하’에게 <그림14-24>와 같은 설정을 하였다면 결과적으로 이 사용자가 로그온 했을때는 ⑤,⑦ 정책항목이 적용된다.

이제 윈도우네트웍스㈜ 회사의 그룹정책을 구현해 보자. 이 회사에서 구현해야 하는 그룹정책은 다음과 같다.

먼저 도메인 수준의 그룹정책부터 구현해 보도록 하자. 마이크로소프트는 관리자가 그룹정책 구성을 보다 수월하게 할 수 있도록 GPMC (Group Policy Management Console)이라는 관리도구를 별도로 제공해 주고 있다. 그룹정책 관리에 아주 유용한 도구이다. 하지만 GPMC가 아닌 기본 그룹정책 관리 인터페이스도 알아두어야 하니 도메인 수준 그룹정책은 기본 메뉴를 이용해서 구현해 보고, GPMC에 대한 것은 잠시 후에 다루어 보도록 한다.

<그림14-26. 그룹 정책 구현 2>	기본적으로 생성되어 있는 Default Domain Policy가 있다. 여기서 [편집]버튼을 열어서 그룹정책을 설정한다.
<그림14-27. 그룹 정책 구현 3>	그룹정책을 열면 ‘컴퓨터구성’과 ‘사용자구성’으로 구분되어 있다. ‘컴퓨터구성àWindows설정à보안설정à암호정책’을 열고 오른쪽 패널에서 ‘최소 암호 길이’를 8문자로 지정하고 최대 암호 사용기간은 60일로 지정했다. 이제 앞으로 사용자가 생성되거나 암호를 변경할 때는 반드시 8자리 이상의 암호를 생성해야만 처리가 된다. 또한 60일이 경과하기 전에 사용자는 암호를 변경해야만 한다.
<그림14-28. 그룹 정책 구현 4>	이번에는 ‘컴퓨터구성àWindows설정à보안설정à계정정책à계정 잠금 정책’을 클릭했다. 계정 잠금 임계값을 ‘5’로 지정했다. 추가사항이 나온다. 계정잠금기간은 5번 틀린 암호를 시도했을 때 계정을 잠그고 30분이 지나면 다시 풀어주겠다는 것이고, ‘다음 시간후… ‘ 옵션은 암호를 틀렸을 때 다음번 암호를 틀릴때까지의 카운터를 갱신하는 값이다. 이 값이 30분일 때 어떤 사용자가 한번 암호를 잘못 입력해서 틀리고, 30분이 지나서 또 틀렸다면 그것은 두번째 틀린 것이 아니라 한번 틀린것으로 처리된다.
<그림14-29. 그룹 정책 구현 5>	이번엔 그룹정책에서 감사정책을 구성한다. 정책을 더블클릭하면 ‘이 정책 설정 정의’체크상자가 있고, 성공과 실패의 시도가 있다. 계정로그온 이벤트 감사의 경우 사용자가 계정과 암호를 제대로 입력해서 로그온을 성공했다면 ‘성공’한 이벤트로 감사가 되고, 암호를 틀려서 로그온을 실패했다면 ‘실패’한 이벤트가 된다.
감사정책을 구현하였다. 이 감사정책에 걸려든(?) 이벤트들을 관리자는 ‘관리도구-이벤트 뷰어’를 통해서 확인할 수 있다. 기본적으로 사용할 몇가지 감사정책을 설정했다. 창을 닫는다.
<그림14-30. 그룹 정책 구현 8>	이 Default Domain Policy 그룹정책을 거부하지 못하도록 ‘무시안함’옵션을 사용한다. Default Domain Policy를 클릭하고 [옵션]버튼을 눌러서 ‘무시안함’을 선택해 준다.
<그림14-31. 그룹 정책 구현 9>	‘무시안함’이 선택된 화면이다. 이 옵션은 OU수준에서 상속을 거부하거나, 동일한 항목의 정책상 충돌이 발생했을때에도 항상 Default Domain Policy는 적용되게 한다.

OU수준의 그룹정책을 설정하기 전에 앞서 언급한 GPMC (Group Policy Management Console)을 설치하자. GPMC는 마이크로소프트 다운로드 사이트에서 찾을 수 있다. GPMC로 검색해서 찾도록 한다.

<그림14-44. 그룹 정책 구현 1>	이번에는 OU수준의 그룹정책을 설정하자. GPMC에서 그룹정책을 적용할 윈도우네트웍스OU를 마우스 오른쪽 클릭하여 ‘Create and Link a GPO Here’ 선택했다.
<그림14-45. 그룹 정책 구현 2>	GPO의 이름을 “전사 표준 정책”이라고 입력했다.
<그림14-46. 그룹 정책 구현 3>	전사 표준 정책 GPO가 생성된 것이 보인다. GPMC의 오른쪽 패널을 보면 정책에 대한 권한, 설정 등을 확인할 수 있다. Settings 탭을 선택했다.
<그림14-47. 그룹 정책 구현 4>	Settings 탭을 확인하니 현재 ‘전사 표준 정책’GPC에는 아무런 설정이 되어 있지 않는 것을 알 수 있다. 그룹정책을 설정하기 위해 그림과 같이 마우스 오른쪽 클릭하여 “Edit”를 선택한다.
<그림14-48. 그룹 정책 구현 5>	그룹정책 개체 편집기가 열린다. 이것은 앞서서 도메인 수준의 그룹정책을 적용했던 것과 동일한 그림이다. Group Policy Template에서 불러온 것이기 때문이다. 먼저 이 회사의 표준 소프트웨어인 Office 2003을 배포해 보자. ‘사용자구성à소프트웨어 설정à소프트웨어 설치’를 마우스 오른쪽 클릭하고 ‘새로 만들기à패키지’를 선택한다.
<그림14-49. 그룹 정책 구현 6>	배포할 패키지의 위치를 찾고 있다. <그림14-32>에서 c:\packages\office2003폴더에 패키지를 저장했다. 예제에서는 \\blueapple\packages$\office2000 라고 입력했다. 배포서버인 blueapple에는 packsoftware$ 라는 이름의 공유폴더가 있어야 하고 이 곳에는 소프트웨어를 설치하기 위한 패키지가 저장되어야 한다. Packages$라는 이름을 사용하여 공유이름을 감춤으로써 사용자들이 네트워크에서 직접 이 공유폴더를 찾아가는 것을 막을 수 있다. 그룹정책에 의해서만 소프트웨어 원본을 분배해 주기 위한 조치이다.
<그림14-50. 그룹 정책 구현 7>	Office2003 패키지 설치파일인 pro11.msi를 선택하고 나니 소프트웨어 방법을 묻는다. 수정된 mst 파일을 배포하기 위해서는 ‘고급’을 선택해야 한다. 게시나 할당을 선택하면 Office 2003이 기본설치되고 사용자들에게 프롬프트를 보여줄 것이다.
<그림14-51. 그룹 정책 구현 8>	<그림14-51>을 보면 고급옵션이 나타난다. [수정]탭을 눌러서 [추가]버튼을 클릭한 후 사용자정의된 .mst 파일을 추가했다.
<그림14-52. 그룹 정책 구현 9>	계속해서 [배포]탭을 선택한 후 배포형식 및 옵션을 결정한다. ‘게시’와 ‘할당’은 사용자가 로그온 했을 때의 설치방법의 차이를 보여준다. ‘게시’로 배포하면 제어판의 프로그램추가/제거에서 프로그램 추가 항목에 접근하면 Office 2003 설치가 대기중인 것을 확인할 수 있고, ‘할당’으로 배포하면 <시작à모든 프로그램>에 Office2003 관련 실행메뉴가 보이는 것을 확인할 수 있다. 실제 설치가 된 것은 아니다. 배포옵션중 ‘로그온시 이 응용프로그램 설치’를 선택하면 사용자가 도메인 로그온을 하면 제일 먼저 Office 2003이 설치된다.
<그림14-53. 그룹 정책 구현 10>	다음엔 인터넷 옵션의 ‘프록시 설정’을 구성해 보자. 그룹정책 개체 편집기에서 <사용자구성àWindows설정àInternet Explorer유지à연결>을 찾아가면 오른쪽 패널에서 ‘프록시 설정’을 찾을 수 있다. ISA Server 2004로 구성된 웹캐싱서버의 IP주소를 입력하고 구성된 포트번호를 기록한다.
<그림14-54. 그룹 정책 구현 11>	무선랜 클라이언트를 지원하기 위해 사용자의 무선랜 연결설정을 구성하자. <컴퓨터구성àWindows설정à보안설정à무선 네트워크>를 선택하고 ‘무선 네트워크 정책 만들기’를 시작한다.
<그림14-55. 그룹 정책 구현 12>	무선 네트워크 정책 이름을 입력한다. 예제에서는 WindowsNetwork WirelessLAN이라고 입력했다.
<그림14-56. 그룹 정책 구현 13>	무선랜 연결의 등록정보를 입력한다. 기본 네트워크탭을 열었다. 회사에 구축된 무선네트워크 연결을 하기 위해 [추가]를 누른다.
<그림14-57. 그룹 정책 구현 14>	네트워크 속성에 무선AP의 SSID를 입력하고, 계속해서 [IEEE 802.1x]탭을 선택한다.
<그림14-58. 그룹 정책 구현 15>	EAP종류에서는 “보호된 EAP”를 선택하고 [설정]탭을 누른다.
<그림14-59. 그룹 정책 구현 16>	신뢰할 수 있는 루트인증기관으로 회사에 구축된 루트CA를 선택하고 인증 방법 선택 아래에 있는 “빠른 다시 연결 사용”을 체크한 다음 [확인]을 눌러서 구성을 마친다.
<그림14-60. 그룹 정책 구현 17>	윈도우네트웍스OU에 링크된 ‘전사 표준 정책’의 구성을 마쳤다. 오른쪽 패널에서 구성된 사항을 확인할 수 있다.
이번에는 “임직원 대상 그룹정책” GPO를 생성하고 임직원OU에 링크시켜 보자. 사용자들의 ‘내 문서’폴더를 파일서버의 개인폴더로 지정하고, 부서공용폴더를 사용자에게 특정 드라이브로 매핑하여 부서공용문서에 접근이 용이하도록 설정해 주고자 한다.
<그림14-61. 그룹 정책 구현 18>	GPMC를 실행하고 임직원OU에서 마우스 오른쪽클릭하여 ‘Create and Link a GPO Here’ 선택한다. “사용자구성àWindows설정à폴더 리디렉션à내 문서”의 속성을 열었다.
<그림14-62. 그룹 정책 구현 19>	blueapple서버에는 사용자들의 데이터를 저장하기위한 용도로 userdoc 라는 공유폴더를 생성해 두었다. <그림14-62>에서 ‘설정’부분은 기본값으로 설정했다. 다른 설정을 선택하면 Active Directory의 그룹별로 다른 공유폴더를 지정할 수도 있다. ‘대상 폴더위치’부분에서 ‘루트경로’를 \\blueapple\userdoc를 지정했다.
이것은 아주 유용한 기능이다. 이 결과 임직원OU에 속한 모든 사용자계정에 해당하는 폴더가 \\blueapple\userdoc 공유폴더에 생성되며 이 폴더는 자동적으로 해당 사용자에게만 모든권한이 부여되고 다른 사용자들은 접근하지 못하도록 권한관리가 이루어진다.   이 그룹정책을 적용받는 사용자가 로그온 하게 되면, 예를 들어 wonsuk 이라는 사용자 계정으로 로그온을 했다면 자동적으로 사용자가 사용하는 컴퓨터에서 바탕화면에 있는 ‘내 문서’폴더는 \\blueapple\userdoc\wonsuk 이라는 이름의 폴더로 매핑이 되어 있다. 사용자가 데이터를 만들고 저장할 때 ‘내 문서’를 이용하도록 교육할 필요가 있다. 사용자가 ‘내 문서(My Document)’에 저장을 하게 되면 실제로 그 데이터는 사용자의 로컬 하드디스크의 파일시스템이 아닌 blueapple 파일서버의 개인폴더 안으로 저장된다. 사용자들이 더 이상 네트워크에서 자신의 폴더를 찾기 위해 헤맬 필요가 전혀 없다. 이렇게 모든 사용자들의 데이터가 파일서버 하나에 집중되게 되면 관리자는 이 서버의 폴더를 백업함으로써 전체 사용자들의 개인 데이터를 보호할 수 있다.   또 하나의 장점은 이 사용자가 어떤 컴퓨터에 앉아서 로그온을 하더라도 항상 바탕화면의 ‘내 문서’는 \\blueapple\userdoc\wonsuk 에 매핑이 되기 때문에 항상 자신의 데이터에 접근할 수 있다는 것이다. 일반 사용자가 생각할때는 마술에 걸렸다고 생각할 지도 모르겠다. 자기 컴퓨터에서 저장했다고 생각한 데이터에 다른 사람의 컴퓨터에서도 “내 문서”폴더만 열면 접근할 수 있으니 말이다.
<그림14-63. 그룹 정책 구현 22>	이번엔 부서별로 공용데이터 폴더에 접근할 수 있도록 사용자에게 드라이브를 연결해 주는 스크립트를 자동으로 실행하도록 설정하려고 한다. ‘사용자구성àWindows설정à스크립트(로그온/로그오프)à로그온’의 등록정보를 열고 있다.
이 작업을 하기 전에 미리 네트워크 드라이브 매핑을 수행할 스크립트 (혹은 배치파일)을 생성해야 한다. 메모장을 열고 “net use x: \\공유서버이름\공유폴더\해당부서폴더” 를 입력한 다음 바탕화면에 배치파일로 저장해 둔다. 사용자 컴퓨터에서 이 배치파일이 실행되면 로컬 X: 에 blueapple의 공유폴더가 매핑된다. 다음에 할 일은 앞에서 만든 배치파일을 사용자가 로그온할 때 자동으로 실행되도록 그룹정책에서 설정하면 되는 것이다.
<그림14-64. 그룹 정책 구현 23>	로그온 등록정보에서 [파일표시]를 선택한 후 앞에서 만든 배치파일을 저장했다.
<그림14-65. 그룹 정책 구현 24>	[추가]버튼을 눌러서 로그온 스크립트로 수행시키고자 하는 파일을 선택한 다음 [확인]을 눌러서 마친다.
<그림14-66. 그룹 정책 구현 25>	임직원 대상 그룹정책의 설정을 마쳤다. GPMC를 통하여 내용을 확인할 수 있다.
<그림14-67. 그룹 정책 구현 28>	마지막으로 IT관리자들은 상위의 그룹정책을 적용받지 않도록 설정하고자 한다. GPMC에서 IT관리자계정을 조직하기 위한 IT관리OU를 마우스 오른쪽 클릭하고 ‘Block Inheritance’를 선택한다. IT관리OU에 파란색 느낌표가 생기는 것을 확인할 수 있을 것이다.
<그림14-68. 클라이언트 로그온 테스트>	Active Directory 도메인에 참여되어 있는 PC에서Windows XP 임직원OU에 속한 사용자의 계정으로 로그온을 해 보았다. 로그온과 동시에 Office 2003이 설치되고 있는 것이 보인다.

이상으로 그룹정책 구성을 마쳤다. 이 그룹정책이 적용되는 클라이언트의 OS는 현재 Windows 2000 Professional, Windows XP Professional 버전이다. Windows NT나 Windows 9x의 경우는 그룹정책과 무관하다. 위의 모든 설정이 전혀 반영되지 않는다는 것이다. 점차 도입되는 새로운 시스템들은 Windows XP 로 대체가 될 것이다. 도메인 환경을 구축하였다면 가급적이면 네트워크에 모든 클라이언트들도 Windows 2000이나 Windows XP를 사용하는 것이 좋다.

하지만 Windows NT, 9x 클라이언트들의 경우에도 로그온 스크립트나 홈폴더 설정등은 아주 간단히 이루어진다. Active Directory 사용자 및 컴퓨터를 이용해서 Windows 9x 컴퓨터를 사용하는 사용자계정의 등록정보로 접근하여 ‘프로필’탭에서 설정할 수 있다. 이것은 Windows 계열의 모든 OS에게 적용되는 설정이다.

14-2-1. 서버의 역할 결정

중소규모 기업네트워크 환경에서 필요한 여러가지 서버의 역할을 각각 고유한 서버가 맡기는 현실적으로 어렵다. 많은 회사들은 최신사양을 갖춘 고가의 전용서버 한대를 들여놓고 회사에서 필요한 모든 서비스를 하나의 서버에 집중시키고 있다. 최소한의 서버대수로써 비교적 원활히 동작할만한 구성을 해 보도록 하자.

현재 회사에는 3대의 서버가 동작하고 있다. 아래의 <그림14-6>와 같이 서버를 배치하고 나니 총 4대의 서버가 소요된다. 한대가 부족하다. 새로운 서버 한대를 도입하고 1^st 도메인 컨트롤러로 구성할 수 있다. 방화벽 서버가 오래되어 성능이 문제가 되고 있었다면 새로 도입하는 서버를 방화벽 서버로 대체하고 기존 방화벽 서버를 도메인 컨트롤러로 설치하는 것도 좋은 방법이다. 나머지는 기존의 3대의 서버를 가지고 구성하였고, 첫번째 서버에는 802.1x 무선랜 인증을 지원하기 위해 IAS (Internet Authentication Service; 인터넷 인증 서비스)서버를 추가로 구성하였다. ISA Server 2004에는 VPN서비스를 구성하여 출장지에서나 재택근무시 노트북 사용자의 사내자원 접근을 허용하고자 한다. ISA서버와 VPN서버 구성에 대해서는 7장을 참고한다.

노트북에 설치되어 있던 Windows XP Home edition은 Active Directory 인프라에 참여할 수 없는 클라이언트이므로 Windows XP Professional버전으로 업그레이드 하였다. Windows 98 3대가 있다는 것이 아쉽긴 하지만 레거시 어플리케이션이 상위버전의 OS에서 지원하지 못한다는 이유로 계속 사용해야 하는 상황이다.

네트워크에 서버를 배치할 때는 8장에서 설명한 ‘기업 네트워크에서 네트워크 서버 배치시 고려할 사항’을 잘 고려해 보자. 당신이 디자인한 네트워크 구성이 이들 조건에 잘 부합되고 있다면 잘 구성했다고 판단해도 좋다.

14-2-2. 첫번째 도메인 컨트롤러 설치

다음과 같은 순서로 진행한다.

회사의 도메인이름은 위에서 외부적으로 현재 사용하고 있는 windowsnetwork.msft 를 사용하기로 결정했다.

구체적인 설치방법에 대해서는 이 책의 ‘13-3. Active Directory 설치’ 단원을 참고하라.

14-2-3. 두번째 도메인 컨트롤러(Replica) 설치

같은 방법으로 두번째 도메인 컨트롤러를 설치한다. 설치옵션만 조금 다를 뿐이다.

역시 구체적인 설치방법에 대해서는 이 책의 ‘13-3. Active Directory 설치’ 단원을 참고하라.

Active Directory 도메인 기능수준 (모드) Windows Server 2003의 Active Directory는 NT4.0과는 다르게 OS의 셋업과 도메인 컨트롤러의 셋업과정이 분리되어 있다. dcpromo 를 이용하여 Active Directory를 셋업하면 도메인 컨트롤러가 되고, 역시 같은 유틸리티를 이용하여 Active Directory를 제거하면 일반서버가 된다.  Windows Server 2003의 도메인은 이전버전인 Windows 2000, NT4.0 도메인컨트롤러와의 호환성을 위하여 기본적으로는 'Windows 2000 혼합모드'를 사용한다. 하지만, Windows 2000 혼합모드는 Active Directory에서 추가된 기능들중 몇 가지를 사용하는데 제약을 주게 된다. Windows NT 4.0 도메인 컨트롤러가 반드시 필요한 상황이 아니라면 그들을 윈도우 서버 2003으로 업그레이드를 고려한다. 회사의 도메인 환경이 Windows Server 2003 도메인 컨트롤러만으로 구성이 완료되었다면 'Windows 2000 혼합모드'를 'Windows Server 2003 기능수준’으로 전환시켜 주어야 할 것이다. 그렇지 않으면 Universal Group, Group의 중첩적용, RAS서버의 정책관리 등의 기능을 구현할 수가 없다. 보다 자세한 사항은 Windows Server 2003의 도움말에 잘 정리되어 있다. 도메인 기능수준을 확인하기 위해서는 관리도구àActive Directory 사용자 및 컴퓨터를 실행하고, 관리콘솔의 왼쪽패널에서 도메인이름을 클릭하고 마우스 오른쪽 단추를 이용하여 등록정보로 접근한다.<그림14-9> <그림14-9.  도메인 기능수준 정보>  <그림14-9>에서는 도메인 기능수준이 'Windows 2000 혼합’으로 되어 있음을 보여준다. Active Directory를 설치하고 나면 기본값이다. 화면에서 보이는 것처럼 ‘사용가능한 도메인 기능 수준 선택’을 클릭하여 원하는 도메인 기능수준을 선택한 후 [수준 올리기]를 클릭하여 기능수준을 전환할 수 있다. 단방향 작업이니 회사의 도메인에 더 이상 NT 4.0 도메인 컨트롤러나 Windows 2000 도메인 컨트롤러가 없다는 것이 확실했을 때 변경하도록 한다. 이 도메인 기능수준은 클라이언트의 종류와는 무관하다. 도메인 컨트롤러가 아닌 서버나 클라이언트들의 OS는 Windows 2000이거나 WIndows NT이거나 Windows 98이거나 상관할 바가 아니다. 이전버전의 도메인 컨트롤러가 더 이상 필요하지 않음이 확실하다면 도메인 기능수준을 변경해서 사용하자.