Windows インフラ

みなさんお久しぶりです。ずいぶんと長い事このブログに記事を書いていませんでした。このブログはいままでどちらかというとWindows Server OSのさらにOSの基本機能に関する部分についてフォーカスして書いていました。実際には自分が後輩に対して知っておいてほしいと思った事や、実際に質問を受けたときに回答をまずブログに書いて、そのURLを紹介するような形が多かったです。あとは、自分が新人のころに理解に苦しんだ事についてですね。 すると当然自分自身は既によく知っている事について書く事になり、それによって自分自身の知識が深まる……ということはほぼ無い状況でした。また、それなりにまとまった情報をきちんと書きたい気持ちもあったのと自分が記事を書くスピードが遅い事もあり、１エントリあたりいつも3,4時間はかけていました。今でもまだまだ書きたいネタは多数あるのですが、モチベーションが保てず、なかなか時間を確保できずにいました。 そこで、今後は方向性を少々変えて、「今時分が勉強している事」も多数盛り込む形にしようと思います。場合によってはWindows Server自体からはちょっと離れた話題になることもあると思います。 これまでの記事を気に入ってくださって…だと思うのですが、RSSの購読者の数が気がつけば90人近くになっていました。ありがたいです。同時に最近記事を投稿できていなくて申し訳ないなと思ってました。若干スタイルが変わりますが、これからもおつきあいいただければ嬉しく思います。(RSSリーダーに登録したまま読んで無い方も多数いるとは思いますが……) #もしも「こんな内容について書いてほしい」というリクエストのようなものがあればコメント頂ければ喜んで書くと思います。

今回は検証環境のネットワーク周りについて書きたいと思います。 検証時にやってはいけないこと 検証をする時には自由にサーバーを立てたりするわけですが以下のようなことをすると非常に大変なことになってしまいます。 - IPアドレスをバッティングさせてしまう きちんと通信できませんし、場合によってはもともと正しくそのIPアドレスを使っていた本来のホストが通信できなくなってしまうようなことにもなります。それが重要なサービスを行っているサーバーだったりすると……。 - DHCPサーバーを本番ネットワークで立ててしまう 検証用ネットワーク…のつもりで構成してあると、起動して間違ったDHCPサーバーからIPアドレスを受け取ってしまったホストがすべてきちんと通信できなくなります。私の所属する会社でも昔は新人が配属された直後に毎年のようにこの事故が起きてました…。 - ホスト名、ドメイン名をバッティングさせてしまう Windowsネットワークではホスト名やドメイン名は重複できません。特に同一セグメント内ではブロードキャストしてますので、ホスト名が重複しているというエラーが表示されちゃいます。同一セグメント内で同じドメイン名、特に同じBETBIOSドメイン名なんて作ってしまうとまともに動かなくなると思います。マニアックなところでは、ドメイン名と同じホスト名が存在してたりするとドメインに参加しているホストのすべてが起動するたびにホスト名の重複のエラーが表示されたりします。この時ホスト名同士が重複しているわけではないので原因を探すのにちょっと時間がかかったりします。 このようなことがありますので、検証用のネットワークはきちんと本番のネットワークから独立させようという話が出てきます。もちろん独立させるべきです。ただ、単純に独立させてしまうと今度は以下のような場面で不便です。 - Microsoft Updateを実行したいけどできない。 - 検証環境にファイルを持ち込んだり持ち出したりしたいけどできない。USBメモリ、UBS HDDは使用禁止だし…。 - 自分のPCからリモート接続できたら便利なのにできない…。 このようなことがあるので、検証環境を本番環境から安全に分離しつつ利便性を損なわない構成にしたくなります。 もっとも、セキュリティを最重視するのであればネットワークは完全に切り離されるべきですし不便であるべきです。部屋も別、携帯等の持ち込みも禁止……、というような環境もあります。私はそこまですると非効率すぎて逆に事故が増えるのではと思いますが…。 具体的な方法 いくつか具体的な対象方法を挙げてみます。 - 検証環境と本番環境の両方に接続するホストを作り、そのホスト上で必要なProxyを動作させる。ファイルの中継場所にする。 - 検証環境と本番環境の間にFWやNATを設け、必要な通信のみ行えるようにする。 - 検証環境からインターネットにアクセスする回線を別途設ける。 どれかひとつだけやればいいというわけでもなく、並行してやっても良いです。他にも色々なやり方があるとも思います。 また、検証環境が仮想環境上にある場合などはネットワーク的には完全に切り離しつつコンソールにアクセスすることが基本機能でできますね。最近はもうこういう環境の方が多いかもしれませんね。ただ、Hyper-Vのコンソールなどはコピペすらまともにできず酷いもんですが…。 よく使うソフト 私がよくつかうソフトを一応紹介しておきます。実はあまりよく調べて選んでいるわけではないのですが便利に使わせてもらっています。 DeleGate Home Page (www.delegate.org) Hyper-Vの物理ホストあたりにはProxyとしてDeleGateを仕込んでおくことが多いです。 BlackJumboDog ちょっとした検証の時にGUIでちょちょいっと設定して動かせちゃうので重宝します。Proxy以外にも色々なサーバーになれてしかもデバッグ表示が優れているので検証用途には重宝しています。

