現象

サーバ側Exchange Server 2010 (SP1)、クライアント側Outlook 2003 (SP3)の環境で、Outlook側で[送受信]ボタンをクリックするなどしてサーバと同期すると、メールの受信等は行えるものの、エラーが発生する。同期ログには「Microsoft Exchange オフライン アドレス帳 0X8004010F」のエラーメッセージが残されている。

対処法

　まず前提として、Exchange Server 2010 のセットアップ中に「組織内に Outlook 2003 または Entourage を実行するクライアント コンピュータはありますか?」との問いに[はい]と答えておく。[いいえ]と答えてしまったときは、セットアップ完了後、Exchange Serverヘルプの「パブリック フォルダーについて」と「パブリック フォルダー データベースの作成」を参照して別途パブリックデータベースを作っておく。もっとも、これをしないとOutlook起動時に「Exchange サーバー管理者が、使用しているバージョンの Outlook をブロックしています。」と出てそもそもまったく接続できないのだが。
　そのうえで、サーバ側のExchange Management Console(EMC)にて次のように設定。

1. ツリーで[組織の設定]-[メールボックス]をクリック。
2. 右ペインの[データベースの管理]タブをクリック。
3. 上ペインの[Mailbox Database …]の行を右クリックして[プロパティ]をクリック。
4. [クライアントの設定]タブをクリックし、[オフライン アドレス帳]の[参照]をクリックして[既定のオフライン アドレス帳]を選択して[OK]をクリック。[OK]をクリックして[Mailbox Database … のプロパティ]を閉じる。
5. 右ペインの[オフライン アドレス帳]タブをクリック。
6. [既定のオフライン アドレス帳]行を右クリックして[プロパティ]をクリック。
7. [配布]タブをクリックして次のものにチェックを入れ、[OK]をクリックする。
   • [Outlook 2003 SP2 またはそれ以降 (Version 4)]
   • [Web ベースの配布を有効にする]
   • [パブリック フォルダーの配布を有効にする]
8. [既定のオフライン アドレス帳]行を右クリックして[更新]をクリック。表示されたダイアログボックスで[はい]をクリック。

　最後にOutlookを再起動して試してみる。

所感

　KB905813に、「この資料は以下の製品について記述したものです」に入っているにもかかわらずExchange Server 2010向けの手順が載っていないのはいかにも不親切。いや、そもそも別の問題なのだろうか。なんだかよくわからない。

現象

Windows UpdateにてWindows Internal Database Service Pack 4 for x64 Edition (KB2463332)のインストールが失敗する。エラーコードは643。

原因

(同じKB2463332でもMicrosoft SQL Server 2005 Service Pack 4となっているものには通常当てはまらない。)
%SystemRoot%\SYSMSI以下にあるWindows Internal DatabaseのディレクトリがNTFS圧縮されているとService Packのインストーラがインストールを拒否するため。

対処法

%SystemRoot%\SYSMSI以下のNTFS圧縮を解除する。
(追記)……とだけ書いておいたところ、この記事を見た直後に「%SystemRoot%\SYSMSI以下のNTFS圧縮を解除する」という検索語で検索する人が続出。これはおそらくこの文の意味がわからなかったということではないかと思われ。
　具体的な手順としては、エクスプローラ等で通常C:\Windows\Sysmsiフォルダ(Windowsをインストールしたドライブが違うときはC:をその別のドライブに置き換えて読むこと)のプロパティを開き、[詳細設定]をクリックして出てくる画面の[内容を圧縮してディスク容量を節約する]チェックボックスを外して[OK]をクリックする。それでもし[属性変更の確認]画面が出てきたときは[変更をこのフォルダー、サブフォルダーおよびファイルに適用する]を選択して[OK]。

所感

　Windows Internal Databaseは実質SQL Serverです。で、SQL Serverのデータファイルは圧縮しないほうがパフォーマンスがいいので、SQL ServerのService PackはSQL Serverのディレクトリが圧縮されていると、その旨のエラーを出して終了する仕様になっています。Windows Internal DatabaseのService Packも実質SQL ServerのService Packと同等の内容で、そのためにこのような現象が起こるのだと思われます。Windows Updateでは一切のメッセージが抑止された状態でインストールが進むので、エラーの中身がわかりづらいわけですね。
　システムドライブは容量がひっ迫しがちであって、圧縮されている状況は一般的ですから、Windows Internal Database向けService Packとしては、本来、圧縮されていてもエラーにならないように仕様変更したものをリリースすべきでした。システムドライブが圧縮されている状況でテストしなかったのでしょうね。
　もっとも、そもそもディレクトリが圧縮されていたらエラーにするというSQL Server Service Packのインストーラの仕様自体やりすぎなのだと思われます。パフォーマンスは悪いながらも動くには動くのであって、ユーザがそれを承知で動かしているならインストーラが文句を言う筋合いのものではないのですから。
　しかもさらに問題なのは、この仕様がドキュメント化されていない(!)ということ。だから同じMicrosoftの社員であろうところのWindows Internal Database Service Packの担当者(たぶんSQLSPの担当者とは違う)すらこの仕様を把握できなかったわけです。Microsoftはこの手のドロナワ式仕様追加が昔からやたらと多い会社で、もうこれはこの会社の体質なんでしょうねえ。

