Керівництво для розгортання Windows 7, Windows, Операційні системи, статті

В залежності від розміру вашого підприємства, складність розгортання Windows 7 варіюється від дуже простий, до дуже складною. Що стосується власних розгортань, завдання потрапляє під останнім опис. Однак, використання System Center, компонента розгортання операційної системи (OSD), диспетчера Configuration Manager 2007 і пакета поновлення 2 (SP2), який скоро вийде, може значно полегшити процес. Не має значення, під який рівень складності потрапляє ваша організація, ви можете використовувати план Microsoft для переходу організації на Windows 7.


У даній статті описується, як група розробників Microsoft розгорнула Windows 7 у власній компанії. У ній йдеться про те, як ми розробляли рішення з розгортання Windows 7, і як ви можете застосувати ці самі кошти для спрощення


Знайомство зі сценаріями розгортання настільних систем в організації


На першому етапі, звичайно ж, необхідно оцінити вимоги і сценарії, необхідні для виконання великомасштабного розгортання нової ОС. На відміну від програм, встановлених на настільних комп’ютерах, від операційних системи значною мірою залежить продуктивність і збереження даних користувачів. Таким чином, ви часто витрачаєте багато часу, намагаючись визначити поточний стан справ і знизити ризики при пошуку найкращого рішення. Саме з цим випадком ми стикаємося в компанії Microsoft, де налічується понад 280.000 настільних комп’ютерів.


*


Рис.1 Сценарії настройки диска настільного комп’ютера підприємства


При розробці рішення для настільного комп’ютера на вашому підприємстві основними об’єктами є настройка жорсткого диска, технології шифрування, додатки і призначені для користувача дані. (Хоча драйвери обладнання також грають велику роль при розгортанні, ця тематика виходить за рамки цієї статті. Рішення компанії Microsoft, що розробляється для спрощення роботи з драйверами устаткування, обговорюється в блозі TechNet: tinyurl.com/kog748.)


Налаштування робочого середовища, з одним або декількома дисками, є важливим елементом при розгортанні Windows 7 з використанням диспетчера Configuration Manager. Завдання є гранично простий – розгортаєте Чи ви Windows 7 тільки на нових машинах, або використовуєте міграцію з іншого ОС. Як показано на рис.1, Вам необхідно розробити рішення, яке дозволило б розмістити систему на одному диску з кількома розділами або на складних Мультізагрузочний конфігураціях з кількома дисками.


Багато настільні системи в Microsoft працюють під управлінням Windows Vista, а деякі робочі групи потребують використання технології шифрування BitLocker, представленої у версії Vista. Додаток BitLocker шифрує і захищає системний розділ у випадку крадіжки або втрати даних. При спробі оновлення ОС, яка працює на зашифрованому диску, послідовність завдань повинна відключити або зупинити шифрування. Більшість мобільних середовищ вимагають шифрування, тому будь-які рішення, розроблені для них, повинні брати до уваги сценарії шифрування.


Одним абсолютним, що не підлягає обговоренню фактом є те, що на будь-якому підприємстві у користувачів є дані, які не можна втрачати під час міграції. Для користувачів ОС Windows компанія Microsoft надає набір засобів міграції користувача середовища (USMT), спроектований для полегшення збору та зберігання інформації користувачів. ОС Windows 7 представляє нове покоління інструментів USMT (версія 4.0), які мають значні удосконалення в порівнянні з попередниками. Основна відмінність між набором USMT 3.0 і версією 4.0 полягає в останній частині наших сценаріїв: вибір відповідного процесу для збору інформації про стан даних користувача і способу, для збереження цього стану.


На відміну від попередньої версії, USMT 4.0 працює минаючи операційну систему. При зборі інформації про стан користувача для можливості відновлення після оновлення, повне завантаження ОС може викликати ряд проблем, так як деякі файли можуть використовуватися або блокіроваться.Также інші додатки, наприклад антивірусні рішення, можуть викликати збій при спробі створення резервної копії даних. Процес збору даних у новій версії працює минаючи повне завантаження ОС, в таких середовищах, як, наприклад, Windows Pre-Execution (PE), значно скорочуючи кількість запускаються служб, використовуваних додатків і інших сценаріїв, які включають в себе відкриті для користувача дані. Можливість завантаження стану користувача з Windows PE (через автономну резервну копію), надійно працює з послідовністю завдань OSD диспетчера Configuration Manager в середовищі Windows PE, оптимізуючи процес резервного копіювання даних користувача.


