KR20050120643A - 비-침해 자동 오프사이트 패치 지문채취 및 업데이팅시스템 및 방법 - Google Patents

Abstract

소프트웨어 업데이트(232)를 발견하고, 주어진 컴퓨터(202)가 소프트웨어 업데이트를 이용할 수 있는지를 발견하고, 이어서 네트워크(200)에서 자동으로 요구될 때 소프트웨어로 컴퓨터를 업데이트하는 방법, 시스템, 및 구성된 저장 매체가 제공된다. 더우기, 실패가 검출될 때(316), 롤아웃이 정지되며(318) 소프트웨어가 이미 업데이트된 그 컴퓨터로부터 자동으로 제거될 수 있다(322). 소프트웨어 업데이트는, 네트워크의 일부가 아니지만 방화벽을 통해서 패키지 컴퓨터(230)에 억세스하는 업데이트 컴퓨터(220)에 소프트웨어 업데이트를 중간에 업로딩하므로서 네트워크 방화벽(214)를 통해서 인억세스되는 어드레스에서 원래부터 저장될 수 있다.

Description

비-침해 자동 오프사이트 패치 지문채취 및 업데이팅 시스템 및 방법{NON-INVASIVE AUTOMATIC OFFSITE PATCH FINGERPRINTING AND UPDATING SYSTEM AND METHOD}

본 발명은 원격 네트워크상에서 기존의 소프트웨어를 업데이트하는 시스템들 및 방법들에 관한 것이다. 본 발명은 특히, 사람이 감시할 필요도 없고, 타겟 네트워크 관리 장치가 소프트웨어 패치들의 사본들을 유지할 필요도 없이, 업데이트할 필요성을 점검하여 클라이언트-서버 시스템에서 요구되는 소프트웨어를 업데이트하는 것에 관한 것이다.

컴퓨터 소프트웨어 산업에서 "기술 상황"은 소프트웨어가 소정의 동작을 수행하는데 있어서 가끔 여러 예외적인 일들이 일어나고 있다는 것이다. 이러한 예외적인 동작들은 "버그"라고 불리우게 되었다.

최초의 컴퓨터 버그는, 현재는 스미소니언에 소장된, 하버드 대학 마크 Ⅱ 아이켄 릴레이 계산기의 오퍼레이션즈 로그에 놓여있다. 운영자들은 컴퓨터내의 릴레이 스위치들 사이에서 트랩되어 있는 모스(moth)를 제거하였으며, "버그가 발견된 최초의 실제 경우"라고 기재하였다. 컴퓨터 하드웨어 및 소프트웨어와 관한 문제들은 "버그"라고 명명되었으며, 이러한 문제들을 제거하는 과정은 "디버그"라고 명명되었다.

소프트웨어가 "디버그"될 때 마다, 소프트웨어의 그 부분에 변경이 야기되는데 - 이러한 변경으로 인해 때때로 "패치(patch)" 또는 "픽스(fix)"라고 하는 소프트웨어의 부가적인 부분이 생성된다. 업계의 소프트웨어 공급자들은 때로 이러한 패치를 더 형식적인 이름으로 "서비스 팩(Service Packs)" 또는 "서포트 팩(Support Packs)"이라고 부른다.

이러한 과정은 업계에서 널리 퍼져서 소프트웨어 공급자가 그들이 얻을 수 있는 "서포트 팩"을 추적하기 위해서 여러 네이밍 및 넘버링 방식을 사용하고 있따. 공급자가 표준 네이밍 및 넘버링 방식에 동의하지 못하면 이러한 "서포트 팩"을 올바로 해나가는데 따른 어려움은 증가하게 된다.

예를들어, 운영 체제 소프트웨어 제품의 윈도우 NT 계열을 갖는, 마이크로소프트는 고객들이 겪을 수 있는 문제를 해결하는데 적용될 수 있는 주요 "서비스 팩"을 적어도 6개 가지고 있다. 더 일반적으로는, 주어진 운영 체제에 대한 패치, 픽스, 솔루션 및/또는 서비스 팩의 총수는 어마어마할 수 있다.

하나의 어플리케이션이 설치되면, 이 어플리케이션은 표준 컴퓨터 파일들과 함께 이러한 운영 체제 파일 패치를 하나 이상 포함할 수 있다. 일반적으로는 패치들이 포함되는데, 이는 어플리케이션 공급자가 하나 이상의 운영 체제 파일에서 얼마의 예외적인 동작을 발견하고, 따라서 이러한 문제 파일중 하나의 상이한 버전의 형태로 "픽스"를 보내기 때문이다. 만약 단지 하나의 어플리케이션 공급자가 이러한 서비스를 수행하거나, 또는 어플리케이션 공급자에 의해서 수정된 파일이 그 공급자의 어플리케이션에 의해서만 사용되면, 이것은 비교적 적은 문제를 야기시키게 된다. 그러나, 때때로 상황이 그와 같이 않다.

또 다른 어플리케이션이 설치되면, 그 어플리케이션은 공유된 코드의 더 최신 버전을 포함할 수 있다. 이러한 공유된 운영체제 파일들의 하나의 서브세트는 DLL(Dynamically Linked Libraries)라고 하는데, 이는 다른 이름들로도 통한다. 이러한 공유된 운영체제 파일들은 때로는 실행가능하며, 이들은 일정수의 파라메터, 모종의 파라메터 등을 예상한다. 만약 공유된 파일의 속성이 변경되었으면 (예를들어, 파라메터 세트가 상이하며, 이름이 상이하고, 기능이 상이하면), 호출 어플리케이션은 더 이상 정확하게 동작하지 않을 수 있다. "프린트"와 같은 많은 공통적인 컴퓨터 기능들이 이러한 방식으로 언급된다.

많은 소프트웨어 공급자들이 최신 버전의 운영체제를 제공하고자 한다. 그러나, 상이한 어플리케이션이 컴퓨터에 로드될 때, 그것은 덧씌워져 최초의 어플리케이션이 계획대로 기능하도록 요구된 운영체제 파일을 잠재적으로(또는 그다지 잠재적이지는 않게) 변경시킬 수 도 있다.

한 조직의 관리자가 일백개의 서버를 유지 및 운영하는 한편 삼백명의 사용자가 이러한 서버들에 접속하도록 지원한다고 가정한다. 또한 이 관리자는 사용자 요청된 또는 관리 명령받은 어플리케이션들 - 쉬링크 랩(shrink wrapped) 구매 또는 내부적으로 개발된 어플리케이션 -을 설치할 책임이 있다. 이 관리자는 또한 적시에 시간에 민감한 문서들을 근거리 또는 원거리에 분배할 책임이 있다.

이제 여섯개의 서비스 팩들이 그 네트워크에 설치되어 모든 클라이언트에 분배되어야 한다고 가정한다. 여섯개의 서비스 팩을 적용하는 것은 쉽게는, 총 칠백번의 방문을 위해서 백개의 서버들 각각 및 개개에 대해서 일곱번의 방문을 야기시킨다. 이러한 수는, 서비스 팩들 중 하나의 어플리케이션이 고정되었을 때 보다 더 많은 문제들을 야기시킬 수 있으므로 머시인 당 하나의 여분의 방문을 가정하며, 따라서 이는 수행되지 않아야 한다.

삼백개의 클라이언트가 모두 동일 워크스테이션 운영체제를 실행하고 있다면, 이는 패치를 적용할 또 다른 이만 천개의 방문을 의미한다. 이 모든 것은 내부적으로 개발된 어플리케이션 및 쉬링크 랩 제품을 설치 및 패칭하는 동안에 수행되어야 함을 명심할 수 있다. 소프트웨어 패치 및 파일, 및 그 후속 어플리케이션을 분배하는 것은 "관리자 고통(administrator agony)"이라고 할 수 있는 것의 첫번째 표시가 된다.

모든 설치가 수행되는 동안, 개별 서버들은 여전히 모니터되어야 한다. 하나의 서버를 주목할 필요가 있을 때, 관리자는 때로는 또 다른 사람과 접촉하는데, 이 사람은 서버가 다운되서 고쳐야 한다고 흥분하여 보고할 수 있다. 이 관리자가 이러한 장치들을 모니터할 어떤 방법이 있다면, 그는 상황이 더 잘 대응하여 문제의 충격을 더 감소시킬 수 있게 된다. 모니터할 필요성은 "관리자 고통"의 두번째 표시이다. 때로는 관리자 직무에 상당한 변동이 있으며, 이러한 시스템의 사용자들은 생산성이 더 낮아진다.

전통적으로, 관리자는 여분의 스탭이 주어지므로 도움을 받아왔다. 물론 이러한 방법도 문제가 없는것은 아니다. 즉, 추가 인력으로 인해서 이들간의 통신 채널의 수가 증가된다. 설치 및 업데이트에 연관된 사람들은 트랙킹 장치 및 시스템을 필요로 하여 이들은 동일 단위의 작업을 수행하지 않거나 수행하고자 한다. 이러한 팀 구성원 간의 조정 부재는 "관리자 고통"의 세번째 표시이다.

현재로서는 이에 대해서 제시된 해결방안들이 형태, 수행방식, 및 적용범위 또는 완성도를 변경하여 사용된다. 전형적으로 이러한 제시된 해결방안은 관리자의 환경에 지역적으로 설치가능한(예를들면, 패치가능한) 쉬링크 랩 제품으로서 사용될 수 있다. 일부 새롭게 출시되는 제품들은 도움이 되지만, 많은 종래의 해결방안들은 관리자의 환경에서 대량의 수정을 필요로 하므로 침해하게 된다. 쉬링크 랩 솔루션은 관리자의 네트워크에서 부가적인 침해 완전 제품 설치를 요구하여, 문제를 가중시키고, 지원 또는 분배 계획을 조정하기 위한 중앙 "명령 센터"가 결핍되어 있다. 새로운 방안들은 침해의 정도가 어느정도 덜하지만, 그럼에도 불구하고 관리자와 솔루션 사이에 특별한 관계을 요구하여, 이들은 때로는 센터에 상응하는 노력을 제공하지 않는다.

더욱이, 주어진 소프트웨어의 요소(piece)가 정확히 어떤 패치를 수신하였는지가 항상 명확한 것은 아니다. 업데이트는 그 존재를 항상 명확히 알리는 것은 아니다. 따라서, 특정 컴퓨터가 미리 특정 패치를 수신하였는지 여부가 항상 명확한 것은 아니다. 따라서, 네트워크상에서 컴퓨터를 업데이트하기 위한 도구 및 기술을 개선할 필요가 있다. 그러한 도구 및 기술이 본원에 기술되며 청구된다.

본 발명의 장점 및 특징을 얻는 방법을 예시하기 위해서, 본 발명의 또 다른 특정 설명이 첨부된 도면을 참조하여 주어진다. 이러한 도면은 단지 본 발명의 선택된 특징만을 예시하며 따라서 본 발명의 범위를 제한하지는 않는다. 도면에서,

도 1은 본 발명에 따른 용도에 적합한 많은 분산된 컴퓨팅 시스템중 하나를 도시하는 도면이다.

도 2는 본 발명에 따른 시스템을 도시하는 도면이다.

도 3은 본 발명에 따른 방법을 예시하는 도면이다.

도 4는 본 발명에 따른 방법을 더 예시하는 도면이다.

도 5는 본 발명에 따른 시스템을 더 예시하는 도면이다.

도 6은 본 발명에 따른 시스템을 더 예시하는 도면이다.

도 7은 본 발명에 따른 시스템을 더 예시하는 도면이다.

도 8은 본 발명에 따른 방법을 더 예시하는 도면이다.

도 9는 본 발명에 따른 시스템을 더 예시하는 도면이다.

본 발명은, 소프트웨어가 업데이트될 필요가 있는지를 판단하고 업데이트될 필요가 있으면 인간 관리자의 요구를 줄이고 네트워크상에서 소프트웨어를 업데이트하기 위한 방법, 물품, 신호 및 시스템에 관한 것이다. 만약 업데이트가 실패하면, 업데이트 소프트웨어가 설치된 컴퓨터(들)는 넌-업데이트된 상태로 회복될 수 있다. 본 발명은 첨부된 청구범위에 의해서 정의되며, 본 요약의 보다 우선된다.

여러 실시예에서, 본 발명은 네트워크상에서, 소프트웨어 배치, 소프트웨어 설치, 소프트웨어 업데이팅, 및 다중 운영체제 및 장치에서 소프트웨어 및 패치 지문 채취 기반 파일 분산을 용이하게 한다. 네트워크 접속부 및 거기서 실행되는 업데이트 에이전트를 갖는 임의의 컴퓨터는 업데이트 서버에 접속될 수 있으며, 관리자가 그 에이전트에 지정하는 모든 태스크를 처리한다.

도 2는 그러한 하나의 시스템의 개략도이다. 간단히 도시하기 위해서 단지 두개의 타겟 컴퓨터와 업데이트 컴퓨터를 갖는 것으로 도시된 네트워크는 방화벽(214)에 의해서 인터넷으로부터 보호된다. 네트워크 타겟 컴퓨터(202, 208)를 업데이트할 필요가 있는 소프트웨어는 방화벽의 내부 또는 외부에 배치되며 방화벽에(214)에 의해서 타겟 컴퓨터(202, 208)와 직접 통신이 차단되는 패키지 컴퓨터(230, 234)에 상주한다. 그러나, 업데이트 서버(220)는, 방화벽(214)를 통해서 억세스되는 것은 물론이고, 잠재적으로는 내부 방화벽을 통해서, 네트워크(200)에 억세스(216)한다. 시스템은 완전히 오프사이트 호스트된 솔루션은 물론이고 온사이트 구매된 솔루션으로서 동작하도록 설계되며, 인트라넷/엑스트라넷 인프러스트럭쳐내에서 임의의 레벨로 방화벽 및 프록시 회로를 동작시킬 수 있다.

패치 지문(902)은 저장소 구성요소가, 주어진 소프트웨어 패키지(패치 지문과 연관된), 패치 드라이버 등이 시스템내의 컴퓨터로 로드되어야 하는지를 판단하도록 하는 해결법을 제공한다. 이러한 지문은 방화벽(214)의 내부 또는 외부에 놓일 수 있는 패치 구성요소 데이터베이스 장소(900)에 저장된다. 저장소 구성요소는 또한 네트워크 타겟 컴퓨터(202, 208) 각각에 대한 기본적인 하드웨어 및 소프트웨어 정보를 포함하는 목록 라이브러리 데이터베이스(918)를 포함한다. 패치 지문, 목록 라이브러리 내의 정보 및 각각의 네트워크 타겟 컴퓨터로부터 수집된 특정 정보를 이용하여, 시스템은 어떤 패치 및 드라이버가 주어진 컴퓨터에 요구되는지를 지능적으로 추천할 수 있다.

도 5에 도시된 바와같이, 본 발명의 바람직한 실시예는 타겟 컴퓨터(500)에 설치된 발견 에이전트(548)로 공지된 부가적인 에이전트를 채용하며, 이는 그 장치에서 하드웨어 및 소프트웨어를 루틴하게 발견한다. 이 목록 정보는 저장소 구성요소내의 다른 어딘가에 배치된 목록 라이브러리(918)에 다시 보고된다. 컴퓨터 목록에 더해서, 발견 에이전트는 또한 패치 지문을 위한 스캔 결과를 리턴하며, 이는 각 패치 지문과 연관된 특정 패치를 설치하는데 적합한지 여부를 표시한다.

목록 데이터베이스는 네트워크내의 특정 타겟 컴퓨터상에 설치되는 소프트웨어, 하드웨어 및 현재 패치 지문의 완전한 목록을 수집한다. 이러한 정보로, 업데이트 서버(528)는 네트워크내의 모든 컴퓨터에 대한 현재 패치 상태의 상세한 보고를 사용자에게 제출할 수 있다. 이는 패치내에 이미 설치된 컴퓨터는 물론이고 패치를 필요로하는 컴퓨터의 수를 나타낸다.

이에 더해서, 지문 정의(906)는 또한 시스템에 의해서 배치하는데 적합한 업데이트 패키지와 정상적으로 연관된다. 특정 패치에 대한 필요가 네트워크내의 모든 또는 임의의 컴퓨터에서 그 서명(들)을 스캐닝함으로서 설정되었으면, 관리자에 의해서 날짜 및 시간을 단순히 선택함으로서 빨리 배치될 수 있다.

일부 실시예에서, 지문 정의(906)는 이동가능한 패치 정의 파일을 형성하기 위해서 다음 즉, 패치(들)를 논하는 벤더 개시(들), 관리자를 위한 발명의 실시예에 의해서 준비되는 보고(들), 타겟 컴퓨터(500) 서명(들), 배치 패키지(들) 중 하나 이상과 결합될 수 있다. 이러한 패치 정의 파일은 다른 네트워크를 업데이트하는데 사용될 수 있는 정보를 제공한다. 패치 정의 파일(소위, "패치 메타파일")은 상이한 네트워크의 업데이트 서버(528) 중에서 패치를 이동 또는 복제하기 위해ㅓ 본 발명의 실시예에 의해서 채용될 수 있다. 적당한 네트워크(100)에는 제한없이 더 큰 보안을 제공하기 위해서 격리되는 군사용 네트워크와 같은 인터넷 및/또는 서로에 접속되지 않는 네트워크를 포함한다. 이러한 이동/복제는 이메일, 테이프 기록/판독, 및/또는 다른 종래의 데이터 전달 수단에 의해서 수행될 수 있다. 패치 메타파일은 또한 상이한 벤더에 의해서 공급되는 발명의 실시예들 사이에서 패치의 상호교환 및 상호작용을 도울 수 있다.

특정 타겟 컴퓨터에 로드될 필요가 있는 패치는 업데이트 에이전트(204, 210)과 연관된 업데이트 리스트(222)내의 업데이트 서버(220)에서 리스트되는데; 이 예에서 리스트(224)는 타겟 1(202)과 연관되며, 리스트(226)는 타겟2(208)과 연관된다. 업데이트 리스트는 패치가 발견될 수 있는 (범용 자원 로케이터 또는 URL과 같은 수단을 통해서) 적어도 하나의 장소를 규정하며, 선택적으로는 소프트웨어가 설치될 수 있는 가장 이른 날짜인 날짜를 포함한다.

동작시에, 타겟1(202)의 업데이트 에이전트(204)는 새로운 패키지가 설치되어야 하는지를 보기 위해 온사이트 또는 오프사이트 업데이트 서버(204)에서 그 업데이트 리스트(224)를 체크한다. 만약 누군가 그곳에 있다면, 업데이트 에이전트(204)는 패키지가 이미 업데이트 서버(220)상의 메모리에 있는지를 점검한다. 만약 있으면, 업데이트 에이전트(204)는 업데이트 서버(220)로 부터 소프트웨어 패치를 직접 설치하고자 시도한다. 만약 없으면, 업데이트 에이전트(204)는 패키지 컴퓨터 장소(232)로부터 소프트웨어 패치 를 직접 설치하고자 시도한다. 어떤 경우에는, 이는 성공적인데, 이 경우에 업데이트 리스트(224)가 업데이트된다.

다른 경우에, 다운로드(218)는 방화벽(214)에 의해서 방해받는다. 이와 같이 되면, 업데이트 에이전트(210)는 업데이트 서버(220)를 통보하여 업데이트 서버(220)는 패키지를 검색하고자 시도하여 메모리(228)에 배치한다. 업데이트 서버상의 그 메모리로부터, 소프트웨어는 타겟 장치에 직접 설치된다.

모니터는 소프트웨어가 타겟(202, 208)상에 적당히 설치됨을 보기 위해 점검하여, 업데이트된 소프트웨어가 정확히 실행되며 타겟 컴퓨터 자체가 관련없는 영역으로 나타나는 문제를 겪지 않음을 보장하기 위해서 계속해서 점검한다 (또는 통보될 수 있다). 패키지가 적당히 설치하는 것이 실패하거나, 또는 패치된 소프트웨어 프로그램에대한 문제를 생성하거나, 또는 타겟 컴퓨터상에 다른 문제를 생성하면, 패키지는 자동으로 제거될 수 있으며 컴퓨터는 업데이트가 제거되었거나 디스에이블된 미리 설치된 상태 또는 또 다른 허용가능한 상태로 복구되며, 타겟 컴퓨터는 동자가능한 상태에 놓인다. 패키지가 하나 이상의 컴퓨터에 설치되었으면, 이들은 모두 제거될 수 있다. 에러가 많은 컴퓨터에 대해서 롤아웃의 중간에 발생하면, 롤아웃은 중지될 수 있으며 소프트웨어는 제거되거나 디스에이블된다. 모니터는 업데이트 서버(220)에, 저장소 사이트(600)에, 적어도 부분적으로는 업데이트 에이전트(204, 210)에, 및/또는 그러한 장소를 조합한 곳에 배치될 수 있다.

설치와 관련된 문제가 있거나, 설치가 성공하면, 관리자는 이메일에 의해서, 페이저에 의해서, 또는 일부 다른 통보 수단에 의해서 통보된다.

업데이트 에이전트(204, 210)는 또한 그 자체 타겟 컴퓨터를 돌아보도록 사용될 수 있으며, 이 정보는 데이터베이스 오프사이트 또는 또 다른 장소에 저장될 수 있다. 이 정보는 가장 적합한 구성을 갖기 위해서 주어진 타겟 컴퓨터가 어떤 업데이트를 필요로 하는지를 판단하기 위해서 사용될 수 있다. 새로운 소프트웨어 패치가 사용가능하면, 저장된 정보는 특별한 타겟 컴퓨터가 패치를 요구하는지를 판단하는데 사용될 수 있다.

타겟 컴퓨터는 운영체제 또는 설치된 소프트웨어에 관계없이, 서버 또는 워크스테이션의 임의의 유형을 포함할 수 있다. 더욱이, 본 발명의 범위는 무선 장치(이동 전화, 개인 휴대 단말기, 포켓 컴퓨터 등), 지능형 스위치 장치, 허브, 라우터, 및 임의의 다른 유형의 인터넷-부착 장치를 포함한 많은 다른 장치에 적용된다.

본 발명은 원격 네트워크상에서 기존의 소프트웨어를 업데이트하도록 하는 시스템, 방법, 제품 및 신호를 제공한다. 본 발명은 특히, 인간의 감시없이도 그리고 클라이언트가 업데이트되는 네트워크상의 관리 장치에서 소프트웨어 패치를 복사하지 않고도, 클라이언트-서버 시스템에서 소프트웨어 업데이트하는 것에 관한 것이다. 이 업데이트는 자동이며, 그것은 특정 업데이트내에서의 에러를 검출하며 네트워크를 사용가능한 상태로 하기 위해서 네트워크를 자동으로 롤백한다.

본원에서 논의되는 각 도면들은 본 발명의 여러 실시예들을 예시하지만, 주어진 도면에 대한 논의는 특정 유형의 실시예에 반드시 제한되는 것은 아니다. 예를들어, 당업자라면 본 발명의 방법들이 본 발명에 따른 구성된 저장 매체 및/또는 컴퓨터 시스템 실행에서 사용될 수도 있음을 알 수 있다. 불필요한 반복을 피하기 위해서, 방법들에 대한 논의는 달리 표시하지 않는 한 제품 및 시스템, 그리고 그 역으로 적용된다. 또한, 방법 단계들 또는 시스템 구성요소들은 다시 명명되거나, 다시 그룹화되거나, 또는 생략될 수 있으며, 방법 단계들은 적합하게 이해되는 청구범위가 특정 단계들 또는 구성요소들을 요청 및/또는 특정 실행 순서를 요구하지 않는 한, 상이하게 순서가 정해지고 중첩 실행으로 수행될 수 있음을 알 수 있다.

