보고 서버의 ReportServer\bin\ReportingServicesService.exe.config 파일에 다음 항목 추가

<dependentAssembly>
<assemblyIdentity name="Microsoft.ReportingServices.ProcessingCore" publicKeyToken="89845dcd8080cc91" culture="neutral" />
<bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0" />
</dependentAssembly>
<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity name="Microsoft.ReportingServices.ProcessingCore" publicKeyToken="89845dcd8080cc91" culture="neutral" />
<bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0" />
</dependentAssembly>

http://support.microsoft.com/kb/972821/en-us

SCOM 콘솔 실행 시 등록된 서버(Registered Server) 목록
SCOM 콘솔은 실행될 때 AD의 MOMSdkSCP를 검색해 등록된 서버 목록에 보이게 된다.
이전에 RMS가 설치되었던 서버의 SCP가 남아있어 잘못된 서버가 목록에 보일 수 있다.

새 SCP 생성
1. ADSIEDIT 실행
2. RMS가 실행 중인 컴퓨터 계정에 우클릭 -> 새로 만들기 -> 개체
3. 클래스 선택 화면에서 ServiceConnectionPoint 선택하고 이름을 SDKServiceSCP로 설정
4. 새로 생성된 SCP 클래스에 다음과 같이 속성 수정
- keywords: MOMSdkSCP
- serviceBindingInformation: <RMS의 FQDN>:5724
- serviceClassName: <관리 그룹 이름>
- serviceDNSName: <RMS의 FQDN>

기존 RMS 서버의 SCP 제거
1. ADSIEDIT 실행
2. RMS가 실행 중인 컴퓨터 계정의 SDKServiceSCP 개체 제거

I. Kerberos vs. NTLM
NTLM 인증: Challenge-Response mechanism
1. 클라이언트가 서버로 사용자 이름을 보낸다.
2. 서버는 이에 대한 요청 값을 생성해 클라이언트로 보낸다.
3. 클라이언트는 이 요청 값을 사용자 암호로 암호화해 서버로 응답을 보낸다.
4. 로컬 계정인 경우 서버는 SAM(Security Account Manager)을 검색해 사용자의 응답을 검증한다.
5. 도메인 계정인 경우 서버는 이 응답을 도메인 컨트롤러로 전달해 검증하고 사용자 계정에 대한 그룹 정책을 받는다.
6. Access Token을 발급하고 세션을 맺는다.

Kerberos 인증: Trust-Third-Party Scheme
- Kerberos 인증 방법은 표준 프로토콜로 네트워크에서 클라이언트와 서버를 상호 인증하는 방식이다.
- 세 가지 주 요소는 KDC(Key Distribution Center), 클라이언트, 접근할 서비스를 가지는 서버
- KDC는 도메인 컨트롤러의 일부로서 설치되며 다음 두 가지 기능을 수행한다.
-- AS(Authentication Service), TGS(Ticket-Granting Service)

1. 사용자가 네트워크에 로그온하면 AS에 TGT(Ticket Grant Ticket)을 요청한다.
2. 클라이언트는 네트워크 자원에 접근할 때 TGT와 인증자(Authenticator), 대상 서버의 SPN(Service Principal Name)을 제시한다.
3. 클라이언트는 네트워크 서비스와의 통신에 사용될 세션 티켓을 받기위해 서비스 계정 도메인의 TGS에 접속한다.
4. 대상 서버가 인증자를 검증하고 나면 클라이언트 사용자에 대한 Access Token을 생성한다.


II. Kerberos와 NTLM 인증의 요구 사항
Kerberos
1. 클라이언트와 서버는 반드시 도메인 구성원이어야 한다. 만약 클라이언트와 서버가 서로 다른 도메인에 속하는 경우 두 도메인은 양방향 신뢰가 구성되어 있어야 한다.
2. SPN 등록. SPN은 서버에서 실행 중인 서비스에 대한 고유한 식별자다. Kerberos 인증을 필요로 하는 서비스는 SPN을 가지고 있어야 클라이언트가 네트워크에서 서비스를 식별할 수 있게 된다.

