Exchangeのメールボックスは昔は「一番最初にアクセスしたクライアントやプログラム等の言語」によって言語が決定される…という動きだったと思うのですが、Exchange Onlineになって、どうやらユーザーの言語設定に応じてメールボックスのフォルダ名の言語が変化する仕様になった模様ですね。 とりあえず全部日本語にしちゃいたければ下記のようにしてしまえば良いです。実行環境はAzure CloudShellで大丈夫です。
シリーズ記事の11個目です。M365フルクラウド環境を検証目的で構築しています。下記の記事も合わせてどうぞ！ Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators- Azure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administrators- M365 E5検証ライセンスを申し込む【M365フルクラウド環境検証 その3】 | Microsoft Cloud Administrators- Intuneへの登録を行う【M365フルクラウド環境検証 その4】 | Microsoft Cloud Administrators- Windows10のデバイス構成プロファイルを作成して割り当てる！BitLockerでディスク暗号化【M365フルクラウド環境検証 その5】 | Microsoft Cloud Administrators- コンプライアンスポリシーを作成して割り当てる！【M365フルクラウド環境検証 その6】 | Microsoft Cloud Administrators- 「条件付きアクセス」で「ベースラインポリシー」を設定する！【M365フルクラウド環境検証 その7】 | Microsoft Cloud Administrators- 条件付きアクセスポリシーを設定してMFAとポリシー準拠デバイスを必須とする！【M365フルクラウド環境検証 その8】 | Microsoft Cloud Administrators- Microsoft Defender ATPを実装する！【M365フルクラウド環境検証 その9】 | Microsoft Cloud Administrators- Office Pro PlusをIntuneから配布する！【M365フルクラウド検証環境 その10】 | Microsoft Cloud Administrators ここまで触れていなかったのですが、読者の方から「Exchange Onlineで使うドメインの設定はどうなっているか?既存のメールシステムとの関係はどうなっているのか？」という質問を頂きました。ここまでの記事の内容と同じことを自分の環境で行ったときに、メール配送はどうなっているのか?という話ですね。 というわけで今回はExchange Online側の話を少し確認します。 Exchange Onlineの「ドメイン」設定 下記の図はAzure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administratorsの記事の操作でAADにドメインを追加し、規定のドメインとしたときの、Exchange管理センターの状態です。 ...
複数の人から「自分自身からメールが届いた、乗っ取られてしまっているのだろうか？」という話をもらいましたので、「そうではないですよ」ということを動画で実際に実演もしながら解説してみました。 今回のネタは動画のほうが伝わりやすいかな？と思って動画にしてみましたが、文章のほうがサクッとすばやくポイントできますので、要点は以下に。 認証なしでメールを送信することができる(※認証が必要なケースもありますが歴史的にみても認証なしのほうが大部分です。)- 「送信者」の設定は単に文字列で指定するだけでありいくらでも自由に設定できる。- 心配だったらメールヘッダで送信元を確認できる 実際のやり方は動画を参照してみてください。 最近ちょっと時間的な余裕ができたことやYoutubeでのライブ配信のやり方を覚えたこともあり、リアルタイムに質問を受けながらそれに回答するようなこともできると嬉しいなと考えています。「それだったらこういうテーマの話をしてほしい」などあれば、コメント、Twitter等でリクエストもらえると嬉しいです。
決してパスワードを生でコードに記載することはおすすめするものではないのですが、Exchange OnlineへのPowerShell接続ができなくて苦労している方をサポートする機会があったのでその際に作成したスクリプトを共有します。…といっても超簡単なものですが。 ドキュメントに書いてあるものそのままなので特に内容に関しては言及することもないのですが、今回の場合 - ドキュメントどおりに実行している - IDもパスワードも何度も確認した - 複数の端末でも実行した - ネットワークも複数切り替えた という切り分けを行っており、それでもうまく接続できない、という状況でした。 そこで、私がIDとパスワードを教えてもらってドキュメントどおりに試してみるとあっさりと接続できてしまう状況でした。 この場合 - なにかしらのドキュメントにも書かれていない超基本的な部分での前提条件の見落としがある - ドキュメントどおりに実行しているつもりができていない ID,Passwordのうち間違え - ドキュメントのスクリプトのコピーミス(ボタンもありますが…) - などなど - その他のなにか というくらいの可能性があるわけですが、1なのか、2なのか判別をつけることが重要だと考えました。なので、ドキュメントにかかれていることを全て単一のスクリプトに落とし、全く同じものを実行するだけで同じ結果が得られる状態にして1なのか2なのかの切り分けをするということに主眼をおきました。ですので、IDもパスワードも生で書き込んでそのままスクリプトを渡し、実行してもらいました。(※これでもまだPowerShellを管理者で実行しなくてはいけないとか色々ありますが、コンセプトとして。) 結果、今回の場合はスクリプトの実行では接続に成功しました。ですのでどこかはわからないですが、「2. ドキュメントどおりに実行しているつもりができていない」だったのだろうという事になりました。 これ、PowerShellスクリプトに完全に落とし込む手法じゃなかったらどれだけ丁寧に手順書が書かれていても手順書通りに実行されないリスクがあるんですよね。その点で完全にコードに落とし込んで確認できることは素敵だなと思うのです。 今回の例に限ったことではなく、可能であれば「コード」でのやり取りをインフラの管理者もするようにすると、コミュニケーションコストが低くなるケースはかなりあると思っています。もちろんInfrastructure as Codeという話もあるのですが、日常のオペレーションに関しても、です。 特にクラウドの時代になってほぼ全てのものがコードで表現できるようになりました。コードでなるべく表現することをベースにしていくことの価値や実現性は昔とは比べ物にならないです。個人的には、自分が行う作業は全てコード化するくらいの気持ちでいます。わたしの場合すぐに忘れてしまうので備忘録代わりでもあります。
皆さんこんにちは。胡田です。相当久しぶりにブログを書いています。 この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) これで、目的を達成することができました。
Microsoft Ignite 2016にてアナウンスがあったものをまとめます。随時更新します。 Security関連 Windows Defender Application Guard Introducing Windows Defender Application Guard for Microsoft Edge | Microsoft Edge Dev Blog Windows 10上のMicrosoft Edgeブラウザを更にセキュアにする機構 Windowsカーネルよりも下位レベルで分離した環境でEdgeを実行 通常のユーザー領域へのアクセスができあい環境でEdgeが動いているため、脆弱性があっても攻撃を防ぐことが可能 Insiderへは来月あたり、広くは来年に提供予定とのこと - Windows Defender Advanced Threat ProtectionとOffice 365 Advanced Threat Protectionの連動 Windows 10上で検出された脅威とOffice 365上で検出された脅威とを連動して調査、対処していくことが可能となる。 - Office 365 Advanced Threat Protection Word, Excel, PowerPoint, SharePoint Online, OneDrive for Businessへの拡張 Dynamic Delivery 添付ファイルがスキャン中のタイミングでもメールを先行して配信。添付ファイルの部分はプレースホルダーの形。 - URL detonation 未知の悪意あるURLをリアルタイムで分析 - Office 365 Threat Intelligence 攻撃に対応してアラートおよび情報を提供し、SIEMシステムと統合可能とすることで脅威にたいしての動的なポリシー設定を可能とする。 - Outlook for iOS, Outlook for AndroidのExchange Onlineメールボックスのネイティブサポート。 Office 365外でのデータキャシュが不必要となり、企業利用にさらに適切となった。 - Enterprise Mobility + Security E5 2016年10月１日からの提供。 Microsoft Advanced Threat Analytics (ATA) Microsoft Cloud App Security Azure Information Protection Azure Active Directory Identity Protection 概要紹介動画 An Introduction to Microsoft Azure Information Protection - YouTube - Azure Active Directory Privileged Identity Management Intune Mobile App Management (MAM) - Secure Productive Enterprise 2016年10月１日からの提供。 Windows 10, Office 365, Enterprise Mobility + Securityが含まれる。 ...
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 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 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 ...
日々徒然さんで、Exchange Onlineの新機能としてアドレス一覧の機能が実装されるという事が紹介されていました。 【新機能】アドレス帳のカスタマイズ « 日々徒然 新しい機能が追加、公開されていくこと自体は素晴らしい事だと思うのですが、はっきり言って「まだこのレベルでは大企業では使えないな」という気持ちが強まるばかりです。アドレス一覧の機能はオンプレミスではExchange Server 2000の頃からある機能で、それでも機能が足りないから・・・ということでやっと階層型アドレス帳が一般的に使えるようになってきたところですので…。 オンプレミスとOffice365。Office365は急速に機能拡張してきてはいますが、まだまだ(日本の?)要求が厳しいお客様への提案は難しいかなと思います。
Exchange Team Blogにて以下のエントリが公開されています。 Recipient Rate Limit Increase to 10K for Office 365 and Exchange Online - Exchange Team Blog - Site Home - TechNet Blogs 要点は以下です。 - 今までは1ユーザーが1日あたり1500のアドレスにしか送信できなかった。(※配布グループは1アドレスとカウント) - これからは1日あたり1万アドレスに上限を緩和する。 - 大量の顧客に個別にニュースレターを送信する……というようなケースではOffice365, Exchange Onlineは使えない。 このあたり上限が増えたとはいえ、顧客の業種によってはOffice365, Exchange Onlineだけで全ての業務をまかなえない例として常に注意する必要がありますね。 ちなみにオンプレミスではこの制限は当てはまりません。オンプレミスでも制限したい場合にはThrottlingPolicyで制御する事になります。 Does exchange 2010 sp2 (RU2) has a Recipient rate limit ?
かなり久しぶりに自宅に仕事を持ち帰ってしまいました。Office365のExchange Online周りのトラブル対応のスクリプトを書いたり動作確認したりするためにRemote PowerShellで接続しようとした所エラーが…。 New-PSSession : [ps.outlook.com] リモート サーバー ps.outlook.com への接続に失敗し、次のエラー メッセージが返されました WinRM は処理を完了できません。 指定したコンピューター名が有効であること、コンピューターにネットワーク経由でアクセスで きること、および WinRM サービスのファイアウォールの例外が有効になっていてこのコンピューターからアクセスできることを確認 してください。 既定では、パブリック プロファイルの WinRM ファイウォールの例外によって、同一のローカル サブネット内のリ モート コンピューターへのアクセスは制限されます。詳細については、about_Remote_Troubleshooting のヘルプ トピックを参照し てください。 発生場所 行:1 文字:16 $O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUr … CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionOpenFailed ネットワーク的にはきちんとInternetに接続できてますし、IEでもきちんと外部サイトが見られる状態。Proxyは無し。Windowsファイアウォールも無効の状態でした。なぜなのかわからずTwitterでつぶやいていたら@genkiwさんにポイントを教えてもらえました。ありがとうございました！ @ebi 接続先はポータルでしょうか、Exchange Onlineでしょうか？ Proxyの設定（IEとwinhttp）とかサインインモジュールが古いとか、 Set-ExecutionPolicy RemoteSignedが実施されてないとか。 — 渡辺 元気さん (@genkiw) 11月 7, 2012 結局、WinHttpの設定がproxyを使用する設定のままになっており、proxyが無い環境なのでps.outlook.comに到達できない状態でした。 Vista以降ではコマンドプロンプトにて「netsh winhttp show proxy」にて現在の設定の表示、「netsh winhttp import proxy ie」にてIEからの設定の取り込みが可能です。これできちんと接続できるようになりました。接続方法はこちら。 ...