Після того, як засіб USMT збере всі необхідні дані користувача, йому потрібно місце для “зберігання” цих даних під час процесу міграції. Компанія Microsoft має безліч варіантів вибору того, де зберігати дані користувача, але цей діапазон рішень може не увійти до бюджету підприємства, виділений на інформаційні технологи. Наприклад, припустимо, що обсяг даних звичайного стану користувача в компанії Microsoft складає приблизно 1ГБ. Варіанти зберігання цих даних для подальшого вилучення включають в себе зовнішні жорсткі диски, файлові сервери та оптичні диски, наприклад, DVD. Для організацій, що використовують диспетчер Configuration Manager 2007, роль State Migration Point дозволяє зберігати дані на віддаленому сервері під час процесу міграції, але все таки є обмеження.


Основна причина їх полягає в тому, що “зовнішнє” пристрій є неекономічним, і зажадає наявності фізичного простору для зберігання, рівного стану кожного користувача. Таким чином, в Microsoft нам би треба було 280ТБ вільного простору і можливість підтримки нашої користувача бази. Даний підхід працює, тільки якщо ви можете точно оцінити кількість призначених для користувача даних. Інакше, швидше за все це призведе до непередбачуваних і незадовільних результатів.


Останнім варіантом є використання машин, на яких проходить процес міграції. Можливо, це самий логічний і економічний спосіб, але зазвичай являє собою складну технічну задачу. Він вимагає того, щоб машини користувачів мали велику кількість вільного простору, доступного для резервного копіювання своїх даних; також сюди входить процес копіювання даних користувача з одного місця на диску на інше. Як відомо ветеранам інформаційних технологій, для переміщення або копіювання будь-якого файлу на жорсткий диск потрібен якийсь час, що в свою чергу, зробить процес розгортання дуже тривалим у часі. Розгортання, яке забирає у користувача день (або кілька днів), просто не представляється можливим, і може становити ризик, на який ви не захочете піти.


Засіб USMT 4.0 має підтримку жорстких посилань, функцію, яка була недоступна в попередніх версіях. Міграція жорстких посилань дозволяє ефективно зберігати дані користувача локально на одному комп’ютері, що вимагає небагато часу і простору на диску.


Єдиною вимогою для використання жорстких посилань є наявність 250МБ вільного простору на комп’ютері користувача. Підтримка жорстких посилань додає можливість резервування та відновлення без переміщення фізичних файлів на диск. Замість цього, засіб USMT зберігає тільки покажчики на фізичні файли і використовує дані покажчики під час відновлення, значно скорочуючи кількість часу, необхідного для міграції Windows 7. (Додаткову інформацію про жорсткі посиланнях дивіться в статті журналу TechNet: tinyurl.com/m76dxv.)


Розуміння різних сценаріїв допоможе вам створити план дій щодо їх використання під час переходу на Windows 7.


СТВОРЕННЯ ВАШОЇ ПОСЛІДОВНОСТІ ЗАДАЧ ДЛЯ МІГРАЦІЇ НА WINDOWS 7


Як тільки ви ознайомитеся з даними вимогами і сценаріями, впровадження рішення стане порівняно простим завданням. Етапи по створенню вашого рішення можна розділити на три основні категорії:



  1. Визначення активності кінцевого користувача
  2. Створення послідовності завдань Windows 7
  3. Міграція користувача середовища

Відділ інформаційних технологій компанії Microsoft розробив рішення під кодовою назвою “Modena,” яке надає вам можливість підтримки першої категорії, завдяки використанню потужного майстра OSD, другої категорії, за допомогою експортування послідовності задач, і третьої категорії, за допомогою сценаріїв міграції користувача середовища. У наступному розділі буде описано те, яким чином слід використовувати засоби OSD Modena, які включають в себе майстер OSD, експортовану послідовність завдань і сценарії.


ВИКОРИСТАННЯ МАЙСТРА OSD


Компонент OSD диспетчера конфігурацій призначений для використання адміністраторами. З цієї причини компонент OSD не містить вбудованого майстра, що передбачає необхідність для багатьох організацій, в розробці свого власного майстра. Загалом, не існує стандартних функціональних можливостей для збору інформації про кінцевих користувачів за допомогою диспетчера Configuration Manager – проблема, з якою зіткнулася компанія Microsoft сама.


