「Microsoft Office365」カテゴリーアーカイブ

Enterprise Mobility + Security E3ではじめるゼロトラスト入門 – 1 – 購入編

ども。こんばんは。

最近のセキュリティ界隈では「ゼロトラスト(セロトラストネットワーク)」なるキーワードが盛んですね。

これまでのようにファイアウォール等の境界で守られたネットワークを信用しない、という考え方のようですね。
例えば、カフェなどの公衆Wi-Fiにつなごうが、社内LANにつなごうがどちらも同じ、何も信用しないという考え方です。

いろいろな構成要素がありますが、自宅でも気軽に試せる部分として
・IDセキュリティ(IDを安全にする)
・デバイス管理(MDM)
からやってみたいと思います。
※あとは、SASE(Secure Access Service Edge)とかEDR(Endpoint Detection & Response)があると、どこでも同じポリシーのセキュリティを、境界ではなくエンドポイント上で不審な動きを監視、といったよりゼロトラストな感じになると思います。

さて、今我が家ではMicrosoft 365 Business Basicを契約しています。

これに、Enterprise Mobility + Security E3を追加して、ID保護としてのAzure AD Premium P1、MDMとして、Microsoft Intuneを使えるようにします。

Microsoft 365 Business Premium(¥26,160/年)にすべきかも悩んだのですが、Microsoft 365 Business Basic(¥6,480/年)+EMS E3(¥11,520/年)にしました。Business Premiumよりも、¥8,000くらい安くなりました。この差額は、デスクトップアプリ版のOffice分ですかね。最近IPadばっかりでWindowsをあまり使ってないのでデスクトップ版Officeアプリはいいかなーという感じです。

ちなみにEMS E3は「Enterprise Mobility Suite Direct」に名前が変わった(変わる?)ようです。

サクッと買います。購入はMicrosoft 365管理センターの「サービスを購入する」から。

無事買えました。

続いてライセンスを割り当てます。

無事にAzure AD上のライセンス画面でも割当が行われました。

知らない間に、Azure ADのライセンスもPremium P1になっていました。

次回からは、各デバイスをIntuneに登録していきたいと思います。

ではでは。またの機会に。

無料のOneNoteからOffice 365への移行

ども。こんばんは。

あんまり参考になりませんがちょっと苦労したので書いておきます。

やりたいこと

  • 無料のOneNoteからOffice 365に移行したい
  • Office 365はデスクトップアプリなし(Office 365 Business EssentialsやE1)

デスクトップアプリのある、Office 365 Business Premiumでは、以下のサイトの方法が参考になります。

Office365 BusinessへOneNote移行が難しすぎる件 | しきろぐ

この通りにやろうとしても、OneNote2016では、Offiece 365のOneDriveにサインインできないため、うまくいきません。

以下のようなエラーになります。そりゃぁまあライセンス買ってないししょうがないけど。。。無料でも使えるのにちょっとこれは悲しい。

このノートブックを使うには、有効な Office 365 サブスクリプションのライセンス認証を行う必要があります

強引にエクスポートしたonepkgファイルを開こうとしても、以下のようなエラーになります。

現在、OneDrive では、ノートブックの作成のみ可能です。ノートブクのその他のオプションを利用するには、Office 365 サブスクリプションのライセンス認証を行ってください。

結論、手でコピーするしか無いようです。

一番やりやすかったのは、

  1. OneNote 2016で無料版OneNoteを開く
  2. ストア版のOneNoteアプリ(UWP)でOffice 365のOneNoteを開く
  3. OneNote 2016でページをコピーしてOneNoteに貼り付ける

セクションをまるごと移せないので最低限必要なページだけ手で移行しました。

まぁ、やろうと思えばOffice 365 Business Premiumを評価版で一時的に使うっていう方法もありかと思います。

ではでは。またの機会に。

 

 

令和になったことだしクラウドへ移行する – 15 – Azure AD Connectを強制停止する

ども。こんにちは。

先日ADをぶっ壊してしまい、再構築しましたが、AD Connectはインストールしておらず、以前のオンプレEchangeからExchange online(Office 365)へ移行した際に設定したAzure AD Connectがずっと同期エラーの状態でした。

また、こんな感じでソースが「Windows Server AD」となっているユーザは、Azure AD上で編集や削除ができません。
不要なユーザはAzure AD上でサインインをブロックに設定はしていましたが、いい加減適当な名前のユーザも結構います・・・。

もう二度とオンプレADと同期はしないと覚悟を決めたので、同期を強制的に解除します。

やり方としてはPowerShellで

 Set-MsolDirSyncEnabled -EnableDirSync $false

を叩くだけです。

参考:Office 365 のディレクトリ同期を無効にする

上記のページにも書いていますが、これは最終手段というかもう二度と同期しないくらいの覚悟?のコマンドのようですね。

PowerShell を使用して、ディレクトリ同期を無効にすることができます。 ただし、トラブルシューティング手順としてディレクトリ同期を無効にすることはお勧めしません。 ディレクトリ同期のトラブルシューティングに関してサポートが必要な場合は、「 Office 365 のディレクトリ同期の問題を解決する」の記事を参照してください。

