ConfigMgr 25 років

Наприкінці минулого тижня я писав про визначну річницю (чверть століття) ConfigMgr. Сьогодні я б хотів зануритися ще глибше в історію цього неймовірного продукту, зробити кілька оголошень і представити новий дивовижний документальний фільм (стережися, Санденс!), що докладно описує становлення та розвиток рішення, завдяки якому з’явилася галузь керування ПК.

Ось наше оголошення щодо ConfigMgr!

З нагоди згаданої вище річниці пропоную дізнатися історію, яку ви раніше не чули.

Перші кроки

Наприкінці минулого тижня я скористався нагодою перечитати оригінальний документ-концепцію або “специфікації” проекту “Гермес”. Я не бачив цього документа кілька років, тому був вражений, наскільки ConfigMgr відповідає початковій концепції. Фундаментальні принципи, закладені в тому документі, усе ще використовуються й залишаються основою для подальшої роботи.

У 1992 році першочергове завдання корпорації Майкрософт (з якою пов’язують так званий ПК в кожному домі та на кожному робочому столі) – просто завоювати якомога більше користувачів. Організації активно переходили від термінальної емуляції до моделі розподілених обчислень x86, але рішення для масштабного керування ПК тоді не існувало. Команда розробників вірила, що проект “Гермес” матиме вагоме значення.

Спочатку над продуктом SMS працювала команда з двох розробників і стажера на ім’я Кен Пан.  Коли я приєднався до колективу в 2003 році, стажер Кен очолював цілу команду розробників, до складу якої входили 150 спеціалістів. З того часу Кен керував для мене проектними роботами над SCCM та Intune!

Цікавий факт:  перша збірка Systems Management Server (SMS) мала номер 245. Чому не 1? Що ж… Остання збірка ОС Windows у той час мала номер 300. Хлопці не хотіли, щоб їхній продукт надто сильно відставав, проте усвідомлювали, що цифра, надто близька до 300, викличе підозри. Тому вони вибрали 245!

SMS офіційно запустили 7 листопада 1994 року. Для підготовки першого випуску знадобилося трохи більше двох років. Тепер ми випускаємо нові збірки для оцінювачів щомісяця!

