新しいOfficeでポータルに常時接続するには

新しいOffice365では、管理権限を持っていない一般ユーザーは、初回アクセスから一定期間(2週間くらい?)経過すると、ログオン時に以下の様な画面が表示されます。
20130524_01

ようこそ画面ではなくOutlookが初期表示として表示されるようになるとのメッセージです。確かに、再ログインするとOutlookが表示されます。[了解しました]しか押せませんし、設定を戻すこともできません。
20130524_02

Fiddlerで動きを追ってみると、https://portal.microsoftonline.com/default.aspx に接続しに行くと、https://www.outlook.com/owa/xxxxx.onmicrosoft.com/?exsvurl=1&ll-cc=1041&modurl=0 にリダイレクトされるようです。

上にも書きましたが、現在これを止めたり元の様な設定に戻す方法はありません。

ただし、?DisableIWLanding=true というオプションを付けると上記の処理をスキップしてくれるようです。

https://portal.microsoftonline.com/ などにブックマークしている場合は、ブックマークを

などに変更すると、元の様に常に「Office365にようこそ」の画面に常時接続できるようになります。
20130524_03

エンドユーザーへの影響を少しでも減らしたい方はブックマーク先を変更した方が良いかもしれませんね。

確かに、利便性を考えると…というので気を利かせているのだろうとは思いますが、そういう人は最初からOWAに直に入るURLをユーザーにブックマークさせていると思うのです…

Office365アップデート通知

ついに私のP1テナントにもアップグレード通知が来ました。
20130402_02

予想と違ったのは、以下くらいですかね?

  • 1ヶ月前予告が無かった(P1だから?)
  • アップグレードの延期オプションがP1でも有った

ポータルにログインすると、しっかり通知文が出るようになりました。
20130402_01

ちなみに、通知メールのfromは Microsoft Office 365 Team <Office365@microsoftonline.com> タイトルはサービスに関する通知:  Office 365 サービスのアップグレードが 2013年 ・・・・・日 に予定されています です。

管理者の権限を持っているユーザー全員+パートナー(登録している場合)に対して送信されますので、spamだと思って捨てないようにお気を付け下さい。

SRVレコード対応のドメインレジストラ

Office365での独自ドメインの利用(RocketNet)でも書いたとおり、Office365のLyncでフェデレーションを利用する為にはSRVレコードが必要です。

残念ながら、日本のドメインレジストラに付帯してくるDNSホスティングサービスではOffice365の技術blog Office 365 で利用するための日本の主要なレジストラーにおける DNS の設定方法にも記載が有るとおり、ほとんど対応していない状況です。

Office365が発売されて時間も経ちましたので、折角なのでSRVレコードの対応状況を調べてみました。

まず、上記サイトでも紹介されていた5つのレジストラ

ですが、残念ながら現時点でもSRVレコードには対応していませんでした。折角なので、今後の対応予定が無いか尋ねてみます。Yahooのみメールでの問い合わせ窓口が分からなかったので送れませんでしたが

件名:DNSサービスの機能に関する問い合わせ

突然の問い合わせ失礼いたします、○○と申します。

マイクロソフトにて公開されております情報を読み、連絡をさせて頂いております。
 http://community.office365.com/ja-jp/blogs/office_365_technical_blog/archive/2012/05/14/office-365-dns-setting-for-major-japanese-registrar.aspx

マイクロソフトで拡販に力を入れているOffice365というサービスが有り、 中小企業を中心に
導入が進んでおります。この中で、LyncというIM/プレゼンス/テレビ会議などを実施することが
できるサービスが、他ユーザーやSkypeなど他サービスとの連携を行う際に SRVレコードの実装が
必須となっております。

ニーズとしては非常に大きいかと思うのですが、御社DNSサービスにおいて 今後SRVレコードに
対応される予定はございませんでしょうか?

よろしくお願い致します。

さすがにこの辺は回答早いですね。4サービスとも翌日には「対応予定無し」「貴重なご意見ありがとうございます」という感じの返答を頂きました。

という訳で、見つけられているレジストラは以下しか今のところは紹介できません。

ドメインレジストラのやっている無償のDNSホスティングはサービスでやっているような物ですから、新たなコンパネの機能開発投資は難しいというのは分かるんですけどね…。

