[SQL Server] SQL Server Agent 실행이 안될 때 - DCOM/레지스트리 권한 문제

SQL Server Agent 서비스가 실행되도록 설정해서, 작업(Job) 등을 사용할 수 있도록 만들려고 했는데,,,

 

내 PC 개발환경 로컬에서 SQL Server Agent를 설정하는 과정에서 예상치 못한 "권한"이슈를 만났다..

특히, DCOM 구성 및 레지스트리 권한이 핵심 문제였다.

📂 목차

 

 

 

---

1. 사용 중인 SQL Server 버전 확인

SSMS에서 새 쿼리 창 열고 아래 입력:

Express Edition의 경우에는 Agent 사용불가 !!

-- 사용중인 SQL Server 버전 확인
SELECT @@VERSION;

 

버전 결과 예시	설명
Microsoft SQL Server Express Edition	❌ Agent 사용불가 (기본적으로 비활성화됨)
Microsoft SAL Server Standard, Developer, Enterprise	✅ Agent 사용가능

 

 

 

2. Agent 서비스 실행

① 서비스 설정

1. Service.msc 실행

2. SQL Server Agent 찾아서 우클릭 → 속성

3. 시작유형: 자동 or 수동

4. 로그온 탭: 로컬 시스템 계정 또는 계정 지정 설정

5. 확인 → 다시 실행

 

② SQL Server 구성 관리자에서도 확인

- 로그온 계정, 서비스 상태 확인

- 충돌나거나 암호 틀리면 실행 안 됨 → 이벤트 뷰어에서 확인

 

 

3. SQL Server  에이전트 계정 지정하여 로그온

SQL Server 에이전트 작업을 실행할 때, 보안상 암호 없는 계정은 허용되지 않는다.
암호가 없다면 [컴퓨터 관리] > [사용자] 에서 비밀번호를 새로 설정해야 한다. 

 

 

 

Windows에서 로컬 계정의 암호가 설정되어 있는지 확인하는 방법 (CMD)

 

그러면 내 컴퓨터에서 암호 설정이 되어 있는지 CMD에서 확인해보자.

1. 명령 프롬프트(CMD) 실행
2. 다음 명령어 입력

   net user 사용자이름

3. 결과확인

 

- "암호 필요 : 예" → 암호가 설정되어 있음

- "암호 필요 : 아니요" → 암호가 없음 (SQL Server Agent 사용 불가)

 

아니라면 아래 명령어로 설정

net user "사용자이름" *

// 비밀번호 설정 후 
net user "사용자이름" /passwordreq:yes

 

 

비밀번호 설정 이후 >> "명령을 잘 실행했습니다." 확인 문구를 보았는데, 암호 필요 → "아니오" 로 설정되어 있어서 net user "사용자이름" /passwordreq:yes 명령으로 암호사용 정책을 다시 설정했더니, 정상으로 암호사용 → "예" 로 표기 되었다.

 

 

 

 

 

4. 발생한 문제 - 에이전트 실행 실패 시 이벤트 로그 확인

• SQL Server Agent 실행 시 중지 상태 유지
• 이벤트 로그 확인 결과 이벤트 ID 10016, CLSID, APPID 관련 DCOM 권한 부족 오류 발생
• 레지스트리에서 관련 AppID 찾았지만...

 

이벤트 뷰어 확인

1. Windows 키 + R → 실행창 열기
2. eventwr 입력 

 

이벤트 ID 10016는 DCOM (Distributed COM) 구성 요소가 특정 보안 권한 없이 액세스를 시도했지만, 권한이 없어 실패한 경우 발생

 

로그 확인하여 해당 CLSD, APPID 경로 확인하였다.

 

레지스트리 실행

레지스트리 편집기에서 로그 위치를 확인해보니

 

해당 로그 파일 위치 우클릭 > 사용권한 > 고급

 

 

내 PC에 읽기 권한만 있고, 모든권한이 없었다..

해당 키의 소유자는 시스템 보호를 위한 최상위 소유자이고, 일반 관리자 권한으로도 권한 변경이 불가했다.

 

Administrators 에게 모든 권한을 줘도, 소유자가 A 일 경우에는 완전한 제어권이 아님....

결국 이슈는 회사 컴퓨터 이기 때문에 그룹정책이나 보안정책에 따라 소유자변경, 권한 상속, DCOM 활성화 등의 작업이 제한된 이슈였다. → 결국 내 로컬에서 소유자를 바꿔도 권한부여 거부됨

---

 

느낀점

• 소유자는 곧 최종 통제자 지만, 그 소유자도 시스템 정책에 따라 제한될수 있음
• 관리자 권한이 있어도 할수 없는게 분명 존재함
• 회사 환경에서는 함부로 소유자를 변경하거나 권한을 열지 못하기 떄문에, 반드시 보안 관리자와 협의 후 조치 가 필요!!