Configuration Manager 상태 메시징에 대한 설명
이 문서에서는 Configuration Manager 상태 메시징 시스템에 대해 설명합니다.
원래 제품 버전: Configuration Manager(현재 분기)
원래 KB 번호: 4459394
상태 메시징 이해
Configuration Manager 상태 메시징은 특정 시점에 클라이언트 조건을 반영하는 메커니즘입니다. 반면 상태 메시지는 관리자가 다양한 Configuration Manager 구성 요소를 통해 데이터 워크플로를 추적하는 데 도움이 됩니다.
상태 메시지 뷰어는 상태 메시지를 보고 추적할 수 있도록 콘솔에 바로 빌드됩니다. 상태 메시지에 해당하는 뷰어가 없습니다. 상태 메시지의 결과는 다음과 같습니다.
- 보고서
- 업데이트해야 하는 시스템 수와 같은 콘솔의 다양한 데이터
- 클라이언트 로그
상태 메시지에는 클라이언트의 현재 상태에 대한 간결한 정보가 포함됩니다. 상태 메시징 시스템은 다음을 포함하여 Configuration Manager 특정 구성 요소에서 사용됩니다.
- 소프트웨어 업데이트
- 원하는 구성 관리
- 네트워크 액세스 보호
중요한 소프트웨어 업데이트 데이터는 Configuration Manager 상태 메시징 시스템에 의존합니다. 더 많은 구성 요소가 이를 활용함에 따라 향후 버전의 Configuration Manager 상태 메시징을 이해하는 것이 더욱 중요해질 것입니다.
다음 다이어그램에서는 상태 메시징 시스템의 작동 방식에 대해 잘 설명합니다.
녹색 상자는 상태 메시징 시스템을 나타냅니다. 상자 내의 구성 요소는 정보를 시스템에 공급하는 구성 요소입니다.
상태 메시지가 수신되면 다음 두 가지가 발생합니다.
- 상태 메시지는 WMI(Windows Management Instrumentation) 공급자에 저장됩니다.
- 상태 시스템은 전송되지 않은 상태 메시지에 대해 15분 주기(기본값)로 WMI를 스크래핑한 다음 관리 지점으로 전달합니다. 주기 기간을 변경할 수 있습니다.
다이어그램에서 클라이언트 설치 조각은 명확성을 위해 별도로 표시됩니다. 클라이언트를 설치하는 동안 관리 지점이 위치하고 상태 메시지를 대상으로 합니다. 클라이언트 설치에 대한 상태 메시지는 다음 조건 중 하나에서 대체 상태 지점(구성된 경우)으로 전달됩니다.
- 관리 지점에 도달하지 않습니다.
- 관리 지점은 어떤 이유로 중단되었습니다.
다른 모든 항목의 경우 트래픽은 관리 지점으로 직접 이동합니다.
관리 지점에 도착하는 상태 메시지는 MP Relay 구성 요소에 의해 파일로 .smx 처리되고 사이트 서버의 auth\statesys.box\incoming 폴더에 배치됩니다. 그런 다음, 워크플로를 완료하기 위해 데이터베이스로 처리됩니다.
더 깊이 파고 들기
다음을 위해 자세한 로깅을 사용하도록 설정해야 합니다.
- 클라이언트
- 관리 지점
- 사이트 서버의 상태 메시징 구성 요소
Configuration Manager 클라이언트 또는 관리 지점에서 자세한 정보 표시 또는 디버그 로깅을 설정하려면 다음 레지스트리 항목을 편집하거나 만듭니다.
| 레지스트리 하위 키 | DWORD 이름 | 값 데이터 |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/CCM/Logging/@Global |
Loglevel | 0 |
KEY_LOCAL_MACHINE/SOFTWARE /Microsoft/CCM/Logging/DebugLogging |
사용 | True |
사이트 서버에서 다음 레지스트리 항목을 편집하여 자세한 로깅을 사용하도록 설정한 다음 서비스(또는 상태 시스템 구성 요소)를 다시 시작 SMS_Executive 합니다.
| 레지스트리 하위 키 | DWORD 이름 | 값 데이터 |
|---|---|---|
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/SMS/Components/SMS_STATE_SYSTEM |
자세한 정보 로깅 | 1 |
SQL 명령을 추적하려면 Configuration Manager 구성 요소에 대해 SQL 추적을 사용하도록 설정해야 합니다. 그러나 추적에서 직접 얻을 수 있는 유용한 데이터는 별로 없습니다. Profiler를 사용하도록 설정한 경우에도 마찬가지입니다. 따라서 클라이언트의 Updatesdeployment.log 및 Statemessage.log 파일을 살펴보겠습니다. 이러한 로그의 상태 메시지를 해석하여 프로세스의 다양한 단계에서 발생하는 작업을 명확하게 파악할 수 있습니다.
로그 코드 예제를 검토하기 전에 상태 메시지 형식을 이해해야 합니다. 상태 메시지 자체는 토픽 유형 및 상태 메시지 ID를 비롯한 여러 부분으로 구성됩니다. 로그의 일부 위치에서 토픽 형식 이 이미 해석된 것 같습니다.
동일한 로그에 토픽 유형 및 상태 메시지 ID 가 항상 함께 표시되지는 않습니다. 다른 형식의 데이터가 없으면 필요한 항목을 결정하는 데 실제로 도움이 되지 않습니다. 그러나 토픽 유형 과 상태 메시지 ID가 모두 있는 경우에도 해석할 수 없다면 정보가 유용하지 않습니다.
다음 차트는 및 StateID 의 TopicType 조합을 해석하여 의미 있는 데이터를 가져오는 데 도움이 될 수 있습니다.
select * from v_StateNames
참고
다음 차트에는 300, 400 및 500 시리즈 토픽 형식 코드가 포함되어 있습니다.
상태 메시징 데이터
| TopicType | StateID | StateName |
|---|---|---|
| 300 | 0 | 준수 상태를 알 수 없음 |
| 300 | 1 | 규정 |
| 300 | 2 | 비준수 |
| 300 | 3 | 충돌이 감지됨 |
| 301 | 0 | 적용 상태를 알 수 없음 |
| 301 | 1 | 업데이트 설치 |
| 301 | 2 | 다시 시작 대기 중 |
| 301 | 3 | 다른 설치가 완료 될 때까지 대기 중 |
| 301 | 4 | 업데이트를 설치했습니다. |
| 301 | 5 | 시스템 다시 시작 보류 중 |
| 301 | 6 | 업데이트를 설치하지 못했습니다. |
| 301 | 7 | 업데이트 다운로드 |
| 301 | 8 | 다운로드한 업데이트 |
| 301 | 9 | 업데이트를 다운로드하지 못했습니다. |
| 301 | 10 | 설치하기 전에 유지 관리 기간 대기 |
| 301 | 11 | 타사 오케스트레이터가 설치를 시작하기를 기다리는 중 |
| 302 | 0 | 평가 상태를 알 수 없음 |
| 302 | 1 | 평가 활성화됨 |
| 302 | 2 | 평가에 성공했습니다. |
| 302 | 3 | 평가 실패 |
| 400 | 0 | 검색 상태를 알 수 없음 |
| 400 | 1 | 필요하지 않음 |
| 400 | 2 | 검색되지 않음 |
| 400 | 3 | 감지함 |
| 401 | 0 | 준수 상태를 알 수 없음 |
| 401 | 1 | 규정 |
| 401 | 2 | 비준수 |
| 401 | 3 | 충돌이 감지됨 |
| 401 | 4 | 오류 |
| 401 | 5 | 해당 없음 |
| 401 | 6 | 검색되지 않음 |
| 401 | 7 | Enforced |
| 402 | 0 | 적용 상태를 알 수 없음 |
| 402 | 1 | 적용 시작됨 |
| 402 | 2 | 콘텐츠를 기다리는 적용 |
| 402 | 3 | 다른 설치가 완료 될 때까지 대기 중 |
| 402 | 4 | 설치하기 전에 유지 관리 기간 대기 |
| 402 | 5 | 설치하기 전에 다시 시작해야 합니다. |
| 402 | 6 | 일반 오류 |
| 402 | 7 | 설치 보류 중 |
| 402 | 8 | 업데이트 설치 |
| 402 | 9 | 시스템 다시 시작 보류 중 |
| 402 | 10 | 업데이트를 설치했습니다. |
| 402 | 11 | 업데이트를 설치하지 못했습니다. |
| 402 | 12 | 업데이트 다운로드 |
| 402 | 13 | 다운로드한 업데이트 |
| 402 | 14 | 업데이트를 다운로드하지 못했습니다. |
| 500 | 0 | 검색 상태를 알 수 없음 |
| 500 | 1 | 업데이트가 필요하지 않음 |
| 500 | 2 | 업데이트가 필요합니다. |
| 500 | 3 | 업데이트가 설치됨 |
| 501 | 0 | 검사 상태를 알 수 없음 |
| 501 | 1 | 카탈로그 위치 검색 대기 중 |
| 501 | 2 | 검사가 실행 중입니다. |
| 501 | 3 | 검사 완료됨 |
| 501 | 4 | 검색이 보류 중인 재시도 |
| 501 | 5 | 검사 실패 |
| 501 | 6 | 오류로 완료된 검사 |
자세한 내용은 Configuration Manager 상태 메시지를 참조하세요.
다음 예제에서는 Updatesdeployment.log 및 Statemessage.log 파일을 정렬하고 비교합니다. 로그가 동일한(녹색 텍스트)를 정렬하여 동일한 TopicID 상태 메시지를 참조하는지 확인합니다. 두 로그가 동일한 상태 메시지를 참조하고 있음을 명확하게 나타냅니다. 는 TopicType 연한 파란색 텍스트로 표시됩니다. 하나의 로그에 상태 메시징 데이터 차트에서 해석할 수 있는 실제 번호가 표시될 수 있습니다. 다른 값은 제네릭 값(이미 해석됨)을 표시할 수 있습니다. 상태 메시지 ID(StateId)는 자주색 텍스트로 표시됩니다.
차트에서 TopicType 및 상태 메시지 ID (StateId)를 결합하여 로그에서 발생하는 작업을 정확하게 추적할 수 있습니다. 이 예제에서 이러한 코드 예제는 다음 정보를 보여 줍니다.
- 평가 업데이트
- 평가 결과
- 다운로드 중인 업데이트
- 설치 중인 업데이트
- 보류 중인 시스템 다시 시작
상태 메시지가 상태 시스템으로 전송되는 방법의 한 예일 뿐입니다.
상태 메시징 데이터 흐름
다음 이미지는 상태 메시징 데이터가 관리 지점으로 이동하고 데이터베이스로 처리되는 방법에 대한 실제 예제입니다.
이 예제에서는 테스트 클라이언트를 사용합니다. 먼저 클라이언트가 모든 상태 메시징 정보에 대해 WMI를 스크래핑하도록 강요한 다음, 다음 폴링 주기에 해당 정보를 관리 지점으로 보냅니다.
WMI에서 상태 메시지는 네임스페이 root\ccm\statemsg 스에 저장됩니다. 해당 네임스페이스에는 두 가지 관심 CCM_StateMsg_SerialNum 클래스인 및 CCM_StateMsg가 있습니다.
CCM_StateMsg_SerialNum 클래스는 상태 메시지에 사용되는 마지막 일련 번호를 기록하는 데 사용됩니다. 모든 상태 메시지에는 하드웨어 인벤토리와 유사한 고유한 일련 번호가 있습니다. 이러한 방식으로 사이트 서버는 시스템에서 상태 메시지가 누락되었는지 여부를 추적할 수 있습니다. 상태 메시지가 누락되면 불완전하거나 부정확한 상태 보고가 발생할 수 있기 때문에 중요합니다.
클래스에는 CCM_StateMsg 상태 메시지 자체가 포함됩니다. 클래스 instance 기록된 모든 상태 메시지를 찾을 수 있습니다.
이러한 메시지 중 하나를 열면 다음 예제와 같이 상태 메시지의 세부 정보와 이전에 설명한 일부 데이터를 찾을 수 있습니다.
다음 다시 동기화 스크립트를 사용하여 데이터를 관리 지점에 다시 전송하고 진행률을 추적할 수 있습니다.
RefreshServerComplianceState()
Sub RefreshServerComplianceState()
dim newCCMUpdatesStore
set newCCMUpdatesStore = CreateObject ("Microsoft.CCM.UpdatesStore")
newCCMUpdatesStore.RefreshServerComplianceState
wscript.echo "Ran RefreshServerComplianceState."
End Sub
$UpdatesStore = New-Object -ComObject Microsoft.CCM.UpdatesStore
$UpdatesStore.RefreshServerComplianceState()
이 스크립트는 웹의 다양한 위치에서 찾을 수 있습니다. Configuration Manager SDK를 사용하여 클라이언트가 관리 지점에 데이터를 다시 보내도록 합니다.
일반적으로 VBScript(Visual Basic 스크립트)는 를 사용하여 cscript실행됩니다. 직접 실행하려고 하면 스크립트가 실패할 수 있습니다. 문제는 Configuration Manager 64비트 서버에서 실행되는 32비트 애플리케이션이라는 점입니다. 의 cscript 기본 버전은 64비트 버전이며 일반적으로 모든 VBScript에서 잘 작동합니다. 그러나 이 경우 호출을 수행하려면 syswow64 폴더가 부족해야 하는 32비트 버전 cscript 이 필요합니다.
다음 상태 메시지 폴링 주기가 발생하면 모든 상태 메시지가 관리 지점으로 전송됩니다.
Statemessage.log 파일에서 상태 메시지 정보가 끌어오고 XML로 서식이 지정된 다음 관리 지점으로 전송되는 것을 볼 수 있습니다. 상태 메시지 정보는 다음 예제와 유사해야 합니다.
<! [LOG[StateMessage body: <?xml version="1.0" encoding="UTF-16"?>
<보고서><ReportHeader><식별><컴퓨터><ClientInstalled>1</ClientInstalled><ClientType>1</ClientType><ClientID>GUID:GUID</ClientID>
<ClientVersion>client_version_number</ClientVersion><NetBIOSName>name</NetBIOSName><CodePage>437</CodePage>
<SystemDefaultLCID>1033</SystemDefaultLCID></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent>
<ReportType>Full</ReportType><날짜>/<날짜><버전>1.0</버전><형식>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="time" SerialNumber="serial_number"><Topic ID="21e49ac6-a273-4a61-9794-eb675bc743e5" Type="500" IDType="3"/><State ID="2" Criticality="0"/><UserParameters Flags="0" Count="1"><Param>102</ Param></UserParameters></StateMessageserParameters></StateMessage></ReportBody></Report>
]LOG<![ LOG[CStateMsgManager::GetSignEncyptMode]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1820">
<! [LOG[관리 지점에 상태 메시지를 성공적으로 전달했습니다]LOG]!><time="time" date="date" component="StateMessage" context="" type="1" thread="3592" file="statemsg.cpp:1527">
참고
이 예제는 XML 파일의 크기 때문에 단일 상태 메시지로 잘립니다.
Statemessage.log 파일은 메시지가 관리 지점으로 디스패치되었음을 기록하지만 상태 메시징 시스템은 실제로 데이터를 관리 지점으로 이동하지 않습니다. 다음 예제에서는 이 작업을 수행하는 것을 CCMMessaging 볼 수 있습니다. 이 시점에서 백그라운드에서 더 많은 것을 진행합니다. 그러나 데이터를 관리 지점(이 경우 MP_Relay 구성 요소)으로 보내는 것을 아는 CCMMessaging 것으로 충분합니다.
<! [LOG[OutgoingMessage(Queue='mp_mp_relay엔드포인트', ID={A9E7A07D-223D-4F5D-93D5-15AF5B72E05C}): 'host_name'을 호스트하는 데 성공했습니다.] 로그]!>
에서 처리하기 MP_Relay위해 데이터가 도착하면 처리되고 파일 형식으로 .smx 변환된 다음 폴더에 auth\statesys.box\incoming 넣습니다.
Inv-Relay 작업: 메시지 본문 처리
Relay: FileType= SMX
Relay: Outbox dir: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\statesys.box\incoming
릴레이: 첨부 파일 0개 수신됨
릴레이: 0개 중 0개의 첨부 파일이 성공적으로 처리됨
Inv-Relay: 작업이 성공적으로 완료됨
폴더에서 auth\statesys.box\incoming 처리 중인 파일을 볼 .smx 수 있습니다. 일반적으로 여기에 표시되지 않습니다. 그러나 파일이 이 폴더에 남아 있는 경우 메시지가 무엇이며 왜 처리되지 않는지 조사해야 합니다. 파일을 찾으 .smx 면 메모장과 같은 텍스트 편집기를 사용하여 파일을 열어 세부 정보를 볼 수 있습니다. 그러나 다음 예제와 같이 파일의 서식을 읽을 수 없을 수 있습니다.
확장명을 .smx 추가하여 .xml 파일 이름을 file_name.smx.xml 지정한 다음 새 파일 이름을 두 번 클릭하면 XML 파일이 인터넷 Explorer 열리고 읽기가 훨씬 쉽습니다.
다음 이미지는 인터넷 Explorer 열린 XML 파일의 예입니다. 컴퓨터 및 상태 메시지의 세부 정보가 강조 표시됩니다. 여기에는 이전에 설명한 정보가 고유 상태 메시지 ID 값과 결합되어 있습니다.
참고
이러한 파일의 이름을 바꾸는 경우 먼저 Statesys.box 폴더에 영향을 주지 않도록 다른 폴더에 복사합니다.
마지막으로 상태 메시지를 데이터베이스로 처리해야 합니다. Statesys.log 파일에서 다음 예제와 유사한 메시지를 볼 수 있습니다.
처리할 새 상태 메시지를 찾아 스레드 처리를 시작합니다.
스레드 "상태 메시지 처리 스레드 #0" ID:5076 시작
CMessageProcessor - 검색된 부모 사이트 'site_name'
CMessageProcessor - 처리 파일: mdlbp169. SMW
CMessageProcessor - 잘못된 레코드가 0개인 1개의 레코드를 처리했습니다.
CMessageProcessor - 파일 "mdlbp169를 성공적으로 복제했습니다. 부모 사이트 site_name SMW"
CMessageProcessor - 잘못된 파일 0개와 함께 이 일괄 처리에서 1개의 메시지 파일을 처리했습니다.
스레드 "상태 메시지 처리 스레드 #0" id:5076이 정상적으로 종료됨
데이터베이스 처리 구성 요소는 SQL 추적을 사용하도록 설정하여 표시할 수 있지만 큰 도움이 되지는 않습니다. 대신 SQL 프로파일러를 사용해야 합니다. 프로파일러가 백그라운드에서 발생하는 일에 대한 힌트를 제공하지만 완전히는 아닙니다. 여러 SQL 저장 프로시저는 상태 메시지 처리를 담당합니다. 또한 데이터베이스의 여러 테이블은 상태 메시징 데이터를 저장합니다. 상태 메시지 처리를 수행하는 저장 프로시저는 일반적으로 이름으로 spProcess시작합니다. 이러한 절차는 많이 있습니다.
사이트 서버는 도착하는 상태 메시지를 추적하므로 누락된 메시지에 플래그를 지정하고 필요한 경우 주기적으로 다시 동기화를 요청할 수 있습니다. 상태 메시지는 중요합니다. 당신은 어떤을 놓치고 싶지 않아요.
상태 메시지가 도착하면 고유 ID가 읽고 데이터베이스에 저장됩니다. 처리가 계속되면 데이터가 정기적으로 업데이트됩니다. 간격이 감지되면 해당 데이터에 플래그가 지정되고 테이블에 누락된 상태 메시지 SR_MissingMessageRanges 로 저장됩니다. 이상적으로 이 테이블은 비어 있습니다. 그러나 프로덕션 환경에서는 테이블에 데이터가 표시 될 수 있습니다. 이 표는 다시 동기화가 필요한 상태 메시지를 추적하는 데 도움이 됩니다.
사이트 제어 파일은 데이터베이스에 있습니다. 에 대한 STATE_MESSAGE_SYSTEM특정 설정을 가져오려면 기본 또는 CAS 사이트에서 다음 쿼리를 실행합니다.
select * from SC_Component_Property where ComponentID in (select ID from SC_Component where ComponentName like 'SMS_STATE_SYSTEM') and sitenumber in (select SiteNumber from SC_SiteDefinition where Sitecode = (Select ThisSiteCode from SMSData))
STATE_MESSAGE_SYSTEM 설정
| 이름 | Value1 | Value2 | Value3 |
|---|---|---|---|
| 하트비트 Msg 간격 | 60 | ||
| 받은 편지함 폴링 간격 | 900 | ||
| 로더 청크 크기 | 256 | ||
| 로더 스레드 | 4 | ||
| 인출된 최대 청크 | 100 | ||
| 최소 누락 메시지 기간 | 2880 | ||
| 다시 동기화 확인 간격 | 15 | ||
| 구성 다시 시도 | REG_SZ | <Config><Retry PatternID="0" RetryQueue="0">7200,28800,86400</Retry></Config> | 0 |
참고
- Resync Check Interval 은 60 분으로 설정됩니다. 상태 메시지 다시 동기화가 필요한 시스템을 검사하기 위한 일정입니다.
- 최소 누락 메시지 기간 은 2880으로 설정됩니다. 다시 동기화를 요청하기 전에 메시지가 누락되어야 하는 기간입니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기