Monthly Archives: June 2015

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.

Advertisements

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.

WDS service unable to start

I have had a few issues with the WDS service not starting on some of my distribution points.

One server was easily fixed by checking and fixing the permissions for the SYSTEM account for the C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18 folder.

It needed to have Full Permissions to start. For some reason the permission was removed which caused the service to fail each time I started to fix it.

WDS

Another time I had this issue, it turned out to be a corrupt SQL computer account in the SCCM SQL database.

Each time I tried to start the WDS service under the System Account it would generate Failure Audit alerts in the Application Log:

Event Type:    Failure Audit
Event Source: MSSQLSERVER
Event Category:          (4)
Event ID:         18456
Date:               3/12/2015
Time:               1:00:00 PM
User:               Domain\ComputerAccount$
Computer:       SCCMDB
Description:
Login failed for user ‘Domain\ComputerAccount$’. [CLIENT: x.x.x.x]

I removed the login for ComputerAccount$ from the SQL Management Studio and re-created it with the same permissions and the WDS service can now start.

PXE issue – There are no task sequences available to this computer.. Please ensure you have at least one task sequence advertised to this computer.

Disclaimer: This is what worked in my environment. It may not work in yours. Run at your own risk. I am not responsible for any issues it may cause. Modifying the database is not supported by Microsoft.

This was a strange issue which caused me a massive headache. I was unable to successfully PXE image any machine at my site. When trying to image, it would get the abortpxe message and not pick up the advertised Task Sequence.

In my environment, I do not have Unknown Computer support enabled. I have a collection and task sequences deployed to the collection as Required.

I could not clear the PXE flag on the machine in SCCM 2012 because the machine had not run the advertisement.

I confirmed the machines had a task sequence deployed to it. I tried different computers with different MAC addresses but it was the same issue.

I checked out smspxe.log on the site server and it said:

There are no task sequences available to this computer.. Please ensure you have at least one task sequence advertised to this computer.

Unspecified error (Error: 80004005; Source: Windows) TSPxe 7/04/2015 2:14:26 PM 872 (0x0368)

Again, I confirmed that the machines did in fact have a task sequence deployed to it as required. The machine was not picking up the policy from the management server. After a lot of research, I found there was a SQL query I could run on the site database which could find a Null entry (if it exists), which was blocking the machines from getting the policy. The query to run was:

SELECT * FROM ResPolicyMap WHERE machineid = 0 and PADBID IN (SELECT PADBID FROM PolicyAssignment WHERE BodyHash IS NULL)

This returned a null entry. To remove it:

Delete FROM ResPolicyMap WHERE machineid = 0 and PADBID IN (SELECT PADBID FROM PolicyAssignment WHERE BodyHash IS NULL)

After this was removed, I restarted my Management Point I could now image again. What a lifesaver this script was!