月: 2013年6月

Start Screen Layout

投稿日: | 投稿者: ssmshibata

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 ファイルに書き足してやる事で、スタート画面に「電卓」を表示させる事が出来ました。

 

Windows Server 2012 R2 Preview のスタートチップ

投稿日: | 投稿者: ssmshibata

画面左下に復活(?)したスタートボタンのようなモノは、正しくはスタートチップ（Starttip）と呼ぶそうです。

前回、普通にクリックすればスタート画面が表示されるだけであると書きましたが、右クリックしてみると、スタートメニューっぽいメニューが表示されました。

内容は以下の通りです。

    ・ プログラムと機能

    ・ 電源オプション

    ・ イベント ビューアー

    ・ システム

    ・ デバイスマネージャー

    ・ ネットワーク接続

    ・ ディスクの管理

    ・ コンピューターの管理

    ・ Windows PowerShell

    ・ Windows PowerShell (管理者)

    ・ タスクマネージャー

    ・ コントロールパネル

    ・ エクスプローラー

    ・ 検索

    ・ ファイル名を指定して実行

    ・ シャットダウン　>

    ・ デスクトップ

 

シャットダウンが出来るのはいいですね。クリックすると、右側に選択肢が展開され、[シャットダウン] か [再起動] が選べます。

 

一番下の [デスクトップ] が何のためにあるのか一瞬疑問に思ったのですが、すぐに分かりました。

スタート画面などデスクトップ以外の画面でも、画面左下隅にポインターを寄せればスタートチップを表示出来るため、そこで [デスクトップ] をクリックすればデスクトップに戻ることができます。

 

Windows Server 2012 R2 Preview をセットアップ。

投稿日: | 投稿者: ssmshibata

２ちゃんねるに「もう Technet でダウンロード出来る。」と書いてあったので、さっそくココからISOをダウンロードして、セットアップしてみました。

 

 

OSのバージョンはやはり 6.3 。ビルドは 9431 。

PowerShell のバージョンは 4.0 、IIS は 8.5 に上がっていました。

 

 

タスクバーの左端にスタートボタンが復活！　していましたが、押してもスタート画面になるだけ。Windows Server 2008 R2 以前のようなスタートメニューは復活していませんでした。

 

 

gpedit.msc で、グループポリシーの中を見てみると・・・

コンピューターの構成の「管理用テンプレート」直下にあるフォルダだけでも、

・サーバー

・タスクバーと[スタート]メニュー

の二つが増えています。

後者はどうやら、スタート画面のレイアウトや、表示されるアプリケーションをコントロールできるポリシー群のようです。Windows 8 が出たばかりの頃には、スタート画面をグループポリシーで管理出来ないか、という問い合わせがよくあったそうなので、その声に応えたわけですね。（対象は Windows 8.1 以降ですが。）

 

 

netsh コマンドはまだありました。

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

投稿日: | 投稿者: 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で記述されています。

 

PowerShell における「変数」の扱い

投稿日: | 投稿者: ssmshibata

PowerShell における「変数」について調べてみました。

PowerShell にはデフォルトでもいくつかの変数が存在します。PowerShell のバージョンを確認出来る "$psversiontable" は、やったことのある方も多いのではないでしょうか。（Windows Server 2008 R2 に標準搭載されている PowerShell V2.0 以降にしか存在しない変数ですが。）

 

 

コマンドプロンプトでも、「%」で前後を括る事により、「環境変数」を使うことが出来ました。例えば、現在ログオンしているユーザー名を表示するためには、"%username%" を実行します。（結果として表示されるユーザー名がコマンドとして実行されてしまうことを回避するには、"echo %username%" を実行します。）

ではPowerShell で"$username" を実行するとどうなるかというと、なにも起こりません。PowerShell においては、「$psversiontable」 のような「変数」と、従来の「環境変数」とは別物のようです。

調べた結果、PowerShell で「現在ログオンしているユーザー名」を表示するためには、"$env:username" を実行すればよいことが分かりました。

この「env:」とやらは一体なにものでしょうか？　実はこれ、「PSドライブ」の一種なのです。（調べれば調べるほど、次から次へと新しい用語が出てくるので参ります。。。）

 

 

「PSドライブ」はPowerShell 独特の概念のようです。PowerShell だけが扱える仮想的なファイルシステムのようなもの、と言えるかもしれません。

従来のコマンドプロンプトでは、Cドライブ等のファイルシステムのディレクトリの中を見るには「dir」コマンドを用いましたが、同じような階層構造を持つレジストリの場合、別途「reg query」コマンドを用いる必要がありました。Powershell の場合はどちらも「PSドライブ」として扱えるので、「get-childitem」という共通のコマンドレットで両方の中を見る事が出来ます。

PSドライブの一覧を確認するには、"get-psdrive” を実行します。すると、マウントされているドライブやレジストリ（HKCU、HKLM）の他に、「Env」もあることが分かります。

 

 

「Env」がPSドライブであるならば、同じくPSドライブであるCドライブの中身を見る時と同じように、"get-childitem" コマンドレットでその中身を見る事が出来るはずです。そこで"get-childitem env:" を実行してみたところ、「環境変数」の一覧を取得することができました。もちろんその中には「USERNAME」もあります。

"$env:username" の意味は、「PSドライブ『Env』配下にある環境変数『USERNAME』に格納されている値を、『変数』として呼び出す」というものだったようです。

 

 

なお、「$」を先頭に付与する事で、PSドライブ配下の「変数ではないもの」を、変数のように扱う事が出来ます。

たとえば、"${C:¥1.txt}" を実行する事で、Cドライブ直下の「1.txt」というテキストファイルの中身を表示出来ます。（パス全体を{}で括る必要があるのは、おそらく「¥」が特殊記号だからでしょう。）

 

 

では、PSドライブを明示する必要が無い、「$psversiontable」のような「純粋な変数」の情報は、一体どこに存在するのでしょうか。

調べたところ、PSドライブ「Variable」の中にありました。このPSドライブの中にある「変数」は、変数名の先頭に「$」を付けるだけで（variable: は記述せずとも）呼び出す事が可能です。Variable 配下の変数の一覧は、"get-variable" ないし "get-childitem variable:" を実行することで確認出来ます。

AT コマンドが廃止されてた。

投稿日: | 投稿者: ssmshibata

Windows の「タスクスケジューラ」にタスクを登録するコマンドとしては、"at" , "schtasks" の２つがありますが、Windows Server 2012 で "at" コマンドを実行すると、「それもう廃止されたから "schtasks" 使ってね。」という旨のメッセージが表示されます。

 

"at" コマンドの特徴として、登録したタスクが、既定では [SYSTEM] アカウントにより実行される、という点が挙げられます。

[SYSTEM] アカウントとは、通常はコンピューターの内部処理に使われるものであり、ユーザーがこのアカウントを用いて対話的にログオンする事は出来ません。

大変強い権限があるため、Administrator でもアクセス許可が無い「何か」へアクセスするタスクは、"at" コマンドで作成すると便利です。

 

 

その "at" コマンドが無くなってしまいました・・・

では 今後、[SYSTEM] アカウントによりタスクを実行したい場合はどうしたらよいのでしょうか？

手段を３つ考えてみました。（Windows Server 2008 R2 SP1 および Windows Server 2012 にて確認。）

 

 

＜１＞　まず一番簡単なのは、手動による変更です。

GUI （タスクスケジューラ）ないし "schtasks" コマンドにより作成したタスクは、GUI 上の操作（タスクを右クリック -> プロパティの[全般]タブ内）でその実行ユーザーを変更することが可能なので、 [SYSTEM] アカウントに変更します。

 

 

＜２＞　タスクの作成および作成後に、GUIでの操作が一切出来ないというケースもあるかと思います。

そのような場合には、"schtasks" コマンドによりタスクを作成する際に、実行ユーザーを指定するオプション "/RU" の引数に [SYSTEM] と記述します。（パスワードの入力は不要です。）

 

 

＜３＞　"schtasks" コマンドによる、「XML ファイルのインポート」という手もあります。

GUI上でタスクを右クリックし、「エクスポート」を選択することで、実行ユーザー等の設定情報が記述されたXMLファイルが保存されます。

あらかじめ [SYSTEM] アカウントにより実行されるよう設定したタスクをエクスポートしておき、"schtasks" コマンドによりタスクを作成する際、XMLファイルを読み込むオプション "/XML" の引数としてそのXMLファイルのフルパスを記述します。

これにより、"/RU" オプション無しでも、 [SYSTEM] アカウントにより実行されるタスクが作成されます。

※"/RU" オプションにより、XML内の記述と異なる実行ユーザーを指定した場合は、"/RU" オプションが優先されます。

 

 

このXMLファイルには、実行ユーザー以外にもタスクの設定情報が多く記述されていて、メモ帳でも編集可能です。

"schtasks" コマンドによりタスクを作成する際のオプションとしては存在しない設定も、どうやら編集出来るようなので、覚えておいて損は無い方法だと思います。