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

Советчики конечно молодцы и разные "оптимизируйте сайт" и "обновите софт", конечно, могут помочь.
Но это не точно.
Я бы сначала исходил из данных мониторинга:
1. нагрузка на сеть
2. нагрузка на память/cpu
3. нагрузка на диск (очереди к диску)
- Канал не загружен в пиках трафика = канал менять пока не надо
- Память/CPU не на 100% ( и нет очереди к CPU) - тоже вроде бы смысла не имеет апгрейдить
- к дискам очередей нет часто - значит дисковая система справляется с вашей нагрузкой.

Если в вышеуказанных областях проблем нет - можно перейти к
- апгрейду компонентов
- анализу нагрузки на БД

Стоит так же упомянуть что вам может помочь
- смена хостера
- Оптимизация доставки контента(CDN, в текущих реалиях и для динамического контента, через, например CloudFlare - несмотря на его последние факапы)
- анализ данных APM. Можно взять какой нибудь datadog или newrelic в бесплатных вариациях, но придется оптимизировать код сайта если обнаружатся проблемы. Я бы не рекомендовал заниматься этим пунктом пока вы не попробовали другие способы решения вашей проблемы - вы можете укопаться в ненужные вам области без надобности и увидеть проблемы там где их реально нет. В вашем случае я бы пока этим не заморачивался

P.S. Мой ответ относится к какому-то общему случаю. Если ваш сайт - это первая в жизни работа какого нибудь начинающего программера (не исключая вас) то вполне может быть ему вообще ничего не поможет, кроме полного переписывания. Не хочу вас обидеть - свое первое поделие я просто выключил и забыл :D

foreach {$file = $_; $destination = (join-path $BackupFolder $(Split-Path $file.Directory -NoQualifier)); if (!(test-path $destination)) {New-Item -itemtype Directory -Path $destination}; Copy-Item $file.fullname -Destination $destination -Container}

Для начала расшифруем то что вы описали:
Дано: пользовательские машины на windows 7
Дано(но это не точно): пользовательские данные на дефолтных местах на системном диске (папка C:\Users\USERNAME\блаблабла)
Дано: золотой образ новой OS подготовленный вашим сисадмином
Дано: механизм обновления: системный диск перезаливается полностью на золотой образ
Задача: сделать так, что данные пользователей не потерялись.
Задача в понимании вашего сисадмина: перемапить пользовательские папки (или папку дефолтного хранения профилей) на диск D: который не будет перезатираться.
Решение задачи в том виде в котором вам ее поставил ваш сисадмин: примерно описано тут
Это решение подразумевает что кто-то будет копировать файлы пользователей в новое место, и судя по всему это будет делаться вашими руками (и вашим временем), что типично для практикантов =)
Решение задачи на которое намекает ваш сисадмин: сделать то же самое, но только с помощью доменных политик (скрипт для переноса файлов, ремап места хранения профилей на другой диск)

Более адекватные и современные решения задачи (применять можно хоть все сразу, хоть некоторые соединения будут и бессмысленны :D ):
1. В рамках обновления предусмотреть миграцию пользовательских данных на сетевую шару и восстановление после (вам в комментариях уже указывали на USMT, заметьте, это рекомендованный MS способ)
2. Хранение пользовательских профилей на сервере (roaming profiles)
3. Забыть об апгрейде с помощью клонирования дисков как о страшном сне.
Тот же Symantec и другие решения позволяют развертывать системы по сети, с нормальной преподготовкой и прескриптами для файлов пользователей.
MS имеет свою систему для развертывания по сети - Windows Deployment Services.
Кроме того, именно для апгрейда на 10-ку появилась адекватная(хоть на нее и были нарекания на старте появления W10) система апгрейда с предыдущих OS через Windows Update (на которую вам тоже указывали в комментариях, не буду приписывать славу себе) - с сохранением данных пользователя!
Однако же ваш сисадмин пользуется инструментами к которым привычен и вам под него подстараиваться. Все это я написал чтобы вы знали что есть "более лучший" способ делать то, что вам делать придется.
P.S. перестаньте общаться на тостере и идите апгрейдить, иначе до нового года перезаписью дисков не успеете всех обработать :D Шутка

Если смотрите все таки в сторону AWS - то S3 в принципе подойдет для хранения фото, с оговорками.
- Хранить в s3 - дёшево.
- Часто забирать - дорого. Хрен бы с ними с фотографиями, если вы не хотите конкурировать с сервисами вроде flickr - у вас не будет много трафика, но есть еще боты.. Если сайт будет в паблике - вам задергают ваш S3 (точнее ваш кошелек) вусмерть. Поэтому - как в комментарии к вопросу уже посоветовали - в паблике надо показывать только миниатюры и желателен следующий пункт:
- Для опять же уменьшения стоимости S3 запросов, очень желательно городить кеширующий слой (nginx какой нибудь на EC2 - с EC2 цена более предсказуема, хотя и там есть ньюансы)
- Ну и на вашем месте я бы полноразмерные фотографии убрал бы в какой-нибудь раздел требующий логина, хоть бы даже и через google. Хотя тут уже возникла бы другая идея : что вам мешает на каком нибудь google drive хранить те самые фото, предоставлять доступ по email (адрес может быть и не на гугле, к примеру) и использовать любой хостинг(да хоть тот же AWS) для работы с имеющимся (google drive) хранилищем и показа миниатюр сгенерированных оттуда, для быстрой ориентации.
Цена на drive будет более предсказуема.

Но в общем и целом - это просто мнение, я плюсую всем предыдущим комментаторам.
Прайсинг в облачных сервисах (там, где принцип оплаты по использованию) может вас очень неприятно удивить: надо знать тонкости каждого, прежде чем реализовывать там решение и надеяться что цена будет одинаковой.

Создаете файл clipboard.vbs

Set objHTML = CreateObject("htmlfile")
text = objHTML.ParentWindow.ClipboardData.GetData("text")
Wscript.Echo text

и в командной строке используете
cscript clipboard.vbs
для получения данных буфера обмена
P.S. зачем и почему - не спрашивайте, даже вспоминать не хочу

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

Вот тут написана какая-то ересь, поясните что вы конкретно в этом пункте делали.
Стандартный пайплайн для переустановки 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