Azure Scheduler 向け、新しい Powershell コマンドレット

2016年8月16日 [Azure Scheduler gets new PowerShell cmdlets] 粗訳

Azure PowerShell 2.0.1 を利用することで、Powershell を使って、Azure Resource Manager 内のジョブコレション・ジョブを管理できます。

このアップデートにには以下のコマンドレットが含まれます:

Get-AzureRmSchedulerJobCollection

Get-AzureRmSchedulerJob

Get-AzureRmSchedulerJobHistory

New-AzureRmSchedulerJobCollection

New-AzureRmSchedulerHttpJob

New-AzureRmSchedulerServiceBusQueueJob

New-AzureRmSchedulerServiceBusTopicJob

New-AzureRmSchedulerStorageQueueJob

Remove-AzureRmSchedulerJobCollection

Remove-AzureRmSchedulerJob

Set-AzureRmSchedulerJobCollection

Set-AzureRmSchedulerHttpJob

Set-AzureRmSchedulerServiceBusQueueJob

Set-AzureRmSchedulerServiceBusTopicJob

Set-AzureRmSchedulerStorageQueueJob

インストール方法についての詳細は、Azure PowerShell のインストールおよび構成方法をご覧ください。

今回のアップデートに関する詳細は、migration guide (英語)をご覧ください。

広告

Azure Automation Hybrid Runbook Worker のプロキシ環境サポート

2016年8月16日 [Azure Automation Hybrid Runbook Worker supports proxy environments] 粗訳

最新の Azure Automation Hybrid Runbook Worker では、プロキシーサーバーを経由した、ワーカー間の通信をサポートしました。これは、PowerShell、および、グラフィカル runbook に適用されます。

利用中の Microsoft Monitoring Agent のバージョンが最新版かどうかは、、 %ProgramFiles%\Microsoft Monitoring Agent\Agent\AzureAutomation\7.2.11136.0 のサブフォルダーとの一致で確認できます。この機能を利用するには、プロキシーとファイアーウォールの設定のためのドキュメントをご覧ください。

Azure DevTest Lab:1つのラボ内での多くの仮想マシンの実行

2016年8月15日 [Azure DevTest Labs: More running VMs are supported in a single lab] 粗訳

Azure DevTest Lab は、仮想マシンが作成されるストレージアカウントが自動的に拡張されるようになり、(その複数のストレージアカウントを利用して)、一つのラボの中に、より多くの仮想マシンを同時に実行できるようになりました。

従来は、異なったストレージアカウントのカスタムイメージ (VHD) から仮想マシンが作成される際、単一のストレージアカウントから他のストレージアカウントにカスタムイメージをコピーする時のパフォーマンスの問題のため、それぞれのラボには、仮想マシン向けに一つのストレージアカウントしか保持できませんでした。しかし、Azure のストレージアカウントは、仮想マシンディスク数に制限があります(「Azure サブスクリプションとサービスの制限、クォータ、制約」の仮想マシン ディスクの制限をご覧ください)。仮想マシンのディスク利用状況を考慮すると、スタンダードレベルの仮想マシンの場合、40ディスクが上限となります。プレミアムストレージアカウントの場合、約25ディスクが最大値となります。、多くの仮想マシンを必要とする規模の大きい開発チームにとっては、これらの限界が、DevTest Labの機能の制限になっていました。

この問題を解決するため、DevTest Lab は、ラボ内にすでに作成した仮想マシンの数を元に、自動的に新しいストレージアカウントを作成するようになり、IOPSを最適化するよう、異なったストレージアカウント間で、新しい仮想マシンのバランスをとります。カスタムイメージの作成後、すべてのストレージアカウントで、カスタムイメージがキャッシュされ、新しく仮想マシンを作成する際のパフォーマンス低下が発生することが無くなります。

今すぐお試しいただき、感想をおきかせください。改善するアイディアをお持ちのかたは、Azure DevTest Labs feedback forum (英語)よりフィードバックください。

ご質問は、MSDN Community forum (英語)をご覧いただくか、新しく質問を投稿してください。

App Service での Azure AD B2C サポートの改善

2016年8月15日 [Improved support for Azure AD B2C in App Service] 粗訳

最新のサービスアップデートにて、Azure App Service での、 Azure Active Directory (Azure AD) B2C サポートの改善をおこないました。アップデートには、web apps での機能拡張も含まれますが、最も重要なのは、Mobile Apps、API Apps、Function Apps での、Azure AD B2C の完全なサポートの追加です。特に、Easy Auth Token Refresh API (英語)のサポートが追加されました。加えて、Login APIは更新され、引数として、特定のAzure AD B2C のポリシーの指定をサポートしました。モバイルアプリ開発者は、これらの改善により、Azure AD B2C を使ったアプリケーション開発がより簡単になります。

