Exchange Server 2007 to Exchange Server 2013 Migration

Exchange 2007 から Exchange 2013 への移行の方法をまとめた動画がアップされています。
初めの Active Directory 構築から、Exchange 2007 のインストールおよび設定、Exchange 2013 のインストールおよび設定、移行、Exchange 2007 のアンインストール、までが 30 分の動画にまとめられており、参考になります。

TITLE : 【早送り検証】Exchange 2007 から Exchange 2013 への移行
URL : https://www.youtube.com/watch?v=I89FuVRVgR8

 

AD FS 証明書の更新後に接続ができなくなった!

AD FS の証明書を更新した数週間後、AD FS への接続ができなくなってしまいました。
証明書を更新した直後は接続できていたように記憶しているのですが、詳細を確認していなかったので、おそらく元の証明書の期限内だったので問題ないように見えていたものと思われます。

インターネットから TMG を経由したアクセスだと、”HTTP Error 503. The Service is unavailable.”  となっており、内部からのアクセスだと、証明書の警告 (期限切れ) となっていました。

以下のページを参考に AD FS と WAP で証明書を再登録して、それぞれ再起動することで、接続ができるようになりましたので、備忘録として記載しておきます。

TITLE : Android デバイスを使って Lync Mobile にサインインすると、エラー “We can’t sign you in” が発生する
URL   : https://support.microsoft.com/ja-jp/kb/2973873

TITLE : ADFSの証明書入れ替えではまった話
URL   : http://www.slideshare.net/genkiw/adfs

:: アプリケーション ID と証明書ハッシュを確認
netsh http show sslcert 

:: 証明書を一旦削除して、新しい証明書で再登録
netsh HTTP DELETE SSLCert IPPORT=0.0.0.0:443
netsh HTTP ADD SSLCert IPPORT=0.0.0.0:443 Certhash=<新しい証明書の拇印> Appid={5d89a20c-beab-4389-9447-324788eb944a}

netsh HTTP DELETE SSLCert HOSTNAMEPORT=adfs.domain.com:443
netsh HTTP ADD SSLCert HOSTNAMEPORT=adfs.domain.com:443 Certhash=<新しい証明書の拇印> Appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices

netsh HTTP DELETE SSLCert HOSTNAMEPORT=adfs.domain.com:49443
netsh HTTP ADD SSLCert HOSTNAMEPORT=adfs.domain.com:49443 Certhash=<新しい証明書の拇印> Appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices


:: 以下は再登録しなくても動作しているようだったが、古い証明書の拇印だったので念のため再登録
netsh HTTP DELETE SSLCert HOSTNAMEPORT=EnterpriseRegistration.domain.com:443
netsh HTTP ADD SSLCert HOSTNAMEPORT=EnterpriseRegistration.domain.com:443 Certhash=<新しい証明書の拇印> Appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices

netsh HTTP DELETE SSLCert HOSTNAMEPORT=EnterpriseRegistration.ad.domain.com:443
netsh HTTP ADD SSLCert HOSTNAMEPORT=EnterpriseRegistration.ad.domain.com:443 Certhash=<新しい証明書の拇印> Appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices

netsh HTTP DELETE SSLCert HOSTNAMEPORT=localhost:443
netsh HTTP ADD SSLCert HOSTNAMEPORT=localhost:443 Certhash=<新しい証明書の拇印> Appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices


 

予定表のアクセス権にグループが追加できない

Exchange 2007 から Exchange 2010 に移行した環境で、特定のグループが予定表のアクセス権に追加できないという問題があります。

数年前によく耳にしていた問題ではあるのですが、最近も耳にしたので、ここに記載しておきます。

■ 現象

  1. メールボックスの [予定表] のプロパティを開く
  2. [アクセス権] タブの [追加] をクリック
  3. アクセス権を追加したいグループを検索
    –> この時点で、以下の例のようにアクセス権に追加できない進入禁止のようなアイコンとなっている状態
    予定表アクセス権に追加できない_1b
  4. アクセス権に追加したいグループを選択して、[追加] – [OK] とクリック
    –> 以下のようなエラー メッセージが表示
    ————————————————————
    フォルダー アクセス権に追加できないユーザーがあります。ローカル ユーザー以外にこのサーバーのアクセス権を与えることはできません。
    ————————————————————
    予定表アクセス権に追加できない_2

