Разберёмся, чем заполняется дисковое пространство на сервере Configuration Manager и как его почистить.

Когда на сервере SCCM заканчивается свободное место, начинают сыпаться разного рода ошибки от Management Point, Distribution Point, SiteServer, SUP, Component Server и\или других ролей. Самым простым и быстрым решением может быть добавление дискового пространства, но оно ж не резиновое и через время проблема снова даст о себе знать. В другом случае начинается монотонная и кропотливая работа по изучению логов и поиску решений. Разберёмся, какие файлы забивают жёсткий диск, какие из них нужны, а какие уже устарели и являются мусором.

 

Анализ папок и файлов

Сначала определяем папки наибольшего размера. К ним относится FileLib, которая содержится в SCCMContentLib, папки wim и Source, которые находится в SCCM2012R2 (место установки сервера), MS SQL Server из Program Files и UpdatesForWindows. Далее смотрим, какие файлы там есть, что они содержат.

 Папка UpdatesForWindows занимает 9 Гб, создана дополнительно вручную при настройке WSUS, предназначена для хранения обновлений пользовательских ОС. Её размер вроде бы небольшой, но если ещё качать обновления для разных версий ОС и программ, то она сильно раздуется. В этом случае стоит позаботиться о выделенном сервере WSUS

Папка wim занимает 35 Гб, содержит в себе эталонные образы операционных систем. Обращение к ней происходит по сети, поэтому её можно перенести на файловый сервер.

Папка Source занимает 20 Гб. В ней лежат установочные программы со специальными настройками, то есть с командными файлами тихой установки. При добавлении этих программ на сервер SCCM используется сетевой (UNC) путь, её также можно переместить на файловый сервер. 

В директории SCCMContentLib имеются 3 папки [https://blogs.technet.microsoft.com/configmgrdogs/2012/04/26/configmgr-2012-content-library-overview/]: DataLib, FileLib, PkgLib. Папка FileLib имеет самый большой размер – 50 Гб. Эта папка служит для хранения содержимого точки распространения. По завершению процесса добавления контента в DistributionPoint будет создана папка, в имени которой - порядковый номер из 4х символов, взятых из хэша файла, и содержать она будет 3 файла (см. рис. 1), в именах которых набор символов в 16-ричном формате (значение хэша):

· .ini - содержит ссылку между файлом и пакетами, которые используют этот файл;

· .sig - содержит оригинальную подпись пакета;

· файл без расширения - является исходником.

Рисунок 1. Файлы в папке FileLib.

В папке PkgLib находятся информационные ini-файлы о распространённом пакете, а DataLib является копией структуры папок пакета, но без реальных файлов, в ней лежат ini-файлы с данными об исходнике.  

В папке MS SQL Server помимо самой базы данных, большой размер имеет лог-файл отчётов ReportServer_log.ldf –16 Гб, что прям через чур много.

 

Наводим порядок

После того, как нашли источники проблемы, начинаем клининговые мероприятия.

Сначала берёмся за лог-файл базы данных. Его интенсивный рост происходит из-за того, что у базы данных установлен режим восстановления Full (полный). Чтобы исправить ситуацию [http://liashov.com/2013/05/большой-размер-reportserver_log-ldf/], нужно в консоли SQL Server Menegement Studio в свойствах базы данных сбросить размер файла, а затем уменьшить предельно допустимое значение его размера.

Переходим к папке FileLib. При неоднократном удалении\установке DistributionPoint и добавления в неё нового контента, оказывается остаётся очень много ненужных файлов с предыдущих настроек. Из ini-файла мы увидим PackageID (номер пакета). По этому номеру можно определить и сам пакет, просмотрев в консоли SCCM подразделы из раздела Software Library. Если соответствия не было найдено, то вся папка подлежит удалению.

При наличии большого количества потерянных папок работа по выявленю соответствия быстро утомляет. Тут можно применить другой вариант, хоть и не совсем простой, но зато рабочий. В этом случае удаляется весь контент из DistributionPoint, удаляются все пакеты из раздела Software Library и все файлы из папки FileLib. В нашем случае переустановливалась и роль Distribution Point [https://www.systemcenterdudes.com/sccm-2012-distribution-point-installation/]. Затем решается, какие программы и эталонные образы уже устарели и от них можно отказаться. Когда весь хлам выкинули, можно приступать к добавлению контента обратно.

 

Окончательная проверка

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

Первым делом проверяем статусы всех пакетов в разделе Software Library, они должны иметь зелёный кружок после распространения. 

Далее открываем свойства DistributionPoint и проверяем контент. Для этого проходим путь Administration->Overview->Distribution Points->двойной щелчок левой кнопкой мыши->вкладка Content. Все добавленные пакеты должны иметь правильный размер (см. рис. 2), если размер = 0 Mb, то имеется проблема.

Рисунок 2. Контент DistributionPoint.

Затем заходим в Monitoting->Overview->System Status->Component Status, чтобы убедиться в отсутствии критических состояний каких-либо компонентов SCCM-сервера.

Следующий шаг - просмотр лог-файлов dataldr.log, distrmgr.log, mpcontrol.log, SMSPXE.log, WCM.log, которые у нас находятся в D:\SCCM2012R2\Logs.

Из утилит можно отметить DP Job Manager (отображает перечень задач из очереди точки распространения, а также разрешает их переместить, удалить, запустить вручную) и Content Library Explorer (позволяет увидеть содержимое точки распространения и решить проблемы с расположением контента).

 

Достоинства: появляется свободное место для работы SCCM-сервера.

Недостатки: тратится много время на анализ проблемы, поиски решения, исправление ошибок.

Вывод: Мы разобрались с назначением многих файлов и папок, как производить чистку ненужного контента и где смотреть ошибки. Теперь не нужно тратить время на поиск решений с нехваткой свободного места на сервере Configuration Manager