一般ユーザーのセルフパスワードリセット（詳細）

前回の投稿では、一般ユーザーのセルフパスワードリセットの概要を紹介させて頂きました。

追加とおさらいとして。一般ユーザーのセルフパスワードリセットを利用する場合、Azure ADの管理画面から有効化を行います。

有効化を行わないデフォルトの状態だと当然セルフパスワードリセットは利用できないのですが、何もしていないテナントでも、少し挙動が変わりました。今までは、[管理者に連絡]というボタンから管理者宛に飛んでいたパスワードのリセット要求のメールの中に

ユーザーが自分でパスワードをリセットできるようにしますか? ほんの数回のクリックで組織のユーザーのパスワードのリセットを有効にする方法をご確認ください。

という様な機能説明のページへのリンクが併記されるようになりました。このメールが来て、初めてこの機能の実装に気がつく管理者の方も多いかも知れませんね。

それでは、詳細設定の方に入っていきたいと思います。まずはセルフサービスができるユーザーの限定。通常社内にいるようなユーザーやパートナー社員に対してはこの機能を解放しないというようなケースで利用できます。

[パスワードリセットへのアクセスの制限]を[はい]に設定することにより、この機能が有効化されます。[SSPR セキュリティ グループ ユーザー]という名前の空のグループが新規で作成されますので、こちらにパスワードリセットをさせるユーザーを適宜追加して利用します。【本機能はプレビュー中の為変更になる可能性が有ります】

また、前回の投稿では、ユーザーに登録用のリンクを送って自身で登録して貰う方法を紹介しましたが、管理メニューの[○○（テナント名）のユーザーを今すぐ編集します]というリンクから辿れるユーザー管理画面の[勤務先]から、電話番号と電子メールアドレスは入力することができます。

ちなみに、ユーザーが使用できる認証方法との対応は、認証用電話が[携帯電話]、別の認証電話番号が[会社電話]、認証用メールが[連絡用電子メール アドレス]になります。

続いては、[秘密の質問]です。インターネットサイトなどでよく見かける物ですが、管理者側としては[①登録する必要がある質問の数]と[②リセットに必要な質問の数] [③秘密の質問]を設定する必要があります。【本機能はプレビュー中の為変更になる可能性が有ります】

数は、その性質上③≧①≧②にする必要があります。①②は3-5が設定できる範囲になります。ここでは試しに①=②=③=5個にしてますが、悪い見本ですね。

1. （後述しますが）回答の最低文字数は3文字なのに姓を答えさせるって1文字とか2文字の人はどうするの？
2. ペット飼ったこと無い人は回答できないし
3. 回答できない質問があるくせに、実質全部の質問に何らかの回答を設定しなくてはいけない

普通に企業IDとしてやるなら、③10個＞①5個＞②3個くらいですかね？　まあ、ここではサンプルなので仮に入力して進めてみます。

ユーザー自身で http://go.microsoft.com/fwlink/p/?LinkId=524980 にアクセスし、答えられる質問を選び、それに3文字以上で回答を設定します。（全角、半角どちらも1文字としてカウントされます。）

そうするとパスワードリセット画面の項目の中に、[セキュリティの質問に回答する]が現れます。ここに、設定した回答と同じ物を入力すると、パスワードリセットを行う事ができます。（パスワード強度を表示する部分が文字化けしているのは、まあ愛嬌って事で）
 

セキュリティを強化させるため、認証に必要とされる数を、デフォルトの1から2に変更することもできます。従来の管理者アカウントのパスワードリセットには電子メールと携帯電話の両方が必要だったので、そちらと同じレベルと考えると良いかと思います。

2に変更すると、認証画面が[確認ステップ1]と[確認ステップ2]に分かれます。ちなみに、当然と言えば当然ですが[携帯電話にSMS送信]と[携帯電話に発信]で2個とはカウントしてくれません。片方で認証が取れると選択肢から消えます。

その他の機能です。

