Archive for 12月, 2010
ワークグループ環境の Outlook で OAB がダウンロードできない
今日は久しぶりに Exchange 2010 を触っていました。
ちょっとクライアント側で調べたいことがあったので、Windows 7 + Outlook 2010 の環境を作ってテストしていました。
メールの送受信はできていたのですが、オフラインアドレス帳 (Offiline Address Book : OAB) をダウンロードしようとしたところ以下のエラーが。
クラスタ環境の SQL Server 2005 に SP4 をインストール
先日、SQL Server 2005 SP4 が提供されました。
Microsoft SQL Server 2005 Service Pack 4 RTM
Windows Server 2008 のクラスタ環境にインストールした SQL Server 2005 にサービスパックを適用する場合には注意点がありますのでまとめてみたいと思います。
# 2008 以外でも発生するかもしれません。(2003 では発生しなかった気もするのですが)
SQL Server 2005 のメインストリームサポート終了日が [2011/04/12] と半年を切っており最新のサービスパック適用の機会があるかもしれないので軽く書いておこうかと。
今回は SP4 を対象としてまとめていますが、SP1 ~ SP3 , Cumulative Update に関しても同様の手順が必要になります。
# CU に関しては、発生するかは更新内容によって変わると思うのですが。
クラスタ環境で SQL Server 2005 のサービスパックをインストールする場合は、SQL Server のリソースを保持しているノードでサービスパックのインストールを実行します。
SQL Server のリソースを保持していないノードでサービスパックのインストールを実行しても、[MSSQLSERVER] (SQL Server ノーサービスコンポーネント) は選択をすることができません。
クラスタ環境の SQL Server 2005 でサービスパックをインストールすると [データベース サービス] のインストールで失敗する場合があります。
インストールの失敗ですが以下の技術情報が該当します。
An error message is logged in the Summary.txt file when a SQL Server 2005 service pack, cumulative update or cluster hotfix installation fails: "The Transaction Manager is not available"
SQL Server 2005 のサービスパックのインストールログですが以下のディレクトリに出力されます。
[C:Program FilesMicrosoft SQL Server90Setup BootstrapLOGHotfix]
このディレクトリの中に、[Summary.txt] がありますので、このファイルの内容を確認してみます。
Product Installation Status |
データベース サービスで [正常に修正プログラムが適用されたパッシブ ノードはありません] のエラーが出力されています。
このログは [アクティブ ノード] (SQL Server のリソースを持っているノード) のログになりますので、パッシブ ノードでもログを確認してみたいと思います。
# ログはアクティブ ノードと同じディレクトリに出力されています。
Product Installation Status |
今回の現象ですが、パッシブ ノードで [データベース サービス] のサービスパック適用に失敗しているのではなく、[クライアント コンポーネント] に対してのサービスパック適用で失敗しています。
この現象ですが、[クラスタの MSDTC のリソースをクライアント コンポーネントの適用が実行されているノードが所有していない] と発生します。
DTC と SQL Server のリソースを [2008-CLS-01] というサーバーで所有させていました。
この状態でサービスパックを適用したため今回の現象が発生していました。
■Windows Server 2008 のクラスタ環境に SQL Server 2005 のサービスパックを適用
ここからが本題で適用するための手順になります。
[2008-CLS-01] でサービスパックのインストーラーを起動するため、SQL Server のリソースは [2008-CLS-01] に配置しています。
DTC のリソースは [2008-CLS-02] (SQL Server から見てパッシブ となっているノード) に配置しています。
この状態でサービスパックのインストーラーを実行します。
- [次へ] をクリックします。
- [同意する] を選択して、[次へ] をクリックします。
- 適応するコンポーネントを選択して、[次へ] をクリックします。
- リモート ユーザーのアカウント情報を入力し、[次へ] をクリックします。
パッシブ ノード側ではここで指定したアカウントを使用してサービスパックの適用が実施されます。 - [次へ] をクリックします。
- [次へ] をクリックします。
- [インストール] をクリックして、インストールを開始します。
インストールをクリックするとパッシブ ノードのタスク スケジューラに [SqlNodeInstall] といタスクが作成され、パッシブ ノードでサービスパックのインストールが開始されます。
このタスクを使用して、インストーラー実行時にパッシブノードの [C:UpdateTemp] にコピーされたサービスパックのプログラムが実行されます。
パッシブ ノードのタスクマネージャーを確認すると [msiexec.exe] や [hotfix.exe] が起動されていることが確認できます。
インストールを開始してしばらくしているとパッシブ ノードで以下のダイアログが表示されます。
# パッシブ ノードにサービスパックのインストール時に指定したアカウントでログオンしておく必要があります。
Windows Server 2008 + SQL Server 2005 の場合、VS 2005 がプログラム互換性アシスタントの警告対象となります。
DTC をパッシブ ノードで実行している場合は、このダイアログが表示できるのですが、アクティブ ノードで DTC を実行している場合はこのダイアログが表示されません。
そのため、クライアント コンポーネントのアップデートができずにエラーとなってしまうようです。
クライアント コンポーネントはアクティブ / パッシブのノード両方でインストールする必要があります。
そのため、アクティブ ノードでクライアントコンポーネントのアップデートが実行される際には、DTC のリソースはアクティブ ノードで実行しておく必要があります。
上記のダイアログがパッシブ ノードで表示されたら、クラスターの管理コンソールを開き、リソースの配置を以下の用に変更しておきます。
# DTC のリソースを [2008-CLS-02] → [2008-CLS-01] に移動しました。
DTC の配置が終わったら、[プログラムを実行する] をクリックします。
# アクティブ ノードでクライアントコンポーネントの適用が実行される前までに DTC のリソースを移動しておけば問題ありません。
パッシブ ノードでインストールが終了すると、アクティブ ノードでインストールがされます。
アクティブ ノードでも [クライアント コンポーネント] のインストールが実行されるタイミングで、プログラム互換性アシスタントのダイアログが表示されますので、[プログラムを実行する] をクリックします。
# アクティブ ノードで DTC のリソースが実行されていないと今度はアクティブ ノードでインストールが失敗します。
この手順でインストールをするとサービスパックの適用が正常に完了します。
SQL Server 2005 のサービスパックをクラスタ環境に適用する場合はクラスタの DTC リソースの配置状況に注意する必要があります。
この現象ですが、[クライアント コンポーネント] の更新が入らない場合は発生しないので、CU の適用時にはクライアントコンポーネントが更新対象として含まれていなければ失敗はしないと思います。
第 1 回 Get The Fact セミナーの振り返り その 6
今回は [データベースの整合性確認] について振り返っていきたいと思います。
[メンテナンス プラン ウィザード] では、 [データベースの整合性確認] のメンテナンス タスクを作成することが可能です。
このタスクを実行するとデータベースの整合性をチェックすることができます。
セミナーの中では、バックアップの取得前等に実行をすることでデータベースに問題が無いかを確認しバックアップを取得することが可能というようなお話がありました。
今回は、この整合性確認についてまとめていきたいと思います。
■データベースの整合性確認で実行される内容
まずはデータベースの整合性確認のタスクで実行される内容について確認していきたいと思います。
作成したデータベースの整合性確認のタスクで実行される T-SQL を確認してみます。
データベースの整合性確認のタスクでは、実行対象として指定したデータベースに対して [DBCC CHECKDB] が実行されます。
# [インデックスを含める] を外すと [NOINDEX] オプションを指定して実行されます。
以下は、BOL の DBCC CHECKDB の記載内容の引用になります。
次の操作を実行し、指定したデータベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。
- データベースに対して DBCC CHECKALLOC を実行。
- データベース内にあるすべてのテーブルとビューに対して DBCC CHECKTABLE を実行。
- データベースに対して DBCC CHECKCATALOG を実行。
- データベース内にあるすべてのインデックス付きビューの内容を検証。
- FILESTREAM を使用して varbinary(max) データをファイル システムに格納する場合のテーブルのメタデータとファイル システムのディレクトリおよびファイルの間のリンクレベルの一貫性を検証。
- データベースの Service Broker データを検証。
DBCC CHECKDB では、上記の処理を実行してデータベースの整合性が取れているかを確認する処理になります。
■整合性確認を実施しないとどうなるか
データベースの整合性確認を行う事でどのようなことが分かるか、簡単に試してみたいと思います。
今回は、バイナリエディタでデータファイル (mdf) を開き、一部のデータを書き換え、データの内容とページのチェックサムが一致しないようにしてみました。
データを書き換える前のテーブルの全件を取得した情報がこちらになります。
SQL Server 2008 以降であれば、データがどのページに格納されているかは [sys.fn_PhysLocFormatter(%%physloc%%)] を使用することで確認することができます。
# この関数は、Undocument の関数です。
上のデータは、以下のクエリを実行して取得しています。
SELECT |
SQL Server のページにはチェックサムがあり、データの内容を元に計算したチェックサムとデータの内容が一致しているかを確認することで、ページが破損しているかを検出する機能がありますのでページに一貫性が無いとエラーとして検出することができます。
# データベースオプションで [CHECKSUM] / [TORN_PAGE_DETECTION] / [NONE] のいずれかを設定することが可能です。([TORN_PAGE_DETECTION] は下位互換となっていますが。)
今回はバイナリエディタでデータベースのファイルを開いて、 (1:114:0) のページを壊してみました。
ページを壊した後に、データを全件取得すると以下のデータまでは取得できるのですが、 (1:114:0) のデータを読み込もうとした際にエラーが発生します。
メッセージ 824、レベル 24、状態 2、行 1 |
(1:114) という情報が表示されていますので、ファイル ID 1 (mdf ファイル) の 114 ページに一貫性のエラー (チェックサムとデータが不整合) が発生していることが確認できます。
今回、私が壊したページ番号と一致しますね。
破損ページの操作をした場合、イベント ビューアーのアプリケーションにも同様の情報が出力されますので、監視ソフト等でログ監視をしているのであれば、エラーを検知することもできます。
今回はデータを全件読み込みしたので破損ページも読み込まれエラーが発生しましたが、破損したページにアクセスをしなければ正常にデータを読み込むことができます。
# Col = 4 のデータを読もうとするとエラーになってしまうので飛ばしています。(先行読み込みの可能性が)
破損したページを操作しないとエラーにはなりませんので、データベースに異常があるかは分かりません。
DBCC CHECKDB を定期的に実行することで障害により発生した潜在的に潜んでいるデータベースの異常をチェックすることが可能です。
[DBCC CHECKDB(N’TEST’)] を実行して、今回整合性のエラーが発生している [TEST] データベースでデータベースのチェックをしてみます。
‘TEST’ の DBCC 結果。 |
DBCC CHECKDB を実行することで、データベースの状態をチェックしてくれますので、破損している領域を操作しなくても異常があるかどうかの確認をしてくれます。
イベントビューアーと SQL Server のログにも結果の概要が出力されますので、後で結果を再確認することも可能です。
SQL Server のダンプのテキストも出力されています。
[msdb..suspect_pages] を SELECT することで直近の情報を取得することもできます。
DBCC CHECKDB をバックアップ実行前に実施する理由ですが、[障害が発生しているデータベースのバックアップは障害が発生した状態] となるからです。
障害が発生していない状態のデータベースのバックアップがないと破損している領域を修復することができません。
# SQL Server 2008 以降のデータベースミラーリングであれば、破損ページを読み込んだ際にミラー側から修復することも可能ですが。
そのため、バックアップを取得する前にデータベース自体に異常が無いかを確認して、その後にバックアップを取ることが推奨されます。
セミナーの中で質問 / 回答があったのですが、DBCC CHECKDB によるデータベースの整合性確認はデータベースのサイズが大きいとかなり負荷がかかります。
そのため、バックアップのたびに毎回実行するのが難しいかもしれませんね。
次の投稿では [データベースの整合性確認の負荷] についてまとめてみたいと思います。
第 1 回 Get The Fact セミナーの振り返り その 5
今回は [バックアップポリシー] について振り返っていきたいと思います。
# 参加から 2 週間経過したのでテンポよくまとめていかないとだいぶ記憶が薄れてきました…。
セミナーでは以下のような図を元にバックアップポリシーについてのお話しがありました。
■バックアップの基本的な設定
上の図は復旧モデルを [完全] または [一括ログ] にした場合のバックアップの基本的な設定になります。
# [単純] 復旧モデルの場合は、ログのバックアップが取れませんので、データベースのバックアップのみになります。
セミナーでは日に一度のデータベースバックアップと、一時間おきのログのバックアップで設定というような例でお話をされていたと思います。
SQL Server のバックアップは大きく分けて 3 種類あります。
# ファイル / ファイルグループでのバックアップも取得ができるのですが、今回は割愛しておきます。
- 完全
- 差分
- トランザクションログ
完全 / トランザクションログは上の図で [データベース] [ログ] と書かれているバックアップになります。
[完全バックアップ] は、その時点 (バックアップを実行したタイミング) でのデータまで復元することが可能なバックアップとなります。
完全バックアップはそのバックアップ単体で戻すことが可能ですのでバックアップにはログも含まれています。
[差分バックアップ] は、前回の完全バックアップからの差分データのみを含んだバックアップになります。
完全バックアップを元にした差分になりますので、単体で戻すことはできず必ず前回の完全バックアップが必要となります。
また、差分バックアップは前回の完全バックアップからの差分データですので、完全バックアップを取得してからの期間が長くなり、全データが更新された状態になってしまうと、完全バックアップ相当のバックアップファイルのサイズとなります。
[トランザクションログバックアップ] は、ログレコードのバックアップになります。
復旧モデルのときにもお話しがあったのですが、復旧モデルを [完全] [一括ログ] にしている場合は必須になるバックアップとなります。
これらの復旧モデルに関しては、ログレコードは自動的に切り捨てはされず、バックアップを取得したタイミングで切り捨てが行われ、切り捨てられた個所が再利用可能となります。
そのため、ログのバックアップを取得しないとログがずっと蓄積された状態となり、ログ領域のディスクが枯渇することになります。
ログのバックアップは障害発生時に重要となるバックアップのため、できるだけ短い間隔で取得することが重要であるとセミナーではお話がありました。
# 1 時間おきのログのバックアップというお話はこのタイミングであった気がします。
データベースの完全バックアップを取得していない状態ではログバックアップは取得することはできません。
バックアップについてですが、以下の資料がわかりやすいと思います。
SQL Server 2000 の資料ですが、それ以降のバージョンでも考え方は同じですので。
第 4 章 バックアップと復元
■定期的なバックアップの設定
定期的なバックアップの設定方法として、[メンテナンスプランウィザード] によるバックアップの設定が紹介されていました。
ワンタイムのバックアップであれば、データベースを右クリックして、[タスク] → [バックアップ] からバックアップを取得することが可能です。
このバックアップに関しては、ワンタイムになりますので定期的なバックアップの取得の設定はできません。
定期的なバックアップをウィザード形式で設定する場合は、セミナーで紹介のあった [メンテナンスプランウィザード] を使用する事で設定ができます。
メンテナンスプランウィザードは [管理] → [メンテナンス プラン] → [メンテナンス プラン ウィザード] から起動することができます。
メンテナンス プラン ウィザードを使用することで、データベースのメンテナンスをする仕組みを数ステップで設定が可能となります。
今回のセミナーでお話しのあったメンテナンスプランに似たものを実際に作ってみたいと思います。
- [次へ] をクリックします。
- [タスクごとに個別のスケジュールを使用する] を選択して、[次へ] をクリックします。
- [データべすのバックアップ (完全)] [データベースのバックアップ (トランザクション ログ)] を選択して、[次へ] をクリックします。
- [次へ] をクリックします。
- [完全] バックアップの取得対象とバックアップのスケジュールを設定し、[次へ] をクリックします。
今回は [すべてのデータベース] を毎日 [22:00] に取得するように設定をしています。 - トランザクションログのバックアップを取得するデータベースとスケジュールを選択し、[次へ] をクリックします。
今回は、[すべてのユーザー データベース] を [毎日1 時間置き] にバックアップを取得するように設定しています。
すべてのユーザー データベースですが復旧モデルが単純以外のデータベースが対象となります。 - ログの出力場所を設定し、[次へ ]をクリックします。
- [完了] をクリックします。
- [閉じる] をクリックします。
以上でメンテナンスプランの作成は完了です。
今回は、[完全 バックアップ] の取得と、[トランザクションログ] のバックアップの取得を設定していますので二つのジョブが SQL Server エージェントに作成されています。
作成した 2 つのジョブを手動で実行して、バックアップの取得状況を確認してみたいと思います。
ジョブを手動実行する場合は、対象のジョブを右クリックして、[ステップでジョブを開始] をクリックします。
今回は、H ドライブにアックアップを取得しているのですが、データベースのバックアップ (.bak) とトランザクションログのバックアップ (.trn) が取得されていることが確認できます。
今回のメンテナンスプランですが、バックアップを取得するたびにタイムスタンプが設定されたバックアップファイルが蓄積されていきます。
また、ログに関してもバックアップを実行するたびに蓄積されていきます。
このバックアップとログの履歴 (世代) 管理ですが、[メンテナンス クリーンアップ タスク] を使用することで管理することができます。
先ほど作成したメンテナンスプランにこの履歴クリーンアップタスクを組み込んでみたいと思います。
作成したメンテナンスプランは、[管理] → [メンテナンス プラン] の下に作成がされますので、作成したプランをダブルクリックします。
そうするとメンテナンスプランのデザインウィンドウが開きます。
先ほど作成したプランが、[Subplan_1] [Subplan_2] として設定されています。
今回は [サブプランの追加] をクリックして、[Subplan_3] として[メンテナンス クリーンアップ タスク] を設定します。
タスクをダブルクリックすると設定画面になります。
このタスクを使用することで、バックアップファイルとメンテナンスプランのレポートを削除することが可能です。
拡張子単位で指定はできるのですが、ワイルドカードは使えないので、[bak] [tran] 用のバックアップファイル削除タスクを用意します。
テキストレポートのクリーンアップタスクとしては以下の内容を設定しました。
今回はスケジュールも設定し、このような形でサブプランを設定してみました。
今回は 4 週経過したファイルが対象になっていますので、以下の PowerShell を実行して、ファイルの更新日付を変更してみました。
# クリーンアップタスクでファイル操作をする際の日付はファイルの更新日付が検索対象となります。
Get-Item "C:Program FilesMicrosoft SQL ServerMSSQL10_50.SQL2008R2MSSQLLogMaintenancePlan_Subplan_1_20101220221815.txt" | Set-ItemProperty -name LastWriteTime -Value (Get-Date).AddDays(-28) |
これで、メンテナンスレポートの日付が 28 日前 (4 週間前) になりました。
それでは、作成したクリーンアップタスクんのジョブを実行してみます。
ジョブを実行したことで、先ほどファイルの更新日付を変更したメンテナンスレポートが削除されていることが確認できます。
バックアップ ファイルに関しても更新日付が条件に一致するのであれば削除されます。
メンテナンス プラン ウィザードを使用することでバックアップのメンテナンスプランを GUI のウィザードベースで柔軟に設定することが可能となります。
今回の投稿では設定をしなかったのですが、メンテナンスプランには [データベースの整合性確認] というメンテナンス タスクがあります。
セミナーの中ではこのタスクについてもお話がありました。
次の投稿では、データベースの整合性確認についてまとめてみたいと思います。
SQL Server のインスタンス ルート ディレクトリを変更した場合の注意点
SQL Server のインストールですが、インストール時に [インスタンス ルート ディレクトリ] を設定します。
インスタンス ルート ディレクトリは任意のディレクトリを指定できますので、デフォルトの [C:Program FilesMicrosoft SQL Server] から変更することが可能です。
このインスタンス ルート ディレクトリですが、変更した際に一点注意点があります。
今回は、C ドライブではなく E ドライブに設定をしてみました。
インスタンス ルート ディレクトリ以外は C ドライブに設定しています。
SQL Server をインストールすると以下のサービスがインストールされます。
- SQL Active Directory Helper Service
- SQL Server
- SQL Server Agent
- SQL Server Browser
- SQL Server VSS Writer
インスタンス ルート ディレクトリに選択したディレクトリには、[SQL Server] [SQL Server Agent] のサービスのファイルが格納されます。
サービス用のプログラムが C ドライブ以外にあることは問題ないのですが、この状態では Windows Server バックアップで [システム状態] [ベアメタル 回復] のバックアップを取得する際に、SQL Server 用のサービスに必要なプログラムが格納されているドライブも取得対象となります。
# このあたりは、System Writer の VSS Writer が制御しているみたいですね。レジストリ (ImagePath の値) を直接修正して、サービスで使用するプログラムの場所を変更すればインスタンス ルート ディレクトリを取らなくすることもできますが。危険すぎてこの方法は使わないですよね…。
最初は [ベア メタル回復] のバックアップ取得を試してみます。
ベア メタル回復を選択すると、自動的にベアメタル回復に必要なドライブが選択されるのですが、C ドライブだけでなく E ドライブも自動的に選択がされます。
E ドライブを外そうとしても以下のメッセージが表示され、ドライブ / ドライブ以下のフォルダを外すことができません。
[システム状態] を選択すると、システム状態の回復に必要なものが取得されます。
# ドライブの選択状況は変わらず、内部でシステム状態の回復に必要なものが自動で取得されます。
システム状態を選択した際に取得されるバックアップを確認してみます。
3 つの VHD ファイルが作成されています。
これですが、[システムで予約済み] (通常にインストールをした際の先頭 100MB) [C ドライブ] [E ドライブ] のバックアップとなっています。
Windows Server 2008 R2 の場合はファイル単位でバックアップが取得できるようになているので、各ドライブのバックアップはシステム状態として必要最低限のファイルがバックアップされています。
# C ドライブであればユーザープロファイルのディレクトリは除外されています。
E ドライブのバックアップを確認してみるとサービスで使用している 2 つのファイルのみが取得されています。
Windows Server 2008 R2 であれば、ファイル単位で取れるのでシステム状態を取得した時にインスタンス ルート ディレクトリを C ドライブ以外にしても最小限のファイルがバックアップされることになります。
Windows Server 2008 ではどうなるでしょう。
Win
dows Server 2008 では[システム回復を有効にする] がベアメタル回復相当のバックアップとなります。
このオプションを有効にすると、インスタンス ルート ディレクトリに指定したドライブも自動的に選択されます。
この動きは、Windows Server 2008 R2 と同じですね。
それでは、システム状態のバックアップを取得するとどうなるでしょう。
Windows Server 2008 の場合は、[wbadmin start systemstate
backup] というコマンドラインを使用して、システム状態だけを取得することが可能です。
# [Start Backup] で取得する場合は、[-allCritical] というオプションを指定します。
システム状態を取得する場合に必要となるファイルが含まれているドライブを自動で判断する動きは Windows Server 2008 R2 と変わりません。
Windows Server 2008 の場合は、デフォルトでは先頭の 100MB の領域は作成されないので、2 つの VHD ファイルが取得されます。
Windows Server 2008 R2 と異なり、サービス以外のファイルも取得されています。
Windows Server 2008 の場合は、ボリューム単位でのバックアップしか取得ができないため、SQL Server のサービスで使用しているファイル以外のものも取得がされます。
そのため、インスタンス ルート ディレクトリのドライブに SQL Server のデータベースを格納していると、Windows Server 2008 ではシステム状態のバックアップでデータベースのファイルも取得がされてしまい、バックアップのファイルサイズが肥大化する可能性があります。
インスタンス ルート ディレクトリを変更することはあまりないかもしれませんが、変更する場合はバックアップの取得で影響がないようにデータベースのファイルを配置するような考慮が必要そうですね。
LocalSystem 以外で WMI イベント警告を受信
先日、SQL Server の WMI イベント警告について投稿をしました。
WMI イベント警告は SQL Server Agent 経由で実行されるため、SQL Server の権限も SQL Server Agent のサービスアカウントのものになります。
BOL に記載されているのですが、WMI イベント警告で警告を受信するためには、以下の権限が必要となります。
WMI 警告の通知を受信するには、SQL Server エージェントのサービス アカウントに、WMI イベントを含む名前空間、および ALTER ANY EVENT NOTIFICATION に対する権限が許可されている必要があります。
SQL Server Agent をローカルシステムアカウント (LocalSystem : NT AUTHORITYSYSTEM) で実行した場合は、特に設定を変更しなくても WMI イベント警告を受信できると思います。
SQL Server Agent を一般ユーザー (Users グループのユーザー) で起動した場合はどうなるでしょう。
イベントの条件に達してもイベントビューアーのアプリケーションに [124] のエラーが出力されて WMI イベント警告が実行されません。
この挙動の原因ですが、ローカルシステムアカウントの場合は、[ALTER ANY EVENT NOTIFICATION] のサーバーレベルの権限が付与されています。
サーバーレベルの権限は以下のクエリで確認ができます。
EXECUTE AS LOGIN = ‘NT AUTHORITYSYSTEM’ |
SQL Server Agent が SQL Server に接続する場合は、[NT SERVICESQLAgent$<インスタンス名>] のログインで実行がされます。
# OS によってはサービスアカウントがそのまま使用されていることもあります。
このログインは、Windows 認証になっているので、Windows アカウントを使用したログインとなっています。
Windwos Server 2008 R2 の場合はこのアカウントはサービス SID になっていて、Windows のログインやグループではなく、サービスに直接関連づいたアカウントになっています。
サービス SID の場合は、上記のクエリだと権限が見えないのですよね…。
サービス SID を使用していない OS (XP / 2003) の場合は、SQL Server Agent の起動アカウントに、[ALTER ANY EVENT NOTIFICATION] の権限は付与されていませんでした。
ローカルシステム以外で SQL Server Agent を起動しているときは、以下のクエリを実行して、権限を付与する必要があります。
USE [master] GO GRANT ALTER ANY EVENT NOTIFICATION TO [NT SERVICESQLAgent$SQL2008R2] |
権限を外す場合はこちらになります。
# REVOKE で権限を外します。
USE [master] GO REVOKE ALTER ANY EVENT NOTIFICATION TO [NT SERVICESQLAgent$SQL2008R2] |
ALTER ANY EVENT NOTIFICATION の権限を付与することで、WMI イベントを SQL Server Agent のサービス起動ユーザーで受信できるようになり、WMI イベント警告を実行できるようになります。
WMI イベントを含む名前空間に関しては、インストール直後の状態の権限で問題は無いようです。
WMI の権限の確認についてですが、ファイル名を指定して実行から MMC を起動して、[WMI コントロール] を追加します。
MMC に WMI のスナップインを追加した後に、WMI コントロールのプロパティを開きます。
WMI コントロールのプロパティが開いたら、[セキュリティ] タブの [RootMicrosoftSqlServerServerEvents<インスタンス名>] を選択して、[セキュリティ] をクリックします。
そうすると、WMI 名前空間に対してのセキュリティを確認することができます。
SQL Server Agent のサービス SID には、[メソッドの実行] [アカウントの有効化] [セキュリティの読み取り] の権限が付与されています。
WMI イベント警告を実行するために必要な権限はこの権限でよいようで、デフォルトから設定は変更しなくても実行することができました。
サーバーレベルで権限を付与する必要があり、この操作は普段あま
りやらない作業だと思いますので、ちょっと戸惑うかもしれないですね。
Forefront Endpoint Protection 2010 と Security Essentials 2.0 が提供されました
先日、エンタープライズ向けのセキュリティ製品である、Microsoft Forefront Endpoint Protection 2010 (FEP) と個人向けの Microsoft Security Essentials 2.0 (MSE) の提供が開始されました。
Microsoft Forefront
Microsoft Security Essentials
MSE は個人向けの製品ですので、インストーラーを実行すればインストールをすることが可能です。
スモールビジネス用として事業で使用する PC 10 台にもインストールすることはライセンス上できますが。
今回提供された、MSE 2.0 ですが、MSE 1.0 からのアップグレードをすることも可能です。
ライセンス条項に
- 本ソフトウェアは、Microsoft Windows オペレーティング システムのエンタープライズ バージョンが実行されているデバイス上では使用できません。
[2011/2/25 修正]
と書いてありますので、エンタープライズバージョン (サーバー OS) で使うと条項に違反すると思いますのでご注意ください。
# インストールできるのと使っていいのかは別になりますので。
本件についてコメントでフィードバックいただきましたので上記を取り消し線にしました。
情報の提供ありがとうございます!!
MSE は Windows Updat 経由でパターンをアップデート / サーバーによる一括管理ができない製品仕様になっているはずですので基本は個人で使用する製品となります。
企業で一括管理、WSUS によるパターンファイルの更新を行いたいといった場合には、Forefront Endpoint Protection 2010 (FPE) を使用することになります。
Windows Update 経由でもパターンファイルの更新は可能です。
これは Forefront という製品ブランドがついているようエンタープライズ向けのセキュリティ製品になります。
FEP はサーバーを立てることで集中管理をすることが可能になりますが、スタンドアロンモードでインストールすることも可能です。
スタンドアロンモードでのインストールですが、FEP 2010 のインストールメディアを入れ、[FEP2010_ja-jpx64client] の [FEPInstall.exe] を実行するとインストールができます。
以前のバージョンである Forefront Client Security (FCS) だと [Clientsetup.exe /NOMOM] といった形でインストールすることで、管理サーバーの配下に置かないスタンドアロンモードになったのですが、FPE だとインストーラーを単純に起動するとスタンドアロンモードになるみたいですね。
デフォルトでインストールすとスタンドアロンモードなので一括管理するモードはどうやって導入をするのかは調べないといけないですね…。
現状 TechNet のライブラリは英語版のみとなっているようです。
下のリンクはツリービューを表示させたかったので意図的に英語にしていますが en-us → ja-jp に URL を変更してもブログの投稿時点では英語版のヘルプになっています。
FEP2010 Client Help
インストール時の画面キャプチャがこちらです。
特に設定を入力することもなく、ウィザードベースで進んでいきます。
以上でインストールは完了です。
二つの製品ですが、エンジン部は共通だったはずですので、定義情報に関しても同じバージョンになっていますね。
以前のバージョンである、FCS の環境にインストールしてみたところ特にアップグレードというメッセージは表示されずに、新規インストールと同じウィザードが起動してきたのですが、設定が引き継がれてアップグレードインストールされていました。
再起動が必要でしたが。
検証 / 評価環境で TechNet サブスクリプションを使用している方は結構多いかと思いますが、FPE は TechNet サブスクリプションで入手ができ、ウイルス対策ソフトとして使用することが可能です。
評価環境のウイルス対策をどうしようと考えられている方は FEP をご利用してみてはいかがでしょう。