Exchange Web Services Managed API SDK を使ってみた

前回のエントリで試した PowerShell を利用した CUI での Exchange Server への疎通はうまくいかなかった。今回は Exchange Web Services Managed API SDK の利用を検討してみた。
Exchange Web Services Managed API SDKExchange Server 2007 SP1 以降で利用可能であり、開発者側で理解しやすい API を用いて Exchange Server 側の情報を容易に操作することができる。
以下の様の NuGET で取得が可能であるため、簡単に取得することができる。今回はこちらを利用してオンプレ向けの Exchange Server に疎通を取ってみる。

上記の通り、32bit 版と 64bit 版があるので留意が必要だ。

Exchange Web Services Managed API SDK を利用した疎通を実施

Exchange Web Services Managed API SDK は NuGet 経由で取得できるため、以下の画面を参考に「Exchange」の文字列で検索して Exchange Web Services Managed API SDK を取得してほしい。
f:id:waritohutsu:20140504161809p:plain

Exchange Web Services Managed API SDK のインストール後、以下のコードを記載して Exchange Server から予定を取得する。

using System;
using System.Linq;
using Microsoft.Exchange.WebServices.Data;

namespace ExchangeConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            // エンプラ向けに古いバージョンの Exchange Server を指定だが、用途に合わせてオプション指定
            ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2007_SP1);

            // EWS のレスポンス情報をログに出力
            service.TraceEnabled = true;
            service.TraceFlags = TraceFlags.All;

            // 環境によっては Autodiscover が無理だが、以下に Autodiscover を推奨する記載がある
            // http://msdn.microsoft.com/en-us/library/dn467891(v=exchg.150).aspx
            // service.AutodiscoverUrl("<ユーザ名>@<ドメイン>", RedirectionUrlValidationCallback);

            // Autodiscover を設定せず、直接 URI を指定する
            service.Url = new Uri(@"https://<Exchange Server アドレス>/EWS/Exchange.asmx");
            service.Credentials = new WebCredentials("<ユーザ名>@<ドメイン>", "<パスワード>");

            // 現在からひと月前~ひと月後を指定して予定を取得する
            var folder = CalendarFolder.Bind(service, WellKnownFolderName.Calendar);
            DateTime dtStart = DateTime.Today;
            dtStart = dtStart.AddMonths(-1);
            DateTime dtEnd = dtStart.AddMonths(1);
            var view = new CalendarView(dtStart, dtEnd);
            foreach (var appointment in folder.FindAppointments(view))
            {
                Console.WriteLine("---------------------");
                Console.WriteLine("Subject = {0}", appointment.Subject);
                Console.WriteLine("Start = {0}", appointment.Start);
                Console.WriteLine("End = {0}", appointment.End);
                Console.WriteLine("IsAllDayEvent = {0}", appointment.IsAllDayEvent);
                Console.WriteLine("IsReminderSet = {0}", appointment.IsReminderSet);
                if (appointment.IsReminderSet == true)
                {
                    // appointment.IsReminderSet == true の状態で参照しないとエラーが出る
                    Console.WriteLine("ReminderDueBy = {0}", appointment.ReminderDueBy);
                }
            }

            Console.WriteLine("!!!!!!!!! end !!!!!!");
            Console.ReadLine();
        }
    }
}

上記のコードにおける「service.TraceEnabled = true; service.TraceFlags = TraceFlags.All;」の指定により、以下のように Exchange Server とのやり取りがログとして出力される。
f:id:waritohutsu:20140504201755p:plain

さらに、標準出力には以下が出力され、無事に Exchange Server から予定が取得されていることが確認できる。
f:id:waritohutsu:20140504201618p:plain

2007以前の Exchange Server から予定をひっこ抜こうとした件

所用で 2007 以前の Exchange Server から予定をひっこ抜こうとしたのだが、疎通の時点で色々と問題があってうまくいかなかった。備忘録としてやったことを簡単にまとめておく。

実施した内容

まずは基本中の基本である以下 TechNet 記事を参照した。

上記は Exchange Online が適用先となっているが、一応オンプレの Exchange Server で出来るかためしたところ以下のエラーが出た。

SSL 証明書の失効チェックできませんでした。取り消しを確認するために使用するサーバーがアクセスできない可能性があります。

調べてみたところ、Windows 専用の Office 365 でのリモート PowerShell を使用して接続するときに、「SSL 証明書をチェックできませんでしたの失効」エラー に記載がある通り、オンプレ Exchange Server の様にインターネットアクセスを持たないために証明書の失効がチェックができない場合に発生するらしい。

次に、上記のオプションを考慮して以下の PowerShell コマンドを実行した。

