Потерянный доступ RDP к Azure VM после Sysprep
Я сделал глупую ошибку. При поиске простого способа сделать резервное копирование моей Azure VM я следовал за направлениями для создания снимка машины VM. В AWS (*which я привык к) снимок является быстрым способом сделать легко восстановимое резервное копирование. Я предполагаю, что MS использует другое понятие.
Во время шагов я следовал, я выполнил sysprep на VM. Я остановился, прежде чем мне удалось удалить текущий VM, но это все еще, казалось, удалило весь мой доступ к тому серверу.
Прямо сейчас я могу выполнить VM и видеть веб-сайт, но у меня нет доступа через RDP к машине. Конечная точка там, но она не впускает меня.
Как я возвращаю доступ к выполнению VM?
Sysprep используется для клонирования виртуальной машины не для целей резервного копирования. Выполнив указанные выше действия, вы сбросите виртуальную машину Windows до состояния по умолчанию, которое можно использовать для подготовки новых виртуальных машин. Любые «специфические для пользователя» настройки будут потеряны, но ваши файлы (не специфичные для пользователя) все равно будут находиться на виртуальной машине.
Вы не можете восстановить доступ к той же установке Windows на виртуальной машине, поскольку она исчезла. Что вы можете сделать, так это использовать образ для создания новой виртуальной машины, а затем перенастроить эту виртуальную машину, чтобы она действовала как старая, которую вы только что подготовили. Надеюсь, это будет второстепенная задача, но все будет зависеть от того, насколько настроена ваша виртуальная машина.
Чтобы завершить объяснение, термин моментальный снимок используется в контексте Amazon AMI , в котором вы можете использовать его для клонировать виртуальную машину.
После многих долгих разговоров с техническими специалистами Azure и множества ударов головой об стену это было окончательное решение.
Во-первых, в этот момент все было настолько испорчено, что невозможно было прикрепить файл изображения и не было споров можно было исправить виртуальную машину удаленно.
Мы закончили тем, что отсоединили диск от текущей ВМ и удалили этот экземпляр ВМ (сохранив старый диск).
Следующим шагом было создание новой ВМ, которая работала и имела все необходимые компоненты. Это была немного сложная конфигурация, поэтому повторять этот процесс было неинтересно.
После того, как новая виртуальная машина была полностью настроена и готова к работе, я подключил старый диск к работающей в данный момент виртуальной машине как диск F: и перенесли данные вручную. В основном копирование и вставка того, что было необходимо.
Я все еще работаю над безопасной миграцией базы данных MySQL, но большая часть всего остального уже завершена на новой виртуальной машине.
Это был серьезный PITA и не особо удовлетворительный способ восстановления машины. Еще очень переживаю, что что-то упустила. Думаю, время покажет.
Пожалуйста, примите это как моральную игру на опасностях использования sysprep без четкого понимания того, что он делает. Им серьезно нужно наклеить на это ярлык. Это чертовски опасно.
Примечание - у этого подхода была альтернатива. Я мог бы загрузить файл VHD для машины и попытаться исправить экземпляр с помощью Hyper-V в моей локальной системе. В этот момент я мог бы загрузить его и запустить новую виртуальную машину с этого виртуального жесткого диска. Я решил не делать этого из-за длительного времени загрузки / выгрузки VHD-файла объемом 130 ГБ и риска того, что это будет бесполезным усилием.