今回はActive DirectoryとDNSについての話をしてみようと思います。Windowsネットワークを構築する上ではある程度の規模以上ではActive Directoryの構築、理解は事実上必須となり、Active Directoryを構築する上ではDNSの利用が必須になります。そしてDNS周りの設計が一番技術的に難易度が高く理解が難しいところです。ひとつずつ解説してみたいと思います。 Active DirectoryにはなぜDNSが必要なのか Active DirectoryにはDNSが必須です。DNSがないときちんと動きません。これはなぜかというと、端的には「DNSをつかってドメインコントローラーを探すから」ということになります。ただ、「DNSを使ってドメインコントローラーを探す」と言われてもピンと来ないかもしれません。イメージを持ってもらうために実際のDNSレコードを覗いてみましょう。 以下はad.localというシングルフォレストシングルドメイン環境に、dc01.test.local, dc02.test.localという2台のDCが存在している状況です。バージョンはWindows Server 2022ですが、Windows Server 2003以降であれば基本的に同じ構造になっているはずです。 _msdcs.ad.localというゾーンにdc01, dc02のGUIDがCNAMEで登録されています。 展開していくと、サイト名にひもづくようなレコードがありSRVレコードにdc01, dc02の値が見えます。 違う場所にも同じようなレコードがあります。 以下同様にまだまだたくさんあります。 pdcのところにはdc01だけしか無かったりします。これはPDCエミュレーターというFSMOの役割を持っているのは(この場合はdc01という)単一のサーバーだけだからです。 _msdcs.test.localゾーンではないtest.localゾーンにも同じようなレコードがあることが確認できます。 本筋からずれてしまうので、ここで個々のレコードの意味を説明することはしませんが、見てもらったようにDNSの中に一定のルールに従ってSRVレコードが作成されていることがわかります。クライアントはこれらのレコードを参照しながらActiveDirectory環境で動作します。そしてドメインコントローラー同士もDNSのレコードを参照してお互いに通信したりします。DNSがないとドメインに参加もできないし、ドメインにログオンもできないほどDNSはActiveDirectory内で大切なサービスです。 インターネットのDNSとActiveDirectoryのDNSの関係について ところでDNSと言えばまず思いつくのはActiveDirectory用のDNS…よりも先にインターネットで使われているDNSが思いつくと思います。世界中にある無数のホストの名前解決を行ってくれている階層、分散管理のシステムです。 Domain Name System - Wikipedia このDNSとActiveDirectoryで使われるDNSとは同じものなのか、違うものなのか?このあたりは中々複雑な状況があります。 ActiveDirectoryが登場する前からインターネットは存在し、そのなかでDNSは使われていました。- ActiveDirectoryは名前解決の仕組みとしてインターネットという大規模システムで使われてもうまく動作しているDNSという仕組みを採用しました。- マイクロソフト実装のDNS(以降MSDNSと書きます)をインターネット上のDNSとして構成することも(やれば)できます。- インターネット上のDNSとして多く使われているBINDをActiveDirectory用のDNSとして構成することも(やれば)できます。 ここまではまぁよいかと思います。MSも独自のDNS実装を作ったけれども、BINDであろうとMSDNSであろうとDNSはDNSなのでどのような用途にも構成すれば使えますよ、ということです。 難しくなってしまうのは以下のあたりの要素があるからです。 インターネット上のドメイン名と同じドメイン名(たとえばgoogle.comドメイン)をActiveDirectoryのドメイン名にすることができてしまいます。(ただし通常これはやらない方がいいです。)- インターネット上のDNSをそのままActiveDirectoryのドメイン名とし、インターネット上にすべて公開することができてしまいます。(ただし、これは絶対にやらない方がいいです。)- ActiveDirectoryのDNSはインターネットの世界とは完全に切り離して構成することが可能です。(これは推奨される構成です。)- ActiveDirectoryのDNSはインターネットの世界とは切り離して構成しつつ、それでもインターネット上のホストの名前解決をActiveDirectoryに参加しているクライアントにさせたい場合には、ActiveDirectoryのDNSがインターネット上のホストの名前解決を可能となるように構成可能です。(これはしばしば行われる構成です。) さらに混乱に拍車をかけるのは、ActiveDirectory以外にそもそも社内に独自のDNSの空間があって、そこに対してActiveDirectoryを追加するようなケースです。 既存DNSの名前解決をActiveDirectoryのDNSにもさせたい。- 既存DNSの名前解決をActiveDirectoryのDNSにはさせたくない。- 既存DNSの名前解決をActiveDirectoryのDNSにもさせつつ、インターネット上のホストの名前解決もできるようにしたい。- 既存DNSの名前解決をActiveDirectoryのDNSにはさせたくないが、インターネット上のホストの名前解決はできるようにしたい。- 既存DNSに問い合わせた場合にもActiveDirectory上のホストの名前解決はさせたい。- 既存DNSに問い合わせた場合にはActiveDirectory上のホストの名前解決はさせたくない。 まだまだバリエーションは増やそうと思えば増やせますね。 さらにここで社内の独自のDNSの名前空間がインターネット上のドメイン名と重複しているような場合…さらに混乱できる構成となってしまいます…。私も新人で、「DNSってインターネットの世界で名前解決に使うやつでしょ?」という認識だったころにこのあたりの話を聞いて大混乱したのをよく覚えています。ただ、実際のところ取りうる組み合わせは多数ありますが、実際にお勧めできる設計のパターンとしてはそんなに多くないのでそれらをこれから具体的に説明してみたいと思います。 長くなってしまったので、続きは「Active DirectoryとDNSについて その2」で。 Active DirectoryとDNSについて その2 | Windowsインフラ管理者への道 (ebisuda.net)