SRVレコードを直接サポートというわけでは無いのですが、直接ゾーンファイルの内容をいじれるなど、間接的には以下でも実装可能ですね。

しっかり使うのであればVPSのLinux OSホスティングを月1000円くらいで借りてきて、そこでbindを運用。セカンダリ側だけレジストラに依頼するのが楽かもしれませんね。

特定条件下でConnect-MsolServiceが失敗する

久しぶりにADFSの環境を構築しようとして、検証環境でConnect-MsolServiceコマンドレットでWindows Azure Active Directoryに接続しようとしたところ、なぜか以下のエラーが出て接続できない事象が発生するようになりました。

PS C:> Connect-MsolService -Credential $LiveCred 
Connect-MsolService : 要求チャネルは、応答を待機してから 00:00:59.8905882 後に
タイムアウトしました。Request の呼び出しに渡すタイムアウト値を増やすか、Binding
 の SendTimeout 値を増やしてください。この操作に割り当てられた時間は、より長い
タイムアウト時間の一部であった可能性があります。
発生場所 行:1 文字:1
+ Connect-MsolService -Credential $LiveCred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Tim
   eoutException
    + FullyQualifiedErrorId : System.TimeoutException,Microsoft.Online.Adminis
   tration.Automation.ConnectMsolService
Connect-MsolService : 種類 'Microsoft.Online.Administration.Automation.Microsof
tOnlineException' の例外がスローされました。
発生場所 行:1 文字:1
+ Connect-MsolService -Credential $LiveCred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Mic
   rosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Micro
   softOnlineException,Microsoft.Online.Administration.Automation.ConnectMsol
  Service

エラーの内容からすると、単なるタイムアウトっぽいです。
20130318_01

他の環境から実行したところ特に問題く接続できるので、クラウド側の障害とかでは無さそうに思えます。下の方のレイヤでの障害が疑われるので、とりあえずWireSharkでパケットを追ってみると、何となくそれらしい所が見つかりました。
20130318_02

Connect-MsolServiceでは、まずlogin.microsoftonline.com(実体はlogin.microsoftonline.com.nsatc.net)に接続しに行った後、provisioningapi.microsoftonline.com(実体はprd-provisioning.msods.nsatc.net)に接続しにいくのですが、このprd-provisioning.msods.nsatc.netがAAAAレコードを持っているというところがポイントの様です。

というのも、この検証環境のOSはデフォルトの構成で適当に組んでいるので内部セグメントではIPv6が有効化されており、ドメコン上のDNSサーバで名前解決もできるのですが、ルーターやFirewall、回線はIPv6対応していなく、IPv6でインターネットに向けて通信ができないという、ちょっと特殊な環境です。

ご存じの通り、Windowsでは同一ホスト名に対してIPv4とIPv6の両方で接続ができる場合、IPv6での接続を優先的に試みます。今回、IPv6の通信がタイムアウトで失敗してIPv4にフェールバックされてくる前に、PowerShellの接続モジュールの方が耐えきれなくなってタイムアウトしている…という状況のようです。

…というわけで、IPv6を切ったら何の問題も無く繋がるようになりました。
20130318_05
20130318_04

Office365も段々とIPv6対応してくるサービスが増えてくるようなので、もう少ししっかりIPv6の構成をオンプレでも見直していった方が良いかもしれませんね。

Office 365 Enterpriseの独自ドメイン

前回のOffice 365 Midsize Businessに引き続き、今回はOffice 365 Enterpriseにおける独自ドメインについて書きたいと思います。

すいません、最初に言っておきます。この記事を投稿した時点ではMidsize Businessとの違いが見つけられませんでした。(今後変更になるかもしれないので、一応エントリーは分けて作成しておきます)

ドメイン関係のメニューなので、[ドメイン]メニューを開き、[ドメインの追加]を選択します。
20130316_01 20130316_02

Enterpriseのドメインの確認プロセスは、以下の3つのプロセスです。

  1. ドメイン名の確認
  2. 独自ドメイン名を持つユーザーの作成
  3. ドメインの目的の設定とDNSレコードのチェック

まずはドメインの確認を行います。ドメイン名を入力すると
20130316_03 20130316_04 20130316_05

そして、ここで出力された物をDNSサーバーに登録します。
20130316_06