# Exchange Server ログイン用の認証情報取得
$myCredential = Get-Credential

# オンプレ向けにインターネットへルート証明書の失効期限を聞きに行かないようにする
$sessionOption = New-PSSessionOption -SkipRevocationCheck

# オンプレ Exchange Server に接続しに行く
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://<サーバ名> -Credential $myCredential -Authentication Basic -AllowRedirection -SessionOption $sessionOption

が、以下のエラーが出てきて目頭が熱い気味。どうやら Exchange Server 側で WS-Management プロトコルを有効化する必要がある?らしい。

New-PSSession : [<サーバ名>] リモート サーバー <サーバ名> への接続に失敗し、次のエラー メッセージが返されました: WinRM クライアントは HTTP サーバーに要求を送信し、要求された HTTP URL が使用不能であるとい
う応答を受け取りました。 これは通常、WS-Management プロトコルをサポートしていない HTTP サーバーによって返されます。詳細については、about_Remote_Troubleshooting のヘルプ トピックを参照してください。
発生場所 行:1 文字:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri ht ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : URLNotAvailable,PSSessionOpenFailed

その他の方法は?

Exchange Server 2007 SP1 以降なら Microsoft Exchange Web Services Managed API が利用可能とのこと。以下の SDK を利用することで何とかなりそうだが、Exchange Server 2007以前では…orz

色々と操作されている情報が以下にあった。後で見よう
MS Exchangeからスケジュールを抜き出すんだぜ

Azure Automaiton を試してみる

2014年4月に開催された BUILD 2014 では様々な機能が追加されたが、ちょっとだけ触ってみた Azure Automation について記載してみる。現時点ではまだプレビュー機能なので、管理ポータルから Activate を実施する必要がある。Azure Automation の公式サイトは以下になるが、まだ情報は少ないようだ。。。

Azure Automaiton の概要

Azure Automaiton を利用することで、Microsoft Azure 上で PowerShellスクリプトを利用/組み合わせで様々な処理を実施することができる。こちらの Get started with Azure Automation にも記載されているが、Windows PowerShell Workflows としての利用ができるようだ。
後述するが、PowerShellスクリプトRunbook として登録して利用することから、どうやら System Center 2012 R2 Orchestrator の Microsoft Azure 版というのがイメージしやすそうだ*1

Get Started を試す

さっそく Get started with Azure Automation を参照しつつ試してみようと思う。
まずは Script Centor から、以下の Write-HelloWorld.ps1 をダウンロードする。

  • Write-HelloWorld.ps1
workflow Write-HelloWorld {
    param (
        [parameter(Mandatory=$false)]
        [String]$Name = "World"
    )
        Write-Output "Hello $Name"
}

次に、管理ポータルから Automation のアカウントを作成する。現在はプレビュー版であり「米国東部」しか選択できない点に注意してほしい。
f:id:waritohutsu:20140407041053j:plain

更に RUNBOOKS タブを選択し、IMPORT ボタンを押下して RUNBOOK 向けの *.ps1 ファイルを選択してアップロードする。
f:id:waritohutsu:20140407041106j:plain

IMPORT の完了後に登録した RUNBOOK を選択し、AUTHOR → DRAFT のタブを選択してスクリプトを PUBLISH する。
f:id:waritohutsu:20140407041241j:plain

PUBLISH の実施後、START を押下することで RUNBOOK が実行される。実行の結果は以下の様に確認できる。
f:id:waritohutsu:20140407041629j:plain

複数の RUNBOOK を実行する

上記で実施した Hello Worldスクリプトに続き、Script Centor のサンプルに登録された How to Invoke a Child Runbook を参照し、以下のスクリプトを作成した。こちらのスクリプトは Write-HelloWorld.ps1 を子供として呼び出すスクリプトになる。

workflow Invoke-ChildRunbookSample
{
    
    [OutputType( [object] )]
    param (
		# Variable
        [parameter(Mandatory=$true)]
        [String]$MyVariable
    )
    
    Write-HelloWorld -Name "Hello World を書いてみる"
    Write-HelloWorld -Name $MyVariable
}

上記のスクリプトを RUNBOOK として登録して PUBLISH の実施*2後、START を押下することで以下の様にログ出力されていることが確認できる。
f:id:waritohutsu:20140407041755j:plain

参考情報

*1:System Centor の OrchestratorRunbook デザイナー相当のものがまだ存在しないため、利用はハードルが高そうだ…

*2:または Asset に必ず登録する必要がある

JBoss AS 7.1.1 Final & WildFly のhttpポートを変更する方法

