Как я уже сообщал на прошлой неделе, службе ConfigMgr исполнилось 25 лет. В связи с этим примечательным событием мне хотелось бы вспомнить основные вехи пройденного нами пути, сделать несколько объявлений и представить новый документальный фильм, в котором увлекательно и подробно рассматривается возникновение и развитие продукта, оказавшего решающее влияние на принципы управления компьютерами. Этот фильм был представлен на фестивале “Сандэнс”.
И еще одна радостная новость о ConfigMgr:
А теперь, в честь этого знаменательного события, предлагаю окунуться в историю и, возможно, вы откроете для себя несколько новых фактов.
Истоки
На прошлой недели я заново изучил начальную концепцию (спецификацию) проекта “Гермес”. Я не обращался к этому документу несколько лет, и мне было интересно узнать, насколько нынешний ConfigMgr соответствует исходному замыслу. Как оказалось, фундаментальные компоненты все еще на месте и формируют надежную основу современного решения.
В 1992 году корпорация Майкрософт делала упор на массовость, желая “установить компьютер в каждом доме и офисе”. Организации активно переходили с эмуляции терминала на модель распределенных вычислений на базе x86, но масштабируемое решение для управления компьютерами отсутствовало. Наши специалисты понимали, что проект “Гермес” способен в корне изменить ситуацию.
Первоначально в команду SMS входили два штатных разработчика и стажер Кен Пэн (Ken Pan). Когда в 2003 году к ним присоединился я, “стажер” Кен уже руководил всей командой разработчиков, включавшей около 150 специалистов. С тех пор я работал над SCCM и Intune под его руководством.
Любопытный факт. Первая сборка Systems Management Server (SMS) вышла под номером 245, а знаете почему? На тот момент у сборки Windows был номер 300, и команда не хотела демонстрировать слишком большое отставание в плане разработки, но число, близкое к 300, выглядело бы подозрительно. Поэтому был выбран номер 245.
Решение SMS было официально выпущено 7 ноября 1994 г. Первый выпуск не обновлялся чуть больше двух лет, зато сейчас новые сборки для программы предварительной оценки выходят ежемесячно!
Билл Гейтс тогда сообщил всем сотрудникам Майкрософт по электронной почте, что решение SMS развертывается в компании. Это был поистине великий миг. Но будучи истинным инженером, Билл не забыл указать, как удалить программное обеспечение SMS с компьютера, если оно вам не нравится.
Это сообщение размещено в конце статьи, при желании вы можете с ним ознакомиться.
Развитие архитектуры
Версии SMS 1.0, 1.1 и 1.2 были выпущены довольно быстро, и на их базе сформировался новый рынок. Команда немедленно начала работу над SMS 2.0.
И тут возникли сложности.
Сказать по правде, не все наши решения были удачными, но участники команды SMS изначально обладали одной важной способностью — они быстро учились.
С 1992 г. принципы архитектуры клиент-серверных приложений сильно изменились, и в 1997 и 1998 гг. мы фактически переписали серверную инфраструктуру SMS, чтобы улучшить масштабируемость и производительность системы. Кроме того, мы обеспечили интеграцию с запланированными к выпуску функциями Windows Server 2000. Мы полностью переработали архитектуру SMS, чтобы наше решение оставалось передовым и актуальным, и это был первый подобный опыт.
SMS 2.0 появился в январе 1999 г. и стал быстро набирать популярность. В то время я работал на крупнейшего конкурента SMS, компанию Novell, и руководил командой Novell ZENworks. Не берусь подсчитать, сколько часов я провел на встречах с пользователями SMS, рассказывая о конкурентных преимуществах ZENworks, которые сводились к активному использованию удостоверений и тесной интеграции каталога.
Кстати, пока я писал эту статью, мне напомнили, что версия SMS 2.0 содержала “пасхалку”. Это был ролик с именами и фотографиями тех, кто работал над продуктом. Я заново его просмотрел и обратил внимание на одно имя.
Терри Майерсон — мой руководитель и исполнительный вице-президент Майкрософт. Подозреваю, что в резюме у всех крутых специалистов значится работа над SMS.
Я присоединился к команде SMS, когда она приступила к активной разработке решения, которому позже дали название SMS 2003.
В нем мы тоже многое полностью переделали. Важно то, что тогда мы смогли реализовать в SMS установку исправлений через службу WSUS, что позволило потребителям и крупным предприятиям устанавливать обновления от Майкрософт через облачную службу Центр обновления Windows. WSUS фактически выполняет те же функции, что и Центр обновления Windows, но работает в вашем ЦОД.
Центр обновления Windows является одной из самых крупных облачных служб и каждый месяц обновляет более 1 млрд устройств. Задумайтесь вот о чем: что является конкурентным преимуществом Майкрософт? Ответ прост: гибридные среды и возможность использования общедоступных облачных служб в ЦОД клиентов. Технология доступа к Центру обновления Windows из ЦОД (WSUS) стала действительно новаторской. Возможно, это был первый пример гибридного решения, подключенного к облаку. В то время существенно возросла популярность ноутбуков, и мы должны были создать новый клиент, способный работать с плохим подключением к сети и даже без него.
Тем временем выпуск SMS 2003 приближался. Каждую пятницу по утрам мы проводили совещания с коллегами из разных подразделений, чтобы оценить состояние проекта. Самыми важными участниками этих собраний были сотрудники ИТ-отдела корпорации Майкрософт (MSIT). Я тогда принял беспрецедентное решение и предоставил специалистам MSIT право запретить выпуск SMS 2003, если, по их мнению, продукт еще не готов. С тех пор отдел MSIT стал нашим основным и лучшим клиентом, и они всегда охотно делятся с нами отзывами о ранних версиях сборок.
Сегодня под управлением Майкрософт находится свыше 500 тыс. компьютеров и мобильных устройств (это не считая 100 млн ежемесячно активных устройств), и эту возможность обеспечивает один только развернутый ConfigMgr. Наши внутренние службы и решения тоже обновляются с каждым новым ежемесячным выпуском. Как компания-разработчик, мы должны использовать собственные продукты — это наше кредо. Еще один любопытный факт. Моя команда курировала внутреннее развертывание ConfigMgr. И действительно, лучший способ изучить решение — начать им пользоваться!
С 2003 по 2007 гг. мы выпустили два пакета дополнительных компонентов. Мы хотели предоставить новые возможности, не дожидаясь выпуска нового продукта, поэтому придумали такой способ. В первом пакете дополнительных компонентов была полностью реализована поддержка WSUS для установки исправлений. Второй пакет обеспечивал функцию развертывания ОС.
Помню демонстрацию на мероприятии в Европе в ноябре 2003 г., когда мы показывали новые возможности развертывания ОС. Билл Гейтс был основным докладчиком, и во время его рассказа о новых возможностях SMS мы в режиме реального времени обновили 100 компьютеров, установленных на стене позади него. Мы назвали эту демонстрацию “Стеной огня”.
Это фото было снято, когда Билл обернулся посмотреть, как идет демонстрация.
А на этом фото “трое смелых” из нашей доблестной команды SMS — именно они проводили демонстрацию.
Рост влияния
Осенью 2004 г. Билл Гейтс и Стив Баллмер (Steve Ballmer) проводили выездное собрание с несколькими руководителями высшего звена компании. Под конец дня настал черед ответов на вопросы. Кто-то спросил Билла о том, какое событие прошлого года было самым значимым для Майкрософт. Билл ответил: “Мы оптимизировали SMS и Active Directory. Эти активы обладают огромным потенциалом для нашего дальнейшего развития”.
Я до сих пор вспоминаю этот день как один из лучших в моей профессиональной карьере.
В 2007 г. мы изменили название SMS на ConfigMgr, чтобы оно соответствовало торговой марке System Center. Платформа Desired State Configuration (DSC) была нашей самой последней инновационной разработкой, созданной по запросам клиентов, поэтому мы вновь усовершенствовали архитектуру, чтобы DSC работала должным образом. Мы также полностью переписали часть, связанную с администрированием.
В феврале 2011 г. во время разработки SCCM 2012 моим руководителем стал Сатья Надела (Satya Nadella), который возглавил подразделение STB, занимавшееся серверными решениями и бизнес-инструментами. По его инициативе подразделение было переименовано в отдел облачных и корпоративных решений (C+E). Наша первая встреча с глазу на глаз состоялась в моем кабинете, куда Сатья пришел сам, чтобы поближе познакомиться. Я несколько лет проработал с ним бок о бок, и это был незабываемый опыт. Я многому научился у этого человека, в котором пытливый ум и невероятная эрудиция гармонично сочетаются с исключительной скромностью и харизмой истинного лидера. Сатья оказал огромное влияние на вектор развития и архитектуру текущего выпуска ConfigMgr.
В ConfigMgr 2012 мы фактически переосмыслили концепцию. Теперь архитектура и интерфейс стали ориентироваться не только на устройства, но и на пользователей.
Клиенты говорили нам, что в будущем основную роль будет играть мобильность, и мы поняли, что это относится к мобильности сотрудников, а не только устройств. Руководствуясь этими данными, мы радикально упростили архитектуру, чтобы она была менее требовательна к оборудованию, и значительно расширили возможности масштабирования. На этом этапе интеграция с облачными службами стала действительно тесной: мы обеспечили ConfigMgr дополнительное преимущество, подключив его к Microsoft Intune.
Эта гибридная конфигурация позволила нам внедрить новый подход к облачным службам, а также расширить возможности локальной версии ConfigMgr за счет гибридного развертывания. Мы верили, что облачные службы позволят реализовать сценарии, которые в прошлом были невозможны. Сатья быстро осознал потенциальное влияние облачных служб на управление устройствами и призвал нас активнее внедрять инновации и смелее экспериментировать.
Переход ConfigMgr в облако
Следующее архитектурное улучшение оказалось самым сложным.
Когда мы узнали, что Windows 10 будет предоставляться как услуга с несколькими ежегодными обновлениями, мы поняли, что решение ConfigMgr тоже должно стать облачным и развиваться по тому же принципу.
Масштабы задачи устрашали.
Традиционно новая версия ConfigMgr выходила раз в 2–3 года. Я помню, как просматривал первый комплексный план по SCCM 2007: после завершения работы с кодом у нас было 16 месяцев на стабилизацию и бета-тестирование до выпуска продукта. Целых 16 месяцев! Было очевидно, что выпускать несколько обновлений в год мы сможем, только если будем предоставлять ConfigMgr в формате SaaS.
Для решения этой грандиозной задачи мы создали небольшую команду из тщательно отобранных кадров. Это были инженеры и руководителей программ, хорошо знакомые с ConfigMgr, способные к личностному развитию и стремившиеся к расширению клиентской базы. Мы полагали, что только небольшая узкоспециализированная команда справится с такой масштабной задачей, как радикальный пересмотр всей архитектуры и создание облачной службы с нуля.
Я вообще-то оптимист, но при взгляде на наш график меня охватывали сомнения. Осилить такой колоссальный объем в столь сжатые сроки — ей-богу, задача казалась невыполнимой.
И все же мы справились. Наша узкоспециализированная инженерная команда ни на йоту не отступила от графика и вовремя представила новый облачный подход к управлению компьютерами, который позволил нам перейти на ежемесячный цикл выпуска обновлений. Чтобы следить за этими обновлениями, мы отказались от традиционных номеров версий (2003, 2007, 2012) и стали использовать формат с указанием года и месяца. Таким образом, первый выпуск шел под номером 1511, так как появился в ноябре 2015 г.
С тех пор новая версия ConfigMgr для программы предварительной оценки выходит ежемесячно, а крупные обновления Current Branch — примерно раз в 4 месяца.
Несомненно, это один из самых невероятных технических проектов, в которых я когда-либо принимал участие.
Клиенты с восторгом восприняли нашу новую облачную модель.
Посмотрите на график.
Уже больше половины клиентов ConfigMgr выполнили обновление до новой модели Current Branch, и сейчас более 100 млн устройств являются активно управляемыми и отсылают нам свою телеметрию.
Вы только вдумайтесь в эту цифру!
Насколько мне известно, в мире есть только 3 корпоративные службы, у которых в активном управлении находится свыше 100 млн активных пользователей или устройств, регулярно отправляющих свою телеметрию: Office 365, Azure Active Directory и ConfigMgr. Что между ними общего? Все они входят в состав интегрированного предложения Microsoft 365.
На этой диаграмме показано принятие основных выпусков ConfigMgr Current Branch, начиная с версии 1511. У нас есть панель мониторинга, на которой эти данные отображаются в режиме реального времени. Каждое воскресенье в 8:30 утра эта диаграмма рассылается всем участникам нашей команды.
Вы не поверите, но 8:30 утра воскресенья — один из самых радостных для меня моментов за всю неделю.
Итак, мы смогли добиться рекордно быстрого обновления ConfigMgr, и, как видите, с каждым выпуском кривая принятия взлетает все выше и круче. Поначалу мы беспокоились о том, как сообщество ConfigMgr отреагирует на столь быстрый выпуск обновлений, поэтому нас так тронули и воодушевили ваши вера и доверие.
Работа над проектом “Гермес” никогда еще не была такой интересной и увлекательной.
Дальнейшие планы
Мы начали переход в облако с ConfigMgr Current Branch версии 1511 в ноябре 2015 г. В то время мы совершенно отчетливо понимали необходимость этого важного шага. Мы также понимали, как много нам еще предстоит сделать.
С момента выхода версии 1511 скорость внедрения инноваций постоянно растет. Организации стремительно переходят в мир облачных служб и подключенных к ним мобильных устройств. Чтобы удовлетворить быстро меняющиеся запросы клиентов и превратить ConfigMgr в полноценную облачную службу, нам пришлось существенно преобразовать его инфраструктуру. Теперь у него постоянно появляются новые возможности, он использует облачные функции искусственного интеллекта, чтобы соответствовать вашим потребностям и обеспечивать необходимую защиту, и способен поддерживать сотни миллионов устройств по всему миру.
Мне вспоминается самая острая проблема, о которой то и дело упоминают руководители ИТ-отделов из самых разных стран: их удручает сложность систем и приложений, которыми им приходится пользоваться для выполнения своих задач. Организации стремятся упростить развернутые решения, им также нужен универсальный способ активации пользователей на всех устройствах, который мог бы обеспечить необходимый уровень контроля и безопасности. Вот поэтому мы и создали Microsoft 365. С M365 вы получаете современное, безопасное рабочее пространство и интегрированные облачные службы, которые расширяют возможности пользователей. Это решение обеспечивает многофункциональную и эффективную рабочую среду, которая нравится пользователям и вызывает доверие у ИТ-специалистов.
Это следующий этап развития всех продуктов корпорации Майкрософт, которыми вы пользуетесь уже много лет, — Windows, Office, Active Directory, ConfigMgr. Благодаря Microsoft 365 мы смогли перенести их в облако. Корпоративные клиенты по всему миру переходят на работу в облако (на базе Windows 10 как услуги, Office 365 и служб EMS), и это закономерный следующий этап развития архитектуры ConfigMgr.
Почти каждая корпорация и коммерческая организация на планете начинала с использования локальной модели, а теперь применяет Active Directory, групповые политики и ConfigMgr в качестве инструментов управления. В мире много желающих перейти на более простую и современную модель управления, но это не так-то просто. Организация не может просто щелкнуть пальцами и перевести пользователей и устройства с AD, групповых политик и ConfigMgr на AAD и Intune. И это наша задача — помочь вам упростить и ускорить этот переход и устранить риски. Мы получили полезный опыт, наблюдая за переходом организаций с локальной версии Exchange на Exchange Online.
И сегодня мы представляем совместное управление — новый набор возможностей, который поможет вам быстрее перейти на современную облачную модель управления. Благодаря Fall Creators Update устройство с Windows 10 может одновременно подключаться к локальной версии Active Directory (AD) и Azure AD.
Функция совместного управления использует это улучшение и позволяет управлять устройствами с помощью агента ConfigMgr и Intune MDM. Переход к современному управлению больше не похож на прыжок в неизвестность. Совместное управление обеспечивает поэтапный переход в облако в удобном для вас режиме.
Мы упростили работу в консоли ConfigMgr, и теперь вы можете выбрать устройства, которые станут управляемыми, и зарегистрировать их для передачи под управление Intune. Затем вы можете выбрать первую рабочую нагрузку и перенести ее в облако (для этого вам достаточно передвинуть ползунок с ConfigMgr на Intune).
Такой сценарий совместного управления в Microsoft 365 имеет одну уникальную особенность. Дело в том, что ConfigMgr и Intune постоянно обмениваются данными. По мере переноса нагрузок выясняется, какое решение (Intune или ConfigMgr) служит авторитетным источником для каждого атрибута пользователя и устройства, что позволяет предотвращать конфликты политик.
Это значительно ускоряет переход к Windows 10 и современному облачному управлению.
* * * * *
Работая над этой статьей, я словно совершил увлекательное путешествие в прошлое. Решение SMS/ConfigMgr/Intune оказало огромное влияние на мою жизнь, жизнь моей семьи, жизни тысяч инженеров, которые работали над этим проектом, и жизни миллионов ИТ-специалистов, которые использовали и продолжают использовать его сегодня. Я люблю этот продукт и люблю это сообщество.
Мне также очень нравится документальный фильм о том, как создавалось решение ConfigMgr, однако мы сняли только первую часть. Вторая часть гораздо важнее, поскольку ее будете создавать вы.
Если вы участник конференции Ignite, приглашаем вам в секцию управления и безопасности в павильоне Майкрософт, где вы сможете поделиться своей историей. Несколько простых рекомендаций вы найдете в этом видео.
Впрочем, вам не обязательно присутствовать на Ignite, чтобы принять участие в создании фильма. Просто откройте страницу aka.ms/ConfigMgr25 и отправьте свой рассказ о ConfigMgr. Основные инструкции см. здесь.
Мы используем эти материалы, чтобы создать вторую часть фильма, которую я бы назвал
“История ConfigMgr глазами пользователей”.
Уверен, это будет нечто потрясающее.
_______________________________________________