DNSキャッシュのせいで少し時間が掛かる可能性が有りますが、これでドメインの所有確認が完了します。
20130316_07
20130316_08

続いてはこの独自ドメイン名を持つユーザーを追加するという工程ですが、これは後からでも追加できますので、特に追加せずに次に進みたいと思います。
20130316_09 20130316_10

最後に、独自ドメインを利用する上でのDNSのチェックです。以前はこの部分は後からトラブルシュートで実施することができましたが、今回からはウィザード中で実施する必要があるようです。

まずはドメインの用途を「Exchange Online」「Lync Online」「SharePoint Online」で選択します。デフォルトでは、Exchange OnlineとLync Onlineのチェックが付いていますが、SharePointのみ排他利用なので、チェックを入れる場合(サイト名として利用する場合)はExchange,Lyncでは利用できません。

ここでLyncのチェックを外したとしてもログオン用のIDとしてその独自ドメインを利用した場合、そのユーザーにLyncのサブスクリプションを付与するとその独自ドメインのSIPアドレスを持つアカウントがLyncで作成されてしまうので、あまり意味は持たないのかもしれません。

独自ドメイン名自体をExchange,Lyncにして、wwwなどのサブドメインを作成してそちらをSharePoint Onlineで利用されるというパターンが多いようです。
20130316_11 20130316_12 20130316_13

ここで表示されたレコードをDNSサーバーの方に設定させて、チェックが通ればこの工程は終了です。ちなみにここのチェックが完了していなくても、設定自体は完了しているのでOffice365は問題なく利用できます。特にSRVレコードが作成できない場合や、他のメール配信サーバーがあってSPFのTXTレコードの値をカスタマイズしている場合など、無視して利用する形になります。
20130316_14
20130316_15

ついでなので、PowerShellからドメインを追加する場合の手順について記載します。

ドメインの追加には、Windows PowerShell 用 Microsoft Online Services モジュールを立ち上げてOffice 365に接続後、New-MsolDomainコマンドレットを実行します。ドメイン認証用コードの取得はGet-MsolDomainVerificationDnsです。
20130316_18

確認はConfirm-MsolDomainコマンドレットで行います。エラーが出ない場合は成功です。画面の表示は変わりませんが、Get-MsolDomainでのStatusがUnverifiedからVerifiedに変わります。
20130316_18

また、最初に追加されたドメインの場合はそのテナントの既定のドメインにするという設定に自動的になりますので、そちらも必要に応じて修正します。

New-MsolDomain -Name ドメイン名
Get-MsolDomainVerificationDns -Mode DnsTxtRecord -DomainName ドメイン名
Confirm-MsolDomain -DomainName ドメイン名
Set-MsolDomain -Name ドメイン名 -IsDefault

1点だけ異なるのが、デフォルト状態でのドメインの用途がGUIから追加した場合はExchange OnlineとLync Onlineにチェックが入っていますが、PowerShellから作成した場合は用途に何も設定されていません。

このままだと、作成するDNSレコードの詳細などが分からないので[ドメイン]メニューから[DNS設定の表示]を開き、[ドメインの目的を変更する]でGUIのSTEP3のメニューを手動実行しましょう。

また、これは少し原因が分からないのですが、Confirm-MsolDomain コマンドレットで認証を行った場合、GUIの設定画面のSTEP1の最後の部分がエラーが出て完了できません。前述の通り、ドメインの認証さえ終わっていれば(GUIの場合DNS設定の表示が出せる状態、PowerShellの場合はGet-MsolDomainの値がVerifiedになっている状態)「セットアップが進行中です」のステータスのドメインでも問題なく利用できますが、少し気持ち悪いですね。

Office 365 Midsize Businessの独自ドメイン

2月より新たに提供開始された1-250名規模の企業向けのプラン、Office 365 Midsize Businessにおける独自ドメインの使用について紹介したいと思います。

Midsize Businessのメニュー体系は、プランEとほぼ同じです。独自ドメインの追加は[ドメイン]メニューの[ドメインの追加]から実施します。
20130315_01 20130315_02

Small Business Premiumが5ステップだったのに対して、こちらはDNSサーバをユーザー側で用意する分、手順が3ステップとかなり簡単になっています。

  1. ドメイン名の確認
  2. 独自ドメイン名を持つユーザーの作成
  3. ドメインの目的の設定とDNSレコードのチェック

