PowerShell でドメインユーザー連続作成 ~ While 編 ~

前回は、CSV ファイルから任意の位置(列,行)の情報を読み込むところまでやりました。

今回はその「」がテーマです。

” ($L[0]).name ” の [0] の部分が「行」を表すわけですが、これを 0 -> 1 -> 2 とカウントアップさせながら、同じ処理(ドメインユーザー作成)を繰り返し行わせる方法を解説します。

 

 

まず、パラメーター(変数)として扱う「行」を、「$C」とします。

最初に ” $C = 0 ” と定めておけば、 ” ($L[$C]).name ” の結果として「aaa」を得る事が出来ます。

 

 

次に、$C をカウントアップ(処理を 1 回行うごとに、1 ずつ増加)させながら繰り返し処理するために、While ステートメントを用います。

基本構文は「 While  (繰り返す条件)  {繰り返し実行したいコマンドレット}  」です。

 

 

(繰り返す条件) は、今回の場合「$C が 2 以下の場合」となります。

つまり、CSV ファイルのユーザーリストを 1 行目 -> 2 行目 -> 3 行目 と順に読み込んで処理し、処理するたびにカウントアップした $C が「3」に達したらそれ以降は処理せず、終了します。

これは、” ($C -le 2) “ と記述します。

あるいは、「$C が  3 より小さい場合」を意味する ” ($C -lt 3) ” でも同様の結果となります。

 

 

次に {繰り返し実行したいコマンドレット} ですが、ここは二段構成となります。

一つ目は、本来の目的である「ドメインユーザーの作成」です。これについては次回以降詳述します。

二つ目が、「$C のカウントアップ」です。こちらは、” $C++ “ ないし” $C = $C+1 “ と記述します。

これにより、ドメインユーザーを一人作り終えた直後に「$C」がカウントアップされるため、次の処理ではCSV ファイルの一つ下の行のデータが読み込まれます。

 

 

これまでのところをまとめると、こうなります。

$L = import-csv samplelist.csv

$C = 0

while ($C -le 2)

{

<ドメインユーザー作成コマンドレット>

$C++

}

 

 

続く

PowerShell でドメインユーザー連続作成 ~ CSV 編 ~

CSV 形式のユーザーリストを元に、PowerShell を用い、Active Directory に複数のユーザーを一度に作成する方法を考えてみました。

なお、全ての操作は、ドメインコントローラー・メンバーサーバーともに Windows Server 2008 R2 SP1 の環境で行っています。

 

 

この作業のためには、PowerShell の3つの機能を組み合わせます。

[1]   CSV 形式のファイルから、指定した位置 (列,行) の情報を読み込む

[2]   [1] で読み込んだ情報を使い、ドメインユーザーを作成する

[3]   CSV の最終行まで、[1],[2] の作業を順番に繰り返す

 

 

第一回の今回は、[1] について記述します。(次回はいったん [3] に飛び、最後に [2] をやる予定です。)

 

 

まず、作成する 3 ユーザーの名前とパスワードのリスト「samplelist.csv」を、下記のように記述します。

※ 先頭行はフィールド名のため、全 4 行となります。

——–<ココカラ>——–

name,password

aaa,bbb

123,456

大畑,fk-01g

——–<ココマデ>——–

 

 

PowerShell で CSV ファイルを読み込む場合、import-csv コマンドレットを用います。

CSV ファイルがカレントディレクトリにある場合は、” import-csv  samplelist.csv “ です。

しかし・・・

CSV ファイルを日本語版 Windows の「メモ帳」で作成していた場合、保存時の文字コードは既定で Shift-JIS であるため、PowerShell 上では「大畑」の二文字が文字化けしてしまいます。

この現象は、ファイルを保存する際に文字コードとして Unicode を選択することで回避可能です。

あるいは、 ” get-content samplelist.csv > unicode.csv ” といったコマンドレットにより、Unicode 形式の別ファイルに変換することも可能です。

 

 

リストの中身全体を正しく読み込めたところで、次は列と行を指定して特定のデータを読み取ります。

まず、リスト全体を読み込むコマンドレットを、変数「$L」として扱えるようにします。

” $L = import-csv  samplelist.csv “

こうすることで、” $L “ を実行するだけでリストの中身を読み込めるようになります。

 

 

それから、name 列 のデータ部 1 行目、つまり「aaa」だけを抽出します。

これは ” ($L[0]).name “ で出来ます。

どうやら、データ部の 1 行目を、PowerShell 的には「0」行目として扱っているようなので、” ($L[1]).name ” だと、結果は「123」になってしまいます。

大畑氏のパスワードを表示するには、” ($L[2]).password ” です。

 

 

続く

Start Screen Layout

Windows Server 2012 R2 (preview版) から新たに追加されたグループポリシー「Start Screen Layout」を設定してみました。

「コンピューターの構成」と「ユーザーの構成」の両方において、

「ポリシー」 => 「管理用テンプレート」  => 「タスクバーと[スタート]メニュー」  

の中に有ります。

※ローカルグループポリシーでも、ポリシーという階層が無いこと以外は同じです。

 

 

対象は Windows 8.1 以降なので、残念ながら Windows 8 に適用しても意味は無いのですが、 そう言われればやってみたくなるのが人情というもの。