追記

　同様の原因によりWindows Update エラー 6d9eで失敗するケースもあるらしいことが記事として掲載されているようなんですが、うちではそういうエラー番号ではありませんでした。まあ、この記事で説明されているのはWindows Internal Database扱いのService Packではないし、SP3ですからね。
　リンクをたどると、圧縮されているとエラーになるという問題について説明したサポートエンジニアのMSDNのブログ記事がありますが、こんなところに書き散らさないできちんとknowledge base(サポートオンライン)に登録すべきではないでしょうか。MSはどこまでだらしなくなるのでしょう。ドキュメントに対する態度は年々ひどくなってます。

　SUAには標準ではbashがない。
　古～いバージョンならバイナリも配布されていたらしいものの、それはちょっと……ということで、ソースから最新版をビルドしたいわけだったのだが、bash 4.1のときはあれこれ苦労したあげく、64bit環境であることがよくないのか、なぜか$(…)形式の展開だけsyntax errorになる(`……`形式は動くのに)という不可解な動作をするバイナリしか作れなかった。しかし最近出たbash 4.2ではあっさりと動くようになっていた。
　わずかにひっかかるのは次の２点。

1. 相変わらずconfigureでシステム名を認識せず、「configure: error: cannot guess build type; you must specify one」と言われるので、support/config.guessとsupport/config.subを最新版(config.guess/config.sub)に入れ替える。
2. ログインシェルとして使うとき、そのままだとlessなどがWARNING: terminal is not fully functionalと警告を出してマトモに動こうとしない状態になる。bash起動時、環境変数のTERMに空文字列が設定されなければならないところがdumbという文字列が設定されてしまうために/etc/profileのTERMを設定する部分がうまく動いていないのが原因で、ワークアラウンドとしては、起動時のコマンドラインをC:\Windows\posix.exe /u /c /bin/bash -c "TERM= /bin/bash --login -i"のようにする。TERM= と/bin/bashの間にスペースが入っているのに注意。

　まだmake testsで少しエラーは出るのだが、4.1のときの惨憺たる結果に比べれば上出来。

　これで使い慣れたUNIX環境に一歩近づいたわけだが、ただSUAそのものは、全体的に動作がもっさりしている上に、時々ひっかかるように十秒くらい動作を停止するようなときもあり、まだUNIX環境として実用レベルと言いがたいところがある。

　opensslのライブラリ(libcrypto)にはlibdes互換機能がついていたが、openssl-0.9.7からそれがdes_old.hによる置換マクロのみの対応となり、libdes互換のためのシンボルは存在しなくなった。このため、libcryptoを共有ライブラリ(libcrypto.so)の形で動的リンクしてlibdes互換機能を利用していたプログラムの場合、openssl-0.9.6からopenssl-0.9.7以降に更新するとバイナリ互換性が失われ、des_cbc_encryptなどいくつかのシンボルが見つからないというエラーが発生するようになった。
　当方の場合、opensslをアップデートしたところ、OS(古いRedHat)にバイナリでインストールされているcyrus-saslパッケージに入っているlibdigestmd5.soが参照しているdes_cbc_encryptなどがundefined symbolとなってしまった。これを使っているpostfixのsmtpdがdlopenするときに、/var/log/messagesに「unable to dlopen /usr/lib/sasl2/libdigestmd5.so.2: libcrypto.so.2: cannot open shared object file: No such file or directory」というエラーを吐く。
　LD_PRELOADで逃げる手も試したがdlopenには効かないようであった。opensslには深刻な脆弱性が見つかっているので、0.9.6のまま使い続けるというわけにもいかないし、そうかといって、再コンパイルしようとすると依存しているバイナリやライブラリを芋づる式にコンパイルしていかなければならなくなりそうで手がつけられない。
　メジャーバージョンアップでもないのにまったくとんでもない仕様変更をしてくれたものだが、変わってしまっているものは仕方がないので、以下のようにしてなんとか強引に対処した。

openssl-0.9.8r:
% ./config shared -DOPENSSL_DES_LIBDES_COMPATIBILITY
% make
% make test
# make install
# cd /lib
# ln -s /usr/local/ssl/lib/libcrypto.so.0.9.8
# ln -s /usr/local/ssl/lib/libssl.so.0.9.8