ハマったのは、反映されるまでの時間です。

オンプレミス Active Directory Domain Services から Azure AD に同期したオブジェクトを管理、削除できない

注: アカウントが無効化されるまで、72 時間ほどかかる場合があります。処理に要する時間は、Office 365 サブスクリプション アカウントにあるオブジェクト数により異なります。

結局、ソースがAzure Active Directoryに変わるまで36時間ほどかかりました。

これで無事Azure AD上から削除できます。

で、やらかしたことは・・・

ユーザを消しすぎた

です・・。

オンプレExchangeからOffice 365に移行したときに、いくつかのメールボックスをユーザメールボックスから共有メールボックスに変換しています(ライセンス節約のため)が、変換前のユーザを勢いで消してしまい、一瞬共有メールボックスがみえなくなりました。。。。

すぐに削除済みユーザから戻したので復活しましたが・・・。

これ忘れそうだな。。。

以前ここで読んでたのに忘れてました。

ユーザー メールボックスを共有メールボックスに変換する

古いユーザー アカウントは削除しないでください。 それは共有メールボックスの固定に必要です。 ユーザー アカウントを既に削除している場合、「削除済みユーザーのメールボックスを変換する」 (削除されたユーザーのメールボックスを変換する) を参照してください。 

またやらかしそう・・・

ではでは。またの機会に。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 5 – Exchange Server 2010 to Office 365(4)

ども。こんばんは。

気づけばもう連休もあと1日半です・・・。

昨日はずっと寝てたのと、今日も夕方まで寝てしまったので、さっさと続きをやります。

とりあえず、前回の残タスクの通り、ライセンス節約のため個人メールボックスを共有メールボックスに変換します。

やり方はこんな感じ。

ユーザー メールボックスを共有メールボックスに変換する

  • 変換するユーザーメールボックスには、共有メールボックスに変換する前に割り当てられたライセンスが必要です。 そうでない場合、変換オプションがメールボックスに表示されません。ライセンスを削除した場合、メールボックスを変換するために再度それを戻す必要があります。 ライセンスは、メールボックスを共有に変換した後に、ユーザー アカウントから削除できます。
  • 共有メールボックスは、ライセンスなしで、最大 50 GB のデータを保持することができます。 これ以上のデータを保持するには、ライセンスを割り当てる必要があります。 ライセンスを削除するには、(添付ファイルがあるものなど) 大きなメールを多数削除してサイズを小さくする必要があります。
  • 古いユーザー アカウントは削除しないでください。 それは共有メールボックスの固定に必要です。 ユーザー アカウントを既に削除している場合、「削除済みユーザーのメールボックスを変換する」 (削除されたユーザーのメールボックスを変換する) を参照してください。

ポイントとしては、上記の3点ですね。特に3つ目。読んでなかったら確実に消してたわ。

【追記:やらかした】
やかしました。多分大丈夫ですが、上記のサイトの下の方にこんなことが書いてあります。
もしかしたら、またユーザメールボックスに戻される・・・のかも???うーん・・・。まぁいっか。
強くお勧めするならもっと上に書いておいてほしかったです。。。

ハイブリッド環境でユーザーのメールボックスを変換する

この共有メールボックスがハイブリッド環境にある場合は、ユーザーのメールボックスをオンプレミスに戻して、ユーザーのメールボックスを共有メールボックスに変換してから、共有メールボックスをクラウドに戻すことを強くお勧めします。

その理由は次のとおりです。クラウド内のメールボックスを変換すると、そのメールボックスは変換されますが、新しい現実はオンプレミスに同期されないため、オンプレミスではメールボックスがユーザーのメールボックスであると見なされます。

通常、これは問題ではありませんが、オンプレミスの属性 (メールボックスがユーザーのメールボックスであると考えられる) が新しいクラウドバージョンの属性を上書きする可能性があるため、その結果、メールボックスの変換が行われる場合があります。 ユーザーメールボックスがライセンスを必要とするか、30日後に削除された場合は、この問題が発生します。

これが発生する理由のほとんどが解決されましたが、これはまだ発生する可能性があります。 安全にして、メールボックスをオンプレミスに戻すことをお勧めします。

あと、やっぱりいきなり契約せず評価ライセンスではじめてほんとに良かった。移行するにしてもライセンスが最初は必要になるんですね。

ちなみに、ちゃんと ハイブリッド構成にしたおかげて?権限も移行できてるので、ちゃんとメインで使う予定のユーザは他のメールボックスを開くことはできます。(フルアクセセスを与えており、ちゃんと引き継がれた。さすがハイブリッド!)

でもやりたいのはこうじゃないし、それぞれのボックスの所有者でログインしたり、それぞれの予定表を作る予定もなく、あくまで、システム通知やSNS系のメールの受け用のボックスがほしいのです。

参考:オンプレExchange時代の運用

で、後悔しないように改めてこちらの記事も読んでみました。うん、今回はやっぱり共有メールボックスが正しい・・はず!

参考:Office365「共有メールボックス」とは