SPN(Service Principal Name)
SQL Server에 대한 SPN은 다음과 같은 요소로 구성된다.
- ServiceClass: 서비스를 식별하는 요소. SQL Server에 대한 Service Class는 MSSQLSvc이다.
- Host: SQL Server가 실행 중인 컴퓨터의 FQDN
- Port: 실행 중인 서비스가 수신 대기 중인 포트
예) MSSQLSvc/sqlserver.domain.com:1433

NTLM
NTLM은 요청-응답의 과정을 위해 사용자 암호를 요구한다. 이후 서버는 클라이언트로부터 암호를 요구하지 않고 클라이언트를 식별할 수 있게 된다. 만약 클라이언트가 시스템 계정으로 실행 중이라면 인증 정보를 보낼 수가 없기 때문에 인증은 실패하게 된다.

NTLM Fallback
NTLM(NT LAN Manager)는 Windows NT와 Windows 2000 Workgroup 환경에서 사용되던 인증 프로토콜이다.
Windows Server 2003, Windows XP, Windows 2000은 어느 인증 프로토콜을 사용할지 협상하는 알고리즘을 사용한다. Kerberos 프로토콜이 기본 값이며 Kerberos 인증이 실패할 경우 NTLM 인증을 시도한다.


III. SQL Server 2005에 접속 시 Kerberos와 NTLM
1. 만약 SPN이 존재하면 TCP/IP를 통한 원격 접속 시 Kerberos가 사용된다.
2. SPN이 존재하고 XP 컴퓨터의 로컬 TCP 연결을 하는 경우 Kerberos가 사용된다.
3. Windows Server 2003의 로컬 연결의 경우 NTLM이 사용된다.
4. 명명된 파이프 연결의 경우 NTLM이 사용된다.
5. SPN을 찾을 수 없고 TCP를 통해 연결하는 경우 NTLM이 사용된다.

SETSPN.EXE
1. SQL Server가 LocalSystem 또는 NetworkService 계정으로 실행 중인 경우 SPN 확인
SETSPN -L <SQL Server가 설치된 서버 이름>
2. SQL Server가 도메인 사용자 계정으로 실행 중인 경우 SPN 확인
SETSPN -L <도메인>\<사용자 계정>
3. 만약 도메인 계정이 관리자 계정이 아닌 상황에서 Kerberos 인증을 반드시 사용해야 하는 경우 SPN 등록
SETSPN -A <도메인>\<사용자 계정>
4. SQL Server는 다음 항목이 만족되는 경우 서비스 시작 시 자동으로 SPN을 등록한다. 아래 항목이 충족되지 않는 경우 Kerberos인증을 위해서는 SPN을 수동으로 등록해야만 한다.
- SQL Server가 LocalSystem 또는 Network Service 또는 도메인 관리자 계정으로 실행 중이다.
- TCP/IP 프로토콜이 활성화되어 있다.

일반적으로 클라이언트가 SQL Server로 TCP 연결을 맺는 경우 클라이언트의 SQL 드라이버는 SQL Server가 실행 중인 서버의 FQDN을 풀게된다. 그 다음 SQL Server의 SPN을 검색하고 협상 과정을 거쳐 KDC의 SPN 검증 여부에 따라 NTLM 또는 Kerberos를 사용해 인증을 시도한다. 만약 Kerberos 인증이 실패할 경우 NTLM 인증을 시도한다. 명명된 파이프로 접속하는 경우에는 SQL 드라이버는 빈 SPN을 생성해 NTLM 인증으로 인증을 시도한다.

스냅샷은 다음과 같은 파일들로 이루어진다.
- VM 설정 파일(.xml)
- Save State 파일(.bin, .vsv)
- 차등 디스크(.avhd): 스냅샷 이후의 작업에 사용되는 Working Disk 파일

VM을 생성하면 다음과 같은 하위 폴더와 데이터가 저장된다.
-  Snapshots
-  Virtual Machines:
원본 구성 파일: VM의 GUID 이름으로 저장(.xml)
하위 VM GUID 폴더: Save State 파일(.bin, .vsv)