libdes-4.04b:
% patch < des.Makefile.diff # libdes.so.3を作りたいときのみ。
% make

適当なディレクトリで:
% gcc -shared -Wl,-soname,libcrypto.so.2 -o libcrypto.so.2 -Wl,--whole-archive libdes.aへのパス libcrypto.aへのパス -Wl,--no-whole-archive -ldl -Wl,-noinhibit-exec
# cp libcrypto.so.2 /usr/lib/sasl2
# cp smtpd.libdes /usr/libexec/postfix
# chown root.root /usr/libexec/postfix/smtpd.libdes
# chmod 755 /usr/libexec/postfix/smtpd.libdes
# vi /etc/postfix/master.cf

smtp inet n – n – – smtpd
とある行(chrootの列は標準ではyだけど)を
smtp inet n – n – – smtpd.libdes
に変更。

# /sbin/service postfix restart

　若干の間違いはあるかもしれないが、大体こんな感じ。
　要するにlibdes.aとlibcrypto.aをくっつけて一つの共有ライブラリを作っているのだけど、シンボルが重複してエラーになるのを-noinhibit-execで無理やり無視させたりして、かなり強引。なんとなく動いているように見えるだけで、実は中の動作はめちゃくちゃかも。
　こんな怪しいライブラリを標準のライブラリのサーチパスに入れておくのは危険なので、上記の通り、smtpdだけに適用するsmtpd.libdesというスクリプトを作った。

注: この記事は個人的なメモです。真似するのは自由ですが無保証です。

　Windowsのシステムドライブの容量が苦しくなってくると、%systemroot%\installer(典型的にはC:\Windows\installer)のサイズがバカみたいに大きいのが気になって、別のドライブに移したくなる人も多いだろう。そして、Windowsに慣れている人ならば、その手段としてlinkd.exeを使えばいいんじゃないかと思いつく人もいるだろう。実際、軽く検索してみるとそれを実行してうまくいったというレポートもある。ところが、さらに詳しく調べると、実はこれがとんでもない罠らしいのだ。
　別ドライブにディリクトリを移動してlinkd.exeで%systemroot%\Installerにジャンクションを作った直後はうまく動いているように見える。ところが、新しくアプリケーションをインストールすると、Windows Installerがそのディレクトリの中身を全部削除して空っぽにした上でジャンクションを解除し、普通のディレクトリとして作りなおすらしい。こうなると、当然既にインストールされているアプリケーションのアンインストールは一切できなくなるとのこと。
　なんでマイクロソフトはこんないやがらせみたいな仕様にしたんだろう?

diskcach.exeについてのコメント等はこちらのコメント欄へ。

現象

　Windows Server 2008 R2で、MSKKのサイトに書かれているとおり、サーバーマネージャから「デスクトップ エクスペリエンス」の機能をインストールしてあり、かつ「Themes」サービスも起動してあるにもかかわらず、[個人設定]画面でAeroテーマを選択できない(グレーアウトしている)。

対処方法

　コントロールパネルの[システム]から[システムの詳細設定]をクリックで表示できる[システムのプロパティ]画面で、[詳細設定]タブの下にある[パフォーマンス]の[設定]をクリックし、[視覚効果]タブの下にあるラジオボタンでいったん[パフォーマンスを優先する]を選択して[適用]ボタンをクリックしてから[デザインを優先する]をクリックして[適用]ボタンをクリックする。

参照

win2008workstation.com A few issues…

大屋雄裕氏の講演に対する高木浩光氏の批判

　この中で高木氏の発言として

…そんなものは決められないし、必要ない。今回の中川氏の事案は「これ以下ならやっていい」の1つである通常のWebクローラの水準（シリアルアクセスかつ1秒に1、2回程度）を満たしていた。実際、三菱電機IS側も、Googlebotを排除するなど、その水準に堪えら…

とありましたが、Webクローラというのを検索エンジンのそれに限定するならば、そういうアクセスはむしろかなり高速に属すると思われます。

　このサイトに対するここ一ヶ月ほどの、User Agentから見て検索エンジンによると見られるクローラアクセスの記録(をUser Agentのカラムでソートしたもの)を見ると、メジャーどころのクローラは大抵数分から数時間に一回程度の頻度でアクセスしていることがわかります。gooはかなり速いですがそれでも数秒に1回ですね。
　公平のためこのサイトについての注意点を。

• 規模が小さい。
• 全体としては更新頻度が低い。
• まあまあ更新されているwordpress部分は動作が遅く、1ページ表示するのに1秒以上かかる。
• サーバ回線部分はADSLなので上りが遅い。

