Hey Guys,
Another odd issue I’ve never ran into before.
We have the profile configuration set to Central time zone… the re-image works, and boots into Windows, but is still prompting for a time zone to be selected, and not progressing further until the time zone is manually entered.
Any idea why the profile time zone configuration is being ignored??
Thanks,
Hello, we have never seen the behavior you are seeing.
For investigating It is needed to understand:
- are you doing a Bare metal deployment or a reimage?
(title is “bare metal time zone” while after you talk later about reimage)
- Which operative system are you deploying?
- In case of reimage which was the starting operative system?
(for example WindosXP reimaged to windows7)
- Is the profile a cloned profile? Or is it created from .iso?
- which version of mdt bundle are you using?
Sorry - it’s pure OSD from bare metal - no ‘reimage’.
I think i discovered the issue - the client chose “U.S. Eastern Standard Time” in the bigfix console while editing the profile config.
The time zone “U.S. Eastern Standard Time” does not exist in the Windows 7 image we are deploying, it is actually called “Indiana (East)” which does no observe DST.
I am presuming that this time zone not existing is where the issue is coming from. I have asked the client to try “Eastern Standard Time” instead of “U.S. Eastern Standard Time”.
Thanks,
Hello, if you want you can open a pmr for having the problem investigated
(why happens that the Timezone is requested and it is not set to default)
It was fixed by choosing the alternate time zone… the timezone “U.S. Eastern Standard Time” doesn’t exist in the Windows 7 image we are using - its called Indiana … not US Eastern
Hello, thanks for updating. We will change code to go to default in cases like this
You should take a look into the “U.S. Eastern Standard Time” possibly being the wrong name. This time zone does not observe DST and is called Indiana time.
We had the exact same issue. I initially chose “U.S. Eastern Standard Time” which caused the problem, just picking “Eastern Standard Time” also fixed my issue…
A fix for the time zone issue will be available in next OS Deployment release (it should be at the beginning of August). Please let us know if the problem will still occur.