달력

5

« 2024/5 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

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

:
Posted by 커널64

[증상]
기본 서비스 모니터를 이용해 서비스 모니터를 생성하고 '서비스 시작 유형이 자동인 경우에만 경고합니다.'를 False로 설정해도 경고가 뜨지 않는다.

[처리 방법]
해당 관리팩을 Export해 메모장으로 연 후 <CheckStartupType>true</CheckStartupType>을 추가한다.

<ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<ServiceName>서비스 이름</ServiceName>
<CheckStartupType>true</CheckStartupType>
</Configuration>
</UnitMonitor>

:
Posted by 커널64
2009. 7. 13. 14:30

NDR 언어 변경 (Exchange 2007) Collaboration2009. 7. 13. 14:30

Set-Mailbox -Identity <MailboxIdParameter> -Languages  <languagecode>
예)Set-Mailbox -Identity administrator -Languages  ko-kr
 
Languages 매개 변수는 기본 설정 순서대로 이 사서함의 언어 기본 설정을 지정합니다.
해당 언어가 지원되는 경우 여러 Exchange 구성 요소에서 기본 설정 언어로 사서함 사용자에게 정보를 표시합니다.
이러한 구성 요소 중에는 할당량 메시지, NDR(배달 실패 보고서), Microsoft Outlook Web Access 사용자 인터페이스 및 UM(통합 메시징) 음성 안내가 포함됩니다.

참고 사이트 (MS Technet)
http://technet.microsoft.com/ko-kr/library/bb123981.aspx


:
Posted by 커널64

Exchange 관리 셸을 사용하여 Outlook Web Access의 로그온 및 오류 언어 설정을 구성하려면 다음을 수행합니다.
Set-OwaVirtualDirectory -identity "Owa (Default Web Site)" -LogonAndErrorLanguage <language code>

Exchange 관리 셸을 사용하여 Outlook Web Access 가상 디렉터리의 기본 클라이언트 언어 설정을 구성하려면 다음을 수행합니다.
Set-OwaVirtualDirectory -identity "Owa (Default Web Site)" -DefaultClientLangugage <language code>

Exchange 관리 셸을 사용하여 개별 사서함의 클라이언트 언어 설정을 구성하려면 다음을 수행합니다.
Set-Mailbox –identity <mailbox identity> -languages <language code>

:
Posted by 커널64

I see a lot of memory related Exchange Server 2007 questions in the Exchange 2007 forum on the MSExchange.org boards, so this month my plan was to talk about what has changed in regards to memory utilization in Exchange Server 2007 compared to previous versions of Exchange Server. As most of you remember, because Exchange Server 2003 was based on 32-bit architecture, this version of Exchange Server was limited to using a maximum of 4GB of memory. Because Exchange Server 2007 is based on 64-bit architecture, this limitation is no longer there. In fact Exchange Server 2007 has much better memory utilization than Exchange Server 2003 had, and is capable of using 32 GB of memory and more. Personally, I have deployed Exchange 2007 Mailbox servers with 16 GB of memory installed, and I have seen Store.exe processes grow as large as to approximately 14 GB in size!
These memory utilization changes are excellent for large enterprise IT organizations, but several of the smaller organizations with a relatively small amount of mailbox-enabled users (between 10-30) and an Exchange 2007 Mailbox server with let us say 4 GB of memory often seem to experience problems with excessive memory utilization. Several Exchange administrators report that their Exchange 2007 Mailbox server uses more memory than the amount of physical memory installed in the server. This means that the server can become sluggish and unresponsive.
With Exchange Server 2003, the store process was bound to a certain memory cache limit. The upper bounds of this limit were typically set at around 900MB. With Exchange Server 2007 which uses 64-bit architecture, the limit on database cache size is no longer present. Currently, the default minimum cache size for Exchange 2007 is 512MB (for machines with at least 2GB RAM), and there is no maximum value set, which means that ESE (store.exe) will grow the cache to consume almost all available RAM on the server if there is no other memory pressure on the system. A larger database cache size typically results in greatly reduced disk I/O as reading information from memory is much faster than reading information from disk. If memory pressure occurs, that is other applications request/require memory, ESE will appropriately shrink the size of the database cache automatically.
Okay, I hear you say, that was a good explanation, but unfortunately this is not the behavior I experience in my environment. So, what can I do if my Exchange 2007 server is sluggish and unresponsive? Although generally not recommended by Microsoft, there is one thing you can do. You can set a limit on the ESE database memory cache. This is done by following the below steps:

Warning!
Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your Operating System. Neither MSExchange.org nor Microsoft can guarantee that these problems can be solved. Modify the registry at your own risk!


· Start ADSI Edit by clicking Start > Run and typing ADSIEDIT.MSC
· Open the following object: Configuration > Services > Microsoft Exchange > Exchange organization > AdministrativeGroups > Your administrative group > Servers > Server name > Information Store
· Right-click the Information Store, and then click Properties.
· Under the list of Attributes, scroll down and select msExchESEParamCacheSizeMax

사용자 삽입 이미지


Click the Edit button, then type the number of 8 kilobyte (KB) pages that you want to set the maximum cache size to.
For example, 1GB cache equates to 1048576 (1024 * 1024). Divide the cache that you want to set by 8kb to determine the value to enter. In this case, 1048576 divided by 8 is 131072.
If you wanted to set the cache size to 16GB, the value would be 2097152 (16777216 divided by 8).

Note
The msExchESEParamCacheSizeMax parameter controls the ESE buffer size. Its value is expressed as a page count, and must be set to an exact multiple of 8192 for maximum efficiency. If this value is not met, the cache size is rounded up to the next 32-MB boundary when virtual memory is allocated. If this value is incorrectly set, memory may be wasted.