독자의 편의를 위해서, 네트워크 및 방화벽과 같은 관련 기술에 대한 일부 적절한 정보가 이하에 제공된다. 본 발명은 이미 공지된 기술보다 월등하지만, 부분적으로는 컴퓨팅 및 네트워킹에서 공지된 장점을 포함하거나 그에 의존하며, 그밖에도 그러한 공지된 장점과 함께 사용될 수 도 있다.

시스템 일반

도 1에 도시된 바와같이, 본 발명에 따라서 보안 컴퓨터 네트워크들(102, 104)와 같은 컴퓨터 네트워크(100)가 구성될 수 있다. 적합한 컴퓨터 네트워크들(100, 102, 104)는, 예로서, 로컬 네트워크들, 광역 네트워크들, 및/또는 인터넷의 부분들을 포함한다. 본원에 사용된 "인터넷"은 사설 인터넷, 보안 인터넷, 부가가치 네트워크, 가상 사설 네트워크, 또는 인트라넷과 같은 변형을 포함한다. 보안 네트워크들은 제한, 암호화, 가상 사설 네트워킹, 및/또는 다른 수단을 라우팅하는 방화벽 소프트웨어(116, 118)에 의해서 한정되는 보안 방어선으로 보안이 유지될 수 있다. 네트워크(100, 102, 104)는 또한 보안 인트라넷을 포함하거나 또는 보안 인트라넷으로 구성될 수 있는데, 이는 TCP/IP 및/또는 HTTP 프로토콜을 내부에 채용하는 근거리 네트워크와 같은 보안 네트워크이다. 본 발명에 따른 동작을 위해 네트워크에 의해서 접속되는 컴퓨터(110)는 워크스테이션(114), 랩톱 컴퓨터(112), 단속이 가능한 이동 컴퓨터(예를들면 PDA 또는 다른 무선 장치들), 서버, 컴퓨팅 클러스터, 메인프레임, 또는 이들의 조합이 될 수 있다. 컴퓨터 하드웨어는 범용, 특수 목적, 독립형, 및/또는 매립형이 될 수 있다. 네트워크(100)는 하나 이상의 LAN, 광역 네트워크, 무선 네트워크(적외선 네트워크를 포함), 인터넷 서버 및 클라이언트, 인트라넷 서버 및 클라이언트, 또는 이들의 조합과 같은 다른 네트워크를 포함할 수 있으며, 이들은 그 자체 방화벽에 의해서 보호될 수 있다.

주어진 네트워크(100)는 예를들면, Novell Network 네트워크 운영체제 소프트웨어(NETWARE 는 Novell사의 등록 상표이다), NetWare Connect Service, VINES, Windows NT, Windows 95, Windows 98, Windows 2000, Windows ME, Windows XP, Windows 2K3, LAN Manager 또는 LANtastic 네트워크 운영체제 소프트웨어, UNIX, TCP/IP, AppleTalk 및 NFS 기반 시스템, 분산 컴퓨팅 환경 소프트웨어, 및/또는 SAA 소프트웨어를 포함할 수 있다 (VINES는 Banyan Systems의 상표; NT, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS ME, WINDOWS XP 및 LAN MANAGER 는 마이크로소프트사의 상표이며; LANTASTIC는 Artisoft의 상표이며; SAA는 IBM의 상표이다). 네트워크는 게이트웨이 또는 유사한 메카니즘을 통해서 다른 네트워크들에 접속가능한 근거리 네트워크를 포함할 수 있다.

본 발명에 따른 하나의 시스템은 네트워크 신호선(108)에 의해서 하니 이상의 네트워크 클라이언트(110)로 접속되는 하나 이상의 서버(106)를 포함할 수 있다. 당업자라면 서버 및 네트워크 클라이언트를 본 발명에 따라서 동작하도록 매우 다양한 방법으로 구성할 수 있다. 서버는 인터넷 서버로서, 인트라넷 서버로서, 디렉토리 서비스 제공자 또는 이름 서버로서, 소프트웨어 구성요소 서버로서, 파일 서버로서, 또는 이들 및 다른 기능들의 조합으로서 구성될 수 있다. 서버는 단일 프로세서 또는 다중 프로세서 장치가 될 수 있다. 서버(106) 및 클라이언트(110)는 각각 랜덤 억세스 메모리와 같은 어드레스가능한 저장 매체, 및/또는 자기 또는 강 디스크와 같은 비휘발성 저장 매체를 포함한다. 신호선(108)은, 무선 접속을 포함하여, 당업자에게 공지된 꼬인 쌍, 동축, 또는 광 섬유 케이블, 전화선, 위성, 마이크로웨이브 릴레이, 변조 AC 전력선, 및 다른 데이터 전송 "와이어"를 포함할 수 있다. 본 발명에 따른 신호는 그러한 "와이어" 및/또는 어드레스가능한 저장 매체에서 실시될 수 있다.

네트워크 클라이언트 컴퓨터에 더해서, 프린터, 디스크 어레이 및 다른 주변기기들이 특정 시스템에 부착될 수 있다. 주어진 컴퓨터는 클라이언트(110) 및 서버(106)로서 기능을 수행할 수 있으며, 이는, 예를들어, 마이크로소프트 윈도우즈 NT 소프트웨어를 실행하는 컴퓨터에서 발생될 수 있다. 특정 개별 및 네트워크 컴퓨터 시스템 및 구성 요소들이 언급되지만, 당업자라면 본 발명이 다양한 다른 네트워크 및 컴퓨터로도 구현될 수 있음을 알 수 있다.

본 발명의 적합한 소프트웨어 및/또는 하드웨어 실행은 본원에서 제시되는 기술 및 프로그램 언어 및 Java, Pascal, C++, C, Perl, shell script, assembly, firmware, microcode, logic arrays, PALs, ASICs, PROMS와 같은 도구, 및/또는 다른 언어, 회로 또는 도구를 이용하여 당업자에 의해서 쉽게 제공된다.

구성된 미디어 일반

서버(106) 및 네트워크 클라이언트(110) 및 개별 컴퓨터(110, 114)는 플로피 드라이브, 테이프 드라이브, 광 드라이브 또는 저장 매체를 읽기 위한 다른 수단을 이용할 수 있다. 적합한 저장 매체는 자기, 광학, 또는 다른 컴퓨터로 판독가능한 저장 장치를 포함한다. 적당한 저장 장치는 플로피 디스크, 하드 드라이브, 테이프, CD-ROMs, PROMs, RAM 및 다른 컴퓨터 시스템 저장 장치를 포함한다. 기판 구성은, 컴퓨터 시스템이 본원에 기술된 바와같이 특정한 그리고 미리 규정된 방식으로 동작하도록 하는 데이터 및 명령을 표시한다. 따라서, 이 매체는, 본원에 대체로 기술된 본 발명의 업데이팅, 모니터링, 관리 및/또는 다른 단계를 수행하도록 서버 및/또는 네트워크 클라이언트 컴퓨터 및/또는 개별 컴퓨터에 의해서 실행가능한 프로그램, 기능 및/또는 명령을 유형으로 구현한다.

방화벽

네트워크 관리자는 일반적으로 임의의 정보가 그들의 시스템으로 유입되는 것을 허용하지 않는다. 오히려, 관리자는 네트워크를 보호하기 위해서 방화벽(116, 118)을 사용한다. 방화벽은 (때때로 컨텐트, 오리진 또는 요청 특성에 따라서) 유입되는 메시지를 차단하며 안전하다고 간주되는 것들 만을 통과하도록 하는 하드웨어 및/또는 소프트웨어 장치이다. 세가지 주요 유형의 방화벽은 스크리닝 라우터(패킷 필터라고도 함), 프록시 서버 회로-레벨 게이트웨이, 및 프록시 서버 어플리케이션-레벨 게이트웨이이다. 스크리닝 라우터는 도메인 이름 및 IP 어드레스와 같은 네트워크 패킷에 대한 외부 정보에서의 결정에 기초할 수 있어서, 허용가능한 도메인 이름 및 IP 어드레스로 부터 나오는 메시지가 120 및 124를 통해서 허용될 수 있는 한편 다른 장소(122)로 부터의 메시지를 거부한다. 프록시 서버 회로-레벨 게이트웨이는 정보를 외부 시스템에 보낼 때 내부 시스템에 대한 정보를 가장한다. 내부 컴퓨터의 IP 어드레스는 전형적으로 프록시의 IP 어드레스와 교체된다. 이 레벨에서, 인증이 요구될 수 있다. 프록시 서버 어플리케이션-레벨 게이트웨이는 스크리닝 라우터 및 회로 레벨 게이트웨이의 모든 특성을 제공하는 한편 패킷 자신의 콘텐츠가 평가되도록 한다. 메시지들은 보안 위배는 물론이고 콘텐츠에 대해서도 거부될 수 있다.

소프트웨어 설치

시스템 관리자들은 때때로 특정 장치에서 소프트웨어를 변경할 필요가 있다. 소프트웨어의 새로운 요소가 처음으로 설치되어야 하는데, 새로운 어플리케이션이 장치에 첨가될 때와 같이 설치되어야 한다. 이미 설치된 소프트웨어의 요소는 업데이트될 수 있는데, 마치 소프트웨어의 기존 요소의 새로운 버젼이 특정 장치에 설치될 때와 같이 업데이트될 수 있으며, 이는 소프트웨어 "교체(replacing)"라고 한다. 소프트웨어의 기존 요소의 데이터 파일은 소프트웨어 구성을 변경시키지 않고도 업데이트될 수 있는데, 이는 세금 목록이 회계 프로그램에서 업데이트되거나, 바이러스 방지 프로그램이 업데이트되는 것과 같이 업데이트될 수 있다. 특정 기계 또는 기계들의 상태에 대한 이러한 변경중 하나 또는 전부는 본 발명에서는 "설치(installation)"라고 한다. 유사하게, "패키지", "패치" 및 "업데이트"라는 말은 가능한 가장 넓은 의미로 주어진다. 예를들어, 패키지는 필요한 모든 파일들을 포함하는 전체 프로그램, 하나 이상의 데이터 파일들, 기존 파일에 대한 소프트웨어 패치, 구성 파일에 대한 변경, *.dll 파일, 컴퓨터 및/또는 컴퓨터 네트워크에 부착되는 하드웨어의 특정 요소에 대한 드라이버 파일 등을 일컬을 수 있다. "업데이트"는 최소한 컴퓨터에 하나의 패킷을 설치하기 위한 시도를 일컷는다.

방법 일반

도 3 및 4를 참조하면, 본 발명에 따라 동작하는 방법의 일 실시예는 프리-업데이트 상태에서 타겟 컴퓨터(500)를 포함한다. 이 타겟 컴퓨터(500)는 본 발명이 최소한 업데이트하기 위해 시도하는 컴퓨터이며, 본 발명의 모든 실시예가 업데이트가 성공적이 되도록 요구하는 것은 아니다. 업데이트 서버(528)는 네트워크(524)에서 타겟 컴퓨터에 접속된다. 일부 실행예에서는, 타겟 컴퓨터는 윈속 층(winsock layer)을 통한 접속부와 같은, 네트워크 접속부를 갖는다. 전형적으로, 타겟 컴퓨터는 전술된 바와같이, 방화벽(526)에 의해서 보호되지만, 업데이트 서버는 타겟 컴퓨터에 억세스하기 위해서 방화벽을 뚫을 수 있다.

현존하는 많은 기업 소프트웨어 관리 도구들은 에이전트를 사용한다. 그 예에는 Microsoft SMS 소프트웨어, Microsoft Active Directory 소프트웨어, IBM Tivoli 제품, Symantic 바이러스 방지 소프트웨어, McAfee 바이러스 방지 소프트웨어, 및 Novell ZENworks 소프트웨어 (그 각각의 소유주의 마크)가 있다. 대규모 네트워크에서, 에이전트는 정보를 알리고자 할 때 병렬로 웨이크 업하거나 리포트한다. 반면에, 에이전트가 부족한 툴은 원격 API 호출에 의존하는데, 이는 서버에 의해서 연속해서 폴(poll)되어, 바람직한 실시예에서 볼 수 있드시 병렬 처리가 아닌 선형으로 스케일되어 수행되도록 한다.

본 발명의 실시예에서 에이전트는 네트워크 대역폭을 유지하기 위해서 압축된 파일을 수신할 수 있다. 압축은 보안을 향상시키기도 하는데, 압축해제 에러가 패치가 수정되었음을 표시하기 때문이다.

또한, 본 발명의 에이전트는, 에이전트가 부족한 패치 관리 툴과는 달리, 에이전트를 베어링하는 이동 타겟이 또다른 장소에서 네트워크에 단선되고나서 재접속될 때 다운로드를 다시할 수 있으며, 따라서 인터럽트되기 전에 전체 서비스 팩 또는 파일을 다운로드할 수 있다. 에이전트가 부족한 툴은 또한 패치가 채용될 때 대역폭 활용에서 제어되지 않은 스파이크를 생성할 수 있는 반면에, 본 발명의 일부 실시예는 관리자에 의해서 업데이트 서버가 제어되도록 하여 서버는 에이전트 접속부(대역폭 드로틀링)를 통해서 특정량의 대역폭 만을 사용하게 된다.

영구 LAN/도메인 접속부에 의존하며 클리이언트 에이전트가 부족한 종래의 패치 툴은, 원격 등록 서비스에 의존할 수도 있는데, 이 서비스는 원격 컴퓨터에 등록 정보를 제공한다. 원격 등록 서비스는 Windows 95, Windows 98, 또는 Windows ME 플랫폼에서는 사용할 수 없다. 그러한 서비스는 클라이언트 컴퓨터가 인터넷상에 놓이는 조직에서 보안 리스크가 있는데, 이들이 원격 컴퓨터가 클라이언트의 등록을 판독하도록 허용하여, 클라이언트의 보안에 침투하거나 다른 공격을 가하는데 사용될 수 있는 정보를 제공하기 때문이다. 본 발명의 실시예는 바람직하게는 보안 리스크 때문에 원격 등록 서비스를 이용하는 것은 회피한다.

업데이트 에이전트(508)는 업데이트되어야 하는 각 컴퓨터에 배치된다. 이 업데이트 에이전트는, 워크스테이션(들) 및/또는 서버(들)과 같은 네트워크 타겟 장치에서, 종래의 방식으로 또는 본 발명을 이용하여, 초기에 설치될 수 있는 소프트웨어 구성요소이다 (보통은 대규모가 아님). 이 업데이트 에이전트는, 인간 관리자가 실제로 장치에 존재했다면 수행될 수 있었던 것과 유사한 방식으로 작업을 수행하기 위해서, 인간 관리자의 지도하에, 인간 관리자의 장소에서 동작할 수 있다. 이 업데이트 에이전트는 네가지 기본 태스크를 수행하는 방법을 알고 있는데, 1) 태스크의 리스트를 검색하기 위해서 업데이트 서버(528)에 접촉하는 방법, 2) 수신된 태스크 리스트에서 태스크를 시작하는 방법, 3) 동작 시간을 위한 정책 정보 등을 처리하는 방법, 및 4) 업데이트 서버로 등록하는 방법이다.

이 업데이트 에이전트는 초기 설치후에 수동으로 조정할 필요없이, 업데이트, 구성 또는 자체적인 교체가 가능하다. 전형적으로 작은 부트-트랩 에이전트가 초기에 설치되지만, 관리자가 명령하거나 또는 관리자 요청을 수행하도록 요구될 때 기능이 늘어나게 된다. 온사이트 관리자 컴퓨터, 서버 컴퓨터, 및 클라이언트 장치와 같은, 여러 종류의 타겟 컴퓨터(500)의 업데이트 에이전트는 단일 에이전트의 동일 버전으로서 모두 시작할 수 있다. 주어진 네트워크의 장치는 모두 설치된 동일 에이전트를 갖을 수 있거나 또는 장치는 설치된 고유의 에이전트들을 갖을 수 있다. 하나 이상의 클라이언트가 존재할 때, 각각은 초기에 상이한 업데이트 에이전트를 갖을 수 있거나, 또는 관리자에 의해서 선택될 때와 같이, 또는 디폴트로서 설정될 때와 같이, 상이한 클라이언트 장치상에 설치될 수 있다. 유사하게, 다중 서버 및 관리자는 또한 초기에 설치된 다양한 에이전트들의 결합을 갖을 수 있다. 개별 타겟 컴퓨터에 대한 에이전트가 변경함에 따라서, 이들은 모두 일제히 변경될 수 있거나 갈라질 수 있다. 일부 실시예에서, 에이전트는 모두 달라지기 시작해서 기능성에서 집중될 수도 있다.

업데이트 서버(528)의 오프사이트 장소는 타겟 컴퓨터와는 다른 장소이다. 이 장소는 완전히 다른 공급자에서 떨어져 있거나, 또는 타겟 컴퓨터(500)와는 다른 물리적인 장소이지만, 동일한 물리적인 장소에서, 동일 엔티티에 의해서 관리되는 장소에서 떨어져 있다. 그것은 서브콘트랙터 장소에서와 같은 타겟 컴퓨터(500)로 부터 다르게 나타나는 장소, 또는 일부 별개로 나타나는 장소에 놓일 수 있다. 중요한 점은 개별 타겟 컴퓨터 운영체제에 관한 한, 작업이 오프사이트가 되어 나타나는 것이다. 하나의 실시예는 업데이트 서버를 타겟 컴퓨터(500)에 배치하지만 오프사이트에 나타나는 방식(다른 구획에서와 같이)으로 배치된다.

타겟 컴퓨터에 설치되어야 하는 실제 업데이트 자료는 때로는 업데이트 서버 및 타겟 컴퓨터로부터 떨어진 별개의 장소(패키지 컴퓨터로 공지됨)에 저장된다. 소프트웨어 업데이트 자체는, 증가형 소프트웨어 패치, 이전에는 타겟 컴퓨터에 설치되지 않은 새로운 소프트웨어 프로그램, 구 프로그램에 대한 업데이트, 소프트웨어 스크립트, 데이터 파일 또는 업데이트 에이전트의 업데이트와 같은, 네트워크에서 업데이트될 수 있는 매우 다양한 소프트웨어중 어떤 것이 될 수 있다.

공지된 상태에 직면하면, 배치 단계(300) 동안에, 태스크 id가 업데이트 태스크 리스트(222)에 놓인다. 공지된 상태는 패치가 현재 컴퓨터상에 있지 않거나, 관리지가 찬성하거나, 타겟 컴퓨터(500)의 소유주가 패키지의 소유주로 부터 허락을 받거나, 아무도 특별히 프리빌리지를 배치하는 것을 부인하지 않는 것이거나, 또는 일부 다른 공지된 또는 본 발명의 상태가 될 수 있다. 업데이트 서버상에 위치한 업데이트 태스크 리스트는 특정 타겟 컴퓨터(500)와 연관되며, 소프트웨어 업데이트를 발견할 수 있는 적어도 하나의 다운로드 어드레스를 규정한다. 다운로드 어드레스는 컴퓨터가 이해할 수 있는 임의의 포멧이 될 수 있다. 본 발명은 임의의 특정 어드레싱 컨벤션에 의존하지는 않는다. 현재 사용되는 두개의 일반 어드레싱 포맷들은 "유니버설 리소스 로케이터" 및 "완전히 적격 도메인 이름" 포멧이다. 다른 포멧들은 PURLs(Persistent Uniform Resource Locator) 및 URN's(Uniform Resource Names)이며, 다른 네이밍 방식은 장차 알려질 것이다. 날짜와 같은 태스크 식별자에 포함될 수 있는 다른 정보가 먼저 시도될 수 있다. 각각 소프트웨어 업데이트가 발견될 수 있는 장소를 규정하는, 다중 다운로드 어드레스는 모두 특정 소프트웨어 업데이트와 연관될 수 있다.

시작 태스크 단계(304) 동안에, 소프트웨어 업데이트는 적어도 패키지 컴퓨터(306)로 부터 업데이트 서버(528)로 업로드되고자 시도될 수 있다. 옵션 선택된 패키지 컴퓨터 단계(306) 동안에, 하나 이상의 다운로드 장소가 태스크 id 리스트(226)에 배치되면, 소프트웨어 업데이트가 다운로드되는 장소가 선택된다. 리스트상에서 첫번째 장소를 이용하며, 검사 메시지가 가장 빨리 리턴되는 장소를 이용하며, 첫번째 사용가능한 장치를 이용하는 등과 같이, 공지된 또는 본 발명의 방법에 의해서 선택이 내려질 수 있다.

업데이트에 대한 장소가 공지되면, 소프트웨어 다운로드는 패키지 컴퓨터(548)의 장소로 부터 업데이트 서버(528)의 메모리(530)로 시도된다. 다운로드가 성공하지 못하면, 본 발명의 한가지 방법에서 태스크 업데이트 리스트내의 가능한 장소의 리스트로부터 또 다른 장소가 선택되며, 소프트웨어 업데이트의 다운로드가 재시도된다. 일부 실행예에서, 다운로드가 어떤 이유로 완수될 수 없으면, 업데이트 서버(528)는 일정 시간 대기하며 패키지 컴퓨터(567)로부터 다운로드하기를 다시 시도한다. 다운로드가 성공하면, 업데이트 서버(528)는 타겟 컴퓨터(500)로 소프트웨어 업데이트를 다운로드(312)하고자 시도한다.

다운로드가 업데이트 컴퓨터내의 캐시 또는 다른 메모리에 있으면, 제 2 다운로드(312)는 업데이트 서버로부터 타겟 컴퓨터로 소프트웨어 패키지를 다운로드하고자 시도된다. 본 방법의 일부 실시예에서는, 제 2 다운로드(312)는 일부 선정된 기준에 의해서 지연된다(310). 이러한 지연은 제 1 다운로드의 시작으로부터 되어, 지연 기간은 패키지 컴퓨터로 부터 업데이트 서버로 소프트웨어 업데이트를 다운로드하는데 필요한 시간의 측정에 기초하여 있다. 제 2 다운로드는 또한, 하루의 비지니스가 끝난 후와 같이, 타겟 컴퓨터(500)가 사용되는 기회가 적을 때 하루중 특정한 시간으로 지연될 수 있다.

모니터(302)는 설치를 체크하여, 설치(314)의 결과를 판단하기 위해서, 전형적으로는 관리자가 하는 역할을 수행한다. 그 결과가 공지되면, 관리자는 이를 통지받는다(328). 통지는, 이메일(330)을 보내거나, 누군가에게 페이징하거나, 기존에 녹음된 전화 메시지를 보내거나, 또는 다른 공지된 또는 본 발명의 방법 및 수단에 의해서 이루어질 수 있다.

모니터링 단계가 실패를 검출하면(316), 실패한 태스크는 중단된다(318). 업데이트 서버(528)에 대한 제 1 다운로드(308)가 실패할 수 있는데, 이는 제 2 다운로드가 업데이트 서버(528)로 부터 타겟 컴퓨터(500)로 이루어질 때와 같다. 소프트웨어 업데이트를 설치하는 다중 타겟 컴퓨터가 있으면, N번째 설치가 실패하는 식이다. 결정 결과가 바람직하게는 소프트웨어 업데이트가 나타나서 적당히 설치되는 것을 단순히 보장하는 것을 초과하며, 본 발명의 일부 실시예에서는 설치를 넘어서 시간을 연장한다. 예를들어, 모니터의 일례는 단지 하나의 타겟 컴퓨터에 설치되게 함으로서 패치 어플리케이션을 검사하며, 이는 적당히 다운로드하며, 설치하며, 이어서 시간 지연을 설정하는 관리자가 패치에서 충분한 확신을 획득하여 다른 타겟 컴퓨터로 적용되도록 할 때 까지 어떤 시간 간격 동안 관찰하도록 한다. 이러한 패치의 어플리케이션이 소프트웨어가, 수정된 프로그램 또는 컴퓨터내의 다른 곳에서, 바람직하지 않은 동작에 의해서 알게될 때, 비정상 활동을 야기시키면, 문제가 해결될 때 까지 롤아웃이 자동으로 정지될 수 있다.

더욱이, 실패가 검출되는 얼마의 경우에 소프트웨어 업데이트는 디스에이블되거나 타겟 컴퓨터로 부터 제거되며(324), 그 장치는 대체로 사전 업데이트 상태 또는 또 다른 수용가능한(동작) 넌-업데이트 상태로 리턴된다. 이것은 설치된 소프트웨어가 타겟 장치(322)로 부터 떨어지거나, 또는 소프트웨어가 제거되며 모든 부수적인 파일들(.dll's, .exe's 등)이 그들의 사전 업데이트 상태로 복구되는 것을 의미한다. 다른 경우에는 타겟 컴퓨터 또는 그중 어떤 부분이 소프트웨어 업데이트가 설치되기 전에 백업되었으며, 백업 자체가 장치로 복구됨을 의미한다.

다중 타겟 컴퓨터(500)이 있으면, 실패는 소프트웨어가 하나 이상의 장치에 설치된 후에 모니터에 의해서 검출될 수 있다. 이 경우에, 소프트웨어 업데이트는 실패가 스폿된 타겟 컴퓨터(500)로 부터만 제거될 수 있지만(322), 그것은 또한 소프트웨어가 이미 설치된(326) 다른 타겟 컴퓨터(500) 모두로 부터 제거될 수 있다(326). 제거 요청은 관리자로 부터 올 수 있거나 또는 제거는 실패가 검출되고나서(326) 자동으로 수행될 수 있다.

모니터(302)는 소프트웨어 패키지가 성공적으로 설치되었는지를 듣기 위해 단순히 대기하는 것 이상의 태스크를 수행할 수 있다. 예를들어, 어떤 경우에 모니터는 설치 후에 시간 주기(400)동안 대기하며 만일 달리 듣지 않았으면 설치가 성공했다고 가정한다.

관리자 및 관리자 헬퍼는 이들이 진입하여 헬프를 위한 요청에 대한 정보를 거색하는 중앙 저장소로 부터 상당히 도움을 받을 수 있다. 이러한 하나의 방법은 헬프 데스크 "티케팅"이다. 티케팅은 리퀘스터, 리퀘스트의 유형, 헬프가 리퀘스트된 때, 리퀘스트에 대한 응답이 완성된 때, 및 다른 유용한 정보를 기록한다. PatchLink HelpDesk 서비스는, 하나의 중앙 저장소를 통해서, 사람 및 컴퓨터 자원인, 그 네트워크 리퀘스트 및 네트워크 자원을 관리하기 위해 관리자에게 편리를 제공한다. PatchLink HelpDesk 소프트웨어는, 관리, 백업, 및 업데이트되어야 하는 또 다른 자원을 도입하는 관리자의 네트워크상에 침해 어플리케이션 설치를 하지 않고도 인터넷상에서 이러한 편리를 제공한다- 이는 오프사이트 관리 센터에서 투명하게 관리된다.

표준 웹 브라우저 또는 일부 다른 공지된 또는 본 발명의 네트워크 접속부에 의해서 접속가능한 웹사이트는 헬프 데스크 서비스를 사용하기 위한 편의를 제공한다. 바람직한 실행예는 현재 www.patchlink.com. 에서 접속가능한, PatchLink 웹 사이트에 있다. 간단한 웹 형태는 인롤먼트 프로세스를 시작하는데 요구되는 데이터 집합을 지원한다. 인롤먼트 프로세스가 완성되면, 관리자는 순환 치환으로 하나 이상의 서비스를 라이센스할 수 있다.

인롤먼트 프로세스는 관리자가 사인 업하고 소정의 참가 레벨을 표시함으로서 프로세스를 개시할 때 시작된다. 본 발명의 바람직한 실시예는 세개의 상이한 사용자 레벨을 갖는데, 게스트, 레귤러, 및 이그제큐티브이다. 게스트는 웹 사이트를 보여주도록 허용되며 사용자 포럼을 읽을 수 있지만 포럼으로 포스트할 수 없다. 레귤러 멤버는 게스트 기능을 수행할 수 있으며 또한 채트 룸에서 채팅할 수 있으며 포럼으로 포스트할 수 있다. 이그제큐티브 멤버는 사이트에 대한 섭스크립션을 갖는다. 사용자는 레귤러 멤버 기능을 수행할 수 있으며, 또한 오프사이트 자동 패키지 업데이트(예를들면, PatchLink Update service), 오프사이트 모니터링 (예를들면, PatchLink Monitor service), 및 오프사이트 헬프 데스크 기능(예를들면, PatchLink HelpDesk service)와 같은 더 진보된 사이트의 특징을 사용할 수 있다.

본 발명의 일 실시예는 커스토머의 전화 영역 코드에 할당된 커스토머 케어 에이전트에 전달되는 이메일을 수반한다. 커스토머 케어 에이전트는 인롤먼트 프로세스를 완성하기 위해서 계류중인 사용자에게 전화한다. 커스토머 케어 에이전트는 필요한 식별 정보 및 지불 정보를 수집하여, 계정의 사용을 허용하도록 계류중인 사용자의 계정을 업그레이드하므로, 계류중인 사용자를 관리자/사용자가 되게 한다. 관리자/사용자가 참여할 수 있거나 사용할 수 있는 영역은 업그레이드 호스트의 데이터베이스의 라이센스된 제품의 테이블내의 엔트리에 의해서 제어된다. 이러한 엔트리는 인롤먼트 프로세스 동안에 커스토머 케어에 의해서 생성된다.

이 모든 서비스들은 인터넷상에서 브라우저 또는 다른 네트워크 접속부를 통해 관리자에게 사용될 수 있음을 상기해 볼 수 있다. 모니터가 티켓을 헬프 데스크에 입력키고 본 발명의 방법의 일부 사례화에서 롤아웃을 개시할 때, 모니터는 실패가 발생했는지 여부를 결정한다(316,406). 결정을 위해서 모니터는 어떤 소프트웨어 업데이트가 최근에 설치되었는지, 설치된 것이 얼마나 되었는지, 현재 하드웨어 및 소프트웨어 구성 등을 볼 수 있다. 어떤 인시던트가 실패로 고려되는지는 제한없이, 관리자에 의해서 설정될 수 있으며, 디폴트가 사용될 수 있으며, 핼프 데스크 퍼스넬의 판단이 고려될 수 있다.

검출 성공 단계(408)에서 타겟 컴퓨터(500)는 업데이트 서버로 부터 타겟 컴퓨터로의 다운로드가 성공적으로 완료된 후에 업데이트 서버에 메시지(410)를 전달한다. 모니터는 실패를 통보하거나 통보받지 않고 특정 시간 주기가 지났으면 성공이라고 추정할 수 있다(404).

실패는 다른 방법으로 검출될 수 있다(316, 406). 예를들면 타겟 컴퓨터는 실패가 발생했음을 모니터네 통보할 수 있으며; 사용자는 헬프 데스크 또는 직접 링크를 통해서 모니터에 실패가 발생했음을 통보할 수 있으며; 제 2 다운로드(312)의 시작으로부터 타겟 장치로 특정 시간내에 타겟 컴퓨터가 모니터에 접촉하지 않을 때 인간 관리자는 실패가 발생했음을 선언할 수 있는 등의 방식이다. 모니터가 성공하게 되는 다운로드의 출력을 선언한 후에도, 헬프 데스크로 부터의 실패 표시와 같은, 나중 이벤트는 모니터가 실패된다고 선언하게 할 수 있다.

본 발명의 일 실시예에서, 업데이트 서버(528)는, 다음 타겟 컴퓨터(500)가 그 업데이트 리스트(222)에 배치되는 소프트웨어 업데이트를 갖기 전에 (모니터에 의해서 또는 또 다른 공지 또는 본 발명의 제어 방법에 의해서) 성공적인 설치의 확인을 대기한다. 업데이트 서버는 소프트웨어 업데이트에 대해서 자격이 있지만 그것을 아직 수신하지 않은(412) 타겟 컴퓨터(500)를 체크한다. 그중 하나가 발견되면(414), 타겟 장치를 규정하는 적당한 태스크 식별자, 소프트웨어 업데이트 및 장소가 업데이트 서버(512)의 태스크 업데이트 리스트에 가산된다(416). 모든 자격있는 컴퓨터가 모두 함께 이들에 설치된 소프트웨어를 갖는 매스 업데이트보다는 이러한 방법으로, 롤아웃이, 디폴트 또는 사용자 규정된 수의 성공적인 설치후에, 롤아웃이 성공으로 간주될 때 까지 한번에 하나의 컴퓨터를 프로시드(proceed)하며; 그 접합점에서 소프트웨어 업데이트는 한번에 하나 이상의 타겟 컴퓨터로 사용가능하게 된다.

특정 타겟 컴퓨터(500)를 바라봄으로서 어떤 소프트웨어 패키지 및 패치가 설치되었는지가 항상 명확한 것은 아니다. 본 발명은, 본 발명이 그 패치를 설치하고자 시도하기 전에 주어진 패치가 컴퓨터(500)상에 아직 설치되지 않았음을 보장하도록 타겟 컴퓨터(500)를 분석하는 방법을 포함한다. 다음 설명은 도 8 및 9를 참조하며 연속해서 도 5를 참조한다.

특정 소프트웨어 업데이트를 정의하는 패치 지문이 더 상세히 기술된다. 패치 지문은 새로운 패치 지문(902)에 대한 패치 구성요소 데이터베이스 장소(900)를 모니터링하므로서 배치된다(800). 여기서 "새로운"이라는 말은 패치가 저장소 구성요소(600)로 다운로드되지 않았음을 표시하거나, 또는 이미 다운로드되었다 할지라도, 어떤 이유로 저장소 구성요소로 다시 다운로드될 필요를 표시한다. 하나 또는 다수의 패치 구성요소 장소가 있을 수 있으며; 그 장소는, 네트워크 링크를 통해서 시스템에 접속되는 별개의 컴퓨터상에, 또는 업데이트 서버(528)상에, 또는 타겟 컴퓨터(599)상에, 또는 패키지 컴퓨터(567)상에, 또는 CD, 테이프, 플로피 디스크 등과 같은 넌-네트워크된 장소 상에, 또는 일부 다른 공지된 또는 본 발명의 장소상에 놓일 수 있다.

패치 지문(906)이 장치되면(800), 그것은 저장소 구성요소(600)로 배치된다(802). 일반 배치 방법은 패치 지문(906)을 저장소 구성요소로 다운로드(804)하는 것이지만, 일부 실시예에서 지문(906)은 동일 파일 시스템에 놓여서, 파티션들 사이의 복사와 같은 네트워크를 이용하지 않고도 복사될 것이다.

예시된 패치 지문은, 특정 패치가 장치에 설치될 수 있는지를 보기 위해서 높은 레벨의 보기가 사용될 수 있는 하나 이상의 일반적인 발명의 설치 의존성(912)을 포함할 수 있다. 그것은 또한 타겟 컴퓨터(500)로 부터 특정 정보를 요청하는데 사용될 수 있는 서명 블록(910), 및 특정 패치가 장치에 로드되었는지를 판단하기 위해 서명 블록 정보를 사용할 수 있는 존재 검사(908)를 포함한다.

본 발명의 어떤 버젼에서, 발명의 설치 의존성(912)은 타겟 컴퓨터(500)에 설치되어야 하는 필요한 소프트웨어 및 하드웨어의 적어도 일부를 설명한다. 이러한 의존성(912)은 목록 라이브러리(918)에 이미 저장된 타겟 컴퓨터(806)에 대한 정보와 비교된다(808). 만약 설치 정보 및 발명 정보가 매치되지 않으면, 피치는 설치되지 않는다. 본 발명의 일부 버전에서 메시지는 설치를 위해 요구되는(필요한 하드웨어 및 소프트웨어와 같은) 구성요소의 리스트를 포함하는 적어도 하나의 관리자에 전달된다.

필요한 발명의 정보가 타겟 컴퓨터(500)이거나 또는 발명 정보가 사용되지 않으면, 서명 블록이 저장소 컴퓨터(600)로 부터 타겟 컴퓨터(500)로 전달된다(810). 더 많은 특정 설치 정보로 이루어질 수 있는, 서명 블록(914)에서 요청되는 정보는 발견 에이전트(548)에 의해서 모아지고(812), 이어서 저장소 구성요소(818)로 되돌려진다. 본 발명의 일부 버전에서, 발견 에이전트는 또한 사용 통계, 설치된 하드웨어 및 소프트웨어, 구성 등과 같은 타겟 컴퓨터에 대한 다른 정보(816)를 모은다. 이 정보는 목록 라이브러리(918)를 점유하는데 사용될 수 있다.

서명 정보(910)가 저장소 구성요소(600)로 전달되었으면, 평가기(914)는 존재 검사(908)를 통해서 서명 블록에 의해서 요청되는 특정 설치 정보의 적어도 일부, 및 어떤 경우에는 발명의 설치 정보(912)를 평가하여, 패치가 타겟 컴퓨터(500)에 부재인지(822)를 판단한다.

옵션 단계로서, 패치가 부재인지가 판단되었으면, 메시지는 관리자와 연관된 적어도 하나의 어드레스에 전달된다(824). 이 메시지는 이메일, 페이저, 팩스, 음성메일, 즉석 메시징, SNMP 통보 등을 포함하여 다양한 방법을 사용하여 전달될 수 있다.

패치 지문

도 5, 8 및 9를 계속해서 참조하면, 본 시스템의 일 실시예는 설치하고자 시도하기 전에 소프트웨어 패키지가 주어진 타겟 컴퓨터(500)에 설치될 수 있거나 설치되어야 함을 확인한다. 그렇게 하기 위해서, 패치 지문(906)이 사용되는데, 예를들면, 클라이언트 상의 에이전트에 의해서 사용된다. 패치 지문은 주어진 소프트웨어 패키기/증가 패치가 이미 설치되었는지 여부를 판단하는 방법을 규정한다. 또한 패치 설치에 필요한 최소의 하드웨어/소프트웨어 구성을 규정할 수 있다. 이러한 패치 지문(906)은 지문 라이브러리(904)에 저장된다. 지문 라이브러리(904)는 저장소 구성요소(600)에 배치된다. 이러한 저장소 구성요소(600)는 업데이트 서버(528)에 배치될 수 있거나, 또는 업데이트 서버(528) 및 타겟 컴퓨터(500)에 억세스가능한 별도의 장소에 놓일 수 있다. 본 발명의 일부 버젼은 또한 타겟 목록를 포함하는 목록 라이브러리(918)를 포함한다. 각각의 타겟 목록(920)은 규정된 세트의 타겟 컴퓨터(500)에 대한 하드웨어 및 소프트웨어 정보를 포함한다. 이처럼 규정된 세트는 주어진 네트워크에서 단지 하나의 컴퓨터 또는 모든 컴퓨터를 포함하거나 또는, 그들 사이의 수의 컴퓨터를 갖는다.

지문 라이브러리(904)는 자동으로 공급될 수 있다. 어떤 실시예에서는, 적어도 하나, 그러나 가능하게는 여러개의 패치 구성요소 데이터베이스 장소(900)가 새로운 패치(902)에 대해서 모니터된다(800). 본 발명의 어떤 실시예에서는, 장소(900)로부터의 신호는 저장소 구성요소(600)에 새로운 패치(902)가 사용됨을 표시한다 (800). 바람직한 실시예에서, 지문 라이브러리(904)는 특정한 시간 간격으로 새로운 패치 지문이 업데이트된다. 저장소 구성요소(600)이 새로운 패치 지문을 알고난 후에, 패치 지문은 저장소 구성요소(802)에 배치되며, 보통은 새로운 패치 지문을 다운로드하기 위한 다운로더(924)를 이용함으로서 배치된다. 그러나, 패치 지문은 다른 방법으로 저장소 구성요소로 진입할 수 있다. 예를들어, 하나 이상의 패치 지문은 관리자에 의해서 지문 라이브러리로 수동으로 설치될 수 있다.

목록 라이브러리

저장소 구성요소(600)는 또한 목록 라이브러리(918)을 포함한다. 어떤 실시예에서 초기에 업데이트 서버(528)에 상주하는 발견 에이전트(600)는 공지된 또는 본 발명의 방법을 이용하여 업데이트 서버(528)로 부터 타겟 컴퓨터(500)로 설치된다. 후에 더 상세히 설명되는 이 발견 에이전트(548)는 타겟 컴퓨터(500)의 소프트웨어 정보(606), 설치된 특정 소프트웨어 업데이트 및 패치를 포함하는 하드웨어 정보(608), 사용 정보(604), 등록 정보(612), 웹 정보(610), 구성 정보(614), 서버들(618), 파일 정보, 사용되어 온 패치 서명 등의 적어도 일부를 목록화한다.

이러한 정보, 또는 그 서브세트 또는 수퍼세트는 일부 실시에서는 압축된 형태로, 목록 라이브러리(918)내의 타겟 컴퓨터 목록(920)으로 보내진다. 결과 정보는 매우 대량이 될 수 있으며 따라서 효율적인 업로드를 위해서 그리고 커스토머 네트워크상에서 대역폭 사용을 최소화하기 위해서 압축될 수 있다. 바람직한 실행예에서는 임의의 다른 공지된 또는 본 발명의 데이터 전달 방법이 사용될 수 있지만, XML 데이터 전달을 이용하여 데이터를 보낸다. 목록 정보의 전달은 시스템 구성 정보의 바라지 않는 와이어-레벨 스누핑을 방지하기 위해서 커스토머 네트워크내에서 암호화될 수 있다.

보고 발생기

이러한 정보로, 보고 발생기(922)가 사용자에게 패치를 필요로 하는 컴퓨터의 수를 나타내는 네트워크내의 모든 컴퓨터에 대한 현재 패치의 상세한 보고를 제공할 수 있으며, 이 컴퓨터는 이미 패치가 설치되어 있으며, 컴퓨터는 하드웨어 또는 소프트웨어가 업그레이드 되는 등이 될 때 까지 패치를 수신하지 못한다. 그에 더해서, 보고 발생기(922)는 네트워크에 부착된 컴퓨터의 부분적인 또는 완전한 목록을 제공할 수 있다. 일부 실시예에서 이 보고 발생기(922)는, 소프트웨어 라이센스 승락을 보장할 뿐 아니라 하드웨어의 위치를 트랙하기 위해서, 관리자에 의해서 분석하기위한 목록의 그래픽 제시를 제공한다. 그러나 목록 구성요소(600)는 또한, 패치 지문(906)으로 부터 발견 에이전트(548)까지 관련된 서명(910)을 분산시키기 위해서 검출된 지문 정보뿐 아니라 목록 라이브러리(918)를 이용하여, 타겟 컴퓨터(500)에서 불필요한 스캐닝 작업을 제거함으로서 패치 발견 프로세스를 상당히 최적화한다.

발견 에이전트

주어진 소프트웨어 프로그램 또는 패치가 설치되는지 여부를 결정하기 위한 하나의 옵션 단계는 필요한 하드웨어가 적용가능하다면 존재하는지 및/또는 필요한 소프트웨어가 존재하는지를 확인하는 것이다. 예를들어, 일부 프로그램들은 특정 운영체제를 요구할 수 있으며, 일부 프로그램은 어떤 프로세서를 요구할 수 있다. 한 예로서, Microsoft Word 소프트웨어의 업데이트가 설치되려면, Microsoft Word 소프트웨어가 장치에 놓이는 것이 필요하다. 이러한 높은 레벨의 의존성은 어떤 버전에서는 패치 지문내의 목록 설치 블록(912)에 저장된다. 목록 설치 블록내의 정보는 일반적으로, 목록 라이브러리(918)내에 저장된 특정 타겟 컴퓨터(500)의 타겟 목록(920)으로 부터 이끌려 나올 수 있을 정도의 충분히 높은 레벨이다.

본 발명의 일부 실행예에서, 패치 지문(906)은 또한 설치 의존성 정보(912)를 포함한다. 이는 전술된 바와같이, 목록 라이브러리에서 찾아 볼 수 있을 것으로 예상될 수 있는 타겟 컴퓨터(500)에 대한 정보이다. 이것은 (특정 버전의 프로그램, 패치, 데이터 파일 또는 드라이버와 같은) 반드시 존재해야 하는 소프트웨어, 또는 반드시 존재해야 하는 하드웨어 구성요소, 또는 반드시 존재하지 않아도 되는 특정 하드웨어 및/또는 소프트웨어를 포함한다.

목록 라이브러리가 타겟 컴퓨터(500)에 대한 현재 목록을 갖지 않으면, 발견 에이전트는 목록 정보에 대해서 타겟 컴퓨터(500)를 스캔하는데 사용될 수 있으며; 이는 서명 정보에 대해서 동시에 스캔하는데 반드시 필요하지는 않다. 바람직한 실시예에서, 발견 에이전트(548)가 주어진 타겟 컴퓨터에서 실행되는 제 1 시간에 목록 정보에 대해서만 스캔하여 그 정보를 목록 라이브러리(918)로 로드하며; 패치 지문 정보는 무시한다. 발견 에이전트(548)가 실행되는 다른 시간에는 목록 정보를 무시하고, 오히려 특정 패치의 존재를 검사하기 위해서 특정 서명 정보(910)를 참조하는데 사용될 수 있다. 서명 블록 정보가 찾아질 때, 등록 엔트리 및 INI 파일 값과 같은 값이 존재하는지 검사될 수 있지만, 실제 값은 목록 구성요소(600)로 리턴될 수 있다.

각각의 패치 지문은 서명 블록(910) 및 존재 검사(908)를 포함한다. 패치 서명 블록은 일련의 정보 요청이며, 정보 자체는 모든 필요한 버그 픽스 및 보안 패치가 설치되는지를 판단하는데 사용되는 타겟 컴퓨터(500)로 부터 모여진다. 패치 서명 블록 정보의 예는 파일, 하드웨어, 등록 및 구성 정보, 특정 파일 또는 목록 이름, 파일이 발견될 것으로 예상되는 경로의 전부 또는 일부, 파일의 특정 버전 수, 파일의 생성된 날짜, 파일의 특정 파일 버전, 및 특정 등록 값을 포함하되 이들에 제한되지는 않는다.