まずは、追加したい独自ドメイン名を入力します。
20130315_03 20130315_04

手順の中では主要レジストラの手順が紹介されていますが、日本の場合は[一般的な手順]を読むと良いでしょう。
20130315_05

既存のDNSサーバに指定されたTXTレコードを記載します。ちなみに、このゾーンは試験用に作ったドメインということでデフォルトのTTL(最初の行)が300秒に設定されてますが、通常は3600(1時間)とか86400(1日)とかが多いと思うので、その場合はレコード毎のTTLを少し落として設定しても良いですね。(後でSPFとして利用されるTXTレコードの設定値をチェックする工程があるので、そこでの確認時間短縮のため)
20130315_06

最初のうちは以前の値がキャッシュされていたり、セカンダリDNS側への伝搬が完了していなかったりするので認証されなかったりしますが、キャッシュがクリアされ次第認証されます。(以前にTXTレコードが1つも無かった場合は、”そんなレコードは無い”という情報が他のDNSサーバでキャッシュされている可能性がありますが、ネガティブキャッシュと呼ばれるこの種のキャッシュの生存期間はSOAレコードの最後の行:minimumで指定されています。上記例であれば1日。気になるようであれば300秒とかに短縮しておきましょう)
20130315_07 20130315_08

続いて、独自ドメイン名のアカウントを作成できます。特に後からでも追加できますので、ここでは[今はユーザーを追加しません]を選択します。
20130315_09 20130315_10

次に、ドメインの目的とDNSのレコードチェックを行います。用途としては、ほぼ2択であり「(デフォルト)①Exchange、Lyncでサービス用のIDとして利用する」「②SharePointのWebサイトとして利用する」のどちらかになります。

ちなみに、ここで下の高度なセットアップを開いて[社内のメールボックスがOffice365で動作するようにセットアップ~]を選択すると、オンプレミスのExchange 2010とのハイブリッド構成用のコネクタの作成などがこの工程中で実施できます。
20130315_11 20130315_13

DNSサーバに設定するレコードの一覧が表示されます。メールで利用するTXTレコード、MXレコードの値が.protectionのサブドメインの付く新しい値に変わっているので、前のバージョンに慣れていた方は入力ミスにご注意下さい。
20130315_14 20130315_15

以前はここでウィザードは終了だったのですが、ここでDNSレコードがしっかり登録できたかどうかのチェックが終わらないと、セットアップが完了しないようになりました。以前もトラブルシュートの画面から設定を手動で確認することができたのですが、今回からは必須要件になったようです。

全てのレコードの設定が正しくないとエラーがでます。TXTとMXが正しく設定しているのに確認が取れないという場合は、おそらく手順1のチェックの際に取得した値をMicrosoft側のDNSがキャッシュとして保持していた場合のエラーなので、おとなしくキャッシュがクリアされる時間を待って再度確認します。

この工程ですが、チェックが完了していなくてもドメインの使用自体は既にできるようになっておりますので、お急ぎの場合は[閉じて後で戻る]などでも良いと思います。その場合、ドメインメニューを開いた場合のステータスが[セットアップが進行中]になります。そのリンクをクリックするとまたこのウィザードに戻る事が可能です。
20130315_16 20130315_17

これが完了すると、ドメインが正しく追加されます。DNSの設定を確認したりドメインの目的を編集したい場合は、[DNS設定の表示]を開いて行います。
20130315_18
20130315_19

余談ですが、また追加後の独自ドメインのステータスが[アクティブ]になりましたね。これ、以前のバージョンで、リリース当初は[アクティブ]だったのですが、途中からいつのまにか[確認済み]に仕様変更されていて、よくユーザーから「マニュアルの手順通りにやっても書いてある結果(アクティブ)にならない。どうしてだ?」と問い合わせを受けたものです…

Office 365 Small Business Premiumの独自ドメイン

特に、Small Business Premiumに関しては、専門の管理者外無くても構築・運用することが可能なように開発者側でケース毎のシナリオを多が用意され、セルフサービスにて解決が可能なように開発されております。

今回は、Small Business Premiumを実環境で利用する上で一番最初にやる必要があることが多い「自社ドメインの追加」について、実際の画面のイメージを交えながら解説していきたいと思います。

