Tag Archives: SCCM 2012

Hardware Inventory not updating – SCCM 2012

I had a client where the hardware inventory had not updated in 3 months.

On the client in C:\Windows\CCM\logs\InventoryAgent.log I could see that the client sent the inventory to the management point “Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint”

I checked MP_Hinv.log on the management point (located in C:\Program Files\SMS_CCM\Logs\MP_Hinv.log) and could see that it received the file from the client
hwinv1

Then I checked dataldr.log on the site server to see if it was processed. Searching for the client name in this log, you can see at the bottom there was a Delta Mismatch.
hwinv2

Now I had to do a full hardware inventory resync on the client. I used the steps from this post to do a full hardware inventory cycle on the client https://brotechcm2012.wordpress.com/2015/11/14/forcing-client-to-do-a-full-hardware-inventory-sync-sccm-2012/

I confirmed that the client was listed in the log MP_Hinv.log but could still not see it in Dataldr.log

I then opened up the SCCM 2012 console and checked \Monitoring\Overview\System Status\Component Status\SMS_INVENTORY_DATA_LOADER
Then it pointed me in the right direction. I saw “Inventory Data Loader failed to process the file C:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\Process\HJWO0QKN.MIF because it is larger than the defined maximum allowable size of 5000000.
Solution: Increase the maximum allowable size, which is defined in the registry key HKLM\Software\Microsoft\SMS\Components\SMS_INVENTORY_DATA_LOADER\Max MIF Size (the default is 5 MB), and wait for Inventory Data Loader to retry the operation.”

I checked C:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\Process\ file size and saw it was over 5mb but under 7mb. I increased the registry to 7mb from the key above.

In about 10 minutes I tried the Hardware Inventory Cycle again and this time it was successfully processed in the dataldr.log.

The hardware inventory had successfully updated.

Forcing client to do a full hardware inventory sync – SCCM 2012

https://msdn.microsoft.com/en-us/library/cc144592.aspx

On the client run Wbemtest.exe as admin and click Connect
hwinv3

Connect to “root\ccm\invagt”
hwinv4

Click Enum Classes
hwinv6

Click Recursive then OK
hwinv7

Double click on InventoryActionStatus
hwinv8

Click on Instances
hwinv9

Delete the inventory action status instance for hardware inventory ({00000000-0000-0000-0000-000000000001}).
hwinv10

Initiate a hardware inventory cycle. This will now do a full scan.
hwinv11

Failed to run BeginSearch() on WUAgent. Error = 0x80070422

In an SCCM 2012 environment I was running through some reporting on which clients reported back scan errors so I could fully patch all servers. Upon checking the servers which failed to report software update compliance, I checked the C:\Windows\CCM\WUAHandler.log and saw the error “Failed to run BeginSearch() on WUAgent. Error = 0x80070422”

0x80070422

In my case, this was an easy fix. If you check services.msc you will see that the Windows Update service (or Automatic Updates service depending which version of Windows Server you are running) was stopped or disabled.

After starting this service and running a Software Updates Scan Cycle again, the WUAHandler.log reported that the cycle worked fine.

0x80070422_2

Maintenance Window types in ServiceWindowManager.log

Recently when troubleshooting some Maintenance Window issues for SCCM 2012 clients, I was watching the client log ServiceWindowManager.log

Each Maintenance Window has a type. For example I set a Maintenance Window for All Deployments.

mainwin1

You can see that this had Type=1.

If you are curious to see what other maintenance windows you may have set for the client, you can check out this link or look at the table below.

https://msdn.microsoft.com/en-us/library/jj155420.aspx

Value Service Window Type Description
1 ALLPROGRAM_SERVICEWINDOW All Programs Service Window
2 PROGRAM_SERVICEWINDOW Program Service Window
3 REBOOTREQUIRED_SERVICEWINDOW Reboot Required Service Window
4 SOFTWAREUPDATE_SERVICEWINDOW Software Update Service Window
5 OSD_SERVICEWINDOW OSD Service Window
6 USER_DEFINED_SERVICE_WINDOW Corresponds to non-working hours.

Part 1 – Installing Software Update Point Role – SCCM 2012

This will be a 2 part series. The first part will involve installing the Software Update Point in SCCM 2012 on Windows Server 2012 R2. The Second Part will focus creating a Windows 8.1 Software Update Group and deploying that group to a Windows 8.1 machine using a Maintenance Window.

Lets get started.

Head into Add Roles and Features wizard and select the Windows Server Update Services role and click next

sup1

Select WSUS Services, I have unticked WID Database and have chosen to use my SQL database which is hosting my SCCM 2012 Database.

sup2

Enter a path. I have created a folder on my drive called WSUS and shared it.

sup3

I have entered in the name of the SQL server in my lab (I am using default instance)

sup4

Click install.

sup5

Click Launch Post-Installation tasks

sup6

Once post installation tasks have finished, click on tools then select Windows Server Update Services

sup7

Click Cancel here

sup8

WSUS is now installed. Lets go back into the SCCM 2012 console and add the SUP role.

sup9

Select the Software Update Point

sup10

I have chosen use ports 8530 and 8531 because I am using Windows Server 2012 R2

sup11

I have skipped proxy and account settings. I am syncrhonizing from Microsoft Update.

sup12

Select the schedule you would like to synchronize WSUS.

sup13

I have left the Supercedence rules, Classifications, and Languages as default. I have also selected Windows 8.1 for the Products. You can set these later if you like in the Administration node. Here is a screenshot if you would like to configure any SUP settings later.

SUP13.1

sup14

To check if installation was successful, you can view the SUPSetup.log

You should be able to see metadata in the All Software Updates section. You can also synchronize the updates from here as well.

sup15.1

You can view the synchronizing status by looking at the wsyncmgr.log to see the progress or any errors.

sup15

PXE image failing – SCCM 2007 to 2012 migration

While in the middle of doing an SCCM 2007 to SCCM 2012 migration, my SCCM 2012 PXE Task Sequences would fail after the image had applied and the client was downloading and installing additional applications.

First thing I did before the image failed was to press F8 to load up a command prompt, then type in CMTrace so I could view the logs easily.

The log of interest was the cas.log which told me that the machine was unable to find any distribution points when locating the software. I knew the boundary was correct and that the boundary group was correct also.

The number of discovered DPs(including Branch DP and Multicast) is 0

Anyway, I double checked the boundary groups in SCCM 2012 and noticed that the SCCM 2007 running migration jobs automatically created a boundary group for the SCCM 2007 distribution point and assigned the boundaries I was using to it. This caused my clients unable to locate software to download and install additional programs.

I had migrated everything I needed from 2007 to 2012, so I simply stopped the 2007 migration job and deleted the automatically created 2007 boundary groups.

I then reimaged the machine and the cas.log looked good and could find the distribution point it needed to download the additional software for the Task Sequence.

Clients failing to download Windows updates – Group policy settings were overwritten by a higher authority

I was facing an issue where every SCCM 2012 client at a certain site would not download Windows updates from the SUP on the SCCM 2012 server.

First thing I checked was the C:\Windows\CCM\Logs\WUAHandler.log on the client.

Reading WUAHandler.log in CMTrace I saw:

Enabling WUA Managed server policy to use server: http://servername.domain.com:8530 WUAHandler 20/05/2015 12:05:39 PM 6628 (0x19E4)
Waiting for 2 mins for Group Policy to notify of WUA policy change… WUAHandler 20/05/2015 12:05:39 PM 6628 (0x19E4)
Group policy settings were overwritten by a higher authority (Domain Controller) to: Server servername.domain.com:8530 and Policy ENABLED WUAHandler 20/05/2015 12:05:41 PM 6628 (0x19E4)
Failed to Add Update Source for WUAgent of type (2) and id ({03C8F032-8F2F-4821-9359-A1732F6F7A9D}). Error = 0x87d00692. WUAHandler 20/05/2015 12:05:41 PM 6628 (0x19E4)
Its a WSUS Update Source type ({03C8F032-8F2F-4821-9359-A1732F6F7A9D}), adding it. WUAHandler 21/05/2015 1:08:23 PM 6312 (0x18A8)

What was happening was the SCCM agent was trying to set the server to get the updates from http://servername.domain.com:8530 but there was a group policy set which overrides the SCCM setting, and was changing the location to servername.domain.com:8530. Notice the difference? The group policy was set without the http://

I found the incorrect setting in group policy and added the http:// to the link, did another “Software Updates Deployment Evaluation Cycle” on the client and all the updates started flowing through for all machines.