일 실시예에서 지문 라이브러리(904)는 SQL 데이터베이스이다. 패치 서명(910)은, SQL 지문 라이브러리로 부터 추출되어 목록 설치 정보(912)내에서 규정된 바와같은 운영체제 및 설치된 소프트웨어에 대한 의존성 기준에 맞는 모든 타겟 컴퓨터에 보내진다.

바람직한 실행예는 XML-기반 요청 입력 파일을 채용한다. 업데이트 서버(528)에 되돌려진 결과 파일은 또한 XML 포매팅을 채용한다. 이 결과 파일은 타겟 컴퓨터에 대한 서명 정보를 포함하며, 또한 소프트웨어 및 하드웨어 목록 업데이트를 포함할 수 있다. 업데이트 서버에 보내진 목록 및 서명 정보는 매우 커 질 수 있으며 따라서 압축되어 바람직한 실행예에서 암호화될 수 있다. 다음은 EXEs 날짜 및 시간은 물론이고 Microsoft Outlook 에 대한 등록 정보, 및 등록내의 정보를 모으는 단순한 패치 서명이다. 즉,

<file componentid="1" reportID="1">

<name>outlook.exe</name>

<path></path>

<version>9.0.2416</version>

<created></created>

<size></size>

<root>HKEY_LOCAL_MACHINE</root>

<Key>SOFTWARE＼Microsoft＼＼Windows＼CurrentVersion＼App

Paths＼OUTLOOK.EXE</key>

<value>Path</value>

</file>

타겟 컴퓨터상의 발견 에이전트가 서명에 대한 그 스캔 결과를 리턴했으면, 존재 검사(908)가, 특정 컴퓨터가 실제로 패치를 갖는지 여부를 추정하기 위해서 평가기(914)에 의해서 사용된다. 이 알고리즘은 평가기에 의해서 수행되어야 하는 검사의 수를 최소화하는데, 그 단독 책임은 정보를 발견하는 것으로서, 데이터 분석이 목록 구성요소(600) 자체에 의해서 수행되도록 한다. 이 방식으로 워크로드를 분산하는 것은 다수의 워크스테이션 및 서버를 스캐닝 및 분석하기 위한 더 양호한 실행예를 제공한다.

각각의 존재 검사는 주어진 패치에 대해서 특정한 것이다. 샘플 존재 검사는 다음과 같다. 즉, 등록 QQ가 값 ZFILEVAL을 포함하거나 또는 (file_Z123.bat이 2000년 12월 12일 오전 11시 52분에 변경되었으며 파일 Z의 크기가 ZFILESIZE이면) 패치 ZPATCH가 존재한다. 패치 지문 라이브러리의 바람직한 실시예는 SQL 데이터베이스이지만, 다른 공지된 또는 본 발명의 데이터베이스가 사용될 수 있다.

패치 지문이 지문 정의에 대한 의존성을 포함할 수 있음을 유의할 수 있는데, 예를들면, "MS-023 ⅡS Vulnerability Fix" 패치가 가설에 근거하여 "Microsoft Windows Service Pack 2"의 존재를 요구한다. 이는 패치 서명이 실제로 보내지는 곳을 더 최적화하는데 사용된다. 이들은 때때로 상황에 따라서 설치 의존성 정보(912)에서 사용되며, 또는 서명 블록(9100에서 사용될 수 있다.

이에 더해서, 지문 정의(906)는 또한 정상적으로는 시스템에 의한 전개에 적합한 소프트웨어 패키지(554)와 연관된다. 특정 패치에 대한 필요가 네트워크 내의 하나의 컴퓨터 또는 모든 컴퓨터에서 그 서명(들)을 스캐닝하므로서 설정되었으면, 날짜 및 시간을 단순히 선택함으로서 관리자에 의해서 신속히 전개될 수 있다.

지문 정의(906)는 또한 패치 서명내의 다른 요소들이 TRUE (패치된) 또는 FALSE(패치되지 않은)으로 평가되어야 하는지를 사정하도록 평가되어야 하는 논리적 표현을 포함할 수 있다. 그 표현은 A. B 및 C가 패치 서명내의 다른 지문 정의를 지칭하는 (A A 및 B)│C와 같은 단순한 논리적 문장이다.

일부 실행예에서 다운로더(924)는 규칙적으로 새로운 패치 지문에 대한 패치 구성요소 데이터베이스를 체크한다. 새로운 패치 지문이 배치되면, 그것은 저장소 구성요소로 다운로드 된다. 평가기는 설치 정보(912)에서 리스트된 특정 패치 실행예에 대해서 필요로 하는 의존성을 목록 라이브러리에서 리스트된 타겟 컴퓨터(500) 명세 각각과 비교한다. 그후 업데이트 리스트가 생성되는데 이는 패치를 필요로 하는 모든 타겟 컴퓨터(500), 패치를 소유하지 않는 모든 타겟 컴퓨터, 패치를 수신할 수 있는 모든 타겟 컴퓨터, 필요한 의존성이 있을 때, 이미 패치를 수신한 모든 타겟 컴퓨터(500)를 식별할 수 있다. 이러한 업데이트 리스트는 현재 타겟 컴퓨터를 업데이트하는데 사용될 수 있거나, 통보기(916)에 의해서 관리자에게 보내질 수 있다.

본 발명의 어떤 경우에는, 패치 구성요소 데이터베이스가 타겟 컴퓨터(500) 소유주가 아닌 다른 누군가에 의해서 소유된다. 이러한 패치 업데이트 호스트가 타겟 컴퓨터(500) 소유주에게 허용했을 때에만, 다운로더는 새로운 패치 지문을 저장소 구성요소로 다운로드하도록 허용된다. 이러한 허용은 구매 동의, 임대 동의, 다운로드 허용에 대한 가입, 및 평가 동의를 포함할 수 있다.

관리자의 관심사가 될 수 있는 임의의 수정이 이루어지면, 통보기(916)는 사용가능하게 된 새로운 패치 업데이트 또는 그 네트워크 구성에서 발생된 패치 관련 상태 변경을 포함하는 통보 메시지를 보낸다. 통보는 이메일, 페이저, 전화, SNMP 브로드케스트 또는 즉석 메시지를 통해서 보내진다.

타겟 컴퓨터

일 실시예에서, 본 발명의 시스템은 세개의 피스, 즉, 타겟 컴퓨터(500), 업데이트 서버(528), 및 패키지 컴퓨터(548)를 포함한다. 타겟 컴퓨터(500)는 메모리(502), 및 네트워크 접속부(504)를 갖는데, 이는 본 발명의 적어도 하나의 실행예에서 윈속 층이 된다. 무소켓 프로토콜이 실행되거나, 또는 임의의 다른 공지된 또는 본 발명의 네트워크 접속부가 사용될 수 있다. 업데이트 서버(528)는 옵션 백업 저장장치(534)를 포함할 수 있는 메모리(530) 및 네트워크 접속부(532)를 갖는다. 패키지 컴퓨터(567)는 메모리(550) 및 네트워크 접속부(552)를 갖는다. 도 5는 편의상 하나의 타겟 컴퓨터(500)를 갖지만 주어진 실시예에서는 더 많을 수 있다. 그와같이, 하나의 업데이트 서버(528), 및 하나의 패키지 컴퓨터(567)가 편의상 도시되며, 본 발명은 하나만을 요구하지만 또한 두개 이상을 지원한다. 바람직한 실시에에서, 이러한 피스들은 모두 별개의 컴퓨터이지만, 이들은 동일 컴퓨터의 가상 피스이어서, 이들은 서로 다르게 나타난다. 예를들어, "패키지 컴퓨터" 피스는 업데이트 서버의 상이한 파티션 또는 동일 파티션에 상주할 수 있다.

타겟 컴퓨터는 네트워크 접속부(544)를 포함하는데, 이는 전술된 바와같이 방화벽(526)에 의해서 외부로부터 보호될 수 있다. 네트워크내의 상이한 타겟 컴퓨터는 상이한 플랫폼에서 실행될 수 있는데, 예를들면, 일부는 Windows 장치가 될 수 있으며, 일부는 Unix 장치 등이 될 수 있다. 동일 업데이트 서버(528)는 모든 플렛폼에 대해서 사용될 수 있거나, 또는 상이한 업데이트 서버(528)는 플렛폼 유형으로 규정될 수 있거나, 또는 업데이트 서버(528)는 상이한 방식을 이용하여 타겟 컴퓨터(500)에 할당될 수 있다.

타겟 컴퓨터(500)는 또한 업데이트 에이전트(508)를 포함한다. 업데이트 에이전트는 한번에 다중 장치에서 본 발명의 방법을 이용하여 설치될 수 있거나, 또는 본 시스템의 일부 실시예에서, 타겟 컴퓨터(500)상에서 종래의 방식으로 설치될 수 있는 소프트웨어 구성요소이다. 일단 등록되면, 업데이트 에이전트(508)는 세가지 기본 태스크를 수행하는 방법을 알고 있다. 즉, 1) 그 업데이트 리스트(536)로 부터 태스크 리스트를 검색하기 위해 업데이트 서버(528)에 접촉하는 방법, 2) 수신된 태스크 리스트에서 태스크를 시작하는 방법, 및 3) 폴링 간격, 동작 시간 등을 제어하는 업데이트 서버(528)로부터 수신된 정책 정보를 검색하는 방법이다.

업데이트 에이전트

타겟 컴퓨터(500)의 업데이트 에이전트는 에이전트(508)에 대해 수행될 작업이 있는지를 판단하기 위한 업데이트 서버(528)에 접촉한다. 업데이트 서버(528)는 에이전트의 업데이트 리스트 큐(536)를 분석함으로서 이를 판단한다. 이 업데이트 리스트(536)는 최소한, 소프트웨어 장소 참조부를 포함하지만, 소프트웨어 패키기(554)가 설치될 수 있는 가장 이른 날짜를 표시하는 날짜(540)를 포함할 수 있으며, 동일 소프트웨어 패키지가 다중 장소로부터 사용가능하면, 다중 소프트웨어 장소 참조부를 포함한다. 업데이트될 수 있는 소프트웨어 유형은, 제한 없이, 타겟 컴퓨터상에 현재 설치된 소프트웨어 어플리케이션을 업데이트하는 패치 파일(556), 데이터 파일(558), 스크립트 파일(562), 새로운 어플리케이션 파일(564), 실행가능한 파일(560), 드라이버 업데이트, 새로운 소프트웨어 버전 및 업데이트 에이전트 파일 자체에 대한 업데이트(566)를 포함한다.

업데이트 에이전트가 적당한 날짜(540)가 있을 때 이를 가지고, 그 연관된 업데이트 리스트(536)상의 엔트리를 발견할 때, 설치기(510)는 초기에 업데이트 서버(528)상의 메모리(530)에 소프트웨어 패키지의 복제가 이미 존재하는지를 점검한다. 만일 발견되면, 업데이트 서버로 부터 직접 소프트웨어 패키지를 다운로드한다. 이러한 상황은 이전의 타겟 컴퓨터(500)가 업데이트 서버(528)로 부터 소프트웨어 패키지(554)를 요청했을 때 발생할 수 있다.

소프트웨어 패키지가 발견되지 않으면, 설치기(510)는 그 네트워크 접속부를 이용하여 소프트웨어 장소 참조부(538)에서 주어진 패키지 컴퓨터 장소로부터 타겟 컴퓨터 메모리(502)로 직접 업데이트를 다운로드하고자 시도한다. 이것은 방화벽(526)이 없거나, 또는 업데이트 서버가 패키지 컴퓨터 장소(548)로 접속될 때 가능하게 된다.

관리자가, 패키지 컴퓨터(567)와 같은 "비 신뢰된" 소스로부터 파일을 검색하도록 업데이트 에이전트(508)에 명령할 때, 설치기(510)는 자원을 직접 검새할 수 없다. 그러나, 업데이트 에이전트는 업데이트 서버(528)가 패키지를 검색도록 요청할 수 있다. 일부 실행예에서 다중 업데이트 서버가 존재하며 업데이트 에이전트(508)는 일부 소정의 기준을 이용하여 이중 어느것을 억세스할지를 결정한다. 그 예에는 사용가능한 제 1 업데이트 서버(528)를 선택하며, 가장 덜 분주한 업데이트 서버를 선택하며, 네트워킹 용어로 "가장 근접한(closest)"인 업데이트 서버를 선택하는 등을 포함한다.

본 발명의 일 실행예에서, 업데이트 서버(528)가 오프사이트 패키지 컴퓨터(567)에 도달할 수 있으면, 그것은 업데이트 에이전트(508)에 자원에 도달할 수 있음을 통보하며 검색에 걸리는 시간을 추정한다. 이러한 추정은 에이전트에 요청된 자원이 사용되기 전에 얼마나 대기해야 하는지를 알린다. 계산 추정이 정확하지 않으면, 이는 인터넷 트래픽 요동 및 서버 응답 시간 변동으로 인해서 가능성이 별로 없는 것으로서, 에이전트가 자원을 다시 요구하면, 업데이트 서버는 또 다른 대기 시간 길이를 제공하며 에이전트는 다시 한번 대기한다. 이러한 주기는 업데이트 서버(528)가 메모리에서 사용가능한 자원을 갖을 때 까지 반복되어 다음 요청시에 에이전트에 전달할 수 있다.

특별한 소프트웨어 패키지가 상이한 에이전트(508)에 의해서 다수로 요청될 때, 본 발명의 한가지 실행예에서, 업데이트 서버(528)는 이 자원을 로컬 캐시(530)에 저장하며, 이로부터 부가적인 검색 요청을 수행할 수 있다. 업데이트 서버(528)가 구 소프트웨어 패키지를 갖는 모든 사용가능한 메모리를 채우지 못하도록 하기 위해서, 일 실시예는 패키지가 억세스되는 횟수 및 저장된 소프트웨어 패키지에 대한 최신 억세스 시간을 저장하며 그 자원이 그 캐시에 머무르는 "생존" 시간량을 추정한다. 업데이트 서버(528)내에서 실행되는 별개의 태스크는 그 유용성을 "아웃리브"한 자원에 대해서 주기적으로 점검하며 캐시(530)로부터 저장된 소프트웨어 패키지 업데이트를 삭제하므로 업데이트 호스트의 저장 자원을 복구하게 된다.

일 실시예에서 업데이트 서버는 패키지가 한번에 하나씩 에이전트의 리스트에서 사용가능하게 한다. 에이전트(508) 또는 아웃컴 파인더(512)가 패치의 어플리케이션이 실패하였다고 보고하거나, 또는 에이전트 타겟 컴퓨터(500)를 패치가 업데이트 서버와 더이상 통신하지 않는 상태로 놓으면, 업데이트 서버는 관리자를 위해서 롤아웃을 자동으로 중지한다. 이 점에서, 관리자 또는 일부 다른 지정된 사람은 아웃컴이 통보될 수 있다(516).

아웃컴 파인더(512)는 소프트웨어 패키지 설치가 성공하였는지를 판단하여 그 파인딩을 업데이트 서버(528)로 통과시킨다. 아웃컴이 성공하지 못하면, 전술된 바와같이, 리스토러(514)는 타겟 컴퓨터를 수용가능한 넌-업데이트된 상태에 놓는다. 아웃컴 파인더(512)는 반드시 실제 소프트웨어 설치만을 모니터하는 것은 아니며, 오히려 일부 지정된 시간 동안, 패치된 소프트웨어, 전체 타겟 컴퓨터, 및/또는 타겟 컴퓨터에 네트워크로 연결되는 컴퓨터의 사용을 살피도록 셋업될 수 있다. 아웃컴 파인더는 상이한 성공 레벨을 갖을 수 있다. 예를들어, 설치 자체(파일 복사)는 낮은 정도의 성공으로 간주될 수 있지만, 그후 일정 시간 동안 동작하지 않는 타겟 컴퓨터는 성공 레벨에 따라 취해진 상이한 동작으로, 더 높은 정도의 성공으로 간주될 수 있다. 성공 또는 실패는 전술된 바와같이 모니터되고, 필요하면 설치가 재시도되고 정지되기도 한다.

일부 실시예는 타겟 컴퓨터(500)상에 소프트웨어 패키지를 설치하기 전에 타겟 컴퓨터(500)의 백업(506, 534) 또는 그 일부를 저장한다. 때때로 백업은 업데이트 서버에 저장되며(534), 때로는 외부의 저장소 사이트(600)에 저장된다. 아웃컴 파인더(534)가 소프트웨어 설치에 관한 문제를 보고하면, 레스토러(514)는 타겟 컴퓨터를 넌-업데이트된 상태로 리턴시키기 위해서 백업(534)을 사용할 수 있다.

본 발명의 일 실시예에서, 업데이트 서버(523)는, 다음 타겟 컴퓨터(500)가 업데이트 서버(528)에서 그 업데이트 리스트(536)에 배치되는 패킷에 대해서 소프트웨어 장소 참조부(538)를 갖기 전에 성공적인 설치(아웃컴 파인더(512) 또는 다른 공지된 또는 본 발명의 접촉 방법에 의해서)의 확인을 대기한다. 바람직한 실시예에서, 설치가 종료되면, 관리자는 이메일(518), 페이저(520), 음성 메일(522), SNMP 통보(568), 즉석 메시징(570), 팩스 또는 다른 수단에 의해서 결과를 통보받는다(516). 설치가 실패하면, 설치가 실패한 특정 장치가 식별된다. 일부 실시예에서는, 디폴트 또는 사용자가 정의한 성공적인 설치의 수 후에, 패키지는 동시에 한명의 사용자 이상에게 사용가능하게 된다.

이러한 업데이트 리스트(536)는, 타겟 컴퓨터(500)이라고 하는, 관리되는 워크스테이션 클라이언트 또는 서버에 전달되거나 롤아웃되는 프리-빌트 패키지 또는 커스텀 빌트 패키지를 관리자가 지정하도록 한다. 이러한 패키지가 사용가능하게 될 때, 업데이트가 본 발명에 의해서 수행되는 관리자에 의해서 스케쥴되며, 이는 패치 또는 서비스 팩을 설치하기 위해서 클라이언트에 관리자의 방문을 요청하는 이전 태스크를 자동화할 수 있다.

업데이트 에이전트(508)는 동작되고 있는 플랫폼을 알고 있을 수 있으며, 관리자를 위해서 동작을 수행하도록 프로그램되거나 스크립트될 수 있다. 일 실시예에서 이러한 특징은 패키지 빌더 위자드를 통해서 관리자에게 노출된다. "소프트웨어 패키지"는 파일, 서비스 팩, 핫픽스, 소프트웨어 설치 및 스크립트의 임의의 조합이 될 수 있다. 이는 원격 장치의 관리에 대한 기회를 주는데, 이는 원격 장치에서 수행될 수 있는 거의 모든 것이 관리자를 위해서 동작하는 에이전트를 통해서 수행될 수 있기 때문이다.

본 발명의 일 실행예는 스크립트(562)가 패키지 설치를 하기 전(프리-설치) 및 후(포스트-설치)에 실행되도록 한다. 프리-설치 스크립의 일예는 다음이 될 수 있다: (의사-코드로)

가능한 디스크 공간을 점검

가능한 디스크 공간이 ValueX 보다 크면(여기서 ValueX = 설치를 위해 필요 한 룸 플러스 버퍼)이면 설치로 진행된다.

그렇지 않으면, 에러가 발생한 외부 관리에 경보를 발하고, 종료한다.

포스트-설치 스크립트의 일예(다시, 의사-코드로):

설치가 성공했으면, 성공저인 설치를 외부 소스에 통보한다.

설치가 성공하지 못했으면, 설치가 성공하지 못했음을 외부 소스에 통보한 다.

도 6 및 7을 참조하면, 네트워크(200)는 많은 상이한 종류의 타겟 컴퓨터를 포함할 수 있으며, 이들 각각은 특정 타겟 플렛폼에 대해서 특별히 구성될 수 있는 에이전트를 갖는다. 예를들어, Microsoft Windows PCs를 실행하는 네트워크, Apple Macintosh 컴퓨터, 및 UNIX 컴퓨터가 세가지 유형의 에이전트를 갖을 수 있다. 이것은 그 타겟 컴퓨터를 둘러보고 이 컴퓨터 정보(602)를 업데이트 서버(528) 및/또는 저장을 위한 별개의 저장소 사이트(600)에 보고할 수 있는 장점을 제공한다. 이 시스템의 얼마의 예에서, 발견 에이전트(548)가 제공되는데, 이는 다른 곳에서 설명되드시, 스캔을 수행한다. 다른 예에서 스캔은 업데이트 에이전트(508) 또는 다운로드 스크립트 파일(562)에 의해서 수행된다. 하드웨어 구성(608), 소프트웨어 구성(606), 여러 하드웨어 및 소프트웨어 구성요소(604)의 사용에 대한 정보, 방문한 웹사이트, 전달 및 수신된 이메일(610)이 오프사이트 장소(600)에 모두 전달될 수 있다. 이 정보가 업데이트 서버에서 사용되면, 관리자는 하나의 장소로부터 전체 관리된 네트워크를 볼 수 있다.

본 발명의 시스템이 기존의 네트워크에서 실행되면, 발견 에이전트(548)는 저장소 사이트(600) 메모리내에서 검출 및 저장되는 기존의 소프트웨어 구성(700)을 갖는, 적어도 타겟 컴퓨터(500)상에 존재하는 소프트웨어의 보기를 수행할 수 있다. 일부 시스템은 전체 네트워크(200)를 볼 수 있다. 업데이트가 요청될 때, 시스템은 그 현재 상태를 점검하기 위해서 네트워크 장치를 다시 보기할 필요없이 어떤 것들이 필요한지를 알고 있다.

타겟 컴퓨터(500)에 대해서 추천된 구성(704)이 업데이트 서버(528)상에 또는 저장소 사이트(600)상에 배치된다. 추천된 구성은, 예를들어, 하드웨어 구성에 의해서, 소프트웨어 구성에 의해서, 컴퓨터 유형에 의해서, 마지막 패키지 업데이트 등에 의해서, 본 발명의 또는 데이터베이스 기술의 숙련자에게 공지된 많은 방법으로 결정될 수 있다. 발견 에이전트(548)는 현재(700) 및 추천된(704) 구성을 비교하여 타겟 컴퓨터(500)에 대한 제안된 업데이트(708) 리스트를 준비한다. 업데이트 리스트는 설치된 소프트웨어, 이전에 설치되지 않은 소프트웨어, 업데이트된 데이터 파일 등에 대한 서비스 팩을 포함할 수 있다. 제안된 리스트를 준비하는 프로세스는 현재의 소프트웨어 구성뿐 아니라 하드웨어 구성(608), 및 본 기술 분야의 당업자에게 공지된 다른 정보는 물론이고, 특별한 프로그램, 데이터 파일 등이 얼마나 자주 억세스되는지(604)와 같은 정보를 고려할 수 있다. 관리자는 자동으로 업데이트 리스트가 통보될 수 있다.

