Евгений Хлебников

Попытка скачать образ с сайта майкрософт не дало результатов, потому что виндовс был предустановленный.

Вот тут написана какая-то ересь, поясните что вы конкретно в этом пункте делали.
Стандартный пайплайн для переустановки Windows без диска примерно следующий:
1. Выясняем ключ продукта
Если он наклеен на вашем системном блоке (что и должно было быть сделано в случае OEM) - вы его знаете.
Если наклейки нигде нет - выясняем с помощью https://www.nirsoft.net/utils/product_cd_key_viewe...
2. идем на страницу закачки
https://www.microsoft.com/ru-ru/software-download/...
вводим там ключ продукта и выбираем 64 битную версию вашей редакции
3. Если в предыдущем пункте ничего не получилось (я напомню, что текущая версия Windows - windows10 и Win7, как ни печально, уходит в историю) то качаем отсюда:
https://answers.microsoft.com/en-us/windows/forum/...
Windows7 Home Premium 64bit ISO (вполне может быть, что и в пункте 2 вам так же будет нужно скачать Home Premium), готовим установочную флешку\CD
4. Вам подойдет только полная переустановка - поэтому скачиваем все что лежит на системном диске на внешний носитель (при переустановке все потеряется) и устанавливаем OS через Custom install
Выбираете новую (или чистая? не помню) установку (upgrade не прокатит).
В идеале перед этим нужно отформатировать(там же - через выбор диска) раздел на котором стояла ваша 32 битная - просто для экономии места
5. При установке указываете ваш Product Key - программа установки примет его и покажет вам верную редакцию вашей OS. Так же, обычно, можно пропустить ввод ключа и ввести его после установки.
6. После установки вводите ключ (обычно ничего сложного, но возможно потребуется магия с применением slmgr.vbs - это же MS) и активируете.
7. Не активируется через интернет - выбирайте активацию по телефону - активация привязалась к вашей "старой" инсталляции OS и нужно ее перебить.
8. На самом деле это пункт №0 - Перед тем как что-то делать удостоверьтесь, что у вас есть диск или флешка с дистрибутивом вашей установленной OS - все это может не прокатить по абсолютно неизвестным причинам: Это MS, это российский реселлер DNS славящийся не всегда адекватным отношением и чудесами с купленными компами с предустановленной OS, это устаревшая OS, возможно ссылки на дистрибутивы уже устарели или не предоставляются MS и тд и тп.

P.S. всегда,конечно, есть торренты с которых вы можете скачать ISO, но я вам это не рекомендую, если вы не знаете что и где, а указывать на тостере ссылки на ресурсы, которые в РФ считаются пиратскими и заблокированы я б себе не рекомендовал.

Ваш вопрос вызывает больше вопросов чем желаний дать ответ, FYI
Вопросы:
1. Объединены ли в сетевом плане облачная сеть и офисная, если да то кто виноват зачем?
2. В вопросе присутствуют
- SQL: вообще не давать доступа никому кроме админов и приложения, логины обязательно отдельные от офисной сети
- Exchange: Вообще никому не давать доступ, кроме админов. Все пользовательские интерфейсы работы с Exchange - внешние.
- Служба терминалов: Вот тут (спорное утверждение) можно бы логиниться под офисными логинами, однако:
Exchange интегрирован с AD domen2, его логины для почты будут отдельными.
Если все равно есть отдельные логины - то и в службе терминалов так-то особо не стоит интегрироваться.

В общем и целом из вашего вопроса я не вижу причин для объединения доменов, так что если отвечать на "как правильно функционально" - ответ,наверное, будет: "не надо объединять"
Но если вам настолько хочется снизить безопасность сети с БД, приложением(1с наверное какой-нибудь) и почтой - дерзайте: объединяем подсети site2site VPN-ом, настраиваем траст, как написал hint000 , надеемся на авось надеемся на авось.

Впихнуть все на один сервер потенциально можно, но в получите неудобство в управлении и риски по безопасности. Приведу очевидные примеры:
сервер терминалов+AD = пользователи сервера терминалов должны быть домен админами
MSSQL + AD = https://www.concurrency.com/blog/february-2017/ins...
IIS + AD = проблемы с безопасностью (или пользователю, под которым запускается apppool не хватает прав - "глюки" в работе веб приложенияили, наоборот, слишком высокий уровень доступа у учетной записи, под которой работает приложение - риск взлома AD через IIS)
Кроме того, понимайте, что после появления AD и присоединения к нему рабочих машин это - центральный сервер вашей сети. Его поломка вызовет вал работ по восстановлению, переприсоединению, перенастройке учетных записей и тд и тп. Вы же вносите в его конфигурацию дополнительные сервисы, что несет для AD дополнительные риски
Тем не менее, у MS всегда было решение Small Business Server которое совмещало на одном сервере роли, необходимые небольшой организации. На текущий момент мои знания по SBS устарели, но продукт существует в виде Windows Server Essentials - возможно, для того, чтобы понять какие роли сейчас (по рекомендации MS) можно совмещать на одном сервере можно посмотреть в его сторону

Может быть нарушен порядок применения.
Попробуйте в firewall.sh в конце добавить sudo systemctl reload iptables или(если не сработает) sudo systemctl restart iptables
В остальном vanoc в принципе все написал что еще можно сделать