ドメインコントローラーとして構築した Windows Server 2012 R2 の「ユーザーの構成」側でこのグループポリシーを有効化し、ドメインのメンバーである Windows 8 に適用させてみました。そして結果を確認するため、Windows 8 側で “rsop” コマンドにより「ポリシーの結果セット」を開きます。

すると、思った通り「管理用テンプレート」の中に「タスクバーと[スタート]メニュー」は無く、「レジストリの追加設定」がありました。これは、自身に存在しないグループポリシーが適用された場合の表示です。

そしてその中身も「Start Screen lauout」ではなく、一つのレジストリキー配下の二つのレジストリ値となっています。

[レジストリキー]

HKEY_CURRENT_USER¥Software¥Policies¥Microsoft¥Windows¥Explorer

[レジストリ値]

–  LockedStartLayout (REG_DWORD)  “1”

–  StartLayoutFile (REG_SZ)  “(空欄)” 

 

 

このレジストリキーは、デフォルトの状態では Windows 8.1 にも存在しないものです。このグループポリシーが適用されることで、始めて作成されます。

二つ目のレジストリ値が 空欄 なのは、グループポリシーの設定時に入力していなかったためです。このグループポリシーは有効にするだけでは意味が無く、レイアウトを定義する XML ファイルのパスを入力してやる必要があるのです。

 

 

XML ファイルを自分で書かないと駄目なのか・・・ と早とちりして挫折しかけましたが、グループポリシーの説明文(英語)をちゃんと読んでみると、PowerShell でエクスポート出来ることが分かりました。

Windows 8.1 ないし Windows Server 2012 R2 (ドメインコントローラーである必要はありません。)で雛形となるレイアウトを作っておき、そのコンピューターの powerShell で

export-startlayout -path layout.xml -as xml

というコマンドレットを実行します。これにより、現在のレイアウトを記述したXMLファイルがカレントディレクトリに作成されます。

 

 

このコマンドレットについては、早くも TechNet に解説が載っていました。

■ Start Screen Cmdlets in Windows PowerShell

http://technet.microsoft.com/library/dn283399(v=wps.630).aspx

※このページに載っているコマンドレットは、どれも PowerShell4.0 でしか使えないようです。

 

 

このXMLファイルをネットワーク上の共有フォルダに置いておき、そのパスをグループポリシーとして設定してやることで、適用先のドメインユーザーのスタート画面を統一出来るようです。

当然、ドメインユーザーはその共有フォルダへのアクセス権を持つ必要があると思われるのですが、今回の検証ではその手順は省いてちょっとズルしました。

グループポリシーが適用された Windows 8.1 のローカルディスク上に、Windows Server 2012 R2 にてエクスポートしたXMLファイルをコピーします。それからレジストリエディタを開き、上記「二つ目のレジストリ値」に直接そのファイルパスを書き込みます。

そうしてサインアウト&再サインインしたところ、スタート画面に元々あった「カレンダー」や「天気」等のタイルが ほとんど無くなり、Windows Server 2012 R2 のスタート画面が再現されました。

正確に言うと、「サーバーマネージャー」と「管理ツール」が欠けた状態です。サーバーマネージャーは元々サーバーOSにしか無いものなので当然なのですが、管理ツールまで無いのは不思議です。

 

 

XMLファイルをブラウザやメモ帳で開いてみると分かりますが、個々のアプリケーションは「AppID」という識別子により記述されています。

コンピューターにインストールされている各アプリケーションのAppIDは、powerShell の “get-startapps | fl“ というコマンドレットで確認出来るのですが、Windows 8.1 で実行してみたところ、「管理ツール」のAppIDはありませんでした。(コントロールパネルの中には有るのに・・・)

 

 

なお、”get-startapps | fl” により確認出来た「電卓」の AppID を XML ファイルに書き足してやる事で、スタート画面に「電卓」を表示させる事が出来ました。

 

Netdom join コマンドによるドメイン参加。

コンピューターをActive Directory のドメインに参加させる方法はいくつかありますが、その一つに、”Netdom join ~~” というコマンドがあります。

グーグルで「Netdom ドメイン参加」で検索すると、少なくともこの記事を書いている時点では、検索結果のトップに「IT Pro」の下記サイトが表示されます。

仕事に役立つコマンド入門   netdomコマンドでドメインに参加する

 

 

最低限必要と思われるオプションを網羅したコマンド例が載っていて助かるのですが、1点だけ気になるところがありました。

参加したいドメイン名を指定する、”/domain:example” の部分です。

これって、いわゆるひとつの 「NetBIOS ドメイン名」ですよね? じゃ、NetBIOSによる名前解決が可能な、同一セグメント内でしか通用しないんじゃ・・・?

 

 

実機(Windows Server 2008 R2 SP1)で確認したところ、ドメインコントローラーとクライアントコンピューターが別セグメントに存在する場合は、確かにドメイン参加に失敗しました。

たとえクライアント側で「優先DNS」にドメインコントローラー(兼DNS)のIPアドレスを登録しておいたとしても、NetBIOSドメイン名だけの記述では不十分だということです。NetBIOSなんですから。

そういったケースでは、例えば ”/domain:example.local” のように、FQDNを最後まで記述する必要があります。そうしたところ、ドメイン参加に成功しました。

ちなみに、TechNet の Netdom join の解説ページでは、コマンド例がFQDNで記述されています。