타겟 컴퓨터 현재 구성(700)이 제안된 업데이트 리스트(706)를 발생한다고 가정하면, 관리자는 자동으로 통보될 수 있다(708). 이 점에서, 컴퓨터는, 새로운 타겟 컴퓨터가 적어도 부분적으로 업데이트될 때 까지, 또는 관리자가 허용할 때 까지, 또는 일부 다른 본 발명 또는 공지된 조건이 맞을 때 까지, 제한될 수 있다. 이처럼 제한된 업데이트 리스트(706)는 또한 다른 곳에서 설명되듯이, 실제로 컴퓨터를 업데이트하는데 사용되는 업데이트 리스트(536)를 한정하는데 사용될 수 있다.

패키지는, 소프트웨어 파일 또는 데이터 파일과 같은 파일을 표시하는 모듈 및 스크립트로 구성되며, 이는 패키지내의 파일을 취하기 위한 일련의 동작이다. 그 대신에 하나 이상의 스크립트 파일(들)은 패키지 콘텐트내에 포함될 수 있으며, 패치를 설치하기 위해서 에이전트에 의해서 실행될 수 있다. 본 발명의 일부 실시예에서, 인간 관리자는 새로운 소프트웨어 패치의 사용가능성을 통보한다. 다른 실시예에서, 언제 롤아웃할지를 결정하는 오프사이트 업데이트 서버(528)에 통보가 직접 전달된다. 오프사이트 업데이트 서버는, 각 타겟 컴퓨터에 이미 저장된 패키지를 영구 메모리에 저장하도록 구성될 수 있다. 새로운 패키지가 사용되게 될 때, 또는 기존의 패키지를 설치하는 동안에, 이전 설치에 대한 정보는 물론이고, 설치될 필요가 있는 소프트웨어 패키지의 기존의 증거는 일부 실싱예에서는 오프사이트 업데이트 서버(528)에서 사용이 가능하며, 다른 경우에는 저장소 사이트(600)에서 사용이 가능하다.

업데이트되는 패키지는 그에 대한 억세스를 수신하기 위해서 타겟 컴퓨터(500) 사용자가 소유할 필요는 없다. 시스템의 일 실시예에서, 소프트웨어 패키지는 사용자에게 소프트웨어를 대여하는 제 3 자가 소유한다. 또 다른 실시예에서, 소프트웨어 패키지는 대여하여 소프트웨어 패키지에 대한 억세스를 타겟 컴퓨터(500) 사용자에게 제공하는 업데이트 서버 사용자가 소유한다.

보안 및 임계 패치 관리, 특징

본 발명은 여러 운영 체제에서 공지된 보안 취약 및 다른 안정성 문제 또는 향상 등을 해결하는 임계 패치를 관리 및 분산시키기 위한 도구 및 기술을 제공한다. 적당한 운영체제에는 제한없이, 모든 Microsoft 운영체제 (예를들면, 95, 98, ME, NT, W2K, XP, .W2K3), UNIX 운영체제(예를들면, Linux, Solaris, AIX, HP-UX, SCO, 등) 및 Novell NetWare 운영체제가 포함된다. 운영체제 제품 이름은 그 각각의 소유주의 마크이다.

과거에는, 보안이나 다른 임계 패치를 관리하기 위해서, 회사나 다른 컴퓨터 사용자가, 예를들어 월드 와이드 웹 주위에 개시된 뉴스 보도 또는 텍스트 경보를 읽으므로 주기적으로 벤더 웹 사이트를 점검하거나 또는 새로운 패치에 대해서 찾기 위해서 이메일 가입 또는 뉴스그룹 등을 통해서 통보를 받았다. 소프트웨어를 회사가 사용하는 벤더가 어플리케이션 소프트웨어, 드라이버 하드웨어, 및/또는 하드웨어를 고정 또는 향상시키기 위해서 새로운 패치를 해제하였음을 알 때, 회사의 소프트웨어 관리 인력은 일반적으로 최신 관련 패치를 수동으로 다운로드하며, 여러 레이아웃 및 구성에서 회사의 장치와 호환성을 위해서 검사하며, 수동으로 또는 그 종래의 소프트웨어 분산 도구를 이용하여 패치(들)를 분산시킨다.

대조적으로, 본 발명은 순향적으로 컴퓨터에 임계 업데이트가 인터넷 억세스를 하는지 여부를 통보(824)할 수 있다. 본 발명은 각 다운로드를 수행하기 위한 고속 관리자 명령을 필요로 하지 않고도 패치 다운로드를 수행함으로서 순향적으로 동작할 수 있다. 본 발명은 또한 소프트웨어 업데이트, 소프트웨어 패키지, 및 다른 데이터를 네트워크로 연결된 데스크톱, 서버, 이동장치 및 다른 컴퓨터에 분배 및 설치하여 조력할 수 있다.

본 발명의 일 실시예는 패키지 컴퓨터(567)와 같은 마스터 아카이브로 부터 최근의 임계 업데이트를 검색하는 업데이트 서버(528)를 통해서 콘텐트 사본을 포함한다. 검색은 128-비트 SSL 또는 보안 전송을 위한 다른 친숙한 프로토콜을 이용할 수 있다. 새로운 업데이트가 마스터 아카이브에 첨가됨에 따라서, 업데이트의 메타데이터는 업데이트 서버 및/또는 지문 라이브러리(904)로 자동으로 다운로드된다. 메타데이터가 패치가 임계값임을 표시하면, 패치는 업데이트 서버에 다운로드되며 빠른 배치를 위해서 그곳에 캐시된다. 각각의 패치는 연관된 설치기(912), 선결 서명(910), 및 다른 지문 증명서(906)를 갖는다.

일부 실시예에서 정보는 일방향으로만 전달되는데, 말하자면, 마스터 아카이브로 부터 업데이트 서버로 전달되며, 따라서 마스터 아카이브의 보안을 향상시킨다. 이에 더해서, 일부 실시예에서 모든 전송된 정보는 암호화되며, CRC(주기적 리던던시 코드) 점검되며, 압축되며, 디지털로 사인되며, 128-비트 SSL 접속에서 다운로드된다. SSL 접속은 패치 보안으로서 마스터 아카이브의 인증을 유효하게 하며 확인하는 보안 네트워크 프로토콜을 채용한다. 다른 보안 네트워크 프로토콜이 사용될 수도 있다. 다른 실시예에서, 이러한 요소의 일부는 생략되는데, 예를들면, CRT 체크 및/또는 디지털 서명이 수행되거나 사용되지 않는다.

업데이트 서버(528)는 클라이언트 타겟 컴퓨터(500)를 위한 패치 소스로서 동작한다. 업데이트 및 소프트웨어 패키지를 관리하기 위한 복제 서비스 및 관리 툴을 포함하는 업데이트 서버는, HTTP, HTTPS 및 XML과 같은 프로토콜을 이용하여 클라이언트(500)를 스캔하고 그들에게 패치 전달을 스케쥴할 수 있다. 일부 실시예에서, 업데이트 서버는 Microsoft의 인터넷 정보 서비스를 이용한다. 업데이트 서버는, 마스터 아카이브로 부터 수신하는 임계 업데이트를 자동으로 캐시하도록 실행될 수 있다. 일부 실시예에서 관리자는 복제 스케쥴을 설정하거나, 복제 를 수동으로 트리거하거나, 예상된 또는 측정된 에트워크 비활동에 응답하여 자동으로 업데이트 서버 복제 및 분산 소프트웨어에서 복제 소프트웨어를 갖지 않을 수 있다.

일부 실시예에서, 관리자는 소프트웨어 패키지(554)를 생성할 수 있는데, 이는 다른 패치와 마찬가지로 배치할 수 있는 것이다. 즉, 일반적인 의미로 "패치"는 수정되고 있는 소프트웨어의 미리 설치된 클로우스-관련 소프트웨어의 피스를 전제로 할 필요가 없지만, 타겟에게는 새로운 소프트웨어 피스를 포함할 수 있다. 예를들어, Microsoft Office 2000 을 포함하는 패키지는 모든 데스크톱에 배치될 수 있다. 커스텀 어플리케이션의 관리자는 커스텀 어플리케이션 및 그들의 패치를 롤아웃하기 위해서 유사하게 패키지를 생성할 수 있다. 일부 실시예의 관리자는 임의의 타겟 컴퓨터에 임의의 소프트웨어 패키지를 분산하기 위해서 내장형 소프트웨어 분산 특징을 이용할 수 있다.

일부 실시예에서 업데이트 서버(528)는 기업 보고 매트릭스나 회사 또는 다른 기업에서 장치의 패치 상태의 다른 요약을 표시하는 소프트웨어 및/또는 하드웨어로 구성된다. 보고는 네트워크 관리자 및/또는 기업의 컴퓨터 기능을 유지하는 책임을 맡은 다른 사람에게 표시된다. 관리자는, 정책 설정, 그룹 정의, 경고에 응답 및/또는 여기서 논의된 또는 이미 알려진 다른 단계를 취함으로, 업데이트 서버로 부터의 어떤 업데이트 또는 패키지가 클라이언트(500)에 푸시되는지에 영향을 준다 (그리고 어떤 경우에는 전체적으로 제어한다). 일부 실시예에서는 관리자는 클라이언트 에이전트 정책을 설정 또는 수정하기 위한 전력 및 리부트의 제어를 포함하여, 패치의 배치를 완전히 제어한다.

패치는 이들이 기업에서 널리 배치되기 전에 내부에서 검사될 수 있는데, 이는 주어진 패치가 상이한 기업에서는 상이하게 동작할 수 있기 때문이다. 패치 관리를 위한 상업적인 소프트웨어 및 서비스를 제공하며, 이 어플리케이션 및 그 앞선 어플리케이션의 양수인인 PatchLink.com Corporation ("PatchLink")은 이들이 PatchLink에 의해서 해제되기 전에는 패치를 연속해서 연구, 검사 및 승인한다. 예를들어, Microsoft W2K(Windows 2000) 운영체제에 대한 핫 픽스가 Microsoft에 의해서 해제될 때, 마스터 아카이브(567)로의 PatchLink 에 의해서 해제되기 전에, 여러 서비스 s 및 다른 핫 픽스와 조합하여, 표준 W2K, SQL 서버를 갖는 W2K, Office를 갖는 W2K, 및 Exchange(Microsoft의 마크)를 갖는 W2K와 같은 이백개 이상의 상이한 W2K 구성에서 PatchLink에 의해서 설치 및 검사될 수 있다.

일부 실시예에서, 클라이언트 에이전트(508)는 어떤 업데이트가 의문시되는 클라언트에서 필요한지를 판단하기 위해서 인트라넷-호스트된 업데이트를 점검한다(332). 그것은, 업데이트 서버로 돌아가서, 관리자에 대해서 보고 매트릭스를 생성하는, 현재 구성(700)과 같은, 수집된 정보를 보고한다. 일부 실시예에서, 관리자는 배치 위저드를 이용하여 패치 배치를 규정 및 승인한다. 관리자-승인된 업데이트 및 패키지는 배경에서 다운로드되어(312), 다운로드를 수신하는 컴퓨터 사용자에게 불편을 감소시키고, 관리자에 의해서 설정된 스케쥴에 따라서 자동 설치된다. 관리자-규정된 규칙이 패치 설치 프로세스의 동작을 제어할 수 있다.

본 발명의 일 실시예는, 관리자가 실시예로 하여금 임계 운영체제 픽스 및 보안 패치와 같은, 소프트웨어 패키지 및 업데이트를 자동으로 다운로드(308, 312)되고 설치되게 하는(510) 순향 서비스를 제공한다.

본 발명의 일부 실시예의 내장형 보안 특징은 디지털 보안 증명서를 사용한다. 타겟(500)상에 다운로드 업데이트를 설치(520)하기 전에, 이 특징은 디지털 증명, CRC 점검, 압축, 및 각 파일 또는 패키지상에서 암호화를 확증한다. 업데이트 서버(528)에서, 관리 페이지 및 다른 제어에 대한 억세스는 승인된 관리자에게 제한된다. 일부 실시예에서, 업데이트의 복제(다운로드)는 SSL을 사용하며 실시예는 업데이트 서버에 다운로드의 효력을 점검한다. 즉, SSL 증명서가 인식된 소스(예를들면, PatchLink.com)를 식별하면, 다운로드는 실패하며, 서버는 이메일 경고를 관리자에게 보낸다. 일부 실시예에서, 모든 다운로드에서의 정보(업데이트 서버에 대한 마스터 아카이브, 타겟에 대한 업데이트 서버)는 암호화되며, CRC 점검되며, 압축되며, 디지털로 사인되며, 128-비트 SSL 접속부에서만 전달된다. 다른 실시예에서는, 이러한 요소가 보정(예를들면, 40-비트 암호화) 및/또는 생략된다.

패치 서명(910)은 실시예가 타겟(500)을 스캔하도록 하며 각 패치에 대한 전제(들)가 만족되었는지, 예를들면, 타겟상에서 적당한 소프트웨어 버전 및 적당한 하드웨어 드라이버에 대한 이이전트 점검을 함으로서 판단한다. 패치 서명 및 패치 지문 채취 특징은 각각 기업 보고 매트릭스에서 볼 수 있는 검출 보고를 만드는데 사용될 수 있다. 워크스테이션 목록 특징은 타겟 컴퓨터에 대해서 필요한 소프트웨어 및 하드웨어 드라이버를 특정하기 위해서 발견 에이전트(508)를 사용한다. 발견 에이전트는 또한 지문에 필요한 서명을 위해 타겟을 스캔할 수 있다. PatchLink.com 은 세상에서 가장 큰 자동 패치 지문채취 저장소중 하나를 수용하고 있는 마스터 아카이브를 갖는다.

일부 실시예에서 배경 다운로드(312) 특징은 보안 배경 전달 서비스에 내장 대역폭 드로틀링을 제공하여, 네트워크 관리자가 큰 배치 동안에 대역폭이 어떻게 활용되어야 하는지를 결정할 수 있다. 일부 실시예는 관리자에게 에이전트의 통신 간격 및 동작 시간을 정의하도록 하는 구성가능한 에이전트(508)를 제공한다. 예를들어, 관리자는 자정과 오전 2시 사이에만 프로덕션 서버에 패치를 롤아웃하기 위한 정책을 설정할 수 있다. 일부 경우에, 에이전트는 주어진 시간에 동작하는 하나 이상의 정책을 갖을 수 있다.

연계된 설치 특징은 Microsoft Qchain.exe tool을 이용하여 관리자가 반복적인 리부팅을 감소시키거나 최소화시키도록 한다. 다중 리부트를 요구하는 다중 업데이트가 설치되려면(510), 관리자는 더 적은 리부트로 업데이트를 배치하기 위해서 Qchain 과 관련하여 본 발명의 기능을 사용할 수 있다. 이 경우에는 단지 단일 리부트가 필요하게 된다. 이러한 리부트의 감소는 업데이트되는 미션 임계 컴퓨터(500)의 업타임을 증가시킨다.

Qchain은 최신 업데이트를 유효하게 하는 순서로 DLLs를 재배열한다. 관리자는 배치하는 동안에 이러한 옵션을 선택할 수 있다.

다운로드 속행 특징을 이용하여, 실시예는 예를들어, 서비스 침해에 의해서 다운로드의 차단(316)을 검출한다. 타겟(500)이 이동 워크스테이션이면, 사용자는 서비스되지 않는 상이한 장소에서 단순히 단속하고 재접속할 수 있다. 업데이트 서버가 억세스될 수 있으려면(예를들어, TCP/IP를 통해서), 실시예는, 전체 패키지를 재전송하기 위해 처음부터 다시 시작하는 대신에, 차단된 다운로드 시점에서 또는 그 근방에서 부터 그 다운로드(312)를 재개할 수 있다.

이동 사용자 지원 특징은, 사용자가 배치가 시작될 때 네트워크에 접속되지 않은 타겟 컴퓨터(500)에 패치 및 소프트웨어 업데이트를 배치하도록 한다. 이동 타겟이 이어서 네트워크에 접속되면, 실시예는 자동으로 그것을 스캔하며 그 타겟을 업데이트하기 위해서 필요한 동작을 수행한다.

실시예는 보안 다운로드(312)를 위해서 업데이트 서버(528)와 통신하는 클라이언트 에이전트(508)를 특징으로 한다. 에이전트를 이용하는 것은 넓은 실시예에서 성능 및 규모를 증가시키고, 따라서 단일 업데이트 서버가 수천개의 클라이언트에 서비스하도록 한다. 에이전트는 방화벽(116, 214)에서 동작할 수 있으며, 기업 네트워크에 TCP/IP (또는 다른) 접속으로 임의의 컴퓨터(500)에서 동작한다.

일부 실시예의 특징은 다중-벤더 패치(554)를 지원하는 것으로서, "광범위한 패치 스캐닝"라고도 한다. 업데이트 서버(528)는 단일 벤더로 부터의 패치에 제한되지 않고, 대신에 다중 벤더로 부터 본 발명의 패치 관리를 지원한다. 예를들어, 업데이트 서버는, Microsoft, IBM, Adove, Coral, Symantic, McAfee, Compaq, WinZip, Citrix, Novell, 및 많은 다른 회사(각 회사의 마크)로부터의 소프트웨어의 패치-관련 보안 취약에 대해 타겟(500)을 스캔하기 위해 타겟을 조정할 수 있다. 이는 더 안전한 네트워크를 제공한다.

일부 실시예의 그룹핑 특징은 관리자로 하여금 선택된 타겟 컴퓨터(500)를 예를들어 "콘테이너" 또는 "그룹"으로 불리는 셋트로 그룹화하도록 한다. 개별 타겟 컴퓨터에 적용되는 동작은 가능한 타겟 컴퓨터의 적당한 서브세트를 유지하는 컨테이너/그룹에 적용될 수 있는데, 즉, 특정 콘테이너에 속하는 모든 타겟 컴퓨터(500)(또는 패치 서명 및 지문의 관점에서 모든 적합한 타겟 컴퓨터)에 적용될 수 있다. 이러한 특징은, 실시예에 따라서, 배치, 지문 보고, 목록 보고, 위임 패치 베이스라인 정책, 및/또는 클라이언트 에이전트 정책의 관리자 관리를 용이하게 한다. 예를들어, 각 콘테이너는 그 멤버, 그 클라이언트 에이전트(508) 정책, 및 위임 패치 베이스라인 정책을 규정하는 특징을 갖을 수 있다. 관리자는 개별 클라이언트(500), 이전에 정의된 클라이언트 그룹, 및/또는 사용자 정의된 배치 그룹을 선택할 수 있다. 일부 실시예에서, 컴퓨터는 요구되는 패치에 따라서 자동으로 그룹화될 수 있다.

일부 실시예에서, 관리자는 Group Manager를 규정하여 그들에게 제한된 관리 제어를 위임할 수 있다. Group Manager 관점에서, 본 발명의 실시예의 고찰 및 제어는, 관리자에 의해서 관리된 그룹에 지정된 컴퓨터(500)만을 망라하도록 좁아지는데, 이들 모두는 바람직하게는 동일 업데이트 서버(528)를 이용한다. 관리자는 여전히 고찰할 수 있으며 그렇지 않으면 특별한 그룹내의 것만이 아니라, 네트워크내의 모든 컴퓨터를 관리한다.

동일 실시예에서 위임 패치 베이스라인 정책 특징은 관리자로 하여금 하나 이상의 네트워크의 컴퓨터에 대해서 최소(베이스라인) 구성을 규정하도록 하는 것이다. 실시예는 베이스라인 정책에 의해서 규정된 조직적인 표준에 운영체제 및/또는 어플리케이션을 순향적으로 패치한다. 기업의 패치 정책을 지원하는 것은 관리자로 하여금 회사에 대한 패치 정책을 설정하도록 하여, 예를들어 회사의 어떤 장치(500)도 최소 패치 레벨 이하로 떨어지지 않는다. 예를들어, W2K 그룹에 대한 위임 패치 베이스라인 정책이 Microsoft Office 2000, Adobe Acrobat Reader 5.0 및 Service Pack 2를 포함하면, 이 그룹에 배치된 모든 컴퓨터(그룹 정의에 초기에 배치되었든, 후에 배치되었든)는 설치된 소프트웨어의 적어도 이 피스를 갖는다.

패치의 베이스라인은 그룹(예를들면, 사용자 정의된 그룹 또는 관리자 정의된 그룹)에 의해서 규정되는 일련의 컴퓨터(500), 또는 특별한 운영체제를 사용하는 일련의 컴퓨터(예를들면, 사용자 또는 관리자 정의된 그룹에 관계없이 모든 W2K 컴퓨터), 또는 특별한 어플리케이션을 이용하는 일련의 컴퓨터(예를들면, Microsoft Office XP를 사용하는 모든 컴퓨터), 또는 그들의 조합과 연관될 수 있다. 예를들면, 일부 실시예에서, 관리자는 Microsoft Office XP가 설치되면 시스템이 Office XP Service Release 1에서 자동으로 패치됨을 언급하는 베이스라인 정책 룰을 설정할 수 있다.

위임 패치 베이스라인 정책이 사용될 때, 테이프 백업, 미러된 영상 또는 그와 같은 것으로 부터 소프트웨어를 회복시킴으로서 타겟(500)으로 부터 드롭되는(제거되는) 패치(554)는, 에이전트(508)가 새로운 구성을 판단한 후에 자동으로 설치되며 그 구성은 정책에 의해서 요구되는 베이스라인과 (클라이언트 및/또는 업데이트 서버에 의해서) 비교된다(822).

위임 패치 베이스라인 정책은 본 발명에 따라서 원하지 않는 소프트웨어의 자동화된 검출 및 내트웨크내의 타겟 컴퓨터로 부터 그 원치않는 소프트웨어의 제거를 수행하기 위해서 사용될 수 있다. 원치않는 소프트웨어가 검출될 때 적용되어야 하는 위임 배치 패치는 원치않는 아이템 UNINSTALL가 될 수 있다. 예를들어, 그러한 하나의 패치는 "Uninstall KaZaA"로서 회사 네트워크로부터의 KaZaA 파일 공유 어플리케이션을 검출 및 제거할 수 있는 것으로서, 비지니스 날 동안에 회사 고용인이 저작권법을 위반할 위험 또는 그들이 사용가능한 모든 네트워크 대그폭을 오락에 소모할 위험을 감소시킨다. 정부 기관 및 다른 대기업에서, 그 사용자를 할당된 직무로 부터 주의를 돌리는 팝업 소프트웨어 및 다른 것들을 제거하는 것은 우선순위가 높은 것이다.

본 발명은 또한 네트워크에서 취약점을 해소하기 위한 위임 패칭의 논리적으로 반대로 생각되는 특징을 제공한다. "금지된 패치"라고 부를 만한 이러한 논리적인 반대는 서비스 팩, 핫픽스 또는 결코 설치되어서는 않되는 다른 소프트웨어를 지칭하는데 사용된다. 위임 패치 특징이 취약점을 자동으로 고치는데 사용되드시, 금지된 패치 특징은 네트워크 관리자가 동작 구성을 망칠 수 있는 소프트웨어를 설치하지 못하게 하는데 사용된다. 일 예로써, Windows2000에서 최신 Microsoft Service Pack과 동작하지 않는 페이롤 시스템을 갖는다고 가정한다. 그 Service Pack 패치가 페이롤 서버(들)에 수동으로 또는 자동으로 배치되면, 관리자는 즉시 알 필요가 있으며, 그렇지 않으면 아무도 주말에 지불하지 않는다. 일부 실시예는 "금지된 패치"의 존재를 스캔 및 검출하여 관리자에 경고할 수 있다. 이들은 또한 룰을 제공할 수 있으며 따라서 관리자가, 적용가능한 그룹 패칭 정책이 어떻게 말하든 관계없이, 그 설치된 패치를 갖어서는 않되는 장치에 금지된 패치를 무심코 배치하지 않게 된다.

일부 실시예에서 패치 순응 보장 특징은 관리자에게 특정 컴퓨터 또는 일 그룹의 컴퓨터(500)에 대해서 일련의 패치(554)를 록킹하는 옵션을 제공한다. 즉, 어떤 패치가 요구되지만, 위임 베이스라인 특징에서 보다 더 약한 방식으로 요구된다. 패치 요구를 위반하는 방식으로 타겟(500) 구성을 변경시키고자하는 시도가 있으면, 이메일 경고 메시지(824)가 관리자에게 전달된다. 예를들어, 여러 W2K 컴퓨터가 패치 순응되는 "IIS 서비스"의 관리자 규정된 그룹에 속할 수 있다. 보안을 위해서, 실시예는 그와같이 모든 운영체제 패치 및 모든 인터넷 정보를 록다운한다. 약간 나중 시점에서 그러한 패치(제한없이 DLLs를 포함)가 변경되면, 실시예는 관리자에게 이메일 경고를 보내서 컴퓨터(500) 이름 및/또는 그에 행해진 수정을 식별한다. 새롭게 비-순응되는 컴퓨터(들) 및 비-순응에 대한 이유(들)- 그들의 구성 및 록크된 구성 사이의 불일치의 개요-이 식별될 수 있다. 일부 경우에, 이러한 순응 특징은 새로운 소프트웨어를 설치하거나 기존의 소프트웨어를 그 장치로 부터 제거하는 사용자를 식별하기 위한 관리자에 의해서 사용될 수 있다. 이러한 순응 록킹 특징은, 비-순응인 타겟(500)을 자동으로 패치하기 위해서 위임 패치 베이스라인 특징과 관련하여 일부 실시예에 의해서 사용될 수 있다. 록크된 패치 또는 다른 소프트웨어 구성요소가 제거되면, 그것은 자동으로 재설치되며, 관리자는 이메일로 통보된다(824).

일부 실시예에서 서비스 변경 특징은 관리자가 클라이언트 워크스테이션(그룹 또는 개별적으로 상주하는)에 제공되는 서비스를 록크하도록 하며, 사용자가 관리자에 직접 접촉하지 않고도 서비스 아이템을 시작 또는 정지하는지가 통보되도록 한다. 사용자가 록크된 클라이언트(500)에서 서비스 상태를 변경 및/또는 변경 시도를 함에 따라서, 이메일 경고(824)가 관리자에게 전달되어 컴퓨터 및 (시도된) 서비스 변경을 식별한다.

어떤 실시예에서의 하드웨어 변경은 관리자가 클라이언트 워크스테이션(500)(예를들면, 그룹으로)에 제공된 하드웨어 구성을 로크 다운하게 하며, 관리자에 직접 접촉하지 않고도 사용자가 워크스테이션과 같은 것으로 부터 하드웨어 아이템을 설치 또는 제거하는지를 통보받도록 한다. 사용자가 록크된 클라이언트에서 하드웨어 구성을 변경(또는 변경을 시도)함에 따라서, 이메일 경고가 관리자에게 전달되어(824) 컴퓨터 및 (시도된) 하드웨어 변경을 식별한다.

임포트/엑스포트 특성은 높게 보안이 유지되는 군사 또는 정부 기관 컴퓨터와 같이, 인터넷에 접속되지 않은 네트워크상의 컴퓨터를 업데이트하는 것을 용이하게 한다. 컨텐트는, 운송중에 취해진 적당한 물리적인 보안 장치로, 물리적으로 운송되는 테이프, 디스크, 또는 마스터 아카이브에서 콘텐트(554)가 로드되는 다른 저장 매체와 같은, 인터넷 이외의 수단을 이용하여 마스터 아카이브로 부터 타겟 네트워크의 업데이트 서버(528)에 운송된다. 매체가 보안 타겟 네트워크의 업데이트 서버(528)에 억세스되면, 전술된 내장형 보안 장치(암호화, CRC 등)가 채용될 수 있으며 운송된 매체로 부터 그 업데이트 서버의 로컬 저장장치로 콘텐트를 운송한다. 이어서 그 업데이트 서버는 전술된 보안 네트워크 타겟 컴퓨터를 업데이트하는 것을(304) 종료할 수 있다.

일부 실시예에서 분산 특징을 순환시키는 것은 기업 고용인 목록 또는 항-바이러스 정의/데이터 파일과 같이, 반복해서 업데이트되는 데이터 또는 문서(554)의 분산을 용이하게 한다. 하나 이상의 그러한 데이터 또는 문서 파일은 관리자에 의해서 규정된 순환 스케쥴에 따라서 모든 타겟(500)에, 예를들면, 관리자 규정된 그룹 또는 단일 타겟에 배치될 수 있다. 다른 단계, 이를테면, 서버 리부트를 순환시키는 것이 일부 경우에 규정될 수 있다.

일부 실시예의 재난 복구 특징은 관리자가 하드 디스크 크래시 또는 서버 하드웨어 실패와 같은 시스템 실패로부터 복구하도록 한다. 업데이트 서버(528)가 실패하면, 관리자는 실패한 서버와 같은 DNS 이름을 갖는 또다른 서버를 생성하여, 새로운 서버에 (요구되면 동일 일련 번호를 갖는) 동일 업데이트 서버 소프트웨어를 재설치한다. 아카이브된, 미러된, 또는 그와는 달리 본 실시예에 의해서 사용된 저장된 데이터 파일(600)이 필요할 때 새로운 업데이트 서버에 복구된다. 그러면 타겟 에이전트(508)는 업데이트 서버의 새로운 경우와 자동으로 접속되며, 타겟 에이전트가 서버 실패에 의해서 손실된 정보(만약 있다면)를 제공한 후에 정상 동작이 재개된다.

일부 실시예에서 자동 캐싱 특징은 업데이트 서버(528)가, 임계, 높은 순위 및/또는 보안 관련된 것으로 마크되는 로컬 업데이트 서버 저장 패치에 자동으로 다운로드 및 캐시하도록 한다. 업데이트 서버는 관리자에게 어떤 패치가 임계이며 어떤 것이 캐시되는지를 통보하며, 패치를 요구하는 타겟 컴퓨터(500)를 스캔한다. 대조적으로, 비-임계 패치는 먼저 배치된 후에 업데이트 서버에서 캐시될 수 있다. 임계 및 보안 패치를 초기 배치전에 캐시하는 것은, 소프트웨어가 취약한 벤더가 패치 요청에 의해서 압도당할 때 패치에 대해서 쉽게 사용가능한 소스를 타겟에 제공한다. 코드 레드 및 님다 바이러스가 공격하는 동안에, 예를들어, 일부 사용자는 패치를 얻기 위해서 마이크로 웹 사이트에 접속하도록 수시간을 대기해야 하는데, 이는 그에 대해서 매우 강한 요청이 있기 때문이다. 본 발명의 업데이트 서버(528)에서 임계 및 보안 패치를 순향적으로 캐싱하는 것은 타겟 컴퓨터(500)의 동작이 그러한 패치의 부족으로 인해서 차단 또는 압축될 위험을 줄인다.

일부 실시예는, 운영체제에 패치를 맞추는(554), 지능형 다중 패치 배치 특징을 갖는데, 이는 운영자가 각각의 타겟 컴퓨터에서 사용되는 운영체제를 고속으로 그리고 완전히 식별할 필요성을 줄여주게 된다. 예를들면, 마이크로소프트가 여러 상이한 운영체제 플랫폼에 대해서 상이한 패치(554)를 규정하는 그 운영체제에 대한 회보를 발행했다고 가정한다. 본 발명의 실시예를 이용하는 관리자는 배치를 위해서 "Microsoft 운영체제"만을 선택할 필요가 있다. 즉, 그들은 여러 규정된 타겟의 운영체제 세부점의 차이에 상관없이 타겟 컴퓨터(500)를 규정할 수 있다. 실시예는 패치와, 호환성 및 패치에 대한 요구에 대한 운영체제 요구조건을 비교하여, 적당한 ㅍ치가 주어진 타겟에 설치되도록 보장한다. 따라서, Microsoft Windows 98 플랫폼에 대한 패치는 Windows 98 운영체제를 실행하는 타겟 컴퓨터에 설치되며, Microsoft NT 플렛폼에 대한 패치는 NT 운영체제를 실행하는 타겟 컴퓨터에 설치되게 되는 식이다. 이러한 특징은 관련되는 운영체제(또는 종래의 패치를 포함하는 운영체제 버전)에 따라서 패치를 타겟에 수동으로 정합시킬 필요로 부터 운영자를 면제시키므로 패치 배치를 가속시킨다.

또 다른 특징은 응용가능한 패치(554)를 검출하여 패치 상호의존성을 관리하여, 관리자가 일반적으로 관련없는 수 다스(혹은 심지어는 수백개)의 패치를 수동으로 분류할 필요가 없게 된다. 그 대신에, 실시예는, 관련된 운영체제, 다른 패치의 존재(또는 부재), 상이한 패치의 상호의존성(어떤 패치가 어떤 다른 패치에 의존하여 적당히 동작하는지를 식별), 및 위임 패치 베이스라인 정책(있다면)과 같은 요인들에 기초한, 그들의 메타데이터, 지문, 및/또는 서명 데이터를 이용하여 적용가능한 패치를 식별한다. 그후, 관리자에게는 어떤 패치가 의문인 타겟(들)(500)에 적용 가능한지가 보여진다. 예를들어, 일 실시예는 IIS가 타겟 컴퓨터에 설치될 때에만 관리자로 향하는 IIS 패치를 도시한다. 일관적으로 사용되면, 이 특징은 패치가 타겟을 향해서 배치될 때, 그 타겟이 의문인 어플리케이션을 갖으며 패치가 그 타겟에 설치된다.

패치 상호의존성의 예로서, Microsoft W2K 플랫폼에는 일 실시예가 관리자에게 Service Pack2을 추천하며, Service Pack2가 설치되면 Security Rollup 패치를 추천하는데, 이는 Service Pack2에 의존한다. 실시예는, 패치(554) 식별을 유효화하기 위한 지문을 정확히 수행하도록 등록 및 파일 정보를 읽는다.

일부 실시예는 관리자가 최근 동작의 히스토리 또는 로그를 재고해 보고, 패치(554) 또는 그 부분과, 패치를 네트워크에 배치하는 롤백 효과를 설치 해제하도록 한다. 이것은 문제를 야기한 패치 설치를 취소하도록 한다. 손실된 사용자 데이터는 반드시 복구되지 않고, 종래의 언인트롤러에 의해서 취해진 보통 단계가, DLL을 삭제하며, 등록 엔트리를 제거하며, 경로 또는 다른 시스템 변수 값을 복구하는 등과 같이, 복구기(514)를 이용하여 취해질 수 있다. 이에 더해서, 서명, 지문, 경고, 및 보고와 같은, 실시예에 특별한 구성 상태가 업데이트되어 직면하는 문제 및/또는 패치의 제거를 반영한다. 관리자에게는 또한 제거된 패치가 패치 의존성 및/또는 위임 패치 베이스라인에서 나타나는지 여부가 통보될 수 있다.

일부 실시예는 "목록-중립(directory-neutral)" 특징을 갖는데, 이는 그들이 플랫폼 중립이며 동작하기 위해서 Novell's NDS 목록 또는 Microsoft's Active Directory 제품과 같은 목록을 요구하지 않음을 의미한다. 그러나, 일부 실시예는 특별한 조직내의 그러한 목록과 통합 및 협동할 수 있다.

일부 실시예는 선택적인 패치 특징에 따라서 동작하는데, 그 때 패치(554)는 그것들이 위임 패치 베이스라인 정책을 만족시키도록 요구되지 않으면 자동으로 설치되지 않는다. 일부에서는, 임계 및/또는 보안 패치로서 마크되는 패치가 자동으로 설치된다. 그러한 실시예에서, 다른 패치는 그들 관리자가 그것들을 선택하고 고속으로 그들의 설치를 승인하지 않으면 설치되지 않는다. 즉, 이것은 조직의 커스토머에게 그것들을 설치하기 전에 그 조직내에 내부적으로 패치를 검사하도록 한다. 패치가 적당힌 검사되면, 그것은 의문인 타겟(500)의 그룹에 대해서 위임 패치 베이스라인으로 첨가될 수 있어서, 필요할 때 자동으로 설치된다.

일부 실시예는 어플리케이션이 타겟 장치(500)에서 동작하지 않도록 하는 보안 정책 패치(554)를 지원한다. 이것은 정책-구동 방법을 제공하여 타겟 컴퓨터의 파일 시스템으로 걸리게 하며 특정 파일(또는 다중 파일)이 실행되지 않게 한다. 이것은, 의문인 실행가능한/DLL 파일(들)을 리네임하며 아무것도 하지 않는 코드, 또는 사용자에게 에러 메시지를 표시하는 코드, 및/또는 관리자에게 이메일로 통보하는 코드를 그 자리에 대치하는 패치에 의해서 실행될 수 있다.

본 발명의 동작은 다음 예의 시나리오를 고려함으로서 더 잘 이해할 수 있다. 하나의 시나리오에서, 새로운 패치(554)가 그 각각의 벤더에 의해서 해제됨에 따라서, 업데이트 서버(528)는 대응하는 지문을 마스터 아카이브(567)로 부터 다운로드한다. 실시예는 타겟 컴퓨터(500)가 패치의 지문을 에이전트(508)에 의해서 스캐닝하기 위해 타겟으로 보냄으로서 파일을 만족시키는지(의문인 패치를 필요로하는지)를 보기위해 점검한다. 관리자는 네트워크상의 새로운 패치 및 그 잠재적인 충격을 통보받고, 보고 매트릭스는 관리자에게 어떤 타겟이 패치를 요구하며 어떤 타겟이 패치를 요구하지 않는지를 알려준다. 관리자는 하나 이상의 개별적인 타겟 컴퓨터 및/또는 그룹을 선택하며, 배치를 승인한다. 배치는 여기서 논의된 바와같이 진행된다. 관리자는 배치 시간을 설정할 수 있으며, 설치후에 리부트하는지 여부를 결정한다.

관리된 데이터 센터 시나리오에서, 센터의 관리자는 데이터 서버의 각 클러스터로부터 패치 그룹을 생성한다. 관리자는 마스터 아카이브(567)로 부터 수신된 임계 업데이트를 검사할 수 있으며, 이어서 한번에 모두 또는 스테이지에서 그룹으로 네트워크 타겟상에 검사된 패치(554)를 배치한다. 에이전트 정책은 관리자가 각 그룹에 대한 동작 시간을 규정하게 할 수 있다.

일 실시예의 업데이트 시나리오에서, 실시예에서 사용되는 소프트웨어는 실시에를 사용함으로서 업데이트된다. 즉, (PatchLink.com과 같은) 벤더가 타겟 에이전트(508), 업데이트 서버(528), 및/또는 다른 실시예 소프트웨어에 대한 소프트웨어에 패치(554)를 제공할 때, 이들 패치는, 운영체제 또는 사용자 어플리케이션에 패치를 배치하는데 더 자주 사용되는 본 발명의 툴 및 기술을 이용하여, 전술된 바와같이 배치될 수 있다. 예를들어, 관리자는 PatchLink HotFix 클라이언트 패치를 선택할 수 있으며 그것을 업데이트 클라이언트 에이전트 소프트웨어로 배치한다. 클라이언트 에이전트는 그것들을 모든 타겟 컴퓨터로 푸시하므로서 초기에 배치될 수 있다.

실행예 노트

특정 실시예에 대한 부가적인 세부점은 아래 제공된다. 이러한 실행예 세부점은, 너무 적은 정보를 포함하는 것이 아니고 너무 많은 정보를 포함함으로서-에러가 일어나면- 오류를 범하기 위해서 제공된다. 신청자는 그처럼 다가오는데 불리하게 되어서는 않된다. 특히, 세부점을 포함하는 것은, 그러한 세부점, 또는 유사한 세부점 또는 유사 레벨의 세부점이 궁국적으로 허용되는 청구범위를 지원하는데 실제로 요구되는 가정 또는 허용으로서 보여져서는 않된다. 특정 실행예 세부점을 포함하는 것은, 다른 것들에 의해서 추론되는 본 발명의 아이디어를 단순히 실행한 발명자로서 취급함으로서 오해되어서는 않된다.

에이전트

ㆍMicrosoft Windows Agents

ㆍNetWare Agent

ㆍLinux Agent

ㆍJava Agent

패키지 구성/패키지 유지

관리자는 이러한 모듈을 이용하여 지정된 Update 에이전트를 통해서 분산을 위한 패키지를 생성하게 된다. 이 패키지는 파일 분산 또는 소프트웨어 패키지가 될 수 있어서, 기존에 설치된 소프트웨어를 업데이트할 때 더 많은 융통성을 허용하며, 지정된 관리 장치를 통해서 새로운 소프트웨어, 파일-복제 등을 설치한다.

이하는 적합한 패키지 생성을 위한 단계이다.

1. 패키지 명세를 입력

ㆍ패키지 이름 - 업데이팅 프로세스를 통해서 패키지를 레이블

ㆍ패키지 유형 - 소프트웨어 패키지가 소프트웨어 패키지 루틴에서 선택될 때, 패키지에 대한 소스 파일이 그 적당한 목적지 순서에 배치된 후에, 관리자는 (나머지 옵션에 대해서 미리 지정된 디폴트 값을 이용하여) 패키지 기준을 즉시 종료할 수 있다. 파일 분산은 관리자가 패키지 기준 루틴에서 모든 단게를 완성하도록 요구한다.

ㆍ운영체제 - 패키지가 롤아웃될 수 있는 운영체제를 선택. 현재, 패키지당 하나의 운영체제를 선택할 수 있다. 이들은, Linux, NetWare, Windows 2000/NT, Windows NT, Windows 95/98/ME를 포함한다.

ㆍ(선택적인) 임포트 - 이전에 엑스포트된 패키지를 임포트. 이 옵션은 다중 운영체제를 위한 동일 패키지르 생성하는데 유용하다.

2. 소스 추가

ㆍ추가 파일 - 로컬 워크스테이션 또는 도달가능한 네트워크 장소로 부터의 목록을 추가

ㆍ Dir 추가- 로컬 워크스테이션 또는 도달가능한 네트워크 장소로 부터의 목록을 추가

ㆍURL 추가 - 원격 파일을 공지된 프로토콜을 통해서 패키지로 추가. 추가할 수 있는 여러 유형의 URL은: Local File-File://, FTP-ftp://, HTT-http://, Secure HTTP-http://, 에이전트가 프로토콜(이 필드는 을 인식하는한 다른 것을 선택함(이 필드가 편집가능).

ㆍ제거 - 패키지로 부터 파일을 제거

ㆍ특성 - 업데이트 서버내에 각 파일이 저장되는 방법에 대한 세부점을 도시. 또한 하나의 소스가 비지 또는 슬로우(예를들어 네트 래그로 인해)인 경우 다중 소스에 대해서 허용한다. 에이전트는 자동으로 다른 소스를 시도한다.

ㆍ임포트 파일 - 이전에 엑스포트된 패키지로 부터 특정 파일 리스트를 임포트.

3. 목적지 추가

ㆍ타겟 컴퓨터 - 패키지 파일 목적지의 계층적 트리 도면. 도시된 여러 디폴트 목록이이 패키지가 타겟되는 운영체제에 의존한다. 패키지는 항상 소스 파일이 원래 임포트되었던 동일 목록 경로에서 표시한다(단계 2 참조). 파일을 주변으로 이동시키기 위해서 목록 또는 파일을 단순히 하이라이트하고 그 새로운 장소로 드레그한다.

ㆍ특성 - 파일이 설치해야 할 목록이 표시되지 않으면, 파일을 하이라이트하고 특성 버튼을 클릭한다. 이것은 소스 파일이 나오는 중인 베이스 정보 및 목적지에 대한 엔트리 필드를 표시한다. 새로운 장소를 타이프하고 OK 및 당신의 변경을 클릭하는 것이 도시된다(이는 어느정도 걸리는데 경로가 큰 패키지 파일 번홍 재접속되기 때문이다).

ㆍ엑스포트 파일 -베이스 패키지를 임포트 기능에서 나중에 사용하기 위한 파일(소스 및 목적지 정보)로 엑스포트한다.

4. 의존성

ㆍ좌측 컬럼 - 롤아웃에 준비되는 기존의 패키지의 리스트(운영체제 의존). 예를들어, 당신이 수많은 컴퓨터로 롤아웃되어야 하는 Java 기반 패키지를 가지고 있다면, 당신은 당신의 의존성으로서 특정 JDK 패키지를 선택하여 JDK가 현재 패키지에 앞서서 설치된다.

ㆍ우측 컬럼 - (화살표 버튼을 사용하므로) 여기에 배치된 패키지는 당신의 패키지에 대한 의존성이다. + 및 - 버튼을 이용하여 중요성의 순서로 의존성을 배치한다 (가장 중요한 것은 제 1 의존성이다). 의존성은 당신의 패키지 전에 처리된다.

ㆍ어셋 - 의존성이 발견되지 않으면 패키지는 설치되지 않는다. 예를들어, Microsoft Office 2000 SRI 패키지가 생성되면, 그 어셋 의존성은 이미 설치되었어야 할 Microsoft Office 2000 이다.

ㆍ설치 - 의존성이 발견되지 않으면, 현재 패키지를 설치하기 전에 그것들을 설치한다. 전의 예를 사용하여, MS Office 2000이 발견되지 않으면, 그것은 SRI 패키지를 설치하기 전에 설치된다.

5. 패키지 설정

ㆍ백업 - 목적지 장치에서 발견되는 임의의 기존의 패키지 파일을 백업한다. 편집가능한 풀-다운 리스트는 의문인 운영체제를 위한 가장 일반적인 목록을 포함한다. 당신의 목록이 발견되지 않으면 리스트에 타이프하기만 하면 된다.

ㆍ확신 레벨 - 모든 새로운 패키지에 대한 디폴트는 New 이다. 확신 레벨은 이러한 패키지가 검사되었으며 그 성능이 그 확신 레벨을 판단하였음을 나타낸다.

ㆍ이용도 - 디폴트는 패키지가 롤아웃을 위해서 이용가능함을 나타내는 Available 이다. Not Available 은 이렇게 생성된 패키지가 롤아웃을 위해서 이용가능하지 않음을 나타낸다.

6. 스크립트

ㆍ당신이 사용할 수 있는 세가지 유형의 패키기 스크립트가 있다: 즉, 명령 라인 - 이 스크립트의 내용은 표준 명령 라인으로서 실행된다. 이 스크립트는 파일이 그 목적지로 복사되고 난 후에 전달된다. 프리-스크립트- 이 스크립트의 내용은 파일이 장치로 복사되기 전에 실행된다. 포스트-스크립트 - 이 스크립트의 내용은 파일이 장치로 복사되기 전에 실행된다.