これらの改善の詳細、サンプルコード、Azure AD B2CをつかったWeb Apps のデモについては、ブログ投稿(英語) をご覧ください。

より簡単な Mobile Apps Quickstart のご紹介

2016年8月12日 [Introducing a quicker Mobile Apps Quickstart] 粗訳

Azure App Service の Mobile Apps 機能を利用する従来の手順は、とても時間のかかることでした。モバイルアプリケーション作成以前に、Azure SQL Database サーバーとデータベースの作成を行い、その2つへのリンクを作成し、コードをデプロイして、それから、やっと、モバイルクライアントの作成にとりかかることができました。どんなに短くても、それには15分程度かかりました。本日、Mobile Apps Quickstart (英語)を利用した、新しいモバイルバックエンドの作成方法をご紹介します。

Mobile Apps Quickstart は、事前に構成されたモバイルバックエンドで、開発環境・モバイルバックエンドの学習に最適化されています。それは、データストレージとして、SQLite データベースを利用するモバイルバックエンドを提供します。それは、既存のデータベースとのリンクを作成することなく、すぐに開発を開始できることを意味します。Easy Table、Easy API、認証、通知など、SQL Database インスタンスに依存しない機能も引き続き利用できます。

詳細については、この新機能の告知ブログポスト(英語)をご覧ください。

Site Recovery での VMware 向け Linux サポートの改善と、その他拡張

2016年8月12日 [Improved Linux support for VMware and other Site Recovery enhancements] 粗訳

最新リリースの Azure Site Recovery では、Linux サポートの強化と、その他、回復性の拡張が加えられています。

Site Recovery 利用者は、以下のバージョンのLinux で VMware上で動作している仮想マシンを Azure 上で保護できます。

  • Red Hat Enterprise Linux 7.1
  • Red Hat Enterprise Linux 7.2
  • CentOS 7.0
  • CentOS 7.1
  • CentOS 7.2

すでに Site Recovery でサポートされている Linux のバージョンに、上記バージョンが追加され、Site Recovery をご利用されているすべて方がご利用いただけます。

また、Amazon Web Services (AWS)上で動作している Linux インスタンスの Azure へのマイグレーションのサポートも追加しました。現在、AWS からマイグレーションできる Linux のバージョンは、Red Hat Enterprise Linux 6.7 HVM イメージに限定されます。

また、ファイルオーバーオペレーションの堅牢性を改善し、トラブルシューティングを容易にするために機能強化しました。機能強化の一つは、Azure Resource Manager のコンピュートインスタンスへ、ファイルオーバーする仮想マシンの起動時診断がデフォルトでオンになっていることです。

北ヨーロッパ・カナダ中部リージョンにて、Azure Automation が利用可能に

2016年8月12日 [Azure Automation available in North Europe and Canada Central regions] 粗訳

北ヨーロッパ、および、カナダ中部リージョンにて、Azure Automation が利用可能になりました。このリージョンの追加により、より良い場所での Automation アカウントの利用が可能となります。

Azure上、オンプレミス上、サードパーティクラウド上にあるリソースの作成、監視、デプロイ、メンテナンスを、高い可用性と信頼性で、DSC(Desired state configuration)エンジンを利用できる、Azure Automation にて行えます。

試用や利用開始については、Azure Automation の概要をご覧ください。

Log Analytics への runbook のジョブステータス・ジョブストリームの送信

2016年8月12日 [Send runbook job status and job streams from Automation to Log Analytics] 粗訳

runbookの ジョブステータス・ジョブストリームを Azure Automation から Azure  Log Analytics (Operations Management Suite)  ワークスペースに送信できるようになりました。この利用シナリオ例は以下の通りです:

  • Automation ジョブ上のインサイトの取得
  • runbook ジョブステータス(失敗、中断)をトリガーにしたメール送信やアラート
  • ジョブストリームをまたいだクエリーの作成
  • 過去のジョブ履歴の可視化

ログを Log Analytics に送信開始したのち、Automation ログに対し、クエリーが記述できるようになり、アラートを設定できます。以下がログを利用し、可視化するクエリーのサンプルです:

  • 失敗もしくは中断したジョブ: Category=JobLogs (ResultType=Failed || ResultType=Suspended)
  • エラーストリームジョブ (ジョブIDごと): Category=JobStreams StreamType_s=Error | measure count() by JobId_g
  • 特定ジョブ向けジョブストリームの調査: Category=JobStreams JobId_g=”INSERT RUNBOOK JOB ID HERE” | sort TimeGenerated | select ResultDescription
  • 実行したジョブの履歴: Category=JobLogs NOT(ResultType=”Started”) | measure Count() by ResultType interval 1day

Log Analytics への Automation ログの送信について学習するには、Forward job status and job streams from Automation to Log Analytics (OMS) (英語)をご覧ください。

その他情報については以下をご覧ください。