　gooが数秒に1回なのはシリアルアクセスだからなのかも知れず、こっちの応答が速ければ1秒に1～2回という頻度になることもあり得るのかも知れません。

　ただ、元の事件にしても、シリアルアクセス(結果が返ってから次のページを要求する)という条件下であれば、ある程度間隔が空いていない高速アクセスであっても、必ずしも過剰に負荷がかかると認識しうるものでないかとは思います。

現象

　Windows Server 2008 R2上で、DNSサーバーの管理ツールの[<サーバー名>のプロパティ]画面の[監視]タブのところの[テストを実行]をクリックすると、単純クエリ、再帰クエリとも「不可」となる。
　通常のDNSの動作やdnscmd /IpValidate /DNSServersには異常がない。
　この問題は、同画面の[インターフェイス]タブのところで[指定したIPアドレスのみ]が選択されているときのみ起こる。

　Windows Server 2003でも同様の問題が起こるらしい(ただしdnscmd /IpValidateはサポートされていない)。

対処法

　ネットワーク接続のプロパティ画面(ネットワークのプロパティとして出る「ネットワークと共有センター」から[アダプターの設定変更]クリックで出る)の[詳細設定]-[詳細設定](WS2008R2では[Alt]を押さないとメニューバーが出てこないので注意)にある[アダプタとバインド]タブの[接続]のところで、前述の[指定したIPアドレスのみ]で指定されたIPアドレスを持つNICを一番上に持ってくる。

参照

NIC複数挿しマシンのDNSサーバ (Windows Server フォーラム)

所感

　こんなの、本来はバグですけどね。

症状

Windows Serer 2003にてWINSをインストールしようとすると、インストールに予想より時間が掛かっている旨の警告メッセージが出て終了する。それでも一応インストールは終わっているので、WINSの管理ツールでサーバを追加し、サービスを起動しようとすると、失敗する。イベントビューアでシステムログをみると、次のようなログが記録されている。

イベントの種類: 情報
イベント ソース: Wins
イベント カテゴリ: なし
イベント ID: 4106
ユーザー: N/A
コンピュータ: COMPUTER
説明:
名前からアドレスのマッピングの WINS データベースが空です。 これは、前回 WINS を起動したときにデータベースが作成され、登録が 行われる前に異常終了したことを意味している可能性があります。

詳細な情報は、http://go.microsoft.com/fwlink/events.asp の [ヘルプとサポート センター] を参照してください。
データ:
0000: 31 1b 00 00 00 00 00 00 1.......


イベントの種類: 情報
イベント ソース: Wins
イベント カテゴリ: なし
イベント ID: 4107
ユーザー: N/A
コンピュータ: COMPUTER
説明:
所有者からアドレスのマッピングの WINS データベースが空です。これは、前回 WINS を起動したときにテーブルが作成され、エントリの追加が行われる前に 異常終了したことを意味している可能性があります。WINS サーバーは、スレッド の準備ができないうちにすばやく異常終了したと思われます。

詳細な情報は、http://go.microsoft.com/fwlink/events.asp の [ヘルプとサポート センター] を参照してください。
データ:
0000: 2a 14 00 00 00 00 00 00 *.......


イベントの種類: エラー
イベント ソース: Wins
イベント カテゴリ: なし
イベント ID: 4193
ユーザー: N/A
コンピュータ: COMPUTER
説明:
WINS は通知ソケットを作成できませんでした。TCP/IP ドライバが正しく インストールされ、動作しているかどうか確認してください。

詳細な情報は、http://go.microsoft.com/fwlink/events.asp の [ヘルプとサポート センター] を参照してください。
データ:
0000: da 01 00 00 fc 2a 00 00 Ú...ü*..

イベントの種類: エラー
イベント ソース: Service Control Manager
イベント カテゴリ: なし
イベント ID: 7024
ユーザー: N/A
コンピュータ: COMPUTER
説明:
Windows Internet Name Service (WINS) は次のサービス固有のエラーで終了しました: 3758096386 (0xE0000002)

詳細な情報は、http://go.microsoft.com/fwlink/events.asp の [ヘルプとサポート センター] を参照してください。


原因と解決方法の一例

　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parametersにある「DataBasePath」の値の種類が「REG_EXPAND_SZ」でなければならないところ、「REG_SZ」で作成されている。
　一旦当該値を削除して「REG_EXPAND_SZ」で作り直す。なお、データは通常「%SystemRoot%\System32\drivers\etc」に設定されている。

参照

EventID.net Event ID 4193 Source Wins Enrique Hernandez 氏コメント

所感

こんなアホな値を追加したプログラムは一体どこのどいつだ!!