保護されているパーティションをPowerShellで削除する

小ネタおよび備忘録です。

手持ちのESXiをインストールしたUSBメモリをフォーマットし直そうとした際に、GUIからだと先頭のブートパーティションが削除できなかったのが発端です。

Diskpartで削除する

最初に参考情報としてDiskpartで削除する手順を紹介します。

nasunoblog.blogspot.com

Insider MVPの那須さんのブログに手順が詳しく記載されています。

こちらのケースではEFIシステムパーティションですが、保護されているパーティションを削除する場合はDiskpartコマンドを起動して該当のパーティションを選択したのち、

delete partition override

とoverrideを付けてdelete partitionしてやればOKです。

PowerShellで削除する

ここからが本題です。

PowerShellでこの様なパーティションを削除する場合はRemove-Partitionを使います。
先述のoverrideパラメーターの様な特殊なパラメーター指定は必要ありません。

実例

今回は下図のディスクを例に挙げます。

図のディスク2がESXiをインストールしていたUSBメモリで、先頭4MBがブートパーティションでGUIからは削除することができません。
(他にもいくつかパーティションがあったのですが、この図ではすでに削除済みです)

この4MBのパーティションをPowerShellを使って削除します。

1. 削除対象パーティンションの確認

はじめに管理者としてPowerShellを起動します。
Get-Diskコマンドを実行すると、システムから見えるディスクの一覧を取得できます。

Get-Disk

Get-Partitionコマンドでディスクにあるパーティションを取得できます。

Get-Partition -DiskNumber [該当ディスク番号]

この例だと、DiskNumber = 2、PartitionNumber = 1が対象のパーティションとなります。

2. パーティンションの削除

Get-Partitionコマンドの結果はWMIのMSFT_Partition*1クラスのオブジェクトであり、このオブジェクトをRemove-Partitionコマンドに引き渡すことでパーティションの削除ができます。

以下の様にパイプラインでつなげてやればOKです。

Get-Partition -DiskNumber [該当ディスク番号] -PartitionNumber [該当パーティション番号] | Remove-Partition

パイプラインを使わず直接DiskNumber、PartitionNumberを指定しても構いません。

Remove-Partition -DiskNumber [該当ディスク番号] -PartitionNumber [該当パーティション番号]

3. 結果の確認

これで保護されているパーティションを削除できます。

GUIから見ても確かに消えていることが確認できました。

*1:PowerShell上は Microsoft.Management.Infrastructure.CimInstance#ROOT/Microsoft/Windows/Storage/MSFT_Partition 型で表現される

PowerShellでDFSの環境を構築する

以前teratailのこちらの質問に回答した際に簡単な検証環境を作ったのですが、その手順を備忘録を兼ねてエントリとして公開します。

teratail.com

DFSの基本

本エントリではDFSの基本的なことについては触れません。
以下の記事が参考になりますのでご覧ください。

ascii.jp

www.atmarkit.co.jp

検証環境

名前空間サーバ(兼 ドメインコントローラー)1台、ターゲットサーバー1台のシンプルな環境を作ります。
OSはともにWindows Server 2012 R2、最新のWindows Updateと最低限のネットワーク設定が済んでいるところからスタートします。

設定項目	名前空間サーバ	ターゲットサーバー
OS	Windows Server 2012 R2	Windows Server 2012 R2
コンピューター名	ADSV	FLSV
ドメイン	corp.contoso.com	corp.contoso.com
利用ユーザー	administrator	administrator

DFSの環境を構築する

1. ドメイン構築

名前空間サーバーで以下のコマンドを実行し、ドメイン corp.contoso.com を作成します。

# マシン名変更
Rename-Computer ADSV -Restart

# (再起動後)ドメイン作成
Add-WindowsFeature AD-Domain-Services, GPMC, RSAT-ADDS, RSAT-AD-PowerShell
Import-Module ADDSDeployment
$Params = @{
    DomainName        = "corp.contoso.com";
    DomainNetbiosName = "CONTOSO";
    ForestMode        = "Win2012R2";
    DomainMode        = "Win2012R2";
    DatabasePath      = "C:\Windows\NTDS";
    LogPath           = "C:\Windows\NTDS";
    SysvolPath        = "C:\Windows\SYSVOL";
    SafeModeAdministratorPassword = (Get-Credential);  # 接続情報
    InstallDns           = $true;
    CreateDnsDelegation  = $false;
    NoRebootOnCompletion = $false;
    Confirm = $false;
}
Install-ADDSForest @Params

2. ターゲットサーバーのドメイン参加

ターゲットサーバーをcorp.contoso.comドメインに参加させます。

# マシン名変更
Rename-Computer FLSV -Restart

# (再起動後)ドメイン参加
Add-Computer -DomainName corp.contoso.com -Restart

3. DFSの設定

名前空間サーバで以下のコマンドを実行してDFSの設定を行います。
最初にDFSの構成に必要な機能をインストールします。

# 機能のインストール
Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, RSAT-DFS-Mgmt-Con