■ユーザメールボックスを共有メールボックスに変換する

早速やってみます。

Exchange管理センターから該当メールボックスをポチッと。

はいはい。

即効でおわります。数秒。

この時点では、ライセンスを停止してない?ので、まだ元のメールボックスの所有者でログインしてOWAでメールが見えるっぽいですね。

もう一つ変換対象があるので、そっちも同様の手順でやります。(10GBくらいあるボックスだったのですが、2分くらいで終わりました。)

無事共有に変換できました。

とりあえず、OWA上で追加してみる。

メインのアカウント上で自分の名前を右クリックして「共有フォルダーの追加」をクリックします。

あとは選ぶだけ。(「他のメールボックスを開く…」と要領は同じですね。)

最終的にこんな感じになりました。

とりあえず、送受信テストしてみます。

あれ、差出人が共有メールボックスにできないですねー。

うーん。フルコントロールなんだけどなー。

一応権限つけてみました。

だめですねー。候補に出てこない。

念の為、「他のメールボックスを開く…」でやってみたところ・・・・

このメールボックスからメッセージを送信するためのアクセス許可がありません。

えー。うそんフルコンやし、ちゃんと送信する権限もつけたけどなー。反映に時間かかるのかなー。

まぁいいわ。別に。そのうちなんとかなるでしょう。「メールボックス所有者として送信する」の権限は必須ぽいので。

ちょっと先に進めます。

■ライセンスを剥奪して、サインインも禁止する!

これで、共有メールボックス化が無事できたので、旧ユーザからはライセンスを剥奪します。
あと、サインアップ時に作った「.onmicrosoft.com」もライセンス剥奪してみます。

また、ADから引っ越してきたユーザはパスワードがボロい可能性も大いにあるので、サインインも禁止します。

さらばライセンス。

ちなみにいいかどうか知りませんが、onmicrosoftのアカウントもライセンス剥奪しました。

これで、ライセンスを持っているのは1人のみになりました。

ちなみにライセンスを剥奪したユーザでログインしてみました。

おー、空っぽですね。

で、一応今回ADと同期してはいますが、余計なユーザはOffice365にサインインできないようにしてみます。
※onmicrosoft,comのユーザは念の為、ライセンスは剥奪しましたが、サインインは可能にしてあります。もちろん別で全体管理者は設定済み&サインアップ時の連絡先は、ライセンス付与済みユーザにしています。

 


【2019/05/05 追記】

勢い余って、Azure AD Connectに必要な同期用ユーザまでサインイン禁止にしてしまったみたいです。

なので、「Sync_[サーバ名]_[ランダム?]@hitsnetcom.onmicrosoft.com」はサインインを有効にしてあげたら治りました。

これでsyncしたら、ブロックしたユーザまたサインイン許可に戻ってしまった・・・

うーん。やっぱりAD側でログイン無効化して同期させるのが正しいんだろうけど、やだなーこれ。課題ですね。

 


 

 

で、サインイン禁止したユーザで入ってみたところ。
※てかID・PWの確認はできてしまう気がする。。。。。。

↑これは反映中だったみたいです。しばらくするとこうなります。

とはいえ、アカウントの存在とパスワードが正しいことはバレちゃいますねこれ。まぁいいか。。

Azureも一緒にかわるっぽい?(←もともとこのユーザサインインできてたか未確認です)

さぁ、だいたいできた。

■正規のライセンスを買って割り当てる

まだ評価期間は残っていますが、このっている今だからこそ正規版を買います。
※そしたら、何かあっても、最悪評価版に割り当て直して調査できる猶予がある!はず・・・。

いきなり1年契約でかいます。

住所とかを入れます。

年間¥6,998です。

何故かシークレットモードのブラウザだと手順3にいけませんでしたのでやり直し。。。

支払い方法を入れます。

かいましたー。

無事追加。

ライセンスを割り当て直します。

試用版をoffにして購入した方をonにします。

個別の機能でのon/offもできるんですね。

できましたー。

ちゃんとライセンス数が更新されていますね。

一応請求書などのメール連絡先も確認します。
予定通り、追加しておいた全体管理者が有効になっており、onmicrosoftの方の連絡先メールアドレスもライセンスのあるユーザになっています。
これならonmicrosoftにはライセンスなくても大丈夫・・・だと思います。

おまけ。ライセンス変更前後のサインイン後の画面。
ちょっとへりました。

■仕上げ:DNSレコードの変更(外部向け)

さて、ここまででもう準備は終わったのでいよいよDNSレコードの向き先を変えます。

とりあえず、CSVでエクスポートもしていたのですが、MXとCNAMEをいれます。

途中の画面を取り忘れましたが、チェックする機能があります。
終わったら確認を押すと以下のようにOKになります。

管理のドメインから状況が確認できます。
おっと、一つカスタムドメインのDNS設定が漏れていましたね。困りはしないのですが一応いれます。

使うサービスを選びます。(これによって向け先に出てくるレコードが変わるみたいですね。Exchangeなら基本MXとautodiscover用のCNAMEとSPFだけとか。)