ユーザーがAzureのアクセスパネルにアクセスした際に以下の様な表示を出して情報の入力を促すことができます。（ただ、Office 365の一般ユーザーはあまりアクセスパネルにログインする機会自体が無いかも知れませんので、その場合はリンクを各ユーザーに伝えて入力する形になります。）

また、連絡先データの再確認を行う間隔を設定できます。デフォルトは180日です。0日に設定すると、再確認は発生しません。

認証情報が分からなくなったユーザーが管理者に連絡する手段として[管理者に連絡]のリンクが設定されていますが、これをURLやメールアドレスに変更することもできます。

ディレクトリ同期環境の場合、[パスワードの書き戻し]機能を有効化するようにとの記載がありますが、残念ながらこちらについては引き続きAzure AD Premiumのサブスクリプションが必要になります。

想定していないパスワードリセットを検知するために、通知機能がデフォルトで有効化されています。複数管理者がいる場合など、対応依頼が来たメールに対して対応済みかどうかを知るために、他の管理者にパスワードリセットするオプションも設定できます。

 

うまく使いこなせば、セキュリティレベルをそれほど下げないで管理者の負荷を軽減できる物になりますので、是非、色々と使い方を研究してみてください。

一般ユーザーのセルフパスワードリセット

Office 365では、以前より管理者アカウントに対してセルフパスワードリセットの機能が提供されていました。

これは、特に中小企業などで社内に全体管理者のユーザーが1名しかいない状況でも、パスワード忘れや退職等に対応できるようにするというのが主たる目的でした。

ただ、それ以外の一般ユーザーのパスワード忘れへの対応というのは、管理者の稼働の多くを必要とする物の一つであり、機能の一般ユーザーへの提供が望まれていました。Azure AD Premiumのサブスクリプションを購入すれば従来から利用はできていたのですが、今回、Office 365のサブスクリプションを有しているユーザーは、この機能が無償で提供されるようになりました。

この機能を有効化するには、Azure ADの管理画面にログインした後、[ユーザーパスワードのリセットポリシー][パスワードのリセットが有効になっているユーザー]を[はい]に変更します。
 

これで、管理者側の設定は完了です。

次に、機能の利用対象である全ユーザーに対して以下のURLを通知し、携帯電話やメールの情報を登録して貰います。

http://go.microsoft.com/fwlink/p/?LinkId=524980

ユーザーがこの画面にアクセスすると、このような画面が表示されて情報の入力を促されます。

