Нотатки адміна-трудоголіка

Наша взаимовыгодная связь https://banwar.org/

Передмова

Почалося все ще восени 2010-го, коли ми з одним клієнтом прийшли до консенсусу і вирішили переходити з опенсорс на Windows і AD. На новорічних канікулах я зібрав з трьох напівмертвих серверів один напівживий і поставив на нього Windows Small Business Server в режимі ознайомлення і розгорнув XP на 20 машин. Ліцензії ще не були куплені, але директор клятвено обіцяв купити їх в якнайшвидшому часі - на сервер до закінчення 180-денного пробного періоду і на ХР в січні. Та й сил моїх більше не було підтримувати зоопарк, що складається навпіл з OpenSUSE і Windows XP, так з трьома серверами на FreeBSD. Весь цей зоопарк колись я ж сам і піднімав, але тоді у мене не було достатньо авторитету, досвіду і часу, щоб ось так з порога зробити всім добре або відразу умовити купити вінди.

Загалом, довго чи коротко, а поставив я SBS 2008. З кавою і матами налаштував, завів користувачів і комп'ютери, шліфувати групові політики, сервер оновлень WSUS, 2ГІС, ще щось по дрібниці. Переніс дані зі старого сервера і пошту з локальних баз Thunderbird на комп'ютерах. До речі, як раз грім-птах мало не стала останньою краплею: ​​пошта - одне з головних бізнес-додатків компанії, і технологічний ліміт розміру ящика в 4 гігабайти половина користувачів досягла вже давно. Гальмували комп'ютери через таку пошти жахливо, до того ж часто ламалися, тому що останній раз парк машин оновлювався ще році в 2005-му. З цієї причини було вирішено використовувати переслані папки - щоб користувач міг зайти під своїм ім'ям на будь-який ПК і спокійно працювати не тільки зі своїми файлами на робочому столі, але і зі своїми настройками скайпу, аськи, офісу і закладками браузера. Та ще й з поштою - вона як раз через браузер і працює, оскільки Outlook купувати ніхто не збирався. Якраз під егідою OWA заодно і пересадив усіх на IE - оскільки OWA 2007 в інших браузерах відображається бідно. Він, якщо його правильно налаштувати, насправді, непоганий браузер. Загалом, користувачі були щасливі - пошта не гальмує, доступна звідки завгодно; ламаються комп'ютери перестали бути проблемою, 2ГІС оновлюється сам, та ще й міста можна вибрати нові без моєї допомоги, глобальна книга адрес і багато інших булочок. Я щасливий тим більше.

Ліцензії купили тільки через рік, зате за цей рік встиг випустити SBS 2011. У ньому і ядро ​​6.1, куди більш спритне, ніж 6.0 (Vista / 2008), і Exchange 2010 з новою OWA, і взагалі круто все. Але переходити на нього ми не збиралися, бо міграція клопітно, а рекомендовані 11 гигов оперативки було взяти ніде. У продуктів MS ж є чудове право Downgrade!

Граблі перші. Висить груша, російські = індуси

Заходжу на VLSC, натискаю кнопку "Завантаження і ключі", і що я бачу? Формене свинство. Ключі для 2011 - ось вони, а ключі для 2008 року я можу отримати тільки з диском, диск можу замовити поштою за окреме бабло, в разі, якщо я не резидент Росії або Індії. Ні, ви вдумайтесь: резиденти всього африканського континенту, включаючи Сомалі і племена Тумби-Мумбая можуть замовити диск, а ми - ні! Пруфпікс:

Ну хіба це не свинство? Зателефонували дистрибутором MS - все вірно, на SBS2008 ми право маємо, але реалізувати це право не можемо. Гаразд, поматерілся і вирішили мігрувати на 2011. Натренувавшись на кішках під VMware Player, приступили до міграції. На все про все було відведено два дні - 29 квітня і 1 травня. Запланували по кроках:
1. Чистий установка SBS2011 на VMware Player
2. Запуск міграції зі старого сервера
3 ... N. За інструкціями майстра міграції
N + 1. Відключення старого сервера
N + 2. установка ESXi
N + 3. Перенесення виртуалки з Player на ESXi
N + 4 Підключення дисків з мережевими папками до віртуального сервера (RDM)

