Увы, нет — всё, что делает обновление kb2998527, это прописывает именно эти и именно такие ветки реестра, как по ссылке (на Vista/2008+ ещё правит названия таймзон внутри .dll). Можете сами скачать tzedit и посмотреть, или отключить сеть и перевести часы на 23:59:50 6 января 2015 г. и посмотреть на результат. Так что или ещё раз править реестр, или снимать галку перехода на летнее время. Сам сначала думал, что всё нормально будет — но проверка показала обратное.
Вот сюда выкладывал, оно молча пропало. Но может в спешке что не так сделал. Спасибо, вот на mega.co.nz.
На самом деле поддержка Яндекса повела себя более чем достойно в этом вопросе, и всячески помогала в борьбе со злобными роботами MS, просто не хочу их больше подставлять.
Это особенность реализации предыдущего перехода, 26 октября, в Windows. Механизм DST там рассчитан на два перевода стрелок в год — на летнее время и обратно. А в 2014 году мы переходили только один раз! Для этого пришлось при создании kb2981580 пойти на некий финт ушами — в нем задним числом включили летнее время 1 января, а выключили 26 октября (из-за этого были глюки с отображением данных за 1 января в некоторых SCADA-системах). Причем механизм DST заточен не на конкретные числа, а на день и номер недели — именно поэтому переход в 2015 году на системах xp/2003 с kb2998527 произойдет в такое странное время (первая среда января 2015 это как раз 7 число). Звучит как бред, согласен, но посмотрите на скриншоты из Tzedit — возможно будет понятнее.
После kb2981580, начинаем летнее время 1 января (точнее в первую среду года), заканчиваем 26 октября (в последнее воскресенье октября).
Перевыложил, ссылку поправил, извините. Файлы другие, в этом и есть суть поста. В прошлый раз MS потребовал удаления файла самособранных руками таймзон, выложенного на Яндекс-диск, через DMCA — в этот раз хотел положить на что-то более абьюзоустойчивое, но, видимо, выбрал неправильно.
Если кому ещё актуально — вышло декабрьское обновление таймзон kb3013410. Если его (или эквивалентные изменения реестра) не установить на 2003/XP, они и дальше продолжат переводить время. Причина — неполная поддержка Dynamic DST, значения в реестре есть, но для действий по переводу времени времени они не используются. Грубо говоря, переводить стрелки в каждый год по–разному научилась только Vista и выше (ядро 6.0). Конкретно в 2015 году, если ничего не предпринимать, 2003/XP с установленным kb2998527 переведут стрелки на летнее время (+1 час) в ночь с 5 на 6 января, и на зимнее (–1 час) 25 октября.
Чтобы этого не произошло, есть простой способ — до 31 декабря с.г. снять галку перевода времени (она опять появилась после установки kb2998527), и правильный способ — установить kb3013410 (или эквивалентные ему изменения реестра). На домашнем компьютере никаких дополнительных действий не надо, сервера я бы советовал перезапустить, т.к., как выяснилось 26 октября, некоторые приложения, а так–же службы (например, IIS в Exchange) не понимают изменения таймзон до рестарта службы.
На Windows Vista/Server 2008 и выше устанавливать kb3013410 прямо сейчас или до конца года не обязательно, они и так никуда не перейдут.
Windows 2003/XP и более ранние версии операционных систем Windows не поддерживают технологию Dynamic DST для собственно процедуры смены времени, хотя соответствующие значения реестра там есть (см. msdn.microsoft.com/ru–ru/library… 85).aspx Minimum supported — Windows Vista / Windows Server 2008). Это означает, что они технически не способны переводить стрелки часов по–разному в разные года. Патчем kb2998527 для России установлены следующие времена соответственно начала и конца летнего времени:
начало — 00 часов первой среды января
конец — 02 часа последнего воскресенья октября
Именно так было сделано, поскольку имеющиеся механизмы DST не позволяют сделать однократный автоматический переход по–другому (я пробовал). Таким образом, в 2015 году и далее, если не предпринять мер, Windows 2003/XP переведет стрелки часов на час вперед в первую среду января (в 2015 это ночь с 5 на 6 января) и в последнее воскресенье октября (в 2015 это 25 октября).
Чтобы перевод стрелок в Windows 2003/XP не произошел, необходимо установить обновление kb3013410 (или эквивалентную правку реестра для XP), или, в крайнем случае, снять галку «( ) Автоматический переход на летнее время и обратно». Однако, для предотвращения проблем в случае ещё одного изменения в законодательстве, я бы не рекомендовал снимать эту галку.
Ещё раз повторюсь, ОС с ядром от 6.0, т.е. 2008/Vista, полноценно поддерживают Dynamic DST и не будут никуда переходить в 2015 и последующих годах. Однако в записи о времени перехода в старом формате, хранящиеся в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\, такие как на скриншоте ниже, будут внесены изменения. В связи с этим возможны проблемы в ПО, которое читает и использует эти значения напрямую для исчисления времени. В подразделы \Dynamic DST, определяющие перевод времени в новом формате, для России никаких изменений не вносится.
Ссылки на Майкрософт:
1) support.microsoft.com/kb/2998527/ru обновление, которое мы устанавливали в октябре 2014, секция «Список известных проблем»
(…)
Неверные параметры летнего времени для будущих лет на Windows Server 2003 и Windows XP Embedded
Если пользователи устанавливать это обновление на Windows Server 2003 или Windows XP Embedded, их системы будет продолжать использовать параметры летнего времени для 2014 даже после изменения календарного года. Это может привести к неправильному отображению времени системы.
Для решения этой проблемы пользователям следует установить накопительное Update(scheduled to be released in December, 2014) декабря до изменений календарного года. При установке обновления русский часовой пояс и декабря накопительных обновлений, их системы применить правильные параметры летнего времени и продолжает отображать правильное время в конце 2014 г.
2) support.microsoft.com/kb/3013410/ru то самое декабрьское обновление, о котором сегодня идет речь. Оно заменяет kb2981580 и все выпущенные до него, в т.ч. kb2998527. Такие обновления выходят регулярно (особенно в конце года, подготавливают систему к изменениям в законодательстве различных стран, изменяющим способ перевода стрелок в следующем году), и, как правило, являются кумулятивными, т.е. заменяют предыдущие обоновления.
Про Windows XP тут ничего не сказано, т.к. она снята с поддержки с 8 апреля 2014 года.
1) ДО 26 числа ставим патч (и перевыбираем ту-же таймзону руками для xp/2003);
2) 26 числа, а также 31 декабря и далее всё нормально, никто ничего не трогает, до следующих решений партии и правительства. Исключение — те регионы, где меняется и таймзона (+0 или -2), там по решению МС меняем её руками в ночь на 26, либо ставим сделанные вручную таймзоны, которые поменяют автоматом, а потом переходим на стандартные МС.
Не надо никакого декабрьского патча с отменой, ну посмотрите же наконец на Dynamic DST (в редакторе правой на таймзону — Dynamic DST). Оно именно для того и придумано, чтобы включать и выключать перевод стрелок в нужный год.
2014
2015
Файлик с таймзонами на Яндекс-диске засаспендили по DMCA требованию Майкрософт, сейчас переписываемся. Если вдруг кому ещё надо, гуглится по Russian_tz_2014.zip.
Так ведь эта галка как раз и исчезла при установке KB2570791. Но заморачиваться с его удалением, на мой взгляд, не стоит — просто добавьте (для московской зоны) 03-Russian Standard Time(-1).reg из архива по ссылке в посте, и всё станет как положено — 26 числа время сместится на час назад, и больше не будет никуда переходить.
Тогда, в 2011, работало %WINDIR%\$NtUninstallKB2570791$\spuninst\spuninst.exe /quiet /norestart или удаление KB2570791 стандартным способом, через панель управления. Но с тех пор выпустили ещё обновлений таймзон (kb2779562, kb2904266, kb2863058 и т.п.), вероятно придется сносить все.
>Cм. п.1.4
Пропустил из-за постоянных запарок — нет времени сделать все по-уму, зато переделывать потом время находится :( Примерно так и случаются большие и малые факапы. Это все я больше для себя написал.
>Хмм, странно, у меня она работала нормально.
На VS2005/Virtual PC? Мне для запуска на Hyper-V пришлось переустанавливать VM Additions, может в этом дело. Стабильно перезагружалась через 2 часа работы, а обновление занимало больше 2 часов, возможно, из-за того, что не указывал время установки обновления на клиентах.
>Она, в принципе, есть в п.1.2
упс, и это пропустил.
ЗЫ почему-то не отправляются комментарии через IE8 — это тут так принято, или у меня что с руками?
Спасибо за единственный в сети вменяемый мануал на тему EX и обновления календарей! Обновились сегодня ночью, что встретилось при обновлении:
1) Права проще дать руками, не через этот безумный скрипт. Включаем отображение прав в оснастке EX в реестре (kb312647) и даем полные права через стандартную вкладку Security прямо на нужную AG или сервер, или что еще нам нужно. Да, это больше, чем нужно — зато быстрее и проще. отбираем так-же точно.
При выдаче прав очень важно членство именно в Exchange View-Only Administrators, т.к. у полноценных администраторов есть явно заданный запрет на доступ к почтовым ящикам рядовых пользователей (и соответственно что-то поменять там не выйдет).
2) Выложенная в MS виртуалка давно закончила свой триальный период. Обновить ее установкой поверх у меня не получилось (возможно, виновато hyper-v — система ушла в bsod 7b). С истекшим триалом она выводит сообщение о шатдауне через ~час работы, и еще через час действительно перезапускается через специальный bsod (kernel time bomb). В принципе, обновление идет более-менее транзакционно, по мере обновления записи об обновленных почтовых ящиках из output.txt удаляются, так что внезапный рестарт не должен сломать совсем все. Но на счет обновляемого в момент рестарта пользователя у меня такой уверенности нет, поэтому накатывал несколько раз и кусками — за один раз не успело обновить все календари.
3) Нужно было сначала предупредить пользователей об обновлении, а потом уже его запускать. Проблема в том, что люди не ожидали получить отправленные системой от их имени повторные приглашения с корректным временем на все запланированные в будущем встречи, и частично их поудаляли (а я не ожидал, что оно их отправит). Реально надо было их принять, иначе вся встреча у отменившего полученное повторное приглашение пользователя удаляется. Ну либо надо было отключить автоматическую отправку уведомлений о встречах на первой страничке в расширенных настройках (это чревато граблями с разным временем одной встречи для пользователей, не попадающих на обновляемый сервер, и другими непонятными проблемами).
4) Непонятно, как все это будет синхронизироваться с мобильными календарями на разных устройствах с разными ОС. Ждем проблем на следующей неделе, в том числе с контрагентами, также пользующимися Outlook.
Я один из админов, но НЕ официальный представитель, т.е. например доверенности на покупку доменного имени у меня нет, как и официально выделенных денег на это. К сожалению, на быстрые телодвижения контора обычно неспособна. Посмотрим, чем все закончится — что еще делать?
На самом деле поддержка Яндекса повела себя более чем достойно в этом вопросе, и всячески помогала в борьбе со злобными роботами MS, просто не хочу их больше подставлять.
После kb2981580, начинаем летнее время 1 января (точнее в первую среду года), заканчиваем 26 октября (в последнее воскресенье октября).
После kb3013410, ничего не трогаем
В прошлый раз MS потребовал удаления файла самособранных руками таймзон, выложенного на Яндекс-диск, через DMCA — в этот раз хотел положить на что-то более абьюзоустойчивое, но, видимо, выбрал неправильно.
Чтобы этого не произошло, есть простой способ — до 31 декабря с.г. снять галку перевода времени (она опять появилась после установки kb2998527), и правильный способ — установить kb3013410 (или эквивалентные ему изменения реестра). На домашнем компьютере никаких дополнительных действий не надо, сервера я бы советовал перезапустить, т.к., как выяснилось 26 октября, некоторые приложения, а так–же службы (например, IIS в Exchange) не понимают изменения таймзон до рестарта службы.
На Windows Vista/Server 2008 и выше устанавливать kb3013410 прямо сейчас или до конца года не обязательно, они и так никуда не перейдут.
Файлы реестра для XP тут filetea.me/t1saFWx8b3bTr6EzxCVuJ1eWg, если кому надо.
Теоретическое обоснование:
Windows 2003/XP и более ранние версии операционных систем Windows не поддерживают технологию Dynamic DST для собственно процедуры смены времени, хотя соответствующие значения реестра там есть (см. msdn.microsoft.com/ru–ru/library… 85).aspx Minimum supported — Windows Vista / Windows Server 2008). Это означает, что они технически не способны переводить стрелки часов по–разному в разные года. Патчем kb2998527 для России установлены следующие времена соответственно начала и конца летнего времени:
начало — 00 часов первой среды января
конец — 02 часа последнего воскресенья октября
Именно так было сделано, поскольку имеющиеся механизмы DST не позволяют сделать однократный автоматический переход по–другому (я пробовал). Таким образом, в 2015 году и далее, если не предпринять мер, Windows 2003/XP переведет стрелки часов на час вперед в первую среду января (в 2015 это ночь с 5 на 6 января) и в последнее воскресенье октября (в 2015 это 25 октября).
Чтобы перевод стрелок в Windows 2003/XP не произошел, необходимо установить обновление kb3013410 (или эквивалентную правку реестра для XP), или, в крайнем случае, снять галку «( ) Автоматический переход на летнее время и обратно». Однако, для предотвращения проблем в случае ещё одного изменения в законодательстве, я бы не рекомендовал снимать эту галку.
Ещё раз повторюсь, ОС с ядром от 6.0, т.е. 2008/Vista, полноценно поддерживают Dynamic DST и не будут никуда переходить в 2015 и последующих годах. Однако в записи о времени перехода в старом формате, хранящиеся в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\, такие как на скриншоте ниже, будут внесены изменения. В связи с этим возможны проблемы в ПО, которое читает и использует эти значения напрямую для исчисления времени. В подразделы \Dynamic DST, определяющие перевод времени в новом формате, для России никаких изменений не вносится.
Ссылки на Майкрософт:
1) support.microsoft.com/kb/2998527/ru обновление, которое мы устанавливали в октябре 2014, секция «Список известных проблем»
(…)
Неверные параметры летнего времени для будущих лет на Windows Server 2003 и Windows XP Embedded
Если пользователи устанавливать это обновление на Windows Server 2003 или Windows XP Embedded, их системы будет продолжать использовать параметры летнего времени для 2014 даже после изменения календарного года. Это может привести к неправильному отображению времени системы.
Для решения этой проблемы пользователям следует установить накопительное Update(scheduled to be released in December, 2014) декабря до изменений календарного года. При установке обновления русский часовой пояс и декабря накопительных обновлений, их системы применить правильные параметры летнего времени и продолжает отображать правильное время в конце 2014 г.
2) support.microsoft.com/kb/3013410/ru то самое декабрьское обновление, о котором сегодня идет речь. Оно заменяет kb2981580 и все выпущенные до него, в т.ч. kb2998527. Такие обновления выходят регулярно (особенно в конце года, подготавливают систему к изменениям в законодательстве различных стран, изменяющим способ перевода стрелок в следующем году), и, как правило, являются кумулятивными, т.е. заменяют предыдущие обоновления.
Про Windows XP тут ничего не сказано, т.к. она снята с поддержки с 8 апреля 2014 года.
2) 26 числа, а также 31 декабря и далее всё нормально, никто ничего не трогает, до следующих решений партии и правительства. Исключение — те регионы, где меняется и таймзона (+0 или -2), там по решению МС меняем её руками в ночь на 26, либо ставим сделанные вручную таймзоны, которые поменяют автоматом, а потом переходим на стандартные МС.
2014
2015
Пропустил из-за постоянных запарок — нет времени сделать все по-уму, зато переделывать потом время находится :( Примерно так и случаются большие и малые факапы. Это все я больше для себя написал.
>Хмм, странно, у меня она работала нормально.
На VS2005/Virtual PC? Мне для запуска на Hyper-V пришлось переустанавливать VM Additions, может в этом дело. Стабильно перезагружалась через 2 часа работы, а обновление занимало больше 2 часов, возможно, из-за того, что не указывал время установки обновления на клиентах.
>Она, в принципе, есть в п.1.2
упс, и это пропустил.
ЗЫ почему-то не отправляются комментарии через IE8 — это тут так принято, или у меня что с руками?
1) Права проще дать руками, не через этот безумный скрипт. Включаем отображение прав в оснастке EX в реестре (kb312647) и даем полные права через стандартную вкладку Security прямо на нужную AG или сервер, или что еще нам нужно. Да, это больше, чем нужно — зато быстрее и проще. отбираем так-же точно.
При выдаче прав очень важно членство именно в Exchange View-Only Administrators, т.к. у полноценных администраторов есть явно заданный запрет на доступ к почтовым ящикам рядовых пользователей (и соответственно что-то поменять там не выйдет).
2) Выложенная в MS виртуалка давно закончила свой триальный период. Обновить ее установкой поверх у меня не получилось (возможно, виновато hyper-v — система ушла в bsod 7b). С истекшим триалом она выводит сообщение о шатдауне через ~час работы, и еще через час действительно перезапускается через специальный bsod (kernel time bomb). В принципе, обновление идет более-менее транзакционно, по мере обновления записи об обновленных почтовых ящиках из output.txt удаляются, так что внезапный рестарт не должен сломать совсем все. Но на счет обновляемого в момент рестарта пользователя у меня такой уверенности нет, поэтому накатывал несколько раз и кусками — за один раз не успело обновить все календари.
3) Нужно было сначала предупредить пользователей об обновлении, а потом уже его запускать. Проблема в том, что люди не ожидали получить отправленные системой от их имени повторные приглашения с корректным временем на все запланированные в будущем встречи, и частично их поудаляли (а я не ожидал, что оно их отправит). Реально надо было их принять, иначе вся встреча у отменившего полученное повторное приглашение пользователя удаляется. Ну либо надо было отключить автоматическую отправку уведомлений о встречах на первой страничке в расширенных настройках (это чревато граблями с разным временем одной встречи для пользователей, не попадающих на обновляемый сервер, и другими непонятными проблемами).
4) Непонятно, как все это будет синхронизироваться с мобильными календарями на разных устройствах с разными ОС. Ждем проблем на следующей неделе, в том числе с контрагентами, также пользующимися Outlook.
И вот еще, в догонку, ссылка с описанием причин на нормальном русском языке support.microsoft.com/kb/931667
Может оно и к лучшему в итоге — конторе наверное проще заплатить много денег, но неспеша.
e-mail: auction@nic.ru
registrar: RELCOM-REG-RF