Exchangeだけえんだので、3つだけです。
※ただし、見切れてますがこの画面上にあるエクスポート機能でエクスポートすると全サービス分のレコードがCSVででてきます。

はい。おわりました!

ちなみに今回SPFレコードは、Office365に加え、自宅の固定IPアドレスも残しています。
それでもチェック結果はOKだったので問題ないと思われます。

■仕上げ:DNSレコード+Postfixのtransportの変更(内部向け)

ここからは内部向けの話なので、関係ない人はここまでで晴れてOffice365ユーザとして利用可能になります!

さて、うちの場合は、

内部DNSサーバのMXレコード修正と、内部用メールをtransportでオンプレExchangeに向けている部分を修正します。

ありふれた手順なので省略します。reloadとかpostmapとか忘れないでね。

ということで、経路がこうなりました。
(この辺ももうリプレースしないとですね。)

内部サーバ->オンプレExchange->ハイブリッド構成->o365

内部サーバ->o365
※ここはTLSにしたいところだけど、面倒くさいのでやめました。

ちなみに、これは主に内部サーバのシステム通知系なので、自ドメイン以外には送信しません。
※内部ですけど、外から来るメールと同じ扱いにしました。

【メモ】
Zabbixの通知先に携帯キャリアメールが入っている。今はオンプレPostfixにSMTPを向けているがこれをo365に変更するときは、うちでも設定が必要。
各種サーバは全体的にSmartRelayでo365にむけないとなぁ。

なので、o365用のMXレコード宛に送りつけるだけです。自ドメイン以外の外部に送る場合は、認証がいるはずです。

この辺を参考にしてみてください。

Office 365 を使用してメールを送信するように多機能デバイスまたはアプリケーションをセット アップする方法

※昔は性的なグローバルIPアドレスを認証条件にできたけど、いつからかTLSで証明書入れるの必須にならなかったけ。

さて、あとはインターネットからメールサーバ宛の25/tcpを閉じれば終わりですね。

TTLも300だしもうとっくに伝播したと思いますが、一応旧メールサーバのmaillogを流しながら、全アドレスにテストメールを送信して、旧サーバに回っていないことを確認しました。

というかこの時点でもまだ、差出人が共有メールボックスにできないです。この記事を書いている間に数時間経過したのですが・・・。まぁそれは別の課題で。。。

ということで、一旦終わりです。

あとは細かなタスクとして・・・

  • macOSのメールアプリで共有メールボックスにアクセスする
  • 古いサーバのメールの向き先変更(snmptrapのメール変換とかもそろそろやめたい・・・)
  • Zabbixの通知メールサーバ変更(宛先にキャリアメールが入っているので注意)
  • 各種アプライアンスのメール通知先とか見直し

そんなところかな。あーWebサーバの移行できるかなぁ。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 4 – Exchange Server 2010 to Office 365(3)

ども。こんにちは。

続きです。

改めて、今回の移行方法ってどれなんだろうと探してましたが、これっぽいですかね。

最低限のハイブリッドを使用して Exchange メールボックスを Office 365 に移行する

 

■メールボックス移行完了

昼間は練習に行ってたので、更新できませんでしたが、とりあえず朝の段階でメールボックスの移行は終わっていました。

移行すると、オンプレExchange側では、「切断されたメールボックス」になり、さらに移行済みユーザはリモートユーザメールボックスというのが作られるっぽいですね。

状態の「完了」と「クラウド内」は何が違うんだろう・・・。

とりあえず、OWAで見れてるからいいよね・・・。

 

それでは続きを。

■早速やらかす

メインで使うつもりのユーザ(ADから同期したもの)のUPN(UserPrincipalName)を変えてしまいました。

というか、変更できるのおかしくないか・・?

たまたま同期の完了前だった・・・?

後述しますが、これ基本あとから変えようと思うと、PowerShellなんですよね。。。

で、なんでOffice365のUPNを変えたかったかというと、特に何も考えてませんでした。

単純にAzure AD Connectから同期したときには全員「ユーザ名@ADドメイン名.ドメイン」だったのです。
もちろんエイリアス(proxyAddresses属性)で「ユーザ名@ドメイン」は追加されているしもともとオンプレExchangeでも承認済みドメインだったので、メールボックスは「ユーザ名@ドメイン」がプライマリメールアドレスになっています。

なんかADドメイン名邪魔なとか、単にそんな理由。

変更したらですね。別で作っているMicrosoftカウントとoutlook.comともろバッティングしました。

もう大変です。すべてごちゃごちゃになりました。

重複問題:#AzureAD と Microsoft アカウントの重複問題に対する取り組み

これひどい話ですよねー。そのうちもっと良くなればいいですけど。

しかも今日気づいた新事実ですが、outlook.comも最近outlook.office365.comにサーバが統合されているっぽいのです。

だから、IMAPでoutlook.comに個人的なメールを取りに行ってたんですが、Office365に置き換わりましたorz
まぁサインインの画面でた時点で気づけって話ですよね。

以下、macOS標準のメールで途中で出てきました。

