원문주소 : Group Policy Preferences Logging and Windows 7
http://blogs.technet.com/askds/archive/2009/11/19/group-policy-preferences-logging-and-windows-7.aspx
안녕하세요? 마이크(Mike)입니다. 2007년 6월에 RSAT를 사용하여 그룹정책 Preferences 디버그 로깅을 활성화시키는 방법을 설명했습니다. 새로운 내용으로 그룹정책 Preferences 디버그 로깅은 그룹정책 관리 템플릿을 통해 활성화할 수 있습니다. 많은 고객은 RSAT와 Windows Vista를 사용하여 로깅을 활성활때정책 설정이 존재하지 않는다는 문제가 발생한다고 합니다. Windows 7 RSAT를 사용할때도 같은 증상을 경험하실 겁니다.
그림 1 Windows 7 RSAT 뷰
그룹정책 Preferences 관리 템플릿은 Windows 7에 포함되어 있지 않습니다. 하지만 Windows Server 2008 R2에는 포함되어 있습니다. 간단한 솔루션은 Windows Server 2008 R2의 ADMX과 ADML파일을 Windows 7 컴퓨터에 복사하는 것입니다. 또는 이 블로그에서 파일을 복사할 수 있습니다. 이 절차는 Windows Vista에서와 같이 남아있습니다. 세부적인 절차는 2007년 6월 블로그를 확인하세요.
그림 2 Windows 2008 R2 GPMC 뷰
참고 : Vista와 Windows 7 그룹정책 Preferences 관리 템플릿 사이에는 미묘한 차이가 존재합니다. 기능상에는 변경이 없지만 많은 ADL 파일에 있는 많은 문자열이 변경되었습니다. 하나의 버전의 Windows ADML 파일과 ADMX 파일을 섞거나 일치시키지 마세요.
Mike “Neebler-Treehouse builder” Stephens
원문주소 : Default Security Templates in Windows 2008
http://blogs.technet.com/askds/archive/2008/05/28/default-security-templates-in-windows-2008.aspx
안녕하세요? 데이비드(David)입니다. 아마도 여러분은 Windows 2000과 2003에서 사용하는 보안 템플릿에 익숙하실 겁니다. 이 템플릿은 보안 구성 및 분석 도구를 사용하여 설정하거나 구성하여 서버에 설정할 수 있는 보안 설정의 마스터 셋과 같은 종류입니다. 이곳 디렉터리 서비스 팀은 적용한 보안 템플릿에 문제가 발생한 고객들과 종종 함께 작업하거나, 자신의 환경에 보안 템플릿을 구성하려는 고객들과 작업합니다.
몇 주전에, 동료중에 한명이 Windows 2008에도 같은 기능이 있는지 물었습니다. 일부 설정을 수정한 고객과 통화중이었고 응용 프로그램이 적절히 동작하지 않아 기본 설정으로 되돌릴 필요가 있는 고객이었습니다.
참고 : 이것이 테스트와 보안 설정을 변경할 때 문서화가 중요한지 권고하는 이유입니다.
물론, 답은 YES입니다.
보안 템플릿은 Windows 2008에도 여전히 존재합니다. 하지만 여러분이 짐작할 수 있듯이 조금 변경되었습니다.
Windows 2003 서버를 보면, 수많은 보안 템플릿을 볼 수 있습니다.
• Setup Security.inf
• DC Security.inf
• Compatws.inf
• Secure*.inf
• Hisec*.inf
• Rootsec.inf
• …and so on
Windows Server 2003에서 이 파일들은 다음 위치에서 찾을 수 있습니다. %systemroot%\security\templates.
(여기에 이 템플릿이 하는 동작에 대한 간단한 리스트가 있습니다)
하지만, Windows 2008 server를 볼 때, 오직 3개밖에 없습니다. 그리고 2개만이 실제로 사용됩니다.
• Defltbase.inf (not really used)
• Defltsv.inf (for servers)
• Defltdc.inf (for DCs)
Windows Server 2008에서는 이 파일은 다음 위치에 있습니다. %systemroot%\inf.
특정 업그레이드/설치 시나리오에 적용할 수 있는 몇가지 추가적인 템플릿이 있습니다. 예를 들어, dcfirst.inf는 포레스트의 첫번째 도메인 컨트롤러를 만들때 적용합니다. 주요 차이점은 계정 정책 또한 설정한다는 것입니다. 하지만, 위에 나열된 3가지는 수동적으로 적용할 수만 있는 기본 템플릿입니다.
다음에서 보안 템플릿이 어떻게 생겼는지 볼 수 있습니다.
이것은 서비스 설정의 한 부분입니다. 템플릿은 상당히 크며 사용자 권한, 서비스 설정 및 권한, 파일 시스템 권한, 레지스트리 권한, 일부 이름 등 여러가지에 영향을 줍니다. 여기서 보는 문자열은 SDDL 문자열입니다. 만약 이것에 대해 더 자세히 알고 싶다면, 짐(Jim)이 쓴 블로그를 보면(파트 1, 파트 2) 될 것 입니다.
참고 : 기본 보안 템플릿을 시스템에 다시 적용하는 것은 수행되는 사용자정의 설정을 제거할 수 있는 위험이 있습니다. 이것은 잘못된 보안 설정으로부터 야기된 문제를 해결하는데 사용되지만, 기능상의 이유로 사용자정의 설정에 의존하는 응용프로그램을 망가트리게 됩니다. 또한 이것은 만병통치약이 아닌것을 주의하세요. 보안 템플릿이 담당하지 않는 영역의 사용자정의 보안 설정은(설치 이후 생성한 데이터 볼륨) 이것으로 롤백되지 않습니다. 주의하면서 진행해야 합니다.
만약 기본 템플릿으로 머신을 되돌릴 필요가 있다면, 다음처럼 하면 됩니다. 첫번째로, MMC를 열고, 보안 설및 및 구성 스냅인을 추가합니다.
콘솔의 중간창에서 새로운 데이터베이스 권한을 만드는 방법을 알려줄 것입니다. 이 작업을 할때, 초기에 사용하기를 원하는 템플릿을 가져오는 것을 묻게 됩니다. defltsv.inf(멤버서버) 또는 defltdc.inf(DC)로 시작하세요. 한번 템플릿을 가져오면, 오른쪽 클릭을 하고, Analyze Computer Now…를 선택하세요.
이것이 스냅인의 진정한 힘입니다. 시스템을 볼수 있고 로드한 템플릿에서 무엇이 다른지 알 수 있습니다. 때때로 이것은 템플릿을 전혀 적용할 수 없다는 것을 의미합니다. 대신 문제의 원본에서 찾을 수 있는 차이는 제로일 것입니다. 다른 영역을 탐색하고 빨간 X를 보게 될 것입니다. 컴퓨터의 무엇인가 기본 템플릿과 다를 것을 알려줍니다. 다음은 어떻게 보이는지에 대한 예제입니다.
녹색 체크마크는 같다는 것을 의미하고, 빨간 X는 다르다는 것을 의미합니다. 이것은 항상 나쁜것은 아닙니다. 그것은 각각의 설정을 평가하는데 중요합니다. 이 프로세스를 진행하면 어디에 문제가 있는지 아이디어를 얻을 것이고(파일 시스템 권한, 레지스트리 권한 등), 살펴봐야할 수많은 것들의 범위를 좁힐 것입니다.
참고 : 이 설정은 그룹정책을 통해 할 수도 있습니다. 보안 템플릿을 적용하려고 시도하기 전에 컴퓨터에 적용할 정책을 확인하세요. 컴퓨터에 적용할 정책을 보고 명령 프롬프트에서 gpresult /v를 실행합니다.
자, 여러분은 이 모든 과정을 진행했고 기본 설정으로 머신을 되돌릴 필요가 있다고 생각합니다. 이제 할 일은 오른쪽 버튼을 누르고, Configure Computer Now…를 선택하는 것입니다.
설정한 것을 되돌리는 것은 쉽지 않기 때문에 이 옵션을 사용할때는 주의하세요(로그 파일과 연결시키기 위해 secedit /GenerateRollback를 먼저 사용한 후에 실행하세요. 자세한 정보는 이 링크를 보세요). 하지만 이렇게 하면, 서버는 기본 설정으로 되돌아 갈 것입니다. 그러면 기본설정으로 되돌아가고 필요할때 변경사항을 다시 실행할 수 있습니다.
서버 코어로 설치했다거나, 또는 명령 프롬프트를 선호한다면, SecEdit 명령줄 도구를 사용하여 이 모든 것을 할 수 있습니다.
보통 MMC를 사용할 것을 권장하는데, 사용하기 쉽고 차이점을 검색할 수 있는 훌륭한 방법을 제공하기 때문입니다. 하지만, 명령줄 도구는 MMC 스냅인에서 할 수 있는 모든 것을 할 수 있습니다.
보안 구성 도구는 무척 강력하고, 위에서 언급한 것들에 추가해서 자신 고유의 보안 템플릿을 만들 수 있습니다. MMC나 SecEdit 유틸리티를 통해 적용하거나 그룹정책을 통해 적용할 수 있습니다. 이것에 대해 더 자세히 알고 싶다면, TechNet에 매우 자세한 글이 있는데, 여기에서 찾을 수 있습니다.
마지막 조언은 무엇을 하든지간에, 테스트를 하고 변경사항을 문서화하라는 것입니다. 디렉터리 서비스 팀은, 서버에 보안 설정이 변경했지만 테스트하지도 않고 문서화도 안되었기 때문에 문제가 생기는 고객들과 매일 이야기합니다. 따라서 서버에 보안을 적용하는 접근은 신중하고 구조적이어야 합니다. 그러면 많은 시간을 절약할 수 있고 실제 환경에 부담을 줄이며, 문제가 발생할 때 해결을 쉽고 간단하게 합니다.
David Beach
원문주소 : Group Policy Slow Link Detection using Windows Vista and later
http://blogs.technet.com/askds/archive/2009/10/23/group-policy-slow-link-detection-using-windows-vista-and-later.aspx
안녕하세요? 마이크(Mike)입니다. 많은 그룹정책 기능은 잘 연결된 네트워크가 필요합니다. 하지만, 모든 연결이 완벽하거나 이상적일 수는 없는데 일부 연결은 느릴 것입니다. 그룹정책 인프라는 느린 링크를 검출하는 기능을 제공합니다. 하지만, 이것은 Windows Server 2008과 Windows Vista와 이전의 운영체제에서 다른 방법을 사용합니다.
Windows Server 2008과 Vista 이전 버전
Windows Server 2003, Windows XP, Windows 2000 그룹정책은 그룹정책 클라이언트와 도메인 컨트롤러 사이의 느린 연결을 결정하기 위해 ICMP 프로토콜을 사용했습니다. 이 프로세스는 다음과 같이 마이크로소프트 KB227260에 기술되어 있습니다. 사용자 프로필 및 그룹 정책 처리에 대한 느린 연결 검색(http://support.microsoft.com/kb/227260/ko)
그룹정책 인프라는 그룹정책 클라이언트에서 도메인 컨트롤러에 ICMP 핑을 연속으로 보냅니다. 첫번째 핑은 0바이트의 payload를 가지고 있고 두번째 핑은 2048바이트의 payload를 가지고 있습니다. 두 핑의 결과를 통해 계산해서, 대역폭을 예상합니다. 하지만, ICMP를 사용하는 것은 제한이 있습니다.
수많은 "나쁜" 응용 프로그램은 ICMP를 악의적으로 사용합니다. 이것은 ICMP를 증가시켰고 IT 전문가는 이것을 예방을 해야 했습니다. 예방책은 ICMP를 차단하는 것입니다. ICMP 차단하는 대안은 악의적인 ICMP 패킷을 방지했지만, 그룹정책을 막게됩니다. 따라서 다음과 같은 대안이 만들어졌습니다. (마이크로소프트 KB816045 그룹정책이 네트워크 ICMP 정책으로 적용되지 않음) 하지만 업데이트는 ICMP 의존성을 제거하기 않았습니다.
Windows Server 2008과 비스타 시대
Windows 7과 Windows Vista는 이 문제를 해결했습니다. 새로운 운영체제는 ICMP를 사용하지 않는 새로운 느린 링크 검출 매커니즘을 구현했습니다. 그러면 어떻게 새로운 그룹정책은 느린 링크를 검출할지 궁금하실 겁니다.
새로운 방식의 느린 링크를 검출하는 가장 쉬운 대답은 NLA(Network Location Awareness)입니다. 이 네트워킹 계층 서비스와 프로그래밍 인터페이스는 자신의 메소드나 알고리즘에서 구현하지 않고 응용프로그램에서 컴퓨터의 네트워크 어댑터로부터 네트워크 정보를 요청합니다. NLA는 특정 네트워크 인터페이스에서 존재하는 트래픽을 모니터링하여 이 작업을 완료합니다. 이것은 두가지 혜택을 제공합니다. 1) 이것은 대역폭 측정을 위해서 추가적인 네트워크 트래픽을 요구하지 않습니다. 2) ICMP를 사용하지 않습니다.
NLA를 통한 그룹정책
일반적으로 하는 질문은 어떻게 그룹정책 느린 연결 검출을 NLA로 구현했냐는 것입니다. NLA에서 사용하는 실제 알고리즘은 대역폭 측정을 위해 NLA에 요청하는 동안 그룹정책이 무엇을 하는지만큼 중요하지 않습니다.
도메인 컨트롤러 위치
그룹정책 클라이언트는 그룹정책을 성공적으로 적용하려면 도메인 컨트롤러와의 통신이 필요합니다. 그룹정책 서비스는 반드시 도메인 컨트롤러를 찾아야 합니다. 이것은 DCLocator 서비스를 통해 수행합니다. 윈도우 클라이언트는 일반적으로 그룹정책 응용프로그램보다 이전에 도메인 컨트롤러를 발견합니다. DCLocator는 이 정보를 캐쉬해서 다른 응용프로그램과 서비스가 사용할 수 있게 합니다. 그룹정책 서비스는 도메인 컨트롤러에 연결하기 위해 세번의 시도를 하는데, 첫번째 시도는 캐쉬에 저장된 도메인 컨트롤러 정보를 사용합니다. 두번째 시도는 DCLocator가 도메인 컨트롤러 정보를 다시 발견하도록 합니다. 캐쉬된 도메인 컨트롤러 정보를 검색은 네트워크를 가로질러 가지 못합니다. 하지만 강제로 재발견을 요청하여 확인합니다. 도메인 컨트롤러 정보는 도메인 컨트롤러의 IP 주소를 포함합니다. 그룹정책 서비스는 대역폭 측정을 시작하기 위해 도메인 컨트롤러의 IP 주소(DCLocator에서 받은)를 사용합니다.
대역폭 측정하는 동안 하는 일
그룹정책 서비스는 도메인 컨트롤러의 위치를 확인한 후에 대역폭 측정을 시작합니다. 도메인 컨트롤러 위치는 도메인 컨트롤러의 IP 주소를 포함하고 있습니다. 그룹정책 서비스는 대역폭을 측정하는 동안 다음의 동작을 수행합니다.
참고 : 이 섹션에 있는 모든 동작은 클라이언트에서 도메인 컨트롤러로 네트워크 트래픽을 발생시킵니다. 이 결과는 네트워크 트래픽을 발생하는 방식을 사용하여 수행되기 때문에 네트워크 트래픽을 발생하지 않는 작업을 포함했습니다. 이 작업은 분명히 추가됩니다.
인증
대역폭을 측정동안 수행하는 첫번째 동작은 인증된 LDAP 연결과 DCLocator 프로세스를 진행하는동안 돌아온 도메인 컨트롤러에 바인드하는 것입니다. 도메인 컨트롤러에 연결은 사용자 보안 컨텍스트와 인증을 위한 커버로스를 사용하여 실행합니다. 이 연결은 NTLM을 지원하지 않습니다. 그러므로, 이 연결 순서는 프로세스를 진행하기 위해서 그룹정책을 위한 커버로스를 사용해야 합니다. 한번 성공하면, 그룹정책 서비스는 LDAP 연결을 닫습니다.
참고 : 사용자 보안 컨텍스트는 그룹정책 프로세싱의 형태와 가깝습니다. 컴퓨터 그룹 정책을 수행을 위한 보안 컨텍스트는 컴퓨터입니다. 사용자를 위한 보안 컨텍스트는 현재 세션을 위한 현재 사용자입니다.
그룹정책 서비스는 사용자 정책 프로세싱은 루프백-교체 모드에 구성되었을때 컴퓨터로 인증된 LDAP 연결을 만듭니다.
네트워크 이름 결정
그룹정책 서비스는 네트워크 이름을 결정합니다. 이 서비스는 도메인 컨트롤러의 IP 주소로 통신하는 최적의 네트워크 인터페이스를 결정하는 것을 IPHelper API를 통해 수행합니다. 이 액션은 또한 Winsock API를 사용합니다. 하지만, 이 액션은 다른 네트워크 트래픽을 만들지 않습니다. 추가로, 도메인 컨트롤러와 네트워크 이름은 향후 사용을 위해서 클라이언트 컴퓨터의 레지스트리에 저장됩니다.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\GroupPolicy\History에 이 값이 저장됩니다. 값의 이름은 DCName과 NetworkName입니다.
참고 : NetworkName 값은 도메인 방화벽 프로필을 로드하는 것을 결정하려고 윈도우 방화벽에서 사용됩니다.
사이트 쿼리
그룹정책 프로세싱은 컴퓨터가 속한 사이트를 반드시 알아야 합니다. 이것을 수행하려고, 그룹정책 서비스는 Netlogon 서비스를 사용합니다. 클라이언트 사이트 검색은 클라이언트 컴퓨터에서 도메인 컨트롤러에 하는 RPC 호출입니다. 클라이언트 netlogon 서비스는 내부적으로 컴퓨터의 사이트 이름을 캐쉬하고 있습니다. 사이트 이름을 위한 TTL(time-to-live)은 5분입니다. 하지만, TTL은 요구할 때 종결됩니다. 이것은 클라이언트는 오직 클라이언트 검색하는 동안에만 TTL을 확인하는 것을 의미합니다. 이 확인작업은 Netlogon(그룹정책 서비스가 아님)에 의해 구현됩니다. 도메인 컨트롤러로부터 마지막으로 가져온 이름이 캐쉬된 이름이 5분보다 오래되었다면, Netlogon 서비스는 컴퓨터 사이트를 검색하기 위해 도메인 컨트롤러에 RPC 호출을 합니다. 이것은 그룹정책 프로세싱동안 RPC 호출을 볼 수 없는 이유입니다. 하지만, 네트워크 트래픽을 볼 수 있습니다.
관리 범위 결정
다음의 그룹정책 동작은 그룹정책 프로세싱 모드의 기반하여 바뀝니다. 컴퓨터 그룹정책 프로세싱은 일반 그룹정책 프로세싱을 사용합니다. 하지만, 사용자 그룹정책 프로세싱은 일반, 루프백-통합, 루프백-교체 모드를 사용합니다.
일반 모드
일반 그룹정책 프로세싱은 그룹정책 프로세싱 동작의 가장 일반적인 형태입니다. 개념적으로 사용자와 컴퓨터에 상관없이 똑같이 동작합니다. 가장 큰 차이점은 그룹정책 서비스에서 사용되는 DN(distinguished name)입니다.
OU와 도메인 리스트 생성
그룹정책 서비스는 컴퓨터/사용자의 DN을 OU와 그룹정책 개체에서 찾을 수 있는 도메인의 리스트를 결정하기 위해서 사용합니다. 그룹정책 서비스는 왼쪽에서 오른쪽으로 DN을 분석하면서 리스트를 만듭니다. 이 서비스는 이름의 OU= 의 각 인스턴스의 이름을 찾아 스캔합니다. 그리고나서 DN을 리스트에 복사하고, 나중에 사용합니다. 그룹정책 서비스는 OU가 첫 DC= 인스턴스를 만날때까지 DN 스캔을 계속합니다. 이 부분에서, 그룹정책 서비스는 목록을 완료할 도메인 이름을 찾습니다. 이 동작은 네트워크 트래픽을 발생시키지 않습니다.
예 : 다음은 주어진 DN의 목록입니다.
Distinguished Name:
cn=user,OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
List:
OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
OU=hq,DC=na,DC=contoso,DC=com
DC=na,DC=contoso,DC=com
관리 범위 평가
그룹정책 서비스는 그룹정책 객체가 각 관리범위에 링크되고 옵션이 각 링크에 연결되었는지 결정하기 위해 OU의 리스트를 사용합니다. 서비스는 이전에 검색된 도메인 컨트롤러에 단일 LDAP 쿼리를 사용하여 연결된 그룹정책 객체를 결정합니다.
LDAP 요청은 베이스, 범위, 필터, 속성의 4가지 주요 구성요소로 되어 있습니다. 베이스는 검색을 시작할 수 있는 디렉터리 내의 위치를 지정하는데 사용하는데, 일반적으로 DN으로 표시합니다. 범위는 디렉터리 내에서 검색을 어디까지 할지 결정하는데, 베이스에서 시작합니다. 옵션은 베이스, 한 단계, 하위트리를 포합합니다. 베이스 범위 옵션은 베이스에 일치하는 필터에 일치하는 객체만을 반환합니다. 한 단계 옵션은 베이스보다 한단계 아래에 있는 객체를 반환하지만, 베이스를 포함하지 않습니다. 하위트리 옵션은 베이스로부터 베이스 아래에 있는 모든 수준의 객체를 반환합니다. 필터는 검색할때 어떤 객체를 반환할지 지정하는 방법은 제공합니다(LDAP 검색 필터 문법에 대한 자세한 정보는 MSDN을 참조하세요). 속성 설정은 필터와 일치하는 객체를 발견하면 반환해야 할 속성의 리스트입니다.
서비스는 다음의 구분으로 LDAP 요청을 만듭니다.
BaseDN: domain
Scope: Sub Tree
Filter: (|(distinguishedname=OU=xxx)( more OUs)(ends domainNC DC=))
Attributes: gpLink, gpOptions, ntSecurityDescriptor
Example: Scope of management LDAP search
BaseDN: DC=na,DC=contoso,DC=com
Scope: SubTree
Filter: (|(distinguishedname= OU=marketing,OU=hq,DC=na,DC=contoso,DC=com)
(distinguishedname =OU=hq,DC=na,DC=contoso,DC=com)
(distinguishedname =DC=na,DC=contoso,DC=com))
Attributes:gPlink,gPoptions,nTSecurityDescriptor
일반적인 그룹정책 프로세싱 모드의 범위를 결정하는 것은 보안 원리를 적용하는 보안 컨텍스트에서 발생합니다. 컴퓨터는 LDAP 쿼리 컴퓨터 프로세싱을 수행하고 사용자는 사용자 프로세싱을 위한 LDAP 쿼리를 수행합니다. 통합하고 변경하는 것은 사용자 프로세싱 모드에서만 있는데, 사용자의 보안 컨텍스트로 실행됩니다.
사용자 프로세싱을 교체하는 것은 컴퓨터의 DN을 사용하여 LDAP 쿼리를 수행합니다. DN의 각 구성요소는 LDAP 쿼리의 필터 부분에 삽입됩니다. LDAP 쿼리 필터 파라미터는 도메인 컴퓨터의 DN으로 끝납니다.(컴퓨터의 DN의 일부분을 사용하여 재구성합니다)
사용자 프로세싱 통합은 두개의 LDAP 쿼리를 수행합니다. 첫번째 LDAP 쿼리는 사용자 객체의 DN을 사용합니다. 두번째 쿼리는 컴퓨터 객체의 DN을 사용합니다. 그룹정책 링크는 하나의 리스트로 통합된 쿼리로 반환됩니다. 그룹 정책 서비스는 사용자 쿼리로부터 반환된 그룹정책 링크 리스트의 끝에 컴퓨터 쿼리에서 반환된 그룹정책 링크를 추가하여 리스트를 통합합니다. 사용자 리스트의 끝에 컴퓨터 리스트와 연결시켜서 그룹정책 링크는 순서대로 리스트됩니다.
링크 상태 검출
그룹정책 서비스는 클라이언트 컴퓨터와 도메인 컨트롤러 사이의 링크 상태를 결정할 준비가 되었습니다. 서비스는 NLA에게 초기 그룹정책 동작이 실행되기 전에 짐작되는 대역폭을 요청합니다. 그룹정책 서비스는 NLA가 GroupPolicyMinTransferRate 갑에 반환한 값을 비교합니다. 그 값은 다음의 위치에 저장되어 있습니다. HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon, 이것은 선호되는 키이고, HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System 이것은 정책 키입니다. 그룹정책 느린 링크를 측정하는 기본 최소 전송률은 500 (Kbps)입니다. 만약 NLA가 반환한 예측된 대역폭이 레지스트리에 저장된 값보다 작으면 도메인 컨트롤러와 클라이언트 사이의 링크는 느린 것입니다. 만약 레지스트리에 두 값이 있다면 정책 값은 처음 위치를 선택합니다. 링크 상태를 성공적으로 결정한 이후에는(빠르거나 느린), 그룹정책 서비스는 느린 링크 상태를 그룹정책 히스토리에 저장하는데 이 값은 레지스트리에 있습니다. 이름은 IsSlowLink이고 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\GroupPolicy\History에 위치합니다. 이 값은 REG_DWORD이며 부울 값으로 해석됩니다. 0이 아니면 거짓, 0이면 참입니다. 만약 그룹정책 서비스에 에러가 발생한다면, 히스토리 키의 마지막 값을 읽고 느린 링크 검출을 위해 거짓 또는 참값을 사용합니다.
결론
그룹 정책 느린 링크 검출은 ICMP를 사용한 느린 링크 검출의 시대 이후에 성숙했습니다. 오늘날에서는, Windows 7과 Windows Vista의 그룹 정책 서비스는 추가적인 네트워크 트래픽없이 클라이언트와 도메인 컨트롤러 사이의 TCP 통신을 샘플링하기 위해서 NLA를 사용합니다.
- Mike “Huuuh, whaaaa?” Stephens
원문주소 : So You Want to Upgrade to Windows 2008 Domain Controllers (ADPREP)
http://blogs.technet.com/askds/archive/2008/11/11/so-you-want-to-upgrade-to-windows-2008-domain-controllers-adprep.aspx
안녕하세요? 롭(Rob Newhouse)입니다. 오늘은 여러분의 도메인을 Windows Server 2008로 업그레이드하고 어떤 절차와, 이전을 부드럽게 할 수 있는 여러 팁에 대해 이야기하겠습니다.
이 글은 ADPREP의 적절한 사용법과 그것을 실행할 때 무엇을 기대할 수 있는지 보여줄 것입니다.
ADPREP은 Windows Server 2008에서 4단계로 나눌 수 있는데, 2단계는 Windows Server 2003을 업그레이드했을 때 익숙한 단계였을 것입니다. 4단계는 포레스트 준비, 도메인 준비, 그룹정책 준비 그리고 읽기전용 도메인 컨트롤러 준비(RODC를 사용하기 원할 경우)로 구성됩니다. ADPREP.exe를 사용하여 이 모든 단계를 수행할 수 있습니다.
ADPREP /forestprep 실행 준비
ADPREP /forestprep는 스키마에 변경을 줍니다. 성공적으로 실행하기 위해서는 다음과 같이 합니다.
1. 포레스트에 있는 모든 도메인 컨트롤러에 시스템 상태 백업을 하거나, 포레스트에 있는 도메인 컨트롤러중에 적어도 하나는 시스템 상태 백업을 합니다.
2. 도메인 관리자, 스키마 관리자와 엔터프라이즈 관리자 그룹에 속해있는 사용자로 로그온합니다.
3. 포레스트에 있는 모든 도메인 컨트롤러가 Windows 2000 SP4 또는 이상의 버전인지 확인합니다.
4. 스키마 마스터에서 ADPREP /forestprep를 실행합니다.
5. 여러분에 환경에 Exchange 2000 을 실행하고 있다면 Windows 2000 도메인 컨트롤러를 Windows Server 2003으로 업그레이드하기 위해 KB325379를 참고합니다.
6. 전체 포레스트에 복제가 동작하는지 확인합니다. 모든 도메인 컨트롤러가 실행되고 스키마 파티션을 위해 스키마 마스터가 완벽한 복제 주기를 수행하는지 확인합니다.
그럼 전체 준비 단계를 자세히 살펴보겠습니다.
1. 첫단계로 Windows 백업(NTBackup)이나 타사 백업도구를 사용하여 모든 도메인 컨트롤러에서 시스템 상태를 백업합니다. 이것은 스키마가 호환되지 않거나 이전 상태로 롤백할 때 필요한 단계입니다.
2. 다음으로, 계정이 적절한 그룹 멤버쉽을 가지고 있는지 확인합니다. Active Directory 사용자 및 컴퓨터를 열고, 업그레이드를 원하는 계정에서 오른쪽 클릭을 하고 속성을 선택합니다. Member Of tab 탭을 선택합니다. 도메인 관리자, 엔터프라이즈 관리자와 스키마 관리자를 볼 수 없다면, 없는 계정을 추가합니다. 로그오프하고, 이 그룹이 보안 토큰에 있는지 검증하기 위해 whoami /groups 명령을 실행합니다.
3. 최소환 Windows 2000 SP4에서 실행되는지 확인하기 위해 ADPREP /forestprep를 사용합니다. Windows 2000 도메인 컨트롤러가 있다면 SP4로 업그레이드해야 합니다. Windows 2000 Service Pack 4 는 링크에서 다운로드 할 수 있습니다.
4. 다음으로, 스키마 마스터에 로그온할 수 있는지 확인합니다. 두가지 방법이 있습니다. 하나는 regsvr32 schmmgmt.dll을 실행해서 Active Directory 스키마 스냅인을 로드할 수 있습니다. 새로운 MMC를 열고 Active Directory 스키마를 추가합니다. Active Directory Schema에서 오른쪽 클릭을 하고 Operations Master를 선택합니다.
다른 방법은 명령 프롬프트에서 netdom query fsmo를 실행하는 것입니다. Netdom은 Windows Server 2003 지원 도구에 포함되어 있습니다.
5. Windows 2000과 Exchange 2000을 사용하는 환경에서 업그레이드할 때 알려진 이슈가 있습니다. 업그레이드 과정에 발생할 수 있는 문제는 KB325379에 다른 단계와 시나리오로 기술되어 있습니다. 이 시나리오 중 한가지를 실행할 수 있습니다. 어떤 시나리오를 선택할지는 여러분의 선택입니다.
6. 마지막 검증작업은 복제가 정상적으로 동작하는지 확인하는 것입니다. Windows Server 2003 지원도구가 설치되어 있지 않다면 설치하세요. 명령 프롬프트에서 repadmin /showreps를 실행합니다.
Last attempt @ date\time was successful을 볼 수 있습니다. ADPREP /forestprep를 실행하기 전에 어떤 오류도 없었습니다.
참고 : ADPREP /forestprep는 스키마 마스터에서 복제가 동작하는지만 확인합니다. 그것은 모든 DC의 복제 상태를 확인하지 않습니다. Repadmin /showreps는 선택한 DC만을 확인합니다. 전체 환경을 확인하기 위해서는 repadmin /replsum을 실행하세요. 이 명령어는 전체 환경의 상태를 나타냅니다. ADPREP /forestprep를 실행하기전에 복제 오류를 고치기를 원할 것입니다.
ADPREP /forestprep 실행
1. 이제 forestprep를 할 준비가 되었습니다. 이 절차는 컴퓨터의 속도에 달려있는데 중간에 중지하면 안됩니다. Windows Server 2008 DVD를 스키마 마스터의 DVD 드라이브에 넣습니다.
2. 명령 프롬프트를 엽니다.
3. 드라이브 문자를 DVD 드라이브로 변경합니다. 스키마 마스터에 DVD 드라이브가 없다면 Sources\Adprep 폴더를 열고 복사할 수 있습니다.
4. Sources\Adprep 디렉토리로 변경합니다.
5. ADPREP /forestprep을 실행합니다.
6. Windows 2000 SP4 혹은 이후 버전이 필요하다는 경고창이 나타납니다.
7. C를 입력하고 엔터를 누르세요
8. LDF 파일로부터 업데이트들을 볼 수 있습니다.
9. 다 되었다면, ADPREP에서 포레스트 전반에 정보를 성공적으로 업데이트한 것을 볼 수 있습니다.
ADPREP /domainprep 실행 준비하기
ADPREP /forestprep을 성공적으로 수행하였다면, ADPREP /domainprep을 실행할 준비가 된 것입니다. ADPREP /domainprep은 업그레이드를 원하는 각 도메인에서 실행해야 합니다.
사전 준비사항
ADPREP /domainprep을 실행하기 위해서는 다음과 같이 해야합니다.
1. 성공적으로 ADPREP /forestprep을 완료합니다.
2. 실행하고자하는 도메인의 도메인 관리자여야 합니다.
3. Windows 2000 네이티브 모드 도메인 기능 수준이이야 합니다.
4. 인프라스트럭처 마스터에 접근할 수 있어야 합니다.
5. 스키마 변경이 환경에 복제될까지 기다리거나, 적어도 인프라스트럭처 마스터는 스키마 업데이트가 복제되어야 합니다.
참고 : Windows 2000으로부터 업그레이드하는 것은 지원하지 않습니다. 자세한 내용은 Windows 2008로 업그레이드 가이드를 참고하세요.
ADPREP /Domainprep 실행
1. Windows Server 2008 DVD을 넣으세요.
2. 명령 프롬프트를 엽니다.
3. 드라이브 문자를 DVD 드라이브로 바꿉니다.
4. Sources\Adprep 디렉터리로 이동합니다.
5. ADPREP /domainprep를 실행합니다.
ADPREP /Domainprep 명령이 실행되는 동안 무엇이 발생하는지 알기 위해서는, Windows Server 2003 SP1에서 ADPREP.exe 개선사항(Q324392)를 참조하세요. 추가 정보 절에 Windows 2003 SP1이후에 기능과 Windows 2008 ADPREP이 기술되어 있습니다.
ADPREP /domainprep /gpprep 실행 준비
ADPREP /domainPrep /gpprep은 Sysvol 공유에 있는 그룹 정책 개체에 상속할 수 있는 액세스 컨트롤 엔트리만을 추가합니다. adprep /domainprep을 실행하기 이전에 실행한다면, 두가지 기능을 실행하는데, 첫번째로 domain prep를 실행하고 두번째로 GP prep을 실행합니다.
사전준비사항
ADPREP /domainprep /gpprep를 실행시키기 위해서는 다음을 해야합니다.
1. ADPREP /domainprep의 사전준비사항을 모두 마쳐야합니다.
2. Sysvol\Sysvol\Policies\{Default Domain and Default Domain Controller GPO guids}이 있어야 합니다.
a. 윈도우 익스플로러에서 Sysvol\Sysvol\Domain\Policies 폴더로 이동합니다.
b. 다음의 GUID가 있는지 확인하세요.
{31B2F340-016D-11D2-945F-00C04FB984F9}
{6AC1786C-016F-11D2-945F-00C04FB984F9}
참고 : Windows 2000으로부터 업그레이드하는 것은 지원하지 않습니다. 자세한 내용은 Windows 2008로 업그레이드하기를 참고하세요.
ADPREP /domainprep /gpprep 실행하기
1. Windows Server 2008 DVD를 넣으세요.
2. 명령 프롬프트를 엽니다.
3. 드라이브 레터를 DVD 드라이브로 변경합니다.
4. Sources\Adprep로 이동합니다.
5. ADPREP /domainprep /gpprep를 실행합니다.
adprep /domainprep 실행없이 ADPREP /domainprep /gpprep 먼저 실행하기
adprep /domainprep를 실행한 후에 ADPREP /domainprep /gpprep 실행하기
ADPREP /rodcprep 실행 준비하기
RODC(Read-Only Domain Controllers)는 Windows Server 2008에 추가된 새로운 멋진 기능입니다. 특정 도메인 구성에서 RODC의 혜택은 그것을 학습하고 구현하는데 노력은 가치가 있습니다. 혜택에 대한 자세한 정보는, TechNet에서 RODC 기능을 참조하세요. 여러분의 환경에 RODC를 적용할 의도가 있다면 ADPREP /rodcprep를 실행해야 합니다. 이 명령어는 Active Directory의 파티션을 준비해서 RODC가 ForestDNS, DomainDNS, Domain 파티션에 보안을 추가하여 사용할 수 있게 됩니다.
사전준비사항
ADPREP /domainprep /rodcprep을 실행하기 위해 필요한 사항입니다.
1. 도메인 관리자와 엔터프라이즈 관리자이어야 합니다.
2. 포레스트의 모든 인프라스트럭처 마스터 역할을 연결될 수 있어야 합니다.
참고 : ADPREP /rodcprep은 최초에 ADPREP /forestprep과 ADPREP /domainprep,없이 실행할 수 있지만, 권고하지 않습니다.
ADPREP /rodcprep 실행
1. Windows Server 2008 DVD를 넣습니다.
2. 명령 프롬프트를 엽니다.
3. 드라이브 문자를 DVD 드라이브로 변경합니다.
4. Sources\Adprep 디렉터리로 변경합니다.
5. ADPREP /domainprep /rodcprep를 실행합니다.
ADPREP 실행에 대해 살펴보았습니다. 위의 단계를 순서대로 실행하면 많은 문제를 제거할 수 있습니다.
- Rob Newhouse
Windows 7 에서 사용할 수 있는 몇 가지 단축 키를 소개합니다.
실시간 파일 시스템 동작, 레지스트리, Process 나 Thread 들의 동작 등을 모니터링 하는데 사용하는 Process Monitor 툴 (기존 File monitor, Registry monitor, Process monitor 의 기능이 합쳐진 툴) 은 잘 알고 계실 것입니다. 가끔, 이 프로그램을 실행할 수 없는 부팅 과정에서 부팅이 완료된 시점 또는 그 이후 특정 시점까지의 Activity들에 대한 동작을 보기 위해서는 어떻게 할까요? 바로 이 툴 안에 해당 기능이 포함되어 있습니다.
사용 시나리오: Boot 과정에 성능 이슈가 발생할 경우 로그 수집
1. Process Monitor 툴 실행 후 Options – Enable Boot Logging 을 선택합니다.
2. Enable Boot Logging 을 선택하면 다음 부팅 동안 로그가 수집됨을 알리는 창이 표시됩니다.
3. 시스템이 재 시작되면 이 과정에는 Process Monitor 툴에 의한 로그가 수행되고 있습니다.
4. 부팅 이후 수집된 로그를 확인/저장하기 위해 Process Monitor 툴을 다시 실행합니다. 이 때, 아래와 같은 메시지 창이 뜹니다. “예”를 눌러 저장합니다.
저장 형식은 .PML 이며, Process Monitor 툴에서 로그를 확인합니다.
원문주소 : Forced Demotion of a Windows Server 2008 Core Domain Controller
http://blogs.technet.com/askds/archive/2008/11/14/forced-demotion-of-a-windows-server-2008-core-domain-controller.aspx
네드(Ned)입니다. 오늘의 글은 짧지만 유용합니다. 이 글이 필요한 상황에서 빠르게 작업할 수 있습니다. 관련된 내용은 TechNet에 아직 없습니다(작성중입니다).
Windows 2000 SP4 이후에, DCPROMO /FORCEREMOVAL 명령어를 사용하여 도메인 컨트롤러를 내리는 것이 가능해졌습니다. 다음과 같은 경우에 이 스위치를 사용할 수 있었습니다.
l 중간의 자식 도메인에 있는 가장 마지막 도메인 컨트롤러를 내릴 때 부모 도메인에 현재 가용한 도메인 컨트롤러가 없을 경우
l 세부적인 트러블슈팅을 진행한 이후에 이름 해석, 인증, 복제 엔진, 또는 해석할 수 없는 Active Directory 객체 의존성이 있기 때문에 Active Directory 설치 마법사를 완료할 수 없는 경우
l 도메인 컨트롤러가 하나 또는 그 이상의 네이밍 컨텍스트를 위한 날짜의 Tombstone Lifetime 번호(기본 60일) 에서 들어오는 Active Directory 변경을 복제하지 못했을 경우(KB216993)
l 도메인 컨트롤러 서비스를 즉시 시작해야 하기 때문에 더 이상 자세한 문제해결이 어려울 경우
자연스럽게 항상 다른 DC들에서 Metadata Cleanup을 수행하게 됩니다.
하지만, 코어 모드(GUI없음)에서 동작하는 Windows Server 2008 DC에서 이 명령어를 수행하려고 하면, 다음과 결과를 반환할 것입니다.
Answer file이나 무인 설치 명령줄 매개변수는 반드시 기술해야 합니다.
Answer file을 제공했더라도, 도메인을 내리는 것을 확인하는 여러가지 프롬프트와 공지가 나타납니다.
그렇다면 어떻게 이 작업을 할 수 있을까요? 다음 명령어를 사용하면 됩니다.
dcpromo /forceremoval /demotefsmo:yes /administratorpassword:<the new password>
예제 :
dcpromo /forceremoval /demotefsmo:yes /administratorpassword:Password1
다음과 같은 질문들이 있었습니다 "하지만 이 서버는 FSMO 역할을 가지고 있지 않습니다. 왜 제가 스위치를 추가해야 하나요? 그 이유는 내리는 것을 강요할 때 FSMO 역할을 함께 주면, FSMO 경고 프롬프트를 막을 수 있기 때문입니다.
이 글에 대해 강력한 제목을 붙이려고 했지만, 실제로 이것이 필요한 대부분의 독자는 굉장히 바빠서 그것을 원하지 않는 것을 알았습니다.
- Ned Pyle
원문주소 : Fail to log Security Settings from Default Domain Policy
http://blogs.technet.com/askds/archive/2008/09/22/fail-to-log-security-settings-from-default-domain-policy.aspx
안녕하세요? 여러분. 스캇(Scott Goad)입니다. 오늘은 기본 도메인 정책에서 보안 설정을 기록하는 것을 실패한 최근 사례에 대해 이야기를 잠시 나눠볼까 합니다. 이 경우에, 2대의 도메인 컨트롤러를 가지고 있는 작은 환경이었고, 모두 FSMO 역할을 가지고 있었으며, 다른 하나는 복제대상 도메인 컨트롤러였습니다.
이슈는 내부 감사를 하는 동안 알려졌고, 고객은 특정 보안 설정이 GPRESULT /v를 실행할때 기록되지 않는 것을 알게되었습니다. 여기서 GPRESULT /v는 특정 사용자와 컴퓨터에 대한 세부적인 정책 결과를 표시합니다. 이슈를 해결하기 위하여 자료를 충분히 수집했는데, 일부 아이템은 기본 도메인 정책에서 생략되었고, 오류는 기록되지 않았습니다
도메인 컨트롤러를 멤버서버로 내리고나서, 정책이 적용되고 정확히 리포트되었습니다.
다음은 각 도메인 컨트롤러의 일부입니다.
...DC1의 GPRESULT 중 일부(FSMO 아님)...
Account Policies
----------------
GPO: Default Domain Policy
Policy: MaxServiceAge
Computer Setting: 600
GPO: Default Domain Policy
Policy: MaxTicketAge
Computer Setting: 10
GPO: Default Domain Policy
Policy: MaxClockSkew
Computer Setting: 5
GPO: Default Domain Policy
Policy: MaxRenewAge
Computer Setting: 7
...DC2의 GPRESULT 중 일부(FSMO임)...
Account Policies
----------------
GPO: Default Domain Policy
Policy: MaxServiceAge
Computer Setting: 600
GPO: Default Domain Policy
Policy: MaxTicketAge
Computer Setting: 10
GPO: Default Domain Policy
Policy: MinimumPasswordAge
Computer Setting: 1
GPO: Default Domain Policy
Policy: PasswordHistorySize
Computer Setting: 6
GPO: Default Domain Policy
Policy: LockoutDuration
Computer Setting: 4294967295
GPO: Default Domain Policy
Policy: ResetLockoutCount
Computer Setting: 30
GPO: Default Domain Policy
Policy: MaxClockSkew
Computer Setting: 5
GPO: Default Domain Policy
Policy: MinimumPasswordLength
Computer Setting: 8
GPO: Default Domain Policy
Policy: LockoutBadCount
Computer Setting: 3
GPO: Default Domain Policy
Policy: MaximumPasswordAge
Computer Setting: 90
GPO: Default Domain Policy
Policy: MaxRenewAge
Computer Setting: 7
또한, 두대의 도메인 컨트롤러에서, 이벤트 ID 1704가 기록되었습니다.
여기서, 기본 도메인 정책을 살펴봤는데, 설정은 다음과 같습니다.
이슈를 조사한 이후에, 로컬 보안 정책을 살펴보고, 실제로 무엇이 적용되었는지 보았습니다. 다음은 GPRESULT에서 나타난 실패한 부분입니다.
이 화면은 정책에 변경을 준 후에 다른 서버에서 찍은 것입니다. 여기에서, 설정이 적용된 것을 알았지만, 어디에도 기록되지 않았습니다. 그래서 GES(Global Escalation Services) 팀에 살펴보도록 요청했습니다. PDC 에뮬레이터를 다른 DC에 옮겼는지 확인을 요청했고, 변경을 발견했습니다. 그렇습니다! GPRESULT의 이 정책 설정은 PDC 에뮬레이터 역할을 따라갑니다.
GES는 코드를 리뷰하고 이것은 설계된 동작이라고 했습니다. PDC 에뮬레이터에서, 멤버 서버와 도메인에 조인된 워크스테이션은 그룹정책을 통해 이 정책을 적용합니다. 도메인의 복제대상 도메인 컨트롤러는 도메인 네임 컨텍스트 앞부분에 있는 것을 모니터링하여 이 설정을 적용합니다. 이 설정은 포레스트의 각 도메인의 도메인 컨트롤러간에 Active Directory 복제를 통해 복제됩니다. 이 설정은 도메인 컨트롤러가 살펴서 동작방식을 제어하는 것을 도와줍니다. 이 설정이 변경되면, DC는 즉시 알게되고 새로운 동작을 시작합니다.
다음은 속성의 전체 리스트입니다.
l minPwdAge
l pwdHistoryLength
l lockoutDuration
l lockOutObservationWindow
l minPwdLength
l lockoutThreshold
l maxPwdAge
l pwdProperties (this is complexity on/off)
이 설정은 아래와 같이 LDP로 볼 수 있습니다.
Expanding base 'DC=adatum,DC=com'...
Result <0>: (null)
Matched DNs:
Getting 1 entries:
>> Dn: DC=adatum,DC=com
3> objectClass: top; domain; domainDNS;
1> distinguishedName: DC=adatum,DC=com;
1> instanceType: 0x5 = ( DS_INSTANCETYPE_IS_NC_HEAD | IT_WRITE );
1> lockoutDuration: 1800;
1> lockOutObservationWindow: 1800;
1> lockoutThreshold: 0;
1> maxPwdAge: 3710851;
1> minPwdAge: 86400;
1> minPwdLength: 7;
1> modifiedCountAtLastProm: 0;
1> nextRid: 1006;
1> pwdProperties: 1;
1> pwdHistoryLength: 24;
다음에 뵙겠습니다.
- Scott “Scooter” Goad
Windows 상의 오류 코드가 무엇을 의미하는가?
Header 없이도 해당 코드의 의미를 알 수 있도록 외부에 Freeware 툴로 제공된 것이 있어서 소개합니다.
http://www.easyfreeware.com/files/hr_plus.zip/14336
Windows Server 2008 / 2008 R2 의 Hyper-V 에는 Snapshot 기능을 포함하고 있습니다.
Snapshot 은 어느 시점 상태로 되돌아 갈 수 있는 VM의 Point in time 이미지들을 말하는 것입니다. 이것은 현재의 VM 상태 (VHD)를 보존하는 상태에서 별도의 Differencing disk file인 .AVHD 파일을 생성하므로서, 현재 Snapshot 상태에서 Windows작업 중에 어떠한 문제가 있을지라도 이 작업을 무시하고 이전으로 되돌아 갈 수 있는 이전 VM 파일의 안전성을 보장합니다.
즉, 번거로운 프로그램을 테스트 작업을 자주 진행하는 개발자 또는 예기치 않은 문제를 야기시킬 수 있는 Hotfixes, Updates 설치 등을 담당하는 시스템 관리자들에게는 유용한 기능입니다.
Snapshot 은 Online 또는 Offline VM 의 Snapshots 을 생성할 수 있습니다. Online VMs 의 경우 Snapshots 은 VM의 Worker process 에 의해 처리되며, Offline VMs의 경우 Snapshot 은 VMMS 내의 Snapshot manager 에 의해 처리됩니다. Snapshot 이 만들어 질 때 아래의 과정이 수행됩니다.
1. 지정된 위치에 현재 .퐁 파일의 Differencing hard disk 이미지인 .avhd 파일이 생성됩니다.
2. 새로운 Snapshot configuration (<GUID.xml) 이 생성됩니다.
3. VM configuration을 Snapshot configuration 파일에 복사합니다.
4. Saved state file (<GUID>.vsv) 을 복사하고 이것을 Snapshot configuration 에 Attach 합니다.
5. 새로운 <GUID>.bin 파일을 생성하고, 메모리의 내용을 이 파일에 복사합니다.
그럼 Snapshot 을 만들어질 경우 VM 파일과 Snapshot 파일이 어떻게 생성되는지 보겠습니다.
Snapshot 이 없는 상태
Snapshot #1생성
Snapshot #2 생성
Snapshot #3 생성
VM의 .bin, .vsv 파일들은 변경되지 않고 있습니다.
VM Client 를 시스템 종료 후 10여분 후 다시 켰을 때는 마지막 AVHD 파일만 변경되고 있습니다.
Snapshot #1으로 이동
Snapshot #1삭제 (Snapshots 폴더 하위 11C6C089-… 가 제거됨)
“Delete Snapshot Subtree” 로 모두 삭제
원문주소 : BitLocker and Active Directory
http://blogs.technet.com/askds/archive/2009/08/18/bitlocker-and-active-directory.aspx
안녕하세요? 디지털 세상의 폴(Paul Fragale)입니다. 오늘은, BitLocker에 대한 정보와 Active Directory (AD)에 키를 저장하고 복구하는 방법을 공유하겠습니다. 실제로 AD에는 무엇이 만들어질까요? 드라이브를 암호화하고 복호화할 때 어떤 일이 발생할까요? 추가 드라이브는 무엇일까요? AD에 복구 정보를 복사하려고 그룹정책을 적용하기 전에 드라이브가 암호화되면 어떻게 할까요?
시작해보죠. 이 글에서는 Windows Vista와 2008에 초점을 맞추겠습니다. 그룹 정책은 클라이언트가 BitLocker 복구 정보를 Active Directory에 보내는 데 필요합니다. 이것을 설정하려면 Active Directory를 Windows BitLocker 드라이브 암호화에 백업하도록 구성하기와 TPM(Trusted Platform Module) 복구 정보를 살펴보세요. 기억할 점은, 드라이브가 암호화되기 전에 필요하다는 것입니다. 정책이 컴퓨터에 적용되기 전에 드라이브가 암호화되면, BitLocker 복구 정보가 AD에 업로드되지 않습니다. 유일한 해결방법은 복호화하고 정책이 적용된 이후 다시 암호화하는 것입니다.
그룹 정책이 한번 구성되면, 컴퓨터에서 암호화 프로세스를 수행할 수 있습니다. 복구 정보가 Active Directory에 저장되는 것을 보증하기를 원한다면, 수동으로 확인할 필요가 있습니다. Active Directory의 컴퓨터 객체 아래에서 자식 객체로 드라이브 암호화가 만들어집니다. BitLocker 복구 객체의 이름은 고정된 63글자로 GUID(globally unique identifier)와 날짜/시간 정보를 가지고 있습니다. BitLocker 복구 객체의 클래스는 ms-FVE-RecoveryInformation 입니다. 이 객체 내부에는 bitlocker 복구에 필요한 속성이 있습니다. 다음은 드라이브를 암호화하면 컴퓨터 객체 아래에서 볼 수 있는 내용입니다.
LDP를 사용하여 무엇이 포함되어 있는지 다음과 같이 볼 수 있습니다.
이 속성의 설명은 Active Directory에서 Windows BitLocker 드라이브 암호화에 백업하는 것을 구성하기와 TPM(Trusted Platform Module) 복구 정보에서 찾을 수 있습니다.
자 그럼, BitLocker를 구현한 후에 Active Directory에서 무엇을 봐야하는지 알 것입니다. 관리자 관점에서 논의를 해보죠. 드라이브를 암호화하면 어떻게 될까요? 무엇보다도, AD는 저장 컨테이너입니다. 이 정보를 업데이트하고, 검증하고, 관리하는 것을 수행할 기능은 하나도 없습니다. 이것은 완전히 BitLocker에 의해 다뤄집니다. BitLocke는 AD에 드라이브 암호화를 알려주지 않고 ms-FVE-RecoveryInformation 객체는 지워지지 않습니다. 사용자가 다시 드라이브를 암호화하면, Bitlocker는 AD에 새로운 정보를 동기화시킵니다. 따라서 같은 드라이브에 대한 두 개의 엔터티를 볼 수 있습니다. 더 나아가 시스템에 암호화된 각 드라이브의 새로운 엔트리를 볼 수 있습니다.
기억할 점은 다음과 같습니다.
1. 모든 암호화된 드라이브는 새로운 자식 객체를 만듭니다. 이것은 추가 드라이브를 포함합니다.
2. Active Directory에 복구 정보를 저장하는 그룹정책은 첫번째 드라이브가 암호화되기 전에 컴퓨터에 구성되고 적용되어야 합니다.
3. 드라이브를 복호화하면 Active Directory에 Bitlocker 복구 정보는 그대로 남게 됩니다. 업데이트되지 않습니다. 드라이브가 나중에 다시 암호화되면, 새로운 자식 객체가 생성됩니다. 현재의 ms-FVE-RecoveryInformation 객체는 삭제되거나 수정되지 않습니다.
4. Active Directory는 단지 Bitlocker 복구 정보를 저장하는 장소입니다. 모든 기능은 암호화된 드라이브가 있는 컴퓨터에 Bitlocker 응용 프로그램에 의해서 다뤄집니다.
이것이 전부입니다. 이것이 여러분의 Active Directory에 BitLocker를 구현할 때 필요한 일반적인 질문에 대한 답이 되기를 바랍니다.
다음에 뵙겠습니다.
Paul ‘Fragale
내 컴퓨터에서 드라이브, 폴더를 포함한 파일 이름의 전체 길이를 알고 싶으신가요?
인터넷에 Path Scan 이란 툴이 있어서 소개합니다. 이 툴은 Scan 할 드라이브 경로, 전체 경로 Character 길이, 찾고자 하는 최소 Character 길이 등을 지정할 수 있고, 결과에 대해 Text 형식으로 저장하여 목록을 뽑아 볼 수도 있습니다.
다운로드: http://www.registrytweaker.net/files/pathscan.zip
원문주소 : So you have a slow logon…? (Part 2)
http://blogs.technet.com/askds/archive/2009/09/24/so-you-have-a-slow-logon-part-2.aspx
밥 드레이커(Bob Drake)입니다. 느린 로그온 시리즈의 두번째 부분에 오신 것을 환영합니다. 이 부분에서는 느린 로그온 문제를 확인하는 것을 도와주는 몇 가지 간단한 문제해결 기술을 다루도록 하겠습니다.
어디에서 느린 현상이 발생하는지 구분하는 것은 어렵지 않습니다...
l 전원 버튼을 누르고 로그온 화면이 나타날 때까지 느린가?
l 로그온 화면까지 빠르고 데스크탑이 나타날 때까지 느린가?
l 모두 사용자이고, 관리자가 아닌가?
l 위의 사항 모두
문제해결을 위해서는 위의 질문에 답해야 합니다. 파워버튼을 누르고 로그온 화면에 도달하지 못하는 경우부터 시작하겠습니다(느린 부팅은 느린 로그온이 아닙니다). 만약 처음 부팅을 시작하고 로그온 화면에 도달하기 전에 느린 현상이 발생하면, 일반적으로 운영체제 자체에 문제가 있던지, 설치된 응용 프로그램에 있던지, 아니면 둘 모두에 있을 수 있습니다. KB 325376처럼 시작, 종료, 로그온, 로그오프시에 상태 메시지를 표시하는 것은 문제해결을 위해 좋은 방법입니다. 이렇게하면 부팅/로그온 프로세스 중에 자세한 정보를 받을 수 있습니다.
정책 위치(XP와 2003)
추가적인 메시지 표시(XP와 2003)
정책 위치(Windows 7, Windows 2008)
추가적인 메시지 보기(Windows 7, Windows 2008)
처음으로 확인해야 할 것은 "클린 부팅(Windows XP/2003)(Vista/2008/Win7)" 될 때 지연이 발생하는지 여부입니다. MSCONFIG를 통해 로딩될 때 선택적으로 모든 타사 서비스와 응용 프로그램을 중지할 수 있습니다. 머신에서 응용 프로그램이 필요해서 문제가 생길 수 있는데, 이 단계는 운영체제가 이슈가 되거나 운영체제에 설치된 응용 프로그램이 이슈가 되는 것을 알기 위해 필수적입니다. 다음에 방법이 있습니다.
1. 시작을 클릭하고 실행에서 "MSCONFIG"를 입력합니다.
2. "서비스" 탭을 선택하고 "Hide all Microsoft Services"를 체크하고 "Disable All"을 클릭합니다.
참고 : "Hide all Microsoft Services"를 클릭할 때 시스템에 설치된 응용 프로그램을 볼 수 있습니다. 때때로 머신에 더 많은 문제를 야기하는(드라이브 암호화 소프트웨어같은) 중요한 부팅/로그온 프로세스가 있습니다. 그런 응용 프로그램은 검토하고 중지할 필요가 있습니다.
"Startup" 탭을 선택하고 "Disable All"을 다시 한번 클릭합니다. 모든 타사의 응용 프로그램을 중지하는 것은 더 큰 이슈를 야기할 수 있는데, 시작시 F8을 누르고 "Last Known Good"이나 "Safe mode"를 통해 "msconfig"에서 변경사항을 되돌려 놓을 수 있습니다.
3. 타사 서비스가 중지되면 재부팅이 필요하다는 메시지가 표시되고 재부팅을 해야 합니다. 다른 창이 화면에서 나타나면, "OK"를 클릭하세요.
4. 부팅 시간이 같은지 아닌지 테스트합니다.
타사 서비스를 중지하면 컴퓨터가 부팅되고 로그온하는게 빠르거나 정상적입니까? 답이 '네'라면 지연을 만드는 소프트웨어를 찾은 것입니다. 어떤 것이 더 많이 걸리는지 찾으려면 빠른 방법은 서비스의 반을 시작하고(시작할 수 있는 서비스 목록을 확인하세요) 지연이 발생하는지 보는 것입니다. 그렇지 않으면, 남은 절반의 서비스를 시작해서 이슈가 반복될 때까지 시도합니다. 어떤 것이 문제인지 확인하면, 그 응용 프로그램이나 구성요소의 업데이트를 시도합니다. 만약 특정 응용 프로그램이 이슈가 된다고 생각되면 확인 차원에서 간단히 그것을 중지시키는 것이 빠른 접근 방법입니다. 원인을 밝혀내는 동안 재부팅을 여러번해야 합니다. 지연을 초래하는 응용 프로그램을 발견하면, 다시 시작해서 지연이 발생하는지 확인합니다. 문제가 되는 응용 프로그램을 확인하면 벤더를 부르고 문제가 발생한 이유를 확인한 다음 해결책을 얻습니다. 때때로 그런 충돌을 해결하는 업데이트나 핫픽스가 있습니다.
참고 : 일부 안티바이러스 응용 프로그램은 MSCONFIG에서 중지해도 그 서비스를 필터 수준 드라이버를 로드합니다. 느린 로그온의 원인이 되는 것이 안티바이러스라는 것을 발견하는 방법은 테스트하는 동안 제거하는 것입니다.
여전히 느리다면?
여전히 부팅이 느리다면 클라이언트의 DNS 구성을 살펴봅니다. 다른 하드웨어(스위치, 라우터같은) 사이에 있는 DNS 서버는 문제의 원인이 될 수 있습니다. 네트워크의 한 부분이 문제가 되고 다른 부분은 그렇지 않다면, 네트워크 이슈를 발견할 기회입니다. 네트워크와 DNS 형태의 이슈를 발견하는 좋은 방법은 NetMon같은 패킷 캡쳐 응용 프로그램을 사용하여 네트워크를 추적하는 것입니다. 어려운 점은 머신이 시작할 때 추적을 캡쳐하는 것입니다. 같은 허브나 스위치에 있는(포트 미러링) 다른 컴퓨터를 통해 모니터링 할 수 있습니다. 네트워크 캡쳐 유틸리티를 시작하고 다른 IP 주소를 필터링합니다.
이 추적에서 볼 수 있는 것은 다음과 같습니다.
l 올바른 DNS 응답(쿼리한 쿼리 응답인가?)
l 지연되거나 응답하지 않는 응답(DNS 서버에서 도메인 컨트롤러까지 모두)
l Kerberos 실패
l SMB 실패
l 다양한 TCP 리셋이나 재전송
l 이슈가 발생하는 특정 도메인 컨트롤러의 일치(도메인 컨트롤러 자체에서 발생하는 가능한 이슈)
네트워크에 관련된 이슈가 있다면 특이점을 봐야합니다.
만약 위의 방법으로 모든 타사 소프트웨어를 중지하고도 부팅 지연이 발생하면, 다음 단계는 머신에 어떤 정책이 적용되는지 확인하는 것입니다. 그룹 정책의 문제를 해결하는 좋은 시작점은 기술 문서입니다.
대부분의 환경에서 다양한 정책이 적용되는데, 이슈가 되는 것을 어떻게 찾아낼까요? 가장 빠른 방법은 Active Directory 사용자 및 컴퓨터 스냅인에서 "TEST" OU를 새로 만들고 OU에 정책 상속을 막는 것입니다. 그렇게 하고, 문제가 되는 컴퓨터를 그 OU에 옮깁니다. 어떤 정책도 "enforced" 또는 "no override" 되지 않게 합니다. 그러한 설정을 가진 정책이 있으면, 상속이 차단된 OU에 여전히 적용됩니다.
컴퓨터를 옮기기 전에 다음 명령어를 통해 어떤 그룹 정책 객체가 링크되었는지 확인해야 한다.
"gp.txt"를 열 때 다음과 같은 정책을 볼 수 있습니다.
머신에 적용되는 "Default Domain Policy"와 "Local Group Policy"를 봐야합니다.
적용된 정책이 확인되면 새로 만든 테스트 OU에 옮기면 됩니다. OU를 만드는 단계와 상속을 막는 단계는 다음과 같습니다.
1. "Test" OU를 만들고 컴퓨터를 그곳으로 옮깁니다.
2. 그룹 정책 관리 콘솔을 열고 TEST OU에 상속을 차단합니다.
참고 : 상속을 차단하면 OU 아이콘이 파란색 느낌표로 바뀝니다.
3. 상속을 차단하고 컴퓨터를 테스트 OU로 옮기고, 이전 정책을 없애기 위해 컴퓨터를 두 번정도 재부팅합니다.
강제하지 않으면 모든 정책이 제거될 때까지 시간이 걸립니다. 적어도 이 시간에 정책의 일부가 남아있게 됩니다. 테스트를 다시 해야합니다...
컴퓨터가 빠르게 부팅되면 지연의 원인이 되는 것이 그룹정책입니다(또는 그룹정책의 조합입니다)어떤 정책이 문제를 야기하는지 찾으려면 한번에 하나씩 링크를 하고 지연이 발생하는지 재부팅을 해야합니다. 이것은 그림처럼 "Link an Existing GPO"를 선택하여 할 수 있습니다. 감사를 통해 정책을 확인하면, 어떤 정책이 지연의 원인이 되는지 알 수 있습니다.
그래도 느리다면...!?!
위의 단계를 다 진행하고 모든 소프트웨어나 정책을 중지해도 부팅이 느려진 원인을 찾을 수 없다면 다음 단계는 디버그 로깅입니다. 사용하는 시스템에 따라 로깅을 시작하는 방법이 조금 다릅니다.
2000, XP, 2003에서는 다음 문서를 통해 로깅을 시작할 수 있습니다. "How to enable user environment debug logging in retail builds of Windows" http://support.microsoft.com/default.aspx/kb/221833. 운좋게도 제 동료 중에 한 명이 이미 결과물을 해석하는 블로그를 썼습니다(두 부분에서 찾을 수 있습니다. 1절과 2절) Vista, 2008 그리고 Windows 7에서는 마이크로소프트는 "Event Tracing"이라고 불리는 것으로 디버그 로깅 포맷을 변경했습니다. 기본적으로 결과 데이터는 KB문서의 결과물과 같지만 2진 출력물에서 변환된 것입니다. 소스 코드를 포함하고 있기 때문에 변환하는데 마이크로소프트의 도움이 필요할 것입니다(프로필없이 정책 부분을 보려면 gpsvcdebug 로깅을 사용하세요).
다른 훌륭한 도구는 "Autoruns"입니다. 이 유틸리티는 시스템이 시작하거나 로그인되는 동안 실행되도록 구성하는 프로그램을 보여줍니다. 이 도구의 가장 훌륭한 기능 중 하나는 "Hide Microsoft Entries"입니다.
또한 사용자별로 autoruns을 선택할 수 있도록 합니다.
Autoruns는 다른 응용 프로그램에서는 일반적으로 볼 수 없는 아이템을 찾을 것입니다.
정리하면, 대부분의 경우의 경우에 느린 부팅이나 느린 로그온은 응용 프로그램 충돌이나 그룹정책의 제약 또는 구성 이슈로 발생합니다. 위의 문제해결방법과 약간의 노력으로 느린 로그온 문제가 발생하는 곳과 원인을 찾아서 최소의 시간으로 해결할 수 있을 것입니다.
- Bob ‘Quasi-Manager’ Drake
원문주소 : So you have a slow logon…? (Part 1)
http://blogs.technet.com/askds/archive/2009/09/23/so-you-have-a-slow-logon-part-1.aspx
안녕하세요? 밥 드레이크(Bob Drake)입니다. 오늘은 느린 로그온 문제를 해결하는 처방과 소중한 시간을 절약할 수 있는 두 개의 글을 올리도록 하겠습니다. 여러가지 느린 로그온 사례를 경험했었지만, 대부분의 경우 매우 다루기 힘들었습니다. 접근방법과 가지고 있는 정보에 따라 달라집니다. 느린 로그온이 발생하는 원인은 다양한 이유가 있는데, 가끔은 다양한 이유가 하나로 표시되기도 합니다.
첫번째 글에서는 느린 로그온에 대한 잘 알려진 사례를 다루겠습니다. 여러분의 환경에 최적화된 로그온 상태와 느린 로그온 이슈가 있을 때 기준점을 문서화할 수 있도록 도와드리겠습니다.
"로그온 프로세스"(이 용어는 워크스테이션을 부팅하고 데스크탑을 사용하기 위해 사용자 로그온을 마친 상태로 사용합니다)는 많은 부분으로 구성되어 있습니다. 가장 중요한 질문은 "감내할 수 있는 로그온 시간이 어느 정도인지 입니다" 컴퓨터를 켜고 데스크탑을 사용할 수 있을 때까지 3~5분만이 소요되기를 바란다면, 모든 작업을 수행하는 간단한 창을 볼 것입니다. 비즈니스 요구사항에 따라 로그온 동안 무엇을 수행해야 하는지 문서화하는 것이 필요하고 다음으로 넘어가기 전에 필요한 목표를 이해해야 합니다.
로그온 작업 리스트를 만들면, 로그온 시간 프레임을 테스트할 수 있습니다. 모든 것을 구성하고 원하는 시간범위를 넘으면, 작업을 제한하든지 원하는 시간범위를 늘리든지 조정작업을 해야 합니다. 너무 적은 시간에 너무 많은 일을 수행해야 할 때 포화점에 도달하게 됩니다.
그러면 로그온 프로세스를 느리게 하는 상위 아이템들을 어떻게 알 수 있을까요? 로그온 시간에 영향을 주는 구성은 다음과 같습니다.
l 오래된 드라이버 : 네트워크 인터페이스 카드(NIC)는 최신 드라이버를 사용해야 합니다.
l 오래된 운영체제 패치 수준 : 윈도 업데이트를 통해 운영체제에 최신 서비스팩을 설치해야 합니다.
l 로밍 사용자 프로필 : 로밍 프로필은 그룹 정책을 수행하는 방법을 변경합니다. 로밍 프로필이 "비동기"(백그라운드로 동작하거나 특정 시간에 다수가 동작)에서 "동기"(포그라운드로 동작하거나 특정시간에 하나만 동작)로 동작하도록 구성합니다. 네트워크가 초기화될때까지 기다리는 "Fast logon Optimization"을 비활성화합니다.
참고 : 로밍 프로필이 구성되었을 때 이것은 정말 중요한데, 소프트웨어 설치와 폴더 리디렉션 그룹 정책은 네트워크가 초기화될 때까지 사용자가 로그온되지 않도록 하는 것을 요구하고 정책을 동기화로 수행합니다. 이것은 기본값이고 변경을 하게되면 로그온의 불일치를 야기합니다.
l 홈 폴더 : 이것은 로그온 시간에 영향을 주는데 시스템 DLL을 위한 로컬 위치를 대신 찾기 때문입니다. 클라이언트 머신은 홈 폴더를 대신할 것을 찾게 됩니다. 매핑된 네트워크 공유가 WAN에 걸쳐있다면 로그온 시간은 더욱 오래 걸릴 수 있습니다.
참고 : 로밍 프로필에서 홈 폴더가 필요하면 동작을 바꿀 수 있는 차단 레지스트리 키가 있습니다(SafeDllSearchMode). 만약 여러분의 환경에서 이것이 이슈가 되지 않는다면, 로그온시 네트워크 추적을 하고 DLL이 네트워크를 통해 홈 폴더에 쿼리하는지 확인합니다. 또한 (StartRunNoHOMEPATH)와 같은 방법이 있는데 응용프로그램이 쿼리하는지 확인하는 것을 도와줄 것입니다.
l 시작 응용 프로그램 : 시작할 때 자동으로 시작하도록 구성된 응용 프로그램은 느린 로그온의 원인이 될 수 있습니다.
l 프로필 스캐닝 : 로그온시 프로필(로밍이라면 홈 지역)을 스캔하는 많은 안티바이러스 프로그램이 있습니다. 안티바이러스뿐만 아니라 다른 응용 프로그램도 마찬가지입니다(문제해결 부분에서 어떻게 이것을 발견하는지 다룰 것입니다).
l 과도한 그룹 정책 : 여러가지 작업과 구성(소프트제한 정책같은)을 수행하는 수많은 그룹 정책은 로그온 시간을 증가시킬 수 있습니다. 모든 것을 수행하는 몇 가지 정책이 각각을 수행하는 많은 정책보다 좋습니다. 그룹 정책을 통합하는게 가능하다면 말입니다.
l 과도한 시작/로그온 스크립트 : 로그온시 동작하는 시작/스크립트는 비효율적인 코드를 사용하여 많은 작업을 수행하면 프로세스를 지연시킬 수 있습니다.
l 과도한 WMI 필터 : 과도한 WMI 필터는 그룹 정책 적용을 느려지게 만들 수 있습니다.
l 로컬 도메인 컨트롤러가 없는 경우 : 로컬 도메인 컨트롤러가 없다면 로그인 지연이 발생할 수 있습니다(사용자가 WAN을 통해 인증하는 경우)
느린 로그온 증상에 대해 문제를 해결하기 전에 느린 로그온이 무엇이고 어디에서 느리게 되는지 확인할 필요가 있습니다. 로그온이나 부팅 시간이 느리다고 말하려면 무엇이 정상적인 로그온이나 부팅시간인지 알아야 합니다. 위의 기대치를 가지고 다음 단계로 정상적인 상태에서 로그온을 수행하는데 걸리는 시간을 기록합니다. 기업환경에는 다양한 운영체제가 있을 수 있는데(데스크탑, 노트북, 서버, XP, 비스타, Win 7, 2003, 2008, 2008 R2) 각각에 대해 기준선을 가지고 있어야 합니다.
다음은 기준선을 문서화할 때 포함할 목록입니다.
l 네트워크 토폴로지
l Active Directory 토폴로지
l 사용자 및 컴퓨터 그룹 멤버쉽
l 운영체제와 서비스팩 수준
l 설치된 응용 프로그램
l 네트워크 대역폭와 지연
l NIC 드라이버 정보
l XP 또는 2003에서 "UserEnv" 로그(다른 보안 그룹의 구성원인 여러 사용자), 비스타와 Win7에서 ETL 로그
l 네트워크 추적
l 그룹정책 정보(컴퓨터와 사용자 모두)
평균 시간에 대한 명료한 기준선이 있으면, 로그온 시간이 증가하는 것에 대해 명확해지고 어떤것이 문제인지 범위를 좁힐 수 있습니다. 위의 문서가 있다면 이슈는 훨씬 빨리 해결될 것입니다. 문서가 없다면 설정하는데 많은 시간과 노력을 해야 합니다. 다음 글에서는 실제로 문제를 해결하는 방법을 다루겠습니다.
다음에 뵙겠습니다...
- Bob “My idea of a short hiatus is 18 months” Drake
파일 서버 용도의 구형 서버를 새로운 서버로 옮겨야 될 경우는 어떻게 할까요?
그렇다면 파일/폴더들에 대한 ACL 및 네트워크 공유 권한도 같이 옮겨야 할 경우가 있습니다.
파일/폴더들에 대한 ACL 정보 또는 NTFS 파일 시스템 권한은 보통 Xcacls, Xcacls.vbs 또는 Cacls 와 같은 툴을 사용할 수 있었으며, Windows Vista 에서는 Icacls 라는 툴을 개발되어 백업/복원 작업을 하실 수 있습니다.
이후 이 툴은 Windows 2003 SP2 와 Windows Server 2008, Windows 7 에 포함되었습니다.
이 툴을 이용하여 위의 두 가지 정보를 백업 및 복원하는 방법을 알아 보겠습니다.
<NTFS 파일 시스템 권한 정보를 백업/복원하는 방법>
예를 들어, d: 드라이브 상에 database 라는 폴더가 있다고 가정하면, 아래의 명령으로 백업합니다.
Icacls.exe d:\database /save acl.txt /t /c
참고! 자세한 스위치 정보를 보기 위해서는 Icacls.exe 를 실행합니다.
Sids may be in either numerical or friendly name form. If a numerical
form is given, affix a * to the start of the SID.
/T indicates that this operation is performed on all matching
files/directories below the directories specified in the name.
/C indicates that this operation will continue on all file errors.
Error messages will still be displayed.
/L indicates that this operation is performed on a symbolic link
itself versus its target.
/Q indicates that icacls should supress success messages.
그리고, 복원을 위해서는 아래의 명령을 실행합니다.
Icacls.exe d:\ /restore acl.txt
여기에서 하나 눈여겨 봐야 할 것이 있습니다. 복원 시에는 백업 당시 사용되었던 절대 경로인 D:\database 를 사용하지 않은 d:\ 가 사용되었습니다. 이것은 저장된 파일이 상대 경로를사용하기 때문입니다.
<acl.txt 파일 내용>
database
D:(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)(A;ID;0x1200a9;;;BU)(A;OICIIOID;GXGR;;;BU)
database\New Text Document.txt
D:(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1301bf;;;AU)(A;ID;0x1200a9;;;BU)
database\perfctrl.dll
D:(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1301bf;;;AU)(A;ID;0x1200a9;;;BU)
database\xperf.exe
D:(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1301bf;;;AU)(A;ID;0x1200a9;;;BU)
database\XperfHighCPU.cmd
D:(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1301bf;;;AU)(A;ID;0x1200a9;;;BU)
< 네트워크 공유 권한을 백업/복원하는 방법 >
네트워크 공유 권한을 백업하기 위해 아래 네트워크 공유에 대한 레지스트리 키를 “내보내기” 후 적당한 이름 Networkshare.reg 로 저장합니다.
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
이후 네트워크 공유 권한을 복원하기 위해서는 위의 내보내기 파일 Networkshare.reg를 실행하여 가져오기 작업을 진행하면 됩니다.
Saving and restoring existing Windows shares
http://support.microsoft.com/kb/125996/en-us
기타 관련 문서:
How to use Xcacls.vbs to modify NTFS permissions
http://support.microsoft.com/kb/825751/en-us
Cacls
http://technet.microsoft.com/en-us/library/bb490872.aspx
