<   2011年 02月 ( 25 )   > この月の画像一覧
バッチファイルをプロンプトを表示せずにバックグラウンドで実行したい
バッチファイルをタスクに仕込んで、一定間隔置きにバックグラウンドで実行するよう設定しました。
しかし、バッチファイルは実行時にプロンプト画面を表示してしまうので、ウィンドウを表示させないようにしたいという要件です。

その場合、WSH(VBScript)で、WshShell.Run メソッドで、第二引数を0にしてバッチファイルを起動するようにしてしまえば、プロンプロトを表示せずにバッチが実行できるようです。
Set WshShell = WScript.CreateObject("WScript.Shell")
'バッチ非表示実行(エラーコードも取得)
Return = WshShell.Run("C:\test.bat", 0, true)


参考:
Windowsのバッチプログラム(.bat)を実行する際、ウィンドウを表示しない方法をお教えください。- 人力検索はてな
MSDN:WshShell.Run メソッド
[PR]
by jehoshaphat | 2011-02-22 22:59 | 豆知識 | Trackback | Comments(2)
DFSが遅延した原因は。。。。

Windows Server の DFS(分散ファイルシステム) を構築してたんですが、DFS上のファイルを開くのに数十秒かかるという問い合わせが殺到しました。

たしかに自機でもファイルを開くのに時間がかかる時と、そうでない時がありました。

DFSはドメインベースで構築してます。
ドメインコントローラ(ActiveDirecotory用DNSサーバも兼用)は3台構成で、ちょうど別拠点用のドメインコントローラ(DC)の構築が終わって、配送待ちにしている状態でした。

DFSは当初2台のドメインコントローラ上に配置してので、ネットワーク負荷が原因かと思い別サーバに構築し直したり、キャッシュの時間を長くしたり、パケット解析をしたりしましたが、どうにも原因が分かりませんでした。

で、別拠点用のDCを設置すると、とたんに現象が置きなくなったのです。

原因はどうやら、そのDCをセットアップ後、設置まで電源を切っていたことのようです。

DFSの名前解決の具体的なプロセスを知らないため何とも言えませんが、おそらくDFSクライアントがDCにアクセスしに行くんだと思いますが、その時にその別拠点用のDCを参照しに行き、見つからないためタイムアウトしてから別DCに接続し、名前解決をしてファイルオープンという感じではないかなと思います。

この別拠点はサイトを分ける予定だったため、この別拠点用DCも別サイトに設定したんですが、どうやら参照されようとしていたようですね。



同様の現象は下記のようにいくつかWEBに載っていました。
@IT:DFSを利用したファイル共有でパフォーマンスが出ません DCを一台停止したら、遅くなったようです。やはりDFSクライアントが停止DCを参照してたようですね。
@IT:Win2000ServerでDFSにアクセスできたりできなかったりします


となると、もし1台DC壊れたらどうなるんでしょうか。。。その壊れたサーバをDCとして参照しないようにActiveDirectory上から削除しないといけませんが、"ドメインコントローラ 削除"でググるといろいろ方法が出てきます。しかし、結構面倒なようですね。

結局起動してないDCが原因というのは分かりましたが、具体的になぜクライアントが停止DCを見に行くのか、またそれを制御する方法が分からなかったのが心残りです。


サポートツールを入れると DFSUtil.exe というコマンドが使えるようになるわけですが、これの詳しい使い方も情報としてあまり載っていませんでした。


ただクライアントから、ドメインベースの名前空間にアクセスできるドメインコントローラを特定するには spcinfo オプションを使えばいいようです。
例えば下記のような感じだと、+のついているドメインコントローラが現在アクティブになっているものらしいです。

C:\>DFSUtil /spcinfo
[*][dc01.hogedomain.jp]
[*][HOGEDOMAIN]
[*][hogedomain.jp]
[+][HOGEDOMAIN]
[-DC02]
[+DC01]
[-DC03]
[+][hogedomain.jp]
[-dc02.hogedomain.jp]
[+dc01.hogedomain.jp]
[-dc03.hogedomain.jp]
Done processing this command.



ただDFSサーバでパケットキャプチャしてると、
NT Trans Request, NT IOCTL FILE_SYSTEM Function:0x002a, FID: 0x800f
というリクエストに対して、
NT Trans Response, FID: 0x800f, NT IOCTL, Error: STATUS_NOT_A_REPARSE_POINT(0xC0000275)
というように、レスポンスパケットでエラーを吐いています。
NTSTATUSエラーコード一覧によると、このエラーは「NTFS ファイルまたはディレクトリは再解析ポイントではありません。」とのことです。調べましたが、結局よくわからないエラーでした。。

DFSは簡単なようで結構ハマる部分が多いので、参考先、特によく寄せられる質問は熟読しておいた方がいいです。

参考先:
MS:分散ファイル システム : よく寄せられる質問
MSサポート:Windows 分散ファイル システム名前空間のアクセス エラーのトラブルシューティング方法 原因の切り分けに役立ちます(翻訳おかしいですが)
MSサポート:紹介で完全修飾ドメイン名を使用するように DFS を構成する方法
MSサポート:Windows XP クライアントの DFS クエリの頻度を制御するポリシー クライアントは15分置きにDCにクエリしてるようです。このクエリの結果がキャッシュに残り上記のDFSUtil /spcinfoで確認できるようです。

MSサポート:DFS 名前空間のサービスと Windows Server 2003 または Windows Server 2008 を実行しているコンピューターで構成データについて
Active Directory ドメインコントローラの 1台を強制的に入れ替える / DFS 名前空間を強制削除 - Nire.Com 古い DFS 名前空間情報を削除する方法です。
[PR]
by jehoshaphat | 2011-02-20 19:21 | サーバがらみ | Trackback | Comments(0)
SunRayとRDTとで画面描画速度の違い

SunRay2で画面描画が遅く残像らしきものが残る の最後の方で、SunRayとターミナルサーバやリモートデスクトップで使う RDT プロトコルの帯域の違いをちょこっとだけ説明しました。


で、機会があったので SunRay の画面描画プロトコル ALP-RENDER と RDP とでどちらがシンクライアントの画面描画のレスポンスが早いか比較してみました。
なお、SunRayはSun Ray Connector for Windows を使いWindowsターミナルサーバに接続しています。
構成としては下記のような感じです。

○SunRayを使う方法
SunRay2 DTU←(ALP-RENDER)→SunRayサーバ←(RDP)→ターミナルサーバ

○RDPを使う方法
NEC US100←(RDP)→ターミナルサーバ


結果は SunRay の方が画面描画は高速でした。
特に画像が多い画面だとその傾向が顕著でした。

やはり SunRay の ALP-RENDER はUDPで帯域を使う分画面描画が高速なのですね。
なので、LAN等帯域が太いところでのソリューションにはいいかもしれません。

逆にRDPはTCPかつ低帯域なので、WANを挟んだ場合は有利かもしれませんね。
[PR]
by jehoshaphat | 2011-02-20 19:19 | サーバがらみ | Trackback | Comments(0)
ターミナルサーバユーザがi-Filterをプロキシとして使うとなりすましができる
プロキシとしてデジタルアーツ社のi-Filter7 を Windows Server 上で使ってます。

これでユーザ認証をNTLM認証としているのですが、ターミナルサーバを利用しているユーザがi-Filterを介してWEB閲覧した場合に、おかしな現象が発生しました。

ブロックログに引っ掛かっているユーザが、実際には別のユーザだったのです。
実際に自身のアカウントでターミナルサーバにログオンし、フィルタに引っ掛かるページを表示したのですが、ブロックページの禁止メッセージには別のユーザのアカウント名が表示されていました。

つまり、ログに表示されるユーザが全く信頼おけないということです。


とりあえずデジタルアーツ社の Q&A を検索すると、「i-FILTER」の「NTLM認証」で、同じ端末からログオンユーザーの切り替えをした際に、前回ログオンしたユーザー設定が残る現象が発生するのは何故ですか。 というのを見つけました。

このページによると、i-Filter には ActiveDirectory(ドメインコントローラ)の負荷軽減のために、「Cache Time to Live」という認証情報をキャッシュする機能が有るようです。
デフォルト値が 600秒(10分) なんですが、ブラウザ起動し i-Filter 認証されてから10分間は認証情報がキャッシュされます。この時間内に別アカウトでログオンしてブロックページ表示したとしても、i-Filterは10分間キャッシュされているユーザがフィルタに引っ掛かったと判断してしまうようですね。


たしかに普通のPCなら、10分以内にログインして使うユーザはそうそう無いと思うのですが、今回のようにターミナルサーバを使ったシンクライアントで百数十人が同時使用している場合は非常に困ったことになります。