Windows Server 2012ではインストールされていない役割、機能のバイナリファイル自体をディスクから削除する機能が追加されました。ディスクが節約できる反面、追加インストール時にひと手間必要になるので少々注意が必要になっています。特に「source」の指定が導入する役割、機能によって別のものになることがあるようなのでその点に注意が必要です。 私がちょっと戸惑ってしまったのは以下のパターンです。 はじめにServer Coreでインストール - その後GUIを追加 - その後.NET Framework 3.5を追加 ※初めからGUIもインストールしておいても.NET Framework 3.5のバイナリもインストールされていません。 同じことでつまずく人がいるかもしれないので記録しておきます。 ServerCoreにGUIを追加する Server Coreでインストール後に、GUIを追加する方法は技術文章に記載されています。 Windows Server インストール オプション Windows PowerShell を使用して、Server Core インストールからフル インストールに変換するには - コマンド mkdir c:\mountdir を使用して Windows イメージ ファイル (WIM) をマウントするフォルダーを作成します。 - 管理者特権のコマンド プロンプトでコマンド Dism /get-wiminfo /wimfile::sources\install.wim を使用して、サーバーのインデックス番号を GUI イメージで確認します (たとえば、SERVERDATACENTERCORE ではなくSERVERDATACENTER)。 - 管理者特権のコマンド プロンプトで、次のコマンドを使用して WIM ファイルをマウントします。Dism /mount-wim /WimFile::\sources\install.wim /Index:<#_from_step_2> /MountDir:c:\mountdir /readonly - Windows PowerShell を起動し、次のコマンドレットを実行します。Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell –Restart –Source c:\mountdir\windows\winsxs - または、ソースとして WIM ファイルではなく Windows Update を使用する場合は、次の Windows PowerShell コマンドレットを使用します。Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell –Restart ...

PowerShell 3.0を触ってすぐに使うことになったコマンドレットをここに書き記しておきます。 ホスト名変更 - Rename-Computer R e n a m e - C o m p u t e r n e w n a m e IPアドレス変更 - Get-NetAdapter - New-NetIPAddress - Remove-NetIPAddress # N I C が 1 つ だ け の 場 合 G e t - N e t A d a p t e r | N e w - N e t I P A d d r e s s 1 9 2 . 1 6 8 . 1 . 1 - D e f a u l t G a t e w a y 1 9 2 . 1 6 8 . 1 . 2 5 4 - P r e f i x L e n g t h 2 4 ...

