ExchangeからOffice365移行の際の注意点

オンプレミスのExchange Serverを利用されていて、BCPなどからOffice365への導入を検討される方も多いかと思います。現時点でドキュメント等に載っていない移行を検討する上での留意点がありますので、紹介させて頂きます。

Exchangeをインストールすると、オンプレミスのActive Directoryのスキーマが拡張され、各ユーザのADオブジェクトにExchange関連の属性が設定されます。この中に、アカウントに紐付くメールボックスを指定するmsExchMailboxGuidという属性が有ります。(多分Exchange 2000から利用されていたと思います)

この属性に値が設定されているままでOffice365にディレクトリ同期を実施した場合、『移行ツール以外からメールボックスを有効にできなくなります

試しにダミーの値を入れて検証してみます。adfs serviceというメールボックスの無いアカウントにmsExchMailboxGuidを設定します。

ディレクトリ同期された後、メールボックスを有効化する為にExchange Onlineのサブスクリプションを付与しようとすると、以下のメッセージが表示されます。

この移行バッチ以外からメールボックスが有効化できないということは、以下のような影響があります。

  • メールボックスを「移行しないでMX切り替えのみ」という移行方法の選択肢が取れない
  • オンプレがExchange2000の場合は、移行ツールを動かす為に2003以上にUpgradeが必要
  • Exchange移行ではなくIMAP移行はできない(IMAPは移行ツール実行前にメールボックスを作る必要がある)

では、対策を少しだけ考えてみます。まずは、

①既にオンプレのExchangeを利用していない場合

A.これは単純です。当該属性(msExchMailboxGuid)をオンプレのAD上で削除してしまい、再度同期をすればOKです。

②オンプレのExchangeを移行前にはオフラインにできない場合

B.一番綺麗な方法は、移行(メールボックスを有効にしたいタイミング)時にディレクトリ同期専用のAD DSを一時的に立てて、そこで当該属性の情報をクリーニングしてから同期させることです。msExchMailboxGuidが邪魔なのは、あくまでメールボックスを有効にするタイミングのみです。メールボックスが作成された後は、同期されるオンプレの当該属性に何か値が入っていても特に問題なく動作します。

C.移行が長期に渡る場合や、余分なAD DSを立てられない様な場合ですが、ディレクトリ同期サーバのMAの設定を書き換えて対応する必要があります。

ということで、案Cを実現させる為の設定をなるべく単純な方法で書いてみたいと思います。

①まず、ディレクトリ同期サーバに入って、C:Program FilesMicrosoft Online Directory SyncSYNCBUSUIShellmiisclient.exe を起動します。
②続いて、[Management Agents]-[TargetWebService]を選択し、[Properties]を開きます。
③[Configure Attribute Flow]を選択して、(Data Source Attribute)msExchMailboxGuid←(Metaverse Attribute)msExchMailboxGuidのExport(Direct,Allow Nulls)となっているルールを探します
④これをおもむろにDeleteします。

これで、Metaverseに格納されたmsExchMailboxGuidの属性をOffice365に同期するというデータフローが無くなります。ディレクトリ同期開始前であれば、これが終わってから同期を開始すれば大丈夫です。

ただ、一度でもディレクトリ同期をしてしまった後(msExchMailboxGuidが一度Office365側に同期されている)については、Metaverseのデータ自体が変更になっているわけでは無いので、再度フル同期をかけても当該属性のUpdate処理は走りません。

このため、Office365のディレクトリ同期で特定アカウントを非同期にするで紹介したやり方を使って、一度対象のアカウントのSource AD側をExplicit Disconnectorに設定し、同期することにより一時的にOffice365からアカウントを削除します。そして、それを再び解除(手動でProvisioningするか、通常のDisconectorにしてから再同期)してから同期を行い、Office365にアカウントを作成し直すことにより、msExchMailboxGuidがNullの状態で同期されるようになります。

というわけで、凄く面倒なので早くOffice365側の仕様を変更して欲しいですね…

AD FS環境でログオンユーザ以外でOffice365にログオンする(2)

