마이크로소프트는 당신이 다양한 네트워크 작업을 하는것을 돕기위한 일관된 인터페이스을
만드는 고상한 목적을 설정했다 MMC가 그와중에 우리에게 왔다 여기 동작과 빠진 조각들을
모아 보았다 하나에 모두을 맞추는것 그것은 회의적으로 취급해야 할말이다 윈도우 환경에서
모든 각양각색의 관리도구을 호스트(host)하기위한 단하나의 인터페이스을 만드는것이 가능
한가? 또는 특별한 기능을 위한 특별한 툴(tool)을 가지는것이 더 나은가? Microsoft
Management Console(MMC)에 대해 마이크로소프트가 의도한 범위는 얼마나 많은 제품들이
MMC 인터페이스에 맞추어질것이 예상되어 있나을 보면 놀라울 것이다 할수 있겠는가? MMC
가 모든 프로그램에서 모든것을 할수 있을까? MMC는 1997년 TechEd에서 특장연설의 중심
이였다 그 개념은 충분히 멋있다 그러나 도메인 사용자 관리자와 서버 관리자가 다른 툴(tool)
을 가지는것을 정말로 꺼리느냐? 반면에 고객화(customized)된 관리 콘솔(consoles)을 만드
는 능력이 흥미로웠다 그 이후 더더욱 많은 응용프로그램이 관리 인터페이스로써 MMC
snap-ins로 나타났다 SMS 2.0에서 과거 SMS 관리자인터페이스는 MMC snap-ins을 포기해
왔다 Internet Information Server(IIS) 4.0은 그것을 사용한다 SQL Server 7.0과 MS Online
Analytical Processing(OLAP)서비스는 역시 그러하다 BackOffice Resource Kit 4.5는 모든
툴에 대한 인터페이스로써 MMC을 사용한다 심지어 Hewlett-Packard와 같은 독립 소프트웨어
공급자(Independent Software Vendors, ISVs) 조차도 그것에 대해 쓰고 있다 그리고 물론
MMC는 윈도우 2000의 모든 관리의 중심에 있다 마이크로소프트는 사실 실제적으로 모든것에
대한 관리적인 인터페이스로써 그것을 표준에 의한 필수적인것으로 생각한다 당신이 네트워크
관리자로써 더욱더 자주 이툴을 직면 할것이기에 우리는 MMC가 무엇인가와 그것이 무었을
할수 있나을 설명하는것으로 시작할것이다 그리고 우리는 그것이 어떻게 설치 되는가을 볼
것이다 그리고 마지막으로 이 인터페이스가 요구하는 큰문제 몇몇을 다룬다

