none
MDT 2013 Custom.ini no longer sets time zone on Win 8.1 computers RRS feed

  • Question

  • I volunteer at a community computer center. It has one HP server running Server 2012 R2 and 20 workstations (10 running Windows 7 and another 10 Windows 8.1). I'm using MDT 2013 for LTI deployment to the workstations

    I found online how to tweak MDT so I could differentiate task sequences in my custom.ini file. My custom.ini provides for two task sequence IDs: WIN7_INSTALL and WIN8_INSTALL. The operator is prompted for which task sequence to run. The properties below are common to both install sequences.

    Timezone worked correctly until a month or two back. Then only Win 7 installed as CST. The Win 8.1 machines now install as Pacific Standard Time. (The rest of Win 8.1 properties install correctly)

    Why does Timezone keep installing as PST, not CST, for Win 8.1? I've also tried editing the Win8_INSTALL unattend.xml file to define Timezone in every possible spot it's used to no avail.

    Any suggestions / insight appreciated.

    ; Locale and Time Page
    SkipLocaleSelection=YES
    SkipTimeZone=YES
    UILanguage=en-US
    UserLocale=en-US
    Systemlocale=en-US
    KeyboardLocale=0409:00000409
    TimeZone=020
    TimeZoneName=Central Standard Time



    Tuesday, August 25, 2015 9:30 PM

Answers

  • Did you create an OOBE file in the image you captured? Because that would explain it.

    https://technet.microsoft.com/en-us/library/cc722315(v=ws.10).aspx

    I took a look at one of my recent logs and I see

    2015-08-31 14:05:58, Info                         [msoobe.exe] Failed to load oobe.xml file at C:\windows\system32\oobe\info\oobe.xml with hr=0x80070003

    which is what I should see because I don't create an OOBE.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, September 1, 2015 1:29 PM
  • I voted the answer but thought I'd also do one final post for anyone reading in the future: The problem was in the oobe.xml files. I found two different oobe.xml files which set TimeZoneName back to Pacific. As pointed out earlier, the problem oobe.xml files were the result of starting from an OEM build

    Wednesday, September 9, 2015 9:05 PM
  • Yes! We're both headed down the same path! I was at the Center this morning to discover OOBE is quite likely the problem

    First, I'll pass along a very helpful debug trick I found online this morning. Instead of F8 to get a command prompt, you can suspend and resume a LiteTouch deployment anytime after the OS is installed by adding a step to the task sequence.

    I was able to pause deployment immediately after the machine reboots and Desktop appears the first time. This allowed me to use File Explorer to look through the disk and copy all the deployment logs before they're removed. Then I just hit a shortcut on the Desktop. The deployment script resumes.

    In my case, Panther\UnattendGC\setupact.log showed me the clues which you also pointed out above. Deployment had loaded 3 oobe.xml files. They were all generated  by HP. 2 of the 3 oobe.xml files set timezone to PST! Tomorrow, I'll try editing the files and change timezone to CST

    fyi. here's what I found in my log fille

    [msoobe.exe] Parsing oobe.xml files...
    2015-08-28 12:48:46, Info                         [msoobe.exe] Successfully loaded oobe.xml file at C:\windows\system32\oobe\info\oobe.xml
    2015-08-28 12:48:46, Info                         [msoobe.exe] Failed to load oobe.xml file at C:\windows\system32\oobe\info\default\oobe.xml with hr=0x80070002
    2015-08-28 12:48:46, Info                         [msoobe.exe] Failed to load oobe.xml file at C:\windows\system32\oobe\info\244\oobe.xml with hr=0x80070002
    2015-08-28 12:48:46, Info                         [msoobe.exe] Successfully loaded oobe.xml file at C:\windows\system32\oobe\info\default\1033\oobe.xml
    2015-08-28 12:48:46, Info                         [msoobe.exe] Successfully loaded oobe.xml file at C:\windows\system32\oobe\info\244\1033\oobe.xml









    Tuesday, September 1, 2015 8:39 PM