7. 시스템 설정

ㆍ언어 - 패키지가 사용가능한 언어를 선택한다. 에이전트는 언어가 장치에 놓이며 패키지는 패키지가 설치되기 전에 매치됨을 점검한다.

ㆍ프로세서 유형 - 패키지가 사용가능한 프로세서를 선택한다. 에이전트는 프로세서가 장치에 놓이며 패키기가 설치되기 전에 매치됨을 점검한다.

8. 종료 - 파일을 업로드하고 패키지를 모으기 위해서 Finish를 클릭한다. 모으기 프로세스가 종료되면 버튼은 Finish에서 Done로 변경된다. 패키지 생성 기능을 완수하기 위해서 Done 을 클릭한다.

그룹 증의/그룹 수정

본 모듈은 관리자가 그룹 장치를 함께 만들게 하여, 롤아웃 과정을 더 용이하게 하므로 롤아웃이 500개의 장치에서와 같이 하나의 장치에 대해서 용이하게 된다. 이에 더해서, 관리자는 대역폭 활용을 그 네트워크에 대해서 더 효율적이도록 그 기능 또는 장소에 따라서 장치를 그룹화할 수 있다.

1. 그룹 이름 - 그룹에 대한 라벨 지정

2. 장치 리스트 - 이 그룹이 포함하는 모든 장치를 선택한다. 하나의 장치는 업데이트 에이전트가 설치되고 등록된 후에만 나타난다.

3. 종료 - 장치가 그룹에 배치된 후에, Finish 버튼이 Done으로 변경된다. 그룹 기능을 완수하기 위해서 Done을 클릭한다.

롤아웃 스케쥴/기존 롤아웃 보기

롤아웃 스케쥴은 패키지가 지정된 장치에 사용가능한 날짜 및 시간을 정의한다.

1. 패키지 선택

ㆍ패키지 선택 리스트- 설치할 패키지(이 시간에는 단지 하나) 선택.

2. 장치 선택

ㆍ그룹 추가 - 이 버튼은 사용가능한 그룹의 리스트를 나타내는 대화 박스를 표시한다. 당신이 배치하고자 하는 그룹을 하이라이트하고 OK 버튼을 클릭한다.

ㆍ그룹 제거- 패키지가 롤아웃되는 것을 원하지 않은 그룹을 하이라이트하고, 그룹 제거 버튼을 클릭한다.

ㆍ장치 추가- 이 버튼은 사용가능한 장치(그들에 등록된 업데이트 이에전트를 갖음)의 리스트를 나타내는 대화 박스를 표시한다. 추가를 위해 장치를 하이라이트하고 이어서 OK 버튼을 클릭한다.

ㆍ장치 제거 - 패키지가 롤아웃되는 것을 원하지 않는 장치를 하이라이트하고, 장치 제거 버튼을 클릭한다.

ㆍ롤백 -막 설치된 패키지를 제거하고 (하나가 지정되었으면) 백업을 리턴한다. 이 옵션은 기존 롤아웃 보기를 통해서만 사용가능하다.

ㆍ재적용-패키지를 재 설치

3. 롤아웃 날짜 및 시간 선택

ㆍ달력 - 발생되는 룰아웃 설치를 위한 날짜를 선택

ㆍ시간 - 패키지가 룰아웃 될때 서버상의 시간.

4. 대역폭 및 순서 선택

ㆍ대역폭 - 이 레벨은 패키지를 다운로드하는 서버상의 대역폭이 얼마나 활용되는지를 결정한다. 최소값은 30%이고 최대값은 100%이다.

ㆍ순서 - YES(디폴트 값)을 선택하는 것은 롤아웃이 전체 롤아웃 프로세스를 통해서 장치간에 이동하게 하며 마지막 장치가 수행된 후에 종료되게 한다. 룰아웃 프로세서에서 어딘가에서 에러가 발생되면 룰아웃은 정지된다. NO를 선택하는 것은 룰아웃이 모든 장치에서 패키지를 설치하도록 한다. 에러가 하나의 장치에서 발생되면, 그것은 또 다른 장치의 패키지 롤아웃에 영향을 주지 않는다.

5. 종료 - 롤아웃이 생성되거나 업데이트되며 Done 버튼을 클릭한 후에 저장된다.

이에전트 요청은 POST 방법을 이용하여 HTML Forms의 형태가 될 수 있다. Host 응답은 잘 형성된 XML 1.0 문서가 된다. 리턴된 문서의 대부분은 간단한 구조로 되어 있으며, DTD, NameSpace, 또는 Schema가 포함되지 않지만, 이들은 문법적으로 그리고 구조적으로 XML 명세에 따른 것이다. 모든 날짜 및 시간은 Coordinated Universal Time(GMT)에 정규화된다.

이는 에이전트, 리퀘스터, 및 호스트, 업데이트 서비스 사이의 트랜잭션 또는 데이터 흐름을 설명한다. 모든 업데이트 트랜잭션은, 호스트가 오픈되며, 에이전트 ID를 전달하고 이어서 에이전트에게 그 요청 스케쥴에 관계없이 호스트로 부터 작업 리스트를 요청해야 함을 효과적으로 "핑(Ping)" 또는 통보하기 위해서 에이전트의 IP 어드레스의 동의 포트 및 프로토콜을 닫는 경우를 제외하고는, 에이전트에 의해서 초기화된다.

제 1 접촉

업데이트 서버(528) 서비스와 대화할 필요가 있는 임의의 에이전트는, 항상 상기/업데이트 서브디렉토리를 위한 지정된 마스터 사이트에 요청한다. 이 서브디렉토리는 '302 Object Moved' 및 그 '새로운' 장소를 리턴하기 위해서 구성된다.

다음 예에서 예시되듯이, 에이전트는 www.patchlink.com 사이트의 상기/업데이트 서브디렉토리 상의 'HEAD' 요청을 수행한다.

헤드 요청

HEAD/update http/1.1

호스트는 물체가 이동하는 것에 응답하며, 새로운 장소가 Location:header에 의해서 제공되는 어드레스에서 발견될 수 있다.

InstallShield Agent Registration:

'update agent'의 물리적인 설치 동안에, 관리자는 에이전트가 설치되기 전에 어떤 정보를 입력시키도록 요구된다. Admin은 Host Name 또는 Address, Account Identifier, GUID(Globally Unique Identifier), 및 등록시에 규정된 User Name 및 Password를 입력시키도록 요구된다. 이 데이터는 에이전트 소프트웨어를 설치할 능력을 증명하기 위해서, 그리고 에이전트에 대한 ID를 보장하기 위해서 호스트로 전달된다.

Agent TaskList

InstallShield가 성공적으로 컴퓨터상에 BootStrap Agent 소프트웨어를 설치했으면, 에이전트가 동작을 시작할 시간이다. 에이전트가 업데이트 서버(528) 호스트 사이트 어드레스를 결정한 후에 'TaskList' 요청을 보낸다. 'TaskList'는 Admin이 수행할 Agent에 대해서 스케쥴한 'Task' 아이템의 간단한 리스트이다.

BootStrap Agent는 다음을 할 수 있어야 한다. 즉,

1. 초기 TaskList를 요청

2. 초기 TaskList를 수신

3. 초기 TaskList를 이해

4. Full Agent의 설치 파일을 다운로드

5. Agent Install을 실행

6. 임의의 설치 문제를 보고하고, 명령대로 계속함

7. Full Agent 시작

8. 새로운 Agent를 시작

9. SoftPkg IDs 및 의존성을 이해하고 다운로드

10. 외부 Scrip Engine을 실행하거나 Agent내에서 부터 Scrip Engine을 실행함으로서 초기 "Action Scripts"

초기 TaskList를 요청하고 리턴된 응답을 처리하는 Agent가 이를 수행한다. 예를들면,

TaskList Request

POST server_object_returned_in_firstcontact http/1.1

Content-Type:text/html

Content-Length:32

Action=TaskList

&AccountID=AF011203-7A09-4b67-A38E-1CB8D8702A50

&AgentID=D7292F2D-CCFE-46dc-B036-3B318C2952E3

&AgentVer=0.0

&LocalTime=20000628010100

&Status=0

이 요청에서, 에이전트의 버전은 0.0 이다. 이것은 호스트에게 이것이 에이전트의 새로운 설치이며 호스트가 적당한 에이전트 소프트웨어의 최신 버전을 다운로드하는 에이전트에 'Task'를 준비해야 한다는 것을 표시한다. 다음 응답에서, 이것은 제 1의 'Task-TaskID="C1D50120-FF13-11d3-95B5-000629526438"으로서 도시된다.

Agent의 정책에 변화가 있었을 때 마다, 호스트는 "TaskList"에 정책 데이터를 포함한다. 왜냐하면 이것은 에이전트로 부터의 초기 요청이며, 정책 데이터는 이 응답에 포함되기 때문이다.

LocalTime은 바로 지방 시간(GMT가 아님)이다. 이것은 서버가 에이전트 장치에서 정확히 몇 시 인지를 알게 한다. 포맷은 YYYYMMDDHHMMSS 이다.

Satus는 수행되어야 할 태스크가 있으면 토크리스트 프로세서에게 간단히 네 또는 아니오 상태로 돌아가도록 말한다.

Status=0 는 정상 태스크 리스트로 리턴하는 것을 의미한다. Status=1은 당신이 수행되어야 할 태스크를 갖는지를 에이전트에게 말하는 것을 의미한다. 이것은 에이전트가 넌-SSL로 가서 빠른 체크를 하도록 한다.

Agent Soft Package Request

제 1 태스크는 설치되어야 할 모듈이 있음을 표시한다. 이하 설명되드시, 에이전트는 호스트로 부터 상세한 설치 정보를 요청한다.

Soft Package Request

POST server_object_returned_in_firstcontact http/1.1

Content-Type:text/html

Content-Length:nnnn

Action=SOFTPKG

&AccountID=AF011203-7A09-4b67-A38E-1CB8D8702A50

&AgentID=D7292F2D-CCFE-46dc-B036-3B318C2952E3

&AgentVer=0.0

&TaskID=C1D50120-FF13-11d3-95B5-000629526438

&PkgID=12340000-1111-0000-0000-000000000000

&LocalTime=20000628010100

이 예에서, 에이전트의 버전은 0.0임을 명심할 수 있다. 이것은 호스트에게 에이전트 소프트웨어를 업데이트하기 위한 패키지가 TaskList 응답에 포함되어야 함을 나타낸다. 이것은 사용가능한 에이전트 소프트웨어의 더 새로운 버전이 있을 때를 동적으로 판단하도록 하며 에이전트가 스스로 업데이트하도록 한다.

호스트는 에이전트가 태스크를 완성시키는데 필요한 정보를 상세히 설명하는 "Open Software Disribution" 문서를 함께 모은다.

LocalTime은 바로 지방 시간(GMT가 아님)이다. 이것은 서버에게 Agent 장치에서 정확히 몇시인지를 알려준다. 포맷은 YYYYMMDDHHMMSS 이다.

Soft Package (모든 요소)

소프트 패키지는 모든 가능한 XML 구성요소이다(백업을 도시한다).

소프트 패키지 상태-성공

리턴 코드 RC 및 SoftPkgRC는 십진수 포맷이다. SoftPkgRC는 패키지의 전체 완성을 나타낸다. 일부 모듈은 성공적이었지만(RC=0), 또 다른 것은 에러를 야기시켰다. 롤아웃이 이미 한번 설치된 패키지로 시도되면, 에이전트는 그것이 설치 및 리턴된(SoftPkgRC=725003) 모든 모듈에 대해서 리턴되거나(RC=0) 또는 0x000b100b Soft Package가 이미 설치되었다.

태스크가 완성될 때, 에이전트는 호스트를 다음 결과로 업데이트한다.

요청

파일 속성 및 ACL's

이 부분은 GX:Destination (GX:URI) 요소에서 발견되는 GX:AGL 요소를 기술한다. Update의 속성은 후술되는 Super set 형태로 에이전트에 공급된다.

기본 파일 속성을 수행하는데 따른 문제는 일부 파일 시스템이 속성과 ACL's 사이의 경계에 결점을 남긴다는 것이다. 하나의 속성은 파일의 기본 ACL이며 여기서 정의되는 것은 작은 크로스 플랫폼 수퍼셋이다. 예를들어, Windows NTFS는 읽기 전용 속성 플래그를 갖지만 그것은 또한 읽기 ALC를 갖는다. 그러므로, 우리가 포괄적인 속성 플래그를 만들고자 하면, 우리는 그 의미가 ACL's로서 사용될 때 어느정도 변경될 것을 예상해야 한다. 유닉스 플랫폼 상에서 그것들은, 다른 플랫폼과 같이, 당신이 이해하지 못하는 또는 정의된 동작이 여기서 리스트되지 않은 플래그를 무시하는 것을 제외하고는, 차이가 없다.

세개의 디폴트 ALC's 는 동일 기본 파일 속성으로 정의 및 동작한다. 즉,

$OTHER, $GROUP, $USER 이다.

유닉스에서 파일 시스템은 모두 세게의 이러한 속성 ALC's가 사용된다. 그러나, NT, FAT 및 NetWare 가 기본 파일 속성에 대해서 $OTHER만을 사용한다. ALC's 소자 데이터내의 임의의 다른 이름이 하나의 이름으로서 해석된다.

ALC 및 속성 플래그

문자	적요	정의
R	읽기	파일의 데이터, 속성, 소유주, 및 허가를 표시한다
W	쓰기	파일에 쓰기, 파일에 덧붙이기
X	실행	파일을 실행(그것이 프로그램이거나 당신이 필요한 허가를 받는 것과 연관된 프로그램을 갖으면)
H	은폐	은폐 파일
S	시스템	시스템 파일
M	수정	읽기, 쓰기, 수정, 실행, 및 파일의 속성을 변경
A	아카이브	파일이 아카이브를 위해 준비됨

소프트 패키지 - 롤백

이 예는 전술된 백업으로 간단한 파일 복사를 롤백한다. 에이전트는 SOFTPKG 소자 태그내에 속성 GX:Rollgack="Y"로부터의 롤백을 나타낸다. GX:Source 소자 태그는 공급되지 않는다.

목적지 MUST는 백업을 복구하는 파일 이름을 포함한다.(주: 백업 파일이 롤백 전에 존재하지 않으면 에러가 아니다(목적지는 패키지가 분산되었을 때 존재하지 않을 수 있다). 그러나, 목적지 파일이 존재하고 롤백 전에 삭제될 수 없으면 에러이다).

ProxyGet

때때로 에이전트는 호스트 사이트에 억세스하도록 허용되기만 하는 구성으로 방화벽 뒤에 설치될 수 있다. 에이전트는 벤더의 사이트에 놓인 패키지에 대한 방법을 검색하고자 시도할 때 이 경우를 검출한다. 에이전트가 표준 HTTP과 통신을 설정할 수 없음을 깨달을 때, 후술되듯이 'ProxyGet' 요청을 이용하여 에이전트를 위한 파일을 검색하도록 호스트에 요청한다.

Bandwidth Utilization

Range specified Get Request:

HTTP/1.1은 클라이언트가 응답 엔티티의 일부만(한 범위)이 응답에 포함될 수 있음을 요청하게 한다. HTTP/1.1은 Range 및 ContentRange 헤더 필드내의 범위 유닛을 사용한다. 엔티티는 여러 구조 유닛에 따라서 서브범위로 나누어질 수 있다.

range-unit = bytes-unit ｜ other-range-unit

bytes-unit = "bytes"

other-range-unit = token

HTTP/1.1에 의해서 정의되는 범위 유닛만이 "bytes"이다. HTTP/1.1 실행예는 다른 유닛을 이용하여 규정되는 범위를 무시한다. HTTP/1.1은 범위의 지식에 의존하지 않는 어플리케이션의 실행예를 허용하도록 설계되었다.

모든 HTTP 엔티티가 바이트의 열로서 HTTP 메시지로 표시되므로, 바이트 범위의 개념은 임의의 HTTP 엔티티에 대해서 의미를 갖는다.

HTTP내의 바이트 범위 명세는 엔티티 바디(메시지-바디와 반드시 같을 필요는 없다)내의 바이트 열에 적용된다. 바이트 범위 동작은 바이트의 단일 범위 또는 단일 엔티티내의 일련의 범위를 규정할 수 있다.

관리자가 대역폭 활용 특성을 선택하였을 때, 그것들을 에이전트의 정책 데이터내로 규정함으로서, 에이전트는 단순한 Get 요청이 아니고 "Range" 규정된 Get을 요청한다.

다음 에이전트 프로파일을 고려:

다음은 Q12345.Exe 파일의 제 1의 1024바이트에 대한 요청 및 호스트의 응답을 도시한다.

Response XML Elements

요소	POLICY
속성	IntervalType - 시간 주기의 유형 ㆍ S=초 ㆍ M=분 ㆍ H=시간Interval- 에이전트가 Tasklist에 대한 홋트를 점검해야 하는 시간 주기의 수Start -에이전트가 수행해야 할 작업에 대해 실행 및 점검을 시작해야 할 날짜(GMT)Stop-에이전트가 수행해야 할 작업에 대해실행 및 점검을 정지해야 할 날짜(GMT)Retries-Backoff 량을 적용하기 전에 요청을 리트라이할 시간의 량BackOff-호스트에 실패한 접촉 후에 간격에 부가되는 IntervalType 시간의 량. 이는 퍼센트 부호(%)를 첨부하므로 퍼센티지로서 표현될 수 있다. UDPPort-{nnn}에이전트를 깨우는데 사용되는 UDP 포트 수.TCPPort-{nnn} 에이전트를 깨우는데 사용되는 TCP 포트 수.TraceLevel -OFF =0, INFO =1, DETAILED =2, DEBUG =3PurgeIntervalType -시간 주기의 유형(IntervalType 참조)PurgeInterval - 에이전트가 백업을 스캔해야하며 퍼지 간격보다 더 오래된 시간의 퍼지를 스캔해야 하는 시간 주기의 수(PurgeIntervalType).
-의 차일드	TASKLIST
-의 페이런트
요소	TASK
속성	TaskID - 고유의 태스크 식별자PkgID - 동작되어야 할 패키지 식별자
-의 차일드	TASKLISK
-의 페어런트

Discovery Agent XML tags

<name>tag - 이것은 당신이 검색하고자 하는 파일의 이름이다.

ㆍ <path>tag - Very versatile. 이것은 당신이 파일을 검색하고자 하는 경로이다.

<Version>tag - 이것은 당신이 찾고자 하는 파일의 버전이다.

<created>tag - 이것은 파일이 생성된 날짜이다.

예 <version>> 5/20/2001 12:01:04 PM </version>

주의: 이 정확한 날짜 포맷이 바람직하다.

<Size>tag - 이것은 당신이 찾고있는 파일의 크기이다. 주의: Cannot due <or>

<root>tag - 이것은 등록 엔트리를 찾기 위한 루트 키이다.

<Key>tag - 이것은 당신이 찾고 있는 등록내의 키이다.

<value>tag - 이것은 당신이 찾고 있는 키 내의 값이다.

<Data>tag - 이것은 그 키에서 찾을 것으로 기대하는 날짜이다.

<class>tag - 당신은 감지하는 임의의 유효 WMI 클래스를 규정할 수 있다. example win32_service

<searchfield> - 이것은 어떤 wmi 엔트리를 보아야 하는지를 최적으로 판단하는 필드이다.

<searchvalue> - 이것은 어떤 wmi 엔트리를 보아야 하는지를 최적으로 판단하는 값이다.

<checkfield> - 이것은 당신이 얻고자 하는 값을 얻기 위해 보아야 하는 필드이다.

<checkvalue> - 이것은 당신이 찾고자 하는 값이다.

입력 파일의 <registry> 섹션의 예

Patch Fingerprint Signature example

위의 예는 등록으로 부터 아웃룩 경로를 찾고 이어서 그 크기를 유효하게 한다.

저작권 공지

본 특허 문서의 개시부는 저작권이 보호되는 자료를 포함하고 있다. 저작권자는 특허 및 상표청 특허 파일 또는 문서에서 볼 수 있는 바와 같이 특허 문서 또는 특허 개시 중 어느 것에 의해서 복사 재생하는 것에는 이의가 없으나, 그 경우가 아니면 모두 저작권을 확보해 두고 있다.

Claims (62)

1. 네트워크 상에서 프리-업데이트 상태의 업데이트 서버에 접속되는 넌-업데이트 상태의 제 1 타겟 컴퓨터를 갖는 시스템에서 소프트웨어를 업데이트하기 위한 자동화된 방법으로서, 상기 시스템은 제 1 타겟 컴퓨터에 인억세스될 수 있으며 상기 업데이트 서버에 억세스되는 패키지 컴퓨터, 및 상기 제 1 타겟 컴퓨터 및 상기 업데이트 서버에 억세스가능한 저장소 구성요소를 갖는, 자동화된 방법에 있어서,

   특정 소프트웨어 업데이트를 정의하는 적어도 하나의 패치 지문을 상기 저장소 구성요소로 넣는 단계;

   상기 제 1 타겟 컴퓨터에 대한 정보를 모으는 단계;

   상기 특정 소프트웨어 업데이트가 상기 타겟 컴퓨터에 존재하지 않는지를 판단하기 위해서 상기 모아진 정보의 적어도 일부분을 상기 패치 지문과 비교하는 단계;

   적어도 하나의 태스크 식별자를 업데이트 태스크 리스트에 놓는 단계로서, 상기 태스크 식별자는 상기 제 1 타겟 컴퓨터를 규정하며, 상기 태스크 식별자는 또한 상기 제 1 타겟 컴퓨터에 대해서 소프트웨어 업데이트를 포함하는 패키지 컴퓨터상의 한 장소를 참조하는 적어도 하나의 다운로드 어드레스를 규정하는 단계;

   상기 태스크 식별자에 응답하여, 상기 소프트웨어 업데이트를 상기 패키지 컴퓨터로 부터 상기 업데이트 서버로 다운로딩하는 단계; 및

   상기 업데이트 서버로부터 상기 제 1 타겟 컴퓨터로 상기 소프트웨어 업데이트의 제 2 다운로드를 수행하는 단계를 포함하는 자동화된 방법.
2. 제 1 항에 있어서,

   이동이 가능하며 복수의 네트워크내의 업데이트 서버들에서 패치를 복제하기 위해서 채용될 수 있는 패치 정의를 제공하는 단계를 더 포함하는 것을 특징으로 하는 자동화된 방법.
3. 제 1 항에 있어서,

   상기 방법은 상기 다운로드 단계들을 수행하기 위한 고속 관리자 명령을 요구하지 않고도 상기 다운로드 단계들을 수행함으로서 순향적으로 동작하는 것을 특징으로 하는 자동화된 방법.
4. 제 1 항에 있어서,

   상기 방법은 타겟 컴퓨터에 상기 패치를 배치하기 전에 상기 업데이트 서버에 마크된 패치를 저장함으로서 순향적으로 동작하며, 상기 패치는 적어도 하나의 임계의, 높은 순위의 그리고 보안 관련으로 마크되는 것을 특징으로 하는 자동화된 방법.
