Как я могу определить, какие клиенты вызывают сбой при обновлении моего дистрибутива?

Это случается время от времени. Я обновляю пакет и мне нужно обновить точку распространения. У нас есть несколько DP, и обычно все проходит нормально, однако время от времени наш основной DP не может обновить пакет.

Скриншот 1 Failed DP

Журнал состояния содержимого никогда не говорит о сбое. У меня нет доступа внутреннего сервера к точкам управления или DP, я просто администратор SCCM. Я могу проверить любые журналы в SCCM, запустить отчеты и все, но я не знаю, где искать.

Раньше я пытался установить параметр «Отключить пользователей от точки распространения» в пакете проблем, оба значения были равны 0, но у нас это не сработало. Кажется, что проблема через некоторое время проходит сама собой, но иногда это занимает несколько дней. Для большинства (на самом деле всех, но может быть один или два, которые я упустил из виду), мы устанавливаем клиенты на «Запуск программы из точки распространения». При развертывании программы не уверены, имеет ли это какое-либо отношение к этому, или каков root причина есть.

Обновить

Я нашел немного больше информации в отчетах, в частности, All Status Messages for a Specific Package at a Specific Siteзапрос. Используя мой идентификатор пакета для запроса, после сбоя обновления DP я увидел одну заметную запись:

Диспетчеру распространения не удалось обработать пакет «Обновления конфигурации» (идентификатор пакета = SOM00013).

Возможная причина : диспетчер распространения не имеет доступа ни к исходному каталогу пакета, ни к точке распространения. Решение. Убедитесь, что диспетчер распространения может получить доступ к исходному каталогу / точке распространения пакета.

Возможная причина : исходный каталог пакета содержит файлы с длинными именами файлов, а общая длина пути превышает максимальную длину, поддерживаемую операционной системой. Решение. Уменьшите количество папок, определенных для пакета, сократите имя файла или рассмотрите возможность объединения файлов с помощью утилиты сжатия.

Возможная причина : на компьютере сервера сайта или в точке распространения недостаточно места на диске. Решение. Убедитесь, что на компьютере сервера сайта и в точке распространения достаточно свободного дискового пространства.

Возможная причина : исходный каталог пакета содержит файлы, которые могут использоваться активным процессом. Решение. Закройте все процессы, которые могут использовать файлы в исходном каталоге. Если этот сбой сохраняется, создайте альтернативную копию исходного каталога и обновите источник пакета, чтобы он указывал на него.

Я сомневаюсь в двух средних причинах по простым причинам

Исходная папка не настолько глубока, чтобы содержать длинные имена файлов для NTFS, хотя я попытаюсь проверить ее полноту.
Я могу добавить файлы в DP просто отлично, так что это не проблема файлового пространства, другие пакеты могут быть обновлены просто отлично.

Чего я не ожидал, так это того, что третья причина говорит, что каталог источника где-то используется. Какая разница, в любом случае? Разве это не просто копирование файлов с файлового ресурса в SCCM DP Share? Далее, бросая меня за петлю, клиенты b / c даже не обращаются к исходному каталогу, это всего лишь промежуточный каталог, из которого sccm копирует файлы.

Это просто оставляет первопричину, но опять же возвращается к тому же: другие пакеты могут обновляться очень хорошо.

sccm sccm-2012 MDMoore313
источник

Я бы начал с просмотра встроенного отчета в разделе «Обновления программного обеспечения - E».

Гарт Джонс

Вы проверили логи самих клиентов? Я обычно начинаю с $ env: windir \ ccm \ logs \ wuahandler.log Ищите строки с флагами ERROR и WARNING. Обновление будет выглядеть так (я схожу с ума; у меня нет машины Windows для вырезания-вставки) 1) Скажите, что скоро начнется обновление. Эта часть занимает много строк, потому что они хотят, чтобы она выглядела симпатично 2) Скажите, кто является сервером SCCM, который получает файлы 3) Укажите, что он проверяет файлы и какие пакеты, если таковые имеются, он получает 4) Если он видит ошибку , он будет сообщать как «Я не могу получить посылку» или «Я не могу найти

raubvogel

-1, это клиент, вызывающий эту проблему более чем вероятно, но индивидуальный просмотр 3000 клиентов для журналов, указывающих на то, что уже должно быть известно точке распространения, является безумным. Я знаю, чего ожидать, это не вопрос, требующий расплывчатого ответа, или даже вопрос, который может дать расплывчатый ответ. Это очень конкретный вопрос.

MDMoore313

Если у него есть доступ администратора SCCM, он должен иметь возможность перейти к пункту мониторинга-> развертывания, а затем найти там запись для пакета программного обеспечения. Нажав на это, вы увидите, какие клиенты установили, а какие нет. Я предположил, что изображение, которое он получил, пришло с этого экрана.

raubvogel

Я сомневаюсь, что вам удастся решить эту проблему, если это так: «У меня нет доступа внутреннего сервера к точкам управления или DP».

Можете ли вы получить доступ к distmgr.log на сервере сайта? Если нет, то вам нужно будет передать вопрос кому-то, кто может.

Эта проблема не имеет ничего общего с клиентом, поэтому я бы проигнорировал другие ответы, советующие взглянуть на клиентов. Эта проблема вызвана тем, что сервер сайта не может скопировать файлы из исходной папки в точку распространения.

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

TallPaul
источник

+1 для информации журнала, но проблема в том, что сервер не может скопировать файлы, да, но наша теория работы заключается в том, что клиент каким-то образом имеет блокировку записи для файлов DP. Структура папок не слишком длинная, потому что в этом конкретном пакете уже были заархивированы файлы, и поведение не является согласованным, но нестабильным.

MDMoore313

Как я могу определить, какие клиенты вызывают сбой при обновлении моего дистрибутива?

Ответы: