カテゴリー: Windows Server 2008 R2

フォレストとドメインの機能レベルを下げてみた。

投稿日: | 投稿者: ssmshibata

フォレストやドメインの機能レベルは、一度上げてしまったが最後、二度と下げる事はできない・・・

そう思ってました。

が、どちらも「2008R2以上のレベルから、2008まで」なら、下げられることを確認しました。

※Technetの下記ページによると、フォレストの機能レベルを下げる事ができるのは「Active Directory のごみ箱が有効になっていないとき」という条件付きだそうです。

AD DS のインストールおよび削除に関する新機能

 

 

上記ページには肝心の手段が書いていないのですが、PowerShellでできることが判明しました。

フォレストの機能レベルなら「Set-ADForestMode」、ドメインの機能レベルなら「Set-ADDomainMode」です。

※Windows Server2008R2の場合は、予め「ActiveDirectory」モジュールをインポートしておく必要があります。

 

 

これらのコマンドレットの必須パラメーターは二つだけです。

「-Identity」でドメイン名を、「-ForestMode（ないし-DomainMode）」で下げたいレベルを指定します。

フォレストのルートドメイン「test.com」でフォレストの機能レベルを2008にする場合は、

Set-ADForestMode -Identity test.com -ForestMode windows2008forest

と書きます。

 

 

この方法により、Windows Server 2012やWindows Server 2012R2のドメインコントローラーで、両機能レベルを「2012」や「2012R2」から「2008」まで下げることもできました。

※上げることもできました。

サービスの「状態」比較 #2

投稿日: | 投稿者: ssmshibata

前回からだいぶ間が空いてしまいましたが、よくあるお問い合わせ「OS を再起動したところ、再起動前は実行されていなかったサービスが、再起動後に勝手に実行されている。これは問題ではないか。」についての第二回です。

 

 

例えば Windows 7 や Windows Server 2008 R2 の場合ですと、サービスの「スタートアップの種類」は４種類あります。

OS 起動時に自動的に開始される [ 自動 ]、それより 2 分遅れで自動的に開始される [ 自動(遅延開始)] 、何らかの契機により必要に応じて開始される [ 手動 ] 、まったく動かない [ 無効 ] です。

 

 

これらのうち [手動] という表現が問題で、「人間が手作業で [ 開始 ] ボタンを押した時にだけ開始する」サービスだという誤解を生んでいます。

実際にはそういう意味ではなく、人間の操作によらずとも、コンピューターの内部動作により必要に応じて随時開始（用が済んだら停止）されます。

 

 

そのことは、イベントビューアの「システム」ログで確認出来ます。

何らかのサービスが開始された際には「レベル：情報, ソース：Service Control Manager, イベント ID：7036, 説明：○○サービスは 実行中  状態に移行しました。」というイベントが記録されますので、パソコンを半日ぐらい手を触れずに放置してから確認してみてください。

いくつかのサービスが勝手に開始していることを確認出来ると思います。

（停止の際に記録されるイベントも、同ソースの同イベント ID です。）

 

 

なお「スタートアップの種類」を [ 自動 ] から [ 手動 ] に変更した場合、「システム」ログに「レベル：情報, ソース：Service Control Manager, イベント ID：7040, 説明：○○サービスの開始の種類は 自動的な開始  から 要求による開始 に変更されました。」というイベントが記録されます。

全部「要求による開始」という表現に統一しておけば無駄な誤解を生むことも無いはずなのですが、マイクロソフトはそこまで考えていないのでしょう。。。

 

 

このように、サービスの中には勝手に開始および停止するモノもありますので、OS 再起動の前後でサービスの状態を単純比較することに、たいした意味は有りません。

（もしかしたら、完全一致するケースの方が珍しいのかもしれません。）

意味のあるチェックをするとしたら、「このサーバーにおいて必ず開始されていなくてはいけない○○サービスが、ちゃんと開始されているか？」といったように、もっと的を絞る必要があります。

DNS サーバーなのに DNS Server サービスが開始されていなかったら、それは当然問題ですからね。

 

 

しかし、実際にこのお問い合わせいただいた場合に、本当に問題が起きていたことはほとんどありません。

大抵の場合は、そのサービスのスタートアップの種類が [ 手動 ] であるがために、状態を確認したタイミングでたまたま開始（または停止）されていただけです。

 

 

まだつづく。

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

投稿日: | 投稿者: ssmshibata

前回の While ステートメントに、実際にドメインユーザーを作成するコマンドレット" New-ADUser "を一行書き足すことで、「ドメインユーザー連続作成」ができるようになります。

 

 

