locked
Apply Windows Settings overwriting CustomSettings.ini time zone RRS feed

  • Question

  • Hi,

    Guess it's a basic question. The thing is that we are migrating our TS from a standard SCCM task sequence to an SCCM MDT task sequence and we are facing an issue. Some context below:

    We have our cs.ini file properly configured and it's working fine, everything gets configured as expected. Basically we have a userexit script that determines the site every computer belongs to reading a specific variable configured during our preprovision web front-end. Once the site has been determined, several regional settings are configured per site (keyboard layout, timezone...etc). Find below a sample of our CS.ini (just an example, not real sites):

    [Settings]
    Priority=BySite, Site, Default

    [BySite]
    UserExit=ZTIGetSite.vbs
    Site=#GetSite()#

    [Site1]
    KeyboardLocale=de-at
    UserLocale=de-at
    UILanguage=de-at
    TimeZoneName=Romance Standard Time

    [Site2]
    KeyboardLocale=en-US
    UserLocale=en-US
    UILanguage=en-US
    TimeZoneName=Tasmania Standard Time

    ...

    [Default]
    _SMSTSOrgName=Running %TaskSequenceID% on %OSDComputername%
    OSInstall=Y
    SkipAdminPassword=YES
    SkipApplications=YES
    SkipAppsOnUpgrade=YES
    SkipBDDWelcome=YES
    SkipBitLocker=YES

    ....

    The file works fine, no issue on it but, we prefer not typing the local admin password on the cs.ini file and when we enable the step "apply windows settings" to configure the local admin password, we are obligated to configure a time zone for this step -see the picture:

    Well, the problem is that when we enable this steps, all the the time zone values in our cs.ini file get overwritten by this one and all clients finish the OSD process with the Eastern Time configured instead of their regional value. Is there a way to change this behavior and keep the "apply windows settings" step enabled to configure the local admin password? We wouldn't like to move the password into the cs.ini file using clear text (or even 64base encoded).

    Thanks.

    Regards.

    Monday, May 30, 2016 9:38 AM

Answers

  • I've got some time to test and, in the end, seems the problem was in unattend.xml file. The domain join was not working either and I saw in the ZTIconfigure.log few warnings about missing entries in the unattend.xml file. I replaced the file by the one we are using in prod and everything worked as expected.

    Regards.

    • Marked as answer by David-JG Friday, June 3, 2016 12:00 PM
    Friday, June 3, 2016 12:00 PM

All replies

  • Well, the problem is that when we enable this steps, all the the time zone values in our cs.ini file get overwritten by this one and all clients finish the OSD process with the Eastern Time configured instead of their regional value.


    Values set during runtime (MDT) usually overwrite design time values (= what's configured in the TS). Have you already examined ZTIGather.log? Did you use the MDT Default TS or did you modify it?

    Torsten Meringer | http://www.mssccmfaq.de

    Monday, May 30, 2016 11:24 AM
  • Hi Torsten,

    Thanks for your reply.

    Yes, I checked the ztigather log file and it looked good to me: cs.ini was properly processed (userexit included) and the TIMEZONENAME property receives the value corresponding the local site where the computer is being deployed. Once local settings are applied, the default section runs, but we don't have site based settings there. I double check it, but i didn't see anything wrong there.

    It's a default client MDT Task Sequence with some logic added to fit our needs but nothing special, few variable checks and few custom scripts, but nothing that should interfere with our regional settings.

    If cs.ini takes precedence, then that's strange because when I disable the "apply windows settings" step everything works just fine.

    I'm going to create another TS from scratch to reduce the amount of logic that has to be processed in our current TS and I'm going to give it a try.

    Monday, May 30, 2016 1:09 PM
  • I've got some time to test and, in the end, seems the problem was in unattend.xml file. The domain join was not working either and I saw in the ZTIconfigure.log few warnings about missing entries in the unattend.xml file. I replaced the file by the one we are using in prod and everything worked as expected.

    Regards.

    • Marked as answer by David-JG Friday, June 3, 2016 12:00 PM
    Friday, June 3, 2016 12:00 PM