ちなみに旧来の「imap-mail.outlook.com」ですが、ガッツリCNAMEでoutlook.office365.comに向いてます。

> imap-mail.outlook.com

imap-mail.outlook.com canonical name = outlook.office365.com.
(以下略)

確かに、改めてOutlook.comを見ると、IMAPの取得先がoutlook.office365.comに変わっている。。。

で、これについては、とりあえず、outlook.comで他のメールアドレスも持っていたので、そっちでログインして一旦回避。あとで、UPNももとに戻しました。苦労しましたけど。これは後述しますね。

■サインアップ時のユーザ以外にも全体管理者を設定

しました。目論見どおりに行けばサインアップ時のユーザにはOffice365のライセンスは与えないつもりです。
※連絡先メールアドレスは、別のユーザ(課金予定)にしています。し、これも後述しますが、zure Active Directory ID 同期ツールのエラーとかはちゃんとそっちのアドレスに届いています。

で、とりあえず全体管理者つけました。

そしたらAzure AD側も勝手にグローバル管理者になってました。
※むしろAzure AD側を変えた?のかな。まぁユーザ管理する以上そうなるか。

■SPFレコードの設定(MX切り替えはまだ)

とりあえずもう事実上切り替わっているので、送信はOffice365になります。
なので、SPFレコードにOffice365も追加しました。

■ID 同期のエラー レポートに対処する

Azure AD Connectで同期し始めたから30分に一通エラーが届いていました。

この問題は、Azure Active Directory ID 同期ツールがインストールされているサーバーでID 同期トラブルシューティング ツールを実行することによって、トラブルシューティングできます。

だそうな。

SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}とやらが同期できないと。

なんかこれもよくあるトラブルっぽいですね。

Office 365 のユーザー アカウントを同期する際、Azure Active Directory 同期ツールを使用できない

mailNickNameが抜けているのでmailに併せて入れろと。

ただ、家の環境だとmailNickNameもmailも空っぽなんですが・・・。

しょうがないんで、他に併せて雰囲気で入れました。

ということで、エラーメールは来なくなりましたので解決?です。

 

■Azure AD Connectでのディレクトリ同期環境におけるOffice365ユーザ名(UPN)の変更

冒頭のやらかしへの対応です。

まぁもう一度戻せばいいやくらいに思ってましたが、ホームのユーザの編集からは変更できない。。
※ちなみにAzure AD上でも編集不可でした。

このユーザーはローカルの Active Directory と同期されています。一部の詳細は、ローカルの Active Directory でのみ編集できます。

んー、昨日触れたやん!

今度は、「アクティブなユーザ」からやってみる。

お、いける?

はいだめー。

The operation on mailbox “ユーザ名” failed because it’s out of the current user’s write scope. The action ‘Set-Mailbox’, ‘EmailAddresses’, can’t be performed on the object ‘ユーザ名’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

※これ、一回やったら戻せないだけかも。再現できちゃったよ。一回は変更できるけどもとに戻せないのかな。不思議だなぁ。

で、直し方ですが、すでにナレッジがあります。Office365はナレッジが多くて助りますね。Exchange 2010も枯れてるし、移行した企業も多そうで、いろいろナレッジが溜まっていてやりやすいです。

ディレクトリ同期環境でオンプレミス AD の UPN を変更しても Office 365 に反映されない

PowerShellで頑張ってくださいってことです。ちなみに上記サイトのサンプルコマンド間違ってるので気をつけてください。

Set-MsolUserPrincipalName -NewUserPrincipalName <変更後の UsePrincipalName> -UsePrincipalName <現在登録されているUsePrincipalName>

↓r抜けてます。

Set-MsolUserPrincipalName -NewUserPrincipalName <変更後の UserPrincipalName> -UsePrincipalName <現在登録されているUsePrincipalName>

まぁ上記サイト通り、「Windows PowerShell 用 Windows Azure Active Directory モジュール」で変更します。
Windows PowerShell 用 Windows Azure Active Directory モジュールのインストール方法は以下のサイトにまとまっています。

Azure Active Directory の PowerShell モジュール

うちの2008 R2は古いので、PowerShellをバージョンアップする必要がありました。

あと、上記のUPN変更だけならモジュールは「MSOnline」だけ入れればOKでした。

 

■残タスク

残タスクは、オンプレミスのExchangeから移行したユーザメールボックスの共有メールボックス化と、そのアクセス方法の検証かなー。それが終われば、MXバチッと切り替えますか。
※内部のサーバとかも結構向け替えないと駄目だからちょっといろいろ昔の設定を調べ直しorz

うまく行けば、試用版からOffice 365 Business Essentiialsの購入ですね。

最悪メインじゃないメールボックスは、¥430の「Exchange Online プラン 1」でもいい気がしてきた。

このIMAPで共有メールボックス読む方法も試してみないと。

APPLE MAILでOFFICE365の共有メールボックスの設定

今だと共有メールボックスよりもグループ?なのかなぁ。

Office365「共有メールボックス」とは

ちなみに、今の所移行は順調ですが、ADいつまでも必要じゃないかな・・・。
一回だけ同期する的なオプションを前回選んだ気がしますが、30分おきに同期してるっぽいんですよね。
同期をちゃんと終了して、もうなくしていいのかな。。。。。。

オンプレExchangeやめ時も難しそう。。。Azure AD Connectもいつまで必要なんや。ちゃんと同期止めたりしないとごちゃごちゃしそうだし。。。
おいらもオンプレのADもExchangeもサポート切れなんや・・・。
※NPSだけなんとかしないと・・・無線ももう無理してEAP使うのやめよかなぁ。
macOSもAD参加させてるしこれの移行も面倒だなorz

ハイブリッド展開でオンプレミスの Exchange サーバーを使用停止にする方法とそのタイミング

うーん。この記事だとカットオーバー移行だったら、スパッとやめられるっぽいことが書いてますね。
環境小さいから、ハイブリッドにしたのやっぱりしくったなぁ。
でもこの記事も同期は1回って書いてるようなぁ。

Exchange 2010 のサポート終了ロードマップ

うちは以下のサイトで言うところの②ですね。

【やまなか日記】第2回Office 365のクラウドID管理

あと、Azure Active Directoryに切り替えてやろうかと思いましたが、ちょっとイマイチなのかなー。
まだまだ情報収集中です。

Active DirectoryのPaaS版、Azure Active Directory Domain Servicesとは?

Active Directory?Azure Active Directory?混乱ポイントを整理!

今日は練習もいって疲れたので残りはまた明日。

予定してるWebサーバのAWS移行は連休中に間に合うかなー。

 

【バックナンバー】

令和になったことだしクラウドへ移行する – 3 – Exchange Server 2010 to Office 365(2)

ども。こんにちは。

前回の続きです。途中インターネット通信の問題が発覚して、溜まっていたWindows Updateなどをやったため、ちょっと時間をロスしました。(一応最新のExchange Server 2010のロールアップを当てておきたかったのでここは飛ばさす)

引き続きオンプレミスのExchange Server 2010からOffice 365(Exchange Online)へ移行します。

ここからはメールボックスの移行のため、ハイブリッド構成ウィザード(HCW)を実行します。

環境:
Windows 2008 Server R2 Datacenter
Exchange Server 2010 Service Pack 3(SP3) Roll Up 27です。

なんやかんや2時間半くらいロスしましたが再開します。

改めてインストール。即効でおわります。

なんかアイコン出てきた&なんか勝手に起動した。

次へ。いい感じで検出してくれます。

Administratorも勝手に検出ってか、ログインユーザか。

続いてOffice365側の資格情報なのですが、ちょっと参ったことに、今回サインアップしたメールアドレスってOutlook.comやマイクロソフトアカウントや、Azureにも使ってるっていうとんでもないアカウントだった・・・。

あと多分まだ、アカウントにライセンスを割り当ててないと思うので、今回はおとなしくonmicrosoft.comで行きます。

はい。とおりましたー。

1分くらい?で情報収集完了。

これはやや悩むなぁ。

デフォで行くかぁ。こだわりもないし。

ハイブリッド > ハイブリッド構成ウィザード > 組織のポリシー

[組織構成の転送] を選択すると、ハイブリッド構成ウィザードにより、組織全体のポリシーがオンプレミスの組織から Office 365 にコピーされます。ウィザードでは、アイテム保持ポリシー、アイテム保持ポリシー タグ、OWA メールボックス ポリシー、モバイル デバイス メールボックス ポリシーをコピーできます。

うん、このまま行こう!

お、また資格情報か。Administratorで良いのだろうか・・・。

行けたっぽい?

はい。更新しまーす!

2〜3分で終わりました。

おー。ここでAzure AD Connectがでてくるのかー。

推奨を信じます。

簡単設定とやらで。

んーーーー

Azureはすでにサブスクリプション持ってるのでそっちにしたかったけどうまく行かず・・
というかOffice 365サインアップした時点でAzure ADできてたっぽいので、またこっちもonmicrosoftで。

こんどはローカルADの情報を入れます。

お、ADのドメイン名と、サインアップ時にしてしたドメイン名がずれてた・・。

「Azure AD へのサインインにオンプレミスの資格情報を使用するには、UPN サフィックスが Azure AD の検証済みカスタム ドメインのいずれかと一致している必要があります。次の表には、オンプレミスの環境で定義されている UPN サフィックスと、一致する Azure のカスタム ドメインが記載されています。」だそうな。

とりあえずAzure AD上にカスタムドメインを作ってみる。

更新ボタンおしたら行けた。

ここもデフォルトを信じる!

おうおう。SQLServerとか入んのかよ。

AD Connect無事完了。

完了しましたを押してあげる。

同期始まった。

うわぁ。わらわらアカウント上がってきた。

どうでもいいテストアカウントとか、無線でMACアドレス認証やろうとしてた名残とか上がってきた・・・。
これ課金されないよね・・・?

グループにも配布フループとかきたっぽい。

はい。移行エンドポイントの作成に失敗します。

これよくあるトラブルらしいですが、クソほどハマりました。ので、あとで詳しく書きます。
※このときはオレオレ(自己署名)証明書が蹴られたかーくらいの甘い気持ちでした。

 

一応終わったぽい。あとはExchange管理コンソールでって感じですね。

よっしゃ移行の続きやるでー!!とおもったら、うーん。やっぱりライセンス割当いるのかー。
これ3人分契約しないと駄目かな・・・。あとで共有メールボックスに変更できるのかな・・・・。

じゃぁまぁとりあえず必要なやつにライセンス当てましょう。
※試用版ではじめておいてよかった・・・。

改めてここから行ってみます。

3つ割り当てます。

ユーザへの通知は一旦後回しにします。自分ひとりだし。

いや、まだ一個も移行してないけど、とりあえず終わったことにします。

 

まだDNSは切り替えないので後回しで。

とりあえずExchangeだけ開始。

ここではとりあえずレコード情報をCSVで抜いておきます。

よし、やっと移行に進めるぞ!!!!

はい。「移行エンドポイントが見つかりません。」

さーて、ここから相当ハマりました。

よくあるトラブルらしく以下のガイドがあります。

(英語だけど詳しい)

Troubleshooting issues where the hybrid migration endpoint cannot be created

(さらっとしている)

オンプレミスの Exchange Server から Exchange Online へメールボックスを移動しようとすると、”The remote server returned an error: (403) Forbidden.” エラーが表示される

うちの場合は以下にどハマりしました。

  • 正規に署名された証明書をOutlook Anyehere(OWA?)に適用していなかった
    • 急いでGeoTrustの30日のトライアル証明書を取得
      これ結構海外でもハマってる人いました。
    • その後、発行された証明書をExchangeコンソールから、IISに適用
  • MRSProxyはEnableだったが、認証方式にBasicがなかった
    • オンプレExchange側の管理シェルで以下のコマンドを実行
    • Set-WebServicesVirtualDirectory “EWS (Default Web Site)” -BasicAuthentication $true
    • iisresetもしておく。
  • MRSProxyのExternalURLが実際に外部(Office365)からアクセス際のURLとずれていた
    • 上記同様に以下のコマンドをExchangeの管理シェルから実行して修正
    • Set-WebServicesVirtualDirectory “EWS (Default Web Site)”  -ExternalUrl https://hogehoge.com/ews/exchange.asmx
    • iisresetもしておく
  • 何故かOffice365側で「ドメイン¥」を入れないと通った
    • 謎。これだけで良かったかも。。。。

以下、上記トラブルシューティングのドキュメントにもあるけど、使えるコマンド。

太字部分は要注意。

 

Get-WebServicesVirtualDirectory|fl ExternalAuthenticationMethods,Externalurl,MRSproxyEnabled,Server

ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity}
ExternalUrl : https://hogehoge.com/ews/exchange.asmx
MRSProxyEnabled : True
Server : hoge

 

Set-WebServicesVirtualDirectory “EWS (Default Web Site)” -BasicAuthentication $true

ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
ExternalUrl : https://hogehoge.com/ews/exchange.asmx
MRSProxyEnabled : True
Server : hoge

あと、MRSHeathも実行してみるといいかも。

[PS] C:\Windows\system32>Test-MRSHealth

(省略)全部isValid Trueなら多分OK

さて、ここまでいろいろ切り分けして・・・

結局ユーザ名にはドメイン名は入れずに・・・

どーん!

はい。無事一つ移行が終わりました。

され、これ同期状態になったわけでですが、新しいメールはDNS切り替えまでこないから多少メールロストするかなぁと思ってたら・・・

新しいメールは、オンプレExchangeを通ってOffice365側に送られているみたいで、逆にオンプレのメールボックスには入りません。
※Office 365がクライアントになってメールをかっさらっていくイメージです。

ほうほう。それでハイブリッドなわけですね。

じゃぁ安心して重たいメールも移行していきますかー。

 

・・・。これ2−3メールボックスならPSTインポートしたほうが早くね・・・。

 

とりあえず、まだMXレコードは切り替えません&ログインのドメインが想定外になってたり、あと、結局ライセンスのシート数の数え方もわからないので。。。ってあれ、もうオンプレには新しいメール来ないのか。。。

まぁ考えます。結局間にExchangeサーバのWindows Updateが走ったりを除くと、ここまで8時間ほどかかりました。うへぇー。

 

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 2 – Exchange Server 2010 to Office 365(1)

ども。こんにちは。

早速行きましょう。

まずはオンプレExchange Server 2010をOffice 365 Business Essentialsへ移行します。

まずは、試用版のあるOffice 365 Business Premiumに登録します。

■サインイン

 

ええええーー。出鼻くじかれた。

お?イケてる?

んー。待てばいいのか?

30分ほど待ちましたが、なんにも起きず管理センターもこの状態・・・。

さて、どうしたものか。。。

しょうがないので改めてトライアルを追加してみる。

間にまたSMSでの認証がはいります。(省略)

即効ででてきた笑

とりあえずここまででサインインは完了かな?

この時点で「onmicrosoft.com」ではすでにメールが受信できました。

 

■Exchange Onlineの設定

