How can I sync the BIOS date in WinPE to avoid PXE boot failure with System Center 2012 R2 Configuration Manager ?

Introduction

I’ve seen this quite a bit so I thought I might as well post it in case others see the same problem, what happens is that computers (virtual or real) that have an incorrect date in the BIOS will cause Policy retrieval problems during PXE boot.

 

Problem

Failure to retrieve policy means you cannot run any task sequence and the failure will in turn produce an error just before running any Required (Mandatory) task sequence or before displaying a list of one or more Available (optional) task sequences.

 

Note: The error produced occurs immediately after entering the PXE password if one is set. The error message displayed to the end user is shown below, in the example below the DATE was set to one year earlier than the current date:

 

Quote

Failed to Run Task Sequence An error occurred while retrieving policy for this computer (0x80004005). For more information, please contact your system administrator or helpdesk operator.

 

Failed to Run Task Sequence.png

 

and the actual error message shown using CMTrace in red text in the SMSTS.LOG file found in x:\windows\temp\smstslog is shown below

 

reply has no message header marker.png

 

and the text of the error message contained in SMSTS.LOG will appear something like the below

 

Quote

<![LOG[reply has no message header marker]LOG]!><time=”17:18:38.515+480″ date=”07-22-2013″ component=”TSPxe” context=”” type=”3″ thread=”1260″ file=”libsmsmessaging.cpp:1970″>
<![LOG[DoRequest (sReply, true), HRESULT=80004005 (e:\qfe\nts\sms\framework\osdmessaging\libsmsmessaging.cpp,5868)]LOG]!><time=”17:18:38.515+480″ date=”07-22-2013″ component=”TSPxe” context=”” type=”0″ thread=”1260″ file=”libsmsmessaging.cpp:5868″>
<![LOG[Failed to get client identity (80004005)]LOG]!><time=”17:18:38.530+480″ date=”07-22-2013″ component=”TSPxe” context=”” type=”3″ thread=”1260″ file=”libsmsmessaging.cpp:6148″>
<![LOG[ClientIdentity.RequestClientIdentity (), HRESULT=80004005 (e:\qfe\nts\sms\client\tasksequence\tsmbootstrap\tsmediawizardcontrol.cpp,1114)]LOG]!><time=”17:18:38.530+480″ date=”07-22-2013″ component=”TSPxe” context=”” type=”0″ thread=”1260″ file=”tsmediawizardcontrol.cpp:1114″>
<![LOG[failed to request for client]LOG]!><time=”17:18:38.530+480″ date=”07-22-2013″ component=”TSPxe” context=”” type=”3″ thread=”1260″ file=”tsmediawizardcontrol.cpp:1114″>
<![LOG[Exiting TSMediaWizardControl::GetPolicy.]LOG]!><time=”17:18:38.530+480″ date=”07-22-2013″ component=”TSPxe” context=”” type=”0″ thread=”1260″ file=”tsmediawizardcontrol.cpp:1420″>

 

Solution

 

Well the fix is easy enough, simply set the correct date in the bios and then reboot the client computer and PXE boot again, this time it should not get the error noted above and it should receive policy correctly.

 

While the above is an easy fix if it’s a rare event you might want to automate a solution if you deal with imaging a lot of computers. So here’s a method I’ve created to do just that, it uses the prestart ability to run a script in WinPE to sync time using NET TIME with a server you specify in your domain, it does require domain user credentials but you can decide how to deal with that.

 

So Let’s get started…

 

Step 1. Download the following script

 

Attached File  WinPE_timesync.zip   1.49KB   1442 downloads

 

Copy this script somewhere useful on your ConfigMgr server, once done open it in notepad and configure the following section before continuing,

 

configure this section.png

 

save your changes

 

Step 2. Add a prestart command to your boot wim

 

Locate a boot image that you are using in your Task Sequences, and right click it, choose properties.

 

properties.png

 

click on the Customization tab and place a checkmark in Enable Prestart Command as in the screenshot below, enter the following in the box provided

cscript.exe WinPE_TimeSync.vbs

cscript WinPE_TimeSync.png

 

Next, place a checkmark in the Include files for the prestart command and click on browse, then browse to the network share where the script downloaded above is stored as shown in the screenshot below

 

Include files for the prestart command.png

 

Apply the changes above, and answer yes when prompted as shown below

 

update dps now.png

 

Click next when prompted and continue through that wizard to completion.

 

close.png

 

Step 3. Test PXE boot

 

Using a computer that has the bios DATE deliberately set incorrectly (like 05-05-05) PXE boot the computer. If you only have access to a virtual machine such as hyperV then PXE boot and before entering the PXE password press F8, then type Date and enter the date 05-05-05.

 

Note: Please make sure that the last deployed task sequence contain the boot image used above otherwise this prestart won’t be used. You can do this by right clicking on the last deployed task sequence and verify what boot image is listed in the Advanced tab like below.

 

boot image clean.png

 

Once done, PXE boot the computer with that you plan on testing with.

 

pxeboot.png

 

If it’s a virtual machine like mine, press F8 and type date to set the date to something incorrect like 05-05-05 as shown below

 

current date is 05 05 05.png

 