Вадим
1. Backup виртуальных машин - это AMI (в принципе те же яйца, только сбоку: снапшоты EBS-ов + конфигурация машины собранные в пакет и зарегистрированные пространстве AMI вашего аккаунта)
Хотите делать полный бэкап машины - делайте AMI а не снапшот EBS . В процессе AMI вполне себе можно затегировать.
Нужный вам подход - освоить AWS CLI для создания AMI и их тегирования. Скрипт будет простой.
В теги можете запихать все что угодно, включая девичью фамилию матери админа, запустившего инстанс.
Поставите в скедулер запуск снятия AMI-шек со всех нужных вам инстансов и будете иметь бэкап продакшена малыми средствами. Помните, что снятие AMI не всегда возможно без выключения машины - внимательнее с этим.

2. Если вам важны DNS записи и IP адреса - вы держите псевдостатическую инфраструктуру в облаке. Образно говоря вы писаете против ветра, поэтому у вас такие проблемы и возникают.
Это ваш жареный петух техдолг и он уже начинает подбираться к вашей пятой точке, судя по вашим вопросам.
Правильный подход с точки зрения AWS - динамика, но если вы собираетесь и дальше стрелять себе в ногу - ваш выход - автоконфигурация (чем угодно, хоть скриптами в юзердате, хоть ansible,chef,puppet,etc) статического адреса и DNS имени после старта машины. Данные об IP и прочих можно забирать через describe-tags на AMI из того же aws cli

Вадим
https://www.terraform.io/docs/providers/aws/r/rout...
Обратите внимание что у блока route два аргумента а у вас - один. В общем и целом, нужно не только указать CIDR который маршрутизировать но и через что его направить

очень, очень странно что за год никто не ответил на этот вопрос, даже и не знаю, чувствую себя некромантом.

В общем-то, если не учитывать бестпрактисез - вы делаете единственно доступным вам правильным способом.
Snapshot - это резервное копирование диска, не виртуальной машины.
Бэкапить машину полностью, включая kernelid и другие настройки - это image (AMI)

Бестпрактиc, правда, не такой
Подготовка кода + скрипты настройки -> подготовка артефактов -> запуск машины
Подготовка кода + скрипты и подготовка артефактов
Здесь вы или подготавливаете артефакты(например zip архив в S3) с кодом и соответствующими ему скриптами, которые заставляют этот код работать на машине
И, опционально, подготавливаете AMI
Это рекомендованный способ во многих случаях. По сути вы сейчас делаете практически то же самое, но создаете AMI после публикации и стабилизации кода и настроек (правильно - до, и тестировать что получилось) . Кроме того ваш способ может привести к сюрпризам в будущем, поскольку вы накатываете изменения на уже существующую машину и какие-то настройки сделанные сейчас будут мешать работать будущим версиям.
Еще одна альтернатива - вообще не готовить AMI. Фиксировать версию кода и настроек(настроечных скриптов). Готовить из них артефакты(или просто git clone из репозитория по версии) и проводить все действия по настройке прямо на старте машины. У вас не будет некоей AMI которая привязана к вашему аккаунту - у вас будут скрипты которые можно запустить на любом аккаунте без промежуточного шага.
Инструменты:
подготовка AMI: packer, cloudformation
запуск инстанса: terraform, cloudformation
скрипты настройки: все что нравится, от банальных bash скриптов до ansible,chef,puppet, etc..
Настройка машины при запуске: cloud-init
CloudFormation - встроенный инструмент в AWS, но он сложноват в сравнении с packer и terraform

Попробуйте открыть console.aws.amazon.com в анонимном режиме, чтобы исключить сохраненные куки.
Для отдельно зарегистрированного аккаунта вход происходит по емейлу-паролю, accountid там еще не фигурирует

Простенький скрипт на powershell

$searchfolder = "j:\1"
$storefolder = "j:\2"
New-Item $storefolder -ItemType Directory -ErrorAction SilentlyContinue -Force
Get-ChildItem $searchfolder -File -Recurse | %{
    $newpath = Join-Path $storefolder -ChildPath $_.BaseName
    New-Item $newpath -ItemType Directory -ErrorAction SilentlyContinue -Force
    Move-Item -LiteralPath $_.FullName -Destination $newpath 
}

powershell.exe get-netadapterstatistics
Если у вас несколько интерфейсов то можете ключом -name отфильтровать вывод

robocopy /MON:n
или robocopy /MOT:n
робокопи встроен сейчас в windows и единожды запустив можно обеспечить подобную синхронизацию

commandline switches for office products

немного исправленный ответ Иван Шумов
1.
2.
3. в asg в юзердате прописать подключение EIP инстансу скриптом с помощью aws cli - в этом случае не придется платить еще и за elb
а. можно сделать втупую - выписат secret key\access key с вашими (полными) правами
б. можно покурить IAM немного и разрешить инстансу совершать определенные действия с eip с помощью Instance Profile ( с ним связаны IAM Policy , IAM Role )
3. Или же можно просто регистрировать получившийся IP (который каждый раз при старте инстанса будет новый) в route53 если у вас зона хостится в AWS