5. 제 1 항에 있어서,

   패치 다운로드의 보안을 위해서 암호화를 활용하는 단계; 패치 다운로드의 보안을 위해서 주기적인 리던던시 코드들을 활용하는 단계; 패치 다운로드의 보안을 위해서 디지털 서명을 활용하는 단계; 패치 다운로드의 보안을 위해서 SSL과 같은 보안 네트워크 프로토콜을 활용하는 단계로 이루어진 보안 단계 그룹중 적어도 두개의 단계를 더 포함하며, 여기서 적어도 하나의 보안 단계는 특별한 방법 실시예에서 사용되는 것을 특징으로 하는 자동화된 방법.
6. 제 1 항에 있어서,

   상기 업데이트 서버로 부터 상기 제 1 타겟 컴퓨터로 소프트웨어 업데이트를 다운로드하는 단계는 배경 다운로딩 프로세스를 이용하여 수행되며, 따라서 상기 제 1 타겟 컴퓨터의 사용자에 대한 불편을 감소시키는 것을 특징으로 하는 자동화된 방법.
7. 제 1 항에 있어서,

   상기 업데이트 서버로 부터 상기 제 1 타겟 컴퓨터로 상기 소프트웨어 업데이트를 다운로딩하는 단계는 대역폭 드로틀된 다운로딩을 이용하여 수행되며, 따라서 네트워크 관리자가 대규모 배치 동안에 대역폭이 채용되어야 하는 방법을 결정하도록 하는 것을 특징으로 하는 자동화된 방법.
8. 제 1 항에 있어서,

   다운로딩은 동작 시간을 제한하는 정책에 종속되도록 수행되며, 상기 정책은 관리자에 의해서 설정되며, 따라서 상기 관리자가 패치 배치가 발생되는 때를 결정하도록 하는 것을 특징으로 하는 자동화된 방법.
9. 제 1 항에 있어서,

   상기 업데이트로부터 상기 패키지 컴퓨터로 소프트웨어 업데이트의 다운로드를 방지하여, 상기 패키지 컴퓨터의 보안을 향샹시키는 단계를 더 포함하는 것을 특징으로 하는 자동화된 방법.
10. 제 1 항에 있어서,

    상기 방법은, 관리자가 다른 경우에 요구될 수 있는 것보다 적은 리부트로 타겟 컴퓨터상에 설치되는 다운로드된 패치를 갖도록 하는 연쇄 설치 특징의 사용을 더 포함하는 것을 특징으로 하는 자동화된 방법.
11. 제 1 항에 있어서,

    상기 방법은 다운로딩 단계의 인터럽트를 검출하고 재접속후에 상기 인터럽션이 발생된 다운로딩 단계에서 상기 포인트에 또는 상기 포인트 근방으로부터 다운로딩 단계를 재개하는 다운로딩 재개 특징을 이용하여, 상기 다운로드를 수행하기 위한 전체 다운로딩 단계를 반복하는 것을 피하게 되는, 단계를 더 포함하는 것을 특징으로 하는 자동화된 방법.
12. 제 1 항에 있어서,

    상기 방법은, 상기 태스크 식별자 배치 단계가 발생될 때 상기 제 1 타겟 컴퓨터가 상기 네트워크에 접속되지 않는다 할지라도 관리자가 패치를 상기 제 1 타겟 컴퓨터에 배치하도록 하는 이동 사용자 지원 특징의 사용을 더 포함하는 것을 특징으로 하는 자동화된 방법.
13. 제 1 항에 있어서,

    상기 방법은 다중 벤더들로 부터 나오는 다중 패치를 다운로딩하는 단계를 포함하는 것을 특징으로 하는 자동화된 방법.
14. 제 1 항에 있어서,

    상기 방법은 하나의 그룹을 형성하기 위해 적당한 서브세트의 타겟 컴퓨터를 그룹핑하는 단계로서, 개별 타겟 컴퓨터에 적용가능한 동작이 상기 그룹에 적용될 수 있도록 하는 단계를 더 포함하는 것을 특징으로 하는 자동화된 방법.
15. 제 14 항에 있어서,

    상기 그룹핑 단계는 관리자에 의해서 규정되는 타겟 컴퓨터를 포함하는 그룹을 형성하는 것을 특징으로 하는 자동화된 방법.
16. 제 14 항에 있어서,

    상기 그룹핑 단계는 비-관리 사용자에 의해서 규정되는 타겟 컴퓨터를 포함하는 그룹을 형성하는 것을 특징으로 하는 자동화된 방법.
17. 제 14 항에 있어서,

    상기 그룹핑 단계는, 상기 그룹에 배치되는 모든 타겟 컴퓨터에 의해서 사용되는 어플리케이션 프로그램을 식별하므로서 규정되는 타겟 컴퓨터를 포함하는 그룹을 형성하는 것을 특징으로 하는 자동화된 방법.
18. 제 14 항에 있어서,

    상기 그룹핑 단계는, 상기 그룹에 배치되는 모든 타겟 컴퓨터에 의해서 사용되는 어플리케이션 프로그램을 식별하므로서 규정되는 타겟 컴퓨터를 포함하는 그룹을 형성하는 것을 특징으로 하는 자동화된 방법.
19. 제 14 항에 있어서,

    상기 방법은 그룹 매니저에 제한된 관리 제어를 위임하여, 상기 그룹핑 단계에 의해서 상기 그룹에 배치된 타겟 컴퓨터에서 상기 그룹 매니저가 제어를 받는 단계를 더 포함하는 것을 특징으로 하는 자동화된 방법.
20. 제 1 항에 있어서,

    상기 방법은 상기 제 1 타겟 컴퓨터에 설치되어야 하는 적어도 일부 소프트웨어를 규정하는 위임 패치 베이스라인 정책의 사용을 더 포함하며, 상기 방법은 상기 제 1 타겟 컴퓨터상에 위임 패치 베이스라인 정책에 규정되는 패치를 순향적으로 다운로드 및 설치하는 것을 특징으로 하는 자동화된 방법.
21. 제 20 항에 있어서,

    상기 위임 패치 베이스라인 정책은 특별한 어플리케이션을 사용하는 타겟 컴퓨터에 대해 베이스라인을 설정하는 것을 특징으로 하는 자동화된 방법.
22. 제 20 항에 있어서,

    상기 위임 패치 베이스라인 정책은 타겟 컴퓨터로부터 바라지 않은 소프트웨어의 제거를 위임하는 것을 특징으로 하는 자동화된 방법.
23. 제 1 항에 있어서,

    상기 방법은 상기 제 1 타겟 컴퓨터에 설치되면 않되는 소프트웨어를 규정하는 금지된 패치 특징의 사용을 더 포함하며, 상기 방법은 그러한 설치가 발생되는 것을 방지하도록 시도하는 것을 특징으로 하는 자동화된 방법.
24. 제 20 항에 있어서,

    상기 방법은, 상기 패치내의 소프트웨어가 상기 위임 패치 베이스라인 정책에 종속되는 타겟 컴퓨터로 부터 떨어진 후에 상기 위임 패치 베이스라인 정책에서 규정되는 패치를 자동으로 재설치하는 것을 더 포함하는 것을 특징으로 하는 자동화된 방법.
25. 제 1 항에 있어서,

    상기 방법은, 하나의 그룹을 형성하기 위해 적당한 서브세트의 타겟 컴퓨터를 그룹핑하며, 상기 그룹내의 상기 타겟 컴퓨터에 설치되어야 하는 적어도 일부 소프트웨어를 규정하기 위한 위임 패치 베이스라인 정책을 이용하는 단계를 더 포함하는 것을 특징으로 하는 자동화된 방법.
26. 제 1 항에 있어서,

    상기 방법은 상기 제 1 타겟 컴퓨터상에서 록크되는 소프트웨어를 규정하는 패치 승락 확신 특징의 사용을 더 포함하며, 상기 방법은 상기 제 1 타겟 컴퓨터로부터 록크된 소프트웨어가 제거되면 순향적으로 관리자에게 통지하는 것을 특징으로 하는 자동화된 방법.
27. 제 1 항에 있어서,

    상기 방법은 상기 타겟 컴퓨터에서 록크되는 적어도 하나의 아이템을 규정하는 변경 제어 특징의 사용을 더 포함하며, 상기 방법은 상기 타겟 컴퓨터에서 록크된 아이템이 변경되면 순향적으로 관리자에게 통지하며, 여기서 상기 아이템은 하드웨어 아이템, 서비스 아이템, 및 소프트웨어 아이템 중 적어도 하나인 것을 특징으로 하는 자동화된 방법.
28. 제 1 항에 있어서,

    상기 업데이트 서버로부터 상기 제 1 타겟 컴퓨터로 상기 소프트웨어 업데이트를 적어도 다운로딩하는 단계가 순환되어, 적어도 상기 제 1 타겟 컴퓨터상의 특별한 파일을 반복적으로 업데이트하는 것을 특징으로 하는 자동화된 방법.
29. 제 1 항에 있어서,

    재난 복구 단계로 된 그룹으로 부터 적어도 하나의 단계를 더 포함하며, 상기 단계는 시스템 실패후에 관리자가 동작을 복구하고 계속하게 하며, 여기서 재난 복구 단계의 그룹은, 실패된 서버와 동일한 도메인 이름을 갖는 또 다른 서버를 생성하며, 서버상에 업데이트 서버 소프트웨어를 재설치하며, 아카이브된 데이터를 재저장하며, 미러된 데이터를 재저장하는 단계를 포함하며, 여기서 적어도 하나의 재난 복구 단계는 특별한 방법 실시예에서 사용가능한 것을 특징으로 하는 자동화된 방법.
30. 제 1 항에 있어서,

    최근 동작 기록을 유지하며, 패치의 배치를 롤링 백하는 단계를 더 포함하여, 관리자가 문제를 일으킨 타겟 컴퓨터 패치 설치를 취소하도록 하는 것을 특징으로 하는 자동화된 방법.
31. 제 1 항에 있어서,

    상기 방법은, 패치를 타겟 컴퓨터 운영체제에 매치시키는 지능형 다중 패치 배치 특징의 사용을 더 포함하여, 관리자에게 상기 타겟 컴퓨터에서 사용되는 운영체제를 고속으로 그리고 완전히 식별할 필요성을 경감시키는 것을 특징으로 하는 자동화된 방법.
32. 제 1 항에 있어서,

    상기 방법은 상기 제 1 타겟 컴퓨터상에 보안 패치를 설치하여, 상기 타겟 컴퓨터의 파일 시스템으로 훅하고 적어도 하나의 특정 파일이 상기 타겟 컴퓨터상에서 실행되는 것을 중지시키기 위해서 정책 구동 방법을 관리자에게 제공하는 것을 특징으로 하는 자동화된 방법.
33. 컴퓨터 시스템의 적어도 일부가 시스템에서 소프트웨어를 업데이트하기 위해서 자동화된 방법의 방법 단계들을 수행하도록 하는 데이터 및 명령을 제공하는 구성을 갖는 구성된 프로그램 저장 매체로서, 상기 시스템은 네트워크 상에서 프리-업데이트 상태로 업데이트 서버에 접속되는 넌-업데이트 상태의 제 1 타겟 컴퓨터를 갖으며, 상기 시스템은 또한, 상기 제 1 타겟 컴퓨터에 인억세스되며 상기 업데이트 서버에 억세스가능한 패키지 컴퓨터와, 상기 제 1 타겟 컴퓨터 및 상기 업데이트 서버에 억세스가능한 저장소 구성요소를 갖는, 구성된 프로그램 저장 매체에 있어서, 상기 방법은,

    특정 소프트웨어 업데이트를 정의하는 적어도 하나의 패치 지문을 상기 저장소 구성요소로 넣는 단계;

    상기 제 1 타겟 컴퓨터에 대한 정보를 모으는 단계;

    상기 특정 소프트웨어 업데이트가 상기 타겟 컴퓨터에 존재하지 않는지를 판단하기 위해서 상기 모아진 정보의 적어도 일부분을 상기 패치 지문과 비교하는 단계;

    적어도 하나의 태스크 식별자를 업데이트 태스크 리스트에 놓는 단계로서, 상기 태스크 식별자는 상기 제 1 타겟 컴퓨터를 규정하며, 상기 태스크 식별자는 또한 상기 제 1 타겟 컴퓨터에 대해서 소프트웨어 업데이트를 포함하는 패키지 컴퓨터상의 한 장소를 참조하는 적어도 하나의 다운로드 어드레스를 규정하는 단계;

    상기 태스크 식별자에 응답하여, 상기 소프트웨어 업데이트를 상기 패키지 컴퓨터로 부터 상기 업데이트 서버로 다운로딩하는 단계; 및

    상기 업데이트 서버로부터 상기 제 1 타겟 컴퓨터로 상기 소프트웨어 업데이트의 제 2 다운로드를 수행하는 단계를 포함하는 구성된 저장 매체.
34. 제 33 항에 있어서,

    이동이 가능하며 복수의 네트워크내의 업데이트 서버들에서 패치를 복제하기 위해서 채용될 수 있는 패치 정의를 제공하는 단계를 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
35. 제 33 항에 있어서,

    상기 방법은 상기 다운로드 단계들을 수행하기 위한 고속 관리자 명령을 요구하지 않고도 상기 다운로드 단계들을 수행함으로서 순향적으로 동작하는 것을 특징으로 하는 구성된 저장 매체.
36. 제 33 항에 있어서,

    상기 방법은 타겟 컴퓨터에 상기 패치를 배치하기 전에 상기 업데이트 서버에 마크된 패치를 저장함으로서 순향적으로 동작하며, 상기 패치는 적어도 하나의 임계의, 높은 순위의 그리고 보안 관련으로 마크되는 것을 특징으로 하는 구성된 저장 매체.
37. 제 33 항에 있어서,

    패치 다운로드의 보안을 위해서 암호화를 활용하는 단계; 패치 다운로드의 보안을 위해서 주기적인 리던던시 코드들을 활용하는 단계; 패치 다운로드의 보안을 위해서 디지털 서명을 활용하는 단계; 패치 다운로드의 보안을 위해서 SSL과 같은 보안 네트워크 프로토콜을 활용하는 단계로 이루어진 보안 단계 그룹중 적어도 두개의 단계를 더 포함하며, 여기서 적어도 하나의 보안 단계는 특별한 방법 실시예에서 사용되는 것을 특징으로 하는 구성된 저장 매체.
38. 제 33 항에 있어서,

    상기 업데이트 서버로 부터 상기 제 1 타겟 컴퓨터로 소프트웨어 업데이트를 다운로드하는 단계는 배경 다운로딩 프로세스를 이용하여 수행되며, 따라서 상기 제 1 타겟 컴퓨터의 사용자에 대한 불편을 감소시키는 것을 특징으로 하는 구성된 저장 매체.
39. 제 33 항에 있어서,

    상기 업데이트 서버로 부터 상기 제 1 타겟 컴퓨터로 상기 소프트웨어 업데이트를 다운로딩하는 단계는 대역폭 드로틀된 다운로딩을 이용하여 수행되며, 따라서 네트워크 관리자가 대규모 배치 동안에 대역폭이 채용되어야 하는 방법을 결정하도록 하는 것을 특징으로 하는 구성된 저장 매체.
40. 제 33 항에 있어서,

    다운로딩은 동작 시간을 제한하는 정책에 종속되도록 수행되며, 상기 정책은 관리자에 의해서 설정되며, 따라서 상기 관리자가 패치 배치가 발생되는 때를 결정하도록 하는 것을 특징으로 하는 구성된 저장 매체.
41. 제 33 항에 있어서,

    상기 업데이트로부터 상기 패키지 컴퓨터로 소프트웨어 업데이트의 다운로드를 방지하여, 상기 패키지 컴퓨터의 보안을 향샹시키는 단계를 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
42. 제 33 항에 있어서,

    상기 방법은, 관리자가 다른 경우에 요구될 수 있는 것보다 적은 리부트로 타겟 컴퓨터상에 설치되는 다운로드된 패치를 갖도록 하는 연쇄 설치 특징의 사용을 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
43. 제 33 항에 있어서,

    상기 방법은 다운로딩 단계의 인터럽트를 검출하고 재접속후에 상기 인터럽션이 발생된 다운로딩 단계에서 상기 포인트에 또는 상기 포인트 근방으로부터 다운로딩 단계를 재개하는 다운로딩 재개 특징을 이용하여, 상기 다운로드를 수행하기 위한 전체 다운로딩 단계를 반복하는 것을 피하게 되는, 단계를 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
44. 제 33 항에 있어서,

    상기 방법은, 상기 태스크 식별자 배치 단계가 발생될 때 상기 제 1 타겟 컴퓨터가 상기 네트워크에 접속되지 않는다 할지라도 관리자가 패치를 상기 제 1 타겟 컴퓨터에 배치하도록 하는 이동 사용자 지원 특징의 사용을 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
45. 제 33 항에 있어서,

    상기 방법은 다중 벤더들로 부터 나오는 다중 패치를 다운로딩하는 단계를 포함하는 것을 특징으로 하는 구성된 저장 매체.
46. 제 33 항에 있어서,

    상기 방법은 하나의 그룹을 형성하기 위해 적당한 서브세트의 타겟 컴퓨터를 그룹핑하는 단계로서, 개별 타겟 컴퓨터에 적용가능한 동작이 상기 그룹에 적용될 수 있도록 하는 단계를 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
47. 제 46 항에 있어서,

    상기 그룹핑 단계는 관리자에 의해서 규정되는 타겟 컴퓨터를 포함하는 그룹을 형성하는 것을 특징으로 하는 구성된 저장 매체.
48. 제 46 항에 있어서,

    상기 그룹핑 단계는 비-관리 사용자에 의해서 규정되는 타겟 컴퓨터를 포함하는 그룹을 형성하는 것을 특징으로 하는 구성된 저장 매체.
49. 제 46 항에 있어서,

    상기 그룹핑 단계는, 상기 그룹에 배치되는 모든 타겟 컴퓨터에 의해서 사용되는 어플리케이션 프로그램을 식별하므로서 규정되는 타겟 컴퓨터를 포함하는 그룹을 형성하는 것을 특징으로 하는 구성된 저장 매체.
50. 제 46 항에 있어서,

    상기 그룹핑 단계는, 상기 그룹에 배치되는 모든 타겟 컴퓨터에 의해서 사용되는 어플리케이션 프로그램을 식별하므로서 규정되는 타겟 컴퓨터를 포함하는 그룹을 형성하는 것을 특징으로 하는 구성된 저장 매체.
51. 제 46 항에 있어서,

    상기 방법은 그룹 매니저에 제한된 관리 제어를 위임하여, 상기 그룹핑 단계에 의해서 상기 그룹에 배치된 타겟 컴퓨터에서 상기 그룹 매니저가 제어를 받는 단계를 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
52. 제 33 항에 있어서,

    상기 방법은 상기 제 1 타겟 컴퓨터에 설치되어야 하는 적어도 일부 소프트웨어를 규정하는 위임 패치 베이스라인 정책의 사용을 더 포함하며, 상기 방법은 상기 제 1 타겟 컴퓨터상에 위임 패치 베이스라인 정책에 규정되는 패치를 순향적으로 다운로드 및 설치하는 것을 특징으로 하는 구성된 저장 매체.
53. 제 52 항에 있어서,

    상기 위임 패치 베이스라인 정책은 특별한 어플리케이션을 사용하는 타겟 컴퓨터에 대해 베이스라인을 설정하는 것을 특징으로 하는 구성된 저장 매체.
54. 제 52 항에 있어서,

    상기 방법은, 상기 패치내의 소프트웨어가 상기 위임 패치 베이스라인 정책에 종속되는 타겟 컴퓨터로 부터 떨어진 후에 상기 위임 패치 베이스라인 정책에서 규정되는 패치를 자동으로 재설치하는 것을 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
55. 제 33 항에 있어서,

    상기 방법은, 하나의 그룹을 형성하기 위해 적당한 서브세트의 타겟 컴퓨터를 그룹핑하며, 상기 그룹내의 상기 타겟 컴퓨터에 설치되어야 하는 적어도 일부 소프트웨어를 규정하기 위한 위임 패치 베이스라인 정책을 이용하는 단계를 더 포함하는 것을 특징으로 하는 구성된 저장 매체.
56. 제 33 항에 있어서,

    상기 방법은 상기 제 1 타겟 컴퓨터상에서 록크되는 소프트웨어를 규정하는 패치 승락 확신 특징의 사용을 더 포함하며, 상기 방법은 상기 제 1 타겟 컴퓨터로부터 록크된 소프트웨어가 제거되면 순향적으로 관리자에게 통지하는 것을 특징으로 하는 구성된 저장 매체.
57. 제 33 항에 있어서,

    상기 방법은 상기 타겟 컴퓨터에서 록크되는 적어도 하나의 아이템을 규정하는 변경 제어 특징의 사용을 더 포함하며, 상기 방법은 상기 타겟 컴퓨터에서 록크된 아이템이 변경되면 순향적으로 관리자에게 통지하며, 여기서 상기 아이템은 하드웨어 아이템, 서비스 아이템, 및 소프트웨어 아이템 중 적어도 하나인 것을 특징으로 하는 구성된 저장 매체.
58. 제 33 항에 있어서,

    상기 업데이트 서버로부터 상기 제 1 타겟 컴퓨터로 상기 소프트웨어 업데이트를 적어도 다운로딩하는 단계가 순환되어, 적어도 상기 제 1 타겟 컴퓨터상의 특별한 파일을 반복적으로 업데이트하는 것을 특징으로 하는 구성된 저장 매체.
59. 제 33 항에 있어서,

    재난 복구 단계로 된 그룹으로 부터 적어도 하나의 단계를 더 포함하며, 상기 단계는 시스템 실패후에 관리자가 동작을 복구하고 계속하게 하며, 여기서 재난 복구 단계의 그룹은, 실패된 서버와 동일한 도메인 이름을 갖는 또 다른 서버를 생성하며, 서버상에 업데이트 서버 소프트웨어를 재설치하며, 아카이브된 데이터를 재저장하며, 미러된 데이터를 재저장하는 단계를 포함하며, 여기서 적어도 하나의 재난 복구 단계는 특별한 방법 실시예에서 사용가능한 것을 특징으로 하는 구성된 저장 매체.
60. 제 33 항에 있어서,

    최근 동작 기록을 유지하며, 패치의 배치를 롤링 백하는 단계를 더 포함하여, 관리자가 문제를 일으킨 타겟 컴퓨터 패치 설치를 취소하도록 하는 것을 특징으로 하는 구성된 저장 매체.
61. 제 33 항에 있어서,

    상기 방법은, 패치를 타겟 컴퓨터 운영체제에 매치시키는 지능형 다중 패치 배치 특징의 사용을 더 포함하여, 관리자에게 상기 타겟 컴퓨터에서 사용되는 운영체제를 고속으로 그리고 완전히 식별할 필요성을 경감시키는 것을 특징으로 하는 구성된 저장 매체.
62. 제 33 항에 있어서,

    상기 방법은 상기 제 1 타겟 컴퓨터상에 보안 패치를 설치하여, 상기 타겟 컴퓨터의 파일 시스템으로 훅하고 적어도 하나의 특정 파일이 상기 타겟 컴퓨터상에서 실행되는 것을 중지시키기 위해서 정책 구동 방법을 관리자에게 제공하는 것을 특징으로 하는 구성된 저장 매체.