All replies

  • 2013 Update 1? or 2013?

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, August 25, 2015 10:03 PM
    Moderator
  • It's MDT 2013,  v 6.2.5019.0

    If you need more info, i can revert to the original unattend.xml file (before I tried mods), generate a BDD.log and provide them in a couple days.  Thanks for the reply


    Wednesday, August 26, 2015 2:39 AM
  • It is possible your unattend is missing the default values.  If so ZTIConfigure will fail to update them.  Can you post your BDD.log with your current failures (to OneDrive or something like that and provide a link here)?

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, August 26, 2015 3:55 PM
    Moderator
  • Well in my case I only have the time zones specified in custom settings and I have no time zones specified in the unattend file (I double checked). I too am in the Central time zone and it's working for me. Do you by chance have a database or anything else that might be changing the time zone? My reference image was set to central as well but that shouldn't matter.

    As Ty mentioned, a BDD log would help to find where and when the wrong time zone is being processed.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, August 27, 2015 1:51 PM
  • Updated my signature to answer the questions of how to find logs and what to do with them.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Thursday, August 27, 2015 6:14 PM
    Moderator
  • Sorry for delayed response. Had to request and wait for my acct to be verified before I could post links.

    @Dan_Vega

    I'm not using a database. I'm only using a custom.ini file. I'm running MDT 2013 (for Win 8.1 - not Update 1). I uploaded files for two test cases I tried. (Unattend.xml, BDD.log and Panther\UnattendGC\setupact.log)

    > Case 1: I restored the original unattend.xml file (before my additional mods). I see it has timezone set to CST in a couple places. But Win 8.1 is deployed to PST
    > Case 2: I edited the unattend.xml to remove the 2 CST references (since Dan_Vega said that's what he saw in his case.) Again, Win 8.1 deployed to PST

    Looking at Panther\UnattendGC\setupact.log in Case 1, I noticed [Shell unattend] set timezone to CST yet oobe.xml shows setting timezone to PST?

    Case 1 - CST in Unattend.xml (link removed by author)

    Case 2 - No CST in Unattend.xml  (link removed by author)





    Sunday, August 30, 2015 1:42 PM
  • Sorry, having trouble following what's going on in the "CST in Unattend.xml" log, as it appears that there are *two* test passes included in the log.

    Both logs show that you are setting the correct value in the Unattend.xml file.

    Updated C:\MININT\Unattend.xml with TimeZoneName=Central Standard Time (value was )

    Additionally, did you include the Unattend.xml file in the zip from the server or from c:\minint\

    IF you want to see if the system is setting the correct value, while you are in WinPE, press F8. Then at the very end, when the machine normally tries to reboot, the machine will stay at the cmd.exe window until you exit. You can use that chance to look at the c:\minint\unattend.xml file to actually see what MDT set (or didn't set) in the file. Look for <TimeZone></TimeZone>


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Monday, August 31, 2015 3:37 AM
    Moderator
  • Try what Keith suggests during WinPE.

    I'm curious if when Windows first boots up (after the image is applied) is the time correct or is it already in the wrong time zone? If it's right, then maybe something that's installed during your sequence is changing it.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Monday, August 31, 2015 6:46 PM
  • @Keith

    I believe the BDD.log you see is from a single deployment. The very last line of the BDD.log is

    Removing D:\MININT folder (final log entry)	LTICleanup

    That line only occurs once in the file, and from what I've seen, is lways the last line of BDD.log files. Perhaps its my task sequence settings that is cause it to look like (or actually does) run twice?. I will try your F8 suggestion (I'm only there 12-20 hrs/week. So will try things as I can)

    @Dan

    I think you may be on to something. As I understand things, the UnattendGC/setupact.log shows what happens during the Windows installation. (Understand, I don't speak with 100% surety. i've been learning this stuff from reading, online tutorials and the very kind help of forum members like you guys :) )   For case 1, when I search the UnattendGC log file for timezone, there are 3 occurences (i've added the line numbers)

    L248: [Shell Unattend] TimeZone: Time zone set to 'Central Standard Time'

    L428: [Shell Unattend] TimeZone: Time zone set to 'Central Standard Time'

    L509: [msoobe.exe] Successfully set timezone (Pacific Standard Time) from OOBE.xml

    So the last of the Timezone settings in the file is PST! Tomorrow, I plan to

    > Create a new Win 8.1 install Task Sequence (see if problem persists. maybe something just got corrupt?)

    > Try  F8 as well to see what's there

    Thanks again for all the help









    Monday, August 31, 2015 10:08 PM
  • Did you create an OOBE file in the image you captured? Because that would explain it.

    https://technet.microsoft.com/en-us/library/cc722315(v=ws.10).aspx

    I took a look at one of my recent logs and I see

    2015-08-31 14:05:58, Info                         [msoobe.exe] Failed to load oobe.xml file at C:\windows\system32\oobe\info\oobe.xml with hr=0x80070003

    which is what I should see because I don't create an OOBE.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, September 1, 2015 1:29 PM
  • Yes! We're both headed down the same path! I was at the Center this morning to discover OOBE is quite likely the problem

    First, I'll pass along a very helpful debug trick I found online this morning. Instead of F8 to get a command prompt, you can suspend and resume a LiteTouch deployment anytime after the OS is installed by adding a step to the task sequence.

    I was able to pause deployment immediately after the machine reboots and Desktop appears the first time. This allowed me to use File Explorer to look through the disk and copy all the deployment logs before they're removed. Then I just hit a shortcut on the Desktop. The deployment script resumes.

    In my case, Panther\UnattendGC\setupact.log showed me the clues which you also pointed out above. Deployment had loaded 3 oobe.xml files. They were all generated  by HP. 2 of the 3 oobe.xml files set timezone to PST! Tomorrow, I'll try editing the files and change timezone to CST

    fyi. here's what I found in my log fille

    [msoobe.exe] Parsing oobe.xml files...
    2015-08-28 12:48:46, Info                         [msoobe.exe] Successfully loaded oobe.xml file at C:\windows\system32\oobe\info\oobe.xml
    2015-08-28 12:48:46, Info                         [msoobe.exe] Failed to load oobe.xml file at C:\windows\system32\oobe\info\default\oobe.xml with hr=0x80070002
    2015-08-28 12:48:46, Info                         [msoobe.exe] Failed to load oobe.xml file at C:\windows\system32\oobe\info\244\oobe.xml with hr=0x80070002
    2015-08-28 12:48:46, Info                         [msoobe.exe] Successfully loaded oobe.xml file at C:\windows\system32\oobe\info\default\1033\oobe.xml
    2015-08-28 12:48:46, Info                         [msoobe.exe] Successfully loaded oobe.xml file at C:\windows\system32\oobe\info\244\1033\oobe.xml









    Tuesday, September 1, 2015 8:39 PM
  • Sounds like you're trying to deploy an image you captured from an OEM setup on a physical machine. You really should be building your reference image on a Virtual Machine so as to make it as clean as possible.

    The suspend task is something I use in my task sequence to build a reference image. It works great to pause the task sequence on a VM so you can create a snapshot that you can revert to. It also gives you the ability to make some manual changes if you need to.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, September 1, 2015 8:49 PM
  • You're correct. Started with an OEM build that I tried to strip down (remove crapware etc) as much possible.

    I only have the OEM build to start with. I didn't think a clean MS Win 8.1 image would activate with an OEM product key. I've had similar issues trying to download 8.1 from MS. MS won't download the 8.1 image if you enter an OEM key.

    What/whose image did you start with for your reference machine?



    Tuesday, September 1, 2015 9:04 PM
  • I deal with Enterprise because we are Volume License customers, but I used to ISO from Microsoft. When you create your task sequence to deploy your reference image, you can specify the product key at that point or later on add it to the unattend file. You can also create a script to update the product key with a different one.

    Here's a helpful post on building a reference image - http://deploymentresearch.com/Research/Post/357/Building-reference-images-like-a-boss


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, September 1, 2015 9:14 PM
  • Product keys are in UEFI of each workstation.

    I can create an image from a retail ISO when i have the chance.

    • Since the key is in firmware, I shouldn't need to include it in the image i think? As I understand it, Windows looks first  for a key in UEFI? So windows should self-active without a key in image or xml file, is my understanding
    • This is a small site, only 20 workstations, donated by CDW i think) Is very likely they each have their own OEM license
    • Do you know if a retail ISO will activate with an OEM license key? I think that may also be a problem




    Tuesday, September 1, 2015 9:45 PM
  • I believe the short answer is people don't have the right to reimage using OEM media. You can't use an OEM key with volume license media either and I've very sure the same applies to retail.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, September 1, 2015 9:55 PM
  • Thanks for the info.

    The lab of 20 public WS that I volunteer in, is a firewalled sub-net of a much larger network that services the rest of the Center. So I'll have to check for certain on licensing arrangements.

    Thanks to you, Ty and Keith for all the help


    • Edited by ComputerGeek of IL Tuesday, September 1, 2015 10:30 PM Forgot to thank keith too!
    Tuesday, September 1, 2015 10:24 PM
  • Officially you shouldn't be mixing and matching OEM SKU's, VL is recommended.

    That being said, I use OEM SKU's all the time. :^)

    If your hardware is all the same, and you are using an image that has been sysprep'ed (imagex /capture the machine *before* it boots into Windows OOBE Setup for the first time), yea it should work.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, September 1, 2015 10:27 PM
    Moderator
  • I voted the answer but thought I'd also do one final post for anyone reading in the future: The problem was in the oobe.xml files. I found two different oobe.xml files which set TimeZoneName back to Pacific. As pointed out earlier, the problem oobe.xml files were the result of starting from an OEM build

    Wednesday, September 9, 2015 9:05 PM