ただドメインユーザーアカウントを一つ作成するだけでしたら、" new-aduser <ユーザー名> " だけでも可能です。

そのため、二つの変数 $L = import-csv samplelist.csv , $C = 0 を定義した直後に " new-aduser ($L[$C]).name " を実行した場合、「aaa」をユーザー名とするドメインユーザーが作成されます。

しかし、この状態ではパスワードが設定されていないのは当然として、ユーザーアカウント自体も「無効」となっています。

作成と同時にアカウントを「有効」とするためには、" -Enabled $true " というオプションが必要です。

" net user <ユーザー名> /add /domain " コマンドで作成したユーザーアカウントであれば、特にオプションを付けずとも最初から有効なのですが。

 

 

ドメインユーザーの作成と同時にパスワードも設定するには、" -AccountPassword " というオプションを用います。

しかし、" -AccountPassword ($L[$C]).password " という記述で CSV ファイルからパスワードを読み込もうとしても、失敗してしまいます。

どうやら、「ごく普通の文字列（プレーンテキスト）」はパスワードとして扱えず、「SecureString」というセキュリティ的に保護された文字列である必要があるようです。

CSV から読み込んだ文字列を「SecureString」に変換するためには " ConvertTo-SecureString " というコマンドレットも併用しなくてはいけないので、実際のドメインユーザー作成コマンドレットは下記のようになります。

" New-ADUser ($L[$C]).name -AccountPassword (ConvertTo-SecureString -asplaintext ($L[$C]).password -force) -Enabled $true"

この一行を While ステートメントに組み込んで繰り返し実行することで、CSV に記述された全ユーザーが作成され、同じく CSV に記述されたパスワードを用いてドメイン内のコンピューターにログオン出来るようになります。

 

 

なお、上記コマンドレットにより作成されたドメインユーザーは、「姓」「名」「表示名」「ユーザー ログオン名」が設定されておらず、「ユーザー ログオン名（Windows 2000 より前）」だけが、指定したユーザー名により設定されている状態です。

そのユーザー名でログオンすること自体に支障は無いのですが、必要に応じてオプションを付与し、適宜設定するようにしてください。

 

 

" new-aduser "、" ConvertTo-SecureString " コマンドレットについての詳細は、下記 URL を参照してください。

New-ADUser

http://technet.microsoft.com/ja-jp/library/ee617253(en-us).aspx

 

ConvertTo-SecureString

http://technet.microsoft.com/en-us/library/hh849818.aspx

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

投稿日: | 投稿者: ssmshibata

前回は、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 編 ~

投稿日: | 投稿者: ssmshibata

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

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

 

 

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

[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 " です。

 

 

続く

フェールオーバー クラスタリング「再起動期間」の意味

投稿日: | 投稿者: ssmshibata

Windows Server 2008 R2 SP1 のフェールオーバー クラスタリング環境で確認したことを、備忘録代わりに書き留めておきます。

 

 

クラスター上の各リソースには、

◆ 再起動期間 （既定値：15 分）

◆ 指定期間内での再起動の試行回数（既定値：1 回）

という二つの設定値が有ります。

設定は、リソースのプロパティ画面の「ポリシー」タブ内で行います。

同じグループ内でも、リソース毎に異なる値を設定可能です。

 

 

上記既定値の意味は、「リソースが " 失敗 " 状態になった場合は再起動を試みるが、15 分以内に 2 回目の " 失敗 " 状態となった場合は、もう再起動を試みない。」というものです。

この「 15 分」という再起動期間が、どのようにカウントされるのかが気になったので、実際に検証してみました。

なお、再起動を試みない場合にフェールオーバーするか否かは、他の設定項目によって変わります。（既定ではフェールオーバーする設定となっています。）

 

 

まず、検証用の設定値に変更します。

◆ 再起動期間  （ 4 分）

◆ 指定期間内での再起動の試行回数（ 2 回）

その上で、「このリソースのエラーをシミュレーションする」でわざと " 失敗 " 状態にしてみます。

（この機能は、リソースを右クリックして表示されるメニューの、「その他のアクション」の中に有ります。）

[ 0 分 00 秒 ]  一回目の失敗。すぐ再起動し、オンライン状態に戻る。

[ 3 分 30 秒 ]  二回目の失敗。すぐ再起動し、オンライン状態に戻る。

[ 4 分 30 秒 ]  三回目の失敗。すぐ再起動し、オンライン状態に戻る。フェールオーバーせず。

=> 最初の失敗から 4 分以上経過しているので、想定通りです。

[ 5 分 30 秒 ]  四回目の失敗。すぐ再起動し、オンライン状態に戻る。フェールオーバーせず。

=> 二回目の失敗から数えた場合、４分経過していないうちに三回目の失敗が起きたことになります。

 

 

以上の結果から、一回目の失敗から 4 分経過した時点で、失敗カウントはゼロ回にリセットされていると考えられます。

決して「直近 4 分以内で何回目の失敗か」という数え方ではないようです。

” システムで予約済み ” パーティション　＜２＞

投稿日: | 投稿者: ssmshibata

OS インストール時に勝手に作られるこの「システムで予約済み」パーティションですが、実は作らずに OS をインストールすることも可能です。

そうした場合、Bootフォルダなどが自動的にCドライブ内に作成されます。つまり、Windows Server 2008 やWindows Vistaと同じスタイルになるというわけです。

 

 

以下に、私が実際に行った手順を紹介します。

※Windows Server 2012 の Hyper-V 上の仮想サーバーにて、Windows Server 2008 R2 SP1  を用いました。

1. サーバーをOSインストールメディアから起動します。

2. 最初の画面で言語やキーボードを選択した後、そのままストレートにOSをインストールするのではなく、まずは「コンピューターを修復する」を選択して「システム回復オプション」を起動します。

3. ラジオボタンの選択は既定（上下二つのうち、上側にチェックが入っていると思います。）のまま「次へ」ボタンを押し、次の画面からコマンドプロンプトを起動します。

4. コマンドプロンプトにて"diskpart" を実行し、下記 -a) 〜 -h) のコマンドにより、OSをインストールするCドライブを作成します。

-a) list disk

現在接続されているHDDの一覧を表示します。

-b) select disk X

OSをインストールしたいHDDを選択します。

X には、a) にて確認したそのHDDのナンバーを入れます。

-c) clean

現在そのHDD内にあるパーティションやデータを一掃します。

-d) create partition primary

そのHDDに新しいプライマリパーティションを作成します。

特にサイズを指定していないので、そのHDDを余すところなく目一杯使います。

-e) list vol

HDDにボリュームが作成されたことを確認します。

-f) select vol Y

作成されたボリュームを選択します。

Y には、e) にて確認したそのボリュームのナンバーを入れます。

-g) assign letter=C

ボリュームにドライブ文字「C」を割り当てます。

-h) list vol

ボリュームにドライブ文字「C」が割り当てられた事を確認します。

5. ウィンドウ右上の[×]でコマンドプロンプトを閉じ、同様にシステム回復オプションも閉じ、「Windows のインストール」画面に戻ります。

6. ここから先は通常のOSインストール手順と基本的に同じです。インストール場所を選択する画面では、先ほどdiskpartコマンドにより作成したCドライブを選択します。

7. OS インストール完了後、ログオンして「ディスクの管理」画面を開き、「システムで予約済み」パーティションが無い事を確認します。

 

 

さて、「システムで予約済み」パーティションが無い状態というのは、通常と比べて何がちがうのでしょうか？

試した限りでは、「Windows Server バックアップ」にて、「ベアメタル回復」オプションを選択せずにCドライブ単体をバックアップした場合にも、そのバックアップデータから新品HDDへのベアメタル回復が可能であることを確認しました。（通常はできないことです。）

※可能だとは言っても、このような回復は正式にサポートされる方法ではないはずなので、万が一回復に失敗しても自己責任となります。

" システムで予約済み " パーティション　＜１＞

投稿日: | 投稿者: ssmshibata

まっさらなハードディスクにWindows OSをインストールすると、通常はCドライブが作成され、そこにOSが入ります。インストールのウィザードにおいて特段何もしなければ、Cドライブとは別にデータ用の領域が作成されるということはありません。

ところがWindows Server 2008 R2 やWindows 7 の場合、Cドライブと一緒に、それもHDDの一番先頭に「システムで予約済み」というパーティションが作成されます。容量は100MBしかありません。

このパーティションにはドライブ文字が割り当てられていないため、OSインストール後に[スタート]メニューから[コンピューター]を開いても、Cドライブしか見えません。しかし、「ディスクの管理」画面を開くと、Cドライブより左（先頭）側にこのパーティションが在ることとが分かります。あるいは、"diskpart"コマンドで"list volume"を実行することでも表示されます。

いったいこのパーティションは何なのでしょうか？　無いとどうなるのでしょうか？

 

 

まずは中身を見てみましょう。「ディスクの管理」画面で右クリックしてやればドライブ文字を割り当てることが出来るので、適当に何か割り当ててやればエクスプローラーで開くことができます。一応ここではFドライブとします。