続けてDFSルートを作ります。
名前空間サーバー上にある共有フォルダに対してNew-DfsnRootコマンドを実行してやります。

以下の例では最初にC:\DFSRoots\Publicに共有フォルダPublicを作成し、DFSルート\\corp.contoso.com\Publicを割り当てています。

# DFS設定(名前空間の作成)
$DFSRootPath = '\\corp.contoso.com\Public'
$DFSRootTarget = 'C:\DFSRoots\Public'
$DFSRootSharedPath = "\\$(hostname)\Public"
# 先に共有フォルダを作る
mkdir $DFSRootTarget
New-SmbShare –Name 'Public' –Path $DFSRootTarget -FullAccess everyone
# DFSルート作成
New-DfsnRoot -Path $DFSRootPath -Type DomainV2 -TargetPath $DFSRootSharedPath

DFSルートを作成した次はフォルダターゲットを作成します。
フォルダターゲットにはターゲットサーバー上の共有フォルダが必要なのでInvoke-Commandを使ってリモートから共有フォルダを作成してやります。

以下の例ではターゲットサーバーのC:\DFSTargets\Shareに共有フォルダShareを作成します。
接続情報は適宜設定してください。

# DFSターゲットの設定(共有フォルダの作成)
$DFSTargetHost = 'FLSV'
$DFSTargetCredential = Get-Credential # 接続情報
Invoke-Command -ComputerName $DFSTargetHost -Credential $DFSTargetCredential -ScriptBlock {
    $targetLocalPath = 'C:\DFSTargets\Share'
    mkdir $targetLocalPath
    New-SmbShare –Name 'Share' –Path $targetLocalPath -FullAccess everyone
}

最後にNew-DfsnFolderを使ってこの共有フォルダをDFSフォルダにします。

# フォルダターゲットの作成
$DFSFolderPath = '\\corp.contoso.com\Public\Share'
$DFSFolderTargetPath = "\\$($DFSTargetHost)\Share"
New-DfsnFolder -Path $DFSFolderPath -TargetPath $DFSFolderTargetPath

結果確認

ここまでの結果「DFSの管理」からは以下の様に見え、DFSの構成が上手くいったことが確認できます。

フォルダへのアクセスも良い感じにできています。

【補足】DFSDsc

今回は触れませんでしたが、DFSを構築するためのDSC Resourceも当然存在しています。

github.com

このサンプルコードが今回の構成に近いので参考にしてみてください。

Azure Cloud Shell(PowerShell)がLinuxコンテナになりました。

先週の話*1なのですが、以前、

blog.shibata.tech

でお伝えした様にWindows Serverコンテナで動作しているAzure Cloud Shell(PowerShell)がLinuxコンテナ上で動作する様になりました。

中の人のツイートがこちら。

#PowerShell in Azure #Cloud #Shell is now running PowerShell Core 6 in a Linux container! Read about the new experience here: https://t.co/nrwYkt3FRI pic.twitter.com/hh1wxJYlH1

— Danny Maertens (@maertend33) July 3, 2018

PowerShell 6.0がデフォルトに

新しいAzure Cloud Shell(PowerShell)を起動すると下図の様になり、Linux(Ubuntu)上でPowerShell Core 6.0がデフォルトで起動する様になっています。

ちなみに今回試すにあたりCloud Shellを作り直したのですが、最初の画面が

の様に「PowerShell(Linux)」と変わっていました。

Azure Cloud Shell(Bash)との違い

Azure Cloud Shell(Bash)とAzure Cloud Shell(PowerShell)は同一OS上で動くことになったわけですが、おそらく、同一のコンテナイメージを使っています。

公式な情報は無くコンテナ内を調べてもズバリな情報を見つけることができなかったのですが、両コンテナで/var/log/dpkg.logが完全に一致しており、ここから間接的ではありますが同一イメージだと推測できます。
(さすがに別イメージならdpkg.logは一致しないでしょう...他にコンテナの同一性を調べる良い方法があれば教えて欲しいです...)

このためAzure Cloud Shell(Bash)とAzure Cloud Shell(PowerShell)の違いはログインシェルだけになります。

Azure Cloud Shell(PowerShell)のこれから？

Azure Cloud Shell(PowerShell)が今後どうなるかについては未だ公式なアナウンスはありません。

Azure Cloud Shell(Bash)でもPowerShell Coreは利用できますので、いまとなっては、Azure Cloud Shell(PowerShell)の存在意義は

「ログインシェルをPowerShellにしたい。」

位しか無い様に思えます。
PowerShellが大好きな私から見ても

「これいる？Bashでログインして pwsh って4文字打てば良いだけでは？」

というのが正直な気持ちです。

ここからは完全に私見ですが、現在Azureを管理するためのコマンドはAzure CLIとAzure PowerShellの二系統あり、両者の使い分けのためにAzure Cloud Shell(Bash)とAzure Cloud Shell(PowerShell)は分かれたまま残り続けるのかなと思っています。

実際にどうなっていくかは今後の情報を追っていきたい感じです。

*1:ちょっとプライベートが忙しくブログを書き上げるのが遅くなってしまいました...