Мне интересно, делал ли это кто-нибудь еще и впоследствии столкнулся с какими-либо проблемами, или, исходя из того, что я описываю, кто-нибудь может предложить типы проблем, с которыми я могу столкнуться:
У меня есть Windows 2008 R2 Datacenter в качестве хоста Hyper-v и гостевая виртуальная машина Windows 2008 R2 Ent, работающая на нем.
Перед крупным обновлением я сохранил копию файла VHD гостевой системы (это был диск C: на гостевой виртуальной машине). Это был не снимок, а просто копия / вставка файла VHD.
После некоторых трудностей и разочарований, связанных с обновлением SQL Server 2012 Upgrade, я решил отказаться от устранения неполадок (у меня был короткий период обслуживания) и вместо этого остановил виртуальную машину. Затем изменил файл VHD на предыдущую копию, которую я сохранил ранее.
ВМ загрузилась, но не была распознана контроллером домена. Я удалил и повторно добавил его в домен, и после этого никаких серьезных проблем. Я выполнил обновление без проблем и без проблем установил обновления Windows.
Считается ли это плохой практикой? Могу ли я оставить эту виртуальную машину как есть или мне нужно перестроить с нуля, чтобы избежать аномалий в ОС? Если бы вы были ведущим системным администратором и это была бы производственная коробка, вы бы разрешили это? Спасибо
Члены домена периодически синхронизируют учетные данные членства в домене. Когда система находится в автономном режиме в течение длительного периода, домен больше не распознает учетные данные системы. Пока вы не переименовываете систему, вы можете повторно присоединиться к домену без проблем, вы также можете попробовать NLTEST /SC_RESET:domain_name\DC_name вместо того, чтобы снова присоединиться к домену
Прежде всего, некоторые базовые понятия о машинах / доменах Windows, которые вам нужно знать (и могут или не могут уже знать):
Компьютеры являются участниками безопасности, как и пользователи
Имена - это просто удобные для человека ссылки на базовый SID.
Компьютеры аутентифицируются в домене при запуске
У учетных записей компьютеров тоже есть пароли (по умолчанию они меняются каждые 30 дней).
По сути, то, что произошло, когда вы заклинили старый VHD на своей машине (я уверен), локальный пароль для учетной записи компьютера не соответствовал паролю, который DC имел для учетной записи компьютера, потому что пароль был изменен где-то между резервным копированием вы сделали и время, когда вы его восстановили. В результате контроллер домена не позволит компьютеру пройти проверку подлинности, и вы увидите ошибку, связанную с нарушением доверительных отношений.
Это основывается на одном или двух предположениях, в первую очередь о том, что ваша резервная копия и машина, на которой произошел сбой, не имеют разных SID, что также нарушит доверие домена. Обычно это происходит, когда вы переименовываете компьютер или присоединяете компьютер к домену с тем же именем, что и существующая учетная запись. Вновь переименованный компьютер будет пытаться аутентифицироваться со своим новым SID, но имя соответствует старому SID, поэтому при проверке AD SID не совпадают и аутентификация не выполняется.
Так или иначе, вы фактически нарушили аутентификацию между вашей виртуальной машиной и доменом, когда вы «восстановили» старую резервную копию. Надеюсь, вы понимаете, почему это плохо. (Было бы менее плохо, если бы это был просто машинный пароль, а не другой SID, о котором стоит упомянуть.)
Почему это «плохая практика» - поступать так, как вы, субъективно и получат разные ответы (или разные конкретные проблемы) от разных администраторов, но мой ответ в основном будет заключаться в том, что это плохая практика, потому что есть лучший способ сделать это, который не нарушить аутентификацию домена или добавить в смесь сложности и неизвестности. (Сколько лет было резервной копии? Что изменилось в системе с того времени до настоящего момента? На что опираются те изменения, которые могут сломаться или вызвать чудовищно сложные проблемы с устранением неполадок? И т. Д.) Это также плохая практика, потому что похоже, что у вас нет настоящих , эффективное резервное копирование или быстрый процесс восстановления из [реальной] резервной копии, если / когда это необходимо. Это очень плохо, по причинам, которые, я надеюсь, вам не нужны разъяснения.
Сказав все это, похоже, вы в относительной безопасности. (При условии, конечно, что в старой резервной копии не пропущен набор данных SQL, или установлена более старая версия чего-то, или что-то подобное.) На пароль другой учетной записи компьютера нигде не будет ссылаться, и, как правило, на ваш полный SID компьютера также не будет использоваться многими вне AD, поэтому измените его не должен вызвать проблемы. (Но, как и любой администратор, побывавший в районе один или два раза, я видел вещи, от которых у вас сворачивалась кровь, и в результате я определял то, что в противном случае было бы абсолютными утверждениями.)
Надеюсь, это поможет.
Проблема в том, что это делается с контроллером домена. Он имеет базу данных с уникальными номерами, которые используются совместно и синхронизируются с другими контроллерами домена. Внезапное возвращение одного из них к старым несинхронизированным номерам - плохая идея.
Изменить: Возможно, я был немного краток. Позвольте мне добавить еще три вещи: