Exchange Server 2013 パブリック フォルダーにアクセスができない

Exchange 2013 へパブリック フォルダーを移行後、パブリック フォルダーへのアクセスが非常に重くなるという現象が発生しました。

現象は大きく分けて 2 通りあり、

1. 比較的高スペックな PC では、パブリック フォルダーへのアクセスが非常に重くなっており、メール送受信などはできるもののパブリック フォルダーにはアクセスできない状態でした。

2. 低スペックな PC では、Outlook が起動直後からハングアップしてしまい、送受信も含めて Outlook の利用が全くできない状態でした。

調査したところ KB2839517 の問題であり、こちらは 2013 年 6 月にリリースされた KB2817371 の修正で解決できるところまで確認できました。
現象発生環境は 2013 年 7 月にリリースされた Office 2010 SP2 が適用済みでしたが、KB2817371 の修正は含まれていないようでした。
Microsoft Update で最新にすると問題が解決できることが確認できたので、修正プログラムを特定していったところ、KB2687567KB2817371 が含まれており、こちらで解決できることが確認できました。

TITLE : Outlook で Exchange Server 2013 のパブリック フォルダーまたは自動で割り当てられたメールボックスに接続できない
URL : http://support.microsoft.com/kb/2839517/ja

TITLE : Description of the Outlook 2010 hotfix package (Outlook-x-none.msp): June 11, 2013
URL : http://support.microsoft.com/kb/2817371/en

TITLE : Description of Office 2010 Service Pack 2
URL : http://support.microsoft.com/kb/2687455/en

TITLE : Description of the Outlook 2010 update 2687567: February 11, 2014
URL : http://support.microsoft.com/kb/2687567/en

Exchange 2013 を使用する際のシステム要件は、以下の通りですが、パブリック フォルダーを使用する場合は最新にしておく、と考えた方が良さそうです。
・Outlook 2013
・Outlook 2010 SP1 + 2012 年 11 月の更新プログラム
・Outlook 2007 SP3 + 2012 年 11 月の更新プログラム

TITLE : Exchange 2013 のシステム要件
URL : http://technet.microsoft.com/ja-jp/library/aa996719(v=exchg.150).aspx

 

Office 365 Exchange Online へのメールボックス移行でのオンプレミスのユーザーへの影響

Office 365 へのメールボックス移行の最終処理を行った際に、移行していないオンプレミス側のメールボックスの一部で、”Microsoft Exchange 管理者によって変更が行われました。Outlook を終了させてから再起動してください。” というダイアログ ボックスが表示されました。

■ ダイアログ画面例
管理者による変更_01a

さらに、ダイアログに [OK] をクリックして Outlook を再起動したところ、Autodiscover のリダイレクトの警告画面が表示されました。
こちらがのダイアログについては以下の KB に詳細がありますが、ひとまず今回は [この Web サイトについては今後このメッセージを表示しない] のチェックをオンにして [許可] をクリックしました。

TITLE : Outlook 2010 および Outlook 2013 で警告自動検出リダイレクトを抑制する方法
URL : http://support.microsoft.com/kb/2480582/ja

TITLE : Unexpected Autodiscover behavior when you have registry settings under the \Autodiscover key
URL : http://support.microsoft.com/kb/2212902

■ ダイアログ画面例_2
管理者による変更_02a

上記までで、オンプレミスのメールボックスでも特に問題なく利用することができるようになりましたが、そもそも何故、最終処理を行ったメールボックス以外のオンプレミス側のメールボックスについても Outlook の再起動が必要であったのかを明らかにする必要がありました。

この点についていろいろ切り分けた結果、共有の予定表として以降の最終処理をを行ったメールボックスを追加している場合に発生していることが確認できました。
おそらくは、予定表参照で該当メールボックスが Office 365 側へ移動していることを検知した Outlook では、この変更を有効にするために再起動が必要であり、再起動後の Office 365 へのアクセス時に Autodiscover のリダイレクトが発生する、という事なんだと思います。

小さなことではありますが、ユーザー影響のあることなので、やはり最終処理はユーザー様の業務時間帯を避けて行う必要がありそうです。

Office 365 Exchange Online からオンプレミス ユーザーの空き時間や予定表が見えない

Office 365 Exchange Online と Exchange 2010 とのハイブリッド環境で、O365 側からオンプレミス ユーザーの空き時間や予定表が見えないという問題が発生しました。
情報探ると、非常に多岐にわたり原因が考えられるようで、Microsoft の KB も多数あり、同様の問題にあたっている人が多くいることがわかりました。
以下の KB 等を参考にしながらトラブルシュートしていきましたが、なかなか解決できずにいました。

TITLE : オンプレミス Exchange Server と Office 365 Exchange Online のハイブリッド展開で発生する空き時間情報 (Free/Busy) に関する問題のトラブルシューティング方法
URL : http://support.microsoft.com/kb/2555008/ja

TITLE : Office 365 環境において、Office Outlook 2007 および Outlook 2010 において他のクライアントの空き時間情報の表示ができない場合のトラブルシューティング方法
URL : http://support.microsoft.com/kb/2581088/ja