VM GUID.xml 파일 - 현재 사용되고 있는 가상 디스크 파일(.vhd)을 가리키고 있다.
스냅샷 생성 이전 - Working Disk(.vhd) 파일에 모든 변경 데이터가 저장되고, Save State는 VM의 위치 하위 Virtual Machine\VM GUID 폴더에 저장된다.

스냅샷 생성 과정(VM이 꺼져 있는 상태)
1. Snapshot 폴더에 두 개의 폴더를 생성한다.
스냅샷의 모든 avhd 파일이 저장될 VM GUID 폴더
Save State가 저장될 스냅샷에 대한 SNAP GUID 이름 폴더
- VM이 꺼져있는 상태이기 때문에 SNAP GUID 폴더에는 아무것도 저장되지 않는다.
2. VM 구성 파일(.xml)의 복사본이 SNAP SHOT GUID.xml로 저장된다.
3. Virtual Machines\VM GUID 폴더에 avhd 파일이 생성된다.
4. VM의 원본 VM GUID.xml 파일은 새로 만들어진 avhd 파일을 Working Disk로 업데이트한다.

스냅샷 생성 과정(VM이 켜져 있는 상태)
- VM이 꺼져 있는 상태와 다른 과정은 동일하나 Sate State 파일이 저장되는 것만 다르다.

Revert 과정
1. 현재 Working Disk인 avhd 파일이 지워지고 새로운 avhd 파일이 생성된다.
2. VM의 원본 VM GUID.xml 파일은 새로 만들어진 avhd 파일을 Working Disk로 업데이트한다.
3. Save State 파일이 있는 경우 해당 상태로 되돌리기 위해 Resume 작업을 수행한다.
4. Save State 파일이 없는 경우 VM은 전원이 꺼져 있는 상태로 돌아간다.

최대 절전 모드
%windir%\system32\rundll32.exe powrprof.dll,SetSuspendState Hibernate

절전 모드
%windir%\System32\rundll32 powrprof.dll,SetSuspendState

컴퓨터 잠금
%windir%\System32\rundll32.exe user32.dll,LockWorkStation

System Center Configuration Manager 2007 용량 산정

ConfigMgr Site Server

(running site server all roles not specifically listed on other servers)

ConfigMgr Site Database Server

(running site server all roles not specifically listed on other servers)

ConfigMgr Management Point Servers

ConfigMgr Software Update Point Server

ConfigMgr Remote/Branch Infrastructure Options

System Center Data Protection Manager 2007의 Pre-Backup, Post-Backup 스크립트 사용

<설치 경로>\Microsoft Data Protection Manager\DPM\Scripting 아래에 다음과 같은 형식의 ScriptingConfig.xml 파일을 놓으면 백업 작업 전/후에 해당 명령을 실행한다. 경로나 원본 이름에 ""(따옴표)를 포함해서는 안 된다.
백업 작업에는 초기 전체 백업, 빠른 전체 백업, 동기화, 일관성 확인 작업이 포함된다.

<?xml version="1.0" encoding="utf-8"?>
<ScriptConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/2003/dls/ScriptingConfig.xsd">
<DatasourceScriptConfig DataSourceName="D:">
<PreBackupScript>D:\Scripts\PreCommand.bat</PreBackupScript>
<PreBackupCommandLine />
<PostBackupScript>D:\Scripts\PostCommand.bat</PostBackupScript>
<PostBackupCommandLine />
<TimeOut>90 </DatasourceScriptConfig>
</ScriptConfiguration>

DataSourceName 속성에는 다음과 같이 입력한다.
볼륨에 대한 보호 시 - 원본 볼륨 또는 이름
SQL에 대한 보호 시 - Instance\Database
Exchange에 대한 보호 시 - Storage group Name
SharePoint Farm의 경우 - SharePoint Farm\SQL Server Name\SQL Instance Name\SharePoint Config DB

System Center Data Protection Manager 2007 Sizing