What is MMC?
관리자는 네트워크에서 문제을 고치기위해 일일조작으로부터 많은 다른 작업을 수행한다
운영체제에 있어서 관리는 사용자계정을 더하는것 하드디스크을 구성하는것 파일에 퍼미션
(permission)과 권한(right)을 할당하는것 같은 작업을 포함한다 SQL서버 같은 어플리케이션
(application)에서 관리는 백업 또는 새로운 데이타베이스을 만드는것일수 있다 IIS에서 관리는
새로운 가상 디렉토리을 만드는것을 포함할수 있다 MMC의 배경 아이디어는 수 많은 다른
관리 작업을 하기 위한 일관된 인터페이스을 관리자에게 제공하는것이다 그러므로 Microsoft
Management Console에서 관리(management)란 당신의 관리 업무 모두을 다루고 작업 할수
있는 능력을 의미한다
MMC는 근본적으로 Snap-ins라 불리는 조그만 툴을 위한 단지 어떤 컨테이너(container)이다
컨테이너는 역시 웹페이지 폴더(folder) Active X controls을 포함할수 있다 그 컨테이너 자체
만으로는 어떤 관리적인 기능을 제공하지 않는다 Snap-ins는 다양한 어플리케이션에 의해
제공되는 관리도구이고 Windows 2000의 경우는 Operating system 그 자체이다 Snap-ins는
MMC의 외부에서는 실행할수 없다 각 Snap-in은 탐색기 인터페이스와 유사한 윈도우 구조을
사용한다 윈도우의 왼쪽은 컨테이너의 트리(tree)을 나타낸다 오른쪽은 각 컨테이너의 내용을
나타낸다 MMC는 MDI(Multiple Document Interface)라 불리는 것이다 이것은 같은 콘솔
(console)에 붙은 다중 윈도우을 가지는것을 가능하게 한다는것을 의미한다 Single Document
Interface의 한예는 Microsoft Internet Explorer이며 그 각 세션(session)은 한번에 단지 하나의
윈도우만 표시할수있다
관리자로써 그아이디어는 당신이 하나 또는 그이상의 snap-ins(Netscape의 plug-in을 의미)을
얻을수 있다는것이다 그리고 당신의 수고을 줄이기 위해 custom management consoles을 만들수
있다 각 custom console은 각 관리자가 다룰 옵션(options)과 뷰(views)만을 나타나게 하는
.MSC 확장자을 가진 Management Saved Console로써 저장될것이다 이것은 모든 관리자의 능숙도
와 작업종류에 따른 아주 구체적인 콘솔을 만든다 .MSC파일은 다른사용자 또는 관리자가 사용
할수있고 자동적으로 구체적인 관리환경을 재창출하기 위해 호출된다 당신은 email메시지로
.MSC파일을 보낼수 있고 사용자의 시작메뉴에 직접 복사 가능하다 이론적으로 .MSC파일이
실행되는 컴퓨터에 요구된 snap-ins가 없다면 MMC는 요구된 컴포넌트(Components)을 다운로드
할것이다 어떤 종류의 콘솔들이 만들어 질수 있느냐? 당신이 SMS을 통해 소프트웨어을 분배하는
것을 관리한다면 당신은 SMS패키지와 단지 컬렉션 컨테이너(collections containers)을 포함한
하나의 .MSC파일을 만들수 있을 것이다 당신이 쿼리(queries)에 답하는 또 다른 관리자라면
당신은 SMS쿼리컨테이너 SGL7.0 snap-in 그리고 BackOffice Resource Kit 4.5(BORK)에 포함된
특성화된 쿼리툴(tool)의 몇몇을 포함하는 또다른 .MSC 파일을 만들수있다 MMC는 당신의 유저
에 대해 보안성을 부여하지 않는다 그것은 더우기 당신이 몇몇 options의 표시(display)을
하거나 하지 않을때 거대한 메뉴처럼 느낄것이다 그러나 그 options모두을 없앨수는 없다
그것은 당신이 실행하는 어플리케이션의 보안성에 의존한다
반면에 MMC는 보안을 강요하지 않는다 단지 MMC는 메뉴와 같은 옵션에 대한 관리적인 제어을
제공한다 MMC는 유저가 콘솔(console)에서 할수있는것과 할수 없는것을 결정하기 위해 다른
모드(modes)을 사용한다 MMC가 저자모드(Author Mode)에서 열려지면 변환의 모든 형태는
콘솔에서 만들어 질수 있다 관리자는 유저모드(User Mode)에서 열리도록 콘솔을 저장하는것을
선택할수 있다 그리고 그것은 3가지의 엑세스(access)형태 즉 full access, 다중창을 가지는
delegated access, 단일창을 가지는 delegated access로 제한한다(다음 버전인 MMC1.2에서
마이크로소프트는 delegated access 대신에 "limited access"라는 용어을 사용한다)
full access에서 유저는 Snap-ins을 더하거나 제거할수 없다 그러나 유저는 완전한 콘솔 트리(tree)
을 따라 움직일수 있다 그리고 그들의 현존하는 snap-ins을 가지고 새로운 창을 열수 있다
제한된 엑세스(delegated access)에서 유저는 snap-ins을 더하거나 제거할수 없다 그리고
유저는 콘솔로 이전에 저장되지 않은 어떤창도 나타낼수없다 다중창 옵션을 가지고 단일창이상이
콘솔의 부분으로써 저장될수 있다 우리의 쿼리(queries) .MSC예에서 우리는 단일창안에 BORK툴
을 저장해야한다 그리고 다른창에 SQL 데이타베이스와 SMS쿼리컨테이너(query container)을
둔다 이 관리적인 제어는 어떤 종류의 보안을 제공하지 않는다 유저가 저자모드에서 MMC을
시작하는것을 막기위해 Group Policy Objects(GPOs)을 사용할수 있다
팁: NT사용자의 시작메뉴 또는 네트워크을 경유한 데스크답에 어떤것을 더하기 쉽다 물론 충분한
권한을 가졌다고 가정한다 윈도우 탐색기을 시작하라 그리고 도구/MapNetworkDrive로 가라
이 경로에서 입력하라 \\computername\admin$ Admin$는 그위의 드라이브 문자가 무엇이건
윈도우가 설치된 디렉토리을 항상가르키는 특별한 숨은 공유이다 단지 관리자만이 이공유을
access한다 당신이 일단 Admin$공유에 맞춘 어떤 드라이브문자을 가지면 그 드라이브 위에
프로파일(Profile) 디렉토리을 찾기 위해 탐색기을 사용한다 프로파일속에 당신이 원하는 유저을
위치시키고 또는 All User profile 디렉토리을 선택하라 당신은 실행파일 바로가기 또는 MMC
.MSC파일을 바로 유저의 Desktop폴더 또는 당신이 원하는 다른사람의 시작메뉴에 붙여 넣을수
있다  - 디자인 차별화 - 마이크로소프트는 Win2k와 함께 선적된 버전 1.2에 대한 많은 계획을
가진다 그중의 하나는 새버전이 현제버전보다 더 나은 언급된 디자인 철학을 따르는것을 바란다
우리는 디자인과 구현사이에 차이의 몇몇 중대한 보기을 가지고 있다 "Microsoft Management
Console: Overview"라고 단순히 이름 붙여진 백서에서 마이크로소프트는 "MMC환경은 snap-ins
사이에 결점없는 통합을 제공한다"라고 주장한다 반면에 이것은 확실히 목표이고 현실은 부족
하다 예을 들어 Proxy Server snap-in은 문제아이다 당신이 MMC1.1을 실행하여 1.0에서 만들어진
.MSC파일을 연다면 MMC는 당신이 1.1 MSC format으로 업데이트하기을 원하는지을 물을것이다
당신이 그렇게 하면 그 기록(document)은 Proxy snap-ins을 포함한다 그러나 당신은 3개의 DLL
을 초기화하는데 실패하여 다시는 그 파일로 부터 Proxy을 관리할수 없게 될것이다 이것에 대해
마이크로소프트와 토론에서 우리의 손이 미치지 못한다 디자인과 디자인의 실제사이에는 또다른
차이가 있다 이상적으로 .MSC파일은 당신이 어떤 snap-ins와 묶도록(package up) 허용하고
그것을 어떤 컴퓨터에 보내는것을 가정한다 백서을 검토하면 "두번째 관리자가 그의 컴퓨터에
설치된 필요한 모든 Snap-ins을 가지지 않으면 MMC는 두번째 관리자가 .MSC file을 로드(loads)
할때 필요한 Snap-Ins을 자동으로 다운로드 할것이다" 그러나 어디에서 다운로드할것인가?
문서는 명시하지 않는다 우리는 다른 날짜로 표시된 같은 이름을 가진 몇몇 문서에서 이와같은
문장을 발견했다 www.microsoft.com/MANAGEMENT/MMC/overview.htm에서 저작권1996의
문서에서 "자동 다운로드는 현제구현되지 않는다 그것은 전문개발자회의(Professional Developers
Conference)후의 배포판 안에 있을것이다" 1998년의 날자가 메겨진 최근의 문서에는 그와같은
디스크레이머(disclaimer)을 쓰지 않았다 그러면 그것이 구현 되었는가? 지금까지는 아니오라고
말할수 있다 우리는 SQL, SMS, BORK 그리고 IIS을 가지고 시도 했다 그들중 어떤것도 당신이
.MSC파일을 실행을 시도할동안 그 어플리케이션이 컴퓨터에 설치되지 않으면 실행되지 않는다
저자모드하에서 트리(tree)의 어떤것위에서 오른쪽 마우스버튼을 클릭하면 "여기에서부터 새창
만들기(New window from here)"을 위한 옵션을 준다 이 메뉴옵션은 새로운 트리의 최상위(top)
로써 그 노드(node)을 가지고 하나의 창을 만든다 그림 2는 이특징이 가정적으로 어떻게 작동
하는가을 보인다 최상위 창에서 당신은 SMS(폴더이름) 옵션의 모두을 볼수 있다는것에 주목하라
최하위창은 트리에서 Collections(폴더이름) 노드위에 "New window from here"을 불러오는 결과
을 나타낸다 불행히도 변경사항은 보존되지 않는다 우리가 "New windows from here"을 얼마나
많이 열었나에 상관없이 우리가 console(최상위 폴더이름)을 다시 열때 우리는 그들창의 각각에
다시 전체의 트리(full tree)을 얻었다 이것은 우리가 희망하는 최고의 경우이다 IIS와 Terminal
Server와 함께 쓸때 당신의 시스템을 멈추게 하는 이옵션의 문서화된 경우가 있다(Knowledge
Base기사 Q194393에 보고된것 같이 "MMC에서 New Window From Here Option은 치명적인
에러을 야기할지 모른다") 우리는 그것이 우리의 SMS시스템을 멈추게하는 일회적인 경험을
가진다 유저모드에서 .MSC파일을 쓰지 못하게 하는것은 해로운 소수의 관리자가 그들의 콘솔을
바꾸는것으로부터 보호하기 위해서라고 생각된다 현실적으로 저자모드에서 access을 얻는것은
어렵지 않다 일단 유저가 .MSC파일을 시작했다면 그사람은 콘솔의 제목막대위에서 오른쪽 버튼
클릭을 하고 유저옵션을 가져올수 있다 그기에서 유저는 "항상 저자모드에서 콘솔을 염"옵션을
선택할수 있다(그림 3참조) 또한 MMC가 자동으로 저자모드을 유도하는 /A 스위치와 함께 시작
하면 역시 저자모드에서 열린다 일반적으로 윈도우 인터페이스(interface)에서 마우스는
객체(object)을 빠르게 그리고 효과적으로 access하기 위해 사용되어질수 있다 이런 관점에서
어떤 snap-ins는 큰 퇴보을 보인다 SMS snap-in에서 당신이 SMS툴 하나을 시작하려면 당신은
우선 그툴을 마우스 오른쪽 클릭을 해야한다 그리고 구문메뉴(context menu)로 부터
"모든작업(All tasks)"을 선택한다 그리고 최종적으로 당신이 시작하기을 원하는 툴을 선택
한다 도대체 좋은 과거의 "더블클릭"은 어떻게 되었는가? 다양한 snap-ins의 사용자로부터
또다른 성가신것은 인터페이스에서 당신이 필요한것을 찾기가 얼마나 어려운가이다 허가된
SMS1.2 인터페이스는 완전한것과는 거리가 있다 그러나 적어도 모든것이 아주 시각적(visible)
이다 SMS1.2에서 당신은 모든 사이트 구성 셋팅(site configuration srtting)을 보기 위해
파일/등록정보 옵션을 사용해야 한다 당신이 일단 그것을 찾았다면 그 부모 사이트(parent site)
을 정할 정확한 버튼(button)이 있다 2.0snap-in에서는 부모사이트에서 자식 사이트(child site)
의 연결을 위한 방법이 사이트 등록정보(site properties)에서 역시 정해진다 그러나 당신이
그들의 등록정보을 볼수있는 유일한 방법은 트리에서 정확한 노드(node)을 찾는것이다 그리고
등록정보 페이지을 가져오는 것이다 어느 노드가 선택되었는지 설명을 시도하는것 조차 그림을
사용하지 않으면 극단적으로 어렵다 그리고 이 옵션이 살아있는 곳을 기억하는것 또한 아주
어려울수 있다 그림5는 우리에게 과거의 인터페이스을 사용해 SMS1.2에서 이 조작(action)을
어떻게 수행하는지을 보여준다 그림 6과 7은 당신에게 MMC에서 이 과정(process)을 보여준다
이런! MMC는 트리에서 아주 시각적으로 기초 되었기 때문에 그것은 마이크로소프트 자신의 접근성
표준과 일치하여 이 인터페이스을 적용하기가 힘들다 윈도우을 위한 마이크로소프트 디자인
가이드라인의 부분은 마우스 없이 엑세스(access) 되는것을 요구한다
다른것들과 사용되는 SQL Server snap-in이 잘못 설치 되었다 당신이 마우스을 사용할수 있다면
당신은 당신이 관리하기을 원하는 서버위을 단순히 클릭할수 있다 그리고 다른 서버을 우회(bypass)
할수 있다 마우스 없이 당신은 서버들의 계층구조을 통해서 가르켜야한다 MMC는 실제로 당신이
닿을수 있는 모든 서버을 연결하도록 강요한다 당신이 여러서버을 가진다면 당신은 단지 리스트
(list)을 통해서 움직일수 있다 그것은 모래시계 그리고 나서 다시 마우스 포인터이다 이 기사을
조사할때 우리는 SQL 서버 서비스가 멈춘 어떤 서버 리스트을 통해 움직이려 했다 우리는 연결할수
없는것에 관한 두개의 에러메시지을 얻었다 그리고 나서 Dr. Watson 에러 메시지을 얻었다
현제 MMC의 구현에 또 다른 아킬레스근(Achilles heel)은 단일 thread 응용프로그램이다 모든
snap-ins는 thread을 공유한다 이것이 우리에게 의미하는것은 Snap-in이 정체되거나 또는 단순히
매우 느린경우 snap-in이 끝나거나 MMC가 재시작 될때까지 다른 어떤것은 MMC와 함께 실행될수
없다는것이다 멀티테스크(multitask)을 수행하는 관리자에게 이것이 의미하는것을 생각해 보라
어떤 snap-in가 작업에 오랜 시간이 걸린다면 즉 SQL서버의 데이타베이스 백업과 같이 그것은
MMC의 몇개의 인스턴스(instances)을 여는것이 필요하다 마이크로소프트로부터의 하나의 제안은
작은 MSC을 만드는것이다 즉 한가지 툴을 포함하는 각각 엔트프라이즈 메니저(Enterprise Manager)
을 위해 하나 SMS을 위해 하나 IIS을 위해 하나 그와 같은 종류는 시작한곳으로 우리을 되돌려
놓았다
많은곳에서 MMC의 기록은 그것이 Windows 9x에서 실행될것이라고 하고 있다 그러나
대부분의 snap-ins는 아니다 이것은 겨울에 산악 여행을 위해 운전수을 고용하는것과
같다 당신은 묻는다 그차가 언땅을 달릴수 있겠습니까? 대답은 예이다 그러나 당신이
그곳에 도착했을때 당신은 차만 발견하고 운전수는 없는것을 안다 많은 관리자는
이것에 의해 당황하고 좌절한다

Who's Behind the Wheel?(차의 손잡이 뒤에는 누가 있느냐?)
한걸음 뒤로 물러나서 MMC에 대한 우리의 초기 묘사을 기억하는것은 중요하다 - MMC는 단지
snap-ins을 위한 컨테이너(container)이다 이것은 메신저(messenger)을 이용하기 쉽다 이런
경우 메신저는 일관성이 흔히 없는 다른 프로그램그룹 또는 다른 회사에 의해 쓰여진 혼란
스럽게 뒤썩인 서로 다른 유틸리티을 묶어주는 MMC envelope이다 그러면 누가 MMC을 소유
하느냐? 마이크로소프트에 실제적인 MMC제품그룹이 있었다 그들은 현제 원도우즈 그룹의
부분인 BackOffice팀으로 옮겼다 우리는 이것이 그들에게 모든 원도우제품과 MMC을 통합
하는데 더 많은 기회을 주기을 바란다(이팀에 대한 제안이나 논평은 [email protected]
으로 할수있다) 비록 MMC을 위한 직원이 있지만 snap-ins는 여전히 마이크로소프트의 다른
application팀 또는 다른공급자 또는 독립프로그래머들에 의해 쓰여진다 그리고 표준에
맞추어 작성하는 사람은 많지 않다
마이크로소프트 프레스는 Snap-ins 제작자 가이드가 될 책을 가지고 있고 몇가지 인터페이스
가이드라인(interface guidelines)을 제공할것이다 그러나 지금은 MMC 표준화에 다른 가이드
라인은 없다 이표준이 많은 현제의 문제을 언급할것이기 때문에 안됐다 그러나 표준이 적절
하다 할지라도 그들이 따를것인가? 아마도 누가 MMC을 소유하느냐 이기보다는 누가 MMC을
집행할것인가이다
SMS에서 이것은 우리가 패키지(package)를 드레그(drag)할수 있고 소프트웨어
분배를 초기화하기 위해 그룹위에 그것을 드롭(drop)할수 있는날까지 물러
나도록 강요하였다 그리고 SMS 디자이너가 말밑에 두사이트를 연결하기 위한
설정을 숨기기로 결정하였다면 어떤 표준이 그들을 못하게 말들수 있느냐?
만약 그들이 했다면 그것이 집행되겠느냐? 빌코스비는 "나는 성공의 열쇠를
모른다 그러나 실패의 열쇠는 모든 사람을 기쁘게 하려는것이다"라고 말한 사람
으로 여겨지고 있다

Too Simple to be Powerful?(강력하기에는 너무 단순하다?)
마이크로소프트 문서에 의하면 MMC는 작업방침, 콘솔의 고객화, 통합성, 확장성,
전체적인 인터페이스의 단순화와 같은 몇몇 중요한 장점을 제공한다 작업방침은
명백히 플러스알파이다 다른 능력과 경력을 위한 .MSC를 고객화(customize)하는
것은 이익이 된다 MMC1.2에서 사용자가 그자신의 작업철(teskpad)를 만들도록
허용하는것은 더 많은 유연성을 더할것이다 그러나 "New window from here"옵션
이 믿을만하고 모순이 없이 동작할때까지 우리의 주요한 고객화된 옵션중에 하나
는 단지 우리가 미칠수없는곳을 맴돌게 한다 어떤이가 서로를 적당히 다루는것
으로부터 모든 snap-ins를 유지할수 있는한 MMC에서의 통합은 좋은 아이디어이다
누가 모든아이가 함께 놀수있도록 모래놀이통을 지켜볼것인가? 확장성이 어떻게
우리가 그렇게 많은 변수를 다룰때 유지할것인가? 인증된 확실한 관리프로그램의
호환성은 OS안에 확실한 응용프로그램의 호환성만큼 광범위하지 않다 그러나
그것은 많은 같은 문제에 직면하게 된다 당신은 모든 다른것을 깨지 않고 어떤것
을 어떻게 바꾸겠는가? 그리고 응용프로그램 프로그래머가 규정과 눈에 띄는 어떤
것을 따르지 않는다면 그것은 나쁘게 보이는것으로 끝맺는 컨테이너이다
MMC홈페이지(www.microsoft.com/management/MMC)에서 마이크로소프트는 snap-ins
겔러리를 유지한다 그곳에서 ISV는 게제된 그들의 snap-ins를 가질수 있다
마이크로소프트에 의해서 그들이 어떤 제출된 snap-ins는 MMC컨테이너에서 만들어
진 변화가 여전히 작동하는것을 확실히 하기 위해 역시 테스트 될수 있다 그러나
그것이 얻는 모든것은 ISV로부터 하나의 변화 또는 서비스팩으로부터의 하나의
변화이다 그리고 모든것이 불쑥나타난다 전반적으로 인터페이스 단순화는 칭찬할
만한 목표이다 그러나 그것은 문제 나름이다 - 너무 단순화 된것으로 그런것이
있느냐? 가정적으로 관리작업이 너무 간단하게 되는 반면에 그들 뒤에 프로그램은
너무 복잡해진다 유사성은 몇년이 지난 차에서 찾을수 있다 당신은 몇년동안 튜닝
(tune-up)이 필요하지 않은 차를 얻을수 있다 문과 창 시트동작등 모든것은 자동
이고 옵션으로 선택되어진다 그러나 어떤것이 고장날 경우 무슨일이 생기겠느냐?
그것은 더이상 차의 뚜껑을 열거나 랜치를 잡는것 같이 간단하지 않다 우리는
우리의 OS와 응용프로그램에서 같은것을 볼수 있다 SQL서버는 자동 튜닝할지
모른다 그러나 특별한 응용프로그램에서 올바르게 자동 튜닝되지 않을때 무슨일이
일어나겠느냐? Windows 2000 MMC는 사용자 계정을 다루는 snap-ins를 제공한다
그러나 설치마법사(wizards)를 제외한 많은 옵션을 주지 않는다 SMS MMC는 디폴트
셋팅에서는 존재하지 않는 부가적인 노드정보를 가진 관리콘솔을 위한 특별한
스위치를 제공한다 관리인터페이스가 너무 단순하다면 관리자는 작업을 끝내기
위해 레지스트리를 변경시켜보거나 ISQL를 사용하거나 또는 스크립트를 쓰는 다른
수단에 의지해야 한다 인터페이스를 더 단순화 할수록 더욱더 자주 정말 어려운
작업을 위해 그것을 포기해야 한다 그리고 더 자주 다른 공급자는 MMC를 사용
하거나 사용하지 않는 관리도구들을 쓰기 시작할것이다 반면에 이것은 단순한
작업를 위한 단순한 도구의 가치를 부인하지 않는다 그것은 진정한 단일화된 관리
인터페이스를 가지는 목적으로부터 더 깊이 우리를 가져간다 우리는 마이크로
소프트나 다른 소프트웨어 회사가 완벽해야 한다고 말하지 않는다 이해하기 쉽고
일관된 인터페이스 같은 그 자체의 어떤 작업을 설정할때 어떻게 그것을 전달할
수 있겠느냐? 진정 마이크로소프트가 하나를 모두에 맞춘 Microsoft Management
Console로 관통할것인가? 확인은 메일로 하라

Catherine Moya, MCSE, MCT, is a senior instructor specializing in Windows NT,
SMS, and TCP/IP courses for QuickStart Technologies, a Microsoft Certified
Solution Provider Partner. She also assists consultants in their field work.
She is the technical editor for a new Sybex book, SMS 24seven by Bill Heldman
(ISBN 0-78212-623-5, $34.99). Contact her at [email protected].

Richard White, MCSE, MCT, is a SQL Server database programmer and administrator
and an application developer in Visual Basic. Reach him at [email protected]

Thanks to Chris randall, who reviewed this article for us
 

원서의 일부가 삭제되거나 빠진점 사과의 말씀을 드립니다