CM: Невозможно выбрать .exe файл при выборе иконки приложения

После обновления Configuration Manager 2012 до Service Pack 1 столкнулся со следующей проблемой — при выборе иконки для приложения отображаются только .dll, .ico, и .jpg файлы, хотя до обновления была возможность выбирать и .exe файлы. Следует заметить, что и в SP1 в окне выбора в списке .exe файлы также присутствуют.

Browse

По этой ошибке уже создано обращение разработчикам — https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/774677/configmgr-2012-sp1-rtm-open-file-dialog-only-displays-dll, так что при возможности жмите кнопку вверх 🙂 На самом деле этот досадный факт не должен останавливать Вас от обновления до Service Pack 1, т.к. это лишь ошибка в регулярных выражениях в консоли и если Вы укажете прямой путь до .exe файла, то иконку также получится выбрать.

Реклама

CM: Configuration Manager 2012 vs Windows Server 2012

ВНИМАНИЕ!!!

Для тех, кто устанавливает клиенты ConfigMgr 2012 на Windows Server 2012 и Windows 8 — это неподдерживаемое решение… Совсем… Более того, есть угроза вывести данные операционные системы из строя. Для тех, кто не в курсе, в ConfigMgr 2012 появился новый функционал, который проверяет здоровье клиента. Проверка здоровья проходит по расписанию из Task Scheduler запуском программы CCMEval.exe. Данная программа не расчитана для новых операционных систем и при каждой проверке считает, что репозиторий WMI неисправен и заново его пересобирает. Это может стать потенциальной угрозой. Есть несколько решений данной проблемы:

  1. Отключить задание в Task Scheduler
  2. Использовать пре-релиз версии ConfigMgr 2012 Service Pack 1
  3. Дождаться окончательного релиза ConfigMgr 2012 Service Pack 1 и использовать его

Сразу замечу, что поддерживаемое решение только под номером 3!

CM: На заметку администраторам Configuration Manager

InformationalВозможно, данная статья будет выглядеть, как навязывание чего-то своего, но в любом случае приведу несколько ошибок, советов и решений. Начну с самых грубых ошибок, которые доводилось встречать на просторах интернета.

Никогда… Совсем никогда не давайте учетной записи Network Access Account права Domain Admin. На это есть несколько причин – его совершенно легко получить, а о последствиях обнародования данного аккаунта в руках третьих лиц можно только догадываться. Данному аккаунту достаточно прав аутентифицированного пользователя.

Также не давайте права Domain Admins и учетной записи Join Account. Это также небезопасно, т.к. пароль этой учетной записи лежит в открытом виде. Достаточно делегировать данной учетной записи права на добавление компьютеров в Active Directory.

Прежде чем что-то нажать, будьте уверены в том, что делаете. Не знаете – не лезьте. Лучше прочитайте инструкции или спросите у знающего коллеги, иначе, велик шанс откатить все компьютеры компании к дефолтной операционной системе, а Вас откатить к бирже труда.

Если Вы подумали «спасибо, Кэп», то это хорошо 🙂 Страшилки закончились и дальше пойдут удобняшки.

Начну с самого простого. Создайте группу в AD, в которую Вы будете помещать все сайт-серверы Configuration Manager. Имея несколько сайт-серверов, вам не придется постоянно добавлять в список ACL контейнера System Management новый сервер и назначать ему права, достаточно один раз дать эти права группе. Это удобно и красиво.

Используйте UNC пути при создании пакетов… Даже если вы храните весь свой софт на одном единственном сервере Configuration Manager, создайте на нем шару и используйте UNC пути.

Две строки назад я писал про UNC пути? Так вот, используйте UNC пути на основе Domain Based DFS-N. Это офигительно удобно, а в нашем случае это еще и функционально. Нам не нужно что-то придумывать в случае, если закончится место на диске – достаточно создать виртуальный каталог и добавить новую шару нового сервера… В конце концов, можно просто всё скопировать на сервер с большими объемами дискового пространства и поменять целевой сервер в оснастке DFS.

Разработайте политику именования папок, коллекций, списков обновлений и т.д.. Вам же будет проще. Я стараюсь использовать следующую модель для пакетов программного обеспечения: \\<DOMAIN>\ConfigMgr\Software\<Software Developer>\<Product Name>\<Language>. Можно добавить версию, убрать язык – это не меняет сути подхода. Старайтесь указывать всё буква в букву. Возможно, это Вам же пригодится при использовании очередного скрипта.

Не забывайте про возможность использовать в строке запуска программ системные переменные. Ведь лучше создать один пакет (если его размер имеет вменяемые размеры) и одну программу для двух разных процессорных архитектур, чем два пакета с меткой x86 и x64, собственной программой, назначением и фильтрами. Пакет с двумя папками AMD64 и x86, в каждой из которых лежит программа setup.exe и строка запуска %PROCESSOR_ARCHITECTURE%\Setup.exe /s выглядит более профессионально и требует меньших настроек.

Ну и напоследок. Старайтесь использовать в удаленных филиалах Secondary Sites, если это возможно. Опять же, это удобно, а с использованием Bing Maps в ConfigMgr 2012 еще и красиво. Помните! Высшему руководству нравятся картинки :).

Естественно, это далеко не всё, но надеюсь, что-то из этого  пригодится и что именно – решать в первую очередь Вам!