AD 재해 복구에 대한 문서를 소개해 드립니다.
꽤 도움이 되는 문서네요...^^
2000 버전이지만 2003과 변경 사항은 그리 없어 보입니다.

소개
Active Directory 개요
Active Directory 백업
Active Directory 재해 복구 순서도
Active Directory 복구
글로벌 카탈로그 서버의 복구
작업 마스터 복구

https://www.microsoft.com/korea/TechNet/win2000/win2ksrv/technote/adrecov.mspx

원래 상위 디렉토리의 사용자 보안 설정은 하위 디렉토리에 적용이 되는 것이 Default 입니다.

제 디렉토리인 D:\1. Documents\2. Technical\1. SQL 을 예로 들겠습니다.
속성 > 보안 > Advanced 를 들어가시면 아래와 같은 그림을 볼 수 있습니다.

위 그림의 하단의 내용과 같이 기본 설정은 상위 디렉토리의 보안 설정을 상속 받습니다.

하지만 계별적으로 하위 디렉토리에서 권한을 설정한 경우 해당 설정이 적용되지 않습니다.
이 경우에는 상위 디렉토리로 이동하여, 강제로 사용 권한 상속을 설정해 줄 수 있습니다.

Edit 을 클릭합니다.
아래의 설정에서는 이전의 Read Write Excute 외에 상세한 권한에 대한 설정이 가능합니다.
하지만 우리가 원하는 것은 바로 하위 디렉토리의 권한이 상위 디렉토리에서 상속받게 강제로 재 설정하는 것입니다.

그렇게 하기 위해서는 아래 그림 부분의 Check box에 체크를 해줍니다.
(물론 바로 위의 Check box는 아시는 것 처럼 상위 디렉토리의 권한을 상속한다는 내용입니다.)

누구나 한번쯤은 들어봤을 MSDTC...
과연 무엇에 쓰는 물건일까?
클러스터 구성할 때 함께 구성하니깐 혹시... 클러스터의 필수 리소스 정도??

답은 땡!

아 글을 쓸려니깐 좀 답답하긴 하다...
하지만 매번 들어왔던 질문이니 만큼 한번 썰을 풀어 봐야 겠다.

Windows 진영의 미들웨어는 Com+, 와 Dcom 이다.
여기서 IIS 가 미들웨어라고 하면 정말 정말 곤란하다.

이 미들웨어라는 녀석들의 가장 큰 역활이 무엇이냐?
업무의 원자성을 보장하는 거다.
그리고 업무 원자성의 단위가 바로! "Database의 Transaction" 이다.
자바 진영에서는 지금은 어떻게 됐는지 모르지만 각각의 미들웨어들이 케시를 지니고 이런 트렌젝션을 관리 했던 것으로 알고 있다. 하지만 Windows 진영에서는 이 "Transaction" 을 Database에 온통 맞겨 버렸다.

쉽게 말해서 프로그램이 실행 될때... 로컬 컴퓨터의 DTC와 Database의 DTC가 서로 통신하면서 프로그램의 하나의 실행 단위를 마치 DB의 Transaction 처럼 보장해주는 것이다. 어차피 프로그렘 (Application)이야 Data 가공만을 담당하고 실제로는 Database에 가공된 데이터가 저장되기 때문에 이 Database에 저장되는 데이터의 Transaction 만 잘 관리하면 데이터의 원자성이 아주 잘 보전 된다는 애기다.!

자 이제 요 잘난 MSDTC 한번 열어서 구경이라도 하자!

 
[그림 1] DTC 관리 콘솔 실행]

[그림 2] DTC 관리 콘솔]

실제 DTC의 설정 자체는 그닥 별다른게 없다.
그저 Front End Tier 와 Back End Tier 사이에 DTC만 구성되어 있어면 끝이라는 점...
다만 이러한 DTC들이 통신을 하기 위해서는 RPC 통신을 위한 포트들 (135, 1024~65000) 및 SQL 이 서비스되는 포트 (1433) 이 열려 있어야 하고, Netbios Name을 통해 Ping이 되어야 한다.
위의 2가지만 충족된다면 DTC에는 그닥 설정한 것들이 별로 없다.

그리고 하나더 추가 하자면 바로 보안 설정이다.
이 보안 설정에 따라 DTC의 수행 범위가 조정되게 된다.

1. 먼저 네트워크 DTC 엑세스

Application Server의 분산 트렌젝션 요청을 처리 하기 위해서는 네트워크 DTC 엑세스가 설정되어 있어야 한다.
해당 설정이 없을 경우 DTC는 자신의 로컬 Transaction만 처리하게 된다.
밑의 클라이언트 및 관리는 그닥 필요 없다. 원격 클라이언트 허용이란 원격지 컴퓨터의 DTC를 이용한다는 것이고, 원격 관리 허용은 원격지 컴퓨터가 로컬 DTC의 여러 설정을 변경한다는 점인데... 이런 일들의 위해서는 Active Directory를 통해 상호 인증 받은 경우 (Computer 계정이 인증을 받아야 함으로)에 가능은 하지만 일반적으로 저런 설정을 사용하는 경우는 태어나 눈 씻고 찾아봐도 한번도 없었다.

2. 중요한 것은 바로 트렌젝션 관리자 통신이다.

내용은 위의 옵션을 보면 알 수 있듯이 간단하다.
인바운드는 외부에서 시작된 트렌젝션이 로컬 머신과 함께 수행 될 수 있도록 허용할 것인지 여부
아웃바운드는 내부에서 외부로 영향을 미치는 분산 트렌젝션을 허용할 것인지에 대한 허용 여부 이다.
당신의 머리속에서 드는 생각과 같이 모르면 둘다 열어주면 된다...
( 아... 이런 염치없는 나의 손가락.... 난 항상 그래왔다... 물론 인증 필요 없음 까지 클릭하곤 했지... 다시 한번 말하지만 Active Directory를 사용하지 않는 이상 Computer 인증은 불가능 하다. )

3. Unix 계열과의 통신을 위한 XA 트랜젝션의 허용도 염두에 두도록 하자.

먼저 이 XA는 SQL Server의 OLE에 준하는 Unix 계열의 분산 트렌젝션 프로토콜이다.
Unix 플랫폼에서 수행되는 DB (오라클, DB2)와 트렌젠셕을 수행하는 경우 허용해 주자.

4. 마지막으로 DTC의 서비스 계정이다.

일반적으로 위의 설정을 조정할 필요는 없다.
다만 MSCS 클러스터로 구성된 환경에서 Registry에서 권한이 없어 가끔 문제가 되는 경우가 있다.

에러를 보면 문제르 확인 할 수 있는데 Fail over 된 순간 해당 node에서 MSDTC 리소스에 대한 Registry를 권한이 없기 때문에 구성 할 수 없다는 것이다.
원본 MSDTC 이벤트 ID 4394

그런 경우에는 아래 그림에서 보는 것처럼 해당 Registry Key Full 권한을 추가하자.
HKLM\Cluster\Resources 밑에 보면 16진수의 집합으로 된 키들이 보기에 된다.
여기서 확인하다 보면 내용에 MSDTC라는 녀석들이 있는 리소스가 보이는 이 리소스에 대한 권한을 부여 하면 된다.

이렇게 해서 본인이 알고 있는 모든 MSDTC에 대한 지식을 정리해 봤다.
보통 서버를 관리하면서 모르는 문제에 부딪쳐야 하는 경우가 많다.
그저 필요한 부분만 대충 구성하고 이게 무엇에 쓰는 설정인지 어떻게 구성해야 하는지에 대한 고민 조차도 없이... 그 순간이 지나면 잊혀져 버린다.

하지만 돌아가 보자...

당신이 처음 일을 시작했을 때 그 열정으로...
나에게 필요 없지만 무엇인가에 대한 지식을 습득했다는 점 하나만으로도 충분히 즐겁지 않은가? 당신?

PS Windows 2008에서는 로깅 등의 설정을 한 화면에 할 수있게 되어 편해졌다... 만쇄~~~

정의를 갈망해야 한다.
순수한 사람은 정의를 갈망한다.

서버에서 간혹 L2 cache의 Size 를 잘못 산정하여 CPU의 Power를 충분히 활용하지 못하는 경우가 있습니다.
Windows의 구성 요소 상에서 자동으로 설정되게 되어 있으나 만약 이를 실패할 경우 256K로 고정되어 L2 Cache를 충분히 사용하지 못하는 경우가 있습니다.

L2 cache : CPU 에서 빈번하게 사용되는 데이터를 저장하는 공간으로써 Memory(RAM) 까지의 Access 시간을 줄여준다.

[설정]
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager \Memory Management\SecondLevelDataCache
REG_DWORD Range: Kilobytes 0, 1 -cache size Default: 0 (256K)

기본값은 0입니다.
해당 값이 0으로 적용되어 있으면 컴퓨터에서는 자동으로 자신의 CPU의 L2 Cache 값을 확인 한 후 적용합니다. 하지만 만약 L2 Cache 값을 확인 하지 못하는 경우 Default 로 256K를 자신의 L2 Cache의 Size로 설정합니다. CPU의 L2 Cache의 Size를 정확하게 아는 경우 해당 값을 위의 Registry에 static하게 적용할 수 있습니다. 만약 1M의 L2 Cache를 가진 CPU를 사용하는 경우 1024로 2M의 경우는 2048로 적용하시면 됩니다.