以前の投稿 で書きましたが、AD FSを利用したシングルサインオン環境だと、強制的にWindowsにログオンしているADのアカウントでOffice365にログインしてしまいます。通常はそれほど問題にならないのですが、

  • 共用で利用しているグループのアカウントが存在する
  • 他人(共用)のコンピュータから自分の権限で利用する
  • 複数のアカウントのメールボックスをOWAから同時に開く

など、限られた環境の中ではありますが、結構ニーズとしてはあるように思えます。

複数のメールボックスを開くというのは、TIPSとして「IEのInPrivateで2つめのウィンドを開き、別のID/PASSで接続する」というのが有りますが、シングルサインオン環境だと両方とも同じアカウントで開いてしまいます。

以前検討した際は、いちいちその都度ゾーンの設定をいじってやりくりする物でしたが、もう少しスマートなやり方を考えてみましたので紹介します。

準備する点は2点。通常通りADFSサーバのアドレスを「イントラネット」サイトに入れますが、ここをhttps://付きで指定すること。もう1点は前の記事で紹介したとおり、httpでもADFSに接続出来るようにすることです。

まずは通常通り一つ目のアカウントを開いてOWAに接続し、そのままInPrivateブラウズでもう一つのウィンドゥを開きます。

 

ここで、2番目に開いた方のウィンドゥで、Exchange OnlineにAD FSを利用して気合いでOWAリダイレクトするで紹介したurlをhttp://に変更したアドレスに接続を試みます。

http://sts.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26wreply%3Dhttps:%252F%252Foutlook.com%252Fowa%252F%253Fexsvurl%253D1

すると、上手いことID/PASSの入力画面がポップアップしてくれますので、ここから開きたいユーザのアカウント情報を入力します。

これで、無事testuser oneさんと阿部 太郎さんの2つのOWAを開くことができました。

Exchange Onlineでのメール転送

Office365で利用されているExchange Onlineは、いくつかの方法で着信したメールを他のアドレスに転送をすることができます。

大きく分けて、転送を設定出来るポイントは4つ有ります。

  1. Forefront Online Protection for Exchangeのポリシールール
  2. Exchange Onlineのトランスポートルール
  3. Exchange Onlineのメール転送
  4. Exchange Onlineの受信トレイルール

今回は、これらの4つをいくつかのポイントに焦点を合わせて比較してみたいと思います。

①FOPE Policy ②Transport ③MailForward ④Inbox-Rule
設定可能な人 管理者 管理者(代理設定)
ユーザー
ジャーナルアーカイブ 対象外 対象
受信トレイに残さず転送 可能 不可
Envelope From書き換え 無し 有り
転送系ヘッダ付与 無し 有り(※1) 有り(※2) 有り(※3)
表示名への書き換え 無し 有り(※4)
受信トレイルールの影響 受けない 有り(※5)
※1: X-OriginatorOrg、X-MS-Exchange-Transport-Rules-Loop
※2: X-OriginatorOrg、X-MS-Exchange-Inbox-Rules-Loop
※3: X-OriginatorOrg、X-MS-Exchange-Inbox-Rules-Loop、Recent-From
※4: Exchangeが自動的に行う変更username@example.com⇒山田太郎<username@example.com>など
※5: ルールの順序により、転送より優先度が高いルールの方が先に処理される

以上のことから、通常は3をベースに条件に応じて使い分けるのが良いかと思われます。

  1. Exchangeに影響無しにメールを転送したい場合
  2. 管理者が保全などの目的で(特定条件を満たす)メールを転送する場合
  3. ユーザ自身が(また、管理者が代理で)携帯などに転送を設定する場合
  4. ユーザが特定の条件に合うメールのみ、条件付き転送を行う場合

設定方法といくつかの注意点をメモ書き程度に

①Forefront Online Protection for Exchangeのメニューから【ポリシールール】でBCCで配信ルールを作成する。

②Exchangeコントロールパネル(組織の管理)の【メールの制御】-【ルール】から新規作成を行う。

③Exchangeコントロールパネルを開き、【アカウント】-【接続されているアカウント】から【電子メールの転送先】を設定する