Компанія Microsoft є організацією, керованою користувачами; всі користувачі працюють в якості адміністраторів.


Багато засуджують рішення, прийняті компанією Microsoft в сфері інформаційних технологій, які вплинули на використання всіх компонентів ОС. Як наслідок, компанії Microsoft довелося забезпечити дуже надійну роботу користувачів навіть при отриманні від них максимальної кількості інформації, але зроблено це було так, що інформація не виявилася надмірною і її отримання не відбилася на роботі користувачів.


Майстер OSD Modena пройшов випробування в Microsoft і є доступним для вашого підприємства. (Додаткову інформацію про отримання коштів OSD ви зможете подивитися в блозі на blogs.technet.com / osd.)


Майстер OSD Modena має два компоненти: виконуваний і конфігураційний файл. Виконуваний файл, OSDSetupWizard.exe, є автономною користувальницької системою, написаної компанією Microsoft. Він розроблений для перевірки того, що комп’ютер готовий для міграції на Windows 7 і для збору інформації про кінцевий користувача. Остання роль майстра полягає в отриманні інформації користувача і налаштування змінних послідовності завдань OSD.


Ключовим аспектом майстра є те, що він спроектований для роботи в режимі plug-and-play, тому він є корисним для багатьох сценаріїв. Він досягає цієї мети за допомогою конфігураційного файлу. По суті, в складному середовищі, наприклад в середовищі Microsoft, один і той же виконуваний файл може використовуватися з різними файлами за допомогою аргументу / xml: osdconffilename.xml.


Наприклад, у розгортанні Microsoft, які вимагали підтримки консолі для Run Advertised Programs (RAP) і Preboot Execution Environments (PXE), використовувалася одна послідовність завдань, але два конфігураційних файлу – по одному для кожної середовища (RAP і PXE). Тим самим був створений пакет розгортання, придатний для використання в будь-якому випадку, що дозволяє використовувати різні конфігурації, що підтримують цей конкретний пакет.


Почнемо знайомство з майстром OSD з огляду доступних екранів кінцевих користувачів (також їх називають сторінками). У майстрі OSD доступно вісім сторінок. Ми використовуємо термін “доступно” в широкому сенсі, тому що кожна сторінка знаходиться в одному з трьох станів: включена, відключена і невидима. У включеному стані сторінка показується кінцевому користувачу; у відключеному стані, сторінка не відображається.


Невидиме стан є особливим випадком, при якому сторінка не відображається, якщо тільки мінлива послідовності завдань OSD дорівнює нулю. В даному випадку на сторінці з’явиться запит на введення користувачем необхідних даних для того, щоб майстер продовжив свою роботу. (Додаткову інформацію про всі станах сторінки (включена, відключена і невидима) майстра OSD см. в блогах TechNet на blogs.technet.com / osd.) У деяких ситуаціях введення даних кінцевого користувача потрібно для окремих сторінок, а в деяких – ніякі дані не потрібні.


Наприклад, у багатьох організаціях кінцевим користувачам дозволено надавати імена для своїх машин, але не дозволяється вибирати свої домени або структурні підрозділи в каталозі Active Directory (AD). Майстер OSD простий у використанні і дозволяє відображати сторінки майстра, але не дозволяє користувачам змінювати вміст окремих даних, наприклад домену або структурних підрозділів. Ця корисна блокуюча функція доступна на всіх сторінках в конфігураційному файлі.


Крім відключення і блокування, деякі сторінки мають додаткові атрибутами, які змінюють внутрішнє поведінка майстра. Функція майстра може автоматично використовувати каталог AD для перевірки унікальності імені комп’ютера або облікових даних користувача. На сторінках з додатковими атрибутами ви можете використовувати значення для включення або відключення даних функцій без повторної компіляції майстра.


Кожна з восьми сторінок майстра OSD названа відповідно до функцією, яку вона забезпечує: привітання, попередня перевірка, комп’ютер, мережа, мова, тому, програми та ув’язнення. Давайте розглянемо ключові функції, надані деякими з цих сторінок, і обговоримо, як їх використовувати.


Ви можете оформити майстра таким чином, щоб він підходив до фірмового оформлення вашої організації. Ви можете легко зробити оформлення через конфігураційний файл, помістивши ім’я фонового малюнка в атрибут заголовка. Для зміни оформлення майстра у вашій середовищі просто створіть точковий малюнок розміром 630×100, додайте його в пакет OSD і відредагуйте конфігураційний файл. (Додаткову інформацію про оформлення см. в блозі TechNet на tinyurl.com/r7jdve.)


