System Center Configuration Manager и как с ним бороться

При импортировании файла лицензий для Asset Intelligence можно встретить такую ошибку:

Один из вариантов проблемы — это неправильный формат файла. Создайте в MS Excel файл, заполните его информацией по лицензиям, сохраните в .csv, откройте Блокнотом и убедитесь, что информация похожа на этот пример:

Name,Publisher,Version,Language,EffectiveQuantity,PONumber,ResellerName,DateOfPurchase,SupportPurchased,SupportExpirationDate,Comments
Microsoft Windows 7 Enterprise 6.1,Microsoft,6.1,English,5,,MegaReseller,10/10/2010,0,10/10/2012,bla-bla-bla
Microsoft Windows Server 2008 R2 Enterprise 6.1,Microsoft,6.1,English,5,,SuperReseller,10/10/2010,0,10/10/2012,tra-ta-ta

Каждый приличный администратор SCCM рано или поздно сталкивается с такой ошибкой при загрузке через PXE:

С такой ошибкой столкнулся и я, в т.ч. в процессе работы с тестовой лабой SCCM 2012. Как известно, после распространения загрузочных образов на PXE DP, папки \RemoteInstall\SMSBoot\x86 и \RemoteInstall\SMSBoot\x64 заполняются служебными файлами, которые требуются для сетевой загрузки. Частый случай — когда папки файлами не заполняются. Правильные методы решения проблемы описаны здесь: 1, 2, 3 и 4.

Я проверил работу DHCP, WDS и PXE SP: всё было в порядке. Мне было лень переустанавливать роли и я просто скопировал соответствующие файлы из \RemoteInstall\Boot в \RemoteInstall\SMSBoot. Компьютер загрузился по РХЕ.

Через неделю столкнулся с этой же ошибкой. Мне опять было лень «правильно» решать проблему переустановкой ролей и я удалил папки из \RemoteInstall\SMSBoot и скопировал туда соответствующие папки с PXE SP SCCM 2007, благо отличий в файлах никаких.

Хозяйке на заметку. 🙂

В случае автоматического неудачного восстановления файлов в процессе миграции операционной системы можно запустить loadstate.exe с нужными параметрами или, если это Windows 7, просто открыть файл двойным кликом:

Альтернативой встроенному средству является утилита MigRecover, работающая из командной строки. Достаточно просто указать путь к MIG-файлу и папку для распаковки:

Continue reading ‘извлечение файлов из USMT.MIG’ »

Загружаясь в Windows PE, компьютер на моменте запроса политик перезагружается с ошибкой 0x80004005. В smsts.log следующая ошибка:

signature varification failed
signature check failed
Failed to get client identity (80004005)
failed to request for client
Failed to read PXE settings.

На PXE Service Point в smspxe.log такая ошибка:

The system cannot find the file specified. (Error: 80070002; Source: Windows)
WARNING: _SMSTSSiteSigningCertificate Not Set. This might cause client failures in native mode.
WARNING: _SMSTSRootCACerts Not Set. This might cause client failures in native mode.
WARNING: _SMSTSCertStoreName Not Set. This might cause client failures in native mode.
WARNING: _SMSTSCertSelection Not Set. This might cause client failures in native mode.

Если сайт работает в смешанном режиме, то заблокируйте активные сертификаты и в свойствах PXE SP создайте новый самоподписанный сертификат:

После этого снова загрузите компьютер в режиме PXE.

При миграции операционной системы на этапе захвата документов и сохранении их на State Migration Point в scanstate.log можно встретить такую ошибку:

Failed to verify certificate signature for ‘SCCM.FIRMA.COM’ (0x80090006)
ClientKeyRequestToSMP failed (0x80090006).
ClientRequestToSMP::DoRequest failed. error = (0x80090006).
Request to SMP ‘SCCM.FIRMA.COM’ failed with error (Code 0x80090006). Trying next SMP.

Первый вариант решения — проверить системные логи сервера SCCM. Возможно, в логах SMP вы найдёте ошибки, связанные с попыткой сохранения документов сверх указанного лимита пользователей, соответственно, этот лимит нужно увеличить:

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

Текстовым редактором открываем на сервере <папка с установленным SCCM>\bin\<архитектура>\MobileClient.tcf. Копируем строчку, начинающуюся на SMSPublicRootKey, и вставляем её в командную строку на проблемном клиенте, как параметр при инсталляции для Client.msi. Выполняемая команда должна быть похожа на следующую:

C:\Windows\System32\CCMSetup\{4CD82FBB-0AFC-4864-A089-15364DF5F14B}\Client.msi SMSPublicRootKey=0602000000A40000525341310004000_тут_ещё_много_цифр

После этого обновляем политики и заново запускаем соответствующий набор задач.

Ежечасно компонент SMS_SRS_REPORTING_POINT сыпет ошибкой ID 7402: «SMS SRS Reporting Point failed to monitor SRS Server on «DC». При этом SQL Reporting Services работают, ссылки http://dc/Reports и http://dc/reportserver доступны, отчёты открываются.

srsrp.log:

Microsoft.ConfigurationManagement.Srs.SrsServer. error = The system cannot find the file specified. SMS_SRS_REPORTING_POINT 01.01.1601 0:00:00
STATMSG: ID=7402 SEV=E LEV=M SOURCE=»SMS Server» COMP=»SMS_SRS_REPORTING_POINT» SYS=DC SITE=000 PID=2496 TID=2548 GMTDATE=Mon Apr 04 11:59:24.936 2011 ISTR0=»DC» ISTR1=»» ISTR2=»» ISTR3=»» ISTR4=»» ISTR5=»» ISTR6=»» ISTR7=»» ISTR8=»» ISTR9=»» NUMATTRS=0 SMS_SRS_REPORTING_POINT 01.01.1601 0:00:00
Failures reported during periodic health check by the SRS Server DC. Will retry check in 57 minutes SMS_SRS_REPORTING_POINT 01.01.1601 0:00:00

С системы сайта удаляем роль ConfigMgr Reporting Services point, устанавливаем её заново с параметрами по умолчанию и через ConfigMgr Service Manager перезапускаем SMS_SRS_REPORTING_POINT:

Ошибка ID 5436 компонента SMS_MP_CONTROL_MANAGER:

MP Control Manager detected management point is not responding to HTTP requests.  The HTTP status code and text is 500, Internal Server Error.

mpcontrol.log:

Successfully performed Management Point availability check against local computer.
Call to HttpSendRequestSync failed for port 80 with status code 500, text: Internal Server Error

Перезапустите на сервере службу SMS Agent Host или просто запустите её, если она по каким-то причинам не запустилась автоматически. Успешная проверка работоспособности отображена в mpcontrol.log:

Successfully performed Management Point availability check against local computer.
Call to HttpSendRequestSync succeeded for port 80 with status code 200, text: OK
Http test request succeeded.

В InventoryAgent.log на клиенте видно, что инвентаризация собирается и успешно отправлется:

Inventory: Temp report = C:\WINDOWS\system32\CCM\Inventory\Temp\a98b401f-2983-4db4-bd8c-014b10e85e01.xml
Inventory: Starting reporting task.
Reporting: 344 report entries created.
Inventory: Reporting Task completed in 0.828 seconds
Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: {C4533A8C-6CF4-4727-BF80-A59E8F3BE6FA}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted
Inventory: Cycle completed in 44.937 seconds
Inventory: Action completed.

Точка управления в лог MP_Hinv пишет, что данные от клиента получены:

Delta report from client TEST, action description = Hardware MP_HinvEndpoint 08.03.2011 21:56:16
Hinv Task: Translate report attachment to file «D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\H0CUTSCD.MIF» returned 0 MP_HinvEndpoint 08.03.2011 21:56:16

Но поместить эти данные в базу не может, что видно из dataldr.log:

CMachineSource::InsertMachine — could not validate machine
Cannot process MIF H0CUTSCD.MIF, moving it to D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\eb4lsv1j.MIF

Инвентаризации по клиенту нет и в консоли SCCM компьютер помечен, как Client=No. Понятно, что проблема в DDR-записи компьютера, которого сервер SCCM считает устаревшим. После принудительного создания DDR и отправки инвентаризации получаем другую ошибку в dataldr.log:

ERROR — attempt to update non-existent row. Invalid command: exec pWorkstationStatus_DATA 1,66,’03/08/2011 21:41:14′,1,’3/8/2011 21:41′,’4294967297′,1049,120
Rollback transaction: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD)
Remote client hardware inventory resync generated for client GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD; update/insert result = 2
Send resync command to local site for machine GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD.
STATMSG: ID=2722 SEV=I LEV=M SOURCE=»SMS Server» COMP=»» SYS=SCCM SITE=000 PID=2596 TID=6476 GMTDATE=Tue Mar 08 19:41:17.426 2011 ISTR0=»TEST» ISTR1=»» ISTR2=»» ISTR3=»» ISTR4=»» ISTR5=»» ISTR6=»» ISTR7=»» ISTR8=»» ISTR9=»» NUMATTRS=0
Cannot process MIF XH733SUDL.MIF, moving it to D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\190i3w91.MIF
STATMSG: ID=2703 SEV=W LEV=M SOURCE=»SMS Server» COMP=»» SYS=SCCM SITE=000 PID=2596 TID=6476 GMTDATE=Tue Mar 08 19:41:17.426 2011 ISTR0=»XH733SUDL.MIF» ISTR1=»D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\190i3w91.MIF» ISTR2=»» ISTR3=»» ISTR4=»» ISTR5=»» ISTR6=»» ISTR7=»» ISTR8=»» ISTR9=»» NUMATTRS=0
Done: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD) code=2 (11 stored procs in XH733SUDL.MIF)

Удаляем все .MIF-файлы из Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS, перезапускаем службу SMS_SITE_COMPONENT_MANAGER, отправляем инвентаризацию с проблемного клиента ещё раз и видим, что процесс прошёл успешно:

Processing Inventory for Machine: TEST Version 2.1 Generated: 03/08/2011 21:56:15
Begin transaction: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD)
Commit transaction: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD)
Done: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD) code=0 (15 stored procs in XH0CUTSCD.MIF)

Что делать, если пакет не добавляется на только что созданную distribution point? Возможно, в логе вы встретите следующую запись:

Attempting to add or update a package on a distribution point. SMS_DISTRIBUTION_MANAGER 01.01.1601 0:00:00
for [«Display=\\serverDP\»]MSWNET:[«SMS_SITE=000″]\\serverDP\, machine account is to be used SMS_DISTRIBUTION_MANAGER 01.01.1601 0:00:00
STATMSG: ID=2342 SEV=I LEV=M SOURCE=»SMS Server» COMP=»SMS_DISTRIBUTION_MANAGER» SYS=SCCM SITE=000 PID=2180 TID=5576 GMTDATE=Sun Mar 06 16:33:15.008 2011 ISTR0=»ccmcertfix» ISTR1=»[«Display=\\serverDP\»]MSWNET:[«SMS_SITE=000″]\\serverDP\» ISTR2=»» ISTR3=»» ISTR4=»» ISTR5=»» ISTR6=»» ISTR7=»» ISTR8=»» ISTR9=»» NUMATTRS=2 AID0=400 AVAL0=»0000002B» AID1=404 AVAL1=»[«Display=\\serverDP\»]MSWNET:[«SMS_SITE=000″]\\serverDP\» SMS_DISTRIBUTION_MANAGER 01.01.1601 0:00:00
Cannot establish connection to [«Display=\\serverDP\»]MSWNET:[«SMS_SITE=000»]\\serverDP\ SMS_DISTRIBUTION_MANAGER 01.01.1601 0:00:00
Error occurred. SMS_DISTRIBUTION_MANAGER 01.01.1601 0:00:00

Вероятнее всего, сервер SCCM  (по умолчанию установка DP проходит с учётной записью сервера SCCM) или введённая учётная запись не имеют администраторских полномочий на сервере, куда устанавливается точка распространения. Укажите в мастере добавления роли правильную учётную запись или дайте администраторские полномочия серверу SCCM:

Во время поиска State Migration Point для сохранения захваченных настроек в логах можно встретить следующую ошибку:

Failed to find client signing certificate. Code 0x80092004
m_ClientInfo.init(), HRESULT=80092004 (e:\nts_sms_fre\sms\client\osdeployment\osdsmpclient\smpclient.cpp,1734)
ClientRequestToSMP::DoRequest failed. error = (0x80092004).
Request to SMP ‘scsm.firma.local’ failed with error (Code 0x80092004). Trying next SMP.

Ошибка свидетельствует о проблемах с самозаверяющимися сертификатами (не путать с native mode). Порядок действий:

1. Заказываем на почту исправление, которое подходит к вашей версии SCCM 2007.

2. Устанавливаем его. На сервере появляется папка Microsoft Configuration Manager\Logs\KB977203,  в которой находится ccmcertfix.exe.

3. Копируем утилиту на проблемный компьютер, открываем командную строку с правами администратора.

4. Запускаем ccmcertfix.exe. Можно запустить ccmcertfix.exe ccmcertfix.log. В логе вы можете увидеть следующие строки:

Processing certificate «SMS Signing Certificate»…Processing certificate «SMS Encryption Certificate»…
Summary: 1 out of 2 certificates fixed.

5. Заново запускаем объявление набора задач для миграции пользовательских данных.

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