④Exchangeコントロールパネルを開き、【電子メールの整理】-【受信トレイのルール】でリダイレクトのルールを作成する

  • プランEではなく、プランPの場合はFOPEの管理メニューにアクセス出来ないので①の方式は利用不可
  • Exchange Onlineのみでメール監査を行う場合、①~③でメールボックスに配送せず転送した場合は、対象外となる
  • ①②の「リダイレクト」は④のリダイレクトとは意味が異なり、メールボックスには配送されない。④のリダイレクトを行う場合は「Bccで送信」を利用する。

OWAにシングルサインオンする(その2)

以前 Exchange OnlineにAD FSを利用して気合いでOWAリダイレクトする の記事でOWAへのシングルサインオンを紹介しましたが、より簡単な方法を見つけましたので紹介します。

やり方は簡単で、ブラウザを立ち上げて https://outlook.com/owa/[ドメイン名] にアクセスするだけです。
または、https://www.outlook.com/[ドメイン名] でも良いらしいです。

ADFSサーバのアドレスがイントラネットサイトに入っていないといけないという条件などは他のシングルサインオンと変わりませんが、これにより自動的にそのドメインがフェデレーションドメインとして構成されていれば、ADFSにリダイレクトされて認証され、最終的にOWAの画面が開きます。

と、これだけだと少しつまらないので、ついでにFidder2で通信のシーケンスを追ってみましょう。

Fiddler2 を使用して Office 365 Id フェデレーション ログオン処理をトレースする方法を参考にしつつ、Fidder2をインストールし、セットアップします。HTTPSの中身を見る場合、ADFSサーバ側のIISの設定変更(拡張保護を使用しないようにする)が必要です。

Fidder2を立ち上げ、Decrypt HTTPS trafficにチェックを入れてアクセスを試行してみます。

outlook.com ⇒ login.microsoftonline.com ⇒ [AD FSサーバ] ⇒ login.microsoftonline.com ⇒ outlook.com ⇒ pod51xxx.outlook.com ⇒sinprdxxxx(or hknprdxxxx).outlook.comの流れてリダイレクトされ、無事シングルサインオン出来ていることが確認できました。

もちろん、ログイン後にホームを押すとOffice365のポータルにも行けますし、そこからチームサイト(SharePoint Online)にもSSOできます。

Exchange Onlineプラン2を(ちゃんと)活用する

Office365で利用できるExchange Onlineには、プラン1とプラン2が有ります。大きく言うと、メールボックス容量が無制限で監査アーカイブ機能に対応した物がプラン2という括りになります。

プラン1とプラン2は、定価ベースで倍値段が違く、一般的な利用であればプラン1のメールボック容量の制限25GBを越えるというのは難しい為、プラン1で良いように思えますが、

「30日以上の期間を遡ってメールボックスの監査を運用上(もしくは法令上)実施する必要のある」ユーザーにとっては、プラン2を契約するのが一番の(というか唯一の)選択肢になります。もう少しクラウドサービスが出そろえば、プラン1+クラウドのジャーナルアーカイブなども考えられますが。

というのも、Office365で謳っている「アーカイブ機能」というのは、一般的に言う「ジャーナルアーカイブ」ではなく「個人のメールボックスアーカイブ」になります。つまり、ユーザは自由にメールボックス上にある過去のメールを削除したり変更したりでき、かつ削除したアイテムは14日後にクラウド上から消え去ります。通常メールの監査を行う場合は、短くて半年なり長い場合は3年、5年間にわたり全社員の送受信したメールの記録を取る必要がございますので、ここの保全の機能でプラン2が必要になる訳です。

「高い金出してうちはプラン2を契約しているから監査対応はバッチリです。」

いえいえ、単に契約しただけでは、実際にはプラン1と変わらない状態でデプロイされてますので、プラン2向けの設定をちゃんと入れてあげる必要があります。(デフォルトのポリシー変えてくれれば良いのに…)

とりあえず、やる必要のある工程は、デフォルトの設定を考えると通常の企業だと

  1. 訴訟ホールドもしくは期間限定訴訟ホールドの有効化
  2. アーカイブメールボックスの有効化
  3. メールボックス監査ログの有効化
  4. メールボックス監査ログの有効期限の設定(任意)
  5. 必要なプロトコル以外の無効化(任意)

