Be The Blogger : 전산병의 근무일지

1. 디비를 완전 wipe하고 All Computers를 눌러도
 Error : Unexpected Error
An unexpected error occurred. Please contact your system administrator if the problem persists.

Click Reset Server Node to try to connect to the server again.

이 메시지가 나오는 것은 결국 해결 못함.
mmc로 콘솔 띄우는 것만이 방법인듯 함


2. KB 업데이트 KB2720211과 KB2734608을 동시에 다 해야 2012 R2, 8.1이 다운로드가 가능해지는 것 같다. 지금까지 이 방법대로 안하고 뻘짓을 했으니 한심하다.

관련링크


3. 물론 저 위의 두 KB를 설치하면 Server version이 3.2.7600.256으로 올라가나, Help- About Update Services를 누르면 거기서는 Version이 계속해서 3.2.7600.226이라 나오더라. 이 문제로 머리 많이 싸매고 고민했는데 그냥 버그인걸로 결론 내렸다...


4.  결국 windows 2012 R2는 Windows 6.3으로 표기되는 문제는 해결 못 함. 그것도 원래 그런걸로 결론 내렸다...

이로서 기능적으로 안되는 것은 없는 WSUS 복구기를 마친다.

해도 해도 해결되지 않는 WSUS 이슈 해결 언제 끝나나

금일중점은 KB2720211이 지워지지 않아서 KB2720211이 아닌 프로그램 및 기능에서 Windows Server Update Services 3.0 SP2를 지웠다. 그랬더니 지워지지 않던 업데이트 관련 KB도 삭제 되는 것을 확인했다.

그렇게 KB가 삭제되니 완전히 서버에서 WSUS가 제거가 되는 것을 확인했다. 그리고 다시 재설치를 한 후, KB2720211을 재설치 했다. 그러나 결과는 역시나, 3.2.7600.226에서 버전업이 되지 않는다.

완전히 wipe한다는 생각으로 2012 이전 버전의 WID(Windows Internal Database, MICROSOFT##SSEE)를 삭제하려고 하였다.

여기나온대로삭제시도함

그러나 수동으로 sc delete mssql$microsoft##ssee 를 한 결과
WID가 깨져서 WSUS 재설치가 되지를 않는다 ㅠㅠ


고민을 하다 답글 중 다음의 도움을 얻어 SSEE를 완전히 삭제할 수 있었다.

If you are running an x64-based edition of Windows Server, use the following command line to remove Windows Internal Database from the computer:

msiexec /x {BDD79957-5801-4A2D-B09E-852E7FA64D01} CALLERID=ocsetup.exe

해당 명령으로 WID 날리니까 다시 설치가 된다!
다시 설치를 클린하게 했다고 생각했는데, All Computers 누르면 또 Error가 발생하는 상황, 그냥 mmc콘솔로 띄워서 사용하고있다.

WSUS를 고치려고 하다 보니 고생이 많다.

2008 R2의 WSUS가 문제가 있어서 뭉개고 다시 설치하였더니, 버전이 3.2.7600.226으로 내려가버리고 만 것이었다...

분명 2012지원을 위해서 KB2720211을 설치하였는데, 설치를 하고, WSUS를 뭉개고 다시 설치하면, KB2720211은 설치가 되어있는 채로, 그것 이전버전으로 WSUS가 올라온다.

다시 말하면 KB2720211설치 -> 3.2.7600.256버전으로 되어 2012 기종 업데이트 지원이 가능해짐 -> 그 상태에서 WSUS 재설치 -> 3.2.7600.226 버전으로 다운그레이드 됨 -> KB2720211은 그대로 설치되어 삭제가 안됨

버전은 다음과 같다고 한다.
WSUS 3.0 (SP2):     Build 3.2.7600.226
 WSUS 3.0 (SP2) + KB2720211:     Build 3.2.7600.251
 WSUS 3.0 (SP2) + KB2734608:     Build 3.2.7600.256
 WSUS 3.0 (SP2) + KB2828185:     Build 3.2.7600.262
 WSUS 3.0 (SP2) + KB2938066:     Build 3.2.7600.274

출처


하지만 재설치 시도를 해도 소용이 없었다. 그래서 상위버전인 2734608을 설치해 보아도 소용이 없다. 계속 WSUS버전은 7600.226으로 나온다.



I thought I'd post the actual steps in here because it solved my problem Thanks so much! (Make sure you restart your server before attempting to install the KB272011 standalone in the last step! It didn't work for me until I restarted!)