ドメインの追加は、[はじめに]ウィンドウと呼ばれる基本メニューの中の一番最初「電子メールアドレス」から実施します。
201303013_01

まず、一番最初に[Office365の電子メールアドレスを変更しますか]と聞かれるので、[今すぐ開始]を選択します。次の画面では、具体的に追加しようとするドメイン名について聞かれますので入力し、[次へ]をクリックします。
201303013_02 201303013_03

次に、そのドメインの用途として「①メールアドレスとして利用しているか」「②www.独自ドメイン名のサイトを持っているか。持っている場合は今のWebサーバをそのまま継続するか」について尋ねられます。ここでは、「①はい」「②はい。引き続き現在ホストされている場所に置きます。」を選択します。
201303013_04

ちなみに、ここで「はい。ただし、Office 365 で新しい Web サイトを作成して置き換えます。」を選択した場合は、電子メールアドレスを切り替えた後に「一般向けWebサイト」で移行をしてくれと表示されます。結局、ここで何と答えても、後からOffice365でホストするように変更が可能です。
201303013_05

これで、ようやくメインのドメイン追加プロセスに移ります。追加プロセスは主に5つのプロセスで行われます。
201303013_06

  1. ドメインの所有確認
  2. Webサイト向けDNSレコードの生成
  3. 既存ユーザーのログイン名/電子メールアドレス変更
  4. 独自ドメインのログイン名/電子メールアドレスを持つ新規ユーザーの追加
  5. ネームサーバーの変更

早速[手順1を開始する]を選択し、追加プロセスに入っていきたいと思います。マイクロソフトがいくつかDNSホスティングサービスを実施している業者の手順を作成してくれているのですが、残念ながら日本の物はありません。[この件に対応してくれる人物がいます。]という選択肢を選んだ場合の表示内容が一番シンプルでしっかりまとまっているので、今回はそちらを選びます。
201303013_07

TXTレコードまたはMXレコードを作成してくれというメッセージが表示されます。MXレコードは既存メールサーバへの配信が変わる可能性が有る(実際は、~.msv1.invalidという存在しないドメイン名なので理論的には悪影響は無いはずですが)ので、今回はTXTレコードで認証を行いたいと思います。bindのゾーンファイルを変更して、@(ドメイン名自身)のTXTレコードとしてMS=ms78940134を追加します。両側の” “はおまじないです。無くても別に認証は通ります。
201303013_08 201303013_09

登録が完了したら、[今すぐ確認する]を選択します。タイミングが早すぎるとエラーがでますが、少し待つと認証できるかと思います。(デフォルトTTLの設定や既存でTXTレコードが有るかどうかにもよるが、数分~1日程度だと思います) これで、STEP1は終了です。
201303013_10 201303013_11

さて、STEP2に移ります。
201303013_12

STEP2は、既存(もしくは新しく移行する)Webサイトの設定情報をOffice365でホストされるDNSのレコードに反映させる作業です。最初に既存のWebサイトのアドレスを調べてきて下さいという内容が出ます。丁寧に、「私のサイトのIPか、静的IPでなければFQDNを教えて下さい」というサンプル文書が表示されるのですが、残念ながら英語です。
201303013_13

調べたIPアドレス(もしくはFQDN)を入力します。ご丁寧に現在のDNSレコードを引いて、それと正しいかどうか見てくれるみたいです(そこまでわざわざやってくれるなら元から自分で検索して初期値として設定してくれればいいのに…とも思いますが)。これにより、wwwのCNAMEレコードとIPアドレスの場合は@のAレコードが、FQDNの場合はCNAMEレコードが裏で生成されます。
201303013_14 201303013_15 201303013_16 201303013_17

STEP3は既存ユーザーのメールアドレスの変更です。
201303013_18

既存のユーザー一覧が表示されますので、その中から電子メールアドレスを独自ドメインに変更したい物をチェックし、[更新]を押します。なお、この際に一緒にログイン名も独自ドメインに変更されます。
201303013_19 201303013_20

