AzureのVNETとAWSをVyOSでつなぐ

なんとなくお蔵入りしてたネタを引っ張りだしてきました。

AzureのVNETと動的ゲートウェイと、AWS上のVyOSなVPNルーターを使ってVPN接続しようというネタです。出来上がる環境はこんな感じ。

image

IPアドレスとかは例です。あと数か月以上前のネタなのでちょっと変わってる箇所あるかも(VyOSのAMIのバージョンとか)しれませんが適宜読み替えてください。それから簡易な接続なので本運用とかには使わない方がいいかもですね。なんにせよ自己責任で。

続きを読む

Azure Update (2015.02.19)

はいはいUpdateですよー。

続きを読む

Get-AzureVMでout of range

なんかAzure PowerShellのGet-AzureVMとかGet-AzureDeploymentとかで得られる応答の一部要素(PersistentVMDowntimeのEndTime)でDateTime.MaxValueなISO8601形式の値(9999-12-31T23:59:59Z)が入ってるようで、こいつを日本みたいなUTCにプラスするタイムゾーン圏内でDateTime.Parseしようとして例外吐いてるみたいです。

> get-azurevm
get-azurevm : The DateTime represented by the string is out of range.
At line:1 char:1
+ get-azurevm
+ ~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureVM], FormatException
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.GetAzureVMCommand

仮想マシンをシャットダウンしたり再起動したりすると、EndTimeの値がまともな値になるのかちゃんと動作するようです。いやいや。。。

Management API側の挙動が変わったのかなー?(こんな値入ってたっけ?)という気がしますが、仮想マシンの再起動とかフザケンナという人はAzure PowerShellを実行するPCのタイムゾーンをUTCとかPSTにして凌ぎましょう。(なんとなくMSには報告済み)

DateTimeOffset使えば問題なさげだけど。

D:\> [System.DateTime]"9999-12-31T23:59:59Z"
Cannot convert value "9999-12-31T23:59:59Z" to type "System.DateTime". Error: "The DateTime repres ented by the string is out of range."
At line:1 char:1
+ [System.DateTime]"9999-12-31T23:59:59Z"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvalidCastParseTargetInvocationWithFormatProvider

D:\> [System.DateTimeOffset]"9999-12-31T23:59:59Z"


DateTime      : 9999/12/31 23:59:59
UtcDateTime   : 9999/12/31 23:59:59
LocalDateTime : 9999/12/31 23:59:59
Date          : 9999/12/31 0:00:00
Day           : 31
DayOfWeek     : Friday
DayOfYear     : 365
Hour          : 23
Millisecond   : 0
Minute        : 59
Month         : 12
Offset        : 00:00:00
Second        : 59
Ticks         : 3155378975990000000
UtcTicks      : 3155378975990000000
TimeOfDay     : 23:59:59
Year          : 9999

やれやれです。

2015.02.17 9:56 追記

Management REST API側で吐き出す値を修正したらしいです。とりあえず動作するようになりました。

同期環境下のOffice 365でExchange属性を弄りたい

あるよね。そういうこと。

オンプレに

  • Active Directoryドメインはある
  • Exchange Serverはない。過去も含めてない。
  • Active Directory SyncとかでOffice 365とアカウントを同期させてる

という環境があるとします。

※ちなみにオンプレ環境は全部Windows Server 2012 R2とします

で、ちょっとアドレス帳から非表示にしたいなーとか思うと

image

はい。ソウデスネ。

もちろんオンプレのADにはそんな(Exchange関連の)属性ありません。

image

どうしましょうか?素直なのは他の属性の値を使ってAADSyncとかのマッピングをいじることです。(ただこれも直感的に何をしてるのかわかりにくいのとSyncするツールに依存しちゃうのでどうなんだろう)
ということで今回は少し斜め上の対応をしてみましょう。

そう、Exchangeスキーマの拡張だけしてしまいましょう。

身もふたもない。

まず評価版のExchange Server 2013をダウンロードしましょう。

ダウンロードしたEXEを実行してファイルを展開します。その後以下のコマンドでSetup.exeを起動してスキーマ拡張だけ行います。(※もちろんバックアップとかその辺ちゃんと考えてください)

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

image

※細かい話はこの辺参照

完了後、スキーマが拡張されたので後はお好きにどうぞ。

image

image

やりました。

ASP.NET 5 (CTP5) のプロジェクトを Azure Websites で動かす

タイトルの通り。前回せっかくDocker on Ubuntu用に作ったのでそのままWebsitesで動かしたいと思います。

やり方は2通り。

  • Visual Studio 2015 (CTP5)から直接発行する
  • ASP.NET5 (CTP5)なソースがあるGit(GitHub)からソース連携して発行する

※Docker on Ubuntu用のproject.jsonなどは前回のPost参照で

結論から言うとVSからの直接発行は何の問題もなし。すんなり動作します。

でGit連携のほうはちょっとだけコツが必要。

How to

Websitesの構成でアプリケーション設定にSCM_KRE_VERSIONを追加し、CTP5用のバージョン(1.0.0-beta2)を指定します。

image

これだけ。

x64にしたりランタイム全部持ってくる場合とか用(?)にSCM_KRE_ARCHやSCM_KRE_CLRとかの引数もあります。VS2015でプロジェクトのプロパティみたときのTarget KRE Versionで指定するあれを分解した感じですね。

※SCM_KRE_VERSIONを指定しないとbeta1が使われてCTP5だと500エラーになります。

※デプロイは一応成功する

まぁそんなわけで、設定してあげてあとはGit連携すればちゃんと動作するようになります。

一応これでASP.NET5 CTP5をWindowsでもLinuxでもAzure Websitesでも動作させられるようになりましたね。理屈的にはMac OS上でも動作すると思いますが環境ないのでわかりません。

細かい話はきっとしばやん先生が解決してくれると思います。あとこちら参照。