서버간 File 동기화를 위한 많은 솔루션들이 있습니다.
몰론 Disk 동기를 위한 아주 비싼 솔루션들도 있죠... 하지만 이렇게 비싼 솔루션들을 다순히 Web Server의 텐츠나 파일서버를 위하여 사용하기에는 비용상 부담이 너무 심합니다.

그래서 Windows Server에서는 DFS라는 이름으로 이런 기능을 제공 하고 있습니다.
특히 Windows 2003 R2에서는 그 기능이 더욱 발전했는데, 예를 들어 기존의 DFS가 파일의 변경이 있을 경우 해당 파일을 통으로 복제 했던 것에 비해 R2의 DFS는 해당 변경된 부분만을 동기화하는 등의 향상된 기능을 제공 하고 있습니다.

DFS를 구성하게 되면 위의 그림과 같이 데이터에 대한 동일한 Namespace로 접근하지만 실제로는 여러대의 서버가 해당 데이터들을 서비스하며 동시에 데이터의 동기화까지 책임 져주게 됩니다.

이제 DFS를 구성하는 방법을 알려 드리겠습니다.
* 중요 : DFS를 통한 파일 복제 구현을 위해서는 Active Directory 가 우선 구성되어야 합니다.
* 중요 : 하나의 DFS에서 관리되는 전체 파일 수는 20,000 개 이하로 유지해야 합니다.

[DFS 구성]관리 도구에서 분산 파일 시스템을 열어 새 루트를 만듭니다.

도메인 루트 DFS의 경우 DFS정보가 AD의 Configuration에 저장이 됩니다.
제가 알기로 독립 실행형 루트의 경우 파일 복제가 안 되는 것으로 알고 있습니다.
그래서 도메인 루트를 만들도록 하겠습니다.

루트가 될 서버를 선택합니다.

공유 디렉토리를 선택합니다.

[복제 Peer 구성]이전의 호스트와 함께 복제의 쌍으로 동작할 서버를 구성합니다. 아래 그림에서 새 루트 대상을 선택합니다.

대상을 추가합니다.

공유할 디렉토리를 선택합니다.

[복제 구성]복제 구성을 클릭하여 두 서버 사이의 복제를 구성합니다.

준비 폴더란 해당 파일들이 완벽하게 복제 되기 전 임지로 저장되는 공간입니다.

복제 토폴로지를 지정할 수 있습니다.

주의 : 아래 내용은 .net framework 1.x 를 기준으로 구성되었다.
설정 변경에 있어 주의가 요구 된다.

ASP.Net는 IIS의 요청을 Aspnet_wp.exe 프로세스가 처리한다.
즉 일반 IIS와는 달리 설정 파라메터가 전역 설정인 Machine.config 및 어플리케이션 설정인 Web.config에 저장된다. 다음은 Machine.config 및 Web.config 설정에 대한 설명이다.

구성 파라메터 설명

- maxWorkerThreads 및 maxIoThreads

ASP.NET은 사용되는 작업자 스레드와 완료 스레드의 최대 수를 제한하기 위한 설정이다.
<processModel maxWorkerThreads="20" maxIoThreads="20">
maxWorkerThreads 매개 변수와 maxIoThreads 매개 변수는 암시적으로 CPU 수를 곱한 값으로 예를 들어, 두 프로세서가 있는 경우 작업자 스레드의 최대 수는 2*maxWorkerThreads 와 같다.

- minFreeThreads 및 minLocalRequestFreeThreads

ASP.NET에는 원격 요청이나 로컬 요청을 시작하는 데 사용할 수 있는 작업자 스레드와 완료 포트 스레드 수를 결정하는 다음 구성 설정도 포함되어 있다.
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
사용 가능한 스레드가 충분하지 않은 경우 요청은 충분한 스레드를 요청에 사용할 수 있을 때까지 대기열에 저장된다. 따라서 ASP.NET은 동시에 (maxWorkerThreads*number of CPUs)-minFreeThreads 이상의 요청을 실행하지 못한다.
참고 : minFreeThreads 매개 변수와 minLocalRequestFreeThreads 매개 변수를 암시적으로 CPU 수로 곱하지 않는다.

- minWorkerThreads