STEP4は独自ドメインのメールアドレスを持つユーザーアカウントの新規追加になりますが、今回は既存で作ってあり、STEP3で変更済みのため新規では作成せず、[いいえ。~の電子メールを使用しているのは私だけです]を選択します。既存のメールサーバーを利用しており、まだそのアドレスを持ったユーザーをOffice365に作成していない場合は、メールの受信を継続できるよう、ここの段階で必ず追加する必要があります。
201303013_21 201303013_22

最後のSTEP5は、ドメインのネームサーバをOffice365に変更するという一番大きい工程です。ここでミスしてしまうと、メールが受信できなくなったりWebサーバに接続できなくなったりかなり影響が大きいので、慎重に今までのSTEPが完了していることを確認してから実行しましょう。
201303013_23 201303013_24

ここでも各種レジストラの設定情報が表示されますが、残念ながら[使用しているサービスが一覧にない]を選択します。ネームサーバー1、ネームサーバー2として記載のある ns1.bdm.microsoftonline.com / ns2.bdm.microsoftonline.com のアドレスをメモしておきます。
201303013_25

前項でメモしたネームサーバーに、利用したい独自ドメインのネームサーバーを変更します。画面のイメージはお名前.comで実施した場合のイメージです。
201303013_26

反映にはしばらく時間が掛かることがありますが、完了したら以下の様に処理完了の旨の表示が出るので、[完了]をクリックし、[完了しました。]をクリックします。
201303013_27 201303013_28
201303013_29

これでドメインの追加は完了です。ドメインのステータスも、[確認済みの表示になります。]
201303013_30

ドメイン名を選択し、[DNSの管理]から既存の設定を見たり、WebサーバーのIPアドレスを変更したり、新たなホストレコードの追加などが可能になります。
201303013_31

【祝】新しいOffice365が提供開始

本日2/27のAM9:00、新しいOffice365がリリースされました。当初はイベントなどでもアメリカ時間で27日、日本時間では28日と言われていましたが、どうやらPSTではなくUTCで2/27 0:00から発売されたようです。

今までも他のプロダクトやサイトの公開などの基準はPSTだったものが、本社所在地に関係なくUTCで提供されるあたりが全世界共通で提供されるクラウドサービスっぽくて少し好感が持てました。

既存のユーザーの移行はこれからですが、すぐに新しいバージョンを触ってみたいという方は、新規で無料版を申し込めばすぐに触ってみることができます。

20130227_00
http://office.microsoft.com/ja-jp/business/

今まで提供されていたSmall BusinessにOfficeのサブスクリプションが付いたSmall Business Premiumと、新しく中規模ユーザ向けにユーザー数制限と一部機能並びに電話サポートが簡略化されたMidsize Business、ならびにフルスイートであるEnterpriseの3種類が試用できます。

ちなみに、3つの管理者画面の見た目は以下の通りです。

Small Business Premium
20130227_01

Midsise Business
20130227_02

Enterprise
20130227_03

MidsizeはEnterpriseとほぼ変わりませんが、Small Business Premiumはだいぶ異なる趣になっています。基本的には最初のダッシュボードからシナリオに従って設定すれば大体使えるというコンセプトになっているかと思います。

実は今回からSmall Business(Premium)はPowerShellがサポート範囲から外れておりますが、試した範囲ではEnterpriseなどと同じく今まで通り使うこともできるようなので、どうしても詳細な設定などが行いたくなった場合は利用しても良いかもしれません。

過去30日の障害履歴が閲覧可能に

Office365のサービス正常性ダッシュボードでは、従来は現在ならびに過去1週間のサービス状態のみ閲覧が可能でした。しかし、IT管理者の方が長期の休みの場合や、原因調査に時間が掛かって事後インシデントレポート(PIR)が遅くなったような場合に過去の物を参照できなくなるというケースがありました。

最近、このダッシュボードの上の部分に「過去30日間の履歴を表示する」というリンクが付くようになりました。
20130226_05

これを開くと、過去1ヶ月間に発生したインシデントの状態が一覧で表示されます。PIRが発行されている物はここからダウンロードすることができます。
20130226_06

これで、月次レポートなどを社内で作成する為に、データを毎週ダウンロードして保全しておくという手間が無くなり、月に1度で済むようになくなりました。

今後もどんどんユーザーの声を取り入れて良いサービスになっていって欲しいですね。(勿論、障害自体が無くなるにこしたことは無いと思いますが)