あたりでしょうか? このうち1番と2番のみ(2番が容量無制限)はプラン2の機能、3~5はプラン1でもできる物です。また、1番で期間限定訴訟ホールドを実装するには、SRベースで対応をして貰う必要があります。SRだと時間が掛かるのと、ユーザの追加の度に実施するのは少し面倒なので、今回は訴訟ホールドのONでPowerShellで実装します。(1,2はECPからGUIでも実施できます)

$TarMBX = Get-Mailbox -identity user1
$Name = $TarMBX.DisplayName
Enable-Mailbox -identity user1 -Archive
Set-Mailbox -identity user1 -LitigationHoldEnabled $true -AuditEnabled $true -AuditLogAgeLimit 183.00:00:00 -ArchiveName "アーカイブ メールボックス - $Name"
Set-CASMailbox -identity user1 -ActiveSyncEnabled $false -ImapEnabled $false -PopEnabled $false -EwsEnabled $false

実施するコマンドは3つで、それぞれ以下のような感じでやってるサンプルです。

  • Enable-Mailbox…②アーカイブメールボックスの作成
  • Set-Mailbox…①訴訟ホールド有効化、③メールボックス監査ログ有効化、④メールボックス監査ログ期間半年に設定、②アーカイブメールボックス名変更(GUIのデフォルト値に)
  • Set-CASMailbox…⑤MAPI(Outlook)とOWA以外での接続のプロトコルの無効化

とりあえずこの状態にしておけば、あれば何か有っても大丈夫な気がします。強いて言うなら以下の辺を注意でしょうか

  1. ユーザーを削除すると過去のメールボックスごと30日後にクラウド上から情報が消え去る
    ※必要な期間消さないで下さい。もしくは.PSTにダウンロードしてから消して下さい
  2. 管理者監査ログの保持期限が90日なので、それより前の特権利用アクセスの有無の調査ができない
     ※Set-AdminAuditLogConfigコマンドで設定変更できるとマニュアルには記載がありますが、実装されていません

Office365の接続確認ツール(RCA)

Exchange Remote Connectivity Analyzer(ExRCA)の名前で提供されていたExchangeの接続確認ツールが、バージョンアップしてOffice365に対応しました。

機能追加になったのは、【Microsoft Single Sign-On(BETA)】になります。これによりAD FS環境での外部からの接続確認(要AD FS Proxyです)が実施できます。

IDとパスワードの他、了解事項のチェックボックスと認証用の文字列を入力します。認証文字は大文字小文字は区別しませんが、間違えるとパスワード欄がクリアされてしまって再入力になりますので、UだかVだか分からないとか微妙な文字列だった場合は認証コードの上側のボタンを押して文字列を再生成しましょう。

ちなみに、前に紹介したCOMODOのフリー証明書は、Windows Updateしていないコンピュータだと、ルートCAが信頼済みの証明書ルートに含まれないと警告が表示されますが、動作に問題はありません。

他にも、ActiveSyncやOutlookなどは、クラウドIDでも、AD FS Proxy経由となるフェデレーションIDでも接続確認が可能です。また、受信SMTP電子メールでは実際にメールの送信の試行を行い、MXレコードが正しく構成されているか、メールサーバへのメールの受信ドメインとして受け入れられるかを試験できます。ただし、以下は注意する必要があります。

  • テストの送信元となるIPアドレスは逆引きができないアドレスで、弾かれる可能性があります(65.55.150.160など)
  • MXレコードの応答がCNAMEレコード(Exchangeをはじめ、配送できないMTAが多い)でも試験が成功する

監査環境下でのExchange Onlineの退職者の処理

Exchangeのプラン2では、長期間に渡るメールの監査・アーカイブへの対応を実施することが可能となっております。これは、「各ユーザのメールボックスの無制限のアーカイブ+削除/変更したアイテムの保全+監査ログ」という要素によって構成されており、情報の分散管理(各ユーザーのメールボックス)とその横断検索がキーとなっています。