この件で、デジタルアーツのサポートにターミナルサーバでちゃんと運用できる方法は無いのかと問い合わせたんですが、キャッシュ時間を短くするしか無いとのことでした。上記Q&AにはCache Time to Liveキャッシュ時間を30秒以下にすると過負荷になる可能性があるので十分に検討しろと書いていますし、サポート担当に規模を伝えてもどれくらいの値が最適かわからないようでした。(0にはできないため1秒で利用している事例は少数ながらあるとのことでしたが、まったく使い物にならんサポートです。)
どうやらこの製品はターミナルサーバでの利用は眼中にないようですね。

おまけにこのキャッシュの時間の設定変更を行うとi-Filterの再起動をしないといけないようです。

WEB上でキャッシュ時間の設定変更だけしておいて、i-Filterサービスを再起動するだけで構わないようなので、業務時間中に設定してバッチファイルでサービスの再起動をしてやる方法が使えます。(この点もサポート担当に聞いてみたんですが要領を得ない回答でしたね。)
[PR]
by jehoshaphat | 2011-02-20 19:17 | サーバがらみ | Trackback | Comments(0)
desknet'sでURLにログイン情報を埋め込める

グループウェアのdesknet's(デスクネッツ)を使ってるんですが、URLにログイン情報を埋め込めるようです。
つまり、ログイン情報を埋め込んだショートカットを張っておけば、ログイン画面をすっ飛ばせるわけですね。

セキュリティ的には非常にまずい仕様な気がしますが、一応形式を書いておきます。

https://xxxx.xx.xx/cgi-bin/dnet/dnet.cgi?cmd=certify&userid=ログインID&_word=パスワード
[PR]
by jehoshaphat | 2011-02-20 19:07 | 豆知識 | Trackback | Comments(0)
WindowsServer 2008 R2 のHyper-V上のライセンス

WindowsServer2008 や WindowsServer2008 R2 は、ライセンスにHyper-V上の仮想インスタンスも含んでいます。

例えば WindowsServer2008 Standard エディションだと仮想インスタンスのラインセス数1、Enterprise になると仮想インスタンス数4 となります。

どうもいまだにこれを勘違いしているSEもいるようで。。。(取引先のSEなんですが。。。)

これは仮想インスタンス(仮想マシン)自体が一つもしくは4つしか動かせないというわけではありません。

ホストOSに Standard エディションを使っていると、その物理ライセンスで、仮想インスタンス(WindowsServer2008 Standardエディション)が一つ実行できるということです。
つまり、仮想マシン用のWindowsライセンスを買わなくても一つなら物理ライセンスで動かせるというわけですね。
(もし、仮想マシンで WindowsServer2008 Standard を5つ動かすなら、残り4つのサーバOSライセンスは購入する必要があります。)

なので、仮想インスタンス自体はサーバスペックが許す限り無制限に配置できます。


ちなみに、物理ライセンスに付属の仮想インスタンス用ライセンスは、物理ライセンスと同じエディションで無いといけません。
ホストOSが Enterprise エディションなら、仮想インスタンスも Enterprise エディションにしないといけません。


また、仮想インスタンスに物理ライセンスを使ってWindowsServer2008をインストールしたのですが、プロダクトキーにハマりました。
ホストOSインストール時のプロダクトキーを入力したのですが、エラーになります。

プロダクトキーは仮想インスタンス用のものがあるので、そっちを使わないといけないようです。
そのキーは、プロダクトキーが書いているシール(COAラベル)の横の方に VirtualKey(仮想キー) として表示されています。

ラックサーバとかだと容易に確認するのが難しい場合もあるので、設置時にVirualKeyも必ず確認するようにしておいた方がいいですね。


注意点として、物理インスタンス付属のラインセスで仮想インスタンスを使った場合、その仮想マシンを別の物理サーバ上のHyper-Vに移動した時に、移動先で既に制限数まで物理インスタンス付属のライセンスで仮想インスタンスを動かしている場合は移動は無理なようです。
ここら辺の詳しい話は、参考先のMSのページで説明されています。


参考:
Windows Server 2008 早わかりライセンス ガイド : 仮想環境とライセンス : エディションごとのライセンスの違いは?
Windows Server 2008 Hyper-V のライセンス: Microsoft Virtualization
Dell PowerEdge システム用Microsoft Hyper-V重要情報ガイド
[PR]
by jehoshaphat | 2011-02-17 23:48 | サーバがらみ | Trackback | Comments(0)
ターミナルサービス構成のセッション制限時間は手打ち入力が可能
ターミナルサーバを動かしているサーバで、ターミナルサービス構成 の RDP-Tcp のプロパティ → セッション タブでセッションタイムアウトの設定ができます。
ここの設定はコンボボックスになっていて時間を選べるんですが、当初ここは選べるだけと思ってました。
デフォルトで用意されている項目は しない,1分,5分,10分,15分,30分,1時間,2時間,3時間,1日,2日 しかありません。
しかし、手で値を入力できるようです。
例えば [5時間] といった感じです。