:
Posted by 커널64
2009. 7. 13. 14:16

SPF 레코드 등록 방법 (Sender ID, SPF Record) Etc.2009. 7. 13. 14:16

1. DNS Management 를 열어서 추가할 도메인 선택 후 우클릭 -> 다른 새 레코드
2. 레코드 종류를 텍스트 형식으로 선택
3. 아래와 같은 형식으로 입력한다. (~와 -에 따라 처리 방법 다름)
domain.com.  IN  TXT  "v=spf1 ip4:1.1.1.1 ip4:2.2.2.2 ip4:3.3.3.3 -all"
===> 보내는 메일 서버가 일치하지 않는 경우 -> 수신 거부

domain.com.  IN  TXT  "v=spf1 ip4:1.1.1.1 ip4:2.2.2.2 ip4:3.3.3.3 ~all"
===> 보내는 메일 서버가 일치하지 않는 경우 -> 받는 서버 정책에 따라 처리

4. 하루 정도 지난 후에 DNS 적용된 것이 확인되면 화이트 도메인 등록 요청
5. DNS 적용 여부 확인은 Command 창에서
nslookup -> set q=txt -> domain.com

:
Posted by 커널64

Exchange에서는 메시지 크기 제한 설정을 하는 부분이 3군데이다.
1. 사용자별 설정
2. Transport Config 설정
3. 송신 커넥터와 수신 커넥터에서 설정

기본적으로 새 계정을 만들게 되면 제한 설정은 제한 없는 상태이다.
그리고, Transport Config도 없는 상태이다.

세번째, 커넥터 쪽이 문제이다.
기본적으로 커넥터를 만들게 되면 기본 값이 10MB가 된다. (송수신 각각 10MB)
GUI 로 는 확인이 불가능하고, 수정 또한 불가능 하므로 Shell을 사용해야 한다.

Shell에서 아래와 같이 입력을 해 보면 현재 설정 값을 알 수 있다.
Get-SendConnector | Select identity, Maxmessagesize
Get-ReceiveConnector | Select identity, Maxmessagesize

10MB로 제한되어 있는 것이 확인된다면 아래와 같이 입력하여 설정값을 수정한다.

Set-SendConnector "커넥터 이름" -MaxMessageSize 용량
예)  Set-SendConnector "Connector Name" -MaxMessageSize 50MB

Set-ReceiveConnector "커넥터 이름" -MaxMessageSize 용량
예) Set-SendConnector "Connector Name" -MaxMessageSize 50MB

Edge 서버가 있을 경우 Edge 서버에서도 설정해 주어야 한다.

http://technet.microsoft.com/ko-kr/library/bb124345.aspx

:
Posted by 커널64

perfmon 결과 값에서 아래 값이 점차적으로 증가하면 메모리 누수 의심
Memory\Pool Nonpaged Bytes
Memory\Pool Paged Bytes

!vm 1 - 메모리 사용량 표시 -> Free System PTEs가 부족하지 않은지 확인
!sysptes - Total System PTE 확인 -> Total System Ptes와 Total free를 확인해 부족 여부 확인
!sysptes 4 - 모듈별로 사용한 PTE 표시

gflag를 이용해서 pooltagging Enable (2003은 Default로 enable)
pool usage - Pool 사용량 표시
!poolused - Module별로 Pool 사용량 표시
!poolused 2 - nonpage pool로 정렬 -> 메모리 많이 먹는 놈의 Pool Tag 확인

Pool Tag가 확인되었다면 어떤 드라이버가 사용하는지 확인
1. CMD 창에서는
C:\WINDOWS\system32\drivers 로 이동해서
findstr.exe /m /i <Tag Name> *.* - 해당 sys 파일이 확인된다

2. Windbg 에서는
!for_each_module s-a @#Base @#End "<Tag Name>" - 해당 Tag를 사용하는 메모리 주소가 확인된다
lm <Memory Address> - 메모리 주소에 Mapping되어 있는 파일이 확인된다.

:
Posted by 커널64
HP ProLiant 서버에 Windows Server 2008 설치 시 블루스크린 발생

블루스크린에 나타나는 메시지는 BUGCODE_USB_DRIVER이며 증상 발생은 불규칙한 것 같다.
Windows Server 2008 모든 버전에서 발생하며 SP2가 포함되었건 R2건 상관없이 발생한다.
원인은 USB 포트가 Sleep 모드로 들어가면서 발생한다고 하는데 뭐... 어쨋든 해결책은...

iLO 2 Firmware를 버전 1.29 또는 그 이상으로 업데이트하면 된다.
이미 설치를 진행하던 중에 발생했다면 다른 운영체제를 설치하고 업데이트하면 되겠다.
:
Posted by 커널64

cd %Windir%\system32\inetsrv

AppCmd set config "Default Web Site/" /section:system.webServer/webdav/authoring /enabled:true /commit:apphost
AppCmd set config "Default Web Site/" /section:system.webServer/webdav/authoringRules /+[users='*',path='*',access='Read'] /commit:apphost
AppCmd set config "Default Web Site/" /section:system.webServer/webdav/authoring /properties.allowAnonymousPropfind:true /commit:apphost
AppCmd set config "Default Web Site/" /section:system.webServer/webdav/authoring /properties.allowCustomProperties:false /commit:apphost
AppCmd set config "Default Web Site/" /section:system.webServer/webdav/authoring /properties.allowInfinitePropfindDepth:true /commit:apphost
AppCmd set config "Default Web Site/" /section:system.webServer/webdav/authoring /fileSystem.allowHiddenFiles:true /commit:apphost
AppCmd set config "Default Web Site/" /section:system.webServer/webdav/authoring /fileSystem.allowHiddenFiles:true /commit:apphost

:
Posted by 커널64