권장 사양
CPU: 2.33GHz 이상 Quad-Core
Memory: 4GB
Pagefile: 복구 지점 볼륨 합의 0.2% 필요
(예를 들어, 복구 지점 볼륨이 총 3TB이면 페이지 파일은 6GB가 추가되어야 한다. 또한, 32bit 운영체제 VSS non-paged pool의 제약으로 10TB 이상의 데이터를 보호하는 경우 반드시 64bit 운영체제가 필요하다.)


플랫폼 별 제약 사항

Operations Manager 2007 R2에서 변경된 서비스 이름
- OpsMgr SDK Service -> System Center Data Access Service
- OpsMgr Config Service -> System Center Management Configuration
- OpsMgr Health Service -> System Center Management

Operations Manager 2007의 Data Warehouse 서버 변경(이동)
1. Operations Manager 관련 서비스 중지
- RMS의 SDK, Config, HealthService 중지
- 모든 MS의 HealthService 중지
2. Operations Manager DW 서버의 OperationsManagerDW DB, Master DB 백업
3. DW 서버의 DW 서버 구성 요소 제거
- 프로그램 추가/제거 > SCOM 2007 Reporting Server > Change >
- Modify > Data Warehouse 구성 요소 제거 (DW DB 자체는 삭제되지 않음)
4. SSMS에서 OperationsManagerDW DB 삭제
- Delete backup and restore history information for databases 체크
- Close existing connections 체크
5. 새 DW 서버에서 Operations Manager 2007 설치
- Data Warehouse 구성 요소 선택
6. 새 DW 서버에서 DW DB 제거
- SSMS 실행 > OperationsManagerDW 삭제
- Delete backup and restore history information for databases 체크
- Close existing connections 체크
7. 작업 2에서 백업해 놓은 OperationsManagerDW DB 복원
8. 새 DW 서버에 다음과 같은 로그인 생성 (SSMS)
- System Center Data Access Service Account
- Data Warehouse Action Account
- Data Reader Account
- 컴퓨터 계정의 경우 domain\computername$의 형태로 생성
9. 새 DW 서버에 각 로그인 계정의 적절한 권한 추가
- SSMS > 보안 > 로그인 > 계정 속성 > 사용자 매핑
- Data Reader Account  > OperationsManagerDW의 OpsMgrReader, db_datareader 체크
- OpsMgr SDK Service > OperationsManagerDW의 OpsMgrReader, db_datareader 체크
- Data Warehouse Action Account > OperationsManagerDW의 OpsMgrWriter, db_owner 체크
10. RMS의 SDK 서비스 시작
11. Reporting Service의 데이터 원본 수정
- http://<ReportServer>/Reports 접속 > 자세한 정보 표시 > Data Warehouse Main 클릭
- 연결 문자열의 data source=<ServerName> 수정 > 적용
12. SSRS가 실행 중인 서버의 레지스트리 수정
- HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Operations Manager\3.0\Reporting
- DWDBInstance의 값을 새 DW 서버로 변경
- 만약, DW 서버와 SCOM RS 서버가 같은 경우 키가 없으며 추가할 필요 없음
13. Operations Manager DB 수정
- SSMS > 데이터베이스 > OperationsManager > 테이블 > dbo.MT_DataWarehouse > 테이블 열기 >
- MainDatabaseServerName_16781F33_F72D_033C_1DF4_65A2AFF32CA3 의 값을 새 DW 서버로 변경
14. OperationsManagerDW DB 수정
- SSMS > 데이터베이스 > OperationsManagerDW > 테이블 > dbo.MemberDatabase > 테이블 열기 >
- ServerName 컬럼의 값을 새 DW 서버로 변경
15. 서비스 재시작
- RMS의 Config Service
- 모든 MS의 HealthService

[[검증]]
1. 콘솔에서 보고서가 정상적으로 보이는지 확인
2. MS의 가용성 > Data Warehouse SQL RS Deployed Management Pack List Request State 상태 확인
3. 이벤트 로그 확인
- 원본: Health Service Module, 분류: Data Warehouse
- 정상인 경우 31570, 31558, 31554
- OperationsManagerDW DB 접근에 문제가 있는 경우 31563, 31551, 31569, 31552