電話番号の登録は、国番号と電話番号を入力してショートメールもしくは電話での認証となります。[電話する]ボタンを押すと、入力した電話番号に電話が掛かってきて、[確認を完了する為に#を押して下さい]と言われるので、[#]を押すと登録が完了します。

 なお、前は+81の後に続けて入力する番号は先頭の0を除いた、例えば9012345678などの値を入力する必要がありましたが、この記事を書いている時点では09012345678と入力しても問題無く電話は掛かってきて認証できました。

続いて、メールアドレスの登録です。メールアドレスを入力した後に、[電子メールを送信する]をクリックするとメールが飛んできます。そのメールの値を入力します。

なお、勿論このメールはOffice 365のパスワードを忘れたときに送信されてくる物になりますので、Office 365のアドレスではなく、例えば携帯のアドレスやgma…、いや、Outlook.comのアドレスなどを設定する必要があります。
 

これでクライアント側の設定は完了です。

さて、実際の利用シーンです。セルフパスワードリセットを利用するには、サインイン画面の下に表示されている[アカウントにアクセスできない場合]をクリックします。

登録してある情報のどれを利用して本人確認をするかの画面がでますので、ここで利用する情報を選択します。今回は電子メールで認証をしています。

携帯電話は、登録したときと同じようにショートメールか電話を選択できます。電子メールと違うのは、登録してある電話番号を認証用に入力する必要があるということです。これは、実際に個人の携帯などに電話が掛かってくるので、間違い電話防止などの意味もあるのでしょうね。

認証が完了すると、リセットするパスワードの入力画面になりますので、新しいパスワードを入力します。上書きのリセットの扱いのようで、前回と同じパスワードを入力しても別にエラーにはなりませんでした。

今回は、まずデフォルト状態でのセルフサービスパスワードリセットを紹介させて頂きました。

Azure AD側では、もう少しこの操作の詳細を設定できるオプションが用意されていますので、そちらは次の機会に紹介させて頂きます。

Office 365 サインイン画面のカスタマイズ

Azure Active Directory Premiumで利用可能であった一部のオプションが、Office 365を利用しているユーザー向けに利用できるようになりましたので紹介します。

今回紹介するのは、サインイン画面のカスタマイズです。

設定するには、Office 365管理センターではなく、Microsoft Azureのポータルから設定をする必要があります。[サービス設定] – [パスワード]の下の方や、左のナビゲーションバーの管理者メニューの一番下の[Azure AD]にもリンクがありますが、Azure AD管理センターにアクセスします。

まだAzureにサインアップしていない場合、携帯の番号やクレジットカード番号を入力して無料評価版としてサインアップします。無料評価版のままでも試せますが、30日間の期限がありますので、期限が切れる前に従量課金制にアップグレードして利用しましょう。あくまで従量課金なので、有償のサービスを利用しないままであれば0円課金のまま継続利用できます。

ポータルのを開くと、最初は唯一利用中であるディレクトリ（Active Directory)のみ表示されます。ここの[構成]メニューを選択します。

 

[ブランドのカスタマイズ]を選択します。

 

バナー（画面右上部に表示される物）やサインインページの図（左側に表示される画像）やテキスト（画面下部に表示される）などを設定します。

下のチェックボタンを押してしばらく待つと完成です。ちなみに、サインインページの図は、最大サイズが500KBに制限されていますので、保存中にエラーが発生した場合はまずファイルサイズを確認してみて下さい。

いつものサインイン画面ですが、IDを入力すると…

先ほど指定した画面に飛ぶようになります。

コーポレートカラーや会社のロゴなどを表示したり、下の部分にカスタマイズしたテキストを表示させることができますので、未ログインの状態のユーザーに対して提示したい情報、例えばID/パスワードを忘れた場合の対応方法や利用開始の申請方法など入れておくと便利です。

ただし、こちらはIDや会社のメールドメインなどを入れただけでも他のユーザーにも表示されますので、社内向けヘルプデスクの電話番号などあまりオープンにすべきでない情報は載せない方が良いかもしれません。

無期限のパスワードポリシー

Office 365では、パスワード有効期限（14日～730日）や、その期限切れ通知を行う期間（1日～30日前）について、テナント単位で設定を行う事ができます。

この画面、最近ちょっと新しくなりました。

まず、パスワードセルフリセットに関する案内が記載されました。これは別の投稿で紹介させて頂きます。また、一番上に「パスワードの有効期限が切れることはありません」という項目が追加されました。

以前は、パスワードの無期限化を設定しようとした場合は、ユーザー単位でPowerShellを利用して設定しなければいけなかったのが、これを利用するとテナント全体でパスワードの無期限化を設定することができます。

勿論、パスワードは定期的に変えるのが運用上良いのですが、どうしても組織の運用と合わない場合などは利用すると良いと思います。

 

ちなみに、この設定は今のところGUIからしかできないようです。

PowerShellから見ると、2147483647（2^31-1）日と表示されますが、実際にPowerShellから同じ値で設定を入れてもGUIの表示でチェックは付かないので…。

 

Office 365の各種URL

遅くなってしまいまして申し訳ないですが、以前の投稿「祝！Office365日本リージョン」のフォローアップです。

あの投稿と平行しましてMicrosoft側にも調査をお願いしていたのですが、どうやら私の普段利用していたログインスクリプトの接続先URLが古く、そのURLを利用した場合に接続できないという事象だったとのこと。

