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

У виртуальной машины VMware со снапшотами в папке должен лежать текстовый файл с расширением .vmsd, содержащий описания всех снапшотов, и несколько бинарных файлов с расширением .vmsn, по одному на каждый снапшот. В папке с репликой всего этого нет, зато есть текстовый файл hbrgrp.<здесь длинный GUID>.txt, в котором имеется информация по всем точкам восстановления. Я написал скрипт на питоне, который использует информацию из этого файла и создает соответствующие .vmsd и .vmsn, плюс к этому файлы с конфигурацией виртуальной машины – .vmx и .nvram. Получается готовая к использованию виртуалка, которую остается только зарегистрировать в vCenter через vSphere Datastore Browser. Но есть нюанс – работает только если при репликации не использовался quiescing, так как разбираться с бинарной структурой .vmsn ни времени, ни желания нет. Скрипт выложил на гитхаб, на случай если еще кому-нибудь пригодится:

https://github.com/avnast/vr-recover

С помощью этого скрипта можно восстановить виртуальную машину из папки с данными vSphere Replication прямо из командной строки ESXi, благо в версии 6.5 имеется python 3 на борту.

Понадобится:

1. компьютер-образец (лучше бы виртуальный)
2. компьютер с установленным Windows ADK
3. флэшка

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

1. «Обезличивание» Windows с помощью sysprep

Sysprep нужен для удаления уникальных идентификаторов из системы. В нашем случае понадобится дополнительный файл ответов:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup"
 processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35"
 language="neutral" versionScope="nonSxS"
 xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <RegisteredOrganization>My Corp</RegisteredOrganization>
            <TimeZone>FLE Standard Time</TimeZone>
        </component>
    </settings>
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup"
 processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35"
 language="neutral" versionScope="nonSxS"
 xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <SkipMachineOOBE>true</SkipMachineOOBE>
            </OOBE>
        </component>
    </settings>
    <settings pass="auditSystem">
        <component name="Microsoft-Windows-Deployment"
 processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35"
 language="neutral" versionScope="nonSxS"
 xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <Reseal>
                <ForceShutdownNow>false</ForceShutdownNow>
                <Mode>OOBE</Mode>
            </Reseal>
        </component>
    </settings>
</unattend>

На шаге specialize устанавливается название компании и часовой пояс. Остальное нужно, чтобы Windows при первом запуске не требовал создать нового пользователя. Сохраняем файл на эталонной системе с именем c:\my.xml и там же запускаем sysprep (из командной строки с правами администратора):

cd c:\windows\system32\sysprep
sysprep /generalize /audit /shutdown /unattend:c:\my.xml

После выполнения инициализации система автоматически выключится. Windows «обезличена» и готова к захвату образа. Следующую загрузку уже необходимо делать с внешнего диска с WinPE.

2. Захват образа системного диска

Понадобится загрузочная флэшка с WinPE (или для виртуалки iso-образ, не принципиально). Создается на компьютере с Windows ADK (полная инструкция):

1. Start the Deployment and Imaging Tools Environment as an administrator.
2. Create a working copy of the Windows PE files:

   copype amd64 C:\WinPE_amd64
   

3. Install Windows PE to the USB flash drive:

   MakeWinPEMedia /UFD C:\WinPE_amd64 <USB drive letter>:

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

net use N: \\mycomp\myshare /USER:username

Если сеть не поднялась по причине отсутствия DHCP, можно назначить сетевой карте статический адрес командой наподобие:

netsh interface ipv4 set address Ethernet0^
 static 192.168.0.88 255.255.255.0 192.168.0.1

И собственно захват образа:

dism /Capture-Image /ImageFile:N:\my.wim /CaptureDir:C:\ /Name:"My"

3. Создание установочной флэшки

Дальнейшие действия выполняются на компьютере с Windows ADK. Создадим загрузочную флэшку, на которой будет лежать эталонный образ системного диска для новых компьютеров и программа для копирования этого образа на жесткий диск. Для этого снова запускаем (от имени администратора) Deployment and Imaging Tools Environment.

1. Создаем рабочую папку с файлами для флэшки:

copype amd64 C:\WinPE_my

Все дополнительные файлы будем размещать в папке C:\WinPE_my\media, которая после загрузки WinPE станет корнем диска D.

2. Разбиваем образ системы на файлы размером не более 4 Гб, так как на флэшке с WinPE файловая система FAT32, и файлы большего размера на нее не записать:

dism /Split-Image /ImageFile:C:\myshare\my.wim^
 /SWMFile:C:\WinPE_my\media\my.swm /FileSize:4000

3. Создаем сценарий C:\WinPE_my\media\partition_disk.txt для diskpart, который создаст разделы на целевом диске:

select disk 0
clean
convert gpt
rem == 1. Windows RE tools partition ===============
create partition primary size=450
format quick fs=ntfs label="Windows RE tools"
assign letter="T"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
rem == 2. System partition =========================
create partition efi size=100
rem    ** NOTE: For Advanced Format 4Kn drives,
rem               change this value to size = 260 **
format quick fs=fat32 label="System"
assign letter="S"
rem == 3. Microsoft Reserved (MSR) partition =======
create partition msr size=16
rem == 4. Windows partition ========================
create partition primary
format quick fs=ntfs label="Windows"
assign letter="W"
rem ================================================
list volume
exit

4. Создаем сценарий C:\WinPE_my\media\setup.cmd, который займется установкой Windows:

@echo off
d:
cd d:\

echo Partitioning disk ...
diskpart -s partition_disk.txt

echo Applying image ...
dism /Apply-Image /ImageFile:my.swm^
 /swmfile:my*.swm /Index:1 /ApplyDir:W:\

echo Copying boot files to the System partition
bcdboot W:\Windows

echo TYPE "exit" TO REBOOT

5. Создаем собственно флэшку:

MakeWinPEMedia /UFD C:\WinPE_my <USB drive letter>:

4. Установка Windows на новый компьютер

На компьютере, на который мы планируем установить Windows 10 с нашей флэшки, необходимо в настройках BIOS включить загрузку с EFI устройств, можно даже отключить Legacy Boot и включить SecureBoot для пущей важности. Возможно, придется руками указать ему грузиться с флэшки. После загрузки вводим команду

D:\setup

Если все прошло успешно, даем команду exit и после перезагрузки имеем свежеустановленную систему.

conversation with relay.friend.local[192.168.0.9] timed out while sending message body

Сервер на CentOS 6.8, почта – postfix. С обратной стороны то же самое – письма от друзей висят в очереди (там Ubuntu 15.10+тот же postfix). Как временный workaround, перенаправили почту друг на друга через Интернет, в обход туннеля – почта залетала. Стало быть, postfix работает нормально, проблема где-то в сетевых настройках.

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

[root@relay.we.local ~] scp test.bin relay.friend.local:
FAIL
[root@relay.friend.local ~] scp relay.we.local:test.bin .
SUCCESS

Копаем дальше. У нас много разных серверов на линуксах в нескольких филиалах, где-то ситуация воспроизводится, где-то все работает без проблем. Внутри одного филиала проблема не проявляется, только через VPN-туннели, хотя каналы у нас неплохие – по 50-100 Мбит. Пытаемся найти отличия между проблемными серверами/каналами и теми, где все работает:

Первая версия – вроде как проблема там, где сетевая карта VMXNET3 (у нас все в виртуальной среде). Меняем на E1000 – не помогло (

Внезапно оказывается, что если отключен файрвол (стандартный линуксовый iptables) – то все работает! Однако, на старом почтовике iptables включен, но все хорошо. Понимаем, что соединение рубится файрволом, осталось разобраться почему.

Прослушка трафика с помощью wireshark показала, что при передаче файла идет куча ретрансмиссий, затем в какой-то момент iptables просто перестает пропускать пакеты. Видимо, перестает считать что пакеты принадлежат существующему соединению и соответственно блокирует. Почему оно так себя ведет – остается загадкой.

Ладно, зайдем с другой стороны. На старом почтовике, так же как и на новом, наш любимый CentOS 6.8, вроде бы системы идентичны. Но на старом проблемы нет, а на новом есть. И построчное сравнение конфигов показало наконец заветное отличие! Всего одна строчка в /etc/sysctl.conf:

net.ipv4.tcp_sack = 0

и проблема исчезает.

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

А при попытке зайти в Exchange Management Shell выдавалось сообщение типа «The attempt to connect to http://<Exchange FQDN>/powershell using ‘Kerberos’ authentication failed». В Интернете можно найти такие варианты решения проблемы:

1. удостовериться, что часы на сервере синхронизированы с контроллером домена (в моем случае все в порядке)
2. воспользоваться скриптом EMTshooter.ps1 от Microsoft (не помогло)
3. удалить значение в реестре командой (снова не помогло)

Remove-ItemProperty -Path HKCU:\Software\Microsoft\ExchangeServer\v14\AdminTools\ -Name NodeStructureSettings

4. рестартовать службу World Wide Publishing (ну или как вариант вообще весь сервер, все равно не помогло)

В моем случае проблема оказалась в SPN, добавленном в процессе настройки NDES на том же сервере, что и Exchange:

После удаления «лишнего» SPN проблема с Exchange Management Tools исчезла:

setspn -D http/bar-exchange.bar.local BAR\ndes.service

Правда, появилась проблема с сервисом NDES, но это уже выходит за рамки этой записи.

Есть на Samba-wiki руководство Migrating a Samba NT4 domain to a Samba AD domain (classic upgrade), которое описывает похожую задачу, но для уже существующего домена на базе Samba 3. А у нас server role = standalone server, все пользователи продублированы в /etc/passwd, /etc/shadow и базе данных Samba, а группы хранятся в /etc/group. Чтобы прошел classic_upgrade, нужно подсунуть самбе что-то похожее на Samba NT4 PDC, что мы в результате и сделаем.

Итак, для начала возьмем новый сервер и сделаем из него будущий контроллер домена Samba 4 Active Directory путем установки дистрибутива Linux, в котором есть умеющая быть контроллером домена Samba. На момент написания статьи таким дистрибутивом оказался Ubuntu 15.10, его и используем в качестве примера. После установки и предварительной настройки останавливаем сервисы samba, если они запущены, и приступаем к переносу пользователей:

На старом сервере:

1) получим список пользователей Samba в формате username:uid

pdbedit -L | cut -d: -f1,2 > user_rid.txt

2) извлечем unix-пользователей из /etc/passwd и /etc/shadow:

sed s/:/:x:/ user_rid.txt | grep -f - /etc/passwd > passwd_delta.txt
sed 's/:.*/:/' user_rid.txt | grep -f - /etc/shadow > shadow_delta.txt

На будущем контроллере домена добавляем содержимое файлов passwd_delta.txt и shadow_delta.txt соответственно в /etc/passwd и /etc/shadow. Таким образом мы перенесли unix-пользователей со старого сервера на новый, теперь займемся группами:

1) сохраняем строки с нужными нам группами из /etc/group на старом сервере в текстовый файл group_delta.txt, и аналогично предыдущему шагу добавляем содержимое этого файла в /etc/group на новом;

2) чтобы classic_upgrade увидел группы и членство пользователей в них, Samba должна знать о соответствии unix-групп группам пользователей в своей базе. Если у нас standalone server, то скорее всего в базе Samba групп нет, так как используются только локальные unix-группы. Проверить это можно командой

net groupmap list

Если список групп пуст, то нужно его создать, запуская для каждой строки файла group_delta.txt команду net groupmap add:

for g in `cat group_delta.txt`; do name=`echo $g | cut -d: -f1`; id=`echo $g | cut -d: -f3`; net groupmap add rid=$id unixgroup=$name ntgroup=_$name; done

Команда выше  создает для каждой группы из файла group_delta.txt NT-группу с таким же именем и unix-GID, но с подчеркиванием в начале. Подчеркивание нужно для того, чтобы избежать возможного совпадения имени группы с именем пользователя (это недопустимо в Windows), ну и потом легче будет выделить импортированные группы в Active Directory.

Следующим шагом копируем на новый сервер бинарные базы данных Samba с нашего старого сервера. Для этого создадим на новом сервере папку dbdir и скопируем в нее со старого сервера файлы:

secrets.tdb
schannel_store.tdb
passdb.tdb
gencache_notrans.tdb
group_mapping.tdb
account_policy.tdb

Расположение файлов может быть разным в зависимости от инсталляции, но обычно их можно найти в папках /var/lib/samba и /var/lib/samba/private. Список файлов взят из вышеупомянутого HowTo, но к примеру в нашем случае нашлось только 5 файлов из 6 перечисленных, и на конечный результат это не повлияло.

Чтобы убедить самбу, что мы обновляемся с PDC, создадим  файл smb.conf.PDC следующего вида:

[global]
workgroup = <короткое имя вашего домена, например CONTOSO>
netbios name = <NetBIOS-имя вашего контроллера домена, например DC1>
security = user
domain master = yes
domain logons = yes
server role = classic primary domain controller
passdb backend = tdbsam
[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
guest ok = yes
read only = yes
[profiles]
comment = Users profiles
path = /home/samba/profiles
guest ok = no
browseable = no
create mask = 0600
directory mask = 0700

Наконец можно приступать к процедуре апгрейда:

samba-tool domain classicupgrade --dbdir=dbdir/ --use-xattrs=yes --realm=<полное имя вашего домена, например contoso.com> --dns-backend=SAMBA_INTERNAL smb.conf.PDC

Если все было сделано правильно, samba-tool должна отработать без ошибок и сформировать пригодный к употреблению /etc/samba/smb.conf. После запуска сервиса контроллера домена:

systemctl start samba-ad-dc

можно проверить миграцию пользователей и групп командами

samba-tool user list
samba-tool group list

Если все хорошо, можно удалить содержимое файлов passwd_delta.txt, shadow_delta.txt и group_delta.txt из соответствующих системных файлов и перейти к дальнейшей настройке контроллера домена: Samba AD DC HowTo after the provisioning step

1. запускаем оснастку Active Directory Users and Computers
2. включаем в меню «Вид»  пункт «Дополнительные компоненты», если он не включен
3. заходим в свойства почтового ящика, доступ к которому нужно убрать, и переходим на вкладку «Редактор атрибутов»
4. находим атрибут msExchDelegateListLink и удаляем из него пользователя, у которого нужно забрать доступ:

После перезапуска Outlook немного подумает и таки удалит  ненужный ящик из области навигации.

certutil -SetCAtemplates +<имя шаблона>

Запускать нужно из командной строки, запущенной с правами администратора.

Однако, процедура получения сертификата, импорта его в системное хранилище и затем выбора этого сертификата в iPCU может показаться утомительной (особенно последний пункт, поиск сертификата в списке установленных доставляет кучу удовольствия). Процесс можно автоматизировать, используя SCEP, благо IOS его поддерживает начиная с версии 4. Добавляем в профиль конфигурации настройки SCEP, и при правильной настройке сервера устройство получит сертификат сразу в процессе установки профиля. Стоит отметить, что сертификат должен иметь расширение «авторизация клиента», иначе авторизация на сервере не пройдет (если в качестве сервера SCEP используется Microsoft NDES, то шаблон сертификата, используемый по умолчанию, не подходит). Однако тут возникает вопрос: как указать клиенту ActiveSync, что он должен использовать сертификат, полученный в результате запроса SCEP? Это нельзя сделать с помощью iPCU. Придется редактировать профиль вручную.

Итак, создаем профиль конфигурации, в который добавляем настройки Exchange ActiveSync (без сертификата клиента) и настройки запроса SCEP. Экспортируем этот профиль, не шифруя и не подписывая его. Открываем полученный файл с расширением .mobileconfig (это обычный xml, вполне читабельный) в текстовом редакторе и добавляем в секцию настроек Exchange ActiveSync ключ PayloadCertificateUUID со значением типа string, в котором указываем PayloadUUID секции настроек SCEP.  Теперь при установке профиля IOS будет знать, что клиент ActiveSync должен использовать сертификат, полученный в результате запроса SCEP.

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

foreach ($device in (Get-ActiveSyncDevice `
     | where { $_.DeviceAccessStateReason -eq 'Upgrade' }))
{
  $allowedIds = @();
  $allowedIds += Get-CASMailbox $device.UserDisplayName `
    | select ActiveSyncAllowedDeviceIDs -ExpandProperty ActiveSyncAllowedDeviceIDs;
  if ($allowedIds) { $allowedIds += $device.DeviceId; }
  else { $allowedIds = $device.DeviceId; }
  Set-CASMailbox $device.UserDisplayName -ActiveSyncAllowedDeviceIDs $allowedIds;
}

Understanding Device Access States

При настройке автоматического завершения работы кластера на обновленной vSphere выяснилось, что скрипт отказывается соединяться с хостами ESXi из-за недоверия к их самоподписанным SSL-сертификатам. Пришлось его доработать – теперь при установке и сохранении паролей для доступа к хостам скрипт также пытается сохранить сертификаты хостов в папке /etc/ssl/vCluster, и при последующих соединениях считает эти сертификаты доверенными. Если в инфраструктуре используются подписанные централизованным CA сертификаты, то можно просто положить корневой сертификат центра сертификации в вышеуказанную папку. Вручную скачать сертификаты хостов можно по ссылкам вида https://<адрес хоста>/host/ssl_cert

Архив с инсталлятором скрипта: vCluster.tar.gz