喜んだのもつかの間、延期通知が来ましたorz
さて、バージョンアップはいつになることやら…
予想と違ったのは、以下くらいですかね?
ポータルにログインすると、しっかり通知文が出るようになりました。
ちなみに、通知メールのfromは Microsoft Office 365 Team <Office365@microsoftonline.com> タイトルはサービスに関する通知: Office 365 サービスのアップグレードが 2013年 ・・・・・日 に予定されています です。
管理者の権限を持っているユーザー全員+パートナー(登録している場合)に対して送信されますので、spamだと思って捨てないようにお気を付け下さい。
Windows Server 2012が発売された当初は、PowerShellモジュールが対応していなかった為に、レジストリをいじらないとOffice365へのシングルサインオンの設定ができなかったのですが、最近モジュールがバージョンアップされて、インストールできるようになったとのことで、早速試してみました。
今回は、検証環境としてこんな環境を作ってみたいと思います。(Office365は新しいバージョンのEnterpriseを利用しています。)
Office365のシングルサインオンの構成自体は、慣れていればかなり簡単に構成できるようになっていますが、少し事前の準備が必要な部分などが多いので、まずはその部分からいくつか説明します。
【準備①.ディレクトリ同期のアクティブ化】
Office 365管理センターの [ユーザーとグループ] – [シングルサインオン][管理]を開き、Active Directory同期の[アクティブ化]を選択します。これは、最大24時間かかると画面にも表示されますが、経験上も処理の完了までに数時間は掛かりますので、インストールの前日までに実施してアクティブ化しておくことをお勧めします。
【準備②.公的SSL証明書の発行】
ほとんどのケースにおいて、ADFSで利用する証明書は外部の公的機関の証明するSSL証明書が必要となります。(Go DaddyやComodoなどの安価な物でもOKです。) SSLの証明書の発行にはお金のやりとりや証明書類のやりとりなどで時間が掛かる場合があるので、早めに申請しておきます。
IISからであれば、[サーバー証明書]を開き[証明書要求の作成]からCSRを作成し、証明書が発行されたら[証明書要求の完了]をした後に秘密鍵と共に.pfxファイルに[エクスポート]しておきましょう。このファイルはAD FSならびにAD FS Proxy両方のサーバーで利用します。
【準備③.ADFSサービスアカウントの作成】
Active Directory内に、ADFSのサービス用アカウントを作成します。AD FSサービスはこのアカウントで実行されますが、パスワードの有効期限が切れた場合は動作できなくなりますので、[パスワードを無期限にする]を選択する必要があります。
AD FSサービスのインストール用のアカウントとして利用しないのであれば、特にドメインの管理権限は必要ありません。
【準備④.代替UPNサフィックスの設定(オプション)】
既存のActive Directoryが、インターネットから解決できないドメイン(例えばcontoso.local)で構成されている場合は、代替UPNサフィックスを作成して、ユーザーのUPN名を username@contoso.local から username@contoso.com に変更します。
Active Directoryドメインと信頼関係でプロパティを開き、[代わりのUPNサフィックス]の欄に自身で所有しているドメイン名を入力します。比較的ユーザー数が少ない場合などは、Active DirectoryユーザーとコンピューターからOffice365で利用するユーザーを選択した後、プロパティの[アカウント][UPNサフィックス]から代替UPNサフィックスに変更することができます。今後、新しくユーザーを作成する場合、プルダウンの中から代替UPNサフィックスが選択できるようになっているので、そちらを選択するようにします。
【準備⑤.ADFSサービス名の内部DNSへのレコードの作成】
ADFSサービス名は、内部DNSと外部DNSで異なるIPアドレスとして解決される必要があります。
(内部DNS…AD FSサーバー群、外部DNS…AD FS Proxyサーバー群)
内部のDNS(通常はActive DirectoryのDNS)において、代替UPNサフィックスのゾーンが存在しない場合は、それを追加します。contoso.com全体としてゾーンを作成しても良いですし、AD FSのサービス名(sts.contoso.com)のみのゾーンを作成しても構いません。今回は、AD FSサービス名のゾーンを作成して進めます。
ゾーンの準備ができたら、AD FSサービス名のAレコードを作成します。通常は、AD FSファームで利用する仮想IPを指定しますが、今回は検証環境で1台しかないので同じIPアドレスを指定します。
※なお、MXレコードやAutodiscoverのCNAMEレコードなど、Office365のドメインの情報で追加するように表示された物は外部DNSのみではなく内部DNSにも忘れずに書くようにして下さい。(内部DNSにゾーンが存在しない場合は外部DNSで解決されるので問題ありません)
【準備⑥.必要なコンポーネントのダウンロード】
シングルサインオン環境の構築に必要なモジュールは、全て事前にダウンロードが可能です。インストールをスムーズに行うためにも、事前にダウンロードして準備しておくのがよろしいかと思われます。サインインアシスタント以外は、Office 365管理センターの [ユーザーとグループ] – [シングルサインオン][管理]のページからダウンロード可能です。
これで、準備は完了です。
それでは、いよいよAD FSのセットアップに入っていきたいと思います。まずは、w15adfsをActive Directoryドメイン(w15jp.local)に所属させます。
そして、AD FSをインストールします。Windows Server 2008 R2などと違い、Windows Server 2012では標準でAD FSが役割として入っておりますので、[役割と機能の追加]から[Active Directoryフェデレーションサービス]を追加します。選択した際に、他に必要なモジュールも合わせて選択されます。
また、PowerShellモジュールのインストールに.NET Framework 3.5が必要なので、機能の欄で[.NET Framework 3.5 Features]を追加します。
この際、.NET Framerork 3.5の機能は、初期インストールされた際にデフォルトだとハードディスクにコピーされてきていないので、OSのインストールメディアをマウントし、そのパスを[代替ソースパスの設定]から指定します。(指定しないとインターネットからダウンロードして設定する形となりますので、環境にもよりますが時間がかかります。)
AD FSの構成の前に、事前準備の段階で用意しておいたSSL証明書を、IISマネージャーの[サーバー証明書]を開いてインポートしておきます。
引き続き、AD FSの初期設定を行います。AD FSファームの構築にはActive DirectoryへのSPNの設定権限が必要なので、ドメイン管理権限を持つアカウントでAD FSサーバーにログオンし、[管理ツール][AD FSの管理]を開き、[AD FSフェデレーションサーバーの構成ウィザード]を実行します。
今回は1台目のサーバーなので、[●新しいフェデレーションサービスを作成する][●新しいフェデレーションサーバーファーム]を選択します。
また、AD FSサービス名の指定では前の工程でインポートしたSSL証明書を選択し、AD FSサーバーファームのサービスアカウント名/パスワードも事前に作成しておいた物を指定します。
画面上では必要な構成が未完了ですと表示されますが、AD FSのOffice 365とのフェデレーション設定は、AD FS管理コンソールではなくPowerShellから実施するのでこの画面は一旦閉じます。
PowerShellからの設定を行うため、Microsoft Online Servicesサインインアシスタントをインストールします。
続いて、Windows PowerShell用Windows Azure Actitive Directoryモジュールをインストールします。これも、特にパラメーターなどはなくインストールできます。
今回は、以前投稿した独自ドメインの追加手順で使ったドメインを用いてそのままシングルサインオンを構成しますので、Convert-MsolDomainToFederatedコマンドレットを利用して行います。AD FSサーバー上からWindows PowerShell用Windows Azure Active Directoryモジュールを起動し、以下のコマンドを入力します。
$LiveCred = Get-Credential Connect-MsolService -Credential $LiveCred Convert-MsolFederatedDomainToFederated -DomainName w15jp.info
1行目のコマンドの際にID/PASSの入力を求められますので、Office365の全体管理者のID/PASSを指定します。Successfully Updated ‘w15jp.info’ domain.などと表示されれば処理は完了です。
これで、AD FSのセットアップは完了です。
引き続き、ディレクトリ同期のセットアップに移ります。今回は、AD FSと同一サーバー上にディレクトリ同期ツールをインストールしますので、ディレクトリ同期のセットアップエラーのエントリーで記載したとおり、事前にMicrosoft Online Servicesサインインアシスタントをアンインストールしてからインストールを実行します。
ディレクトリ同期ツールのインストーラーを管理者として実行します。
引き続き、Windows Azure Active Directory同期ツールの構成ウィザードに移ります。事前準備のディレクトリ同期のアクティブ化が完了していることを確認し、Windows Azure Active Directory管理者の資格情報にはOffice365の全体管理者アカウントを、Active Directoryの資格情報にはEnterprise Adminsの権限のアカウントを指定します。
これで、AD FSを利用してOffice365にシングルサインオンする環境が整いました。
早速動作を確かめてみたいと思います。ディレクトリ同期されたアカウントにはOffice 365のライセンスが割り当てられていませんので、Office 365管理センターから[同期済みユーザーのアクティブ化]を行い、ライセンスを割り当てます。
また、クライアント側でも1つ設定を行う必要があります。ブラウザから現在のログオン情報をAD FSサーバーに渡せるように、[インターネットオプション][セキュリティ]から、[ローカルイントラネット]にADFSサービスのアドレスを追加します。また、[信頼済みサイト]に*.microsoftonline.com、*.outlook.com、*.sharepoint.com、*.lync.comも追加しておきます。
そして、Office365のサインイン画面から自分のActive Directoryのアドレスを入れると、Office365にシングルサインオンができます。
BIG-IP LTM VEによるADFSの冗長化#1に準備した環境に、いよいよAD FSの冗長化設定を行っていきたいと思います。
ADFS側のモニターです。Intervalは少し長めにしますが、実際のID/PASSでログオンできるかどうかまでモニターしてますので、かなり正確にKeepAliveすることができるかと思います。
AD FS Proxy側は少しシンプルに、IISでTCP/443から正常応答が来るかどうかで判定しています。
これで、AD FS側とAD FS Proxy側のモニターが作成できました。
続いて、プールを作成します。(今回は単体の用途で利用しますので、ノードはプールの作成の中で同時に作成します。) AD FS、AD FS Proxyそれぞれで適切なモニタを設定した物を作成し、Load Balancing MethodをLeast Connections (member)にし、適切なサーバーのIPアドレスをノードに追加します。
正しく作成され、サーバも正常稼働している場合はプールのStatusが緑色の●の表示となります。
IPアドレス等の他には、以下の様な設定を行います。
バーチャルサーバができあがると、プールと同じようにStatusが緑の●になります。
最後に、冗長化しているのでConfig Syncを行います。[Device]の[Overview]でMaster側のマシンを選択し、[Sync Device to Group]を選択して[Sync]します。
これで、設定は完了です。最後にポータルからサインインができるかどうかを確かめます。
問題なくサインオンできました。これで冗長化に必要な作業は完了です。
Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”
https://devcentral.f5.com/blogs/us/big-ip-and-adfs-part-1-ndash-ldquoload-balancing-the-adfs-farm-rdquo
ADFSやADFS Proxyを冗長化する場合、アプリケーションレベルでの障害をKeepAliveにより検知し、自動的に切り離しを行おうとすると、Microsoft標準のNLBでは実現できず、ハードウェアのLBが必要になります。
従来は専用機を利用して高価なシステムとなっていたハードウェアロードバランサを利用した構成ですが、昨今、仮想上で動作する仮想化アプライアンスなどが安価に利用できるようになってきました。
今回はF5のBIG-IP Local Traffic Manager Virtual Edition(Hyper-V)などが発売され、比較的安価に、しかも冗長構成で組めるとのことで、手元のADFS環境に導入できるかどうか試してみました。
論理的には以下の様な感じの構成で組みたいと思います。(IPアドレスが飛び飛びなのは他のマシンがいっぱいるからです。見づらくてスイマセン。)
BIG-IPは勿論スタンドアロンの構成にすることもできますが、2台用意することにより冗長構成も取ることができます。今回は、異なるHyper-Vホスト上に2台置いて冗長構成としたいと思います。基本的な手順は同じなので1台目の方で説明します。
まずは、F5のサイトからHyper-V用のイメージを落としてきます。今回は11.3のイメージが有ったのでそれを利用します。
では、VMを立てていきたいと思います。メモリは4096MB割り当てます。パフォーマンスを重視したい場合は8192MBでも良いようです。また、NICは11.3ではレガシーではない通常のNICが利用できます。最初のNICがManagement用のポートになるので、新規作成のウィザードではそのvSWを指定します。そして、仮想ハードディスクとして先ほどダウンロードしてきたVHDファイルを指定してウィザードを終了させます。
次に、作成したVMの設定画面を開き、いくつか修正をします。プロセッサは「数を2に」「予約を100%に」します。LBでは周りのサーバの負荷に影響されずに安定した動作が求められている上での推奨事項です。
ネットワークアダプタで、他に必要なポートを追加します。スタンドアロンの場合は「Management」「Internal」「External」で3つ、冗長構成とする場合は「HA」を加えた計4つのNICを作成します。(HA構成の場合も、フローティングIP(VIP)は実MACアドレスで通信を行うのでMACアドレススプーフィングのチェックは入れなくて大丈夫です。)
また、自動停止アクションで「ゲストオペレーティングシステムをシャットダウンする」を選択します。
同様に2号機側も同じような設定で作成します。
これで、Big-IPを起動します。普通のLinuxコンソールが立ち上がってきますので、デフォルトのID: root / Pass: defaultでログインします。
BIG-IPの設定は基本的にブラウザから行いますが、そこに接続する為のManagementのIPを設定する必要がある為、configコマンドを実行します。(もしManagementのセグメントでDHCPが有効化されているのであればこの工程は省略できます)
簡易的なユーティリティが立ち上がりますので、IPとサブネット、もし管理PCが異なるセグメントから接続してくる場合はデフォルトゲートウェイを設定します。なお、このインターフェイスは実際のサービスとは切り離されて利用されます。ここで設定したデフォルトゲートウェイは管理用にのみ利用されます。
設定したIPに対してブラウザから接続します。証明書エラーが出ると思いますが、無視して進めます。
初期パスワードはID: admin Pass: adminです。(先ほどのrootとは違うので注意して下さい)
最初はライセンスのアクティベーションを行います。私の環境だとなぜか上手くオンラインでできなかったので、Activation MethodでManualを選択し、ブラウザからライセンスキーを取得して設定しました。正しいキーを入れてしばらく待つと、アクティベーションされます。
Resource Provisioningは特に今回は検証環境で意識しないのでそのままNextを選択します。
Management関連の設定です。先ほど設定したIPアドレスを確認(DHCPで割り当てていた場合はそれを固定設定)して、rootならびにadminのパスワードなどを適宜設定します。
続いて、ネットワークの構成です。Standard Network Configurationで行いますのでNextを選択します。
続いて、ネットワークインターフェイスの設定を行います。順番はInternal、External、HAのになります。また、最初にHyper-Vから作成したvNICが順に1.1,1.2,1.3として認識されていますので正しい値とvNICを割り当てます。
ConfigSync、Failover、Mirroringの設定はそれぞれデフォルトのままでNextとします。
これで、Active/Standbyのペア設定を行うためのActive機側の準備が整いました。続いて、Stanby機の方でも設定を行います。(Standby機の方はConfigure Peer Deviceの画面でFinishedを押してセットアップユーティリティを完了させておきます。)
Standby機の設定が完了した後、Active機側でDiscover Configured Peer DeviceでNextを押して設定を進めます。
セカンダリ機の情報を入力し、Retrieve Device Informationを押すと、セカンダリ側の情報が取得できますので、Finishedします。
Device ManagementのOverviewから同期の状態が見れますので、ここでSyncを押すと同期が完了します。
これで、HA構成のロードバランサが設定できました。続いては実際のADFSの冗長化に取り掛かりたいと思います。
(参考)
Manual: BIG-IP Virtual Edition Setup Guide for Microsoft Hyper-V
http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ve-hyper-v-setup-11-3-0.html
Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”
https://devcentral.f5.com/blogs/us/big-ip-and-adfs-part-1-ndash-ldquoload-balancing-the-adfs-farm-rdquo
BIG-IP LTM Virtual Edition Trial セットアップガイド
http://f5networks.co.jp/shared/pdf/BIG-IP_TB_setup_ve_trial.pdf
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を運用。セカンダリ側だけレジストラに依頼するのが楽かもしれませんね。
Exchange Onlineと同様、Small Businessのテナントからは、Lync Onlineの管理者画面(Lync管理センター)に接続するためのメニューは提供されていません。
管理者による設定は、全て管理ポータルの[サービス設定][IM、ミーティング、および会議]などの画面から設定を行う形になります。
ただ、こちらもExchange同様、管理者画面へのリンクが張られていないだけであり、実際は接続するすることは可能です。管理画面のURLは、https://admin.online.lync.com/lscp/?language=ja-JP です。(テナント毎に収容が異なる可能性が有ります。)
本来のURLは、上記から更に細分化されたhttps://admin0f.online.lync.com/lscp/?language=ja-JP&tenantID=(テナントID) などになります。上記のURLなどで接続できない、設定が反映されないなどの場合は、テナントIDは、上記管理画面のHTMLファイルのソースを見れば<div id=”TraceInfoDiv”>の中にTID=で入っていますので調べることが可能です。
非サポートの手順となりますので、いつ接続できなくなるか分からない/この画面から設定変更することによりその後のサービスの利用に支障を来す可能性が有る、など、接続の際には十分ご留意頂ければと思います。
Exchange Onlineのブラウザによる設定は、通常Exchange管理センター(略EAC、旧ECP:Exchangeコントロールパネル)から実施します。
ただし、新しいOffice 365のSmall Business(Premium含む)については、Exchange、SharePoint、Lyncの設定をそれぞれの画面から実施するのでは無く、管理ポータル上から一元的に実施できるようにインターフェイスが変更されています。
例えば、サービス設定の画面からは予定表の共有やActiveSyncの設定が行えます。
ユーザーとグループからは、外部連絡先/配布グループ/共有メールボックスの作成などが行えます。
ただし、現在の時点で設定できる項目は少なく、従来行えていたようなよりきめ細やかな設定などは実施することができません。
また、OWAの設定メニューの[オプション]を押せば、Exchange管理センターにつながりますが、個人用の設定の画面のみであり、従来接続できた[組織]の設定の画面に行くことができません。(MidsizeBusiness/Enterpriseであれば、上部の[管理者▼]メニューの[Exchange]から接続できますが)
そこで、Exchange管理センターに接続したい場合は、管理者アカウントから上記画面に接続した後、ブラウザのアドレスバーの/ecp/以降の文字列?rfr=owa…以降を全て削除したURL(https: //pod510xx.outlook.com/ecp/ )に対して接続します。そうすると、管理者アカウントのデフォルト画面である組織の管理画面に接続することができます。
PowerShellからの接続同様、【利用できるけどサポート無し】というポリシーでの利用となるかと思いますのでご使用の際にはご留意頂ければと思います。
久しぶりに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
他の環境から実行したところ特に問題く接続できるので、クラウド側の障害とかでは無さそうに思えます。下の方のレイヤでの障害が疑われるので、とりあえずWireSharkでパケットを追ってみると、何となくそれらしい所が見つかりました。
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を切ったら何の問題も無く繋がるようになりました。
Office365も段々とIPv6対応してくるサービスが増えてくるようなので、もう少ししっかりIPv6の構成をオンプレでも見直していった方が良いかもしれませんね。
新しいOffice365では、今までPowerShellからしか実行できなかった設定変更のうち、利用頻度の高い物をGUI(Exchange管理センター)から実施できるようになりました。今回は、機能のON/OFFのうち、ニーズの多い物について説明したいと思います。
まずは、連絡先(画面上での表記はPeople)についてです。連絡先関係で制御ができるのは、主に以下のパターンです。
1)のソーシャル連携、良く話を受けますがインターネット上の個人のアカウントと会社のメールのアドレス帳の連携は禁止したいという要望は日本の企業としては大きいようです。GUIからは「LinkedIn連絡先の同期」「Facebook連絡先の同期」のチェックを外します。PowerShellから実施する場合は、Set-OwaMailboxPolicyの「-LinkedInEnabled $false」「-FacebookEnabled $false」です。
2)について、Outlookではビル毎の会議室などのアドレス帳のサブセットを作った際に階層構造で表示できるのですが、OWAは名前順になってしまうので、見た目上あまり綺麗じゃないなどの場合に利用します。PowerShellだと「-AllAddressListsEnabled $false」です。
これを適用すると、個人の連絡先の他に[ディレクトリ]だけ表示されるようになります。
3)のグローバルアドレス帳(2番でいう[ディレクトリ])を無効化するというのは、PowerShellからしか実施できませんが、2の設定に加えて「-GlobalAddressListEnabled $false」を指定すれば表示を個人の連絡先だけにするということができます。
この状態でも、メール作成時などに検索をすることはできますので、アドレス一覧で運用するのが現実的では無いような大規模なユーザーではニーズがある設定かと思います。
4)はGUIからであれば[連絡先]のチェックを外す、PowerShellの場合は「-ContactsEnabled $false」で消せます。かなりドラスティックですが、個人の連絡先を消す場合はこの設定になります。前述の通り検索は可能なので、グローバルアドレス帳の検索のみでの運用としたい場合はこの設定にします。
続いては、予定表関係です。 予定表は他のグループウェアなどで管理しているので利用させたくない場合などに利用します。
GUIの場合は[予定表]のチェックボックスを、PowerShellであれば「-CalendarEnabled $false」で予定表自体の表示を消せます。Outlookと併用している場合など必要に応じて[アラームと通知]も消して下さい。
タスク(仕事)に関してはGUIの[タスク]かPowerShellの「-TasksEnabled $false」で設定ができます。私の試した限りでは、環境ではメール下部の[タスク]の表示は消えず、クリックするとタスク画面に移ったのがクリックしてもタスク画面に移れないという挙動に変更になりました。
メモ、OWAからの場合は受信トレイの下部フォルダから見れるようになっているのですが、これも消せます。GUIの[メモ]またはPowerShellの「-NotesEnabled $false」です。
さて、これらを全て消すと、Exchange Onlineしかサブスクリプションを設定しないユーザーはOutlookしか表示されなくなり、かなりシンプルになります。本当に限定的なWebメーラーとしての使い方をしたい場合にはアリかもしれません。
Set-OwaMailboxPolicy OwaMailboxPolicy-Default -TasksEnabled $false -CalendarEnabled $false -ContactsEnabled $false
ただ、将来的には会議室予約やタスク・スケジュールとの連携などExchangeのフル機能を利用し、業務を効率化していく事を是非目指していって欲しいですね。
最後に注意点ですが、これはあくまでOWAから接続できないように設定をしているのみですので、Outlookを利用した場合は普通に利用できます。そちらも合わせて制御するのであればOfficeのポリシーテンプレートとかで制御する必要があります。