Note: Without the prestart command and script provided here, the above date would be enough to produce the problem mentioned at the start of this guide !

 

Now you are ready to enter the PXE password, so go ahead and enter it, then press next, if you did the above correctly the prestart will pop up a command prompt window before running the script

 

prestart popping up.png

 

After a while, you’ll see the list of task sequences displayed even though the computer had an incorrect BIOS date, now that is a result, no reboot needed !

 

list of task sequence.png

So how does it all work ? well the script makes a connection to the specified server using a domain user, once this completes successfully (and it’s required), we use a NET TIME command to sync the bios DATE/TIME with that on the server specified.  You can see this in action by reviewing the SMSTS.log in CMTRACE

 

In the screenshot below we see the first command prompt we opened to forcefully change the date manually.

 

Notice how the logging jumps from the real date/time to 2005, that’s the incorrect date now in ‘action’.

 

2005.png

 

scroll down a bit until you see it executing the prestart command as shown in the screenshot below, notice how before the prestart the date is 05-05-2005 but after it’s changed to the correct date  and that the date change correction occurs before the Management point is contacted

 

correct date set before get command.png

 

the rest of the smsts.log file will look like any normal one processing and downloading policy before displaying the list of task sequences, this would not be possible without the fix above.

 

download policy.png

 

job done !

 

Troubleshooting

 

The script generates three log files listed below

 

  • WinPE_TimeSync.log
  • WinPE_Net_Use.log
  • WinPE_Net_Time.log

 

please refer to these logs when troubleshooting non-working scenarios, for comparison purposes you can see what my successful log files look like below:

 

WinPE_TimeSync.log

 

WinPE_TimeSync log.png

 

WinPE_Net_Use.log

 

WinPE_Net_Use log.png

 

WinPE_Net_Time.log

 

WinPE_Net_Time log.png

 

Also to note, the script outputs the net use and net time commands to the CMD prompt window (for troubleshooting), but you can REM those lines out by changing any line that begins with:

wscript.echo strCommand

to

'wscript.echo strCommand

cheers

niall

 

Related Reading

 

You can download a Microsoft Word copy of this guide here.

 

Attached File  How can I sync the BIOS date in WinPE to avoid PXE boot failure with System Center 2012 R2 Configuration Manager .zip   1.38MB   520 downloads

This entry was posted in ConfigMgr 2012. Bookmark the permalink.

11 Responses to How can I sync the BIOS date in WinPE to avoid PXE boot failure with System Center 2012 R2 Configuration Manager ?

  1. bamesbeard says:

    Hi Niall, great post. I am having a date issue myself, but the interesting part is that the smsts.log file is dated a day in advance. I’ve checked the Management Point and the date/time is correct and confirmed the same on all other DP. The laptop is also correctly set to the correct date/time.

    We did solve this on one occasion by amending the date in the bios to match, but obviously this isn’t a perfect fix! Any ideas on this? I can supply the smsts.log file if it helps…

  2. MikeJ says:

    Hi Niall –
    Thanks for posting this and saving me the trouble of writing this myself. I’m receiving Access Denied (System Error 5) . This occurs on the net time step. The net use command executes properly. Also, I am able to execute both commands from an elevated cmd prompt on a Windows 7 device that is domain member without issue. I believe the issue is due to the WinPE environment not being a domain member. Are you aware of any issues that would cause a non-domain member to be denied on a Net Time command?
    Thanks.

    • ncbrady says:

      hi Mike
      the script provides a method for you to enter domain credentials required, did you not do so ?

      • MikeJ says:

        Indeed I used the credentials as you specified in your guide. The log showed that the ‘net time’ cmd was failing so I decided to run the cmds directly from the cmd line in WinPE.
        ‘net use \\server.domain.local Password1 /user:domain.local\user’
        executes successfully
        ‘net time /domain:domain.local /set /y’
        fails with access denied
        They both execute properly from a domain joined Win7 box. Do you think this could be related to permissions of a non-member?
        On a side note, this works if I do ‘net time \\server.domain.local /set /y’.
        That does not work since we are distributed across different time zones. Surely I could use subnet detection and reach out to the related server, but I want to keep this fairly simple. Thanks.

        • BarnabyA says:

          Great solution Niall!
          For MikeJ and others, I had this issue and found I had to use the net time \\servername instead /domain: option.
          This means changing the line
          strCommand = (“cmd /c net time /DOMAIN:”) & strDomain & (” /SET /Y”) & (“>”) & (” “) & (“x:\WinPE_net_time.log”)
          to
          strCommand = (“cmd /c net time \\”) & strServer & (” /SET /Y”) & (“>”) & (” “) & (“x:\WinPE_net_time.log”)
          Cheers, Barnaby

  3. james7mc says:

    Hi – when I try to download the script it tells me the content can no longer be found.

    Can it please be restored?

    Thanks for the information.

  4. relapse808 says:

    I had this working at one point and now its failing. This is important because I am using it for Surface Pro 3 and it doesnt allow to set the date and time in bios withing the UEFI firmware itself. I am not sure what changed but net time log is completely empty unlike your screenshot. Do you have any suggestions?

    • ncbrady says:

      i’ve seen that happen when it’s failing to connect to the server/share specified, have you verified (manually) that it works ?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.