新元号の発表は
2019年4月1日
もう少しとなりました。
令和おめでとうございます。
対応について、少しまとめておきたいと思います。
Microsoft製品で対応が必要な製品
Microsoftでは新元号に対する方針について下記にまとめています。
2019 年 5 月の新元号への変更に関する更新
https://support.microsoft.com/ja-jp/help/4470918/updates-for-may-2019-japan-era-change
Windows
当然ですが、基本ソフトとなるWindowsです。
対応が予定されているWindows
日本の元号の変更について – KB4469068
https://support.microsoft.com/ja-jp/help/4469068/summary-of-new-japanese-era-updates-kb4469068
サポートされるWindowsは
Windows 7 SP1以降
Windows Server 2008 SP2以降
となっており、
Windows Embedded
についても、Widnows 7ベース以降となっています。
対応方法
月例セキュリティパッチを適用することで、対応されます。
なお、実際のところは、
レジストリに新元号の記載を追加するだけです。
これを、4月に公開される月例セキュリティパッチを適用することに対応されます。
そのため、事前にテストする方法も公開されており、
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] レジストリ パスに以下のエントリを追加します。
“2019 05 01″=”新元号_新_TestEra_E”
こちらを追記し、日付の表示を変更すると対応されます。
同様のレジストリを追記できれば、パッチを適用する必要なないわけですが、
逆にパッチはみんな適用してるからこれなら大きな問題は起きないよねという考えなのでしょう。
※2019/4/2追記
新元号が発表となりましたので、変更用バッチファイルを添付しておきます。
マイクロソフトから公開がありませんが、
令和_令_Reiwa_R
となるかと。
こちらを追加するバッチファイルがこちら。
新元号
こちらを管理者で実行していただければ対象のレジストリが追記されるはずです。
上記だと、元年表記されないので、
変更するレジストリですが、
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese
文字列:InitialEraYear(REG_SZ)
値(元年表記する場合) :元年
値(元年表記しない場合):1年
でカレンダーの表記が変わります。
Excelで元年表記する場合は、セルの書式設定で変更する必要があります。
Office
Windowsの次に利用が多いであろうoffice統合製品「Microsoft Office」
こちらも、対応する必要があります。
対応が予定されているOffice
マイクロソフトから公開されている情報については、
2019 年 5 月の日本の元号変更に関する Office の更新プログラム
https://support.microsoft.com/ja-jp/help/4478844/updates-for-may-2019-japanese-era-change-for-office
現在対応が予定されているのは、
Microsoft Office 2010以降
であり、ホームページには、2019年1月にリリースされた、「Microsoft Office 2019」について記載はありません。
「Microsoft Office 2019」
については、これから記載が追加されるかと。
対応方法
対応方法は、Windows同様4月の月例のセキュリティパッチを適用することです。
なお、Officeについては、Windowsのレジストリを参照しないことから、Officeのパッチ適用が必須となります。
Officeについては、
購入方法によりことなり、
プリインストール版やDSP版、パッケージ版といったOfficeについては、インターネットから直接ダウンロード
ボリュームライセンスは、Microsoft UpdateによるインターネットかWSUSサーバからのダウンロード
となります。
企業の場合、困るのが
プリインストール版やDSP版、パッケージ版といったOffice
です。
いままで、家電量販店で買ってそのままインターネットに接続せず利用しているパソコンについては、
4月までに1度インターネットに接続し、最新の状態にしておく方が良いでしょう。
ここで、困ったことがひとつ。
Microsoft Office 2013(32Bit版)については、
まだ、Excel 2013用元号対応用パッチが出ていないことです。
※2019/4/9(日本時間:2019/4/10)に修正プログラムが公開され「Excel 2013(32Bit)」でも表示されるようになりました。
さすがに4月にでるかと思いますが、こちらで検証しているときになぜか元号が確認できなくて、悩んでいたら
Microsoftの公式サイトで追記されました。
そういったことははやめにお願いいたします。(切望)
.net Framework
プログラムの実行環境である「.net Framework」についても対応が必要となります。
色んなソフトがこの「.net Framework」の上で動いているので、知らないところで結構動いているはず。
対応が予定されている「.net Framework」
.NET Framework 用の日本の新元号対応更新プログラム
現在対応が予定されている「.net Framework」は
.net Framework 3.5以降
です。
対応方法
対応方法については、バージョンによって異なります。
また、.net frameworkの対応は大きく3つあることも注意が必要です。
.net Framework 3.5
こちらは、新元号がプログラムの中に記載されているため、
Windowsの情報を参照するように変更するセキュリティパッチを導入することで、
Windowsが対応することにより、対応されます。
また、元号の範囲と元年表記の対応のセキュリティパッチの適用が必要です。
ただし、この変更により動かないプログラムが発生する場合があるとの
情報もあり、事前にテストしておく方がよさそうです。
.net Framework 4.5.2/4.6以降
こちらについては、Windowsの情報を参照する対応がされています。
しかし、元号の範囲や、元年表記については、セキュリティパッチの適用が必要です。
対応が推奨されるテスト シナリオ
リラックス元号範囲チェック
このテスト シナリオでは、新元号への移行が将来の日付に設定されている場合に、LOB アプリケーションが機能することを確認します。ある元号の日付が次の元号に “あふれる” 可能性がありますが、既定で ArgumentOutOfRangeException または FormatException はスローされません。 Switch.System.Globalization.EnforceJapaneseEraYearRanges を true に設定すると、厳密な元号チェックを復元できます。
元年
このテスト シナリオでは、日本の新元号の 1 年目として “元年” と表記する書式設定操作を確認します。.NET の既定の書式設定操作では、”元年” の表記が採用されています。 年を表すときに “元年” ではなく常に “1” と表記する以前の動作に戻すには、Switch.System.Globalization.FormatJapaneseFirstYearAsANumber を true に設定します。
このあたりは、早めにチェックしておいた方が良いでしょう。
Oracle
Oracleについても対応が必要ですね。
Oracle Databaseの新元号への対応について | アシスト
https://www.ashisuto.co.jp/support/gengo/product/oracle-database.html
postgreSQL
対応不要だが、独自に和暦に関する関数を利用している場合は個別で対応が必要と。
PostgreSQLの新元号への対応について | アシスト
https://www.ashisuto.co.jp/support/gengo/product/postgresql.html
Microsoft SQL Server
元号/和暦 の変更に伴う影響について (SQL Server, Azure SQL Database, SQL Data Warehouse) – Microsoft SQL Server Japan Support Team Blog
https://blogs.msdn.microsoft.com/jpsql/2018/02/26/%E5%85%83%E5%8F%B7%EF%BC%8F%E5%92%8C%E6%9A%A6-%E3%81%AE%E5%A4%89%E6%9B%B4%E3%81%AB%E4%BC%B4%E3%81%86%E5%BD%B1%E9%9F%BF%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6-sql-server-azure-sql-database-sql-data-war/
トラブルシューティング
さて、元号対応といったわけではありませんが、セキュリティパッチが適用できない場合、当然トラブルシューティングが必要です。
Windowsおよび.netFramework
通常「WindowsUpdate」で提供されます。
そのため、
・インターネットに接続されていること
・パッチ配布サーバによる管理下でパッチの提供されること
が前提となります。
適用できない場合は、
WindowsUpdate.log
および
イベントログ(system、Aplication)
を確認し、原因を特定する必要があります。
多くの場合、
C:\Windows\SoftwareDistribution\DataStore
の削除が有効となるかと。
削除手順については、こちらを参考にすると良いでしょう。
また、USB接続機器が原因で適用できない場合があります。
周辺機器はできるだけ外しておくほうがトラブルが発生しません。
あと、Windows 10の場合で「高速スタートアップ」が有効となっている場合
通常のシャットダウンでは、うまく適用できない状態が継続する可能性があります。
この場合、明示的に再起動を選択する必要があります。
Windows 10については、これでほぼクリアできるかと。
Office
Officeの適用でトラブルとなることはそうありません。
Office 2013以降の問題点は、PROXY環境下だと、Winhttpの設定を確認しておくことが必要です。
こちらを参考とするのも良いですが、
コマンド設定を変更すると改善すると良いでしょう。
ただ、オフラインのOfficeについてどうするか悩みどころ。
こちらにある
にて、オフライン更新プログラムを入手し更新するとよいでしょう。
最後に
結果として、
Microsoft製品は、日頃からMicrosoft Updateの更新をきちんと実施している人には影響は少なそうですが
「.net Framework」関係で、不具合があったり正しく表示されないシステムがありそうです。
システム担当者は、
.net Framework関係について良く調査してく必要がありそうですね。
ではでは。