普通に見ても空っぽなのですが、エクスプローラーの「フォルダー オプション」で「保護されたオペレーティング システム ファイルを表示しない（推奨）」を無効化することで中身が表示されます。するとなにやらOSのブートに関するフォルダやファイルがあります。というか、それしかありません。

Fドライブ直下にあったのは、

・Boot  (フォルダ)

・System Volume Infomation  (フォルダ)

・bootmgr  (ファイル)

・BOOTSECT.BAK  (ファイル)

の4つだけでした。（"dir F: /s /A”コマンドを使えば、Bootフォルダの中身まで表示されます。）

このBootフォルダの直下に在るBCDというファイル（ブート構成データ）は、OSをブートする為に非常に重要です。これが壊れるとブート出来なくなるそうです。

こちら↓のサイトでいろいろ興味深い実験をしています。

◆ win7 システムの修復

（http://ftlabo.sakura.ne.jp/win/w7-system-repair/w7-system-repair.shtml）

 

その他、マイクロソフトのサイトにも解説が載っています。

◆ ブート構成データ エディタに関してよく寄せられる質問

（http://technet.microsoft.com/ja-jp/library/cc721886(v=ws.10).aspx）

この↑サイトを見ると分かりますが、BCDによるブートの制御自体は、Windows Server 2008 やWindows Vistaの段階ですでに採用されています。しかし、それらのOSではCドライブ内に存在しました。ではどうして、Windows Server 2008 R2 やWindows 7 では独立したパーティションが作られるようになったのでしょうか？

 

 

手がかりとなりそうな情報が、同じくマイクロソフトのサイトにありました。

◆ ヒント: 不可解な小さなパーティションを理解して削除する

（http://technet.microsoft.com/ja-JP/windows/Win7_Tips65）

◆ ハード ディスクを BitLocker ドライブ暗号化用にセットアップする

（http://windows.microsoft.com/ja-jp/windows-vista/set-up-your-hard-disk-for-bitlocker-drive-encryption）

 

 

どうやら、「BitLocker」という暗号化機能のためのようです。BitLocker機能自体はWindows Server 2008 やWindows Vistaの段階ですでにあったのですが、OSが存在するCドライブ自体を暗号化したい場合には、「OS起動用の領域」を手動で切り分ける必要がありました。なぜなら、BIOSは暗号化されたCドライブを直接認識出来ないからです。

それを最初から独立させておいたのが、Windows Server 2008 R2 やWindows 7における「システムで予約済み」というパーティションなのです。

 

つづく

netsh の運命や如何に。

投稿日: | 投稿者: ssmshibata

Windows Server 2012 R2 のプレビュー版が、６月中には公開されるそうですね。

ソースは、Microsoft Cloud というMicrosoft社によるツイッターアカウントです。

 

 

Windows Server 2012 では、コマンドプロンプトで " netsh " を実行し、次に " interface " 等を実行した時点で「Windows の将来のバージョンで、TCP/IP の Netsh機能が削除される可能性があります。」と表示されます。そしてPowerShell への移行を促されます。

さて、Windows Server 2012 R2 ではどうなっているでしょうか。

 

 

本当に無くなるのはさらに次のバージョンかもしれませんが、 "netsh" が無くなるとすると、これまで蓄積してきたスクリプト等の資産に少なからぬダメージがあるのではと思います。Windows Server 2008 R2 以降はパケットキャプチャまで出来ますからね。

Windows Server 2003 では OS 自体に標準で付属していたキャプチャツール「 Network Monitor 」が、Windows Server 2008 以降はダウンロードツールになりました。

商用稼働中のサーバーの場合、障害調査のためといえど、パケットキャプチャのためにフリーソフトをインストールすることなど言語道断！なケースもあります。たとえ Microsoft 純正であっても。そんな時には、 "netsh>trace" コマンドが有効な手段となりました。

パケットだけでなくネットワーク関連の様々な情報をまとめて採取出来るので、パケットキャプチャ自体が不要だったとしても、ネットワークの障害調査には有用なコマンドだと思います。

 

 

今のところ、Windows Server 2012 標準のPowershell v3.0 には、パケットキャプチャのコマンドレットは無いようです。Windows Server 2012 R2 には新しいバージョンが搭載されるのでしょうか。あるいは、バージョン自体は同じでモジュールの数が増えるのでしょうか。今から楽しみです。

 

 

ちなみに、Windows Server 2012 の PowerShell で "Get-Wild" と実行すると・・・

何も起こりません。

Windows Server 2012 R2  に期待します。

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

投稿日: | 投稿者: ssmshibata

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

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

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

 

 

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

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

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

 

 

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

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

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

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