TITLE : オンプレミス Exchange Server と Office 365 Exchange Online でハイブリット展開されたリモート ユーザーの空き時間情報を表示することができない
URL : http://support.microsoft.com/kb/2667844/ja

TITLE : Users from a federated organization cannot see the free/busy information of the local Exchange Server 2010 organization
URL : http://support.microsoft.com/kb/2752387/en

TITLE : Office 365 Exchange Online とオンプレミス Exchange Server のハイブリッド展開でクロスプレミスの予定表を編集できない
URL : http://support.microsoft.com/kb/2807149/ja

TITLE : ハイブリッド環境またはクロスプレミス環境で発生するエラー: “Free/Busy information couldn’t be retrieved because the attendee’s Mailbox server is Busy.”
URL : http://support.microsoft.com/kb/2838688/ja

TITLE : Office 365 のユーザーは、Exchange Server 2010年ベースのハイブリッド展開でのオンプレミスのユーザーの空き時間情報データを取得できません。 (機械翻訳ですが、英語版ページが表示できませんでした。)
URL : http://support.microsoft.com/kb/2879736/ja

TITLE : クロスプレミス環境または Exchange ハイブリッド展開組織のユーザーの空き時間情報参照機能が動作しない
URL : http://support.microsoft.com/kb/2928514/ja

/autodiscover/autodiscover.svc/WSSecurity へのアクセスで O365 User の認証が通らなかったので、認証まわりの問題であることがわかり、はじめは負荷分散装置の設定を疑いましたが、いろいろ確認しても問題はなさそうでした。

そこで、Try and Error で Exchange 2010 側の設定をいろいろやっていく中で、EWS の -DigestAuthentication を $True にして iisreset したところ、解決することができました。

## 設定変更前の状態確認
Get-WebServicesVirtualDirectory | FL *auth*

CertificateAuthentication     :
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication    : False
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True

CertificateAuthentication     :
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication    : False
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True


## 設定変更 (この設定後に解決を確認)
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -DigestAuthentication $True
iisreset /noforce


## 設定変更後の状態確認
Get-WebServicesVirtualDirectory | FL *auth*

CertificateAuthentication     :
InternalAuthenticationMethods : {Basic, Ntlm, Digest, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods : {Basic, Ntlm, Digest, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication    : False
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : True
WindowsAuthentication         : True

CertificateAuthentication     :
InternalAuthenticationMethods : {Basic, Ntlm, Digest, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods : {Basic, Ntlm, Digest, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication    : False
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : True
WindowsAuthentication         : True

確認のために再度 -DigestAuthentication を $False にすることで現象を再現することができたので、この設定で解決していること自体は間違いないと思うのですが、ダイジェスト認証が必要という情報はどこにも見当たりませんでした。
すっきりしないですが、ひとまず解決となりました。

Office 365 にディレクトリ同期されているアカウントを Office 365 側から完全に削除して再同期する方法

Office 365 にディレクトリ同期されているアカウントは Office 365 の GUI から操作して削除することはできません。
“Windows PowerShell 用 Windows Azure Active Directory モジュール” がインストールされているマシンからコマンドレットで削除を実施します。
削除を実施後は、Office 365 側の “削除済みユーザー” に入り、30 日間は回復が可能な状態となり完全には削除されません。
このため、Active Directory 側のユーザーを消している訳ではない場合は再度ディレクトリ同期がかかったタイミングで自動的に回復が行われます。

しかしながら、トラブル シュートなどで Office 365 側のアカウントや Exchange Online のメールボックスを最初から作り直したいような場合、30 日も待たなければならず、少し不便です。
そういった場合、-RemoveFromRecycleBin というパラメーターを指定して再度削除することで、”削除済みユーザー” からも削除してすぐに作り直しができます。

■ ディレクトリ同期されているアカウントを Office 365 側から完全に削除

## 1. ユーザーを削除
Remove-MsolUser -UserPrincipalName User01@domain.com

## 2. 削除済みユーザーを削除
Remove-MsolUser -UserPrincipalName User01@domain.com -RemoveFromRecycleBin

## 3. ディレクトリ同期を実行して Active Directory から再同期

■ ディレクトリ差分同期用のバッチ ファイル
参考までに、私はディレクトリ同期用に以下のようなバッチ ファイルを作成しています。
もっとスマートな方法もあるのかもしれませんが。。。

@echo off
cd "C:\"

:: ###### 処理
:: ## 差分ディレクトリ同期を即時実行
PowerShell.exe -PSConsoleFile "C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1" -Command . { Start-OnlineCoexistenceSync }

Exit /B

Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #5

これまでに続いて、Exchange 2007 から Exchange 2013 へパブリック フォルダーを移行する際にハマった落とし穴について記載します。
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #1
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #2
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #3
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #4
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #5
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #6

ちょっと番外
Exchange Server 2013 パブリック フォルダーにアクセスができない

移行の手順はおおむね以下の Technet 記事の通りに実施しています。
TITLE : 以前のバージョンから Exchange 2013 にパブリック フォルダーを移行する
URL : http://technet.microsoft.com/ja-jp/library/jj150486(v=exchg.150).aspx

■ #5. 作成者権限を持っていても、過去の投稿アイテムを編集できない
フォルダーに対して作成者権限が与えられている場合、自分自身の投稿アイテムについては編集や削除ができます。
しかしながら、Exchange 2013 への移行後、これができなくなるという問題が発生しました。
フォルダーに対して編集者の権限を与えると、アイテムが編集できることは確認できたので、作成者の情報が変わってしまっているのではないかと予想できました。

MFCMAPI を使用してアイテムの MAPI プロパティの比較を行ったところ、PR_CREATOR_NAME については変わっていませんでしたが、PR_CREATOR_SID という MAPI プロパティが消失しており、これが原因のようです。
現在 Microsoft にも調査を依頼しているところですが、メールボックスの予定表フォルダーでも類似の現象が発生しているようです。
Exchange 2013 ではパブリック フォルダーもメールボックスなので、Exchange 2013 メールボックスに移行する際に何か問題があるのかもしれません。
何か情報にアップデートがあればこちらでお知らせします。

#### 2014/06/17 追記
本件については、修正のリクエストは見送られたとのことでした。
また、Exchange Blog でもこの現象についての情報が公開されましたので、記載しておきます。

TITLE : Exchange 2007 から Exchange 2013 へ移行したパブリック フォルダーのアイテムが一部編集できない
URL : http://blogs.technet.com/b/exchangeteamjp/archive/2014/06/16/3632892.aspx

#### さらに追記
KB ができていました。

TITLE : Exchange 2013 へのメールボックスの移動により、共有された予定表フォルダのアイテムが編集できない
URL : http://support.microsoft.com/kb/2938619/ja-jp

#### 2015/07 さらに追記
この問題は Exchange 2013 CU8 以降で修正されているようです。

Exchange Server 2013 への PF 移行後、作成者権限を持っていても過去の投稿アイテムを編集できない問題

Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #4

これまでに続いて、Exchange 2007 から Exchange 2013 へパブリック フォルダーを移行する際にハマった落とし穴について記載します。
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #1
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #2
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #3
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #4
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #5
Exchange Server 2013 へのパブリック フォルダー移行での落とし穴 #6

ちょっと番外
Exchange Server 2013 パブリック フォルダーにアクセスができない

移行の手順はおおむね以下の Technet 記事の通りに実施しています。
TITLE : 以前のバージョンから Exchange 2013 にパブリック フォルダーを移行する
URL : http://technet.microsoft.com/ja-jp/library/jj150486(v=exchg.150).aspx

■ #4. Legacy PF をロック ダウン後の問題
以下のコマンドレットで、Legacy PF (旧パブリック フォルダー) をロックダウン後、小さな問題が 2 つ発生しました。
いずれも、上記ページに記載のあることなのですが、備忘録的に記載しておきます。

## PublicFolderMigrationRequest を再開
Get-PublicFolderMigrationRequest | Resume-PublicFolderMigrationRequest

## 差分同期が完了して、再度 AutoSuspended になったことを確認後、
## Legacy PF をロックダウン
[PS] D:\PFMig>Set-OrganizationConfig -PublicFoldersLockedForMigration:$True

## 数名のユーザーで New PF へのアクセスをテストするための設定
$TestUser = @("User01","User02","Administrator")
$PFMailbox = "PrimaryPF"
$TestUser | Set-Mailbox -DefaultPublicFolderMailbox $PFMailbox

■ #4-1. 単一のパブリック フォルダー データベースなのに、30 分以上経過しても、ロックダウンされない
上記の Technet ページには以下のような記載がありますが、今回は単一のパブリック フォルダー データベースのみだった上、最後のレジュームはロックダウンの直前にやっていました。

――― 抜粋 ―――
組織に複数のパブリック フォルダー データベースがある場合、パブリック フォルダーのレプリケーションが完了して、すべてのパブリック フォルダー データベースの PublicFoldersLockedForMigration フラグが解除されたことが確認されるまで待機する必要があります。この処理には数時間かかる場合があります。
―――――――――

30 分以上経過してもロックダウンされていないようでアクセスが可能な状態になったため、パブリック フォルダー ストアを一旦ディスマウントして、再度マウントしなおしたところ、ロックダウンされたようでアクセスできなくなりました。 原因については不明ですが、検証環境でも本番環境でも発生していました。

■ #4-2. メールが有効なパブリック フォルダーへのメールは移行完了まで配信されない (滞留する)
こちらも上記の Technet ページには以下のような記載がありますが、メールが届かないという事はこの部分のテストは一旦移行を完了するまで確認できないという事であり、若干の注意が必要です。

――― 抜粋 ―――
次の手順では、ユーザーをパブリック フォルダーからログ オフさせて、移行が最終的な同期を完了するまでフォルダーをロックします。このプロセスの間、ユーザーはパブリック フォルダーにアクセスできません。また、メールが有効なパブリック フォルダーに送信されたメールはキューに入れられ、パブリック フォルダーの移行が完了するまで配信されません。
―――――――――

以上が、Legacy PF をロック ダウン後に発生した (小さな) 問題です。 次回は、移行後に発生した問題について記載します。