ここで1点問題になってくるのが、退職者に関する処理です。ディレクトリ同期下において、退職したからと言ってローカルのAD上でアカウントを削除してしまうと、削除した情報がそのままクラウド側に同期され、ユーザが削除され、メールボックスが一定期間(30日)後にサーバ上から削除されます。

こうしてしまうと、退職前に何か仕掛けてから辞めていった人に対しての、さかのぼっての監査が実施できなくなってしまいます。とはいえ、永久的にメールボックスを残すということは、辞めた人の分も合わせてID単位の課金を続けなくてはいけなくなり、どんどん必要なサブスクリプションを追加していかなくてはならず、非現実的です。

退職者の情報は、ネットワーク管理者が必要な分のみ.PSTファイルに落として一定期間ローカル保存しておくという運用が一般的ですが、横断検索が出来なく無くなるなどの不便が生じますので、一定期間Office365にアカウントを残すという運用を考えます。

  1. 当該ユーザーのログオンを不可にする
  2. 当該ユーザーへのメールの配送を止める
  3. 配布グループから抜いたり、グローバルアドレス一覧の非表示化などの後処理

などが考えられますが、1.に関してはローカルのADでアカウントを無効化すれば、Office365へのアクセスも不可になります。(サブスクリプションは解放されないですし、普通にメールも配送され続けますが)

2.はExchange Online側のアクセス権で普段はメールを送ることが無い管理用アカウントなどだけからのメールを受け取るようにSet-Mailboxコマンドレットで-AcceptMessagesOnlyFromを指定しておくのが楽だと思います。PowerShellからの設定になりますので、Exchange Onlineに接続してから実行します。

3.については、Office365のExchange Onlineサービス説明によりますと、

管理者は、社内の Active Directory でオブジェクトに HideInAddressList 属性を設定して (ディレクトリ同期ツールを使用している場合)、またはリモートPowerShell を使用して、ユーザー、配布グループ、および連絡先をグローバル アドレス一覧で非表示にすることができます。

とあるので、2.でSet-Mailboxコマンドを実行するついでに実施してしまおうと思います。

おろ、ディレクトリ同期環境下ではローカルのみですか…困りましたねぇ。そう、勘の良い人ならお気づきだと思いますが、GALの表示を制御するmsExchHideFromAddressLists属性は、Exchangeをインストールする際のスキーマ拡張で実装される物で、オンプレミスでExchangeがないユーザの環境では設定自体ができません。もちろん、マニュアルに誤記されているHideInAddressListなんてのも有りません。

さて、考えられるのは2つ。ディレクトリ同期(ILM)をいじって、どこか使ってない属性からマッピングしてくるか、スキーマを拡張するかです。ホントは前者で行きたいですが、このmsExchHideFromAddressLists属性はBoolean(TRUEかFALSEを保持する)形式なので、対応した良さそうな物が見つかりませんでした。ということで、不本意ながらExchange2010SP1の評価版をサイトからダウンロードして、中身は使わずセットアップの準備コマンドだけを利用します。

今回はスキーマ拡張だけを行いますので、setup.com /PrepareSchemaを実行します。

完了すると、無事msExchHideFromAddressLists属性が設定できるようになります。Set-ADUserコマンドの場合、拡張属性なので以下のような感じでしょうか

Set-ADUser -replace @{msExchHideFromAddressLists=$True}



う~ん、高々アカウント削除だけの話なんですが、面倒ですね。

ジャーナルアーカイブがOffice365の中で使えればこんなこと考えなくても良いのでしょうけど。(今は他のEnterpriseVaultとかのアーカイブに飛ばして格納しないといけないので、NW帯域考えると現実的では無いですよねぇ…)

Exchange OnlineにAD FSを利用して気合いでOWAリダイレクトする

リクエストを頂いたので、Office365ポータルではなくExchange Online(OWA)もやってみます。

OWAのリダイレクトを設定すると、Office365に移行済みのユーザがオンプレミスのOWAにアクセスした際に、Office365側にリダイレクトをかけることができます。ただ、普通にhttps://outlook.com/owa/example.comなどにリダイレクトをかけても、

って感じで悲しくもサインイン画面に飛んでしまいます。

というわけで、前回同様サインインのURLを適当に解析してみて、一個一個省略可否を探って行きます。

