%EB%A5%BC%20%EC%8B%A0%EB%A2%B0%ED%95%98%EC%A7%80%20%EC%95%8A%EC%8A%B5%EB%8B%88%EB%8B%A4..png)
배경:
여러 레거시 Windows Server 2003 시스템을 VMware에서 Azure로 마이그레이션해야 합니다.
예, 우리는 그들이 레거시 OS를 가지고 있다는 것을 알고 있습니다. 하지만 우리는 그것들을 계속해서 운영해야 합니다. 그리고 이것은 (적어도 부분적으로)마이크로소프트에서 지원.
한 가지 중요한 단계는 물론 서버를 Azure로 이동하기 전에 서버에 Hyper-V 통합 서비스를 설치하는 것입니다. 우리는 이 단계를 수동으로 수행하기로 결정했습니다.시작 스크립트에 의존하는 공식적으로 문서화된 프로세스다소 신뢰할 수 없는 것으로 입증되었습니다.
따라서 우리 프로세스에서 서버는 먼저 Hyper-V 시스템으로 변환됩니다. 그러면 HVIS가 설치되고 VMware Tools가 제거된 다음 Azure로 이동됩니다.
프로세스는 정의, 테스트 및 문서화되었습니다. 올바르게 작동합니다.
하지만.
한 특정 시스템에는 장치 드라이버와 관련하여 매우 이상한 문제가 있습니다. 그것은 신뢰하지 않는다어느기본 드라이버를 포함한 장치 드라이버를 설치하고 설치하기 전에 수동 확인을 요청합니다.어느하드웨어. 이는 Hyper-V 드라이버에서만 발생하는 것이 아니라모든 장치, 드라이버가 Windows 자체에 기본인 드라이버를 포함합니다. 아래 예:
이는 고통스러운 일이지만(VMware에서 Hyper-V로 이동할 때 해당 프롬프트가 15~20개 있음) 서버와 수동으로 상호 작용하는 한 살아남을 수 있습니다. 그러나 서버가 Azure로 이동되면 새 네트워크 어댑터를 포함하여 Azure의 새 장치를 설치하기 전에 동일한 수동 확인을 기다립니다. 물론 이는 네트워킹이 없고 Azure VM에 액세스할 방법이 없음을 의미합니다.
왜 이런 일이 발생합니까? 어떻게 고칠 수 있나요?
서명되지 않은 드라이버를 자동으로 허용하도록 시스템을 구성해 보았습니다.~이다서명되었으며 이런 일이 전혀 발생해서는 안 됩니다):
그러나 서버는 여전히 동일한 작업을 수행하고 새 하드웨어를 설치하기 전에 확인을 요청합니다(그리고 Windows 로고 테스트를 통과하지 못했다는 경고).
우리는 또한 sfc /scannow
어떤 문제도 발견하지 못했고 문제를 해결하지도 못했습니다. chkdsk
역시 아무 잘못도 발견하지 못했습니다.
이 특정 서버가 왜 이런 식으로 작동합니까?
이 문제를 어떻게 해결할 수 있나요?
참고: 이 문제는 업데이트 누락 및/또는 인증서 만료로 인한 것이 아닙니다. 원본 ISO를 사용하여 Hyper-V에서 Windows Server 2003을 새로 새로 설치하려고 했으나(아직 사본이 있음) 업데이트가 전혀 없었고 이와 같은 작업이 수행되지 않았습니다.