관리 콘솔에서 단말이 오프라인으로 표시될 때는 네트워크 연결만 확인해서는 부족합니다. 에이전트 서비스 상태, 관리 서버 주소 해석, 인증서·시간 동기화, 프록시 정책, 마지막 체크인 기록을 순서대로 점검해 재등록 전 복구 가능성을 판단합니다.
관리 콘솔의 단말 아이콘이 회색으로 바뀌고 상태 갱신이 멈추면, 단순히 인터넷이 되는지만 확인해서는 원인을 찾기 어렵습니다. 화면 사용은 가능하지만 관리 정책이 내려오지 않거나 자산 정보가 오래된 시각에 멈춰 있을 수 있습니다. 이때는 오프라인 표시 자체보다 마지막 체크인 시각과 에이전트의 실행 상태를 먼저 읽어야 합니다. 네트워크 단절, 관리 서버 주소 오류, 인증서 검증 실패, 프록시 정책은 서로 비슷한 결과를 만들지만 조치 방법은 다릅니다. 무작정 재등록하면 기존 그룹과 정책 설정을 다시 맞춰야 할 수 있으므로, 연결 복구 가능성을 우선 판단하는 편이 안전합니다. 초기 확인이 어렵다면 동네형컴퓨터 010-6833-8119 로 현재 화면과 마지막 통신 시간을 기준으로 점검 범위를 상담할 수 있습니다.
에이전트 체크인 경로가 끊긴 지점 찾기
관리 콘솔에서 먼저 확인할 항목은 마지막 연결 시각, 단말 식별값, 적용된 정책의 수신 이력입니다. 마지막 체크인 시간이 일정 시점에서 동시에 멈춘 단말이 여러 대라면 관리 서버, DNS, 방화벽처럼 공통 경로를 의심해야 합니다. 반대로 한 대만 멈췄다면 해당 단말의 에이전트 서비스, 로컬 네트워크 설정, 인증서 저장소를 먼저 보는 순서가 효율적입니다.
창동 STATUS_DEVICE_OFFLINE 상태를 확인할 때도 콘솔의 오프라인 문구만 보고 단말 고장으로 판단하면 안 됩니다. Wyse Management Suite 는 단말 에이전트가 지정된 서버에 정해진 주기로 체크인하지 못할 때 연결되지 않은 상태로 표시할 수 있습니다. 즉, 웹 브라우징이나 사내 업무망 접속이 가능하더라도 관리 통신 경로만 막혀 있을 수 있습니다.
| 확인 결과 | 우선 의심 지점 | 먼저 할 조치 |
|---|---|---|
| 여러 단말의 체크인 시간이 동시에 멈춤 | 관리 서버, DNS, 방화벽, 프록시 | 서버 주소 해석과 포트 정책 확인 |
| 한 대만 오프라인, 화면 사용은 가능 | 에이전트 서비스 중지·손상 | 서비스 상태와 로그 시간 확인 |
| 서비스는 실행 중이나 연결 시각 미갱신 | TLS 인증서, 시간 오차, 프록시 인증 | 시간대·인증서 오류·프록시 경로 분리 |
단말 측에서는 Wyse Device Agent 관련 서비스가 실행 중인지, 시작 유형이 중지 또는 수동으로 바뀌지 않았는지 확인합니다. 서비스가 실행 중이라도 실제 서버 주소로 접근하지 못하면 체크인은 회복되지 않습니다. 관리 서버가 내부형인지 클라우드형인지 구분한 뒤, 설정된 서버 주소가 변경되지 않았는지와 이름 해석 결과가 기대한 주소인지 함께 확인해야 합니다.
인증서와 시간 오차로 막힌 관리 통신 구분하기
관리 통신이 TLS 기반이라면 시스템 시간이 틀어진 것만으로도 인증서 검증이 실패할 수 있습니다. 날짜뿐 아니라 시간대, 자동 시간 동기화, NTP 동기화 성공 여부를 확인하고, 최근 CMOS 배터리나 네트워크 환경 변경이 있었는지도 살핍니다. 오류 로그에 인증서 신뢰, 보안 연결, 핸드셰이크, 만료 관련 문구가 있다면 단순 서비스 재시작보다 시간과 인증서 체인을 먼저 검토해야 합니다.
그다음에는 DNS, 프록시, 방화벽을 한 번에 바꾸지 말고 순서대로 분리합니다. 관리 서버 이름이 올바른 IP로 해석되는지 확인한 후, 프록시가 관리 에이전트 통신에도 적용되는지 봅니다. 프록시 인증이 필요한 환경에서는 사용자 브라우저가 인터넷에 연결돼도 시스템 서비스 계정의 통신은 차단될 수 있습니다. 마지막으로 관리 서버에 필요한 포트가 단말에서 나가는 방향으로 허용되는지 확인하면 문제 지점을 좁힐 수 있습니다.
재시작·에이전트 복구·재등록의 선택 기준
가장 먼저 할 수 있는 조치는 에이전트 서비스 재시작입니다. 재시작 직후 로그의 기록 시간이 새로 갱신되는지, 콘솔의 마지막 체크인 시각이 바뀌는지를 비교합니다. 로그가 새로 작성되는데도 서버 응답 실패가 반복되면 통신 경로 문제에 가깝고, 서비스 시작 자체가 실패하거나 관련 파일 오류가 나타나면 에이전트 복구를 검토할 수 있습니다.
에이전트 복구 전에는 현재 단말이 속한 그룹, 적용 정책, 네트워크 설정, 등록 식별 정보의 보존 범위를 확인해야 합니다. 재등록은 관리 서버 주소가 바뀌었거나 등록 정보가 손상돼 기존 연결을 되살릴 수 없을 때 선택하는 마지막 단계입니다. 특히 창동 STATUS_DEVICE_OFFLINE처럼 현상명만 같아도 단말 OS, 에이전트 버전, 서버 유형에 따라 복구 절차가 달라집니다. 재등록부터 진행하기보다 마지막 체크인 이후의 로그 변화가 있는지 확인하는 편이 설정 유실 위험을 줄입니다.
방문 점검이 필요한 경우
단말 화면 접근이 가능하고 관리자 권한이 준비돼 있다면 서비스 상태, 관리 서버 경로, DNS 응답, 로그와 설정값은 원격으로 우선 확인할 수 있습니다. 부팅이 되지 않거나 네트워크 자체가 끊겼고, BIOS 수준 설정 또는 현장 보안망 확인이 필요한 경우에는 방문 점검이 적합합니다. 창동 현장 작업은 단말 접근 가능 시간과 관리 서버 접속 권한을 맞춘 뒤 진행하면 불필요한 대기 시간을 줄일 수 있습니다.
끊긴 단말을 다시 관리에 연결할 때
서비스를 재시작한 뒤에도 체크인 시간이 갱신되지 않거나, 여러 단말에서 같은 시각부터 연결이 멈췄다면 원인 분리가 필요한 시점입니다. 문의 전에는 오류 화면, 단말 모델명, OS와 에이전트 버전, 마지막 체크인 시각, 관리 서버가 내부형인지 클라우드형인지 정리해 두면 확인 속도가 빨라집니다. 프록시 또는 방화벽 변경 이력도 함께 전달하면 관리 통신 문제를 더 정확히 구분할 수 있습니다.
동네형컴퓨터는 출장 점검을 오전 9 시부터 오후 6 시까지 서울·경기·인천·세종에서 진행하며, 원격 점검은 새벽 시간을 제외하고 가능합니다. 에이전트 재시작 후에도 연결 시각이 바뀌지 않는다면 010-6833-8119 또는 https://udns.kr/로 오류 화면과 확인 내용을 남겨 주세요.
자주 묻는 질문
Q. 관리 화면에서 단말이 오프라인으로 보인다는 것은 무엇인가요?
A. 대체로 단말의 관리 에이전트가 서버에 정상 체크인하지 못하고 있다는 뜻입니다. 단말 전원이 꺼졌다는 의미와 항상 같지는 않으며, 화면 사용이 가능한 상태에서도 나타날 수 있습니다.
Q. 네트워크가 되는데도 관리 상태가 복구되지 않는 이유는 무엇인가요?
A. 관리 서버 주소, DNS 해석, 프록시, 방화벽, 시간 동기화, 인증서 검증, 에이전트 서비스처럼 관리 통신에만 영향을 주는 원인이 남아 있을 수 있습니다.
Q. 원격으로 처리할 수 있는 범위는 어디까지인가요?
A. 단말 화면 접근과 관리자 권한이 가능하면 서비스 상태, 네트워크 경로, 로그, 설정값을 원격으로 점검할 수 있습니다. 부팅 불가, 완전한 네트워크 단절, BIOS 설정 문제는 현장 확인이 필요할 수 있습니다.
마무리: 오프라인으로 멈춘 단말은 재등록부터 시작하기보다 마지막 체크인 시각, 에이전트 실행 상태, 서버 통신 경로를 차례로 확인해야 합니다. 시간·인증서·프록시 문제를 분리한 뒤에도 체크인이 회복되지 않을 때 에이전트 복구와 재등록을 결정하는 것이 안정적인 관리 연결 복구 절차입니다.