たまにこの設定に意味を忘れるのでメモしておきます。

・ユーザ設定より優先にする(切断されたセッションを終了)
 ActiveDirectoryの各ユーザアカウントにも同様の設定ができますが、これにチェックを入れるとサーバの設定が優先されるようです。

・切断されたセッションを終了
 ターミナルサービスでセッションを切断した場合(リモートデスクトップで×ボタンで閉じたときとか)に、どれくらい時間が経てばセッションを終了(強制ログオフ)するかを設定するようです。

・アクティブなセッションの制限
 セッションの最大可能時間を設定します。つまりターミナルサーバにログオンしててもこの時間が経つとセッションの切断もしくは終了させられます。

・アイドルセッションの制限
 アイドルつまりターミナルサーバにはログインしてるけど、操作してない場合、この時間が経つとセッションの切断もしくは終了させられます。


・ユーザ設定より優先にする(セッションの制限に達したり接続が中断した場合)
 ActiveDirectoryの各ユーザアカウントにも同様の設定ができますが、これにチェックを入れるとサーバの設定が優先されるようです。
この下の項目で、セッションの制限に達したり、接続が中断した場合に、セッションを切断するか終了するかを選択できます。

参考:
リモート・デスクトップの接続時間を制限する - @IT
[PR]
by jehoshaphat | 2011-02-17 23:45 | サーバがらみ | Trackback | Comments(0)
Windowsサーバのパフォーマンス測定
Windowsサーバの負荷状態を調べるために、パフォーマンスモニタ(パフォーマンスカウンタとも言う)でチェックすることになりました。

とりあえず調査したいのはサーバ全体(特定のプロセスとかではない)での CPU,メモリ,HDD I/O,ネットワークI/O の負荷です。

●CPU
まずCPU負荷をみるための項目です。
Processor\%Processor Time
これはタスクマネージャのCPU使用率と同義です。
正確には「プロセッサがアイドル以外のスレッドを実行するために使用した経過時間の割合をパーセントで表示します。」という意味のようですね。
85%を超えるようだとボトルネックの可能性があるようです。
値の上限は複数CPU選んでも、100(100%)のようです。


Processor\%Interrupts/Sec
これは1秒当たりのハードウェア割り込み回数を表します。
この値が普段より大きい場合は、ハードウェア割り込みが頻発し、そっちにCPUリソースを取られている可能性があるようです。
怪しいデバイスドライバを無効にして、どのデバイスドライバが原因か突き止めないといけませんね。

System\Processor Queue Length
CPU処理を待つスレッド数を表します。
継続して 2 以上の値になっている場合、プロセッサがボトルネックの原因の可能性があるようです。


●メモリ
Memory\Available MBytes
物理メモリの空き領域です。足りないとスラッシングになってしまい、激しくパフォーマンスが低下します。
使用可能のメモリが最低 4 MB または 5% 以上であることが望ましいようです。

Memory\Page/sec
ハードページフォルトの1秒あたりの回数です。
これが起きるとHDD上のページファイルにアクセス(ページング)が発生してます。
多発(20を超える)してる場合は物理メモリが足りてない可能性がありますね。


Memory\Committed Bytes
システム全体で利用されているメモリの使用量(HDD上のページファイル含む)です。
OSで設定してる仮想メモリサイズに限りなく近づいてるとまずいですね。


●HDD I/O
Physical Disk\%Disk Time
ディスクアクセス時にビジーだった時の割合、つまり、ディスクからの読み取り、書き込みを含むアクセス時間の割合です。
MSによると、「常に数値が 80 % 以上の場合、メモリリークの可能性がある。」だそうです。
しかし、参考サイトによると「ただし、この値が高い場合でも、必ずしもディスクがボトルネックというわけではない。例えば、低速なネットワークを利用している場合、ディスクから効率よくデータを読み書きできなくなる。」とのことです。
ディスクの不調という原因も考えられるようですね。