• 【重要】Exchange Online PowerShell 接続時に最新の ConnectionUri を利用してください
• ConnectionUri が更新されていないと日本のデータセンタ上のサーバーに Powershell で接続できない

確かに、いつの間にかTechnetなどの接続先が https://ps.outlook.com/powershell/ から https://outlook.office365.com/powershell-liveid/ に変わっていました。（2014/2/19の英語版の改定からそうなっていたようですね）

ただ、個人的に素晴らしいなと思うのは、「古いURLを使っているとつなげない」という問題に対して、単純にそれをKBとして公開して終わりではなく、それを使い続けている人がどういうシナリオで使っていて（例：スクリプトに埋め込んでいる）、その人達に対してどう伝えれば効果的（例えばCommunityの上の方に固定表示させる）なのかを色々と考えてくれるのだな、と感じました。

ただ、この投稿を書いている現在は問題であったDNSレコード pod51075psh.outlook.com のDNSが登録されたようで、古いURLからも接続できるようになっているようです。何か有った場合のサポートコストを考えると、新しいのにばっさり切り替えるよりは今までの互換性を担保できるようにした方が良いとの判断でしょうね。

私自身、ポータルのURLが変わるという情報は blog【重要】Office 365 にサインインするためのアドレスの変更について などで見ていたので気づいていましたが、PowerShellの接続先は見落としてました。

自身のリマインダも兼ねて、接続先URLを新旧対応含めいくつか記載しますね。

• Office365 ポータル：https://portal.office.com （旧：https://portal.microsoftonline.com）
• Outlook Web App：http://mail.office365.comまたはhttps://outlook.office365.com/owa/contoso.com（旧：https://outlook.com/owa/contoso.com）
• Exchange管理Shell：https://outlook.office365.com/powershell-liveid/ （旧：https://ps.outlook.com/powershell/）

それぞれ、古いURLを使っていると一部挙動がおかしく（OWAからサインアウトできない）なったりすることもあるので、確かに全クライアントPCで変更するのは大変ですが、そろそろ新しいURLにブックマークやスクリプトなどは変えて行った方が良いかと思います。

MVP Community Camp 2015に登壇します

1/31(土)に全国8都市で実施されるMVP Communitu Camp 2015の東京会場（品川・Microsoft）で、1セッション担当させて頂くことになりました。

MVP Community Camp 2015
https://msevents.microsoft.com/cui/EventDetail.aspx?EventID=1032608669&culture=ja-JP

同一会場内だけで4セッションもあるので、1つくらいは若手/若年層向けではなくITPro向けの話でもいいかな、と思ってます。予定しているタイトルは以下の通りです。

Office 365 とオンプレミス製品の共存/使い分け

Office365が出て、最近あまり話を聞く機会が無くなったExchange/SharePoint/Lyncのオンプレミス向けのServer製品について、Office365がでてきた今だからこその観点で話をしたいといます。

そんなのOffice365で良いじゃんと思われる方もいらっしゃると思いますが、実はオンプレミス製品も需要有るんですよというのを、なるべく実例を交えて話させて貰いたいと思いますので、お時間のある方は是非参加していただければと思います。

