Get-AzureVMでout of range

2015/02/162015/02/17 / buchizo / コメントする

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

&gt; 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

Get-AzureVM : The DateTime represented by the string is out of range

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

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

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

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

D:\&gt; [System.DateTimeOffset]&quot;9999-12-31T23:59:59Z&quot;


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側で吐き出す値を修正したらしいです。とりあえず動作するようになりました。

Azure PowerShell 0.8.6 で認証ダイアログが組織アカウント優先になってる

2014/08/172014/08/17 / buchizo / コメントする

Azure PowerShell 0.8.6でMSアカウントと組織アカウントが同じメールアドレスの場合、Add-AzureAccountでMSアカウントのほうで認証しようとしても認証できないようです。

Azure PowerShellが新しくなって、Add-AzureAccountで組織アカウントを求められるようになったんだけど、今まで通りMicrosoftアカウントでログインすることはできないってこと！？ #azurejp #jazug
—
足利　惟 (@yuiashikaga) August 16, 2014

こまったちゃん。

0.8.5以前は以下のようにメアドいれると、それぞれ転送されててもしMSアカウントと組織アカウントがあるようだったら選択のダイアログが出ていました。

0.8.6だと組織アカウント優先のようで、

選択の余地なし。もしCookieだか何だかよくわからないけど以前に管理ポータル等にサインインしたときの情報が残っていればキャンセルボタンからMSアカウントなりへの選択画面にうつれるのですが、、、

先ほどの例みたいにキャンセルボタンもなければもうどうしようもなかったり。。。つらい。

一応、管理的にはAdd-AzureAccountを使わずにPublishSettingsファイルを使うとか（Import-AzurePublishSettingsFile）で管理はできそうですが。何のためのサインインダイアログなのだー

まぁ他にもCo-Adminするとかいろいろあるとは思いますが、なんだろう。パケットみるとちょっとだけOAuth2時のパラメータ違うのでその辺かなぁと思ってもどうしようもないですね。（AADのライブラリのバージョンによるのかな？謎）

とりあえずつたない英語でフィードバックだけはしておきました。

Azure PowerShell のあれこれ

2014/05/082014/05/10 / buchizo / コメントする

Azure PowerShellも日進月歩な感じである意味時代の最先端（未発表機能が追加されてたり）をイッてるツールなわけですが今日はその小ネタを。

証明書が無いとかなんとかエラーがウザイ

%userprofile%\AppData\Roaming\Windows Azure Powershell フォルダにいろいろあるので、バッサリ消して初期化しちゃいましょう。うん。

Import-AzurePublishSettingsFile とか面倒くさいしウザイ

最近のバージョンでは Add-AzureAccount すればフェデレーション認証な感じでMSアカウントで認証して必要な権限をゲットできます。ほとんどのコマンドはこれだけで済むのでむっちゃ便利です。

Import-AzurePublishSettingsFile も便利なんですが、こいつに渡すファイルを Get-AzurePublishSettingsFile とかで取得するとその都度証明書作られたりウザイ。というわけでステステ。

※とはいえスクリプト内で実行する場合などは必要になるので、適宜ちゃんと作成・管理しましょう。

Import-AzurePublishSettingsFile 使わないと Add-AzureVhd でエラーになるんじゃ

clientCert cannot be null とか言うやつですね。わかります。なぜかAdd-AzureVhdだけ特殊な気が。。。

面倒くさいので New-AzureStorageContainerSASToken とかでSASを取得してアップロード先のURLにつけるといいですよ。

$sas = Get-AzureStorageContainer -Container vhds | New-AzureStorageContainerSASToken -Permission rwdl -ExpiryTime (Get-Date).AddDay(5)
$dest = &quot;https://～～/vhds/test.vhd&quot; + $sas

Add-AzureVhd -LocalFilePath $vhd -Destination $dest

こんな感じで。SAS便利だね☆

(5/9追記）SASの有効期間が短くてUpload中にエラーになったりするので、-ExpireTimeで長めの有効期限を渡しておきましょう。（例だと5日間）

はぁー、暇になりたい。

PSSnapInを自作する

2013/02/16 / buchizo / コメントする

メモ程度。

1. Visual Studio 2012でクラスライブラリを作る

2. System.Management.Automation と System.Configuration.Install の2つのアセンブリを追加する。（※System.Management.Automation は C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0\System.Management.Automation.dll にあるはず）

3. プロジェクトのプロパティで「ビルド後に実行するコマンドライン」でinstallutil.exeを使ってアセンブリをアンインストールする

c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\installutil.exe $(TargetDir)$(TargetFileName)

※x64なアセンブリの場合はFramework64にしよう

※installutilを使ってインストールするので、Visual Studioは管理者権限で起動しておかないとうまくいかない（気がする）

4. デバッグ時に外部プログラムを開始するようにする

C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe

引数は以下のようにしてAdd-PSSnapInで読み込む

-noexit -command add-pssnapin buchizo.SnapinTest

5. SnapInクラスを継承したクラスを実装する

using System.ComponentModel;
using System.Management.Automation;

namespace buchizo.SnapInTest
{
	[RunInstaller(true)]
	public class buchizoSnapIn : PSSnapIn
    {
		public override string Description
		{
			get { return "test."; }
		}

		public override string Name
		{
			get { return "buchizo.SnapInTest"; }
		}

		public override string Vendor
		{
			get { return "buchizo"; }
		}
    }
}

RunInstaller(true)属性を忘れずに。

6. Cmdletクラスを継承してCmdletを実装する。

using System.Management.Automation;

namespace buchizo.SnapInTest
{
	[Cmdlet("Get", "Test")]
	public class GetTest : Cmdlet
	{
		protected override void ProcessRecord()
		{
			this.WriteObject("Test3");
		}
	}
}

細かいのはリファレンス参照で。

とりあえずこれで動く。デバッグ実行もOK