Azure の Webサイトで Java の APサーバを動作させる際、必要に駆られて調べたので簡単にメモ。JBoss AS は 7 以降から大きく構成が変わっており、以下のファイルに http ポートのポート番号が記載されている*1

  • %JBOSS_HOME%\standalone\configuration\standalone.xml
  • %WILDFLY_HOME%\standalone\configuration\standalone.xml

これら standalone.xml 等の変更方法については、以下の記事が参考になる。
http://duke4j.wordpress.com/2011/10/03/jboss-as-7-admin-guide-core-management-concepts-general-configuration-concepts/

JBoss AS 7.1.1 Final の http ポート番号を変更する場合

以下のファイルの一番下部に、http のポートが 8080 と直接記載されているのが確認できる。

  • %JBOSS_HOME%\standalone\configuration\standalone.xml
    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>

こちらを以下の様に編集する。

        <socket-binding name="http" port="${jboss.http.port:8080}"/>

後は以下のコマンドで起動すれば、JBoss AS 7.1.1 Final の起動ポートが 9090 になる。

C:\opt\jboss\jboss-as-7.1.1.Final\bin>standalone.bat -Djboss.http.port=9090

WildFly の http ポート番号を変更する場合

WildFly は最初から以下の記載となっているため、特に設定ファイルに修正は要らない。

  • %WILDFLY_HOME%\standalone\configuration\standalone.xml
    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
        <socket-binding name="http" port="${jboss.http.port:8080}"/>
        <socket-binding name="https" port="${jboss.https.port:8443}"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
</server>

後は以下のコマンドで起動すれば、WildFly の起動ポートが 9090 になる。

C:\opt\jboss\wildfly-8.0.0.Final\bin>standalone.bat -Djboss.http.port=9090

*1:といっても、こちらは standalone モードだけなので、domain モードを利用している場合は修正対象ファイルが異なる

2014年3月, 4月の JAZUG のイベント

Japan Windows Azure User Group が 2014年3月、4月に実施するイベントをまとめてみた。都合が合いそうな方(合わなくとも是非調整して)は是非参加してほしい!

3/29(土) Global Windows Azure Boot Camp 2014 in Japan!! at 品川

Global Windows Azure Bootcamp 2014 in Japan!! は、全世界で同一日に Windows Azure イベントの日本枠になる。Global Windows Azure Bootcamp を主催するスウェーデンからの Magnus氏 が来日する他、ブルガリアの Mihail 氏とも協力してブルガリアの Global Windows Azure Bootcamp とも内容を連携しあう。世界的なイベントになる!

4/12(土) JAZUG女子部 第6回勉強会 ~日本DCがやって来たヤァ!ヤァ!ヤァ! at 品川

Japan Windows Azure User Group 女子部 第6回勉強会が 4/12 に開催されます。 JAZUG女子部 第6回勉強会 ~日本DCがやって来たヤァ!ヤァ!ヤァ! から参加登録可能であり、Windows Azure の日本データセンタって何が美味しいの?、MS本社で新機能が多々発表される Build 2014 参加者の内容連携だったりと、内容盛りだくさんだ。

4/26(土) 第3回JAZUG静岡勉強会 at 浜松

JAZUG の静岡支部、第三回目の勉強会になる。第3回JAZUG静岡勉強会から参加登録可能だ。主催・運営メンバーはJAZUGのコアメンバなので運営クオリティは期待できるのはもちろんなので、内容は普段都内に出てくるのが難しい方は是非参加してほしい。
また、静岡の美味しい食べ物に興味のある方も参加してみても良いかも?

Windows Azure の Webサイトで Tomcat, Jetty の稼働をサポート!!!

さて、今回はWindows Azure アドベントカレンダー の15日目だが、ここで大きなニュースがある。
来た! Web サイトで Java が動く日がついに来たのだ! さあ皆、↓の画面を見るんだ!!
f:id:waritohutsu:20140315204517j:plain

上記の様に JDK 1.7 update 51 が選択可能で、ついでに Tomcat と Jetty が動くのが確認できる。今回はこのネタを話したいと思う。

Kudu を利用したフォルダ構成、環境変数の確認

次にちょっとフォルダ構成を確認するために、Kudu を利用したいと思う。Kudu を知らない人は、No.1 が詳しい記載のある Windows Azure Web Sitesの魅力を120%引き出す を確認してみよう!

一旦は Tomcat 側で設定した Web サイトを作成し、Web サイトに https://<サイト名>.scm.azurewebsites.net/ でアクセスして、構造を確認してみよう。Kudu の Debug Console を利用するこでフォルダ構成をチェックできる。Tomcat のインストールディレクトリを確認したところ、以下の様に D:\Program Files (x86)\ 以下に配置されている。

