Merge pull request #374 from ShuheiUda/master

Add archive articles

articles/archive/azure-lb-pre-warming-and-monitoring.md

@@ -58,4 +58,4 @@ https://channel9.msdn.com/Events/de-code/2016/INF-001
 ロードバランサーからみて、バックエンドの何台が生きていて、何台が死んでいるかは、Azure Load Balancer のログ機能でご確認いただくことも可能です。本機能は現在プレビュー中のため、内部ロードバランサー (ILB) については対応していないなど、一部制限がございます。以下ドキュメントをあわせてご確認ください。
 
 * Azure Load Balancer のログ分析 (プレビュー)
-https://docs.microsoft.com/ja-jp/azure/load-balancer/load-balancer-monitor-log
+https://docs.microsoft.com/ja-jp/azure/load-balancer/load-balancer-monitor-log

articles/archive/azure-vm-arm-nic-change.md

@@ -0,0 +1,70 @@
+---
+title: Azure VM (ARM) の NIC 差し替えについて
+date: 2016-09-14 16:11:16
+tags:
+ - Archive
+ - Network
+ - NIC
+---
+> [!WARNING]
+> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。**
+
+Azure サポートの宇田です。今回は ARM の Azure VM で、NIC を差し替える方法についてご紹介します。
+
+[先日の記事](https://jpaztech.github.io/blog/archive/static-mac-address/)でもご紹介した通り、2016 年 8 月上旬より、Azure VM を割り当て解除にしても MAC アドレスが変更されないように動作が改善されました。これによって、いわゆる[ゴースト NIC が増える問題](https://jpaztech.github.io/blog/archive/delete-nic/)が解決されましたが、一方で VM 内で誤ってネットワーク周りの設定を変更してしまい、RDP 接続ができなくなった場合に、割り当て解除や再デプロイで対処を行うことが出来なくなっています。こうした場合には NIC を入れ替える方法が有効ですので、以下の方法で対処ください。
+
+## 事前準備
+
+NIC の差し替えはポータルから行うことが出来ませんので、Azure PowerShell から実施します。
+
+このため、お手元に Azure PowerShell が利用できる環境をご用意ください。([設定方法](https://learn.microsoft.com/ja-jp/powershell/azure/install-azure-powershell))
+
+## NIC の差し替え
+
+<pre># 設定項目
+
+$VmName = "<仮想マシン名>"
+$ResourceGroupName = "<リソース グループ名>"
+$VirtualNetworkName = "<仮想ネットワーク名>"
+$SubnetName = "<サブネット名>"
+$Location = "<リージョン名>"
+$OldNicName = "<既存の NIC 名>"
+$NewNicName = "<新規作成する NIC 名>"
+$NewPublicIpAddressName = "<新規作成する Public IP 名>"
+
+# 差し替える NIC (+ Public IP) を新規で作成
+$VirtualNetwork = Get-AzureRmVirtualNetwork -Name $VirtualNetworkName -ResourceGroupName $ResourceGroupName
+$Subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name $SubnetName -VirtualNetwork $VirtualNetwork
+$NewPublicIpAddress = New-AzureRmPublicIpAddress -Name $NewPublicIpAddressName -ResourceGroupName $ResourceGroupName -Location $Location -AllocationMethod Dynamic
+$NewNic = New-AzureRmNetworkInterface -Name $NewNicName -ResourceGroupName $ResourceGroupName -Location $Location -Subnet $Subnet -PublicIpAddress $NewPublicIpAddress
+
+# 新規 NIC を追加
+$VM = Get-AzureRmVM -Name $VmName -ResourceGroupName $ResourceGroupName
+Add-AzureRmVMNetworkInterface -VM $VM -NetworkInterface $NewNic
+
+# 既存 NIC を削除
+$OldNic = Get-AzureRmNetworkInterface -Name $OldNicName -ResourceGroupName $ResourceGroupName
+Remove-AzureRmVMNetworkInterface -VM $VM -NetworkInterfaceIDs $OldNic.Id
+
+# NIC の変更を適用 (再起動が発生します)
+Update-AzureRmVM -VM $VM -ResourceGroupName $ResourceGroupName</pre>
+
+## 留意事項
+
+ご利用の仮想マシンの構成によってさまざま異なりますが、以下のような点にご留意ください。
+
+* NIC の差し替えに伴い、VM の再起動が発生します
+* パブリック IP アドレスを新規作成するため、IP アドレスが変更されます
+* 既存の NIC 設定は引き継がれません
+(NSG の設定や ロードバランサー配下への追加等は別途実施ください)
+
+~~また、今回と同様の手法で NIC の追加や削除のみを行うこともできますが、Azure VM ではシングル NIC とマルチ NIC の行き来が出来ません。(1 枚 ⇔ 2 枚 は不可、2 枚 ⇔ 3 枚以上は可)~~
+
+~~* 複数 NIC を持つ VM の作成 – 制限事項~~
+~~https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-multiple-nics/#制限事項~~
+> ~~単一 NIC の VM をデプロイ後に、複数 NIC で構成することはできません (その逆の場合も構成できません)。構成するには、VM を削除してから、再作成する必要があります。~~
+
+**2017/12/13 追記**
+現在は、仮想マシンを停止した状態であればシングル NIC とマルチ NIC の行き来も可能となっております。(ただし、NIC を 0 枚にすることは出来ません。)
+
+以上、ご参考になれば幸いです。

articles/archive/azure-vm-may-fail-to-activate-over-expressroute.md

@@ -0,0 +1,96 @@
+---
+title: ExpressRoute 環境でライセンス認証ができない事象について
+date: 2016-05-16 16:07:44
+tags:
+ - Archive
+ - Network
+ - ExpressRoute
+---
+> [!WARNING]
+> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。**
+
+こんにちは。Azure サポートの宇田です。
+
+今回は ExpressRoute を利用している環境で、Azure VM でライセンス認証に失敗するという事象についてご紹介します。
+
+## 概要
+
+ExpressRoute を利用する環境では、デフォルト ルートを ExpressRoute に向ける、いわゆる強制トンネリング (Forced Tunneling) と呼ばれる仕組みを使用して、Azure 仮想ネットワークからのパケットを強制的にオンプレミス側へとルーティングすることができます。強制トンネリングが有効な環境では、インターネットへ出る通信は、オンプレミスのネットワークを経由して出ていきますが、Azure VM における Windows のライセンス認証で使用される KMS サーバーは、Azure 内からの通信しか受け付けません。こうした理由により、KMS サーバーとの通信が確立できず、ライセンス認証に失敗します。
+
+![](./azure-vm-may-fail-to-activate-over-expressroute/PrivatePeering.png)
+
+こうした現象が発生しないようにするためには、以下の UDR による対処が必要です。
+
+また、Windows のライセンス認証のほかにも、RHEL や SUSE の更新サーバーに接続できないといった現象も、同様の理由により発生します。いずれの場合についても、関連が疑われる場合は、下記の通りルーティングの見直しなど検討頂ければと思います。
+
+## 対処策: ユーザー定義ルート (UDR) を設定する
+
+ユーザー定義ルート (UDR) 機能を使い明示的に KMS サーバー向けのルーティングを設定することでも、対処が可能です。KMS サーバーの IP アドレス (kms.core.windows.net: 23.102.135.246) に対し、Azure PowerShell にて以下の手順でルーティングの設定を実行ください。これにより KMS サーバーへの通信を強制トンネリングの対象から除外し、直接インターネット経由で通信させ、認証が成功するように構成できます。
+
+~~※ KMS サーバーの IP アドレスは、現時点で変更の予定はありませんが、将来変更される可能性があります。~~
+
+![](./azure-vm-may-fail-to-activate-over-expressroute/UDR.png)
+
+### クラシック (ASM) 環境の場合
+
+<pre># 新規でルート テーブルを作成します
+New-AzureRouteTable -Name "<ルート テーブル名>" -Label "<ルート テーブルの説明>" -Location "<リージョン名>"
+
+# 作成したルート テーブルの情報を取得します
+$rt = Get-AzureRouteTable -Name "<ルート テーブル名>"
+
+# ルートを定義します
+Set-AzureRoute -RouteTable $rt -RouteName "<ルート名>" -AddressPrefix "23.102.135.246/32" -NextHopType Internet
+Set-AzureRoute -RouteTable $rt -RouteName "<ルート名>" -AddressPrefix "20.118.99.224/32" -NextHopType Internet
+Set-AzureRoute -RouteTable $rt -RouteName "<ルート名>" -AddressPrefix "40.83.235.53/32" -NextHopType Internet
+
+# 上記で定義したルートをサブネットに対して適用します
+Set-AzureSubnetRouteTable -VirtualNetworkName "<仮想ネットワーク名>" -SubnetName "<サブネット名>" -RouteTableName "<ルート テーブル名>"</pre>
+
+### リソース マネージャー (ARM) 環境の場合
+
+<pre># 仮想ネットワークの情報を取得します
+$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName "<VNET のリソース グループ名>" -Name "<VNET 名>"
+
+# 新規でルート テーブルを作成し、ルートを定義します
+$RouteTable = New-AzureRmRouteTable -Name "<ルート テーブル名>" -ResourceGroupName "<ルート テーブルのリソース グループ名>" -Location "<リージョン>"
+Add-AzureRmRouteConfig -Name "<追加するルート名>" -AddressPrefix 23.102.135.246/32 -NextHopType Internet -RouteTable $RouteTable
+Add-AzureRmRouteConfig -Name "<追加するルート名>" -AddressPrefix 20.118.99.224/32 -NextHopType Internet -RouteTable $RouteTable
+Add-AzureRmRouteConfig -Name "<追加するルート名>" -AddressPrefix 40.83.235.53/32 -NextHopType Internet -RouteTable $RouteTable
+Set-AzureRmRouteTable -RouteTable $RouteTable
+
+# 上記で定義したルートをサブネットに対して適用します
+$forcedTunnelVNet = $vnet.Subnets | ? Name -eq "<設定対象のサブネット名>"
+$forcedTunnelVNet.RouteTable = $RouteTable
+Set-AzureRmVirtualNetwork -VirtualNetwork $vnet</pre>
+
+**2022/07/26 追記**
+以下でアナウンスされた通り、新たに azkms.core.windows.net という KMS サーバーが追加されています。また、既存の kms.core.windows.net の IP アドレスが 2023/03/01 までに変更される予定です。そのため、UDR では 23.102.135.246 のほかに 20.118.99.224、40.83.235.53 のルートも追加で設定が必要となりましたのでご注意ください。
+
+* 一般提供:Azure Global Cloud の新しい KMS DNS
+https://azure.microsoft.com/ja-jp/updates/new-kms-dns-in-azure-global-cloud/
+
+**2022/07/26 追記ここまで**
+
+## 参考リンク
+
+本投稿は以下のブログをもとに、一部内容を追記してご紹介しています。
+
+* Azure VM may fail to activate over ExpressRoute
+https://blogs.msdn.microsoft.com/mast/2015/12/01/azure-vm-may-fail-to-activate-over-expressroute/
+
+また、2015 年 12 月以前に作成した Windows Server 2012 R2 に限って、以下の事象も報告されています。あわせてご参照ください。
+
+* Azure 環境に展開される Windows Server 2012 R2 のライセンス認証ができない
+https://blogs.technet.microsoft.com/askcorejp/2015/12/08/azure-windows-server-2012-r2/
+
+この他、ExpressRoute 環境に限らず、 Firewall 等の機能において送信ポート 1688 を制限されている場合も、ライセンス認証に失敗します。こちらのポートについては、Firewall 等にて拒否しないようにご留意ください。
+
+**2016/10/31 追記**
+**現在、NSG で TCP 1688 の通信を制限した場合に、意図せずライセンス認証ができなくなることを避けるため、Azure 基盤側で明示的に通信が許可されるように機能改善が行われました。(OS が持つ Firewall 機能など、NSG 以外で TCP 1688 を制限された場合は、引き続きライセンス認証に失敗いたしますので、その点はご留意ください。)**
+
+* ネットワーク セキュリティ グループ (NSG) について
+https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-nsg/(抜粋)
+ライセンス (キー管理サービス): VM で実行される Windows イメージには、ライセンスを適用する必要があります。ライセンスを適用するために、そのような問い合わせを処理するキー管理サービスのホスト サーバーには要求が送信されます。この要求は、ポート 1688 を通じて送信されます。
+
+**2016/10/31 追記ここまで**