Граблі другі. Гігабіти не винаходили.

Перші три кроки пройшли нормально. Плануючи міграцію, я подивився обсяг бази поштових скриньок: 20 Гбайт. Скільки можуть перекидатися 20 гігабайт по гигабитной мережі? Теоретично - 2 хвилини 40 секунд. Якщо враховувати швидкість жорстких дисків - 7 хвилин. Ну нехай навіть 10, для рівного рахунку. Але ж ні, поштові ящики переносилися два з половиною години. Як, чому - вникати не став, але на цьому перший день з двох закінчився. Зате міграція ящиків пройшла без помилок.
А поки вони мігрували, я зайнявся експортом мережевих папок.

Щоб зробити це легко і невимушено, найкраще експортувати список расшаренних папок з реєстру і потім його імпортувати.
1. Йдемо в розділ HKLM \ CurrentControlSet \ services \ LanmanServer \ Shares, експортуємо його під ім'ям Shares_OLD.reg
2. Видаляємо з цього розділу і підрозділу Security все, крім тих папок, які потрібно мігрувати
3. Знову експортуємо HKLM \ CurrentControlSet \ services \ LanmanServer \ Shares, але під ім'ям Shares_MIGR.reg
4. Відновлюємо розділ назад з файлу, створеного на кроці 1.
Надалі, після підключення дисків до виртуалке, потрібно буде переконатися, що у дисків залишилися ті ж букви (або привести в сответствие reg-файл), імпортувати reg-файл і перезапустити служби "Сервер" і "Мережевий вхід в систему".

Далеко не так легко пройшла міграція загальних папок Excahnge.

Граблі треті. зайві болтики

Поняття загальних папок Exchange в конторі не прижилося, тому крім OAB в загальних папках нічого не було. Обсяг бази на диску - 200 метрів, міграція йшла довше ніж міграція ящиків. Тільки на наступний день після першого запуску скрипта MoveAllReplicas.ps1 репліки з'явилися на новому сервері. Але вперто не хотіли віддалятися зі старого, що необхідно для видалення Exchange 2007 з організації. А репліки не вилучено навіть до того моменту, коли старий сервер пора було гасити. Довелося застосовувати важку артилерію: лізти в ADSI.

Гугл розповів, що робиться це так.
1. Переходимо в розділ CN = Configuration, DC = <ім'я домену>, DC = com, CN = Services, CN = Microsoft Exchange, CN = <Організація>, CN = Administrative Groups, CN = Exchange Administrative Group (FYDIBOHF23SPDLT), CN = Servers, CN = <Сервер>, CN = <Ім'я групи сховищ із загальними папками>;
2. У цьому розділі знаходимо потрібну непотрібну базу даних загальних папок і видаляємо її;
3. (тільки для E2007 і нижче) Переходимо в розділ CN = Configuration, DC = <ім'я домену>, DC = com, CN = Services, CN = Microsoft Exchange, CN = <Організація>, CN = Administrative Groups, CN = Exchange Administrative Group (FYDIBOHF23SPDLT), CN = Databases;
4. Відкриваємо властивості нової БД загальних папок, копіюємо значення атрибута distinguishedName;
5. Відкриваємо властивості об'єкта CN = Configuration, CN = <DomainName>, CN = com, CN = Services, CN = Microsoft Exchange, CN = <Організація>, CN = Administrative Groups, CN = Exchange Administrative Group (FYDIBOHF23SPDLT) і вставляємо скопійоване значення замість поточного значення атрибута siteFolderServer;
6. Перезапускаємо службу "Банк даних Microsoft Exchange" (Microsoft Exchange Server Information Store).

Після цього Exchange на старому сервері дозволив себе видалити. По завершенні деінсталяції сервер був знижений

Граблі четверті. Майже не настав.

Поки новий сервер вимикався перед перенесенням (а він за добу роботи знайшов 80 оновлень і при виключенні смачно їх пережовував близько години), я ставив ESXi на те залізо, де тільки що був старий сервер. Це теж несподівана грабля: витрачати годину на вимикання сервера я не планував.

