プリンターやシステムのアラートメールなど、社内ネットワークからExchange Online上にあるユーザーのメールボックスにメールを送信するにはいくつか方法があります。
その中で一番設定が簡単で利用されるシーンも多いのが、MXレコードの向け先と同じ contoso-com.mail.protection.outlook.com などのアドレスにSMTP(TCP/25)で直接送信をする方式となります。
Office 365 を使って、多機能デバイスやアプリケーションがメールを送信するように設定する方法
このケースにおいて、稀にメールが受信できないという事象が発生することがあり、調査してみるとSMTPで送信をしようとした際に4xx番台のエラーが出て失敗したという物です。
Exchange Online と連携したアプリケーションを利用する際、アプリケーション偽装（ApplicationImpersonation）という特権（管理者権限）を利用するケースが多いです。
これを利用する事により、アプリケーションは自身の権限設定を利用して対象のユーザーになりすましてメールを取得したり、予定表を更新したりできます。
例えば、以下の様なことができます。
最近特にExchange Onlineと連携するアプリケーションやサービスが沢山出てきて、その中で利用されています。
今までと同じポリシーで利用したいということで、Exchange Online で IP アドレス制限を掛けたいという話は良く聞きます。これまでは、AD FSを利用したクレームルールを構成するか、Azure AD Premiumの条件付きアクセスの機能を利用する、あるいはサードパーティのツールを利用するなどして制御するしかありませんでした。
いずれも新規でサーバを立てるなり、追加でライセンスを購入するということでコストの掛かるソリューションでしたが、Exchange Onlineに実装された（現在、まだ全てのテナントで利用可能ではありませんが）クライアントアクセスルールを利用する事により、標準機能としてこれを実装できるようになりました。
Exchange Online のクライアント アクセス規則
また、この機能は現在 AD FS などを利用してIPアドレス制限を掛けている環境においても、その不足する部分を補完する存在になり得ますので、是非この機能は注目して頂ければと思います。
今回はちょっとトリッキーなTipsです。
色々なテナントをテストで利用していて、ふと「あれ、この独自ドメイン紐づけていたのどのテナントだっけ」となったり、「あの会社確かOffice 365使っていると言っていたけどテナント（xxx.onmicrosoft.com）どこだろう」…と調べたくなることがあると思います。
こういったときには、Exchangeの管理シェルからGet-FederationInformationコマンドで調べられます。Exchange Onlineに接続し、以下のコマンドを実行してみます。
[PS] C:\>(Get-FederationInformation -DomainName mirogo-shoji.com -BypassAdditionalDomainValidation).DomainNames Domain ------ mirogo.onmicrosoft.com mirogo-shoji.com
この例では、mirogo-shoji.com のドメインが紐づけられているテナントは mirogo.onmicrosoft.com だということが分かります。逆の場合（特定の xxx.onmicrosoft.com に紐づけられているのはどんな独自ドメインか）も同様のコマンドで調べられます。
なお、この例では Autodiscover のDNSをきちんとOffice 365用に設定していないと調べられません。
その場合は、ちょっと面倒ですが、Exchange Server（バージョンはいくつでも良いです）を1台立てて、そのサーバ上のHostsファイルに autodiscover.[調べたいドメイン名] を autodiscover.outlook.com のどれかのIP（例えば40.100.154.56）に向けるように設定して、コマンドを実行すれば大丈夫です。
この投稿は PowerShell Advent Calendar 2016 に参加しています。
Facebookでリスクエストを貰ったので、PowerShellから全社員のメールボックスに創立記念日の予定を入れるPowerShellを作ってみたいと思います。
Exchangeでは、各種管理用のPowerShellコマンドレットが用意されておりますが、各ユーザーのメールボックスのアイテムを直接操作するコマンドは基本的には有りません。
ただし、EWS(Exchange Web Services)というAPIが用意されておりますので、そちらを利用する事によりメールボックスにアプローチできます。また、その際にアプリケーション偽装(ApplicationImpersonation)権限を利用する事により、「そのユーザーに成り代わって」そのアイテムを利用できます。
今回は、目的が明確ですので一番近いサンプルスクリプトとして以下のstack overflowに回答例として提示されているスクリプトを元に、作成用のコマンドを作ってみます。
How to import meetings into office365 (EWS and Powershell?)
変更している所は赤字で記載します。
function Create-Appointment
{
[CmdletBinding()]
param(
[Parameter(Position=0, Mandatory=$true)] [string]$MailboxName,
[Parameter(Position=1, Mandatory=$true)] [string]$Subject,
[Parameter(Position=2, Mandatory=$true)] [DateTime]$Start,
[Parameter(Position=3, Mandatory=$true)] [DateTime]$End,
[Parameter(Position=4, Mandatory=$true)] [AllowEmptyString()] [string]$Location,
[Parameter(Position=5, Mandatory=$true)] [AllowEmptyString()] [string]$Body,
[Parameter(Position=6, Mandatory=$true)] [Boolean]$IsAllDayEvent,
[Parameter(Position=7, Mandatory=$true)] [PSCredential]$Credentials
)
Begin
{
$EWSDLL = (($(Get-ItemProperty -ErrorAction SilentlyContinue -Path Registry::$(Get-ChildItem -ErrorAction SilentlyContinue -Path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Web Services'|Sort-Object Name -Descending| Select-Object -First 1 -ExpandProperty Name)).'Install Directory') + "Microsoft.Exchange.WebServices.dll")
if (Test-Path $EWSDLL)
{
Import-Module $EWSDLL
}
else
{
"$(get-date -format yyyyMMddHHmmss):"
"This script requires the EWS Managed API 1.2 or later."
"Please download and install the current version of the EWS Managed API from"
"http://go.microsoft.com/fwlink/?LinkId=255472"
""
"Exiting Script."
exit
}
$ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($ExchangeVersion)
$creds = New-Object System.Net.NetworkCredential($Credentials.UserName.ToString(),$Credentials.GetNetworkCredential().password.ToString())
$service.Credentials = $creds
$Provider=New-Object Microsoft.CSharp.CSharpCodeProvider
$Compiler=$Provider.CreateCompiler()
$Params=New-Object System.CodeDom.Compiler.CompilerParameters
$Params.GenerateExecutable=$False
$Params.GenerateInMemory=$True
$Params.IncludeDebugInformation=$False
$Params.ReferencedAssemblies.Add("System.DLL") | Out-Null
$TASource=@'
namespace Local.ToolkitExtensions.Net.CertificatePolicy{
public class TrustAll : System.Net.ICertificatePolicy {
public TrustAll() {
}
public bool CheckValidationResult(System.Net.ServicePoint sp,
System.Security.Cryptography.X509Certificates.X509Certificate cert,
System.Net.WebRequest req, int problem) {
return true;
}
}
}
'@
$TAResults=$Provider.CompileAssemblyFromSource($Params,$TASource)
$TAAssembly=$TAResults.CompiledAssembly
$TrustAll=$TAAssembly.CreateInstance("Local.ToolkitExtensions.Net.CertificatePolicy.TrustAll")
[System.Net.ServicePointManager]::CertificatePolicy=$TrustAll
$service.AutodiscoverUrl($MailboxName,{$true})
#"Using CAS Server : " + $Service.url
$service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $MailboxName)
$folderid= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar,$MailboxName)
$Calendar = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$folderid)
$Appointment = New-Object Microsoft.Exchange.WebServices.Data.Appointment -ArgumentList $service
$Appointment.Start = $Start
$Appointment.End = $End
$Appointment.Subject = $Subject
$Appointment.Location = $Location
$Appointment.Body = $Body
$Appointment.IsAllDayEvent = $IsAllDayEvent
$Appointment.Save($Calendar.Id,[Microsoft.Exchange.WebServices.Data.SendInvitationsMode]::SendToNone)
}
}
New-ManagementRoleAssignment –Name:EWSCalendarApplication -Role:ApplicationImpersonation –User:ews_user
続いて、PowerShellを実行するコンピュータにEWS Managed APIをインストールします。
PowerShellを開き、上記コードを実行し、Create-AppointmentのFunctionを登録します。
最後に、以下のコマンドを実行します。最初の行では実行アカウントのID/PASSを入力します。
$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber
$results = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | select WindowsEmailAddress
foreach ($result in $results){
Create-Appointment -MailboxName $result.WindowsEmailAddress -Subject "創立記念日" -Start "2017/07/01" -End "2017/07/01" -Body $null -Location $null -IsAllDayEvent $true -Credential $LiveCred
}
これで、来年の7/1に終日イベントとして[創立記念日]が全ユーザーMBXに作成されます。
他にも、これを応用すれば会議室の利用状況を集計したり、役員の今日の予定の印刷用の元データを抜いたりできます。
また、このコマンドを行うには対象となるメールボックスが先に作成されている必要があります。メールボックスはNew-Mailboxコマンドなどで作成した時点では実体は作成されていません。ユーザー自身のログイン以外にも、以下の様な動作を行う事により作成されますので、エラーが出て登録出来ないメールボックスには試してみると良いでしょう。
Sonyから、待望のフラッグシップモデルのスマートフォンXperia Z4が発売されました。
今回は、スマートフォンを利用する上で一番よく利用すると思われるExchange Onlineの設定方法を紹介します。
Exchange Onlineに接続するには、標準の「Eメール」アプリケーションを利用します。[開始する]を選択すると、アカウントの設定画面が開きます。
ここで、Eメールアドレスとパスワードを入力します。
【注意】ここでは、[手動セットアップ]を選択します。
[次へ]を押して自動セットアップを行っても自動的にサーバ情報を取得してアカウントが設定できるのですが、IMAPを利用したプロファイルになってしまい、メールの送受信はできますが、それ以外の機能やサーバ側でのポリシー管理ができなくなってしまいます。
手動セットアップを選ぶと、アカウントの種類を選択する画面になります。ここれは、[Exchange ActiveSync]を選択します。
ドメイン\ユーザー名と表示されている部分は、\に続いて先ほど入力したメールアドレスの@の前の値が入っていますので、Office 365にログインする際に使っているUPN（ユーザー名＠ドメイン名）の形式のアカウント名を入れます。また、サーバは@の後の値が入っていますので、ここを手動で[outlook.office365.com]を入力します。入力が完了したら、[次へ]を押します。
スマートフォンの制御をアプリケーションに許可するので、[OK]をクリックします。
アカウントの基本設定を行います。プッシュ通知（常時接続）かつメモを除く全ての情報が同期されるように設定されてますので、必要に応じてこのデフォルトの値を変えます。
作成されたアカウントのプロファイルに識別用の名前を付けます。
最後に、Office 365のポリシーによって制御することのできる操作の権限の許可（いっぱい有ります）を確認して[有効にする]をクリックします。まあ、リモートワイプができるくらいなので基本は全ての制御権限をOffice 365に渡すと思った方が良いと思います。
これで設定は完了です。良いOffice 365ライフを！
全ユーザーの予定表の権限を変える場合、ユーザーの言語設定やOWAログオンの有無などによって、設定をするべきフォルダ名が username:\Calendar になったり username:\予定表 になったりします。
これって結構スクリプト化する上では悩みの種なんですよね。
仕方が無いので、[予定表]で設定できなければ[Calendar]だろうと決め打ちしてスクリプトを作ったりするケースがよく有ります。例えば、全ユーザーのCalendarもしくは予定表フォルダの権限をReviewerに変更する場合、
$mbxs = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
foreach ($mbx in $mbxs){
$alias = ${mbx}.alias
try{ Set-MailboxFolderPermission -Identity "${alias}:\予定表" -User "default" -AccessRights Reviewer -ErrorAction Stop }
catch { Set-MailboxFolderPermission -Identity "${alias}:\Calendar" -User "default" -AccessRights Reviewer -ErrorAction Stop }
}
とやったりしますが、微妙にこれでもエラーになってしまう場合が有って、例えば中国語など別の言語圏のフォルダ名になってしまっている場合や、フォルダ名の破損・重複などで[予定表1]などがデフォルトの予定表フォルダとして指定されてしまっている場合です。
中国語とかならともかく、[予定表1]とかはさすがに分からないですよね…。こういった場合、いくつか方法はありますが、私の場合は Get-MailboxFolderStatistics を利用します。これは、ルート以下のそれぞれのフォルダのアイテム数や格納サイズを出してくれる物ですが、この中に FolderType という属性があり、それが Calendar の物が予定表のフォルダ名です。
あとは、このIdentityの値が [ユーザ名\フォルダ名] の形式なので、Set-MailboxFolderPermissionの指定形式 [ユーザー名:\フォルダ名] に変換すれば大丈夫です。
$mbxs = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
foreach ($mbx in $mbxs){
$alias = ${mbx}.alias
$path = (Get-MailboxFolderStatistics $alias | ? {$_.FolderType -eq "Calendar"}).Identity -replace "\\",":\"
Set-MailboxFolderPermission -Identity $path -User "default" -AccessRights Reviewer
}
スクリプトを作っていく上では、「英語か日本語以外に設定している人がいないだろうから…」という思い込みで作るのでは無く、こうしたエラーを引き起こす原因となる例外の発生確率を少しでも減らす努力をしていくと、最終的に管理者の負担軽減に繋がるのではないかと思います。
注：この投稿は検証結果を元にした推測の部分を多大に含みます 今回は、Exchange Onlineのサーバ構成について考えてみたいと思います。
メールのヘッダには、様々な情報が付与されています。これを読み解くことによって、メールの送信遅延がどこで発生しているのか、どういうサーバを経由して届いたのかを調べることができます。
例えば、以前の記事 重複メッセージの除去（Exchange Online） で送信したテストメールを見ると、以下の様なReceivedヘッダが付与されています。
Received: from SG2PR03MB0537.apcprd03.prod.outlook.com (25.160.235.149) by SIXPR03MB0541.apcprd03.prod.outlook.com (25.160.173.25) with Microsoft SMTP Server (TLS) id 15.1.99.14 via Mailbox Transport; Sun, 8 Mar 2015 13:39:47 +0000 Received: from SIXPR03CA012.apcprd03.prod.outlook.com (10.141.119.22) by SG2PR03MB0537.apcprd03.prod.outlook.com (25.160.235.149) with Microsoft SMTP Server (TLS) id 15.1.106.15; Sun, 8 Mar 2015 13:39:46 +0000 Received: from DB3FFO11FD006.protection.gbl (2a01:111:f400:7e04::167) by SIXPR03CA012.outlook.office365.com (2a01:111:e400:a82b::22) with Microsoft SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Sun, 8 Mar 2015 13:39:46 +0000 Received: from xxxx.localdomain (xx.xx.xx.xx) by DB3FFO11FD006.mail.protection.outlook.com (10.47.216.95) with Microsoft SMTP Server id 15.1.112.13 via Frontend Transport; Sun, 8 Mar 2015 13:39:43 +0000
Receivedヘッダは、リレーされる度に下から上にだんだんと追加されていきます。Office 365の中では、主に以下の様な流れで記録されています。
まず、①では外部からMXレコードを引いた値でEOPに送信されます。これは、APACには限定されず、世界中のEOPで受信する形になるようです。今回はDB3～というホスト名で受信していますので、恐らくヨーロッパリージョンのダブリンのEOPで受け取ってからAPACに転送されているのだと思います。
Exchangeでは、外部からのメールはCAS（クライアントアクセスサーバ）で動作しているフロントエンドトランスポートが受ける形になります。直近数百通のメールを見る限りで、後述するDAGより大きな単位で束ねられたシンガポール・香港のCASサーバ群に負荷分散されて到着しているようです。ここはロードバランサーにより行われていると推測します。
次に、メールボックスの存在するDAG（データベース可用性グループ）に対してルーティングされます。DAGは、Exchange Server 2013と基本的なアーキテクチャが同じという前提であれば、最大16台のメールボックスサーバで構成されるクラスタサーバ群になります。同じく直近のメールのヘッダを追う限りでは香港①/香港②/シンガポール①/シンガポール②でそれぞれ4台ずつ構成されている様です。
最後にメールボックストランスポートから実際のメールボックスに対してメールが配信されます。メールボックスデータベースは、1つのActiveと複数のPassiveによって構成されていますが、メールボックストランスポートからは現在Activeとなっているメールボックスサーバにメールが配送されます。
これらをまとめると、以下の様なメールフローになります。CASのサーバ名は非常に数が多かったのでサンプルを、メールボックスサーバの中で実際に見つからなかったが、名前付けルールから推測したものを( )で表示しています。（※たまたま通らなかっただけかもしれませんし、故障やメンテナンスで切り離されていたのかもしれません。）
次に、 重複メッセージの除去（Exchange Online） で紹介している過去一定期間に受信したメールの重複チェック用のデータですが、これは各メールボックスストアごとに保存されており、メンテナンスや故障対応などのためにデータベースのActiveが別のサーバに切り替わるとリセットされます。
以下、3/4以降のメールについて、最後のReceivedヘッダの記録されているサーバ（つまり、メールボックスのストアされているサーバ）と時刻のリストです。24時間ではない間隔で来ているメールはそれぞれ短時間（数十分）の間SG2～→SIX～に切り替わり、切り戻りが発生しており、メンテナンスで同一データセンター内でActiveが切り替わったと推測されます。
Activeが切り替わった場合でも、OutlookからExchange Onlineへの接続は透過的に行われていますので、ユーザーが気づくことは少ないかと思われます。
サイト障害を考えると、シンガポール、香港ともに2つずつはメールボックスDBを配置するのが必要だと思いますので、HK2～、HKX～のどれかにもPassiveが存在しており、最低、平常時は1 Active – 3 Passive以上の冗長性は確保されているものと思われます。更に運用によって（すぐにオンラインに戻す必要はないと前提で運用設計する場合）はDC内に2つ以上のPassiveを構成している可能性もありますね。
また、これらのユーザーの所属するサーバ群はたまに変わるようです。 （私のメールボックスは、2/6のAM6:00-7:00頃に HK2PR03MB0833 から切り替わっています。）
これは、オンプレミスで利用するのと同じで、それぞれのユーザーの利用量や負荷についてはバラツキがあり、これを解消する為のリバランス処理や障害対応（主に、検索インデックス関係）が多いと思われます。
今回は、利用者側が便利、というよりは管理者よりの便利機能になりますが、誤送信対策を提供するアドインの紹介です。
そもそも、Exchange/Outlookは標準で誤送信対策に役立つ機能がいくつか備わってますが、それでは万全ではないと考える組織向けになります。欧米では免責事項を文末に付けておけば十分とされている部分も多大にありますが、日本は少し厳しめですね。
Office 365 に標準装備されている電子メールの誤送信防止機能 5 点
いくつか出てますが、今回は試用版がVectorからダウンロードできるWISE Alertを紹介します。
インストール自体は、インストーラーを実行すると簡単に完了します。
なお、Chromeからダウンロードしようとすると警告メッセージがでてしまうので、IEからダウンロードした方が良いかもしれません。
Wise Alertの基本機能は、①メール送信時の確認画面のポップアップ ②自動メール遅延送信の2つです。メールを送信すると、自分が送信しようとしたメールの宛先や添付ファイルに誤りが無いかどうかを確認する画面がポップアップします。
この画面の表示条件は設定により変更することができます。添付ファイルが有る場合、外部ユーザーが存在する場合など、比較的よく利用するパターンで条件付けをすることが可能です。
デフォルトでは10分の送信待ち時間が設定されていますが、その場合10分間はOutlookの「送信トレイ」に残っている状態になりますので、そこから削除や編集などをして取り消しすることができます。
他にも、有名どころではCipher Craft/Mail（Outlookアドインタイプ） などがありますが、企業情報を登録しないと試用版をお出しできないということで、こちらはまた機会があれば紹介させて頂きます。
前回の投稿に引き続き、Outlookを便利にするアドインを紹介させて頂きます。
Exchange Onlineは、マルチドメイン/マルチアドレスに対応しており、一人で複数のサブアドレスを持つことができます。ただし、これらは基本的に受信専用のアドレスであり、送信時に利用されるのはプライマリアドレスと呼ばれる代表アドレスのみになります。
これらを回避するため、配布グループや共有メールボックスなどを作成し、送信者アクセス権を割り当てることにより任意のアドレスから送信できるよう運用対処することがあるのですが、…正直面倒ですよね。
という訳で、それを解消するのがこのProxy Managerです。$29.99と有償の英語のソフトウェアですが直感的なインターフェイスですので恐らく誰でも利用できると思います。インストールはダウンロードしてきた.msiファイルを実行するのみで完了します。
インストール完了後にOutlookwp起動すると、 [Send Using Proxy Addresses]というプルダウンメニューが表示され、サブアドレス含めたアドレス一覧が表示されますので、ここで送信元として利用したいアドレスを選択します。
初回のみID/PASSを設定する画面が表示されますので、こちらにOffice365のID/PASSを入力します。また、Emailアドレスの前の表示名も変更したい場合はこちらの画面で[Names]を変更します。
到着したメールは、以下の様に送信者の部分に先ほどの電子メールアドレスと表示名が記載されています。また、購入前の場合はフッタに購入情報が記載されます。表示や操作について問題無いと確認してから、購入すれば良いと思います。
購入はメールのリンクから実施します。ライセンスキーが発行されたら、[Proxy Manager Options]の左下の[Register]ボタンから入力して完了です。
複数のユーザーやプロダクトを兼任している窓口業務などの返信用にお勧めいたします。