Defender for Endpoint 온보딩이 실패하는 6가지 원인을 Sense 서비스 로그, Client Analyzer, Intune·GPO 진단 순서로 5분 안에 좁혀내는 헬프데스크 실무 가이드입니다.
업데이트: 2026년 7월 10일
Microsoft Defender for Endpoint 온보딩 실패는 대부분 Sense 서비스가 클라우드 엔드포인트(*.endpoint.security.microsoft.com)에 연결하지 못하는 상황에서 발생합니다. 즉, 라이선스나 정책이 아니라 프록시·방화벽·인증서 신뢰 체인 문제인 경우가 90% 이상이죠. 이 글에선 온보딩 스크립트 실패, "Not onboarded" 상태 지속, Sense 서비스 시작 안 됨 등 헬프데스크에서 실제로 자주 접수되는 6가지 시나리오를 진단 명령·이벤트 로그와 함께 정리했습니다. 목표는 하나입니다. Defender for Endpoint 온보딩 실패를 5분 안에 원인 계층까지 좁히는 것.
MpCmdRun.exe -EnableIntegrityServices와 Get-MpComputerStatus가 아니라 Client Analyzer(MDEClientAnalyzer.cmd) 실행 결과입니다.HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status의 OnboardingState=1 여부가 클라우드 등록 성공의 유일한 기준입니다.솔직히 말해, 제일 먼저 해야 할 일은 Microsoft 365 Defender 포털의 "Device inventory"만 보고 판단하지 않는 겁니다. 포털은 최대 24시간까지 지연이 있고, 특히 온보딩 직후에는 "Can be onboarded" 상태로 오래 남아요. 실제 진실은 클라이언트 레지스트리와 Sense 서비스 상태에 있습니다. 관리자 권한 PowerShell에서 아래 세 줄을 순서대로 실행하세요.
Get-Service -Name Sense | Select-Object Status, StartType
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" | Select-Object OnboardingState, OrgId, LastConnected
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntispywareEnabled, RealTimeProtectionEnabled, IsTamperProtected정상 온보딩된 장치는 Sense 서비스가 Running / Automatic, OnboardingState = 1, OrgId가 GUID로 채워져 있고, LastConnected가 최근 시각이어야 합니다. OnboardingState = 0이면 스크립트는 실행됐지만 클라우드 등록에 실패한 상태예요. OrgId가 비어 있다면 온보딩 스크립트가 아예 정책을 쓰지 못한 것이며, 대부분 관리자 권한 없이 실행됐거나 GPO 우선순위에 밀린 경우입니다.
한 가지 더 있습니다. LastConnected가 3일 이상 갱신되지 않으면 클라우드 통신이 끊긴 상태로 간주하고 즉시 방화벽·프록시 진단으로 넘어가야 해요. 저는 지난 4월에 재택 근무자 노트북 40대에서 이 값만 확인해 회사 SSL 인터셉트 어플라이언스가 Defender 트래픽을 재서명해 신뢰 체인을 끊고 있다는 걸 20분 만에 특정한 적이 있습니다. (당시 보안팀은 세 시간째 라이선스 문제를 의심하고 있었죠.)
Sense 서비스(Windows Defender Advanced Threat Protection Service)가 "Access denied", "Error 1053: The service did not respond in a timely fashion", 또는 아예 시작 후 즉시 중지되는 증상이 가장 흔합니다. 이벤트 뷰어의 Microsoft-Windows-SENSE/Operational 로그를 열고 아래 표에서 이벤트 ID를 매칭하세요.
| 이벤트 ID | 의미 | 즉시 조치 |
|---|---|---|
| 5 | Sense가 클라우드에 성공적으로 연결됨(정상) | 조치 불필요 (정상 신호) |
| 6 | 서비스 시작됐으나 아직 온보딩되지 않음 | 온보딩 스크립트 재실행 또는 정책 확인 |
| 15 | URL 통신 실패(프록시·방화벽 차단) | 연결 URL 예외 등록, TelemetryProxyServer 설정 확인 |
| 25 | 온보딩 페이로드 유효성 검증 실패 | WindowsDefenderATPOnboardingScript.cmd 재다운로드 |
| 30 | 서비스가 이미 오프보딩됨 | 레지스트리 정리 후 완전 재온보딩 필요 |
| 71 | Microsoft Defender Antivirus가 수동 모드가 아님 | 3rd-party AV 제거 또는 EDR in block mode 활성화 |
제가 CDW에서 다뤘던 사례의 60% 이상이 이벤트 15번이었어요. 이벤트 15는 무조건 방화벽·프록시·SSL 인터셉트 셋 중 하나입니다. HTTPS 검사(SSL 인터셉트)를 하는 SASE·SWG 장비는 반드시 Defender for Endpoint 대상 URL을 검사 예외로 등록해야 하는데요. 인증서 재서명이 들어가는 순간 Sense는 클라우드를 신뢰하지 않고 조용히 실패합니다. 오류 메시지도 흐릿해서 헬프데스크가 놓치기 쉽고요.
2026년 기준 Defender for Endpoint는 통합 URL 세트(*.endpoint.security.microsoft.com 및 *.events.data.microsoft.com)를 사용합니다. 과거의 winatp-gw-*, wd-* 개별 URL 목록은 신규 온보딩에서 요구되지 않지만, 오래된 방화벽 룰이 살아 있으면 오히려 새 트래픽이 차단됩니다. Microsoft가 제공하는 최신 목록은 Defender for Endpoint 프록시 및 인터넷 연결 설정 문서에서 확인하세요.
최소 필수 URL 세트는 다음과 같습니다.
# EDR 및 자동 조사 트래픽
*.endpoint.security.microsoft.com
*.events.data.microsoft.com
*.wdcp.microsoft.com
*.wdcpalt.microsoft.com
# 클라우드 딜리버드 프로텍션(MAPS)
*.smartscreen.microsoft.com
*.smartscreen-prod.microsoft.com
# 진단 데이터 및 원격 측정
settings-win.data.microsoft.com
*.blob.core.windows.net프록시를 사용한다면 온보딩 이전에 시스템 컨텍스트(LocalSystem)에서 프록시가 어떻게 인식되는지 확인해야 합니다. 사용자 컨텍스트의 프록시 설정은 Sense 서비스에 전혀 적용되지 않기 때문이죠. PsExec으로 netsh winhttp show proxy를 SYSTEM으로 실행하거나, 정적 프록시를 원한다면 그룹 정책의 Configure the proxy server URL을 사용하세요.
# SYSTEM 컨텍스트에서 실제 프록시 상태 확인
psexec -s -i cmd.exe
netsh winhttp show proxy
# WinHTTP 프록시를 IE 설정에서 가져오기(현장 노트북에 유용)
netsh winhttp import proxy source=ieIntune에서 Endpoint security → Endpoint detection and response 프로필을 만들었는데 대상 장치가 계속 "Not onboarded"로 남는다면, 8할은 그룹 대상(Assignment)이 아닌 MDM 사용자 스코프 문제입니다. Entra ID(구 Azure AD)의 Mobility (MDM and MAM) 블레이드에서 Microsoft Intune의 MDM user scope가 "None"으로 되어 있으면 EDR 프로필은 절대 적용되지 않아요. 이게 Intune 관리 콘솔에서는 그냥 "정책 배포됨"으로만 보여서 원인 파악이 오래 걸립니다. 저도 처음 이 함정에 걸렸을 땐 하루를 통째로 날렸습니다.
확인 순서는 다음과 같습니다.
dsregcmd /status 실행 → AzureAdJoined : YES 및 MdmUrl이 enrollment.manage.microsoft.com인지 확인추가로 확인할 흔한 함정이 두 가지 있습니다. 첫째, "Microsoft Defender for Endpoint" 커넥터가 Intune과 연동되지 않은 경우입니다. Intune 관리 센터의 Endpoint security → Microsoft Defender for Endpoint에서 "Connection status: Enabled"인지 확인하세요. 둘째, Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations 토글이 꺼져 있으면 EDR 정책이 배포되어도 온보딩 페이로드가 함께 오지 않습니다. Active Directory 계정 및 정책 이슈가 얽혀 있는 환경이라면 gpupdate /force 안 됨 해결 진단 가이드를 참고해 GPO와 MDM 정책이 서로 덮어쓰지 않는지 함께 점검하시길 권합니다.
레거시 환경에서는 여전히 GPO 시작 스크립트를 통해 WindowsDefenderATPOnboardingScript.cmd를 배포하는 경우가 많습니다. 문제는 이 스크립트가 조용히 실패한다는 점이죠. 스크립트는 종료 코드 0을 리턴해도 실제로는 레지스트리 쓰기에 실패했을 수 있습니다.
안정적인 진단을 위해서는 시작 스크립트를 아래처럼 로깅을 강제하는 래퍼로 감싸는 게 좋습니다.
@echo off
REM MDE 온보딩 스크립트 래퍼. 결과를 이벤트 로그와 파일에 남긴다
set LOG=%WINDIR%\Temp\MDE_Onboard_%COMPUTERNAME%.log
echo [%DATE% %TIME%] Onboarding 시작 >> "%LOG%"
REM 이미 온보딩된 경우 skip (중복 실행 방지)
reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" /v OnboardingState 2>nul | find "0x1" >nul
if %ERRORLEVEL% EQU 0 (
echo [%DATE% %TIME%] 이미 온보딩됨. 종료. >> "%LOG%"
exit /b 0
)
REM 스크립트 실행 및 결과 로깅
call "\\domain.local\NETLOGON\MDE\WindowsDefenderATPOnboardingScript.cmd" >> "%LOG%" 2>&1
set RC=%ERRORLEVEL%
REM 이벤트 로그에도 기록 (SCCM/Intune에서 수집 가능)
eventcreate /T INFORMATION /ID 9001 /L APPLICATION /SO "MDE_Onboard" /D "MDE onboarding 완료 RC=%RC%"
exit /b %RC%이 래퍼를 GPO의 Computer Configuration → Windows Settings → Scripts → Startup에 등록하면 재실행 방지, 로그 파일 저장, 이벤트 로그 기록이 한 번에 됩니다. 대량 배포에서는 이벤트 ID 9001만 수집해도 성공률을 실시간으로 볼 수 있고요.
Microsoft 공식 툴인 Client Analyzer는 대부분의 헬프데스크가 존재를 모르거나, 알아도 결과 리포트를 어떻게 읽어야 하는지 몰라서 잘 안 씁니다. 저는 신입 SC-200 응시자에게 이 툴 사용을 필수로 가르쳐요. 다운로드는 MDE Client Analyzer 공식 배포 페이지에서 받을 수 있습니다.
실행 절차부터 봅시다.
# 관리자 권한 명령 프롬프트에서
cd C:\MDEClientAnalyzer
MDEClientAnalyzer.cmd
# 원격 조사가 필요한 경우(사용자 환경 재현이 어려울 때)
MDEClientAnalyzerPreview.cmd -o # 온라인 상태만 검사
MDEClientAnalyzerPreview.cmd -a # 전체 진단 + 트레이스실행이 끝나면 MDEClientAnalyzerResult\SystemInfoLogs 폴더에 MDEClientAnalyzer.htm 리포트가 생성됩니다. 이 리포트에서 반드시 확인해야 하는 섹션은 네 개인데요.
온보딩 스크립트를 세 번, 네 번 재실행해도 상태가 바뀌지 않는다면 클라우드 측 디바이스 레코드가 손상됐거나, 오래된 SenseGuid가 남아 있는 상태입니다. 이 경우 부분 재실행으로는 절대 복구되지 않아요. 반드시 완전 오프보딩 후 재온보딩이 필요합니다.
절차는 다음과 같습니다.
WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd 실행Get-Service Sense가 Stopped, OnboardingState = 0인지 확인7일 대기 시간은 실무에서 가장 자주 무시되지만 가장 자주 문제의 원인이 되는 부분입니다. Defender는 SenseGuid로 디바이스를 식별하는데, 오프보딩 직후에는 이 GUID가 아직 유효 상태로 남아 있어 새 온보딩과 충돌할 수 있어요. 급한 경우 Microsoft 지원 티켓으로 강제 삭제를 요청할 수 있지만, 대부분의 헬프데스크 환경에서는 그냥 기다리는 게 빠릅니다.
2026년 기준으로 Microsoft Monitoring Agent(MMA) 기반 온보딩은 완전히 지원 종료됐습니다. Windows Server 2012 R2, 2016, 2019, 2022 모두 통합 에이전트(unified agent, MDE.Windows.Server 패키지)를 사용해야 하죠. 이 전환 과정에서 헬프데스크가 자주 놓치는 문제가 두 가지 있습니다.
첫째, Server 2012 R2와 2016은 통합 에이전트 설치 전에 반드시 Servicing Stack Update와 최신 누적 업데이트가 선행되어야 합니다. 이 사전 조건 없이 설치 시 MDESetupError: 0x80070643 오류로 조용히 실패해요. 로그는 %WINDIR%\Temp\MDEInstall.log에 남습니다.
둘째, Windows Server의 Defender Antivirus는 서버 역할에 따라 기본 제외 규칙이 자동 등록되지만, 온보딩 후에는 이 규칙을 다시 검토해야 합니다. 특히 도메인 컨트롤러의 경우 SYSVOL, NTDS, 그리고 Group Policy 처리 경로가 제외되지 않으면 정책 처리 지연이 발생합니다. AD 계정 잠금 조사가 겹치는 상황이라면 Active Directory 계정 잠금 원인 찾기 PowerShell 추적 가이드의 이벤트 상관관계 방법과 조합해 진단하면 근본 원인 격리가 훨씬 수월합니다.
서버 온보딩 상태는 다음 명령으로 확인합니다.
# 통합 에이전트 버전 확인 (10.8000 이상이어야 최신)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection" | Select-Object Version
# 서버용 Sense 서비스 진단
sc query sense
sc qc sense
Get-WinEvent -LogName "Microsoft-Windows-SENSE/Operational" -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, MessageServer Core나 원격 데스크톱 서비스가 활성화된 서버는 트래픽 패턴이 워크스테이션과 다르기 때문에, 정책 배포 전에 시험 서버 하나로 최소 3일간 관찰하고 검토된 EDR 정책만 대량 배포하시길 권합니다. 원격 세션 이슈가 함께 발생하는 경우 헬프데스크에서 자주 참고하는 Windows 11 원격 데스크톱(RDP) 연결 오류 해결 가이드와 교차 점검하면 원인 축소에 도움이 됩니다. 대규모 배포 이전에는 Microsoft 공식 온보딩 문제 해결 문서의 사전 점검 표를 반드시 훑어보세요.
관리자 권한 PowerShell에서 Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status"를 실행해 OnboardingState가 1인지, OrgId가 GUID로 채워져 있는지, LastConnected가 최근 값인지를 함께 확인하면 60초 안에 정확한 상태를 파악할 수 있습니다.
Tamper Protection이 활성화된 상태에서 3rd-party AV가 남아 있거나, 그룹 정책이 Sense 서비스 시작 유형을 Disabled로 강제하는 경우가 많습니다. Get-Service Sense의 StartType이 Automatic이 아니면 정책 소스를 gpresult로 추적하고, 남아 있는 3rd-party AV는 완전 제거 후 재부팅하세요.
Connectivity Test 섹션이 최우선입니다. 필수 URL 중 하나라도 200/301이 아니면 다른 어떤 설정도 무의미하기 때문이죠. 그다음 Sense Configuration의 OnboardingState 값과 EDR Sensor Health의 최근 15·30번 이벤트를 순서대로 확인하는 것이 실무에서 가장 빠른 진단 경로입니다.
Microsoft 365 관리 센터 → Billing → Licenses에서 사용자 할당 여부를 먼저 확인하고, 그다음 Defender 포털의 Settings → Endpoints → Licenses에서 잔여 P1/P2 시트를 확인합니다. 온보딩 자체는 시트가 남아 있으면 성공하지만, 고급 기능(자동 조사, Threat & Vulnerability Management 등)은 P2 라이선스에서만 활성화됩니다.
Entra 관리 센터의 Mobility(MDM and MAM) 블레이드에서 Microsoft Intune의 MDM user scope가 대상 사용자 그룹을 포함하는지 먼저 확인하세요. "None"으로 설정되어 있으면 프로필이 배포된 것으로 표시되어도 실제 클라이언트에는 도달하지 않습니다. 그다음 클라이언트에서 dsregcmd /status로 MDM URL이 올바른지 검증합니다.
Microsoft Teams 마이크가 작동하지 않을 때 Windows 11 권한, Teams 장치 설정, Bluetooth 헤드셋, Intune 정책, 오디오 드라이버까지 순서대로 점검하는 단계별 헬프데스크 가이드.
Windows 11에서 프린터가 오프라인으로 표시되는 세 가지 핵심 원인(Spooler 중단, SNMP 폴링 실패, 오프라인 사용 옵션)을 PowerShell·GUI·그룹 정책으로 한 번에 해결하는 헬프데스크 실전 가이드입니다.
Windows 11 BitLocker 복구 키를 5가지 방법으로 찾는 헬프데스크 실무 가이드. Microsoft 계정, Entra ID, Active Directory, PowerShell, manage-bde까지 1티어가 5분 안에 잠금을 풀 수 있는 절차를 정리합니다.