Однією з найбільш потужних функцій майстра є можливість здійснення ваших попередніх перевірок перед переходом на Windows 7. Наприклад, припустимо, що у вашій компанії є додаток у відділі кадрів, несумісне з Windows 7. Для зниження впливу на продуктивність користувача, створіть сценарій і призначте попередню перевірку майстру OSD будь-якого елемента, на якому програма встановлена. Грунтуючись на результати цієї перевірки, ви зможете дозволити користувачам продовжити міграцію або попередити їх про несумісних додатках.


В даний час майстер OSD має дві вбудованих попередніх перевірки, які ви можете включити або відключити в конфігураційному файлі. Ці попередні перевірки є в наявності, тому що їх можна застосувати для більшості підприємств. Першою попередньою перевіркою є контроль харчування, здійснюваний на повністю завантаженої ОС (наприклад, коли користувач робить міграцію з використанням програм RAP або AddRemove) і з’являється повідомлення про помилку. Якщо в ході попередньої перевірки виявляється, що користувач не підключений, з’явиться повідомлення про помилку, що вимагає від користувача під’єднання мережевого адаптера. Після цього користувач може клацнути вкладку Retry Pre-Flight Checks і продовжити, якщо не виникнуть інші помилки.


Другий попередньою перевіркою є контроль бездротового зв’язку. При роботі OSD вимагає великої пропускної здатності мережі і краще працює при підключенні до мережевої карти Ethernet (наприклад, провідне підключення 802.3). Якщо в ході перевірки бездротового підключення виявляється, що користувач не підключений до мережі, з’явиться повідомлення про помилку, що вимагає від користувача встановити дротове підключення до мережі.


Проте попередні перевірки не обмежені вбудованими елементами. Вони підтримують будь виконуваний файл або сценарії Windows Scripting Host, наприклад сценарії Visual Basic. Число попередніх перевірок необмежено, тому що вони можуть запускатися і закінчувати роботу протягом п’яти хвилин (якщо потрібно більше часу, майстер OSD призупинить виконання сценарію).


*


Рис.2 Майстер OSD


Кожен раз при виконанні сценарію або виконуваного файлу, код повертається до майстра OSD. В залежності від конфігурації майстра, з’явиться сповіщення про успіх, попередженні або помилку (див. рис. 2). При отриманні сповіщення про успіх або попередженні, користувач може продовжити роботу з майстром. Але при отриманні сповіщення про стан помилки, робота користувача блокується. Допустимі коди, повертаються сценарієм попередньої перевірки або вбудованим сценарієм, можна настроювати в osdconf.xml, і вони не вимагають змін у виконуваному файлі майстра. Крім того, текстовий опис помилки також можна налаштувати.
Існує два способи доставки додатків як частини розгортання Windows 7: як частина інсталяційного образу Windows Installation Image (WIM) базової версії Windows 7 або як етапи індивідуальної послідовності задач. Крім додатків для Windows 7, образ WIM часто використовується для додатків, які часто потрібні кінцевим користувачам, але не так часто оновлюються. Даний підхід має дві основні відмінності. По-перше, розмір образу збільшується, що впливає на час завантаження клієнтів; крім того, необхідно втручання адміністратора. Після кожного оновлення додатків, образ WIM вимагатиме від вас створення новий настановних образів і поновлення відповідних пакетів диспетчера Configuration Manager, пов’язаних з базовим чином.


*


Рис.3 Майстер вибору програм OSD


Для цих цілей кошти Modena добре інтегруються з функцією програми Configuration Manager 2007 Install Software для забезпечення кінцевих користувачів можливістю вибору програм, які вони хочуть встановити в якості частини процесу OSD. (Додаткову інформацію ви зможете знайти в статті журналу TechNet на http://tinyurl.com/pdfp5s.) Як показано на рис.3, Додатки перераховані в деревоподібної структурі, заснованої виключно на вашому проекті в конфігураційному файлі майстра OSD. Наприклад, ви можете визначити групу додатків на основі підрозділів, розташування або типу додатків, потім визначити всі програми для цієї групи, для установки за умовчанням. Це дає можливість простого зміни або додати програми з одним лише вимогою, щоб додаток містилося в базі даних Configuration Manager 2007 і було доступно.


Крім того, основною метою майстра є забезпечення користувачів можливістю впливати на кінцевий результат, використовуючи образ Windows 7. У середовищах, в яких передбачається робота з невеликою кількістю для користувача даних, майстер можна налаштувати на запити про мінімальну інформації; інше жорстко кодується адміністраторами в послідовності завдань.



Втрата даних: це виключено


Набір USMT 4.0 включає в себе базовий комплект конфігураційних файлів, що підтримує створення багатьох корпоративних користувальницьких середовищ. Дані конфігураційні файли, MigApp.xml і MigDocs.xml, містять більшість сценаріїв для створення призначених для користувача даних. (Додаткову інформацію про конфігураційних файлах можете знайти в статті журналу TechNet на http://tinyurl.com/okfgw4.)
Компонент OSD очистить те, в якому буде встановлена ​​операційна система Windows 7. З цієї причини дуже важливо, щоб для користувача середовища правильно і точно створювалися після кожного використання OSD. Коротше кажучи, можливість втрати інформації навіть не розглядається.


Кращий варіант, також використовується компанією Microsoft, – це створення безпечного місця розташування через послідовність завдань, яким є ваша цільова папка для вашої користувальницької середовища. Потім за допомогою змінної OSDStateStorePath вбудованої послідовності завдань OSD, ви можете виключити даний каталог з очищення томи, виробленої компонентом ОС Apply в послідовності завдань. (Ознайомитися з використанням цієї функції ви можете в блозі TechNet на blogs.technet.com / osd.)


Створення послідовності завдань для розгортання Windows 7


Засоби Modena OSD включають експортовану копію послідовності завдань OSD, яка була використана в компанії Microsoft. Експортована послідовність завдань розбита на кілька груп з іменами Master Group і Failover, і має ієрархічну структуру. Група Master Group має дочірні компоненти, пов’язані з кожним основним етапом, використовуваному при розгортанні Windows 7. Кожен з цих компонентів (Див. рис. 4) Має стану помилок, які повідомляються в групу Master Group, і далі передаються в спеціалізований компонент Failover.


Розбиття послідовності задач на дані компоненти спрощує процеси ведення журналу, створення звітів та обробки помилок. Як і у випадку з подібними складними завданнями, помилки будуть з’являтися незалежно від того, скільки часу ви витрачаєте на підготовку – це відноситься до групи Failover Group. Вона створена для збору всіх існуючих файлів журналу, необхідних для усунення проблем установки, і приміщення їх у безпечну папку OSD.


Для застосування відмовостійкості в послідовності завдань почніть роботу на кореневому рівні і створіть дві дочірні групи, Master Group і Failover. Іншим хорошим варіантом є включення в групу Master Group всіх робочих етапів, необхідних для вашого розгортання, і використання її в якості групи для продовження роботи над помилкою. Кожна дочірня група Master Group, у випадку з компанією Microsoft, має п’ять вкладених груп, показаних на рис.4, Необхідних для продовження виконання послідовності задач і настройки відмовостійкості.


*


Рис.4 Групування послідовності завдань


Інший відмінною рекомендацією є настройка будь-який з дочірніх груп, які не є критично важливими для розгортання, на продовження роботи над помилкою. Механізм послідовності завдань OSD завжди визначає необхідні дії в разі виникнення помилки, шляхом перегляду батьківського групи з метою відстеження можливості її продовження. В силу цього поведінки ви повинні визначити, повинен Чи кожен компонент призупинити роботу при виникненні помилки або продовжити. Якщо компонент не налаштований на продовження роботи при виникненні помилки, послідовність виконання завдань перейде до батьківської групі з метою визначення наступного дії. В даному проекті (Рис.4) група Master Group налаштована на продовження роботи при виникненні помилки таким чином, що вона продовжить роботу з групою Failover Group, будучи її вузлом.


Наприклад, припустимо, що група створена для запису відомостей про користувача середовищі. В силу особливої ​​важливості компонентів в даній групі, проект для кожного з них повинен гарантувати, що в разі помилки, розгортання далі не продовжиться, можливо, з подальшим видаленням томи (передбачається, що це наступний етап у вашій послідовності задач). В цьому випадку механізм послідовності завдань визначає, налаштований чи виконуваний компонент на продовження роботи при наявності помилки, а якщо ні, він повернеться до етапу батьківського групи для визначення наступного дії. Батьківська група Backup State, параметр на продовження якої при наявності помилку є неперевіреними, звернеться до свого батька, яким в даному проекті є група Master Group.


Метою створення групи Failover Group, як уже говорилося, є забезпечення факту запису всіх даних, необхідних для вирішення проблем у разі збою. Цю групу слід налаштувати як вузол групи Master Group, щоб група Master Group зверталася до неї у разі виникнення помилок (див. рис. 4). Група Failover Group ніколи не включається в роботу під час розгортання, якщо не відбувається збій, який може виявитися критично важливим. Це останній елемент послідовності задач, який запускається завжди, навіть у випадку успішної установки.


Стан розгортання грунтується на значенні, збереженому у змінній SMSTSLastActionSucceeded. Ось так використовується механізм послідовності завдань спільно з “деревом” послідовності задач, поки, зрештою, не буде отработан.В даному випадку це означає, що всі етапи групи Failover Group виконані, зібрані всі журнали записів і необхідні дані. (Додаткові відомості про проектування наведені в блозі TechNetblog на blogs.technet.com / osd.)


Надання стану користувача за допомогою точкових рисунків і BGInfo.exe


Для користувачів компанії Microsoft дуже важливо було повідомляти користувачам про поточний стан міграції в OSD. За замовчуванням, всі стани клієнта передаються через функції OSD диспетчера Configuration Manager. Хоча і ці повідомлення про стан добре працюють в деяких організаціях, існують і інші творчі методи для повідомлення користувачам про більш великих етапах, складових міграцію.


Дуже важливим є розуміння того, що існують більші етапи, які супроводжують процес міграції. Наприклад, цими етапами можуть бути Partition Drive (створення розділів на жорсткому диску), Install Windows (установка Windows) і додатки Last Install. Основною причиною всього цього є те, що дані етапи надають більш детальне визначення всього процесу, а користувачі, в свою чергу, обожнюють такого роду інформацію.


Основними п’ятьма етапами, використовуваними компанією Microsoft, є стани резервування, установки Windows, настройки Windows, установки додатків і відновлення. Користувачі отримують повідомлення за допомогою статичних точкових рисунків, які динамічно відтворюються за допомогою засобу TechNet Sysinternals BGInfo.exe. (Ви можете завантажити BGInfo.exe на сторінці tinyurl.com/2nbxmd, але це засіб не входить в інструментарій Modena OSD.) Цей засіб дозволяє завантажувати точкові малюнки і налаштовувати їх виведення на екран, для відображення поточного стану міграції.


Засіб Modena включає п’ять точкових малюнків, один для кожного етапу, і зображення, що повідомляють про стан, встановленому за допомогою послідовності завдань. Наприклад, у групі послідовності завдань Install OS (Установка ОС), засіб BGInfo.exe викликається для завантаження точкового малюнка, що відображає даний етап (див. рис. 5).


*


Рис.5 Відображення поточного стану міграції


Засіб Modena OSD надає вам платформу для розгортання цього рішення на вашому підприємстві і вимагає від вас лише заміни точкових рисунків. Для цього знайдіть папку сценаріїв, відкрийте каталог BG і замініть кожен точковий малюнок вашої оновленою версією. Цією дією ви повідомите своїм кінцевим користувачам про п’ять основних етапах, використовуваних при розгортанні Windows 7. Це буде прекрасний спосіб тримати користувачів в курсі справи, не вимагаючи від них читання докладних повідомлень, наданих механізмом послідовності завдань OSD.


Резюме


ОС Windows 7 доступна в корпоративному варіанті, але зважаючи на супутніх складнощів, багато організацій ще не починають оновлювати свою інфраструктуру. У компанії Microsoft, даний процес почався майже рік назад; ми майже стали експертами, але немає межі досконалості.


ОС Windows 7 надає кінцевим користувачам максимальну продуктивність. В кінцевому рахунку, існує одна перешкода на шляху готовності до розгортання. Компанія Microsoft пропонує користувачам диспетчер System Center Configuration Manager 2007 кошти Modena OSD для зниження часу на підготовку розгортання виходячи з рівня його складності. Якщо вашому підприємству потрібен високий рівень взаємодії з кінцевими користувачами або ви віддаєте перевагу принцип “мінімального зачіпання”, ви можете спростити ваш проект розгортання Windows 7 за допомогою процесу, який ми використовували в компанії Microsoft.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*