2番煎じでつまらないですが、以下のURLでOWAにSSOできるようになります。

https://sts.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26wreply%3Dhttps:%252F%252Foutlook.com%252Fowa%252F%253Fexsvurl%253D1

これをSet-OrganizationRelationshipで設定してあげれば上手くリダイレクトされる環境が作れそうです。

Exchange OnlineをPowerShellで操作する2(社内にばらまいた不適切なメールを削除する)

前回に引き続き、GUIでは実施できなくてPowerShellでないと実行できないのに、少しリファレンスが少なく感じた機能を紹介します。

(Exchange Onlineサービス説明より)
また、管理者は、複数の組織の複数のメールボックスに送信された不適切な電子メール メッセージを検索して削除することができます。たとえば、機密の給与情報がすべての従業員に誤って電子メールで送信された場合、管理者はユーザーのメールボックスからその電子メールを削除できます。

個人的には良い機能ですが、役員には知られたくない機能ですね。「○○君、実はさっき間違えてこんなメールを社内に送ってしまったのだが…」とか(w

クライアントがOutlookを利用している場合は、すぐに送信済みボックスを開いて、取り消しメールを送れば済むことも有りますが、OWAを利用している場合や、そもそもそんなクライアントの機能を知っているような人はこんな事にはならないという話も。

という訳で、PowerShellを利用してこれに対応してみましょう。Search For and Delete Messages from Users’ Mailboxes あたりが参考になります。

まずは該当メールを特定します。該当メールを絞り込むため、なるべく多くの条件を聞き出します。「タイトル」「だいたいの送信日時」「送信者」「送信先(To)」「Cc」「添付ファイル名」などでしょうか。

ここでは、hoge@example.comさんが7/3の朝8:00くらいに社内ALLにばらまいた、タイトル「昨日は楽しかったよ」を削除することをしたいと思います。

前提として、この作業はユーザのメールボックスの中身を検索・操作する必要があるので、通常の管理者では持っていない特権を付与する必要があります(通常の管理者アカウントだとSearch-Mailboxコマンドレット自体が利用できません)。Mailbox Import ExportMailbox Searchの権限が必要になりますが、ビルトインの役割グループには適した物が無いので、ここでは新規に作成して、管理者のアカウントに割り当てます。

そして、権限を割り当てられたユーザでExchange OnlineにPowerShellで接続します。接続が完了したあと、まずは対象のメールのみを取り出すクエリを作ります。この辺を参照に、今回の条件を-SearchQueryの条件の中にカンマ区切りで記載します。そして、-LogOnlyオプションを付けて実行します。

注意なのですが、Sent条件で指定する日付は、MM/DD/YYYY形式のUTC時間(日本の場合は-9時間した値)ですので、今回は7月2日として検索します。

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery "subject:'昨日は楽しかったよ', Sent:07/02/2011" -TargetMailbox admin -TargetFolder SearchAndDelete -LogLevel Full -LogOnly

これにより、adminさんのSearchAndDeleteフォルダに、検索結果の詳細レポートが格納されます。こちらの情報(添付されているCSVファイル)などを元に、問題ないと判断したら、-DeleteContentオプションを付けて実行します。

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery "subject:'昨日は楽しかったよ', Sent:07/02/2011" -DeleteContent

間違えて他のメールを削除してしまった時の為や、後々の為?に削除するメールのコピーを念のため取っておく必要がある場合は、先ほどのコマンドに-TargetMailboxと-TargetFolderオプションを付けて実行します。

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery "subject:'昨日は楽しかったよ', Sent:07/02/2011" -TargetMailbox admin -TargetFolder SearchAndDelete -DeleteContent

こうすると、検索されたメールは削除されて、メールのコピーが先ほどレポートが格納されていたフォルダ配下に、ユーザ名-実行日時(UTC)-メールボックス名-フォルダ名の階層構造として格納されます。

ちなみに、上で実施した管理アカウントへの特権割り当てやそれを利用したメールボックス操作などは、当然ながら全て監査ログに記録されておりますので、後で何か有ったときの防衛のため、依頼主からの正当な申請に基づいて実施した旨、しっかりとエビデンスは残しておくことをお勧めします。

Exchange OnlineをPowerShellで操作する(共有メールボックス)

Office 365のExchange Onlineは、Exchange 2010同様PowerShellで各種操作が可能です。Exchange管理コンソール(EMC)が提供されていない分、細かい操作をしようとするとPowerShellでの操作が必須となります。

Exchange Onlineサービスの詳細などにも、「リモートPowerShellを利用して、~が可能です」という記載を多く見かけます。コマンド例などが記載していない物も多いので、いくつか紹介したいと思います。

  1. 複数人から利用できるメールボックス(共有メールボックス)を作成する
  2. Fromで通常利用するメールアドレスを変更する
  3. 他のFromアドレスでメールを送る(=送信者アクセス権(SendAs)をユーザに与える)

まず、共有メールボックスはNew-Mailboxコマンドに-Sharedオプションを付けて作成します。共有メールボックスはサブスクリプションは必要ないのですが、(ログオン不可の)ユーザオブジェクトは作成されますので、AD FS環境で作成する場合は、フェデレーションドメイン以外(xxx.onmicrosoft.comドメインなど)で作成する必要があります。

New-Mailbox -Name "共有メールボックス1" -Shared -Alias share1

次に、share1@xxx.onmicrosoft.comのアカウントのFromで利用するアドレスとして、独自ドメインのshare1@example.comを利用するように設定します。Set-Mailboxコマンドの-EmailAddressesオプションに受信するアドレス一覧を指定します(メインで利用する物のみSMTP:で、他はsmtp:で記載します)。

$NewEmailAddresses = @()
$NewEmailAddresses += ("SMTP:share1@example.com")
$Temp = Get-Mailbox -Identity "共有メールボックス1"
$NewEmailAddresses += ($Temp.EmailAddresses -replace "^SMTP" , "smtp")
Set-Mailbox -Identity "共有メールボックス1" -EmailAddresses $NewEmailAddresses

次に、この共有メールボックスへのアクセス権を設定します。その共有メールボックスを開くために必要なFullAccess権はAdd-MailboxPermission権で、その共有メールボックスのアドレスでメールを送信できる権限をAdd-RecipientPermission(※Office365の場合はAdd-ADPermission -Extendedrightsでは有りません)コマンドで付与します。

New-DistributionGroup -Name "共有メールボックス1グループ" -Alias share1g -CopyOwnerToMember -ManagedBy "testuserone" -Type Security
Set-DistributionGroup share1g -HiddenFromAddressListsEnabled $true
Add-MailboxPermission -Identity "共有メールボックス1" -User share1g -AccessRights FullAccess
Add-RecipientPermission -Identity "共有メールボックス1" -Trustee share1g -AccessRights SendAs -Confirm:$False

これで準備は完了です…が、結構このコマンドを実行した後、クラウド内のActive Directoryに権限情報が行き渡るのに時間が掛かります。(手元の環境だと1時間掛かりました。)

作成した共有メールボックスの開き方ですが、Outlookの場合はアカウント設定の[電子メール][変更][詳細設定]から詳細設定タブの[メールボックス][追加]から作成した共有メールボックスを指定すると、自分のアカウントの下に追加されます。共有メールボックス宛に来たメールに返信すると、自動的にFromアドレスも共有メールボックスになります。

つぎに、OWAの場合ですが、まずアカウントごと開く場合は右上の自分のアカウント名のプルダウンメニューから[他のメールボックスを開く]で共有メールボックスを指定する方法があります。

この場合、その共有メールボックスのアカウントとしてそのまま操作できます。メールを作成する場合は自動的に共有メールボックスがFromアドレスとして設定されます。

また、メールボックスのカウント名を右クリックし、[他のユーザーの受信トレイを開く]から共有メールボックスを指定すると、自分のメールボックスと並べて共有メールボックスを開くことができます。ただし、Fromアドレスを共有メールボックスのアドレスでメールを作成する場合、Fromアドレスを毎回手動で指定してから送信する必要があります。

開く必要のあるフォルダの数や、用途(参照のみか実際に操作もするか)などに合わせて使い分けると良いと思います。