しばたテックブログ

気分で書いている技術ブログです。

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の構成が上手くいったことが確認できます。

f:id:stknohg:20180717235804p:plain

f:id:stknohg:20180717235814p:plain

f:id:stknohg:20180717235831p:plain

f:id:stknohg:20180717235842p:plain

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

f:id:stknohg:20180717235923p:plain

【補足】DFSDsc

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

github.com

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

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

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

blog.shibata.tech

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

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

PowerShell 6.0がデフォルトに

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

f:id:stknohg:20180709170144p:plain

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

f:id:stknohg:20180709170156p:plain

の様に「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 CLIAzure PowerShellの二系統あり、両者の使い分けのためにAzure Cloud Shell(Bash)とAzure Cloud Shell(PowerShell)は分かれたまま残り続けるのかなと思っています。

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

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

Microsoft MVPアワードを再受賞しました

TwitterやFacebookでは先に報告させて頂きましたが、本日Microsoft MVP(Cloud and Datacenter Management)を再受賞することができました。
今回で3回目の受賞となります。

去年の活動

去年はほぼPowerShell一本に絞ったアウトプットをしており、このブログを中心に以下の様な活動をしてました。

実生活に無理のない範囲でまあまあのアウトプットができたかなと思っています。
特にコード量としては僅かですがPowerShell本体に直接貢献できたのは自分でも良かったなぁと思っています。
ただ、コミュニティの運営スタッフとしてはあまり主体的な活動ができておらず周りの負担を高めてしまっていたと反省しています。

今年の予定

基本的にはこのペースで変わらず活動していきたいと思っています。

人前で話すのが苦手なのでこれまで登壇は控えめにしていたのですが、今年はもう少し頑張ってみても良いかな、と。
あとコミュニティの裏方としてもう少しちゃんと働きます...

技術領域としては引き続きPowerShell中心となるでしょうがもう少し他の技術もネタとして拾っていきたい気持ちがあります。
というのも、このブログがPowerShell中心になった理由として私自身がPowerShellを学ぶためというのがあったのですが、自分の中でのPowerShellに対する疑問も結構消化できてきており、今の気持ちとしては、次の2つの疑問点

  • PSObjectとは何か?
  • パイプライン文の挙動

に対して自分なりを答えを出すことができれば一区切りつけても良いかなと思っているためです。

どちらもPowerShellのコア中のコアな部分であり非常に難しい問題であるため簡単には答えは出ないでしょう。
ですのでただちにPowerShellの情報発信を止めるというわけではないのでご安心?ください。

具体的にPowerShell以外のどの技術を深掘りしていくかは決めていないのですが、本ブログの説明文にある様に気分でやっていこうと思います。

最後に

若干とりとめのない感じになってしまいましたが引き続き情報発信していきますのでよろしくお願いします。