Exchange Server

Exchange Onlineでの自動メール転送に関してとてもよいまとまった記事がありましたので備忘録として。 Exchange Online でのメールの自動転送について知っておくべきこと | Japan Exchange & Outlook Support Blog (jpmessaging.github.io) 「自動転送を行いたい」というニーズは様々な場面で発生しますが、適切に設定しないと情報漏洩の元になりますので、注意が必要ですね。

Exchangeのメールボックスは昔は「一番最初にアクセスしたクライアントやプログラム等の言語」によって言語が決定される…という動きだったと思うのですが、Exchange Onlineになって、どうやらユーザーの言語設定に応じてメールボックスのフォルダ名の言語が変化する仕様になった模様ですね。 とりあえず全部日本語にしちゃいたければ下記のようにしてしまえば良いです。実行環境はAzure CloudShellで大丈夫です。

また、大変長い時間が前回のエントリから空きました…。 でも、私最近Exchange Online結構さわってますよ！ その証拠にスクリプト書きました。(共有)メールボックスにフルアクセス権を付与するスクリプトです。ネストされたグループに含まれているユーザーを直接付与する形にしています。これによってメールボックスの自動接続もおこなわせてしまおうという作戦です。 https://twitter.com/ebi/status/1179368184643821573 https://twitter.com/ebi/status/1179368413803757568 https://twitter.com/ebi/status/1179402934213316609 スクリプトは下記。

皆さんこんにちは。胡田です。相当久しぶりにブログを書いています。 このExchange Serverブログに関しては前回更新が2014年4月8日とのことなので、3年以上更新しておらず…。月日の流れというのは恐ろしいものですね。 Exchange Serverに関しては一時期非常にDeepに取り組んだので過去、私の一番の得意分野でしたが気がつけばもう10年くらいはまともに触っていない状況な気がします。環境もオンプレミスでExchange Serverを構築するのが当たり前…というかそれしか選択肢が現実的になかった時代もありましたが、今ではExchange Onlineが相当普及してきた印象です。本質的に重要ではない部分に時間を取られなくなって良くなった面が非常に大きいように感じています。サーバーのサイジング、拡張可能なアーキテクチャ設計、Notes環境の接続等当時私が相当ノウハウをためた部分がほぼ意味がなくなっている面もありますが、製品、アーキテクチャとしてはかなり成熟しており、今でも質問をうけてもぱっとあたりをつけられるのはありがたいなと思います。 閑話休題。 今回はExchange Online(に限った話ではないのですが)にて、外部にメールを送信する際に、自分のメールアドレスではないアドレスで外部に送信する方法に関してです。 下記の状況を考えます。 ``ユーザーが1人います。操作の主体です。masahiko@ebisuda.onmicrosoft.com `` ``グループが1つあります。今回このグループのアドレスからメールが送信されたように見せたいわけです。test@ebisuda.onmicrosoft.com `` ``※今回、「配布グループ」でテストしたかったのですが、配布グループを作成しようとしても強制的にOffice 365グループになってしまいました。挙動は全く同じだと思いますので、このまま進めます。 ``以下はOWAでメールを作成している所です。 ``[](https://exchange.ebisuda.net/wp-content/uploads/2017/06/image-2.png) ``以下は該当メールをgmailで受信した所です。 ``[](https://exchange.ebisuda.net/wp-content/uploads/2017/06/image-3.png) ``迷惑メールになってしまいましたが(笑 さて、この状態で、masahiko@ebisuda.onmicrosoft.comがtest@ebisuda.onmicrosoft.comからのメールを出そうとするとどうなるでしょうか。 ``操作としては「差出人」を設定することで行なえる… ``[](https://exchange.ebisuda.net/wp-content/uploads/2017/06/image-4.png) ``のですが、差出人には自分しか表示されず、切り替えることができません。 ``[](https://exchange.ebisuda.net/wp-content/uploads/2017/06/image-5.png) `` ``` ``` `` ``` 非常にわかりづらいのですが、実はこの部分は編集、削除することができます。右クリックするとメニューが表示されます。 ``` `` ``` ですが、私の環境では「編集」は動作しませんでした。一度「削除」してからアドレスを選択しました。 ``` ``ですが、送信するとすぐにエラーとなります。 ``[](https://exchange.ebisuda.net/wp-content/uploads/2017/06/image-7.png) ``というわけで、「差出人として送信する」という権限が必要な事がわかります。 ``権限といえばPermission。Exchange Onlineの管理といえばPowerShell…ということで、Exchangeの管理用コマンドレットからPermissionという単語を含むものを検索します。 PowerShellでのExchange Onlineへの接続が必要なので以下の記事も参考に…。 - [Exchange Online PowerShell への接続](https://technet.microsoft.com/ja-jp/library/jj984289(v=exchg.160).aspx) 以下のスクリプトを実行します。 > #Exchange Onlineへの接続$UserCredential = Get-Credential$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri [https://outlook.office365.com/powershell-liveid/](https://outlook.office365.com/powershell-liveid/) -Credential $UserCredential -Authentication Basic -AllowRedirectionImport-PSSession $Session > > #Permissionという単語を含むコマンドレットの検索Get-Command *Permission* 実行結果は以下です。 > PS C:\Users\mebisuda> Get-Command *Permission* > > CommandType Name Version S o u r c e----------- ---- ------- -Alias Get-AdlStoreItemPermission 3.0.0 AAlias Set-AdlStoreItemPermission 3.0.0 AFunction Add-MailboxFolderPermission 1.0 tFunction Add-MailboxPermission 1.0 tFunction Add-PublicFolderClientPermission 1.0 tFunction Add-RecipientPermission 1.0 tFunction Get-MailboxFolderPermission 1.0 tFunction Get-MailboxPermission 1.0 tFunction Get-PublicFolderClientPermission 1.0 tFunction Get-RecipientPermission 1.0 tFunction Remove-MailboxFolderPermission 1.0 tFunction Remove-MailboxPermission 1.0 tFunction Remove-PublicFolderClientPermission 1.0 tFunction Remove-RecipientPermission 1.0 tFunction Set-MailboxFolderPermission 1.0 tCmdlet Get-AzureRmDataLakeStoreItemPermission 3.0.0 ACmdlet Set-AzureRmDataLakeStoreItemPermission 3.0.0 A > > Add-RecipientPermissionというコマンドレットがありますね。 Get-Helpコマンドでヘルプを見てみます。 > PS C:\Users\mebisuda> Get-Help Add-RecipientPermission > > 名前 Add-RecipientPermission 概要 This cmdlet is available only in the cloud-based service. Use the Add-RecipientPermission cmdlet to add SendAs permission to users in a cloud-based organization. For information about the parameter sets in the Syntax section below, see Exchange cmdlet syntax. 構文 Add-RecipientPermission -Identity <RecipientIdParameter> -AccessRights <MultiValuedProperty> -Trustee <SecurityPrincipalIdParameter> [-Confirm <SwitchPa rameter>] [-WhatIf <SwitchParameter>] [<CommonParameters>] 説明 When a user is assigned SendAs permission to a user or group, the user can send messages that appear to come from the other user or group. You need to be assigned permissions before you can run this cmdlet. Although all parameters for this cmdlet are listed in this topic, you may not have a ccess to some parameters if they're not included in the permissions assigned to you. To see what permissions you need, see the "Recipient provisioning p ermissions" section in the Recipients Permissions topic. > > 関連するリンク Online Version [http://technet.microsoft.com/EN-US/library/0740023b-47df-4f36-bcb9-ce3b0707a6d4(EXCHG.160).aspx](http://technet.microsoft.com/EN-US/library/0740023b-47df-4f36-bcb9-ce3b0707a6d4(EXCHG.160).aspx) > > 注釈 例を参照するには、次のように入力してください: "get-help Add-RecipientPermission -examples". 詳細を参照するには、次のように入力してください: "get-help Add-RecipientPermission -detailed". 技術情報を参照するには、次のように入力してください: "get-help Add-RecipientPermission -full". オンライン ヘルプを参照するには、次のように入力してください: "get-help Add-RecipientPermission -online" ビンゴ！ですね。 - [Add-RecipientPermission](https://technet.microsoft.com/ja-jp/library/ff935839(v=exchg.160).aspx) 結局以下のコマンドで権限の付与が行なえます。 > PS C:\Users\mebisuda> Add-RecipientPermission -Identity test@ebisuda.onmicrosoft.com -AccessRights SendAs -Trustee masahiko@ebisuda.onmicrosoft.com > > Identity Trustee AccessControlType AccessRights Inherited-------- ------- ----------------- ------------ ---------test_84c6f4d24d masahiko Allow {SendAs} False AccessRightsとして「SendAs」が付与された状態です。これで「差出人」になれるわけですね。 コマンド実行後はそれが反映されるまでしばらく時間がかかります。2時間程度は反映に時間がかかると思っておいてもらうと良いと思います。 [](https://exchange.ebisuda.net/wp-content/uploads/2017/06/image-8.png) 「差出人」を書き換えて、メールを送信します。初回は必ず差出人を手動で書き換える必要があるようです。 [](https://exchange.ebisuda.net/wp-content/uploads/2017/06/image-9.png) 意図したとおり、[test@ebisuda.onmicrosoft.com](mailto:test@ebisuda.onmicrosoft.com)を差出人のアドレスとしてメールを送信することができました。 一度送信に成功すると、次回からはドロップダウンから選択できるようになります。 [](https://exchange.ebisuda.net/wp-content/uploads/2017/06/image-10.png) これで、目的を達成することができました。

ExchangeチームブログにてオンプレミスからExchange Onlineへのメールボックス移行パフォーマンスの分析スクリプトが紹介されています。そして非常に便利に使えそうです。 - [Mailbox Migration Performance Analysis - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2014/03/24/mailbox-migration-performance-analysis.aspx) オンプレミス同士であってもメールボックス移行には様々なトラブルがつきものです。その中でも「パフォーマンスが出ない」というトラブルが非常に多く、頻繁に発生します。Exchange Online(O365)へのメールボックス移行となるとインターネット回線を経由することになるので時間も長くかかりますし、パフォーマンスは非常にクリティカルな問題になります。このようなツールも使いつつ、しっかりとメールボックス移行をしていく必要があります。 遅い！という時には結局再起動すると早くなった…なんていう事が一番多いんですけどね…(＾＾；

規定の設定ではExchange 2007と2013の共存環境で、Exchange 2013側から2007側の空き時間情報が参照できないそうです。これは空き時間情報の公開期間の違い(2013は62日、2007は42日)に起因するらしくExchange 2007 CAS側でweb.configを書き換えて対処が可能とのことです。 - [Lets Exchange: Free/Busy Information Period (Exchange 2013-2007 Error)](http://letsexchange.blogspot.jp/2014/02/freebusy-information-period-exchange.html) バージョンをまたいでの移行は色々と注意点がありますね。

すっかりSystem Centerどっぷりになってしまったので、こちらのブログの更新が滞っております。そんな中でも色々なブログの情報等はチェックしています。 やはり英語圏の情報が多い中、ExchangeブログJAPANでAutodiscoverに関するとても良い記事が2つありましたので紹介です。 - [Autodiscoverを振り返るエピソード1 - Exchange ブログ JAPAN - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchangeteamjp/archive/2014/03/03/3624093.aspx) - [Autodiscoverを振り返るエピソード2 - Exchange ブログ JAPAN - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchangeteamjp/archive/2014/03/18/3625368.aspx) Exhcangeチームの英語ブログが日本語翻訳されなくなってしまった今、日本語のこういう記事は貴重ですね。英語の技術文章を読むのはさほど苦ではないのですが、それでもやっぱり日本人の書いた日本語の文章だとわかりやすいです。

Exchange Server 2010のDAGのトランザクションログがDPM 2012でバックアップを実施しても消えない…という話を受けて、調査してみました。 調べた所以下のブログに非常に良い情報がありました。 - [Exchange 2010: Log Truncation and Checkpoint At Log Creation in a Database Availability Group - Tim McMichael - Site Home - TechNet Blogs](http://blogs.technet.com/b/timmcmic/archive/2012/03/12/exchange-2010-log-truncation-and-checkpoint-at-log-creation-in-a-database-availability-group.aspx) Exchange Server 2010 SP1以降挙動が変わっており、要点は以下とのことです。 - ログファイルを消しているのはバックアップソフトウェアではなくて、ExchangeのReplicationサービス - トランザクションログが作成されたタイミングのチェックポイントがログファイルに埋め込まれている - DAGのコピーノード毎にどこまでログの切り詰めをしていいか報告される - 一番わかい番号までログのきりつめを行えると判断されるが、実際には”checkpoint depth”の分だけは消さずに残しておく - 切り詰めされるのはきちんと増分バックアップされているファイルのみ - “Checkpoint at log creation time”はeseutil /ml <ログファイル名>”で確認できる 要は、きちんとバックアップが成功していても、チェックポイントとして100程度、実際のファイル数としてはそれ以上のログファイルが残っているのが正常だ、ということです。 今回の検証環境では200ファイル程度ログファイルが残っており、確かに最新のログと最古のログとでチェックポイントとして100の違いがありました。

Exchange Server 2013になり、TCPコネクション数をOutlookがより沢山使うようになっています。 これはOutlookプロファイル上でサーバー名部分がユーザーメールボックスのGUIDとなり、特定サーバーを指すものではなくなったため、同一サーバー上であっても過去バージョンにおける別サーバーであるかのようにTCPセッションを使うようになったからだそうです。Outlook Anywhereを常に使うようになったため、HTTPS通信が多数発生します。 特に他人の予定表を参照するような動作の時に個別のTCPセッションとなるため、1クライアントから数十のTCPセッションが発生し、かなりの数のコネクションが保持されるようなことが容易に起こります。 オンプレミスでは問題にならないケースも多いですが、特にExchange Onlineの場合にはProxy経由で外部に出て行くことが多いためアクセスがそこに集中し、TCPコネクション数の論理的な限界に達することや、そこまで行かなくてもProxy上の制限に合致し、まともにOutlookが使えない、Webが閲覧できない等の障害が発生することが多いようです。 オンプレミスであればきちんとシステムの変更に関してきちんと計画、テストがなされるのが普通だと思いますが、Exchange Onlineの場合には勝手にアップグレードされてしまい、障害が起きたから切り戻す…ということも行えないため場合によっては致命的な状況に陥る可能性があります。対処法がProxyサーバーを増やす、グローバルIPを増やす…というようなものになってしまう場合、対処するまでの時間も非常に長くなってしまいます。みなさんも気をつけて下さい。

最近は知識はあっても実際に自分で手を動かすことはめっきり少なくなってしまったのですが、やっとExchange Server 2013の環境を構築してみました。特につまるところもなく構成出来たのですが、ECPで操作をしているとすぐにIEがクラッシュしてしまうという現象に見まわれました。環境は以下のとおりです。 - Windows Server 2013 - Exchange Server 2013 CU2 - Internet Explorer 10 おそらくこの組み合わせでは、何をしようとしてもすぐにクラッシュすると思います。 「Internet Explorer は動作を停止しました」と無慈悲なメッセージが…。 回避策を探したところ、以下のIEの累積パッチを適用することで現象が改善されることを確認しました。 - [http://download.microsoft.com/download/F/B/2/FB217F16-026B-499F-8F44-7D7ECFAA3B53/Windows8-RT-KB2761465-x64.msu](http://download.microsoft.com/download/F/B/2/FB217F16-026B-499F-8F44-7D7ECFAA3B53/Windows8-RT-KB2761465-x64.msu) - [[MS12-077] Internet Explorer 用の累積的なセキュリティ更新プログラム (2012 年 12 月 11 日)](http://support.microsoft.com/kb/2761465/ja) 具体的にどのhotfixがこの問題の修正なのかまでは確認していませんが、きちんと稼働するようになったので深くは追わないことにしました。

Exchange Team BlogにてExchangeのDAGのWitnessのみをWindows Azure上に配置するという話題が有りました。結論は「まだサポートされない」ということで残念ですが、将来的にサポートされるようになりそうな感じですね。 - [Database Availability Groups and Windows Azure - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/08/07/database-availability-groups-and-windows-azure.aspx) DAGにかぎらずですが、きちんとスプリットブレイン状態を防ぎ、稼働しているマシンで稼働させ続けるためにはどうしても3拠点が必要になります。本文中では以下のように書かれています。 You need two well-connected datacenters, in which Exchange is deployed You need a third location that is connected via the network to the other two datacenters The third location needs to be isolated from network failures that affect the other two datacenters 過半数が稼働し通信できていないといけないので、例えば2拠点でDAGを組もうと思っても、結局Witnessをどちらに置くか、という話になり、Witnessが配置された方の拠点がだめになればDAGとしては停止してしまうわけです。で3拠点目があればその問題は解決するのですが、ネットワーク的に完全に分離されていて、安定しているような拠点でできれば地理的にも離れている…というような都合の良い拠点をすぐに用意するのは難しいわけです。そこでAzure上に配置可能ならかなりメリットが出てくる…という話なのですが、まだ無理なようですね。 今後に期待したい所です。

TMGが新規に購入できなくなり、マイクロソフトソリューションで固めていた顧客が今後のリバースプロキシに何を使うべきなのか迷っている現状がありますが、どうやらMS的にはIISを一つの選択肢に持ってくるようです。 - [Part 1: Reverse Proxy for Exchange Server 2013 using IIS ARR - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/07/19/reverse-proxy-for-exchange-server-2013-using-iis-arr-part-1.aspx) IISのARR(Application Request Routing)でリバースプロキシができますよ、ということだそうです。 ドメインに参加させる必要も無いということですし、Windows Server 2008以降のOSがあれば構成できるようですから、あまりコストをかけたくない場合や検証用途であればこれで十分にいけそうに思います。

Released: Exchange Server 2013 RTM Cumulative Update 2 - Exchange Team Blog - Site Home - TechNet Blogs 早速スキーマ拡張も含まれています。3ヶ月毎ってやっぱりサイクル早いですね。

Exchange Team Blog日本語版の更新は2013年6月20日以降は行われない、というそっけない通知が出ていました。 - [http://blogs.technet.com/b/exchange_jp/archive/2013/06/07/3577368.aspx](http://blogs.technet.com/b/exchange_jp/archive/2013/06/07/3577368.aspx) すべてのことに当てはまりますが、翻訳するというのはかなり時間もコストもかかりますので、今後もますますこのような傾向は加速するものと思います。これまでもそうですが英語の重要性がますます高まっていきますね。

Exchange Server Teamブログにて予定表の直接予約設定が行われているメールボックスを見つけて無効化するスクリプトが公開されています。 - Use Exchange Web Services and PowerShell to Discover and Remove Direct Booking Settings - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/09/use-exchange-web-services-and-powershell-to-discover-and-remove-direct-booking-settings.aspx これはとても素晴らしいスクリプトですね。有効に活用したいところです。 ところで、このブログの中で以下の部分が個人的に注目の箇所でした。 While the Direct Booking method for resource scheduling can indeed work on Exchange Server 2007/2010/2013, we strongly recommend that you disable Direct Booking for resource mailboxes and use the Resource Booking Attendant instead. 直接予約を使わないことを「強く推奨」しているとは知りませんでした。理由には納得ですしそうすべきと私も重います。ですが、実際の案件の中ではわざわざOutlookのレジストリを変更してまでして直接予約を有効にするケースがあります。なぜそんなことをするのかというとExchange Server 2003から使い続けているユーザーが2007, 2010に移行したタイミングで会議室予約時の挙動が変わってしまうのを良しとしない顧客がいるからです。 何かを「変更」するということを極端に嫌い、リスクを避け、変化を嫌い、何かあった時の責任を取りたくない…という気持ちはわからないでもないのですが、何に関しても「より良く改善していく」ということはやはり行うべきだし、ましてや製品を作っている側が「そうしてくれ」といっているようなことには従うべきだと思います。そうでなければ結局無駄なトラブルを招いたり、製品のメリットをきちんと最大限引き出すことができませんので。 というわけで、予定表の予約方法に関してはサーバーサイドで全部コントロールするようにすべきですね。 ...

Exchange team blogにてEWS(Exchange Web Service)を使ってパーソナルタグをつけるという話題がありました。 - Using Exchange Web Services to Apply a Personal Tag to a Custom Folder - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/20/using-exchange-web-services-to-apply-a-personal-tag-to-a-custom-folder.aspx Exchange Server 2013に移行する際に管理フォルダーを使っている場合にそれをどうやって移行するか、という話題もありますがEWSを使った場合にそれが「サポートされるのか」ということに言及しています。 答えは「サポートされる」だそうです。もちろんEWSを利用するコードのロジックは含まれないですが、ドキュメントとして公開されているEWSのAPIはサポートされるということです。 EWSを叩くだけでも「開発！」となってしまい拒否反応を起こす人や、そもそもコードをかけない人なども多いですがExchange(に限らないですが)を管理していてコードが書けないのでは相当管理工数に違いが出てしまいますので使うべきところでは積極的に使っていくべきだと私は考えます。

Exchange Server 2013を監視するためのSystem Center Operations Manager用の管理パックが公開されています。 - Released: Exchange Server 2013 Management Pack - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/15/released-exchange-server-2013-management-pack.aspx - MP Blog: Exchange 2013 Management Pack released - System Center: Operations Manager Engineering Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/momteam/archive/2013/05/14/exchange-2013-management-pack-released.aspx ダウンロードはこちらから行えます。 - Download Microsoft Exchange Server 2013 Management Pack from Official Microsoft Download Center http://www.microsoft.com/en-us/download/details.aspx?id=39039 今回の管理パックは監視コンセプトが以前とは変更され「ユーザーに対してどのような影響があるのか」という視点がより強くなるそうです。 - Lessons from the Datacenter: Managed Availability - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2012/09/21/lessons-from-the-datacenter-managed-availability.aspx ...

以前からExchange guysの間では使うのが常識になっているExchangeのサイジングツールですが、そのExchange Server 2013版が出ています。しかもメールボックスサーバーに限定されていない、全ロール向けのものになっています。助かりますね。 - Released: Exchange 2013 Server Role Requirements Calculator - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/14/released-exchange-2013-server-role-requirements-calculator.aspx サイジングは適当に行ってしまうと後で困るわけですが、きちんとやろうと思ってもアーキテクチャを理解していないと出来ない難しいものです。 例えばメールボックスを格納するディスクのサイズを計算しようと思っても単純にユーザーが使う領域を人数分掛け算すれば良いわけではなく、削除済みアイテムの領域も必要だし、削除されたメールボックスが完全に消されるまでの領域も必要だし、検索のためのインデックスを格納する領域も必要だし、トランザクションログ領域も必要だし、バックアップに失敗してトランザクションログがクリアされない時のための余裕も必要だし、DAGのメンバが長期間停止した時の考慮も必要だし……と、言い出したらきりもなければ抜け漏れも出やすいわけです。それが開発チームからガイドラインが出て、必要なパラメータを入れると参考値を出してくれるわけですから使わない手はないですね。 最もこれがあればあとは何もいらないわけでは全くありませんけれどもね。 リンクはリンク集にも追加しておきました。

Exchange Onlineへの移行も進んでいるようですが、ハイブリッド構成などでExchange Onlineからオンプレミス方向へのメールボックス移行などの必要性も発生します。このあたりを調べる必要があったのでまとめて記録しておきます。 前提条件：まずきちんとハイブリッド構成にしておくこと まずはじめにきちんとハイブリッド構成にしておく必要があります。これには以下のExchange Server Deployment Assistant(ExDeploy)が便利です。 - Home - Exchange Deployment Assistant http://technet.microsoft.com/en-us/exdeploy2010/default(EXCHG.150).aspx 希望する構成と、いくつかの質問に答えるとなすべきことを教えてくれます。 メールボックス移動実施方法 メールボックスの移動方法に関しては以下のドキュメントが非常によくまとまっています。 - Exchange Hybrid Deployment – Moving Cloud-Based Mailboxes to the On-Premises Organization http://community.office365.com/en-us/wikis/exchange/566.aspx クラウドで作成されたアカウントとオンプレミスで作成された上でクラウドに移動したアカウントとでは違う手順になるので注意が必要です。 トラブル Exchange Onlineからオンプレミスへのメールボックス移行の際にいくつかの問題が発生するケースがあるようです。以下、検索してすぐにみつかったケースです。 - Error message when you try to use the New-MoveRequest cmdlet to move a mailbox from Exchange Online in Office 365 to the on-premises environment in a hybrid deployment: "Operation has timed out" http://support.microsoft.com/kb/2723127/en-us - Mailbox Move from cloud to on-premises issue: Relinquishing job because the mailbox is locked. The job will attempt to continue again after. What to do? - Email and calendar - Office 365 - Microsoft Office 365 Community http://community.office365.com/en-us/forums/158/t/84117.aspx ...

The Exchange Team Blogにて、サイズ制限によりEdge Transportサーバーでメールループが発生するという問題が紹介されています。 - Mysterious mail loop on Edge Transport server: Check your size limits! - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/03/28/mysterious-mail-loop-on-edge-transport-server-check-your-size-limits.aspx Edge Transportサーバーの外部からのメール受け入れサイズ制限は大きいのに、Hub Transport側の受け入れサイズ制限が小さいと - Edgeは受け入れる - Hubには送れないから外部宛のSend Connectorで送ろうとする - それは自分自身なのでループする という挙動になってしまうという話ですね。サイズ制限は一番外側が一番厳しいようにするか、全体で統一しないといけませんね。この件に限らずサイズ制限まわりはバージョン間での移行時ふくめ色々と変な動きをするので気をつけないといけませんね。 それは、それとして、コメント欄の反応がなかなかおもしろいですね。こんなブログ買いてないでBPAにチェックコードいれろよとか、Exchange Onlineじゃなくてオンプレミスの記事を書いてくれてありがとう(皮肉)とか。やっぱりオンプレミスでExchange管理をしている人はExchange Onlineがきになるでしょうし、MSがかなりExchange Onlineに傾倒していっているのが気になっているのでしょう。もちろん私もです。