버전 12.0 이상에서 ECE를 PCCE와 통합
목차
소개
이 문서에서는 버전 12.0 이상에서 ECE(Enterprise Chat and Email)를 PCCE(Packaged Contact Center Enterprise)와 통합하는 단계에 대해 설명합니다
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
- ECE(Enterprise Chat and Email) 12.x
- PCCE(Packaged Contact Center Enterprise) 12.x
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 버전을 기반으로 합니다.
- ECE 12.5(1)
- PCCE 12.5(1)
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
PCCE 버전 12.0에는 SPOG(Single Pane of Glass)라는 새로운 관리 인터페이스가 도입되었습니다. 이제 이 인터페이스에서 컨택 센터 및 관련 애플리케이션의 거의 모든 관리가 수행됩니다. ECE와 PCCE를 모두 제대로 통합하려면 이 통합에 고유한 여러 단계를 완료해야 합니다. 이 문서에서는 이 프로세스를 안내합니다.
용어
이 문서에서는 이러한 용어를 사용합니다.
- ECE(Enterprise Chat and Email) - ECE는 음성 통화와 동일한 방식으로 이메일 및 채팅 요청을 컨택 센터 상담원에게 라우팅할 수 있는 제품입니다.
- SPOG(Single Pane of Glass) - SPOG는 버전 12.0 이상에서 PCCE 관리를 수행하는 방식입니다. SPOG는 12.0 이전 버전에서 사용된 CCE 관리 툴을 완전히 다시 쓴 것입니다.
- CA(Certificate Authority) - PKI(Public Key Infrastructure) 모델에 따라 디지털 인증서를 발급하는 엔티티입니다.
두 가지 유형의 CA가 있습니다.
- 공용 CA - 공용 CA는 루트 및 중간 인증서가 대부분의 브라우저 및 운영 체제에 포함되어 있는 CA입니다. 일부 공용 CA에는 IdenTrust, DigiCert, GoDaddy 및 GlobalSign이 포함됩니다.
- 프라이빗 CA - 프라이빗 CA는 회사 내에 존재하는 CA입니다. 일부 프라이빗 CA는 공용 CA에서 서명하지만, 대개 독립형 CA이며 발급하는 인증서는 해당 조직의 컴퓨터에서만 신뢰합니다.
두 CA 유형 중 하나에는 두 가지 유형의 CA 서버가 있습니다.
- 루트 CA 서버 - 루트 CA 서버가 자체 인증서를 서명합니다. 표준 멀티티어 PKI 구축에서는 루트 CA가 오프라인이며 액세스할 수 없습니다. 이 모델의 루트 CA는 중간 CA라고 하는 다른 CA 서버에만 인증서를 발급합니다. 일부 기업은 단일 계층 CA만 사용하도록 선택합니다. 이 모델에서는 루트 CA가 다른 CA 서버가 아닌 엔티티에서 사용할 인증서를 발급합니다.
- Intermediate CA Server(중간 CA 서버) - 중간 또는 발급 CA 서버는 다른 CA 서버가 아닌 엔티티에서 사용할 인증서를 발급합니다.
- MMC(Microsoft Management Console) - 다양한 스냅인을 로드할 수 있도록 하는 Microsoft Windows에 포함된 응용 프로그램입니다. 스냅인을 사용하여 서버 관리를 위한 사용자 지정 콘솔을 만들 수 있습니다. Windows에는 다양한 스냅인이 포함되어 있습니다. 인증서, 디바이스 관리자, 디스크 관리, 이벤트 뷰어, 서비스 등의 간단한 목록이 있습니다.
- NLB(Network Load Balancer) - 일반 물리적 이름으로 최종 사용자에게 여러 물리적 리소스를 제공하는 디바이스 또는 애플리케이션입니다. NLB는 웹 애플리케이션 및 서비스와 매우 일반적입니다. NLB는 여러 가지 방법으로 구현될 수 있습니다. ECE와 함께 사용할 경우 쿠키 삽입 또는 이와 동등한 방법을 사용하여 사용자 세션이 동일한 물리적 백엔드 웹 서버로 반환되도록 NLB를 구성해야 합니다. 이를 쿠키 삽입과 함께 스티키 세션이라고 합니다. 고정 세션은 모든 상호 작용에 대해 동일한 물리적 백엔드 서버에 사용자의 세션을 반환하는 로드 밸런서의 기능을 가리킵니다.
- SSL(Secure Sockets Layer) 패스스루 - SSL 패스스루는 최종 사용자 디바이스와 사용자의 세션이 할당된 물리적 웹 서버 간에 SSL 세션이 존재하는 방법입니다. HTTP 세션이 항상 물리적으로 암호화되므로 SSL 패스쓰루에서는 쿠키 삽입을 허용하지 않습니다. 대부분의 NLB는 세션 설정의 serverhello 및 clienthello 부분을 모니터링하고 고유한 값을 테이블에 저장하는 스틱 테이블을 사용하여 SSL 통과를 사용하는 스티커 세션을 지원합니다. 이 값과 일치하는 다음 요청이 NLB에 제시되면 스틱 테이블을 사용하여 동일한 백엔드 서버에 세션을 반환할 수 있습니다.
- SSL Offload(SSL 오프로드) - SSL 오프로드에 대해 NLB가 구성된 경우 지정된 최종 사용자 세션에 대해 2개의 SSL 세션 또는 터널이 존재합니다. 첫 번째는 최종 사용자 디바이스와 웹 사이트의 NLB에 구성된 VIP(가상 IP) 간의 문제입니다. 두 번째는 NLB의 백엔드 IP와 사용자의 세션이 할당된 물리적 웹 서버 사이입니다. SSL 오프로드는 HTTP 스트림이 완전히 암호 해독되는 동안 추가 HTTP 쿠키를 삽입할 수 있고 세션 검사를 수행할 수 있는 NLB에서 쿠키 삽입을 지원합니다. SSL 오프로드는 웹 애플리케이션에 SSL이 필요하지 않지만 보안을 위해 수행되는 경우 자주 사용됩니다. 현재 버전의 ECE는 비 SSL 세션에서 애플리케이션에 대한 액세스를 지원하지 않습니다.
필수 단계
두 시스템의 통합을 시작하기 전에 완료해야 하는 몇 가지 전제 조건이 있습니다.
- 최소 PCCE 패치 레벨
- 버전 12.0(1) - ES37
- 버전 12.5(1) - 기본 기능에 대한 최신 최소 버전 없음
- 최소 ECE 패치 레벨
ECE에서는 최신 ES(Engineering Special)를 실행하는 것이 좋습니다.
- 버전 12.0(1) - ES3 + ES3_ET1a
- 버전 12.5(1) - 기본 기능에 대한 최신 최소 버전 없음
- 구성 항목
ECE_Email, ECE_Chat 및 ECE_Outbound MRD(Media Routing Domain)를 올바른 애플리케이션 인스턴스와 연결해야 합니다.
- PCCE 2000 에이전트 구축 모델의 경우 애플리케이션 인스턴스는 MultiChannel이며 PCCE를 구축할 때 미리 구성됩니다.
- PCCE 4000/12000 에이전트 구축 모델의 경우 애플리케이션 인스턴스는 모든 이름일 수 있으며 통합을 수행하는 사용자가 생성해야 합니다. 모범 사례는 {site}_{peripheral_set}_{application_instance}의 형식을 사용하는 것입니다.
사이트 이름을 Main으로, 주변 장치를 PS1로, 응용 프로그램 인스턴스를 Multichannel로 하여 PCCE를 설치한 경우 응용 프로그램 인스턴스 이름은 Main_PS1_Multichannel입니다.
통합 단계
이 문서의 모든 단계에 대한 자세한 내용은 ECE 및 PCCE 설명서에서 모두 다루지만 목록에 표시되지 않으며 모두 동일한 문서에 표시되지 않습니다. 자세한 내용은 이 문서의 끝에 있는 링크를 참조하십시오.
1단계. SSL 인증서 구성
ECE 웹 서버에서 사용할 인증서를 생성해야 합니다. 자체 서명 인증서를 사용할 수 있지만 CA 서명 인증서를 사용하는 것이 더 쉬운 경우가 많습니다. 자체 서명 인증서는 CA 서명 인증서보다 안전하지 않으므로 인증서를 처음 생성하는 단계가 적지만 인증서를 교체해야 할 경우 모든 PCCE 관리 데이터 서버의 Java 키 저장소에 새 인증서를 업로드해야 합니다. CA 서명 인증서를 사용하는 경우 루트 인증서와 중간 인증서(있는 경우)만 키 저장소에 업로드하면 됩니다.
구축에 여러 웹 서버가 있는 경우 이 지침을 검토해야 합니다. 네트워크 로드 밸런서를 구성하는 데 필요한 특정 단계는 이 문서의 범위에 속하지 않습니다. 필요한 경우 로드 밸런서 공급업체에 문의하십시오.
- 로드 밸런서는 필요하지 않지만 구현을 크게 간소화합니다
- 각 웹 서버의 ECE 애플리케이션에 액세스하려면 사용된 로드 밸런서 방법과 상관없이 SSL을 사용해야 합니다
- 로드 밸런서는 SSL 패스스루 또는 SSL 오프로드로 구성할 수 있습니다
- SSL 통과를 선택한 경우
- 한 서버에서 모든 인증서 작업을 수행해야 합니다
- 인증서가 올바르게 구성되면 인증서를 내보내고 개인 키가 PFX(개인 정보 교환) 파일에 포함되어 있는지 확인해야 합니다
- 배포의 다른 모든 웹 서버에 PFX 파일을 복사한 다음 IIS로 인증서를 가져와야 합니다
- SSL 오프로드를 선택한 경우 각 웹 서버는 고유한 개별 SSL 인증서로 구성할 수 있습니다
1.1단계. 인증서 생성
이미 인증서를 만들거나 가져온 경우 이 섹션을 건너뛰고, 그렇지 않은 경우 두 옵션 중 하나를 선택할 수 있습니다.
옵션 1. 자체 서명 인증서 사용
- IIS 관리로 이동합니다.
- 왼쪽의 Connections 트리에서 서버 이름을 선택합니다.
- 중앙 창에서 서버 인증서를 찾아 두 번 클릭하여 엽니다.
- 오른쪽의 Actions(작업) 창에서 Create Self-Signed Certificate...를 선택합니다.
- Create Self-Signed Certificate(자체 서명 인증서 생성) 창에서 Specify a friendly name for certificate(인증서에 대해 친숙한 이름 지정): 상자에서 이름을 선택하고 입력합니다. 이 이름은 다음 주 단계의 선택 프로세스에서 인증서가 표시되는 방법입니다. 이 이름은 인증서의 일반 이름과 일치하지 않아도 되며 인증서가 최종 사용자에게 표시되는 방식에는 영향을 주지 않습니다.
- Select a certificate store for the new certificate: 드롭다운 상자에서 Personal이 선택되었는지 확인합니다.
- OK(확인)를 선택하여 인증서를 생성합니다.
- 다음 주요 단계인 Bind certificate to website(인증서를 웹 사이트에 바인딩)로 진행합니다.
옵션 2. CA 서명 인증서 사용
CA 서명 인증서는 CSR(Certificate Signing Request)을 생성해야 합니다. CSR은 CA로 전송된 텍스트 파일이며, 여기서 CA가 서명되고, 서명된 인증서가 필수 CA 인증서와 함께 반환되고 CSR이 이행됩니다. IIS 관리 또는 MMC(Microsoft Management Console)를 통해 이 작업을 수행할 수 있습니다. IIS 관리 방법은 특별한 지식이 필요하지 않으므로 훨씬 쉬우며 인증서의 Subject 특성에 포함된 필드를 구성하고 비트 길이를 변경할 수만 있습니다. MMC에는 추가 단계가 필요하며 유효한 CSR에 필요한 모든 필드에 대한 철저한 지식을 갖추고 있어야 합니다. MMC는 인증서 생성 및 관리에 대해 보통 ~ 전문가 수준의 경험이 있는 경우에만 사용하는 것이 좋습니다. 배포에서 둘 이상의 정규화된 이름으로 ECE에 액세스해야 하거나 인증서의 일부(주체 및 비트 길이 제외)를 변경해야 하는 경우 MMC 메서드를 사용해야 합니다.
- IIS 관리를 통해
다음 단계를 사용하여 IIS 관리자를 통해 CSR(Certificate Signing Request)을 생성합니다.
- IIS 관리로 이동합니다.
- 왼쪽의 Connections 트리에서 서버 이름을 선택합니다.
- 중앙 창에서 서버 인증서를 찾아 두 번 클릭하여 엽니다.
- 오른쪽의 Actions(작업) 창에서 Create Certificate Request...를 선택합니다. Request Certificate 마법사가 나타납니다.
- Distinguished Name Properties 페이지에서 시스템의 양식에 값을 입력합니다. 모든 필드를 입력해야 합니다. 계속하려면 다음을 선택하십시오.
- Cryptographic Service Provider Properties(암호화 서비스 공급자 속성) 페이지에서 암호화 서비스 공급자에 대한 기본 선택 사항을 그대로 유지합니다. Bit length: 드롭다운을 최소 2048로 변경합니다. 계속하려면 다음을 선택하십시오.
- File Name(파일 이름) 페이지에서 CSR 파일을 저장할 위치를 선택합니다.
- CA에 파일을 제공합니다. 서명된 인증서를 받으면 웹 서버에 복사하고 다음 단계로 진행합니다.
- IIS 관리자의 같은 위치에 있는 [작업] 창에서 [인증서 요청 완료]를 선택합니다. 마법사가 나타납니다.
- Specify Certificate Authority Response(인증 기관 응답 지정) 페이지에서 CA가 제공한 인증서를 선택합니다. 식별 이름 상자에 이름을 지정합니다. 이 이름은 다음 주 단계의 선택 프로세스에서 인증서가 표시되는 방법입니다. 새 인증서에 대한 인증서 저장소 선택: 드롭다운이 Personal로 설정되어 있는지 확인합니다.
- OK(확인)를 선택하여 인증서 업로드를 완료합니다.
- 다음 주요 단계인 Bind certificate to website(인증서를 웹 사이트에 바인딩)로 진행합니다.
- MMC(Microsoft Management Console)를 통해
다음 단계를 사용하여 MMC를 통해 CSR을 생성합니다. 이 방법을 사용하면 CSR의 모든 측면을 사용자 정의할 수 있습니다.
- 시작 단추를 마우스 오른쪽 단추로 누르고 실행을 선택합니다.
- 실행 상자에 mmc를 입력하고 확인을 선택합니다.
- MMC 창에 인증서 스냅인을 추가합니다.
- 파일, 스냅인 추가/제거 순으로 선택합니다. 스냅인 추가 또는 제거 상자가 나타납니다.
- 왼쪽의 목록에서 Certificates(인증서)를 찾은 다음 Add(추가) >를 선택합니다. Certificates(인증서) 스냅인 상자가 나타납니다.
- 컴퓨터 계정 옵션을 선택한 다음 다음 >을 선택합니다.
- [컴퓨터 선택] 페이지에서 [로컬 컴퓨터:(이 콘솔이 있는 컴퓨터)]가 선택되었는지 확인한 다음 [마침]을 선택합니다.
- OK(확인)를 선택하여 Add or Remove Snap-ins(스냅인 추가 또는 제거) 상자를 닫습니다.
- CSR 생성
- 왼쪽 창에서 Certificates (Local Computer)(인증서(로컬 컴퓨터)를 확장하고 Personal(개인)을 확장한 다음 Certificates(인증서) 폴더를 선택합니다.
- Certificates(인증서) 폴더를 마우스 오른쪽 버튼으로 클릭하고 All Tasks(모든 작업) > Advanced Operations(고급 작업)로 이동한 다음 Create Custom Request(맞춤형 요청 생성)...를 선택합니다. Certificate Enrollment 마법사가 나타납니다.
- 소개 화면에서 다음을 선택합니다.
- Select Certificate Enrollment Policy(인증서 등록 정책 선택) 페이지에서 Custom Request(사용자 지정 요청) 아래에 나열된 Proceed without enrollment(등록 정책 없이 진행)를 선택하고 Next(다음)를 선택합니다.
- Custom request(맞춤형 요청) 페이지에서 선택한 템플릿이 (템플릿 없음) CNG 키이고, Request format(요청 형식)이 CA에 적합한지 확인합니다. PKCS #10은 Microsoft CA에서 작동합니다. 다음 페이지로 진행하려면 다음을 선택합니다.
- Certificate Information(인증서 정보) 페이지에서 Details(세부 정보)라는 단어 옆의 드롭다운을 선택한 다음 Properties(속성) 버튼을 선택합니다. Certificate Properties 양식이 나타납니다.
- 인증서 속성 양식의 모든 옵션을 제공하는 것은 이 문서의 범위를 벗어납니다. 자세한 내용은 Microsoft 설명서를 참조하십시오. 여기 이 양식에 대한 몇 가지 메모와 팁이 있습니다.
- Subject:(제목:) 탭의 Subject name:(제목 이름:) 섹션에 모든 필수 값을 입력합니다
- Common name에 대해 제공된 값이 Alternative name: 섹션에도 제공되었는지 확인합니다
- Type:을 DNS로 설정하고 Value: 상자에 URL을 입력한 다음 Add(추가) > 버튼을 선택합니다
- ECE에 액세스하기 위해 여러 URL을 사용하려면 이 필드에 각 대체 이름을 입력하고 각 URL 뒤에 Add >를 선택합니다
- Private Key(개인 키) 탭의 Key size(키 크기)를 1024보다 큰 값으로 설정해야 합니다.
- HA 설치에서와 같이 여러 웹 서버에서 사용할 인증서를 내보내려는 경우 개인 키 내보내기를 선택해야 합니다. 이렇게 하지 않으면 나중에 인증서를 내보낼 수 없습니다
- 입력한 값과 선택한 항목은 검증되지 않습니다. 모든 필수 정보를 제공하거나 CA가 CSR을 완료할 수 없도록 해야 합니다
- 모든 항목을 선택한 후 확인을 클릭하여 마법사로 돌아갑니다. 다음 페이지로 진행하려면 다음을 선택합니다.
- 오프라인 요청을 저장할 위치를 선택하십시오. 페이지에서 액세스할 수 있는 위치에 있는 파일 이름을 선택합니다. 대부분의 CA에서는 형식으로 Base 64를 선택해야 합니다.
- CA에 파일을 제공합니다. 서명하고 인증서를 반환하면 인증서를 웹 서버에 복사하고 마지막 단계를 진행합니다.
- MMC용 인증서 관리 스냅인에서 Certificates (Local Computer)(인증서(로컬 컴퓨터)) > Personal(개인)으로 이동하고 Certificates(인증서)를 마우스 오른쪽 버튼으로 클릭한 다음 All Tasks(모든 작업) > Import...를 선택합니다. Certificate Import Wizard가 나타납니다.
- 소개 화면에서 Next(다음)를 선택합니다.
- File to import(가져올 파일) 화면에서 CA가 서명한 인증서를 선택한 후 Next(다음)를 선택합니다.
- Place all certificates in the following store(다음 저장소에 모든 인증서 가져오기)를 선택했는지 확인합니다.
- Certificate store:(인증서 저장소:) 상자에서 Personal(개인)이 선택되어 있는지 확인한 후 Next(다음)를 선택합니다.
- 마지막 화면을 검토한 다음 Finish(마침)를 선택하여 가져오기를 완료합니다.
- MMC 콘솔을 닫습니다. 콘솔 설정을 저장하라는 메시지가 표시되면 [아니요]를 선택합니다. 인증서 가져오기에 영향을 주지 않습니다.
- 다음 주요 단계인 Bind certificate to website(인증서를 웹 사이트에 바인딩)로 진행합니다.
1.2단계. 웹 사이트에 인증서 바인딩
- 이전에 IIS(인터넷 정보 서비스) 관리자를 열지 않은 경우 IIS 관리자를 엽니다.
- 왼쪽의 Connections 창에서 Sites(사이트)로 이동하고 Default Web Site(기본 웹 사이트)를 선택합니다.
기본 웹 사이트 이외의 사이트 이름을 사용하도록 선택한 경우 올바른 사이트 이름을 선택해야 합니다.
- 오른쪽의 Actions 창에서 Bindings...를 선택합니다. 사이트 바인딩 상자가 나타납니다.
- Type, https 및 Port가 443인 행이 없으면 다음을 완료합니다. 그렇지 않으면 다음 주요 단계로 진행합니다.
- Add...(추가...) 버튼을 선택하면 Add Site Binding(사이트 바인딩 추가) 상자가 나타납니다.
- Type: 드롭다운에서 https를 선택합니다.
- IP address: 드롭다운에 All Unassigned(모든 미할당)가 표시되고 Port:(포트:) 필드가 443인지 확인합니다.
- Host name:(호스트 이름:) 필드를 비워 두고 Require Server Name Indication(서버 이름 표시 필요) 옵션을 선택하지 않았는지 확인합니다.
- SSL certificate: 드롭다운에서 이전에 생성한 인증서에 해당하는 인증서 이름을 선택합니다.
- 어떤 인증서를 선택해야 할지 확실하지 않은 경우 선택... 단추를 사용하여 서버에 있는 인증서를 보고 검색합니다
- 선택한 인증서를 보고 세부 정보가 올바른지 확인하려면 View... 버튼을 사용합니다
- 확인을 선택하여 선택 사항을 저장합니다.
- Type(유형) 열에서 https를 표시하는 행을 선택한 다음 Edit...(편집...) 버튼을 선택합니다. Edit Site Binding 상자가 나타납니다.
- IP address: 드롭다운에 All Unassigned(모든 미할당)가 표시되고 Port:(포트:) 필드가 443인지 확인합니다.
- Host name:(호스트 이름:) 필드가 비어 있고 Require Server Name Indication(서버 이름 표시 필요) 옵션이 선택되지 않았는지 확인합니다.
- SSL certificate: 드롭다운에서 이전에 생성한 인증서에 해당하는 인증서 이름을 선택합니다.
- 어떤 인증서를 선택해야 할지 확실하지 않은 경우 선택... 단추를 사용하여 서버에 있는 인증서를 보고 검색합니다
- 선택한 인증서를 보고 세부 정보가 올바른지 확인하려면 View... 버튼을 사용합니다
- 확인을 선택하여 선택 사항을 저장합니다.
- IIS 관리자로 돌아가려면 닫기를 선택합니다.
- Type, https 및 Port가 443인 행이 없으면 다음을 완료합니다. 그렇지 않으면 다음 주요 단계로 진행합니다.
- IIS 관리자를 닫습니다.
2단계. 파티션 관리자 SSO 구성
파티션 관리자 SSO 컨피그레이션을 사용하면 ECE가 SPOG에서 ECE 가젯을 여는 모든 관리자를 위해 파티션 레벨 사용자 계정을 자동으로 생성할 수 있습니다.
2.1단계. AD(Active Directory) 인증서를 가져오고 키 저장소를 만듭니다.
이 단계는 Microsoft에서 발표한 최근 보안 변경 사항을 해결하는 데 필요할 수 있습니다. 업데이트가 적용되지 않고 도메인에 변경 사항이 없는 경우 이를 건너뛸 수 있습니다.
자세한 내용은 Microsoft KB4520412 세부 정보를 참조하십시오.
- Partition Administrator Configuration(파티션 관리자 컨피그레이션) 양식에서 제공한 AD 서버에서 Base 64 형식의 SSL 인증서를 가져옵니다. 한 가지 방법이 표시됩니다.
- 워크스테이션을 사용하여 OpenSSL에서 Windows용 OpenSSL 사본을 다운로드하고 설치합니다. 라이트 에디션은 적당합니다.
- OpenSSL 명령 프롬프트를 시작합니다.
- 이 명령을 실행합니다. 서버 이름을 글로벌 카탈로그 도메인 컨트롤러의 정규화된 이름으로 바꿉니다.
openssl s_client -connect gcdcsrv01.example.local:3269 - 출력에서 Server certificate(서버 인증서) 줄을 찾습니다.
C:openssl s_client -connect 14.10.162.6:3269
CONNECTED(00000003)
depth=1 DC = com, DC = massivedynamic, CN = MassiveDynamic Enterprise CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:
i:/DC=com/DC=massivedynamic/CN=MassiveDynamic Enterprise CA
1 s:/DC=com/DC=massivedynamic/CN=MassiveDynamic Enterprise CA
i:/C=US/OU=pki.uclabservices.com/O=Cisco Systems Inc/CN=UCLAB Services Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIH1DCCBbygAwIBAgITJwAAAAbAAn/HKFuWCQAAAAAABjANBgkqhkiG9w0BAQsF
ADBcMRMwEQYKCZImiZPyLGQBGRYDY29tMR4wHAYKCZImiZPyLGQBGRYObWFzc2l2
ZWR5bmFtaWMxJTAjBgNVBAMTHE1hc3NpdmVEeW5hbWljIEVudGVycHJpc2UgQ0Ew
HhcNMjAwNDE1MDAxNDM0WhcNMjEwNDE1MDAxNDM0WjAAMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAxFajhqjrWqQHfqTXg+SXP5pzvNVrTHIigrAam8D0 - "-----BEGIN CERTIFICATE-----"의 시작부터 "-----END CERTIFICATE-----"까지의 출력을 복사합니다. BEGIN CERTIFICATE 및 END CERTIFICATE 행이 포함되어 있는지 확인합니다.
- 복사한 정보를 새 텍스트 파일에 붙여 넣은 다음 이 정보를 crt 확장자로 컴퓨터에 저장합니다.
- 인증서 파일을 애플리케이션 서버 중 하나에 복사합니다.
- 인증서를 복사한 애플리케이션 서버에 대한 RDP 세션을 엽니다.
- 새 Java 키 저장소를 생성합니다.
- 응용 프로그램 서버에서 명령 프롬프트를 엽니다.
- ECE JDK(Java Development Kit) bin 디렉토리로 변경합니다.
- 이 명령을 실행합니다. 값을 적절하게 바꿉니다.
keytool -import -trustcacerts -alias mydomaincontroller -file C:\temp\domainctl.crt -keystore c:\ece\pcce\mydomain.jks -storepass MyP@ssword
- 12.6 이전 버전에서는 사용자 환경의 다른 모든 애플리케이션 서버에 있는 동일한 경로에 키 저장소를 복사합니다. 버전 12.6에서는 ECE를 구성하는 워크스테이션에서 액세스할 수 있는 위치에 키 저장소를 복사합니다.
2.2단계. AD LDAP(Lightweight Directory Access Protocol) 액세스 정보로 ECE를 구성합니다.
- Internet Explorer 11이 설치된 워크스테이션 또는 컴퓨터에서 비즈니스 파티션 URL로 이동합니다.
- pa로 로그인하고 시스템의 비밀번호를 입력합니다.
- 성공적으로 로그인했으면 초기 콘솔에서 Administration 링크를 선택합니다.
- SSO Configuration(SSO 컨피그레이션) 폴더로 이동합니다. Administration(관리) > Partition(파티션): default(기본값) > Security(보안) > SSO and Provisioning(SSO 및 프로비저닝).
- 오른쪽 상단 창에서 Partition Administration(파티션 관리) Configuration(컨피그레이션) 항목을 선택합니다.
- 오른쪽 하단 창에 LDAP(Lightweight Directory Access Protocol) 및 AD 값을 입력합니다.
- LDAP URL - 모범 사례로서 GC(글로벌 카탈로그) 도메인 컨트롤러의 이름을 사용합니다.
GC를 사용하지 않으면 다음과 같이 ApplicationServer 로그에 오류가 표시될 수 있습니다.
LDAP 인증 <@>의 예외
javax.naming.PartialResultException: 처리되지 않은 연속 참조; 나머지 이름 'DC=example,DC=com'- 비보안 글로벌 카탈로그 포트는 3268입니다.
- 보안 글로벌 카탈로그 포트는 3269입니다.
- DN 특성 - userPrincipalName이어야 합니다.
- Base - GC를 사용하는 경우에는 이 설정이 필요하지 않으며, 그렇지 않은 경우에는 기본 알맞은 LDAP 형식을 제공해야 합니다.
- LDAP 검색을 위한 DN - 도메인에서 익명 바인딩을 허용하지 않는 경우 LDAP에 바인딩하고 디렉토리 트리를 검색할 수 있는 사용자 DN을 제공해야 합니다.
- 보기 메뉴에서 고급 기능 옵션을 선택합니다.
- 사용자 객체로 이동한 다음 마우스 오른쪽 단추를 누르고 등록 정보를 선택합니다.
- Attributes(특성) 탭을 선택합니다.
- [필터] 단추를 선택한 다음 [값이 있는 속성만 표시]를 선택합니다.
- 목록에서 distinishedName을 찾은 다음 두 번 클릭하여 값을 봅니다.
- 표시된 값을 강조 표시한 다음 복사하여 텍스트 편집기에 붙여넣습니다.
- 텍스트 파일의 값을 복사하여 LDAP 검색 필드에 DN으로 붙여넣습니다.
값은 CN=pcceadmin, CN=Users, DC=example, DC=local과 유사해야 합니다.
- Password(비밀번호) - 지정된 사용자의 비밀번호를 제공합니다.
- LDAP에서 SSL 활성화 - 이 필드는 대부분의 고객에게 필수 항목으로 간주될 수 있습니다.
- 키 저장소 위치 - AD에서 SSL 인증서를 가져온 키 저장소의 위치여야 합니다. 이 예에서는 이미지에 표시된 대로 c:\ece\pcce\mydomain.jks입니다.
- LDAP URL - 모범 사례로서 GC(글로벌 카탈로그) 도메인 컨트롤러의 이름을 사용합니다.
- 플로피 디스크의 아이콘을 선택하여 변경 사항을 저장합니다.
3단계. 구성 파일 유효성 검사
모든 12.0 설치에는 이 섹션을 완료해야 합니다. 12.0 이외의 버전에서는 이 섹션을 건너뛸 수 있습니다.
이 단계가 필요할 수 있는 모든 버전의 추가 시나리오가 두 개 있습니다. 첫 번째는 ECE가 고가용성 설정에 설치된 경우입니다. 두 번째는 웹 서버의 호스트 이름이 ECE에 액세스하는 데 사용하는 이름과 일치하지 않는 경우입니다. 예를 들어, 호스트 이름이 UCSVRECEWEB.example.com인 서버에 ECE 웹 서버를 설치했지만 사용자가 URL이 chat.example.com인 ECE 웹 페이지에 액세스하는 경우 이 섹션을 완료해야 합니다. 서버의 호스트 이름과 ECE에 액세스하는 URL이 동일하고 버전 12.5 이상을 설치한 경우 이 단계를 건너뛰고 섹션을 완료할 수 있습니다.
{ECE_HOME}을(를) ECE를 설치한 물리적 위치로 바꿉니다. 예를 들어 C:\Cisco에 ECE를 설치한 경우 각 위치에서 {ECE_HOME}을(를) C:\Cisco으로 바꿉니다.
- 구축의 모든 ECE 웹 서버에 대한 원격 데스크톱 세션을 엽니다.
- 이 경로({ECE_HOME}\eService\templates\finesse\gadget\spog)로 이동합니다.
- spog_config.jsfile을 찾아 안전한 위치에 백업 복사본을 만듭니다.
- 텍스트 편집기에서 현재 spog_config.jsfile을 엽니다.
- 이 두 행을 찾아 구축에 맞게 업데이트합니다.
web_server_protocol은 https여야 합니다. 필요한 경우 업데이트합니다.
ECE에 액세스하기 위해 사용하도록 할당한 정규화된 이름과 일치하도록 web_server_name을 업데이트합니다. 예: ece.example.com- var 웹 서버 프로토콜 = "https";
- var web_server_name = "ece.example.com";
- 변경 사항을 저장합니다.
- 구축의 다른 모든 웹 서버에 대해 반복합니다.
4단계. PCCE 인벤토리에 ECE 추가
12.0부터 PCCE는 에이전트 2000개(2K 에이전트), 에이전트 4000개(4K 에이전트), 에이전트 12000개(12K 에이전트)의 3가지 구축 옵션을 제공합니다. 이 세 가지 구축 옵션은 2K Agent와 4K/12K Agent의 두 그룹으로 구분할 수 있습니다. SPOG에서 보이는 모습에 몇 가지 근본적인 차이가 있으므로 이렇게 나뉜다. 두 방법의 매우 높은 수준의 비교는 이 단락에 따른다. 이 문서에서는 인벤토리에 구성 요소를 추가하는 특정 단계를 제공하지 않습니다. 이 프로세스에 대한 자세한 내용은 이 문서의 끝에 있는 링크를 참조하십시오. 이 섹션에서는 PCCE에 ECE를 추가할 때 확인해야 하는 특정 세부 정보를 다룹니다. 또한 이 문서에서는 PCCE 설치가 완료되었으며 솔루션의 다른 부분에 액세스하고 구성할 수 있다고 가정합니다.
- 2K 에이전트 구축
- PCCE 구성 요소의 초기 컨피그레이션은 전적으로 CCE 관리를 통해 수행되며 자동화됩니다
- IP 또는 호스트 이름 및 필요한 자격 증명 또는 구성 요소별 컨피그레이션과 같은 세부 정보를 입력하는 팝업 상자를 통해 Inventory(인벤토리) 페이지에 새 구성 요소가 추가됩니다
- 4K 및 12K 에이전트 구축
- 초기 컨피그레이션의 대부분은 UCCE에 사용되는 단계를 반영합니다
- 구성 요소는 CCE 관리에서 다운로드한 CSV(Comma-Separated Values) 파일을 통해 추가되며, 특정 설치에 따라 정보를 입력한 다음 업로드합니다
- 초기 구축에서는 첫 번째 CSV 파일에 몇 가지 특정 구성 요소를 포함해야 합니다
- 시스템을 처음 설정할 때 추가되지 않은 구성 요소는 필요한 정보가 포함된 CSV 파일을 통해 추가됩니다
4.1단계. Java 키 저장소에 ECE 웹 서버 인증서 업로드
- 자체 서명 인증서가 사용되는 경우
- 기본 ADS(Side-A Administration Data Server)에 대한 원격 데스크톱 연결을 엽니다.
- 관리자로 Internet Explorer 11을 열고 ECE 비즈니스 파티션으로 이동합니다.
- URL 표시줄의 오른쪽에 있는 자물쇠 아이콘을 선택한 다음 View Certificates(인증서 보기)를 선택합니다.
- Certificate(인증서) 상자에서 Details(세부사항) 탭을 선택합니다.
- 탭의 하단에서 파일로 복사...를 선택합니다.
- Certificate Export Wizard(인증서 내보내기 마법사)에서 Export File Format(파일 형식 내보내기) 페이지에 도달할 때까지 Next(다음)를 선택합니다. Base-64 인코딩 X.509(.CER) 형식을 선택해야 합니다.
- ADS 서버의 c:\Temp\certificates와 같은 위치에 인증서를 저장하여 내보내기를 완료합니다.
- 다른 모든 ADS 서버에 인증서를 복사합니다.
- 관리 명령 프롬프트를 엽니다.
- Java 홈 디렉토리로 변경한 다음 bin 디렉토리로 변경합니다. Java 홈 디렉토리는 다음과 같이 액세스할 수 있습니다. cd %JAVA_HOME%\bin
- 현재 cacerts 파일을 백업합니다. %JAVA_HOME%\lib\security에서 다른 위치로 cacerts 파일을 복사합니다.
- 이전에 저장한 인증서를 가져오려면 이 명령을 실행합니다. 키 저장소 암호가 'changeit'가 아닌 경우 설치와 일치하도록 명령을 업데이트합니다.
keytool -keystore ../lib/security/cacerts -storepass changeit -import -alias <ECE 서버의 FQDN> -file <인증서를 저장한 위치> - ADS 서버를 다시 시작합니다.
- 다른 ADS 서버에서 8-12단계를 반복합니다.
- CA 서명 인증서가 사용되는 경우
- DER/PEM 형식의 루트 및 중간 인증서를 가져와 모든 ADS 서버의 C:\Temp\certificates과 같은 위치에 복사합니다.
- 기본 A측 ADS에 대한 원격 데스크톱 연결을 엽니다.
- 관리 명령 프롬프트를 엽니다.
- Java 홈 디렉토리로 변경한 다음 bin 디렉토리로 변경합니다. Java 홈 디렉토리는 다음과 같이 액세스할 수 있습니다. cd %JAVA_HOME%\bin
- 현재 cacerts 파일을 백업합니다. %JAVA_HOME%\lib\security에서 다른 위치로 cacerts 파일을 복사합니다.
- 이전에 저장한 인증서를 가져오려면 이 명령을 실행합니다. 키 저장소 암호가 'changeit'가 아닌 경우 설치와 일치하도록 명령을 업데이트합니다.
keytool -keystore ../lib/security/cacerts -storepass changeit -trustcacerts -import -alias <Name of CA root> -file <루트 인증서를 저장한 위치> - 6단계를 반복합니다. 중간 인증서가 있는 경우 가져옵니다.
- ADS 서버를 다시 시작합니다.
- 다른 모든 ADS 서버에서 2-12단계를 반복합니다.
4.2단계. 인벤토리에 ECE 데이터 서버 추가
- 데이터 서버는 시스템 인벤토리에 존재해야 하지만 PCCE ADS와 데이터 서버 간에 직접 통신이 이루어지지 않습니다
- ECE가 1500 에이전트 구축에 구축되면 데이터 서버가 서비스 서버입니다
- ECE가 HA 컨피그레이션에 설치된 경우 A측 서비스 서버만 추가합니다
4.3단계. 인벤토리에 ECE 웹 서버 추가
- 정규화된 이름으로 웹 서버를 추가해야 합니다
- 이 이름은 ECE 인증서의 일반 이름과 일치하거나 SAN(주체 대체 이름) 중 하나로 나열되어야 합니다.
- 호스트 이름 또는 IP 주소만 사용하면 안 됩니다
- ECE의 사용자 이름 및 비밀번호는 pa 로그인 자격 증명이어야 합니다
- 응용 프로그램 인스턴스가 올바른지 확인합니다.
- 애플리케이션 인스턴스 이름은 대/소문자를 구분합니다
- 2000 에이전트 PCCE 구축의 경우 애플리케이션 인스턴스는 MultiChannel입니다
- 4000/12000 에이전트 PCCE 구축의 경우 애플리케이션 인스턴스에는 사이트 및 주변 장치 집합이 이름의 일부로 포함됩니다
- ECE를 1500 에이전트 구축 또는 400 에이전트 HA 구축과 같이 둘 이상의 웹 서버와 함께 설치할 경우 로드 밸런서를 가리키는 URL 또는 각 개별 웹 서버를 가리키는 URL을 웹 서버의 정규화된 이름으로 사용할 수 있습니다. 모범 사례는 로드 밸런서를 사용하는 것입니다.
- 둘 이상의 ECE 배포가 있거나 둘 이상의 ECE 배포가 있는 배포에서 각 개별 웹 서버를 추가하도록 선택하는 경우 SPOG에서 ECE 가젯을 열 때 올바른 웹 서버를 선택하는 것이 좋습니다.
5단계. ECE와 PCCE 통합
- CCE 관리에 관리자로 로그인합니다.
- 이미지에 표시된 대로 이메일 및 채팅 카드, 이메일 및 채팅 링크를 선택합니다.
- Device Name(디바이스 이름) 드롭다운에서 현재 선택한 서버를 검토합니다. HA 설치에서 두 웹 서버를 모두 추가한 경우 웹 서버 중 하나를 선택할 수 있습니다. 나중에 시스템에 두 번째 ECE 구축을 추가하는 경우 계속하기 전에 적절한 서버를 선택해야 합니다.
- Chat and Email(채팅 및 이메일) 옆의 드롭다운 목록에서 이미지에 표시된 대로 Partition(파티션) 또는 Global(전역)을 선택합니다.
- 상단 메뉴에서 Integration을 선택한 다음 이미지에 표시된 대로 Unified CCE 옆의 화살표를 선택하고 두 번째 Unified CCE를 선택합니다.
- 설치 시 AWDB Details(AWDB 세부사항) 탭에 값을 입력한 다음 Save(저장) 버튼을 선택합니다.
- Configuration(컨피그레이션) 탭을 선택하고 다음과 같이 이 작업을 완료합니다.
- Application Instance(애플리케이션 인스턴스) 옆의 드롭다운을 선택하고 ECE에 대해 생성된 애플리케이션 인스턴스를 선택합니다.
- 흰색 + 기호가 있는 녹색 원을
선택하고 에이전트 PG를 선택합니다.
- 에이전트 PG(또는 둘 이상의 에이전트 PG)를 선택합니다.
- 모든 에이전트 PG를 추가한 후 Save(저장)를 선택합니다.
6단계. ECE 통합 검증
- CCE Administration(CCE 관리)에서 상단 상태 표시줄에 경고가 표시되지 않는지 확인합니다. 경보가 있는 경우 Alerts라는 단어를 선택하고 Inventory 페이지를 검토하여 ECE 서버에 대한 경보가 없는지 확인합니다.
- 왼쪽의 탐색 모음에서 Users(사용자), Agents(상담원) 순으로 선택합니다.
- 목록에서 에이전트를 선택하고 이를 확인합니다.
- 이제 General(일반) 탭에 Support Email & Chat(지원 이메일 및 채팅)에 대한 새로운 확인란이 표시됩니다.
- 이제 이미지에 표시된 것처럼 Enable Email & Chat(이메일 및 채팅 활성화)라는 새 탭이 표시됩니다.
- ECE용 테스트 에이전트를 활성화합니다.
- Support Email & Chat(이메일 및 채팅 지원) 확인란을 선택하고 Enable Email & Chat(이메일 및 채팅 활성화) 탭을 선택할 수 있습니다.
- Enable Email & Chat(이메일 및 채팅 활성화) 탭을 선택하고 Screen Name(화면 이름) 필드에 값을 입력합니다.
- 사용자를 업데이트하려면 Save를 선택합니다.
- 성공 메시지가 나타납니다.
- ECE가 업데이트되었는지 확인합니다.
- Overview(개요) 탐색 버튼을 선택한 다음 Email and Chat(이메일 및 채팅 카드) 및 링크를 선택합니다.
- Chat and Email(채팅 및 이메일) 옆의 드롭다운에서 상담원의 부서에 해당하는 이름을 선택합니다.
- 상단 메뉴에서 User Management(사용자 관리)를 선택한 다음 Chat and Email(채팅 및 이메일) 아래의 메뉴에서 Users(사용자)를 선택합니다.
- 목록에 새 에이전트가 표시되는지 확인합니다.
문제 해결
여러 도구를 다운로드하고 ECE 서버에 유지하는 것이 좋습니다. 따라서 시간이 지남에 따라 훨씬 더 쉽게 문제를 해결하고 솔루션을 유지 관리할 수 있습니다.
- Notepad와 같은 텍스트 편집기++
- 7-Zip과 같은 아카이브 툴
- Windows용 많은 Tail 프로그램 중 하나
몇 가지 예를 들면 다음과 같습니다.
통합 관련 문제를 해결하려면 먼저 몇 가지 키 로그 파일과 각 파일의 위치를 알아야 합니다.
-
ECE의 파일 이름 및 위치
ECE 시스템에는 많은 로그가 있으며, 이러한 로그는 통합으로 문제를 해결하려고 할 때 가장 유용합니다.
로그 파일 서버 이름 규약 설명 응용 프로그램 서버 C/A eg_log_{HOSTNAME}_ApplicationServer.log Wildfly 서버의 로그 외부 에이전트 할당 C/초 eg_log_{HOSTNAME}_EAAS-process.log MR PG와의 상호 작용 외부 에이전트 메시징 C/초 eg_log_{HOSTNAME}_EAMS-process.log CTI 서버와의 상호 작용 루트 로그 C/A/M/초 egpl_root_{HOSTNAME}.log 프로세스 간 로그, HazelCast, 일반 오류 구성 요소 상태 C/A/M/초 eg_log_{HOSTNAME}_component-status.log 프로세스 시작 및 파일 복사 완료 프로세스 시작 관리자 C/A/M/초 eg_log_{HOSTNAME}_ProcessLauncher.log 서비스 및 프로세스 시작을 위한 일반 로그 분산 서비스 관리자 C/초 eg_log_{HOSTNAME}_DSMController.log 서비스 서버에서 프로세스 시작 및 중지를 보여 주는 로그
서버 키:- C = 배치된 서버
- A = 애플리케이션 서버
- S = 서비스 서버
- M = 메시징 서버
또한 대부분의 로그 파일에는 두 개의 다른 로그가 연결되어 있습니다.
-
eg_log_{SERVERNAME}_{PROCESS}.log - 기본 프로세스 로그
-
eg_log_dal_connpool_{SERVERNAME}_{PROCESS}.log - 연결 풀 사용
-
eg_log_query_timeout_{SERVERNAME}_{PROCESS}.log - 시간 초과로 인해 쿼리가 실패할 경우 업데이트됩니다.
-
PCCE의 파일 이름 및 위치
통합 문제에 대한 PCCE 로그는 모두 A측 ADS에 있습니다. 다음은 통합 문제를 해결할 때 가장 중요한 로그입니다. 이러한 각 기능은 C:\icm\tomcat\logs에 있습니다.
로그 파일 이름 규약 설명 CCBU CCBU.{YYYY}-{MM}-{DD}T{hh}-{mm}-{ss}.{msec}.startup.log CCE 관리자 및 모든 관련 웹 애플리케이션에 대한 기본 로그 CCBU 오류 오류.{YYYY}-{MM}-{DD}T{hh}-{mm}-{ss}.{msec}.startup.log CCE 관리자 및 관련 웹 애플리케이션에 표시되는 오류 카탈리나 catalina.{YYYY}-{MM}-{DD}.log Tomcat 네이티브 로그, 인증서 오류 표시 Tomcat stdout tomcat9-stdout.{YYYY}-{MM}-{DD}.log Tomcat의 표준 발신 로그 메시지 톰캣 스타더 tomcat9-stderr.{YYYY}-{MM}-{DD}.log Tomcat의 표준 오류 로그 메시지
이 로그들 중 처음 세 가지는 가장 많이 요청되고 검토된 로그이다.다음 단계를 사용하여 추적 레벨을 설정하고 필요한 로그를 수집합니다.
-
추적 레벨 컨피그레이션
이 섹션은 ECE에만 적용됩니다. PCCE에 필요한 로그는 Cisco에서 추적 수준을 설정하며 변경할 수 없습니다.- Internet Explorer 11이 설치된 워크스테이션 또는 컴퓨터에서 시스템 파티션 URL로 이동합니다.
- sa로 로그인하고 시스템의 비밀번호를 입력합니다.
- 성공적으로 로그인했으면 초기 콘솔에서 System 링크를 선택합니다.
- System(시스템) 페이지에서 System(시스템) > Shared Resources(공유 리소스) > Logger(로거) > Processes(프로세스)를 확장합니다.
- 오른쪽 상단 창에서 추적 레벨을 변경할 프로세스를 찾아 선택합니다.
참고: HA 시스템 및 둘 이상의 애플리케이션 서버가 있는 시스템에서는 프로세스가 두 번 이상 나열됩니다. 데이터를 캡처하려면 프로세스를 포함하는 모든 서버에 대한 추적 레벨을 설정합니다. - 맨 아래의 오른쪽 창에서 Maximum trace level(최대 추적 레벨) 드롭다운을 선택하고 적절한 값을 선택합니다.
ECE에는 8개의 추적 레벨이 정의되어 있습니다. 이 목록의 4개는 가장 자주 사용되는 것입니다.- 2 - 오류 - 프로세스의 기본 추적 수준
- 4 - 정보 - 문제 해결에 일반적으로 사용되는 추적 레벨
- 6 - Dbquery - 설정 초기 문제 또는 더 복잡한 문제를 진단하는 데 도움이 되는 경우가 많습니다.
- 7 - Debug - 매우 자세한 출력, 가장 복잡한 문제에만 필요
대부분의 프로세스 추적 수준 유지, 2-오류 레벨 7 또는 8을 선택하는 경우 최대 기간도 선택해야 합니다. 최대 지속 시간이 충족되면 추적 레벨은 마지막 레벨 세트로 돌아갑니다.
시스템을 설정한 후 이 네 가지 프로세스를 추적 레벨 4로 변경합니다.- EAAS 프로세스
- EAMS 프로세스
- dx-프로세스
- rx-프로세스
- 저장 아이콘을 선택하여 새 추적 레벨을 설정합니다.
-
로그 파일 수집
- 프로세스가 필요한 로그를 기록하는 서버에 대한 원격 데스크톱 세션을 엽니다.
- 로그 파일 위치로 이동합니다.
- ECE 서버
로그는 다음과 같이 작성됩니다.
- 기본적으로 로그는 최대 크기가 5MB인 작성된 파일입니다
- 하나의 로그 파일이 구성된 최대값에 도달하면 {LOGNAME}.log.{#} 형식으로 이름이 바뀝니다.
- ECE는 이전 49개의 로그 파일과 현재 파일을 모두 유지합니다.
- 현재 로그는 항상 .log로 끝납니다.
- 로그는 아카이브되거나 압축되지 않습니다.
- 대부분의 로그는 공통된 구조를 가지고 있습니다
- 로그 파일은 <@>을 사용하여 섹션을 구분합니다
- 로그는 항상 GMT+0000 시간으로 기록됩니다.
ECE 로그는 특정 설치에 따라 다른 위치에 있습니다.
- 400개 에이전트 구축
- 단면
- 서버: 배치된 서버
- 위치: {ECE_HOME}\eService_RT\logs
- 고가용성
- Servers(서버): 두 콜로케이티드 서버
- 위치: {ECE_HOME}\eService\logs
- DFS(분산 파일 시스템) 공유를 위해 만든 디렉터리에는 설치 및 업그레이드를 위한 로그만 포함되어 있습니다.
- DSM(Distributed Systems Manager) 역할을 담당하는 서버만 서비스 역할에 속하는 구성 요소에 대해 로그를 씁니다
- DSM 역할 소유자는 Windows 작업 관리자의 [프로세스] 탭에서 찾을 수 있습니다. 이 서버에는 보조 서버에 없는 10-15개의 Java 프로세스가 있습니다.
- DSM의 구성 요소에는 EAAS, EAMS, Retriever, Dispatcher, Workflow 등이 있습니다.
- 단면
- 1500 에이전트 구축
- 역할을 호스팅하는 서버에 있는 로그
- 위치: {ECE_HOME}\eService\logs
- 서비스 서버를 제외하고 모든 서버는 구성 요소와 연관된 모든 프로세스에 대해 작동하며 로그를 기록합니다
- 고가용성 구축에서는 서비스 서버가 액티브/스탠바이 컨피그레이션으로 작동합니다
- DSM(Distributed Systems Manager) 역할을 소유한 서버만 로그를 씁니다
- DSM 역할 소유자는 Windows 작업 관리자에 표시되는 프로세스 수로 식별할 수 있습니다. 10~15개의 Java 프로세스가 기본 서버에서 실행되고 4개의 Java 프로세스만 보조 서버에서 실행됩니다
- PCCE 서버
- PCCE의 필수 로그는 C:\icm\tomcat\logs에 있습니다.
- Tomcat 로그는 롤오버 또는 보관되지 않음
- 로그는 로컬 서버 시간으로 기록됩니다
- ECE 서버
- 문제가 관찰된 후 생성되거나 수정된 모든 로그를 수집합니다.
로그 및 발견된 문제에 대한 완전한 설명은 이 문서의 범위를 벗어납니다. 몇 가지 일반적인 문제, 검토해야 할 사항, 가능한 몇 가지 해결 방법은 다음과 같습니다.- 인증서 관련 문제
- 인증서를 가져오지 않음
- 동작: SPOG에서 ECE 가젯을 열려고 하면 "페이지를 로드하는 동안 오류가 발생했습니다. 관리자에게 문의하십시오."
- 확인: PCCE에 대한 카탈리나 로그에서 다음과 유사한 오류가 있는지 확인합니다.
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX 경로 작성 실패: sun.security.provider.certpath.SunCertPathBuilderException: 요청한 대상에 대한 올바른 인증 경로를 찾을 수 없습니다. - 해결 방법: ECE 웹 서버 인증서 또는 적절한 CA 인증서를 ADS의 키 저장소로 가져왔는지 확인합니다.
- 인증서 불일치
- 동작: SPOG에서 ECE 가젯을 열려고 하면 인증서의 일반 이름 또는 주체 대체 이름이 구성된 이름과 일치하지 않음을 나타내는 오류가 표시됩니다.
- 확인: SSL 인증서 검증
- 해결 방법: 제목에 있는 공용 이름 필드나 [주체 대체 이름]에 있는 DNS 필드 중 하나에 웹 서버 이름으로 SPOG에 입력한 정규화된 이름이 포함되어 있는지 확인하십시오.
- 인증서를 가져오지 않음
- 시스템 문제
- 서비스가 시작되지 않음
- 동작: SPOG에서 ECE 가젯을 열려고 하면 "https://{url}의 웹 페이지가 일시적으로 다운되었거나 새 주소로 영구적으로 이동했을 수 있습니다."라는 오류가 표시됩니다.
- 확인: 웹 서버를 제외한 모든 ECE 서버에서 Windows 서비스 - Cisco 서비스가 시작되었는지 확인합니다. 애플리케이션 서버의 루트 로그에서 오류 검토
- 해결 방법: 모든 ECE 서비스에서 Cisco Service를 시작합니다.
- 서비스가 시작되지 않음
- 컨피그레이션 문제
- LDAP 컨피그레이션
- 동작: SPOG에서 ECE 가젯을 열려고 하면 "페이지를 로드하는 동안 오류가 발생했습니다. 관리자에게 문의하십시오."
- 확인: Application Server의 추적 레벨을 레벨 7- Debug로 높인 다음 다시 로그인을 시도하고 Application Server 로그를 검토합니다. LDAP라는 단어를 검색합니다.
- 해결 방법: 파티션 관리자 SSO에 대한 LDAP 컨피그레이션이 올바른지 확인합니다.
- LDAP 컨피그레이션
- 인증서 관련 문제
관련 정보
ECE 설치 또는 통합을 시작하기 전에 반드시 철저하게 검토해야 하는 주요 문서입니다. 이것은 ECE 문서의 포괄적인 목록이 아닙니다.
Cisco Enterprise Chat and Email 설명서의 시작 페이지에서 설치, 업그레이드 또는 통합 전에 업데이트가 있는지 확인합니다.
https://www.cisco.com/c/en/us/support/customer-collaboration/cisco-enterprise-chat-email/series.html
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
29-Jul-2020 |
최초 릴리스 |
피드백