Physical Disk\Current Disk Queue Length
ディスクへのアクセス待ち要求数です。
継続して2つ以上のアクセス待ちがある場合はボトルネックの可能性が高いようです。
注意点として、参考先には「なお、このカウンタをすべてのディスクで計測すると、すべてのディスクでのアクセス待ち数が表示されるので注意してほしい。例えば、4つのディスクでそれぞれ1つずつアクセス待ちがあれば、Current Disk Queue Lengthカウンタには「4」という値が出力される。」とありました。

PhysicalDisk\% Read/sec,PhysicalDisk\% Writes/sec
ディスクの読み込み、書き込み速度になります。
最近の一般的なHDDなら70-100くらいはあるんじゃないでしょうか。RAIDを組んで、サーバ用の高速HDDだともっと速いかもしれません。


●ネットワーク I/O
Network Segment\%Net Utilization ネットワークの利用率です。高いならより高速なNIC、ネットワークインフラに変更することを検討した方がいいかもしれません。
Ethernetネットワークでは30%以上はボトルネックと判断するようです。

Network Interface\Bytes Total/Sec
NICの1秒間の送受信バイト数です。
ネットワーク利用が増えるとハードウェア割り込みが増えるので、Interruptsカウンタや、Processor Timeカウンタが増えるようです


Network Interface\Packets/sec
NICの1秒間の送受信パケット数です。
Bytes Total/Secと合わせてみることで、サイズの大きいパケットが多いのかどうかを調べることができますね。



参考:
パフォーマンスモニタ徹底攻略マニュアル[2]パフォーマンスモニタの見極めポイント : Windows Server - Computerworld.jp
Windowsパフォーマンスモニタ
MS:パフォーマンスカウンタ クイック ガイド
3流プログラマのメモ書き : Google Desktop でシステムモニタガジェットを追加するとCPU使用率が上がる(前編) Processor \ % Processor Time と Process \ % Processor Time の違いにご注意。後者はコア数が増えると上限が200%とか400%とかなります。
3流プログラマのメモ書き : メモリ使用量の調査。用語メモ書き… メモリについてはこっちの方が若干詳しく書いてます。
TechNet:パフォーマンス データを分析する しきい値等詳しく載っています。
[PR]
by jehoshaphat | 2011-02-17 23:43 | 豆知識 | Trackback | Comments(0)
IE8を入れたらおかしくなった
Windows Server 2003 で、WindowsUpdateでIE8とその他もろもろのパッチを入れて再起動すると、IEがおかしくなりました。
IE8入れたはずなのに、IE6になっています。

IE操作時に「序数423がダイナミックライブラリ urlmon.dll から見つかりませんでした。」とか「C:\WINDOWS\system32\muweb.dll を読み込み中にエラーが発生しました。このオペレーティングシステムでは %1 は実行されません。」というエラーダイアログが表示され、WEBページが表示できません。


一回コンパネよりIE8をアンインストールして、再度IE8を単体で入れれば治りました。

全く驚きましたよ。
[PR]
by jehoshaphat | 2011-02-17 23:41 | 豆知識 | Trackback | Comments(0)
ローカルブリッジ設定Linux版UT-VPN ServerでVPNクライアントからサーバにアクセスする方法

UT-VPNのローカルブリッジとSecureNATで書きましたが、Linux版 UT-VPN Server でローカルブリッジを設定すると UT-VPN クライアントからローカルブリッジしているサーバのIPアドレスにアクセスできません。

マニュアルによるとこれはLinuxの制約のようです。

しかし2枚もNICをさす余裕がないので、何とか一枚のNICでローカルブリッジしているサーバのIPアドレスにアクセスできないか考えました。
そこで成功したのが下記の方法です。

ローカルブリッジ作成時に物理的な NIC eth0 にブリッジするのではなく tap デバイス(仮想NIC)にブリッジさせます。
そしてその tap デバイスと物理 NIC eth0 を Linux 内部でブリッジさせるわけです。
構成図は下記のような感じです。
e0091163_23514172.jpg


UT-VPN Server のローカルブリッジ設定画面で、ブリッジ先の設定で新しい tap デバイスを作成しブリッジ接続できるようです。
e0091163_23515713.jpg


UT-VPNによってローカルブリッジされた tap デバイスと物理NICとのブリッジ接続方法は、Linuxでネットワークカードをブリッジするを参考してください。


これでUT-VPNクライアントからUT-VPN Server を動かしているサーバのIP(上記構成図だと192.168.1.10)にアクセスできるようになりました。
[PR]
by jehoshaphat | 2011-02-15 23:52 | ネットワーク | Trackback | Comments(0)