The location of the task sequence log file smsts.log varies depending upon the phase of the task sequence:
In Windows PE BEFORE Format and Partition Disk step: X:\Windows\temp\smstslog\smsts.log (X is the Windows PE RAM drive)
In Windows PE AFTER Format and Partition Disk step: X:\smstslog\smsts.log, then copied to C:\_SMSTaskSequence\Logs\smstslog\smsts.log when drive is ready
In the new Windows OS BEFORE the client is installed: C:\_SMSTaskSequence\Logs\smstslog\smsts.log
In Windows AFTER the client is installed: C:\Windows\CCM\Logs\smstslog\smsts.log
In Windows AFTER the task sequence completes: C:\Windows\CCM\Logs\smsts.log
The task sequence OSD goes into a legacy BIOS partition and failed at the partition step.
ERRORS
smsts.log
TSManager 800 (0x320) The condition for the action (Partition Disk 0 - BIOS) is evaluated to be true
TSManager 800 (0x320) Successfully completed the action (Partition Disk 0 - Physique 80/20) with the exit win32 code 0
ApplyOperatingSystem 1552 (0x610) System root for target OS is C:\Windows, System drive is C:
ApplyOperatingSystem 1552 (0x610) OSArchitecture=X64
ApplyOperatingSystem 1552 (0x610) OS version is 10.0 ( OS system file version found to be 10.0.19041.1202 )
ApplyOperatingSystem 1552 (0x610) Successfully loaded a source BCD boot system
ApplyOperatingSystem 1552 (0x610) SetupNewOS: Loaded source boot system from target volume "C:\"
ApplyOperatingSystem 1552 (0x610) System partition not set
ApplyOperatingSystem 1552 (0x610) Unable to find the partition that contains the OS boot loaders. Please ensure the hard disks have been properly partitioned
Unspecified error (Error: 80004005; Source: Windows)
ApplyOperatingSystem 1552 (0x610) Bcdboot failed! bcdboot.exe C:\Windows /l en-US failed (15299)
Generally, after partition completes we should see a System type volume. Verify this by running the command diskpartlist volume. For example, the line in bold shows a partition of System type. It size is generally very small, eg. 500 M.
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 C : NTFS Partition 476 GB Healthy Boot
Volume 1 D Save Me NTFS Partition 475 GB Healthy
Volume 2 Windows RE NTFS Partition 499 MB Healthy Hidden
Volume 3 SYSTEM FAT32 Partition 499 MB Healthy System
Volume 4 NTFS Partition 700 MB Healthy Hidden
This is exactly what happened in this case.
Solution
Go to “Partition Disk 0 – BIOS”
Add one volume as shown in Figure 1 and Figure 2.
Disk type: Starndard(MBR)
Partition type: Primary
Tick Make this the boot partition
Tick Do not assign a drive letter to this partition
Install applications in OSD failed with 0x80072f0c
The customer used one https-enabled management point for OSD. Other management points are non https-enabled.
They created a bootable media with selecting Dynamic media, which allows a management point to redirect the media to another management point, based on the client location in the site boundaries. Refer to the document on how to create bootable media. That option brought application policy download issues afterwards as below.
CIDownloader.log:
CIDownloader 5416 (0x1528) CIDownloaderJob({43C5526D-D617-40CF-8A8C-23E9C69267B4}): CI with ModelName ScopeId_1DE19AF0-FD8E-47D4-8739-F9CDDEC66C8A/RequiredApplication_f6e3dd75-4212-4c92-8945-30ff3f1e9a9a, Version 9. Model:(null) added to job.
CIDownloader 1568 (0x620) Failed to read 'SecurityToken' from registry
CIDownloader 1732 (0x6c4) CCIDownloader::ParseDtsMessage - Dts failed with error code: 0x80072f0c. CI Downloader will retry.
CIDownloader 1732 (0x6c4) Failed to read 'SecurityToken' from registry
CIDownloader 1732 (0x6c4) In provisioing mode without authenticator.
CIDownloader 1732 (0x6c4) UpdateURLWithTransportSettings(): NEW URL - https://contosomp.lab.com:443/SMS_MP
CIDownloader 1568 (0x620) CCIDownloader::ParseDtsMessage - Package download info - Pkg loader job id: {43C5526D-D617-40CF-8A8C-23E9C69267B4}
CIDownloader 1568 (0x620) CIDownloaderJob({43C5526D-D617-40CF-8A8C-23E9C69267B4}): Received Dts failure message during CI download.
CIDownloader 1568 (0x620) CIDownloaderJob({43C5526D-D617-40CF-8A8C-23E9C69267B4}): CCIDownloaderJob::QueueRetry - Job is set to fail immediately on error - no retries.
CIDownloader 1568 (0x620) CIDownloaderJob({43C5526D-D617-40CF-8A8C-23E9C69267B4}): QueueRetry failed (0x87d00267).
CIDownloader 1568 (0x620) CIDownloaderJob({43C5526D-D617-40CF-8A8C-23E9C69267B4}): NotifyClientOfJobFailure
The CIDownloader reports 0x80072f0c, meaning a certificate is required to complete the request.
Error Code: 0x80072F0C (2147954444) Error Name: WININET_E_CLIENT_AUTH_CERT_NEEDED Error Source: Windows Error Message: A certificate is required to complete client authentication
Why is that? The reason is that the task sequence initially contacted a NON-HTTPS-Enabled management for OSD which completed OS deployment with success. When a non-https-enabled management point is used, there would be no authenticator created during the OSD process. Without authenticator, if the client tries to contact a https-enabled management point for application installation after OS is applied application installation will fail due to being unable to provide client authentication. That is the story the customer experienced. When it comes to the installing application period, the task sequence contacted the https-enabled management, which asks for a certificate for client authentication. But the client could not provide either an authenticator or a valid certificate. If the client had happened to contact the https-enabled management point it could have succeeded.
To resolve the application installation issue, there are two ways:
Provide a PKI client certificate after OS is applied which can then be used for application installation
Make the client contact https-enabled management during whole the OSD process so that an authenticator can be created during OSD phase and used later for application installation
We opted for the second option because it is difficult to add a PKI certificate to the client during OSD process. So, we created a new bootable media and selected Site-based media this time and chose the https-enabled management as the only management for this media.
The above error was gone but a new issue came up. See below.
smsts.log:
TSMBootstrap 1524 (0x5f4) Adapter {42908ABB-7573-419A-A05A-A828050DBC0E} is DHCP enabled. Checking quarantine status.
TSMBootstrap 1524 (0x5f4) Sending RequestBGRContentLocations for CAS0031D
TSMBootstrap 1524 (0x5f4) ContentLocationRequest: <ContentLocationRequest SchemaVersion="1.00" BGRVersion="1.00" ExcludeFileList=""><Package ID="CAS0031D" Version="4" DeploymentFlags="9223373136366932978"/><AssignedSite SiteCode="PRI"/><ClientLocationInfo AllowMulticast="1" AllowSuperPeer="1" DPTokenAuth="1" UseAzure="1"><ADSite Name="?"/><IPAddresses><IPAddress SubnetAddress="10.36.68.0" Address="10.36.68.175"/></IPAddresses><Adapters><Adapter Name="Ethernet" IfType="6" PhysicalAddressExists="1" DnsSuffix="my.contoso.com" Description="Lenovo USB Ethernet"/></Adapters></ClientLocationInfo></ContentLocationRequest>
TSMBootstrap 1524 (0x5f4) Setting the authenticator.
TSMBootstrap 1524 (0x5f4) CLibSMSMessageWinHttpTransport::Send: WinHttpOpenRequest - URL: CONTOSOMP.LAB.COM:443 CCM_POST /ccm_system_AltAuth/request
TSMBootstrap 1524 (0x5f4) SSL, using authenticator in request.
TSMBootstrap 1524 (0x5f4) In SSL, but with no client cert.
TSMBootstrap 1524 (0x5f4) Request was successful.
TSMBootstrap 1524 (0x5f4) reply from server is 'NoReply'
TSMBootstrap 1524 (0x5f4) content location request failed
TSMBootstrap 1524 (0x5f4) Content location request failed for CAS0031D:4. (Code 0x80004005)
smsts.log says reply from server is ‘NoReply’ from the management. It was like the client threw a stone into a black hole without getting any feedback. The root cause is that the https-enable management contosomp.lab.com was set for only internet use, that is internet-only. When it received a request from an intranet client, it just dropped that request. To solve this issue, the solution is set the https-enabled management point to: Allow intranet and internet connections.
Client computer started with Bootable media does not show task sequence deployed to Unknown computers collection
Issue description
Client computer boot with bootable media but does not show the task sequence deployed to Unknown computers collection.
smsts.log
The following messages come from the smsts.log. To find smsts.log location, refer to this guide.
08-11-2021 00:09:57.807 TSMBootstrap 1396 (0x574) Unknown machine GUIDs: 2d1d6e4c-77fe-4904-aed2-ed62c2727373 7d3568e0-7e41-4a62-96ea-dae7f9782877
08-11-2021 00:09:57.807 TSMBootstrap 1396 (0x574) Management Point specific X86 unknown machine GUID is received at run time
08-11-2021 00:09:57.807 TSMBootstrap 1396 (0x574) Management Point specific X64 unknown machine GUID is received at run time
08-11-2021 00:09:57.807 TSMBootstrap 1396 (0x574) Downloading policy from https://contoso.test.lab.
...
08-11-2021 00:09:57.854 TSMBootstrap 1396 (0x574) Client Identity: GUID:86C1936D-883C-450F-AC6B-43108FB09C43
08-11-2021 00:09:57.854 TSMBootstrap 1396 (0x574) Netbios name: TESTCLIENT-M123456L
08-11-2021 00:09:57.854 TSMBootstrap 1396 (0x574) Client GUID = GUID:86C1936D-883C-450F-AC6B-43108FB09C43, Netbios name = TESTCLIENT-M123456L, State = Known
While “Client GUID = GUID:86C1936D-883C-450F-AC6B-43108FB09C43, Netbios name = TESTCLIENT-M123456L, State = Known” suggests the target client is a known computer. The customer also confirmed that this computer was used by a user and managed by SCCM.
SOLUTION
Delete the client TESTCLIENT-M123456L from SCCM console and the policy should appear.
When it comes to PXE boot, various problems can occur. Recently a customer turned to me reporting that their testing physical machine failed to PXE boot. One of the key information was that the testing machine was in a different subnet than the pxe-enabled distribution point. So, I asked them to do a test in the same subnet of the distribution point. They did and told me that there was no problem in that case. It is obvious that there is a problem with the network between the two subnets, that is the subnet where the testing client was and the one which the distribution point belonged to.
I asked them to capture a network packet file from both the distribution point and the testing client. The network trace file capture on the distribution point showed that no DHCP request ever received from the testing client, though the testing client could send DHCP request to the DHCP server and could get a valid IP address. Coupled with the fact that their distribution point and the testing client computer were not on the same subnet, I asked them to verify if IP Helper was properly configured (refer here and here). It took days before they came back to me again telling me that IP Helper has been configured.
However, a new issue arose. The testing client shows the following page.
smspxe.log from the distribution point shows the following messages –
12-15-2020 15:57:39.943 SMSPXE 2744 (0xab8) 00:D8:61:AE:24:3D, 40364D80-1925-11EA-BB2A-98251BAD1100: Device is in the database.
12-15-2020 15:57:39.943 SMSPXE 2744 (0xab8)
Operation: BootReply (2) Addr type: 1 Addr Len: 6 Hop Count: 0 ID: 3D24AE64
Sec Since Boot: 16 Client IP: 010.138.001.168 Your IP: 000.000.000.000 Server IP: 192.168.210.121 Relay Agent IP: 000.000.000.000
Addr: 00:d8:61:ae:24:3d:
BootFile: smsboot\x86\wdsnbp.com
Magic Cookie: 63538263
Options:
Type=53 Msg Type: 5=Ask
Type=54 Svr id: 192.168.210.121
Type=97 UUID: 00804d36402519ea11bb2a98251bad1100
Type=60 ClassId: PXEClient
Type=250 02010105040000002903020014040200ba062c436f6e66696775726174696f6e204d616e61676572206973206c6f6f6b696e6720666f7220706f6c6963792e0b0101
12-15-2020 15:57:56.509 SMSPXE 2744 (0xab8) 00:D8:61:AE:24:3D, 40364D80-1925-11EA-BB2A-98251BAD1100: no advertisements found
12-15-2020 15:57:56.556 SMSPXE 2744 (0xab8) 00:D8:61:AE:24:3D, 40364D80-1925-11EA-BB2A-98251BAD1100: No boot action. Aborted.
Note that the log says the device is in the database but no advertisements found and thus boot action was aborted. This is an important hint indicating that the device was not in a proper collection to which the task sequence was deployed. After they put the testing client into a collection and initiated a reboot as I had suggested, the previous issue disappeared, but the testing client computer stopped at the screen below.
Spotting the message “Press F12 for network service boot“, I asked the customer if he did press on F12 and he replied with a firm “Yes”. Okay. Investigation had to continue. Turning to smspxe.log, which, however, showed no errors at all –
12-16-2020 15:05:01.019 SMSPXE 2744 (0xab8) 04:0E:3C:30:C3:B3, 9655701B-A6F4-11EA-B39E-040E3C30C3B3: found optional advertisement S012000B
12-16-2020 15:05:01.019 SMSPXE 2744 (0xab8) Looking for bootImage S0100002
12-16-2020 15:05:01.035 SMSPXE 2744 (0xab8) Not in SSL.
12-16-2020 15:05:01.050 SMSPXE 2744 (0xab8) Not in SSL.
But “found optional advertisement” caught my eye. This message told us that the task sequence was deployed as Available and so it will prompt a message asking you to press F12 (refer here).
Looking at the network trace file captured on the testing client end, we could see DHCP requests were sent to the distribution point for wdsnbp.com and pxeboot.com files. All looked quite good. However, no more DHCP requests! Noting seemed wrong here. I scratched my head, not knowing what actually happened.
Then, I called the customer again asking him how he pressed F12 and he told me that he pressed F12 only once at the sight of the “Press F12 for network service boot” message on the screen. Only once! That was not enough… That only-once press on F12 would only bring the client into pxe boot but would not kick off the optional advertisement. With that thought, I asked him to keep on pressing down and up on F12. As I had expected, the issue was gone and pxe boot succeeded in the end.
SCCM Monde 