Я планирую перейти с System Center Essentials 2010 на Configuration Manager и Operations Manager. Я много знаю о первом, мало знаю о последних двух, поэтому, прежде чем я начну вникать в него, я хотел бы прояснить несколько вещей.
Прежде всего, я считаю, что SCE на 90% контролирует, очень похоже на SCOM, а оставшиеся 10% - это управление конфигурацией, но в отличие от SCCM, он может устанавливать собственные пакеты через WSUS, и все, это очень простая вещь. Вот почему на клиентах я вижу агент SCOM, но не вижу агента SCCM. Я прав?
Мне не нужно хранить какие-либо данные от SCE, так что, думаю, мне повезло. Поэтому я просто удалю SCE, а затем установлю SCOM и SCCM на сервер. Я знаю, что должен разместить их на разных серверах, но я не могу, на одном сервере много ресурсов, и никто не говорит, что это не сработает.
Интересная часть - миграция агентов SCOM. Они были развернуты вручную из консоли SCE, без интеграции с AD. Если я установлю SCOM и включу интеграцию с AD, найдут ли агенты SCOM новый сервер или мне придется заново настраивать каждый из них вручную? Я знаю, что SCE устанавливает агентов SCOM 2007 R2, и я очень надеюсь, что интеграция с AD - это то, что нужно для решения этой проблемы, иначе мне это очень не понравится.
Итак, у меня есть опыт работы с SCE, исходя из моего понимания, это означает, что мне нечего будет много узнавать о SCOM, но SCCM будет совершенно новым. Итак, последний вопрос, похож ли он на SCOM: я включаю интеграцию с AD, агенты устанавливаются автоматически, они будут готовы выполнять мои приказы, но в противном случае они никак не повлияют на системы? Я имею в виду, что обычно я не устанавливаю программное обеспечение, которого не понимаю, но если у меня нет времени на изучение всех аспектов SCCM, но я все же решаю установить агентов, они не причинят никакого вреда, верно?
Здесь я предполагаю, что вы выполняете обновление, потому что вы достигли пределов 50 серверов Windows и / или 500 клиентских ПК с Windows в SCE, потому что я не вижу другого четкого экономического обоснования для переключения.
Мой опыт работы с SCCM не выявил снижения производительности из-за установки клиентов SCCM или каких-либо конкретных конфликтов с другим программным обеспечением, которое мы запускаем, но если вы используете здесь критически важные системы, было бы разумно провести некоторое тестирование или получить некоторые (оплаченные за ) совет от вашего поставщика.
Что может представлять интерес в зависимости от того, что вы используете, так это то, что есть некоторые функции агента SCCM, которые требуют перезагрузки клиента, прежде чем они будут работать правильно, или требуют .NET, что потребует перезагрузки. Если вы не можете позволить себе время простоя для ПОЛНОЙ установки клиента и его необходимых компонентов, то вы можете не получить то значение, на которое рассчитывали.
Одной из таких функций является диспетчер желаемых конфигураций, который позволяет вам определять «базовые» конфигурации, которым должны соответствовать все ваши компьютеры, а затем составлять отчеты о системах, которые им не соответствуют. Это также позволяет вам передавать изменения реестра и другие изменения конфигурации в ваши системы - если память работает правильно, это была та часть клиента, которая не была четкой.
Что касается отправки обновлений Windows и развертывания программного обеспечения, SCCM просто оборачивается вокруг WSUS и других механизмов развертывания. Если это все, что вам нужно, возможно, вам понадобится WSUS или комплекты развертывания. Например, SCCM помогает развернуть Windows на серверах и ПК, но всего этого можно добиться с помощью других инструментов и приложив немного больше усилий. На самом деле кривая обучения SCCM довольно крутая, поэтому вы можете потратить Меньше время на выяснение сценариев автоматической установки и т. д.
В общем, я советую вам перед покупкой посмотреть, что вы ожидаете получить от SCCM. Если вам нужно лишь небольшое количество из его многочисленных функций, потратьте некоторое время на поиск альтернатив для этих функций.