Самі ж граблі в тому, що в безкоштовній версії ESXi існує обмеження швидкості передачі файлів в Datastore - 5 МБайт / с. Я згадав про це обмеження відразу після введення безкоштовного ключа. Але оскільки віртуальний новий сервер ще ставив поновлення, я, не мудруючи лукаво, перевстановив ESXi, благо длітельнойсть цієї процедури - не більше 10 хвилин. Але файли потім все одно переносилися більше години, на швидкості 12-15 МБайт / с.

На жаль, я не знайшов підтвердження про обмеження швидкості в офіційних джерелах, тому наводжу посилання тільки на гілку в VMware Communities.

Граблі п'яті. Бачиш ховраха?

Віртуальна машина скопіювати, в ІНВЕНТОР додалася, пора причіплювати жорсткі диски з даними. Запускаю майстер додавання віртуального диска, і - що я бачу? Щелепа падає на стіл, в голову лізуть погані думки. Пункт "Raw Device Mapping" відключений!

Мозок говорить "цього не може бути", тому що ось цими ж руками тиждень тому в безкоштовному ж ESXi цю функцію використовував. Перезавантажився, зайшов в BIOS, поміняв режим роботи SATA-контролера з EHCI на IDE Emulation. Не те, щоб це повинно було допомогти - просто "ну, а раптом". За кілька хвилин нагугліть, що немає в цьому нічого неможливого, але чомусь від користувача можливість захована. З системами зберігання можна, з апаратними RAID-контролерами можна, а зі звичайними гвинтами можна, але чомусь не можна. Через vSphere включаємо SSH, підключаємося і робимо наступне:
1. cd / vmfs / volumes / <datastore_name> / <VM_name>
2. ls / vmfs / devices / disks /
3. vmkfstools -r / vmfs / devices / disks / <ім'я потрібного диска> Physical_HDD_0.vmdk (не забудьте розширення в кінці команди, а то я хвилини дві думав, чому диски не з'явилися в майстра додавання існуючого диска)
4. Повертаємося в vSphere Client і додаємо до віртуальної машини віртуальний диск за пунктом "Use an existing virtual disk"
Я повторив пункт 4 для чотирьох дисків, все успішно підключилися до виртуалке і надалі запустилися.

Граблі шості. VMware і VMware - дві великі різниці

Ось вже ніяк не чекав, що формати віртуальних машин різних гіпервізора одного виробника не сумісні один з одним. Хто там щось мимрив на тему "майкрософт не робив свій гипервизор, а купив готовий у Connectix"? Запускаю виртуалку, і мовить вона людським голосом видає вона помилку:

Unable to create virtual SCSI device for scsi0: 0, '/ vmfs / volumes / <datastore uid> / <VM_name> /SBS2011-0.vmdk'
Failed to open disk scsi0: 0: Unsupported or invalid disk type 7. Make sure that the disk has been imported.

Зверніть увагу, і Player, і ESXi - останніх версій. Ну да ладно. Проблема вирішується по ssh:
1. cd cd / vmfs / volumes / <datastore_name> / <VM_name>
2. vmware-vdiskmanager -r Windows \ SBS \ 2011.vmdk -t 4 Windows \ SBS \ 2011.vmdk

Тут же моя проблема була б вирішена, якби у бабусі якби жорсткий диск з ESXi був трохи більший: я поставив його на 160-ку, VMware побачила 143, а виртуалка зайняла 85, відповідно, ще одна копія не влізла. Мені пощастило: крім цього диска було два дводискових дзеркала з даними. Я подумав, що за годину з гвинтом нічого не трапиться, і відформатував одну з реплік під тимчасовий datastore, попередньо відключивши його rdm-vmdk від виртуалки. На нього конвертувати vmdk з SBS, перемістив його назад на datastore1, підключив диск назад до виртуалке.

Граблі сьомі. Роздвоєння особистості