D:\Program Files (x86)\apache-tomcat-7.0.50>dir
Volume in drive D is Windows
Volume Serial Number is 6416-721C
Directory of D:\Program Files (x86)\apache-tomcat-7.0.50
03/11/2014 10:20 PM <DIR> .
03/11/2014 10:20 PM <DIR> ..
03/11/2014 10:20 PM <DIR> bin
03/11/2014 10:20 PM <DIR> conf
03/11/2014 10:20 PM <DIR> lib
03/11/2014 10:20 PM <DIR> logs
03/11/2014 10:20 PM <DIR> temp
03/11/2014 10:20 PM <DIR> webapps
03/11/2014 10:20 PM <DIR> work
03/11/2014 10:20 PM 57,862 LICENSE
03/11/2014 10:20 PM 1,228 NOTICE
03/11/2014 10:20 PM 9,258 RELEASE-NOTES
03/11/2014 10:20 PM 16,742 RUNNING.txt
4 File(s) 85,090 bytes
9 Dir(s) 9,324,318,720 bytes free

次に、war を配置する webapps の設定を確認するために conf/server.xml の中身の一部も確認してみる。

D:\Program Files (x86)\apache-tomcat-7.0.50\conf>cat server.xml 

<中略>

<Host name="localhost" appBase="d:\home\site\wwwroot\webapps" xmlBase="d:\home\site\wwwroot\"
unpackWARs="true" autoDeploy="true" workDir="${site.tempdir}">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="${site.logdir}"
prefix="site_access_log." suffix=".txt"
pattern="%h %l %u %t &quot;%r&quot; %s %b" />
</Host> 

以下の様に war を配置するフォルダは appBase="d:\home\site\wwwroot\webapps" で記載されている。どうやらここに war を配置すればよいのだと推察できる。次に d:\home\site\wwwroot\webapps を確認すると、ROOT フォルダが存在し、以下に一つだけ index.jsp ファイルが存在している。
f:id:waritohutsu:20140315204906j:plain

ここで http://<サイト名>.azurewebsites.net にアクセスすると以下の画面が表示され、Oracle JDK かつ GMT タイムゾーンであることが確認できる。
f:id:waritohutsu:20140315204947j:plain

次に、環境変数を確認する。ここでは JDK, Jetty, Tomcat 向けに設定された環境変数の情報が確認可能だ。
f:id:waritohutsu:20140315205001j:plain

自前アプリをデプロイ

Kudu さんの Debug Console からドラッグアンドドロップで HelloWorld.war を d:\home\site\wwwroot\webapps 以下に配置した後、https://<サイト名>.azurewebsites.net/HelloWorld にアクセスすると以下の様に自前で作成した HelloWorld.war が正しくデプロイしていることが確認できる。
f:id:waritohutsu:20140315205519j:plain

次に git clone を利用して Web サイトをクローンしたところ、d:\home\site\ から引っこ抜かれてしまったので、毎度 war を push する必要がありそうだ。この辺りは Eclipse からのデプロイ等の改善が期待されるところだ。

C:\xxxxxxxxxxxxx\ilovejava>dir /a
 ドライブ C のボリューム ラベルがありません。
 ボリューム シリアル番号は D461-5218 です

 C:\xxxxxxxxxxxxx\ilovejava のディレクトリ

2014/03/15  15:15    <DIR>          .
2014/03/15  15:15    <DIR>          ..
2014/03/15  19:28    <DIR>          .git
2014/03/15  15:15            65,954 hostingstart.html
2014/03/15  20:51    <DIR>          webapps

仮想ネットワーク上に作成する仮想マシンに対し、固定 IP アドレスを割り当て可能に

今まで仮想ネットワーク上に作成する仮想マシンIPアドレスは固定化できず、DHCPで割り振られる IP アドレスのみ利用可能でしたが、 PowerShell cmdlets for Windows Azure version 0.7.3 から IP アドレスが固定化できるようになった。
Windows Azure now allows to set fixed IP-addresses for virtual machines

PowerShell のコマンドから以下をたたくと、IPアドレス固定化に利用するためのコマンド(Set-AzureStaticVNetIP)が存在しているのが確認できる。

PS C:\> Get-Command *Azure*

f:id:waritohutsu:20140306005036j:plain

備考

DHCP で動的に割り当てられる IP は「10.x.x.4 ~ の 4から割り当てられる」や DNSサーバーの割り当ては固定化できる等の特性を考慮した工夫である程度対応できたが、PowerShell cmdlets for Windows Azure version 0.7.3 からは、仮想マシンに対して明示的に固定のIPアドレスをふれるようになった。
Set-AzureStaticVNetIP が利用できるようになる前の情報については、神ブログである SE の雑記 に記載されている AzureVM の DNS の設定についての注意点を参照のこと