■ 原因

はじめに、予定表のアクセス権に追加できるグループの条件は以下の通りです。

  1. メールが有効
  2. セキュリティグループ
  3. スコープが「グローバル」か「ユニバーサル」 (Exchange 2007 以降は原則として (ユニバーサル」)

このうち、メールが有効でなければアドレス帳に出て来ないのでこれは当然問題なく、残りの 2 項目についてもすぐに確認および変更ができるため、問題になることはほとんどないと思います。

また、何らかの変更を加えた直後などは、クライアント側のキャッシュの問題で現象が解決できないように見える可能性がありますが、これもオフライン アドレス帳を更新後、ダウンロードしなおせば問題はなくなります。

ここまでの情報については、技術情報も公開されています。

TITLE : You may receive an error message when you try to set permissions for a distribution group in Outlook 2007 or Outlook 2010
URL   : http://support.microsoft.com/kb/941318/

TITLE : How to change a UDG to a USG in Exchange 2010
URL   : http://blogs.msdn.com/b/pepeedu/archive/2010/08/26/how-to-upgrade-a-universal-distribution-group-to-a-universal-security-group.aspx

しかしながら、上記のようなことをしても問題を解決できない場合があり、そのような場合に  msExchRecipientDisplayType の値を削除することで問題が解決できるケースがいくつかありました。

具体的には、ADSI Edit で問題のオブジェクトのプロパティを開いて、msExchRecipientDisplayType の値を削除する、という方法です。

私が見てきたケースではこれにより別問題が発生したケースはないのですが、msExchRecipientDisplayType を Exchange 以外から編集することは Not Support とのことですので、Active Directory のバックアップ等、万が一の事態に備えた上で作業する必要があります。

TITLE : Outlook 2010 cannot add group for permissions – One or more users cannot be added to the folder access list. Non-local users cannot be given rights on this server
URL   : http://support.risualblogs.com/blog/2011/08/26/outlook-2010-cannot-add-group-for-permissions-one-or-more-users-cannot-be-added-to-the-folder-access-list-non-local-users-cannot-be-given-rights-on-this-server/

TITLE : O365: Exchange and AD – How msExchRecipientDisplayType and msExchangeRecipientTypeDetails Relate to Your On-Premises
URL   : http://blogs.technet.com/b/johnbai/archive/2013/09/11/o365-msexchangerecipienttypedetails.aspx

TITLE : Exchange 2007 and Recipient Type Details
URL   : http://blogs.technet.com/b/benw/archive/2007/04/05/exchange-2007-and-recipient-type-details.aspx

 

移行後の Windows Server 2012 R2 Active Directory にログオンできなくなる問題

Windows Server 2003 Active Directory から Windows Server 2012 R2 Active Directory の移行した環境で、コンピュータ アカウント パスワードが変更が 2 回発生した後に、ドメインにログオンできなくなる、という問題があります。
原因は、Windows Server 2012 R2 ドメイン コントローラーの AES 暗号化キー作成処理にある問題なのですが、既に移行してしまっている場合、対処によるインパクトが大きいです。

■ 移行前の場合の対処
Windows Server 2012 R2 に修正プログラム (KB2989971) を適用してから、ドメイン コントローラーに昇格する。

■ 移行後の場合の対処
Windows Server 2012 R2 ドメイン コントローラーに修正プログラム (KB2989971) を適用してから、すべてのドメイン コントローラーおよびメンバーを再起動する。

なお、KB2989971 の修正プログラムを適用するためには、以下を満たしている必要があります。
1. KB2919355 が適用されている事 (Windows Update で適用可能)
2. AD DS (Active Directory ドメインサービス) がインストールされている事

【参考情報】
TITLE : Can’t log on after changing machine account password in mixed Windows Server 2012 R2 and Windows Server 2003 environment
URL : http://support.microsoft.com/kb/2989971/en

TITLE : Windows Server 2012 R2 をドメイン コントローラーとして Windows Server 2003 で構成された Active Directory ドメインに追加後、ログオン障害が発生する
URL : http://blogs.technet.com/b/jpntsblog/archive/2014/10/16/windows-server-2012-r2-windows-server-2003.aspx

 

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