Сервер нарешті запустився, поставив поновлення, підхопив мережеві папки (див. Граблі №2), але з мережі його не видно. Мережева плата є, адреса у неї правильний (наприклад, 192.168.7.2), роутер з нього пінгуєтся навіть, але ось з інших машин і з роутера - НЕ пінгуєтся. Каюсь, тут довелося зображати танці з бубном в чистому вигляді: додаю другий адреса на мережеву - 192.168.7.1 - пінгуєтся, 192.168.7.2 все одно не пінгуєтся. Видаляю 192.168.7.2, залишаю тільки 192.168.7.1. Пінгуєтся, але 192.168.7.2 автоматично прописується знову. Між тим в DNS всі записи ведуть на 7.2. На якомусь етапі 7.2 навіть запінговался (не пам'ятаю, як - справа була вже під ранок), але після перезавантаження перестав. Вирішилося тупо - видалив мережеву з виртуалки, додав нову, прописав адресу - запрацювало. Швидше за все, причина була все в тому ж - несумісність форматів віртуалок між Player та ESXi.

2 травня, 7:40 ранку. Сервер нарешті запустився і працює, комп'ютери домен бачать, DHCP роздає адреси, OWA красива, свистілки і перделкі на місці.

Граблі восьмі. Ой.

Його користувачі не можуть увійти в систему. Точніше, можуть, але толку від цього мало: переслані папки ведуть на старий сервер, не дивлячись на те, що в політиці шлях виправлений. Ну і що, що виправлений, - подумав Штірліц і стукає на вже неіснуючий сервер. У реєстрі користувачів шляхи ведуть на старий сервер, а там шляху змінюються тільки при штатній, плавної міграції перенаправлених папок - коли деякий час в мережі присутні обидва сервера. У такому випадку при вході користувача і застосуванні модифікованої політики перенаправлених папок відбувається перевірка реплікації між старим і новим призначенням. А в нашому випадку старий сервер зник, звіряти ні з чим, і взагалі, все погано. Те, що в DNS прописав ім'я старого сервера, провідне на новий - не врятувало, клієнти чіпляють папки по імені.

Виправив створенням групової політики, що замінює значення реєстру за адресою HKCU \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ User Shell Folders. Замінюємо тільки ті значення, які змінені груповою політикою, з використанням змінної% username%, чекаємо застосування політик (за замовчуванням застосовуються кожні півтори години, але я давно завбачливо зробив інтервал оновлення в 15 хвилин), просимо користувачів перезавантажитися.

Все працює, все щасливі, хепі-енд.

UPD. Після восьмих граблів потрібно перебудувати кеш автономних файлів, інакше профілі будуть продовжувати спроби синхронізації зі старим сервером

посилання

- Migrate to Windows Small Business Server 2011 Standard from Windows Small Business Server 2008
http://unified.swiatelski.com/2011/01/force-removal-of-public-folders.html - Force removal of Public Folders Database
http://technet.microsoft.com/en-gb/library/aa996485.aspx - Site folder server deleted
http://msmvps.com/blogs/acefekay/archive/2009/09/08/folder-redirection.aspx - Ace Fekay's Blog: Folder Redirection
http://technet.microsoft.com/ru-ru/library/gg615497.aspx#BKMK_CreateShares - Create shared folders and restore permissions on the Destination Server
http://support.microsoft.com/kb/242557/en-us - Registry Settings for Folder Redirection in Windows
http://communities.vmware.com/thread/285269 - VMware Communities: ERROR: Unable to create virtual SCSI device for scsi0: 0
http://kb.vmware.com/kb/1026256 - VMware KB: Recreating pass-through Raw Device Mapping (RDM) files for a virtual machine
http://chmv.allnetic.com/article/vmware-esxi-podklyuchenie-lokalnogo-diska-kak-rdm/ - VMware ESXi 5 - Підключення локального диска як RDM
http://communities.vmware.com/thread/200443 - Низька швидкість копіювання на ESXi. Це нормально?
http://communities.vmware.com/message/1135905 - File transfer to datastore from VM Infrastructure Client extremely slow
http://kb.vmware.com/kb/1003746 - Virtual machine hardware versions