ちなみに、来週末ですが、スライドの進捗は…非常に悪いです(w

祝！Office365日本リージョン

12/16に、いよいよ待望のOffice 365の日本リージョンが開設されました。既存のAPACテナントに配置されているユーザーも移設されるようなので、楽しみですね。

というわけで、さっそくトライアルを申し込んで利用してみました。
Pingを打ってみると、既存テナントが80-100msecなのに対して、10-25msecとかなり近いです。（日本でも値にぶれがあるのは東日本<132.245.144.66>と西日本<132.245.131.50>の差ですかね？）

ホスト名の命名規則はkaw,ty1,os1,os2のようです。前2つが東日本、後ろ2つが西日本ですかね？　ちなみに、前はsin,six,hkn,hkxのような感じ。

（注意）
この記事を書いている時点で、Exchange OnlineにPowerShellから接続しようとすると、pod51075psh.outlook.comの名前解決ができないというエラーがでます。しばらく待っても変わらないのでネガティブキャッシュでもなさそうです。

他のPODのDNSを参考にすると、pod51xxxpsh.outlook.comはpod51xxx.outlook.comのAlias（CNAME）なので、とりあえずpod51075.outlook.comを引いた物のうちの任意の1つをHostsに書いてあげれば接続できます。

Windows Server 2012 R2のADFSを使う10（+1）の理由

このblogはOffice 365 Advent Calendarに参加しています。

Windows Server 2012 R2がリリースされて1年が経ちました。Windows Server 2008 R2などでAD FS環境を作られている方も多いかと思いますが、今日は、Windows Server 2012 R2のAD FS環境に乗り換えるメリットや注意点などを簡単にまとめてみたいと思います。

1. 最新のソフトウェアバージョンであるから
   • Office 365を利用する上で、それと連携する環境はたとえServer OSであっても随時バージョンアップし、新しい物に追従していく必要があります
   • Windows Server 2008 R2のAD FSは、現在はサポート範囲には入ってますが、既に新機能は提供されておらず、次期Server OSが公開されるといずれサポート外になってしまいます
2. デバイス認証(DRS)が利用できるから
   • 利用できるクライアント環境には制限があるものの、新機能であるWorkplace Joinを利用すると、Active Directoryに所属していないデバイスを登録し、デバイス認証によるログインを実施することができるようになります
   • デバイス認証の要否もAD FSのクレームルールとして記載できますので、より柔軟なアクセス制御が実施出来るようになります
3. 多要素認証が利用できるから
   • AD FS自体がアドインの多要素認証を意識した設計になりました
   • 従来は、AD FSの処理の外（PhoneFactorであれば、AD FS ProxyのIISのフォーム認証の部分）で追加認証を実施してましたが、AD FSの処理の内部で利用することにより、ある条件下のみでの多要素認証の要求など、柔軟な処理が実施できるようになります
4. AD FSサービス用のユーザーアカウントが不要だから
   • グループの管理されたサービスアカウント（gMSA）というサービス実行専用の特殊アカウントが利用できるようになりました。これにより、AD FSサービスの実行用に特別な管理者アカウントの管理は不要です
   • 管理権限を保有し、実効上パスワードの無期限化が必要、かつAD FS Proxy経由の無差別攻撃などでロックアウトし、AD FSがサービス停止する危険性など、従来の運用上のリスクから開放されます
5. パッシブフェデレーションでも接続情報を取得できるから
   • 従来、ブラウザからのアクセス（パッシブフェデレーション）ではアクセス元のIPやクライアント種別などの情報が取得できませんでしたが、これが取得できるようになったことで、より外部アクセスに関しての細かなアクセス制御が実施できるようになりました
6. 外部アクセスへのアカウントロックアウトの対応ができるから
   • Exchange OnlineのアクセスにAD FSを利用している場合、外部から攻撃を受けたり、パスワード変更後に設定未変更のスマートフォンなどの端末からのアクセスでオンプレミスのActive Directoryアカウントがロックアウトすることがありました
   • AD FS Proxy経由でのアクセスについてAD FSの処理でロックアウトを実施することができるようになりました。これでアタックをうけてもActive Directoryアカウントには影響を与えません
7. リバースProxy機能を持つWAPが利用できるから
   • Windows Server 2008 R2のAD FS Proxyは、AD FSへの要求をフォワードすることしかできませんでした
   • Windows Server 2012 R2はWeb Application Proxy(WAP)として新たに構成され、AD FS以外にもより汎用的に各種社内Webアプリケーションをインターネットに公開（もちろん、AD FSを利用して認証させることもできます）できるようになりました
8. サインイン画面がカスタマイズできるから
   • 標準機能としてサインイン画面に会社名やロゴを入れたり、問い合わせ先などのリンクを入れたりできるようになりました
9. 内部/外部の認証方式の方式をカスタマイズできるから
   • 従来はweb.configなどをいじって対応する必要のあった認証方式の変更がGUIから簡単に実施できるようになりました
   • 例えば、イントラからの認証をWindows認証からAD FS Proxyと同じフォーム認証に変更できます。イントラ内に複数のADフォレストが存在する環境や、PCのログインユーザーとOffice365へのログインユーザーの情報が異なる場合などに活用できそうです。
10. AlternateLoginIDが利用できるから
    • 従来、認証で利用する情報はUPNに固定されていました。このため、contoso.local をActive Directoryのドメインとして利用している場合などは各ユーザーのUPNを変更する必要がありました
    • AlternateLoginIDの設定の有効化により、ログイン要求が来てそのUPNが見つからなかった場合、指定したUPN以外の一意な項目（例えばmailなど）をキーとしてユーザーを検索し、そのユーザーへの認証要求として取り扱えるようになりました
11. カリスマトレーナーによるトレーニングがあるから
    • 新しい技術分野にも関わらず、クリエイルミネートさんの Office 365 ユーザー認証ベストプラクティス で短期間で体系的かつ実践的に知識を身につけることができます。
    • 講師は勿論、あの国井傑先生です。

良い事ばかり並べましたが、勿論新しいバージョンになったことで新たに考慮しなくてはならなくなったことや運用上の注意点なども出てきてます。この辺は後日またまとめてみたいと思います。

Office 365 Soloが発売されました

遂に、日本市場向けに、Office 365の個人版であるOffice 365 Soloが発売されました。今回は、Office 365 Soloの導入にあたっていくつかポイントとなる点を紹介させて頂きます。

①個人用の「Microsoftアカウント」を利用します

Office 365 Soloを利用するには、マイクロソフトの個人用アカウントであるMicrosoftアカウント（旧Windows Live ID）が必要です。One DriveやOutlook.comなどの個人向けサービスや各種イベントサイトなど、Microsoftのサイトにサインインするために利用されてます。

既にお持ちの方が多いかとは思いますが、無い場合は無料で新規作成することができますので、利用開始前に新規でアカウントを作成しておきます。

Microsoftアカウント http://www.microsoft.com/ja-jp/msaccount 

なお、このアカウントにどのPCでOffice 365 Soloの有効期限や利用しているPC（2台まで利用可能）などの情報が紐付けられていますので、マイアカウントのページで新規セットアップの他、他のPCで利用する為に古いPCでの利用停止、期限延長の為の課金処理などを実施することができます。

ちなみに、Office 365 Business Premiumなどは、企業でドメイン単位で管理されている「組織アカウント」と呼ばれるアカウントを利用して管理されます。

②プロダクトキーの入力は、Officeのインストール時に入れるのではなく、オンラインで入力してアクティベートします

Office 365 Soloを購入すると、箱の中に「プロダクトキーカード」が入っています。その銀色の部分をコインでこすると25桁のプロダクトキーが記載されています。

今までのOfficeを利用されたことが有る方であれば、これをOfficeのDVDメディアなどからのインストールの際に入れれば良いと思われるかも知れませんが、Office 365 SoloではこれはオンラインでMicrosoftアカウントに対してアクティベートすることにより利用します。

アクティベート用のページは、Office 365 Soloの箱の中にも入っていますが、以下のサイトにログインして実施します。

プロダクトキー入力ページ　http://office.com/setup

ここでプロダクトキーを入力して「開始」をクリック。言語の設定を実施すると、Microsoftアカウントへのアクティベートが完了します。

なお、有効期限の1年間というのはアクティベートした日が開始の起算日になりますので、量販店などで購入後した場合、利用開始するPCの準備が整ってから作業は実施しましょう。また、誤って他のアカウントに付けてしまった場合、後から付け替えることはできませんので、慎重に作業しましょう。

③インストールメディアではなく、オンライン上からダウンロードしてインストールします

Office 365 Soloを購入して来ても、中に薄い説明書とプロダクトキーの書かれた紙が入っているだけです。インストールメディアは？と思われる方もいらっしゃるかと思いますが、インストールメディアはありません。オンラインで常に最新の物をダウンロードしてインストールします。

Office 365 Soloは、「1年間」「2台まで」利用できるサブスクリプションモデルのサービスとなります。その期限や誰がどのPCで利用しているのかを管理するために、インストールはマイアカウントのページから実施します。

マイアカウント http://office.com/myaccount

ページの上の方にある「インストール」を選択するとインストールが実施されます。

ここからのインストールは2台に限定されています。もし故障やPCの買い換えなどで3台目に入れようとした場合、インストール前に使わなくなったPCへの割り当てを「非アクティブ化」する必要があります。この処理により、古いPCでは作業が実施できなくなりますが、新たなPCでのインストールが可能になります。

インストールされたOffice 365のソフトウェアは常にインターネットに接続し、自分のサブスクリプションの期限が切れていないか、非アクティブ化されていないかをチェックすると共に、更新があればそれをダウンロードしてインストールします。この為、定期的にインターネットに接続させる必要があります。

Office 365 における Office クライアント単体プランの比較

SOHO・法人向けである「Office 365 Business 9600円/年（Access無し）」「Office 365 Pro Plus 13920円/年（Access含む）」も、Skype無料通話こそ含まれませんが、5台のPCまで利用できて、オンライン1TB（こちらはOneDrive for Business）にテクニカルサポート付きになり、1ユーザーから個人でも契約することができます。

サブスクリプションを管理される単位や利用されるシーン、PCの台数などに応じて適正なプランを選択して利用して頂ければと思います。

オンラインサービスの価格について

Office 365をOEM提供するシンジケーションパートナーより一部情報が出始めましたので、巷で噂されておりますOffice 365の値上げについてお話をさせて頂きます。

最大３割以上のUpもあるプラン別の値上げ！！駆け込みがお得！？

クラウドサービスは、AWSの値段に代表されるようにハードウェアの価格低減などの要因で、時間が経つに従って「値下げ」される物だという印象があります。

実際、Office 365も2011.6に発売になってから2度値下げがされております。例えば、E1、E3の価格の変化は以下の通りです。

Office 365 E1 : 1000円→800円→660円
Office 365 E3 : 2550円→2120円→1800円

ただし、アメリカでの価格の変化は以下の通りです。

Office 365 E1 : $10→$8
Office 365 E3 : $24→$20

そう、2回目の2012/12/1の価格改定は、日本ローカルでの値下げでした。

Office 365はワールドワイドで提供しているグローバルなサービスです。日米に事業所がある会社で一括してOffice 365を入れる場合、当時のドル円は約82円くらいでしたので同じ物を入れるのにアメリカの事業所で一括契約した方が2割程度安く購入できるような状態でした。

 

日本のみならず、こういった地域間での価格の格差を無くすために定期的に想定円レートの見直しが実施されていく事になります。

2012/12/1に行われた改定から約2年後、どうやら近々日本でも見直しになるようです。気になる価格ですが、プランにもよりますが、＋30%強と言われてます。

Office 365はEプランは1年契約で、前回の更新から1年間は旧価格が有効ですが、ユーザーによっては今期中に価格改定が適用されるケースも有りそうです。企業の場合など、年間の予算は大丈夫でしょうか…心配です。

こういったことに備え、可能であれば予算申請の際は少し余裕を持って積んだり、ドル円のレートも見ながら立てると良いかもしれませんね。

 

値上げも可能性が有るというのは昨年からちょこちょこ勉強会などでは話しており、先月もMVP Community Campで話したところではありましたが、実際に来るとなると結構大変ですね。