社内の環境で利用していたシステムを、Office365のようなインターネット上のクラウドサービスに移行すると、事前に検討・準備したつもりでもいざ導入となった時に色々と検討漏れが出てきてしまうことがあります。
単純に設定変更や運用回避などができる物であれば問題ないですが、例えば会社のセキュリティポリシーの変更やパソコンの入れ替え、VPNサービスの更改などが必要な場合、導入スケジュールに大きな影響を与えてしまうことがあります。
ここでは、メモ書き程度にOffice365の導入トラブルのあるあるを記載させて貰います。
①クライアントPCが要件を満たさない
②既存で利用しているメーラーが対応していない
③ユーザーがクライアントPCの管理者権限持っていない
Windows Server 2012は、デフォルトでインストールするとGUI無しのサーバコアモードでインストールされます。
テストやインストールのためにWindows Firewallを無効化することがたまにあるかと思うのですが、その際にGUIから無効化することはできないのでコマンドラインからの無効化の方法を紹介します。
コマンドプロンプト
C:>netsh advfirewall set allprofiles state off
もしくは、せっかくWindows Server2012からPowerShellで色々とできるようになったので、慣れておいたほうが良いかもしれません。
PowerShell
PS C:>Get-NetFirewallProfile | Set-NetFirewallProfile -Enabled false
戻すときは、逆にstate onか-Enabled trueです。一度覚えてしまえば簡単ですね。
PowerShellのヘルプは、Update可能なヘルプとして構成されており、Update-Helpコマンドでオンラインで更新をすることができます。
ただ、現在Windows Server 2012のRTM版で、Update-Helpコマンドを実行すると、一部のモジュールが含まれる場合に以下のようなエラーが出ることがあります。
Update-Help : UI カルチャ {ja-JP} を使用してモジュール ‘NetWNV, RemoteDesktop’ のヘルプを更新できませんでした: モジュール マニフェストの HelpInfoUri キーの値は、ヘルプ ファイルが格納されている Web サイト上のコンテナーまたはルート URL に解決される必要があります。HelpInfoUri ‘http://technet.microsoft.com/library/cc732148.aspx’ はコンテナーに解決されません。
これは、ヘルプのオンライン更新先で定義されている先のURL（HelpInfoUri）がまだ利用可能になっていないために発生するエラーです。
参照先は、各モジュールのマニュフェスト内で定義されています。例えば、上でエラーが出ているRemoteDesktopでは、 C:WindowsSystem32WindowsPowerShellv1.0ModulesRemoteDesktopRemoteDesktop.psd1 にて以下のように定義されています。
# HelpInfo URI of this module HelpInfoURI = 'http://go.microsoft.com/fwlink/?LinkId=225876'
ためしに表示されているhttp://go.microsoft.com/fwlink/?LinkId=225876にアクセスをしようとすると、http://technet.microsoft.com/library/cc732148.aspx にリダイレクトされ、「アクセスしようとしているドキュメントはまだご利用いただけません。」と表示されます。
現時点ではマイクロソフト側での公開が開始されるのを待つしかない状態かと思います。どうしてもエラーメッセージが出るのが気になる方は-Moduleオプションを利用して、個別にその他のモジュールのみヘルプをUpdateするという形になるかと思います。
例） PS C:> Update-Help -Module ServerManager
Advent Calendarとは、12月1日からクリスマスまでの間、参加者が日替わりで記事を書く年末恒例のイベントです。今年は、テーマ「Office 365」で実施したいと思います。
内容については特に制限は設けませんので、Office 365に関する事でしたら技術的なことでも、導入の体験談や関連ソフトの紹介などでも、何でも構いません。
誰も参加者がいないと、1人で25日間連続でblogを書かないといけないという悲惨な事態に陥ってしまうので、軽いノリで是非参加頂ければと思います。
Office365を導入する目的として最も多い要因は、メールシステムの更改かと思います。
各種ドキュメント、書籍や事例などによってかなり多くの情報が得られるようになってきましたが、Office365のExchange Onlineのベースとしているソフトウェア「Exchange Server」は、インターネット上で利用されてきているSendmailやPostfixなどのMTA（メール転送エージェント）と比較して、特徴的な実装となっているところがあります。
ここでは、Office365を導入する前に有益な情報となるよう、一般的なメールシステムと比較してのExchangeの特徴についていくつか記載をさせて頂きたいと思います。
①From詐称ができない
②MessageIDが重複するメールは1通しかメールボックスに届かない
③メールアドレスの表示名がサーバ側で自動的に書き換えられる
④MIMEエンコードはExchange外部に出る際に実施される
⑤Exchange内部ではMXレコードを参照せずに配信する
⑥キャッチオールアドレスは作成できない
⑦配布グループは通常メール以外は受け取れない
⑧メール以外の情報もメールボックスに格納されている
⑨メール送信処理はサーバー（メールボックス）で実施され、送信履歴も残る
⑩送ったメールのリボーク（取り消し）ができる
いかがでしたでしょうか？
知らない機能であったり、移行してみて少し挙動が変だなと思うことがあるような要因になるようなものを集めてみましたが、他にも「こんな事あるよ」とか「こうなってるのはどうなの？」とか有りましたら教えて頂けると幸いです。
Office365は、プランE・プランP共にディレクトリデータベースとしてWindows Azure Active Directoryを利用しています。Azure側は特に両者の区別はなく展開されており、利用するサービスが違うという扱いです。
この為、Windows Azure Active Directoryのポータルにサインオンすると、プランPとしてはサポートされていない（メニューに出てこない）シングルサインオンなどのメニューもプランE同様に表示されます。ここでは、Windows Azure Active Directoryを利用してADFSによるシングルサインオンをセットアップする手順を紹介致します。
ポータルにOffice365のアカウントを利用してサインインします。ポータルが表示された後は、メニューから独自ドメインを追加します。
手順はOffice365と同じです。ドメイン名を入力後に表示される ms=MSｘｘｘｘｘｘｘｘ という値をそのドメインのTXTレコードに追加して、確認を行います。
追加後はそのドメインの用途を選択する画面になりますので、必要なサービスを選択します。続いてその独自ドメインをOffice365で利用する際に必要なDNSレコードが表示されます。後から再度表示させることもできますので、ここではDNSの設定はせずに先に進みたいと思います。
続いて、新たなメニュー「統合」を開き、「ディレクトリ同期」のメニューを開きます。ADFSの展開前に、まず最初に時間のかかる（経験上、数時間以上掛かる場合もあります）「アクティブ化」を選択します。選択後はバックグラウンドで処理が行われていますので、シングルサインオンの設定に進みたいと思います。
まず、ADFS2.0 RTWをダウンロードし、インストールします。ついでにADFS 2.0 RU2（KB2681514）もインストールしておきます。
ADFSの設定ウィザードに行く前に、準備（①必要な証明書をIISにインストールする ②ADFSの実行用アカウントを作成する）をしておきます。ウィザードは特に上記2つの設定が出るくらいです。デフォルトWebサイトを先に作成している場合、デフォルトWebサイトの構成で警告が出ますが、特に問題は無いので先に進みます。
続いて、ドメインでシングルサインオンを有効化します。前項でドメインを既に追加している場合は、Convert-MsolDomainToFederatedコマンドレットを、新規で追加したドメインをシングルサインオンとして構成する場合はNew-MsolFederatedDomainコマンドレットを使用します。ここでは、新規追加の場合を例に挙げておきます。
事前準備として、サインインアシスタントとWindows PowerShell用Microsoft Online Servicesモジュールをインストールしておきます。
Connect-MsolService New-MsolFederatedDomain -DomainName contoso.com New-MsolFederatedDomain -DomainName contoso.com
1回目のNew-MsolFederatedDomainコマンドの後に、所有確認用のDNSレコードが表示されますので、追加後に再度同じコマンドを実行します。このコマンド終了後、今回は同じマシンにディレクトリ同期もインストールしようと思っており、これが残っているとディレクトリ同期のインストールに失敗するのでサインインアシスタントを一回アンインストールします。
次に、ディレクトリ同期のインストールです。10/23現在、Windows Azure Active Directoryポータルからダウンロード可能なディレクトリ同期ツールは、残念ながら今年いっぱいでサポート終了が決まっている32bit版なので、64bit版をOffice365からダウンロードするのが良いと思います。
ディレクトリ同期ツールは、インストールに比較的時間はかかるものの、特に選択肢は無くそのまま終了します。また、ここでサインインアシスタントが同時にインストールされてます。同梱されているバージョンが単体で入手できる物より少し古いので、気になる方はWindowsUpdateでバージョンアップすると良いと思います。
一旦Office365のポータルに戻って、ディレクトリ同期が有効化されたことを確認してからディレクトリ同期の設定に入ります。
必要な情報は、Office365のインポート/エクスポートに利用するOffice365の管理者アカウントと、ADからの同期用アカウント（MSOL_AD_SYNC）の設定を行うのに必要なADの管理者アカウントの情報です。
と、ここまでの工程を実施すると、
プランP1のテナントでもディレクトリ同期やシングルサインオンができるようになります。
ちなみに、Windows Azure Active Directoryポータルを経由しなくても、直接PowerShellコマンドレット（Set-MsolDirSyncEnabled -EnableDirSync $true）とかでも有効化できます。
ただし、プランP1のサポートはコミュニティサポートのみであり、コミュニティでは基本的にシングルサインオンなどは対象外となっているようなので、お試しの際はあくまで自己責任で実施されるようお願い致します。
Exchange Onlineは、Exchange Server 2010をベースに構成されております。この為、基本的な機能はオンプレミスのExchangeと同じですが、細かい使い勝手で差分があります。
クラウドサービスであるOffice365を使う上では、導入前にその差分について十分検討し、Fit&Gapを行っていくことが重要です。機能一覧上は一見オンプレミスと同じだし、価格も安いので…というだけで導入を決めてしまうとあまり良い結果を生まないと思います。
ここでは、構築運用実績のあるExchangeエンジニアの立場として、オンプレミスのExchange 2010と比較した場合のクラウド（Office 365）のExchange Onlineについて、いくつかのポイントに絞って考えてみたいと思います。
詳細はExchange Onlineサービス詳細の巻末の機能比較表をご覧下さい。
簡単に並べるとこんな所でしょうか？
これだけ書くと、デメリットばかり並べているように見えますが、これだけ多くのお客様がOffice365を導入しているという事例などを見ますと、代替案などを検討して上手く落としどころを作ったり、サービスの方に合わせて自社の運用を変えたり、割り切ったり…という決断をされたお客様は結構多いということなのではないでしょうか。
Microsoftからアナウンスが有りましたが、ディレクトリ同期ツールの32bit版がサポート切れになるとのこと。年内に64bit版にアップグレードする必要が出て参りましたので、ここでは、簡単にディレクトリ同期ツールのアップグレードについてお話をさせて頂きたいと思います。
まず、基本的な説明から。ディレクトリ同期の32bit版を利用されている場合は、通常Windows Server 2008を利用されており、64bit版の導入に当たってはWindows Server 2008R2になる形となるかと思いますので、基本的にはOSごと入れ替えるという形になります。
詳細は以下の図で軽く説明をしておりますが、この入れ替えに際して、旧サーバで最後に行った同期から、新しいサーバで最初に同期を実施するまでの間にActive Directory上でオブジェクトの「削除」が行われると、Office365（Windows Azure Active Directory）上にゴミのオブジェクトが残ってしまいます。このオブジェクトはディレクトリ同期されている物と認識されてますので、ポータル等から削除できないオブジェクトとして残ってしまって消すのは結構大変です。※1
そこで、このリスクの生じる時間に関してはなるべく短くなるように計画し、かつドメインコントローラー間の同期間隔を考慮して、その周辺の時間はメンテナンス時間として確保してActive Directoryへの変更は行われないように運用対処するのが望ましいと思われます。
作業自体は簡単で、新規でのインストールとあまり変わりません。移行先として別の筐体という前提で簡単に手順を書きますと、
この工程の中で、ディレクトリ同期で利用する「MSOL_AD_Sync」アカウントのリセットが行われ、AD内でディレクトリ同期を行うことができるサーバが新サーバに切り替わります。また、終了後に再度Active DirectoryのオブジェクトとOffice365のオブジェクトのマッチングが実施されます。マッチングは、基本的には既に同期済みであり、キーとなるSourceAnchorが設定されていますので、特にこの間に変更が行われていない限りはハードマッチして元の状態になります。
同じ筐体を利用するということであれば、3番の後にOSをクリーンインストールして、ディレクトリ同期ツールをインストールするという形になるかと思います。
また、前に紹介したようなディレクトリ同期対象のフィルタなど、個別のカスタマイズ設定や、ローカルのMIIS_Adminsグループに追加したユーザは、当然新しいサーバになると全てクリアされますので、再設定が必要な場合は忘れずに実施するようにしましょう。
※1 ゴミが残ってしまった場合、放置しておくとそのオブジェクトで利用していたUPN、Emailアドレスなどの属性が再利用できなくなってしまうなどの弊害が残りますので、以下のいずれかの方法で削除する形となります。
【参考】
サービスに関する通知：【重要】32 ビットのディレクトリ同期ツールは 2013 年 1 月 1 日までに 64 ビット版に切り替えてください
ディレクトリ同期ツールをアップグレードする
10/1に通知があり、Microsoft MVPをOffice365のカテゴリで受賞させて頂いたとのこと。
これも、いつもblogを見に来て下さっている皆様や、勉強会などの場を提供頂いている方々のおかげだと感謝しております。今後も、blogにコミュニティに、皆様に役立つ情報を発信していきたいと思いますので、よろしくお願い致します。
2012.10～
BPOS-S ではSRで受信トレイルールの上限値を増加することが可能でしたが、Office 365では当初64KBに上限値が設定され、その上限値を上回る受信トレイルールを作成することはできませんでした。
この為、作成の仕方によっては（例えば、多数のメルマガを受信していてそのメルマガ毎に専用のフォルダに振り分ける、ある条件に合致したメールを特定の携帯などのアドレスに転送する、などの使い方などをされている場合）、この上限値に引っかかって新規で受信トレイルールを作成できなくなることがございました。
Office365サービスの改訂により、PowerShellが利用可能な場合、この制限を管理者が緩和できるようになったようなのでやり方を紹介します。
Set-Mailbox username@contoso.com -RulesQuota 256KB
このコマンドにより、username@contoso.comの受信トレイルールのクォータサイズが標準の64KBから最大値（256KB）に拡張されます。単純に計算して4倍の受信トレイルールを作成することが出来るわけです。
なお、テナントによってはまだ実施できない可能性も御座いますので、その場合は修正が適用されるまでお待ち下さい。