Cause:

- Applied KB2720211 to a WSUS 3.0 SP2 server thats running on Windows 2008 64 bit server with local SQL db.

What happened:

- I could no longer sync my WSUS server with the interwebs.
- clients could still connect to WSUS and I could still open the WSUS console.
- Uninstalled WSUS, left DB and downloads and reinstalled WSUS in attempt to fix broken syncing.
- Clients could now no longer sync with WSUS server. (They got Windows Update error code 800B0001).

Solution:

- Googled, found this page.
- Followed just these last few steps that Chucker2 posted.

    Extract necessary files from 2720211 installer

    Download the KB2720211 installer for your architecture from Microsoft (http://support.microsoft.com/kb/2720211)
    Extract WUSSetup.msp from the installer by running the installer with the /extract parameter (example: "WSUS-KB2720211-x64.exe /extract")
    With 7-zip, open WUSSetup.msp and extract "PCW_CAB_SUS".
    With 7-zip, open "PCW_CAB_SUS" and extract "DbCert", "DbCertDll", and "DbCertSql".
    Rename those files to "WSUSSignDb.cer", "WSUSSignDb.dll", and "WSUSSignDb.sql", respectively.
    On your WSUS server, navigate to "C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig" and copy the extracted "WSUSSignDb.cer" and "WSUSSignDb.dll" to it. Make a backup copy of the two existing versions, just in case.
    On your WSUS server, navigate to "C:\Program Files\Update Services\Database" and copy the extracted "WSUSSignDb.sql" to it. Make a backup copy of any existing versions of the file.
    Reinstalled 2720211

PROBLEM FIXED AND CLIENTS COULD ALL SYNCH AGAIN.

Thanks Chucker 2.


이거대로 해도 안된다 ㅡㅡ
출처

나는 WSUS를 다시 한 번 뭉개기로 했다.

두 번째 포스팅으로 WSUS 재구성에 성공 한 후, 마치 잘 되는것처럼 보였으나, 내가 가진 테스트 클라이언트에서 업데이트를 제대로 받아가지 못하는 것을 발견했다.

문제는 두 가지가 있을 수 있는데
1. 클라이언트쪽에서 오류가 났다.
2. 서버쪽에서 오류가 났다.

먼저 나는 1번은 염두도 안하고 2번쪽으로 의심하기 시작했다. 그래서 서버를 완벽하게 지우는(wipe) 방법을 쓰게 되었다. 관련링크는 아래 참조
How to completely wipe WSUS and start again

시키는대로 파워쉘에서 uninstall 명령을 날리고, WSUS 레포지토리 폴더를 날리고,
제일중요한 C:\Windows\WID\ 폴더를 날려주었다. 그리고 재구성
WID를 안지우고 다시 설치했을 때는 기존 값들이 남아 있어서 찜찜했는데 해당 폴더를 지우니 처음부터 재구성하듯이 메뉴가 뜨더라. 그래서 깔끔히 지워지는 기분을 받았다.


문제는 여기서 끝이 아니었다. 그렇게 구성을 완료했음에도 클라이언트가 새롭게 구성한 WSUS로부터 업데이트 파일을 제대로 받아가지 않는 것.

역시나 해결방법은 클라이언트의 wuauserv 서비스를 중지하고, SoftwareDistribution폴더를 삭제하는 방법이 정답이었다. (SoftwareDistribution 하위의 Download만 지우고 다시 업데이트 시도를 해도 제대로 되지 않음)

SoftwareDistribution폴더를 지우기 전에는 클라이언트에서 DB가 꼬였는지 제대로 다운로드가 되지 않았다. 다운로드 진행률 77%에서 계속 hang이 걸려 있었던 것이다.
하지만 폴더를 지운 후에는 바로 다시 새로운 다운로드 파일을 받았으며, 지금 Installing을 잘 하고 있음을 발견했다.

이상으로 근 몇주간의 고민을 해결한 일지를 마친다. 아직 2018년01월 업데이트가 WSUS에 잘 내려왔는지 모르겠지만...우선 되긴된다!!! 이제 더 이상 문제가 없길 바라며..더 잘 고칠 수 있을까...

지난 번 포트 바인딩 문제로 해결 가능한 줄 모르고

WSUS Role을 내린 후, WSUS Content 가 들어있는 폴더를 삭제해버렸다.

그리고 다시 WSUS Role을 재설치 했지만 이게 웬걸 컴퓨터 정보랑 업데이트 패키지 정보가 그대로 남아있었다.

포트바인딩만 80으로 바꿔준 그 상태에서 업데이트를 진행하니, 클라이언트가 업데이트를 찾아오기는 하나, 업데이트 설치를 누르는 순간 오류가 난다. 왜? 원본 WSUS의 Content를 삭제해 버렸기 때문에...
아무리 synchronization을 수행해도 삭제된 애들이 다시 받아지지 않더라..

이것을 해결하기 위해 구글링을 또 할 수 밖에 없었다.

WSUS컨텐츠재구성하는방법


다음 명령어 한 줄로 깔끔히 해결되었다.

C:\Program Files\Update Services\Tools>WsusUtil.exe RESET

1. WsusContent폴더를 강제로 삭제
2. WSUS Service 서비스를 강제로 내리기
3. 해당 서비스를 다시 시작
4. 위의 명령어를 cmd에서 입력
5. Update Service "Reset Server Node" 수행

그 이후 대시보드에서 한참동안 Synchronization Status가 Loading....인 상태로 hang이 걸린듯 오랫동안 처리해서
퇴근을 하였고
월요일날 와 보니 다시 Reset Server Node를 눌러야 하는 화면으로 대시보드가 바뀌어 있었다.

하지만 Reset Server Node를 누르는 순간, 뭔가 잘 되었다는 느낌을 받을 수 있었고
WsusContent에 다시 파일이 들어와 있었다!

업데이트도 잘 되고 노심초사했던 WSUS를 이렇게 살리게 되었다.

참고로 WSUS Content 폴더를 지웠다가 다시 Role 올리면서 구성되었더니 이 폴더 자체가 공유폴더이고 Everyone권한이 기본 설정인지라, Everyone을 제외시키는 보안조치를 다시금 해야만 했다.

클라이언트가 아무리 WSUS Registry설정을 잘 하고 wuauclt명령어로 계속 컴퓨터의 고유값을 초기화 해 주었음에도 불구하고

모든 컴퓨터는 업데이트 확인을 누르기만 하면 Error발생..

Code 8024401F Windows Update ran into a problem.

이 메시지가 업데이트 확인을 누르자마자 발생할 정도였다.

그리고 WSUS 현황판에는 모든 컴퓨터들이 no status로 감지되었다.

따라서 나는 차라리 갈아엎자는 생각으로 서버 role을 내렸다가 다시 올렸음에도 불구하고 오히려 기존 데이터는 그대로 남아있는 수준이었다..

eventvwr에서 찾아보니 Could not find a base address that matches scheme https for the endpoint with binding BasicHttpBinding. Registered base address schemes are [http]

이 구문을 보고 그대로 구글링 결과
 우연히 발견한 정보로 해결
WSUS 2016 use on port 80

그렇다 여기 나온 대로 바인딩 문제였던 것이다.

나의 WSUS는 80 포트를 사용하게끔 설정이 되어있는데, IIS Manager - WSUS Administration 이라는 Sites의 Bindings에 8530이 http로 binding 되어 있었던 것.

80포트를 중복해서 쓸 수 없으므로, Default Web Site의 80포트를 냉큼 8080으로 바꾸고 Wsus Administration Site에 http를 80으로 추가해 주었다.

그리고 website 재시작 및 서비스에서 WSUS Service 재시작
그 후 클라이언트에서 윈도우 업데이트 돌리니...잘된다!!!

금일 이슈는 KMS OS 인증을 위해서는 라이선스 키를 activation 할 수 있는 PC가 사내에 25대 이상 보유 하고 있어야 하는데 최근 PC 발급 변경 등으로 모수를 유지해주고 있던 애들이 삭제되면서 사이트 내 총 인증가능한 PC의 대수가 25대 밑으로 내려가면서 발생한 이슈이다.

골든이미지에서 이미지를 생성하는 특성상 cmid값이라는 것이 있는데 그 값이 중복되면 MS에서는 모수로 집계를 하지 않는다. 그래서 반드시 rearm이라는 명령을 통해 cmid값을 초기화 하고 리부팅을 해야 서로 다른 PC로 인식하고 모수가 집계된다.

25대 밑으로 내려가자 정품인증 잘 되던 애들도 갑자기 모두 안되기 시작함..
따라서 반드시 25대가 유지될 수 있도록 관리를 해야 한다.

다음은 AD로 내릴 수 있는 스크립트다.

cscript %WINDIR%\system32\slmgr.vbs /skms KMS서버IP:1688
cscript %WINDIR%\system32\slmgr.vbs /ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
cscript %WINDIR%\system32\slmgr.vbs /rearm
cscript %WINDIR%\system32\slmgr.vbs /ato

rearm - 골든 이미지에서 찍어낸 경우 cmid 값을 초기화 해주어야 한다.


관련 문서 : 훗~님의 블로그

#Check Point

while read CheckPoint
do
rm -f -v $L_PATH/$CheckPoint/$(date -d -182days '+%Y-%m-%d')* 2>&1 | tee -a $D_PATH/del-`date +%F`.txt
rm -f -v $S_PATH/$CheckPoint/$(date -d -365days '+%Y-%m-%d')* 2>&1 | tee -a $D_PATH/del-`date +%F`.txt
done < $CPFWs

#PALO-ALTO

while read PaloAlto
do
find $L_PATH/$PaloAlto/ -mtime +365 -exec rm -fv {} \; 2>&1 | tee -a $D_PATH/del-`date +%F`.txt
done < $PAFWs


#secui

find $L_PATH/secuilog/ -mtime +180 -exec rm -fv {} \; 2>&1 | tee -a $D_PATH/del-`date +%F`.txt
find $S_PATH/secuilog/ -mtime +365 -exec rm -fv {} \; 2>&1 | tee -a $D_PATH/del-`date +%F`.txt
find $S_PATH/SDS-Mgmt/ -mtime +365 -exec rm -rfv {} \; 2>&1 | tee -a $D_PATH/del-`date +%F`.txt

상황 : activex 기반으로 web을 통해 설치되는 프로그램을 설치 유무를 AD 환경 상에서 확인해야 할 필요가 있을 때.
해당 프로그램은 프로그램 및 기능에 표시 되지 않음

해결법 : regedit /e명령을 사용

"regedit /e 추출파일명 레지경로"

해당 명령은 레지스트리 하위 디렉토리 밑에 있는 값들의 내용을 출력하는 옵션이다.
예> HKLM\Software\Policies\Micrisoft\Windows\WindowsUpdate
까지 출력하면 해당 디렉토리의 설정값들과 하위 디렉토리인 AU의 값들이 추출됨

단, 해당 경로가 레지스트리에 없거나, 레지스트리의 디렉토리 값이 아닌 파일 값을 설정하면, 파일 자체가 출력되지 않음!!

예>
HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\TargetGroup
(실제 있는 문자열값)까지 출력 명령을 내리면 출력되지 않음


아이디어 : regedit /e  명령어를 통해 파일의 생성 유무를 판단하고,
실제 그 레지스트리 값이 존재하는지 유무를 파악할 수 있다.

다음은 실행 배치파일의 예시이다.
있음직한 파일 확장자를 확실히 제거하기 위해
testreg.abc라는 파일을 만들어보았다.(해당 로직에서 파일이름이 어떻게 되었든 상관이 없다)

@echo off
set vol="Network Drive Path"
regedit /e c:\testreg.abc "HKEY_CLASSES_ROOT\TypeLib\{159D2F40-6B0C-4749-AD92-8043AEEF4DB0}\1.0"
IF EXIST "c:\testreg.abc" (
echo %date%,%time%,%COMPUTERNAME%>> %vol%\userlist.txt
del c:\testreg.abc
)


(실제 저 레지값은 ActiveX로 설치되는 파일 이 생성하는 레지스트리 경로이다.)