設定を進めていきます。

今は試用版なのでアプリがでてるっぽいですが、迷わずExchange側の設定に進みます。
※購入するのはあくまでOffice 365 Business Essentialsなので。

この辺はサクッと

今回はDNSにTXTレコードを書く方法でやります。

以下CloudFlareの例です。

まぁサクッと終わりますね。

ここでは一旦ユーザ追加はしません。

お、移行の話になってきましたね。

もちろんExchangeで!

ハイブリッド構成ウィザードなるものを入れろと。

exeが降ってきたのでオンプレExchangeサーバにいれましょう。

・・・お?

話がそれますが、ここに来てうちの古いCentos 5がwindows.comとかマイクロソフト系の名前解決に軒並み失敗していることに気づいてしまいます。
(うちは大昔からの名残で、ActiveDirectory兼ExchangeサーバもBINDをDNSサーバとして向けています。愚の骨頂です。)

ただ、CentOS6のDNSサーバは問題なさそうでなので急遽AD兼ExchangeサーバのセカンダリDNSサーバにCentOS 6を設定。※ちなみにCentOS 5.11はbind-9.3.6-25.P1.el5_11.12でした。古!!!!

今更ながらKSKロールオーバーの影響じゃね?という気がしてきた。。。
今までも失敗してたけど、CentOS6側に問い合わせが流れて行ってたみたい。

FortiGateばっかり疑ってたわー。

2018年9月24日くらいからWindows Updateこけっぱなしで変だなぁとは思ってたけど。。。。

 

話がそれましたが、ちょっとWindowsUpateなので休憩。

次は移行から。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 1 – 全体方針

ども。こんんばんは。

今日から新元号「令和」となりましたね。

ということで、いい加減に我が家の老朽化したシステムたちを10連休後半で移行していきたいと思います。

  • 方針
    • クラウド移行対象
      • メール
        • 既存のExchange Server 2010をOffice365に移行する
      • ブログ
        • AWS EC2へ移行する
    • クラウド移行対象外
      • 監視サーバ(Zabbix)
      • ActiveDiretory
      • PBX(FreePBX)
      • ファイルサーバ
    • その他: NASもそろそろいい加減にリプレース
      • NASをリプレースし、移行しないオンプレシステムは原則コンテナで構築しなおし
        ADだけは、無線の802.1xなどもあるので、そのへんを鑑みて、AzureADで対応できるか今後調査。
        最悪FreeRADIUSとかをコンテナで・・。
      • ファイルサーバも廃止しNASのネイティブなSMB、CIFSなどに統合する
    • クラウド移行済み
      • 外部向けDNSサーバ
        • CloudFlareに移行済み

さて、それぞれですが、以下の理由により選定しました。

  • Office365:既存のExchangeからリプレースしやすそう。メールボックスはEACから移行できるっぽい。
  • AWS
    • 最初はAzure App ServiceもしくはAzureのVMを検討、ただAzureはまぁなんやかんや仕事でも使うので、あんまり触っていないAWSに挑戦してみることにする。
      すでにAzure上にはSentinelやVMが動いてるし。。
    • AWSだとLightsailがお得だと思うが、それならさくらとかのVPSとかと変わらない・・・と思うので、ちゃんとEC2を立ててみることにする。
    • GCPのAlways Freeも検討しましたが、割とチューニングしないと重くて動かなそうです。
    • その他wpXとか、mixhostとかも良さそうなんだけど、今回は勉強も兼ねてAWSですね。

ただ、ちょっと問題が早速ありそうで、macOSの標準メールだと、Exchange上の共有メールボックスがおそらく開けないと思われます。(IMAPなら行けるという記事も:APPLE MAILでOFFICE365の共有メールボックスの設定)
※WindowsのOutlookなら、それぞれのメールボックスに権限を付けるだけで勝手に見えるようになります。

過去、同じ問題に対処していますが、結局オンプレExchangeなのでボックスごとにユーザを割り当てて、複数アカウントを管理する形で逃げています

ところが今度はクラウドなのでそのやり方をすると、おそらくユーザが複数になるかと

参考:Macネタ – 2 –Macネタ – 4 –

Office 365 E1(¥870/ユーザ、アプリなし)か、Office 365 Business Premium(¥1,360/ユーザ、アプリあり)か悩みますね。

もちろんExhchage目当てにE1にするくらいなら、Buisiness Eessential(同じくExchangeくらい)で、もっと費用を落とす手もありますねぇ。

BusinessとEnterpriseうーん・・・

比較参照情報

うーーーーん。やっぱりデスクトップ版のoutlook必要かー?まぁメインのメールボックスさえ開ければあとはOWAでもいいかなぁ。

macOS標準メールでも行けそうなきがするなぁ

Adding Office 365 Shared Mailbox in Mac Mail

んーーー!!!

訴訟ホールドとかいらんし、300人超えることもありえなし、Buisines Essentialsでいいかな!

駄目だったらプラン変更すればいいし!どうせE3は変えないんだからビジネスでいいや!

ということで、次からメールの移行を始めたいと思います。

ではでは。またの機会に。