Важливою подією з моменту запуску став електронний лист, надісланий Біллом Гейтсом кожному працівнику корпорації Майкрософт, з інформацією про те, що SMS розгортається в середовищі компанії. Професійний інженер Білл указав у тому листі, як видалити програмне забезпечення SMS із комп’ютера, якщо в цьому виникне потреба. (:

Ті, кому цікаво переглянути лист, може ознайомитися з ним під цим дописом.

Розвиток архітектури

Випуски SMS 1.0, 1.1 та 1.2 з’явилися досить швидко, і новий ринок почав поступово розвиватися. Без затримок команда почала роботу над SMS 2.0.

Ось тоді все дещо… ускладнилося.

І, якщо чесно, ми прийняли кілька поганих рішень. Важлива складова образу мислення, орієнтованого на професійне зростання, – це здатність швидко навчатися. Фахівці, що працювали над SMS, дотримувалися цього принципу від самого початку.

З 1992 року архітектура програм типу “клієнт-сервер” значно змінилася, через що команда істотно переписала код інфраструктури сервера SMS в 1997 і 1998 роках, щоб підвищити його функціональний рівень і продуктивність. Водночас були інтегровані нові можливості Windows Server 2000. Це перший раз, коли архітектура SMS була переписана для відповідності рівню технологічного розвитку, досягнутому на той момент.

SMS 2.0 випущено в січні 1999 року. Зросли масштаби, з якими його впроваджували та використовували. У той час я працював на найбільшого конкурента SMS, Novell, очолюючи команду розробників Novell ZENworks. Не злічити годин, які я провів, зустрічаючись із клієнтами SMS і розповідаючи про переваги ZENworks, які полягали в увазі до користувачів (ідентичностей) і глибокій інтеграції з Directory!

Під час підготовки цього допису мені нагадали, що пакет SMS 2.0 включав інформацію-сюрприз. Це було відео з іменами й фотографіями людей, які працювали над продуктом. Коли я знову переглянув цей запис цього тижня, одне ім’я виділилося з-поміж інших.

Так, Террі Майерсон – мій керівник і виконавчий віце-президент корпорації Майкрософт. Схоже, усі визначні особистості нашої компанії працювали над SMS на якомусь з етапів своєї кар’єри.  (:

Я приєднався до команди розробників SMS, коли йшла підготовка до випуску пакета керування SMS 2003.

Для версії SMS 2003 значні фрагменти коду продукту знову-таки переписали. На той момент важливо було узгодити SMS зі службою WSUS, щоб застосувати виправлення. Це дало змогу узгодити оновлення від корпорації Майкрософт, що завантажувалися з хмари (Windows Update) для окремих споживачів і корпоративних клієнтів. WSUS, по суті, – аналог Windows Update, але запускається в локальному центрі обробки даних.

Windows Update – одна з найбільших у світі хмарних служб, через яку оновлюються понад 1 млрд пристроїв щомісяця. Задумайтеся про це на хвилину:  одна з ключових відмінностей загальнодоступної хмари Microsoft на сьогоднішній день – гібридні функції та можливість запускати її (фактично) у локальному центрі обробки даних. Запуск Windows Update у локальному центрі обробки даних (WSUS) – дійсно революційне рішення та, можливо, один із перших прикладів використання хмарної й гібридної моделей інфраструктури. У ті часи також стрімко переходили на ноутбуки, і нам потрібно було створити новий клієнт, який функціонував би за умов повної або часткової відсутності підключення.

Ближче до дати випуску версії SMS 2003 ми почали збиратися з колегами з різних відділів компанії щоп’ятниці вранці, щоб обговорити, на якому етапі знаходиться проект. Одними з ключових учасників нарад були представники IT-відділу Microsoft (MSIT). Я зробив безпрецедентний крок – надав фахівцям ІТ-відділу право вето на рішення про випуск SMS 2003, якщо вони вважатимуть, що воно ще не готове. З того часу MSIT став нашим першим і найкращим клієнтом, а також одним із найнадійніших джерел зворотної інформації про ранні збірки.

Сьогодні ми керуємо понад 500 000 ПК та мобільних пристроїв корпорації Майкрософт (це число не включено в 100 млн пристроїв, керування якими здійснюється за допомогою Microsoft Active Directory), розгорнувши лише ConfigMgr. Ми постійно розгортаємо нові випуски в корпорації Майкрософт, які виходять щомісяця. Ми беззаперечно використовуємо власні продукти. Інший цікавий факт:  моя команда фактично контролює внутрішнє розгортання ConfigMgr. Найкраще навчатися на практиці!

Між 2003 і 2007 роками ми випустили пакети нових функцій. Ми не хотіли чекати на випуск нового продукту, щоб запровадити додаткові можливості, тож вигадали цей спосіб. З першим пакетом нових функцій завершилася робота з узгодження виправлень із WSUS. Другий пакет додаткових компонентів вийшов разом із пакетом розгортання ОС.

Одним із моїх найулюбленіших спогадів про цей період стали презентації під час заходу в Європі в листопаді 2003 року, які представляли пакет розгортання ОС. Білл Гейтс виступав із доповіддю. Коли він перейшов до частини “Новини про SMS”, ми в режимі реального часу оновили 100 ПК на стіні за спиною Білла. Ми назвали цю презентацію “Стіна вогню”.

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

Ось фотографія відважних представників команди розробників SMS, які підготували презентацію.

Неймовірний вплив

Восени 2004 року Білл і Стів провели виїзну нараду з кількома топ-менеджерами компанії. Кінцевим пунктом програми була бесіда у формі запитань і відповідей за участі Білла та Стіва.  Хтось попросив Білла назвати найважливішу подію, що сталася в житті корпорації Майкрософт за останній рік. Білл відповів: “Ми підготували SMS і Active Directory – це неймовірні ресурси для нашого подальшого розвитку”.

До цього дня той момент – один із найкращих у моїй професійній кар’єрі!

У 2007 році ми змінили назву з “SMS” на “ConfigMgr”, щоб узгодити її з брендом System Center. Служба Desired State Configuration (DSC) стала новим інноваційним рішенням, потрібним нашим клієнтам. Тож ми знову вдосконалили архітектуру, щоб забезпечити належну роботу DSC. Також ми повністю переробили інтерфейс адміністрування.

У лютому 2011 року, на півдорозі до випуску SCCM 2012, Сатья очолив підрозділ Server and Tools Business (STB), перейменував його на Cloud and Enterprise (C+E) і став моїм керівником. Наша перша особиста зустріч відбулася в моєму кабінеті. Сатья приділив справді багато часу, щоб просто познайомитися зі мною. Працювати під безпосереднім керівництвом Сатьї протягом кількох років і вчитися з його неймовірної прискіпливості, установки на професійне зростання й лідерства з позиції покірного слуги було просто неймовірно. Сатья дуже вплинув на майбутнє й архітектуру ConfigMgr під час роботи над цим випуском.

У ConfigMgr 2012 ми фактично перевернули архітектуру з ніг на голову, зосередивши увагу на користувачах, а не лише на пристроях.

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

Така гібридна конфігурація перетворилася на модель, що дала нам змогу впроваджувати інновації в хмарі, а потім розширювати функціональність локального рішення ConfigMgr шляхом гібридного розгортання. Ми були переконані, що хмара дасть змогу реалізувати сценарії, неможливі в минулому. Сатья також розпізнав потенційний вплив хмарних технологій на керування пристроями. Він постійно закликав нас до інновацій і експериментів у цій сфері.

ConfigMgr: перехід у хмару

Наступний етап еволюції архітектури виявився найскладнішим за весь час роботи над нею.

Коли ми дізналися, що Windows 10 надаватиметься як послуга з багаторазовим оновленням щороку, то зрозуміли, що ConfigMgr потрібно адаптувати відповідним чином і переносити в хмару.

Це завдання викликало острах.

Так історично склалося, що нові випуски ConfigMgr виходили з інтервалом у 2–3 роки. Пригадую, як переглянув перший загальний план реалізації проекту SCCM 2007 і помітив, що на етап стабілізації та бета-тестування перед випуском продукту виділено 16 місяців. 16 місяців!   Зрозуміло, що для того, щоб випускати оновлення кілька разів на рік, до ConfigMgr потрібно застосувати модель SaaS.

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

Визнаю, що графік проведення цієї модернізації я оцінив скептично, незважаючи на мою природну схильність до оптимізму. Реалізувати план так швидко здавалося неможливим.

Результат тепер очевидний:  вузькоспеціалізована команда інженерів перевищила всі очікування й розробила новий підхід до керування ПК на базі хмарних технологій, що дало нам змогу випускати оновлення щомісяця. Щоб відстежувати ці оновлення, ми відійшли від традиційної нумерації версій (наприклад, 2003, 2007, 2012) і замість цього почали називати їх за роком і місяцем виходу. Тому перший випуск мав номер 1511, оскільки вийшов 11-го місяця 2015 року.

З того часу ми випускаємо нову версію ConfigMgr для оцінювачів щомісяця, а основні оновлення, Current Branch, виходять приблизно кожні 4 місяці.

Це, без сумніву, одне з найскладніших технічних завдань, яке мені коли-небудь доводилося виконувати.

Тепер користувачі отримували оновлення через хмарну, і їхня реакція була неймовірною.

Графік оновлень

Трохи більше половини клієнтської бази ConfigMgr вже встановили оновлення Current Branch. Зараз ми активно керуємо понад 100 млн пристроїв і збираємо телеметричні дані.

100 мільйонів! Неймовірно!!!

Мені відомі лише 3 корпоративні служби у світі, які охоплюють понад 100 млн активних користувачів або пристроїв і повертають телеметричні дані:  Office 365, Azure Active Directory та ConfigMgr. Що спільного мають ці три продукти?  Усі вони – складова інтегрованого рішення Microsoft 365.

На цій схемі представлено, як упроваджувалися основні випуски оновлень Current Branch для ConfigMgr, починаючи з версії 1511. У нас є інформаційна панель, на якій у режимі реального часу відображаються дані. Щонеділі о 08:30 ми надсилаємо цю діаграму всій команді.

Ви й не уявляєте, як я люблю ці недільні ранки.

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

Проект “Гермес” іще ніколи не користувався таким інтересом і прихильністю.

Подальші вдосконалення

Перехід до хмарних технологій для ConfigMgr ми почали з випуску оновлень Current Branch 1511 у листопаді 2015 року. Тоді було очевидно, що ми робимо найважливіший крок до своєї мети. Також ми розуміли, що ще багато чого потрібно зробити.

Після виходу версії 1511 інтенсивність, з якою ми впроваджували інновації, лише зростала. Організації активно переходять на хмарні служби й обслуговувані з їх допомогою мобільні пристрої. Щоб задовольнити потреби клієнтів за таких умов, ми зробили великі кроки та перетворили інфраструктуру ConfigMgr на істинно хмарну службу. Тепер це служба, для якої постійно виходять нові функції. Вона використовує можливості штучного інтелекту, щоб адаптуватися до ваших потреб і забезпечити необхідний рівень захисту. Це рішення надається як хмарна служба, здатна масштабуватися й охоплювати сотні мільйонів пристроїв у всьому світі.

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

Це наступний етап еволюції всіх продуктів Microsoft, якими ви вже користуєтеся багато років (Windows, Office, Active Directory, ConfigMgr). Нам вдалося перенести їх усі в хмару за допомогою Microsoft 365.  Корпоративні клієнти в усьому світі переходять на хмарні технології (застосовуючи для цього Windows 10 як послугу, Office 365 і служби EMS). Це природний наступний етап еволюції архітектури ConfigMgr.

Сьогодні практично кожна компанія та комерційна організація на планеті починає з локальної моделі, що передбачає такі інструменти керування, як Active Directory, групова політика й ConfigMgr. Прагнення перейти до простішої та сучаснішої моделі значне, проте зробити це не так просто. Не можна одним порухом пальця перенести користувачів і пристрої з AD, GP й ConfigMgr до AAD та Intune. Користувачам знадобиться проміжне рішення, що спростить і прискорить перехід, а також дасть змогу уникнути ризиків. Ми багато про це дізналися, спостерігаючи за переходом організацій від локального рішення Exchange до Exchange Online.

Сьогодні ми з радістю оголошуємо про впровадження спільного керування – нового набору функцій і проміжної ланки, яка допоможе прискорити перехід до сучасних методів керування за допомогою хмарних технологій. За допомогою Fall Creators Update пристрій із Windows 10 можна одночасно пов’язати зі службами Active Directory (AD) і Azure Active Directory.

Спільне керування використовує переваги цього вдосконалення й дає змогу керувати пристроєм за допомогою агента ConfigMgr та Intune MDM. Перехід до сучасних методів керування більше не нагадує стрибок зі скелі. Використовуючи спільне керування, можна здійснити поетапний перехід на хмарні технології в спосіб і зі швидкістю, що відповідають потребам вашої організації.

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

Одна з унікальних особливостей спільного керування через Microsoft 365 полягає в постійній взаємодії ConfigMgr та Intune. Під час перенесення робочих навантажень ми визначаємо повноважне джерело (Intune чи ConfigMgr), відповідальне за кожен атрибут користувачів або пристроїв, завдяки чому застосувати конфліктні політики неможливо.

Це значно прискорить перехід до Windows 10 і сучасних методів керування з хмари.

* * * * *

Готуючи це допис, я занурився в надзвичайно приємні спогади. Продукти SMS, ConfigMgr та Intune справили вагомий вплив на моє життя, а також життя моєї сім’ї, тисяч інженерів, залучених до роботи над проектами, і мільйонів IT-фахівців, які продовжують використовувати ці рішення й сьогодні. Я обожнюю цей продукт і спільноту.

Мені також дуже сподобався сьогоднішній документальний фільм про історію ConfigMgr. Але це лише перша частина історії. Друга частина набагато важливіша. Це через те, що її авторами маєте стати ви.

Завітавши на конференцію Ignite, зупиніться біля стенда корпорації Майкрософт, присвяченого технологіям керування пристроями та безпеці, і поділіться своїм досвідом. За цим посиланням ви знайдете прості поради про те, що саме потрібно зробити.

Якщо відвідати Ignite у вас немає можливості, узяти участь усе одно дуже просто. Завантажити свої спогади й розповіді про ConfigMgr можна сюди: aka.ms/ConfigMgr25. Тут ви дізнаєтеся, що саме потрібно зробити.

На основі отриманих матеріалів ми створимо другу частину історії – відео під назвою

“Історії користувачів про ConfigMgr”.

З нетерпінням чекаю на нього.

_______________________________________________