ASP.NET 1.0 서비스 팩 3 및 ASP.NET 1.1부터 ASP.NET에는 원격 요청에 즉시 사용할 수 있는 작업자 스레드 수를 결정하는 다음 구성 설정이 포함되었다.
<processModel minWorkerThreads="1">
이 설정을 통해 제어되는 스레드는 CLR의 기본 "스레드 조정" 기능으로 만드는 작업자 스레드보다 훨씬 빠른 속도로 만들 수 있게 되었다. 이 설정을 사용하면 백 엔드 서버의 속도 저하, 클라이언트측으로부터의 갑작스런 요청 쇄도 또는 대기열의 요청 수를 급격히 증가시키는 것과 비슷한 원인으로 인해 ASP.NET 요청 대기열을 갑자기 채우라는 요청을 처리할 수 있다. minWorkerThreads 매개 변수의 기본값은 1이다. minWorkerThreads 매개 변수의 값을 . minWorkerThreads = maxWorkerThreads / 2 으로 설정하여 주는 것이 좋다.

기본적으로 minWorkerThreads 매개 변수는 Web.config 파일이나 Machine.config 파일에 모두 표시되지 않는다. 이 설정은 암시적으로 CPU 수를 곱한 값이다.

- maxconnection

maxconnection 매개 변수를 사용하면 특정 IP 주소에 만들 수 있는 연결 수를 결정할 수 있다.
<connectionManagement>
<add address="*" maxconnection="2">
<add address="65.53.32.230" maxconnection="12">
</connectionManagement>

이 문서 앞부분에서 설명한 매개 변수에 대한 설정은 모두 프로세스 수준이였다. 그러나 maxconnection 매개 변수 설정은 AppDomain 수준에 적용된다. 기본적으로 이 설정은 AppDomain 수준에 적용되므로 프로세스의 각 AppDomain에서 특정 IP 주소에 대한 연결을 최대 두 개까지 만들 수 있다.

- executionTimeout

ASP.NET은 다음 구성 설정을 사용하여 요청 실행 시간을 제한한다.
<httpRuntime executionTimeout="90"/>
Server.ScriptTimeout 속성을 사용하여 이 제한을 설정할 수도 있다.
참고 : executionTimeout 매개 변수의 값을 늘리는 경우 processModel responseDeadlockInterval 매개 변수 설정을 수정해야 할 수 도 있다.

권장 사항

각 ASPX 페이지에서 한 IP 주소에 대한 웹 서비스를 호출하는 경우 다음 구성 설정을 사용하는 것이 좋다.

- maxWorkerThreads 매개 변수와 maxIoThreads 매개 변수의 값을 100으로 설정
- maxconnection 매개 변수의 값을 12*N(CPU 수)으로 설정한다.
- minFreeThreads 매개 변수의 값을 88*N(CPU 수)으로, minLocalRequestFreeThreads 매개 변수의 값을 76*N으로 설정한다.
- minWorkerThreads 매개 변수의 값을 50으로 설정한다. 기본적으로 minWorkerThreads는 구성 파일에 없으므로 직접 추가해야 한다.

위의 계산식에서 하이퍼 스레딩을 활성화하는 경우 물리적 CPU 수가 아닌 논리적 CPU 수를 사용해야 한다. 예를 들어, 하이퍼 스레딩이 활성화된 네 개의 프로세서로 구성된 서버가 있는 경우, 이 공식의 N은 4가 아닌 8이 된다. 즉 이 경우 100 – 88 = 12 즉 CPU당 최대 12개의 ASP.NET 요청을 실행 할 수 있따. 따라서 최소 최소 88*N개의 작업자 스레드와 88*N개의 완료 포트 스레드를 다른 용도(예: 웹 서비스 콜백용)로 사용할 수 있다.

예를 들어 하이터 쓰레딩이 활성화된 4CPU의 서버의 경우 아래와 같은 설정값을 사용하면 된다.
<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"> <httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"> <connectionManagement> <add address="[ProvideIPHere]" maxconnection="96"/> </connectionManagement>

병목 검출을 위한 성능 카운터

출처
http://support.microsoft.com/kb/821268/ko
http://msdn.microsoft.com/en-us/library/ms998583.aspx

서버에 연결되는 Port의 숫자가 5000개 이상 (Exchange 60000) 될 경우 해당 서버가 네트워크 장애가 발생합니다.
일반적으로 WAS와 연결되는 Windows 서버 및 Exchange 서버에서 이러한 문제가 많이 발생합니다.

이런 경우 MaxUserPort 를 65534 개로 조정하여 해당 문제를 해결 할 수 있습니다.

MaxUserPort 를 65534개로 조정

1. 레지스트리 편집기를 시작합니다. 
2. 레지스트리에서 다음 하위 키를 찾은 다음 Parameters를 누릅니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

3. 편집 메뉴에서 새 값을 누르고 다음 레지스트리 항목을 추가합니다.
값 이름 : MaxUserPort
값 종류: DWORD
값 데이터: 65534

출처 : http://support.microsoft.com/kb/196271/ko