SSLはインターネット上で安全な通信をするための非常に重要な仕組みですが、それについての概念を技術的な話はほぼ交えずに以下エントリで解説されていてわかりやすいと感じたので紹介します。 - [なぜb-casは失敗してインターネットはうまくいくのか？ - アンカテ](http://d.hatena.ne.jp/essa/20120525/p1) タイトルはb-casの話のようですが、内容はSSLの解説です。 「SSLって暗号化するための技術で公開鍵とか使ってるんでしょ?」程度の理解の方は読んでおくことをお勧めします。このサイトでもそのうち１つずつ解説していきたいなと考えています。

telnetでメールを送信する方法としてこれまで2つのエントリで方法を紹介してきました。 - [コマンドプロンプトだけでメールを送信する | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2009/03/26/%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%83%97%E3%83%AD%E3%83%B3%E3%83%97%E3%83%88%E3%81%A0%E3%81%91%E3%81%A7%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%92%E9%80%81%E4%BF%A1%E3%81%99%E3%82%8B/) - [telnetで日本語メールを送信する | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2012/01/04/telnet%e3%81%a7%e6%97%a5%e6%9c%ac%e8%aa%9e%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%92%e9%80%81%e4%bf%a1%e3%81%99%e3%82%8b/) 前回の方法でとりあえず日本語メールが遅れているのですが、もうちょっときちんとしたヘッダを付けてメールを送信する方法を紹介したいと思います。 まず、SMTPで日本語を(も)取り扱うための規格としてMultipurpose Internet Mail Extensions(MIME)があります。 - [Multipurpose Internet Mail Extensions - Wikipedia](http://ja.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions) これによってUS-ASCII以外の文字や添付ファイルなどが扱えるようになっています。今回はきちんとMIMEを使って日本語メールを送ってみようと思います。 ヘッダとボディ これからMIMEの説明をするにあたっては、まずヘッダとボディをきちんと認識する必要があります。前回送信したメールで説明すると以下のようになります。 dataコマンドでデータを送信することを指定した後でメールのヘッダとボディを連続して書き込んでおり、ヘッダとボディの区切り目は空行によって表現されているわけです。MIMEヘッダの記述はヘッダ部分に行っていきます。 MIME-Version MIMEのバージョンを区別するためのヘッダです。現在1.0しかありませんので必ず以下のような記述になります。 M i m e - V e r s i o n : 1 . 0 Content-Type メッセージ(ボディ部分)の形式を指定するヘッダです。様々なものがありますが、日本語メールを送りたい場合にはここはtext/plainになります。さらにtext/plainの場合にはその文字コードを表すcharsetが追加されます。具体的には以下のような記述になります。 C o n t e n t - T y p e : t e x t / p l a i n ; c h a r s e t = " i s o - 2 0 2 2 - j p " ; ...

特定ディレクトリ以下のファイルオブジェクトを取得するサンプルコードです。 [gist]https://gist.github.com/2716715[/gist] 再帰関数内でオブジェクトを新規に作成してそれを返り値として返すことがなかなかうまくいかなかったので、外部のスコープで定義したScripting.Dictionaryオブジェクトに値を追加する実装で妥協しました……。

ローカルの管理者権限の有無をnet.exeを使って確認します。 [gist]https://gist.github.com/2716207[/gist] 元ネタはこちらです。 - [PowerShell: ◆ローカルのAdministrator権限が有るか確認する](http://mtgpowershell.blogspot.jp/2012/05/administrator.html) - [2012 Scripting Games Commentary: Those Who Forget The Past... - Don Jones - Powershell.com – Powershell Scripts, Tips and Resources](http://powershell.com/cs/blogs/donjones/archive/2012/04/19/2012-scripting-games-commentary-those-who-forget-the-past.aspx) ただし、元ネタだとドメインユーザーがローカル管理者権限を持っているときにそれを判定できなかったのでその部分のロジックを追加しました。

レジストリへの値設定スクリプトです。事前に値を確認し、変更の必要があることを確認し、書き込み、きちんと書き込めたかどうか確認しています。 WindowsVista, 7, 2008, 2008 R2でUACが有効な場合には管理者権限があっても書き込みに失敗してしまうので、事前に昇格をおこなってから実行させる必要があります。 - [Windows VistaでのWSH(VBScript)の管理者権限への昇格方法 - ebi's diary(2008-08-13)](http://ebi.dyndns.biz/diary/20080813.html#p01) [gist]https://gist.github.com/2601725[/gist]

VBScriptでちょっとしたスクリプトを書き捨てることは今までにかなりしてきましたが、そろそろPowerShellに本格的に移行できる感じになってきました。とはいえまだまだVBScirptの出番もあると思いますので、今まで書き捨ててきたスクリプトの中で特に「毎回同じこと書いてるなー」と感じるような処理についてgistに上げつつ共有できるようにして行きたいと思います。 まずは、どのスクリプトでもほぼ必ず行うファイルへのログ出力処理です。 [gist]https://gist.github.com/2586011[/gist]

今回はクライアント展開作業計画のポイントについての話です。クライアントをまとまった台数で入れ替える…というのは、機器が古くなり、OSが新しくなって古い物がサポートされなくなる以上、未来永劫ずっと続く作業です。全体的な流れも大切ですが、作業時間が長くなってしまいがちなのがこの作業です。計画作成時のポイントについてまとめてみます。 雛形の作成 端末を入れ替えるにあたっては、旧端末で動作するアプリケーションや各種設定等はすべて引き継ぐようにするのが基本路線となるでしょう。もちろんOS自体のメジャーバージョンアップ時や何かコンセプトを変更することを目的に作業する場合には必ずとは言えないですが、一度動き始めてしまったらずっと使い続ける事が「安全」ととらえてしまう人が多いのも現実であり、すべて引き継ぐことが非常に多いはずです。 多数のアプリケーションや多数の設定をすべて１台づつ行うわけには当然行きませんので、企業での端末展開では - 雛形を作成する - 雛形を展開して個別の機器を作る ということはほとんどの案件で実施されると思います。 さらに単純ミスや仕様変更ふくめて雛形には多数修正が入ります。雛形自体の修正はしないで展開後に修正作業を行う事も可能ですが、効率を考えるとやはり雛形の段階でできるだけ多くの設定を取り入れておくべきであり、現実的には「雛形の修正を簡単に行える環境および雛形展開方法」を取っておくのが望ましいです。 - 雛形作成用のマスター端末は案件終了時まで確保しておく - 雛形作成後のイメージはCD,DVD等に焼くのではなく、ネットワーク経由での配布ができる環境を整えておく(CD,DVDを焼く時間、メディアを入れ替える時間が短縮できる) また、雛形の種類は極力少なくしておくべきです。機器構成や、ソフトウェア構成上どうしても複数の雛形になってしまうケースもあるとは思いますが、何か修正をするたびにすべての雛形への修正を間違えずに確実に行えるように管理しなくてはいけません。できれば1種類にしておきたいですね。 ミスや仕様変更発生時の自動修正ポイントを作っておく 前述のようになるべく雛形の修正や雛形への追加作業を行うのが望ましいのですが、それを確実にやって行ったとしてもどうしてもどこかでミスは発生してしまう物です。展開作業がある程度はじまった後でミスが発覚し、修正を行う必要が発生することも想定しておかなくてはいけません。 そのために - 雛形展開後、自動的にファイルサーバーの特定の場所にあるスクリプトを実行する - 展開作業中にファイルサーバーの特定の場所にあるスクリプトを実行するように手順書に明記し、チェックポイントとする など、「修正を盛り込む場合にはここに盛り込む」というものを作っておくのがおすすめです。 もちろん構成がきちんとしていて、あとからグループポリシーやクライアント管理ソフトウェア等を使って修正を対象端末に確実に適用できるならそれで良いのですが、そういう事が文化的に、あるいは運用ルール的に難しいお客様の環境(他チームへの依頼事項となってしまう等)もあると思います。あらかじめ用意しておくとスムーズです。 雛形展開後のセットアップ作業は極力自動化する これは私の好みなのですが、セットアップ作業は極力「自動化」しておくべきだと思います。なぜかというと、「人間はミスをする」からです。もちろん自動化してもその自動化プログラム自体にバグ、間違いが紛れ込むことはあるのですが人間の多種多様な間違い方やなれからくる油断のようなものとはプログラムは無縁ですから。分厚い手順書を毎日毎日同じ人間にずっとやらせるのは危険だと思います。 ただし、自動化する際にも「そこで何をしているのか」ということは別途明確にしておく必要があります。これを怠ると、自動化したものがうまく動いている間は良いのですが一度なにかの原因で動かなくなると作業が完全にストップしてしまいます。手動作業バージョンの手順書と自動化バージョンの手順書の両方が用意されているのが理想的です。 そして、自動化したものも間違いや修正が発生するのが世の常ですので、すぐに修正がきちんとできる状態にしておくのが望ましいです。一番はじめの処理でファイルサーバー上から最新バージョンを取得する仕組みにしておいて、修正はファイルサーバー上の１カ所で修正すればよいようにしておくなどの方法が考えられます。 作業の流れを工夫する 作業の中で時間短縮のためには流れを工夫する必要がでてきます。作業には主に以下の４つの種類があります。 - 雛形に組み込めるもの - 管理者権限があればできるもの - ドメインに参加した状態が必要なもの - ユーザーアカウントで設定が必要なもの 雛形に組み込めるものはもちろん雛形に組み込めば良いでしょう。 管理者権限があればできるものにはドメイン参加やソフトウェアのインストール等があります。雛形に組み込めないこの手の作業は雛形展開後に自動実行されるのが望ましいです。 ドメイン参加後にしかできない作業はドメイン参加後に自動化して実施します。ドメイン参加後の再起動からの自動的なログオン、自動的なコマンド実施等自動化の流れを作ってしまうのが良いと思います。場合によっては先にドメイン参加してその上で設定後、ドメインから外した上で雛形を作成する……という荒技も場合によっては選択肢になります。(一応動くようです。) 最後にユーザーアカウントでの設定が必要な物ですが、ここが一番作業には効いてきてしまいます。 ユーザーアカウントで入った後にしかできない設定をどうするか？ ユーザーアカウントでログオンし、作成されたプロファイルに対して設定を行う必要がある…というものが結構な量存在するはずです。ソフトウェアの構成しかり、ユーザーの保持しているデータしかり。ユーザーアカウントに依存してしまうので、雛形の段階で組み込んでおく事もできません。なので、必ずユーザーの席に設置したあとでユーザーにログオンしてもらったあとで作業する必要がある……というのが自然な流れなのですが、その作業が1時間も2時間もかかるようだと時間的に問題になる可能性が高いです。 どのように時間短縮をすることが可能かというと、以下のような選択肢があると思います。 - ユーザーに長時間のセットアップを我慢してもらう。 - 事前にユーザーアカウントでログオンし構成を済ませる。 - ユーザーにログオンしてもらう。 - パスワードを教えてもらう。 - パスワードをリセットさせてもらう。 - 作業用のDCを別途作成し、そこでパスワードをリセットする。 - 手順書を用意し、ユーザー自身に行ってもらう。 どの方法で行くかは実際に作業に必要な時間やその会社の文化によって選ばれる事になると思います。何が正しい、正しくないという事もありません。ただ、引き出しは沢山持っておいた方が良いでしょう。 3の「作業用のDCを別途作成」というのは例えばネットワーク的に切り離した環境にDCをバックアップからリストアし、そのDCに対してクライアントを接続し、ログオンし、プロファイルを作成してしまうという荒技です。SIDがきちんと同一の物になるので本番環境のユーザープロファイルとひもづきますし、何も気にせずにユーザーのパスワードをリセットしてしまう事ができます。ただ、展開中に新規で作成されたユーザー等に関しては対応できないので、注意が必要です。 ユーザーデータの移行はどうするか? クライアント展開作業で実際のところ時間の振れ幅が多く読みづらいのはユーザーデータの移行作業だと思います。ユーザーによっては全くデータを持っておらずすぐに終わるユーザーもいれば、しこたまデータを溜め込んでいるユーザーまで千差万別だと思います。さらに顧客によってデータはそもそもローカルに保存すること自体が禁止で、すべてファイルサーバー上に保持しているところもあれば、デスクトップ、マイドキュメントなどユーザープロファイルの場所に置く文化の所、どこに何があるかわからない無法地帯になっているところまで本当に色々です。移行に対する方針も顧客ごとにまちまちになりますが、多いのは以下のようなパターンでしょうか。 - ファイルサーバー等を使って、ユーザーデータはユーザー自身が移行する。 - 事前に移行が必要なデータはすべて指定した場所(マイドキュメントフォルダの中など)に移動しておいてもらい、それ以外は移行しない。 - 拡張子で移行対象を決定し、すべてのデータを検索したうえで移行する。 - 特定のアプリケーションの特定のデータはきちんと作業員が確認した上で移行する。(OutlookのPSTファイル、辞書ファイル等) 特にケアが必要なのは「ユーザーが普通認識していないが重要なユーザーデータ」です。ブラウザのお気に入りの情報や辞書ファイルなどが該当し、ユーザーが使用しているアプリケーションを把握した上でどこまでのデータを移行させるのかきちんと合意しておく必要があります。 ...

今回は「もしかしてネットワークがおかしい?」という時のポイントの話をしようとおもいます。「もしかしておかしい?」というのは随分と曖昧な表現ですが、実際にこのような微妙な状況というのはよく起こるものです。 - 通常の処理は全部正常に出来るのだけれども、時間がかかりすぎているような感じがする。 - ほとんどの処理は正常なのだけれども、サイズの大きなファイルを扱う時だけうまくいかない。 - ネットワーク上のファイルコピーになんだかやけに長い時間がかかる・・・けど、ほおっておけば終わる。 - なんとなくネットワークを利用する処理が重い気がする。 このようなことは良くあります。よくある問題やチェックポイント等、私がいつも意識してチェックしている項目を紹介します。 SNP Windows Vista以降、ネットワーク関連で何か怪しいところがあればまず試してみるのがこの項目です。本来性能Upのためにあるものなのですけど…ね。 - [予期せぬ挙動が!? 新機能 Scalable Networking Pack をご存知ですか? - Ask the Network & AD Support Team - Site Home - TechNet Blogs](http://blogs.technet.com/b/jpntsblog/archive/2010/03/23/scalable-networking-pack.aspx) - [［Windows 7編］ネットワーク設定を標準で使ってはいけない - ITアーキテクトの「やってはいけない」：ITpro](http://itpro.nikkeibp.co.jp/article/COLUMN/20100824/351391/) SNPの実装自体はWindows Server 2003 SP2のころからあったようですが、規定の状態で有効になったのはVista以降とのことです。時間がたち、技術が成熟することで問題は落ち着き本来の性能向上の恩恵にあずかれる…状態には残念ながらまだまだならないようです。さらにHyper-V上で複数の仮想OSが稼働するようになって問題発生時の複雑度がさらに上がっている印象です。残念ですが、とりあえず現段階では「すべて無効にする」のが得策だと思います。 得に注意したいのは「OSで設定を無効にするだけではなく、HW側の設定も無効にする」という事です。「SNP無効にしてる?」「うん。してるよ。それでもまだ問題が発生しているんだ。」というケースでも実はHW側ではまだ機能が有効で、それにより問題が引き起こされていた…ということが何度かありました。 ジャンボフレーム ジャンボフレームが原因でネットワークのトラブルが起きるケースがあります。もちろんこちらもきちんと構成すればパフォーマンスが向上するのですが…。ジャンボフレームについては以下の記事が理解しやすいと思います。 - [イーサネットを高速化するジャンボ・フレーム技術 － ＠IT](http://www.atmarkit.co.jp/fwin2k/pchard/05jumbo/05jumbo_01.html) ジャンボフレームはTCPの3ウェイ・ハンドシェイクの中でMSSとして値が渡されホスト間でパケットサイズが決定されるので、「通信するホストはどちらもジャンボフレームに対応しているんだけど、間のネットワークにはジャンボフレーム未対応のスイッチやルーターがある」というような場合にトラブルが発生します。しかも小さいサイズのパケットは普通に通るので「pingは全く問題ないんだけどな」というようなことになりがちです。 ブラックホールルーター ジャンボフレームの問題とかなり発生メカニズムや症状は似てくるのですが、発生原因が異なるのがブラックホールルーター問題。昔からときおり見かけるやっかいな存在です。 - [ブラック ホール ルーターの問題をトラブルシュートする方法](http://support.microsoft.com/kb/314825/ja) 解決手順にはセオリーがありますので上記のKBをよく読んでもらえるといいと思います。 ポート枯渇 TCPポートが枯渇することで問題が発生することもあります。TCPポートについてはレイヤ4 -トランスポート層- ポート番号をご覧ください。1つの典型的なケースとしてフロントエンド/バックエンドシステムでTCPポートが涸渇する問題への対処方法を紹介しましたが、このパターン以外でも様々なケースでポート枯渇問題に遭遇することがあります。基本的にnetstat -anコマンドにてコネクションの数を確認すればこの問題が発生しているかどうか判別することができます。集計にはPowerShellで簡単に集計する方法なども使えます。 パケットを見る 上記のどの問題も、それ以外の問題もパケットを見れば理屈上は全部わかるはずです。パケットを見るにはパケットをキャプチャする方法で紹介した方法をつかってまずパケットを取得します。 その後色々な見方がありますが、私がまずお勧めするのはwiresharkでのフィルタを使った確認方法です。 ...

このエントリでは典型的なWindowsクライアント、Windowsサーバーのトラブルシューティング時の確認ポイントやよくある問題についてまとめてみようと思います。 ログ確認 - イベントログ アプリケーション - システム - (監査)※監査ログを追う機会は比較的少ない - アプリケーションのログ デバッグモード、診断ログ的なものがあれば有効にする - 循環したり、切り捨てられるものが多いのですぐに回収する ダンプ - ダンプファイル確認 再現 - 再現性の有無を確認する - 再現手順を探す 設定差異 - 問題が発生する状況を確認する(問題発生時と未発生時) 端末 - ユーザー - OSバージョン - SPバージョン - 修正パッチ - ブラウザ(違うブラウザでの切り分け) - 導入ソフトウェア、アドオン 特にウイルス対策ソフトウェア(無効、除外による切り分け) - ログオンDC - ログオンサイト - ドメイン - ネットワーク設定 SNP - GW - DNS - NetBIOS over TCP/IP - WINS - IPv6 - コンポーネント - Windows FireWall パフォーマンス確認 - CPU - メモリ - ディスク - リーク メモリーリーク - ハンドルリーク 環境確認 - ネットワークトラフィック ブラックホールルーター問題 - SNP - ジャンボフレーム - DC複製状況 repadmin - GPO適用状況 gpresult - VSS動作状況 vssadmin list writers 問題発生時の動作確認 - ProcessMonitor - TCPコネクション状態 TCPポート枯渇 - パケットキャプチャ ...

今はもうOSに標準でPowerShellが搭載されている時代です。Windows 2000世代からはWSHが標準搭載されバッチファイルから解放されました。Windows 7, Windows Server 2008ではPowerShellが標準搭載されWSHからも解放されました。.net frameworkも使いつつオブジェクト指向のスクリプトが書ける、そんないい時代になりました。めでたしめでたし…とはいかないのがこの業界です。残念ながら最新のOS上でいまだにバッチファイルを書かなければならない仕事、未だに仮想化されたWindowsNTの面倒を見なければいけない仕事などが存在するのが現実です。 バッチファイルでは実際のところ相当生産性が低いのですが、そんな中で異彩を放つコマンド”for”。その名前からはただの繰り返しコマンドに思えるのですが、実は恐ろしい力を秘めています。実際の所バッチファイルでちょっと複雑なことをやろうと思うとforを効果的に使わないといけません。今回は未だにバッチファイルを書かなければいけない不幸な人のためにforコマンドのTips集をお届けします。 forコマンドのヘルプから読み取れる「できること」 forコマンドは色々な事ができるコマンドなのですが、まじまじとヘルプを見たことが無い人も多いと思います。以下はWindows7のforコマンドのヘルプです。 指 定 さ れ た コ マ ン ド を フ ァ イ ル セ ッ ト の 各 フ ァ イ ル に 対 し て 実 行 し ま す 。 F O R % 変 数 I N ( セ ッ ト ) D O コ マ ン ド [ コ マ ン ド パ ラ メ ー タ ー ] ...

今回はExchange Server 2010の高負荷時の挙動についてです。特にシステム導入前にLoadGeneratorで実際にパフォーマンス試験を行うような場合に規定値のままでは問題が発生してしまいますので注意してください。 規定値から設定変更すべき項目 現時点(2012/03/05)ではExchange Server 2010 SP1導入時にはSet-TransportServerコマンド及びEdgeTransport.exe.configの値を変更すべきです。規定値のままで動作させた際に、制限値に到達し、問題が発生するケースが多数報告されています。具体的な設定変更すべき項目等をここに書きたいのですが、残念ながら業務上得た知識なので、公開されているもの以外はここに書けません。(他の皆さんはどうされているのでしょうかね・・・) ネット上に情報があるものとしては以下のものが確認できました。 - [Exchange 2010 SP1 Store Driver throttling | Thoughtsofanidlemind's Blog](http://thoughtsofanidlemind.wordpress.com/2010/12/07/exchange-2010-sp1-store-driver-throttling/) The new keys and their values are: - [メッセージ調整について](http://technet.microsoft.com/ja-jp/library/bb232205.aspx) Set-TransportServer MaxConcurrentMailboxDeliveries このパラメーターには、メッセージをメールボックスに配信するためにハブ トランスポート サーバーが同時に開くことができる配信スレッドの最大数を指定します。ハブ トランスポート サーバーのストア ドライバーは、メールボックス サーバーへのメッセージの配信とメールボックス サーバーからのメッセージの受け付けを行います。この制限は、Exchange 組織内のすべてのメールボックスへのメッセージの配信に適用されます。MaxConcurrentMailboxDeliveries パラメーターの既定値は 20 です。 Set-TransportServer MaxConcurrentMailboxSubmissions このパラメーターには、メールボックスからメッセージを受け付けるためにハブ トランスポート サーバーが同時に開くことができる配信スレッドの最大数を指定します。ハブ トランスポート サーバーのストア ドライバーは、メールボックス サーバーへのメッセージの配信とメールボックス サーバーからのメッセージの受け付けを行います。この制限は、Exchange 組織内のすべてのメールボックスからの新しいメッセージの受け付けに適用されます。MaxConcurrentMailboxSubmissions パラメーターの既定値は 20 です。 Set-TransportServer MaxConnectionRatePerMinute このパラメーターには、ハブ トランスポート サーバーまたはエッジ トランスポート サーバーに対して開くことができる新しい受信接続の最大数を指定します。これらの接続は、サーバーに存在する任意の受信コネクタに対して開かれます。MaxConnectionRatePerMinute パラメーターの既定値は 1 分あたり 1200 接続です。 ...

今回は自分で使うようにPowerShellのよく使うコマンドレットやTipsをまとめてみます。随時更新する予定! Get-Command Get-Commandでコマンドレットの一覧を取得できます。 P S C : \ > G e t - C o m m a n d C o m m a n d T y p e N a m e D e f i n i t i o n ...

CassArrayは必ず作成すべし Exchange Server 2010では、OutlookクライアントからのMAPIアクセスに対してCasへのアクセスポイントを集約するための仕組みとしてCasArrayが存在します。それをコントロールするRPCClientAccessServerという属性がデータベースに存在します。この動きを理解していないと思わぬ落とし穴にはまる可能性があります。 基本的にCasArrayは2台以上のCASサーバーがサイト内に存在している場合にOutlookの接続先を指定するもので、接続先を単一の名前にすることで冗長化することを可能にしています(冗長化の仕組み自体はCasArrayは提供しないので、別途HWロードバランサー、SWロードバランサー、NLBなどで冗長化の仕組みを構築する必要があります)。サイト内に1台しかCASサーバーが存在しない場合には特にCASArrayを作成する必然性はありません。・・・が、実はその場合でもCasArrayを作成しておいたほうが良いです。つまり、どんな場合でも例外なくCasArrayを作成しておき、そこに対して接続させるように構成すべきなのです。このことは以下のドキュメントにも明記されています。 - [RPC クライアント アクセスについて: Exchange 2010 のヘルプ](http://technet.microsoft.com/ja-JP/library/ee332317.aspx) **クライアント アクセス サーバー アレイは、組織内に 1 つのクライアント アクセス サーバーしかない場合でも作成することをお推めします。**クライアント アクセス サーバー アレイが作成されると、クライアントは、クライアント アクセス サーバーの完全修飾ドメイン名 (FQDN) に直接ではなく、クライアント アクセス サーバー アレイの仮想名によって接続します。1 つのクライアント アクセス サーバーを Active Directory サイト内部で置き換える必要があるか、2 つめのクライアント アクセス サーバーを追加する場合、クライアント上でプロファイル更新は必要ありません。 つまり、一度プロファイルが作成されてしまうとCASの実ノードへのアクセスがクライアントに記憶されてしまい、その後CasArrayを使う構成にしたりCasを切り替えたりする場合にプロファイルの更新がクライアント側で必要になってしまう危険性があるのです。サーバー側で管理者が操作するだけで変更できるならともかく、クライアント側で個別に作業が発生してしまうのは管理者にとって悪夢です。しかもそれが自動化しづらいものとなると・・・。事前の準備が肝心です。 構築時の注意点 構築時にはいくつか注意点があります。知っていないと思わぬ挙動に頭を悩ませることになる危険性があります。 まず新しくCasArrayを作成するのは簡単です。 - New-ClientAccessArray Name "CAS Array" Fqdn "casarray.test.local" Site "SiteName" これでおしまい…ではないことに注意が必要です。Cas Arrayが作成されても自動的にそれが使われるようにはならないのです。きちんとDatabaseに対してCassArrayを使用するように設定を行う必要があります。具体的にはMailboxDatabaseのRpcClientAccessServer属性をCassArrayのFQDNにする必要があります。 - Set-MailboxDatabase DB1 -RpcClientAccessServer "casarray.test.local" この指定を忘れていると「CasArrayを構成しているのにCASが1台落ちたらクライアントがつながらなくなってしまった」というトラブルが発生します。しかもその時に全部のクライアントが同じ挙動になるのではなく、正常に接続できるOutlookクライアントもあれば、正常に接続できないOutlookクライアントもある・・・という状況になってしまうはずです。なぜかというと、MailboxDatabaseのRpcClientAccessServer属性は以下のように決定、設定されるからです。 - サイト内にCasArrayが存在する場合 → CasArrayが設定される - サイト内にCasArrayが存在しない場合 → MBXとCASが同居している場合 → サーバー自身が設定される - サイト内にCasArrayが存在しない場合 → MBXとCASが同居していない場合 → サイト内のCASからランダムに選ばれ設定される つまり、CasArray作成前に先行的にMailboxDBが作成され、Outlookプロファイルが作成されるとそのクライアントはCASの実ノードに接続されてしまうのです。その後CasArrayの構成を正しくやり直すと、そのあとで作られたOutlookプロファイルはCasArrayにきちんと向きますが、それ以前のものは自動では変更されません。 ...

結果がいくつあるか数える 結果がいくつあるかを数えたいケースは結構あるとおもいます。一度テキストファイルに吐き出して、エディタで開いて、行数を見て……。なんていうことは必要なく、Measure-Objectを使えば一発です。 例えば、フォルダ内のアイテム数を数えたい時には以下のようにできます。 ファイルだけ数えたければ以下のように。 フォルダだけ数えたければ以下のように。 コネクションがいくつ貼られているかを数えたければnetstatの結果を数えることができます。結果を文字列で出力するコマンドレットの結果をMeasure-Objectに渡すと、文字列の行数を数えてくれます。(厳密に行数を数えたければ –Lineオプションをつけて行数を数えるほうが「行数」としては正確です。) ESTABLISHEDな接続の数を数えたければ以下のように。 特定のIPアドレスとの接続の数を数えたければ以下のように出来ます。 CSVファイルの集計 PowerShellではCSVファイルの読み込みが非常に簡単に行えます。きちんと1行づつオブジェクトになるので、個人的には感動するレベルです。(だって、PowerShellは規定の状態でサーバーに入ってるんですから！) 以下のようなヘッダ付きのCSVを用意します。 コマンドレット一発でCSVファイルを読み込めます。 おっと、文字化けしてしまいました。これは、PowerShellがUTF-16しか読み込めないからです。UTF-16に変換する方法は色々ありますし、別途文字コード変換ツール等をつかってもらえばいいとおもいますが、PowerShellで1番簡単にできるのは以下のようにTypeを使う方法かとおもいます。。 たったこれだけでPowerShellにCSVファイルが読み込まれ、それぞれの行が1つのオブジェクトになっています。素晴らしいですね。 プロパティはStringですから、もちろん各種Stringのプロパティ、メソッドも使えます。 そして、簡単に行の集計ができます。 これだけ簡単に手軽に色々な集計ができるのはPowerShellの大きな魅力だと思います。是非皆さんも使ってみてください。

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 空き時間情報とは 「空き時間情報」は各個人(各メールボックス)の予定表情報のうち、何時から何時に予定が入っているか等の「空き時間」の情報を抜き出したものです。主に会議出席依頼を作成中にメンバーの予定表を一括で参照する際に利用されます。各個人のメールボックスの予定表のデータそのものを参照するのとは別のロジックで取得されます。 Outlookのバージョンと空き時間情報の取得方法 空き時間情報の取得方法、取得場所はOutlookのバージョンによって大きく異なります。 - ～Outlook2003 パブリックフォルダを使って空き時間情報を投稿、取得します。 - Outlook2007～ Exchange Server 2003までのバージョンに対してはパブリックフォルダを使って空き時間情報を投稿、取得します。 - Exchange Server 2007以降のバージョンに対しては可用性サービスから空き時間情報を取得します。 Outlook2003の時代(Exchange Server 2003の時代)にはパブリックフォルダから空き時間情報を取得する方法しか存在しなかったのでOutlook2003はどのバージョンのExchange Serverに接続しようとも(Exchange Server 2007, 2010であったとしても)常にパブリックフォルダに空き時間情報があるものとして動作します。Outlook2007以降は下位互換のためにパブリックフォルダに空き時間情報があるとして動作することもできますが、Exchange Server 2007以降に接続していると判断すれば可用性サービスを利用するモードに切り替わります。そのほうが色々と問題(※後述)が発生しないからです。 Exchange Serverのバージョンと空き時間情報の提供方法 Exchange Serverのバージョンによっても空き時間情報の提供方法は異なります。 - ～Exchange Server 2003 空き時間情報は管理グループに一番初めに作成されたパブリックフォルダストア内に自動的に格納場所が作成されます。便宜的に「提供方法」と書きましたが、Exchange Serverは場所を提供するだけで、後はOutlookクライアントが空き時間情報のアイテムを投稿、参照する形になります。パブリックフォルダ機能をユーザーに解放しない場合でも、システムが正常に動作するためにパブリックフォルダストアを削除することはできません。 → - Exchange Server 2007～ Outlook 2007以降のクライアントに対して可用性サービスを提供します。 可用性サービスはWebサービスです。 - Outlook 2003(以下)が存在する場合にはパブリックフォルダを作成し、空き時間情報の投稿、取得場所を提供することができます。Outlook 2007以降しか存在しない環境ではパブリックフォルダを作成しないことも選択できます。 空き時間情報の場所と動きの違い Exchange Server 2003, Outlook 2003の時代とExchange Server 2007, Outlook 2007以降とでは空き時間情報関連の動作が全くことなることがわかりました。これだけ大きな変化をさせたからには以前の方法には大きな問題があり、新しい方法ではそれが改善されているはずです。比較表がtechnetに記載されていますので以下に引用します。 空き時間コンポーネント Exchange 2003 で実行されている Outlook 2003 Exchange 2010 または Exchange 2007 で実行されている Outlook 2007 ...