安納＠札幌です。
先ほど、セミナールームで MVP の @NAOKI0311 さんとお話をしていたところ、今日初めて知ったことがあります…。それは、一般ユーザーがドメインに参加させられるクライアントの数には上限があり、それが10台までだということ..。
フィールドを担当していた時代は sysprep で自動的にドメイン参加をさせていたので、こんな制限があるなんてことは考えたこともありませんでした…お恥ずかしい…。
（参考情報） ドメイン ユーザーがワークステーションまたはサーバーをドメインに参加させられない http://support.microsoft.com/kb/251335/
では、これは回避できるのか？
どうやら、Active Directory の規定値を変更することで回避することができそうです。以下は当該情報が記載されたKBです（英語ですみません）。
Default limit to number of workstations a user can join to the domain http://support.microsoft.com/kb/243327
手順は簡単です。
もちろん、この設定は数を増やすだけでなく、数を制限するのに使うこともできます。1人1台までしかドメインに参加させたくない！という場合には、この値を1にすればよいということです。
ちなみに、「当該ユーザーが、既に何台のWSをドメインに参加させているか？」を調べるには、コンピュータアカウントの「ms-DS-CreatorSID」属性を調べればよいみたいなのですが、これについてはもう少し調べてみたいと思います。
手元の環境に Exchange Server 2010 をインストールしてみたのですが、WinRM でエラーが出るので仮想マシンごと削除してしまいました…
再度まっさらのサーバー Exchange Server 2010 をインストールしようとしたら…以下のエラーが出ました。
一部のコントロールが有効ではありません。Exchange Server は不整合な状態にあります。障害回復モードでのみ使用できます。Setup /mode:RecoverServer を使用してこの Exchange サーバーを復元してください。
あぁぁぁ、またしてもやってしまいました。きっと Active Directory に Exchange 関連オブジェクトが残っているんです… （Active Directory は使いまわしているのです）
仕方がないので、Active Directory から直接オブジェクトを削除したいと思います。
以上で完了です。
再度、Exchange Server 2010 のインストールを開始すると、今度はちゃんとウィザードが遷移しました。
初物は..いろいろあります…特に「勘」にたよっていると…
みなさんは気を付けてください。
「26204」という数字を見て、「あぁ、あれね」と思い当たった方はシニア認定です。
Operations Manager や System Center Essentials のデモ環境を作成するときに（もちろん本番環境でも）絶対にやってはいけないことがあります。
それは、sysprep をせずに OS が入った VHD をまるまるコピーして使いまわすこと…。わかっちゃいたんです…でも急いでてつい…結果、大幅な時間ロスです…。自分が馬鹿すぎて涙が出てきます。
実は、Operations Manager 2007 R2 のインストール時に、以下のエラーが発生しました。何度やっても発生します。
エラー 26204。Error –2147217900: failed to execute SQL string, error detail: Windows NT ユーザーまたはグループ…..
どんなエラーかというと、Operations Manager のインストールウィザードで指定した管理者アカウントが見つからない..って言っています。
このエラーを違う角度から見てみましょう。
この状態で、SQL Server Management Studio で、[ログイン] に上記と同じ管理者アカウントを作成しようとすると、以下のエラーが発生します。
ログイン <domein>\<user> の作成に失敗しました。Transact-SQL ステートメントまたはバッチの実行中に例外が発生しました。Windows NT ユーザーまたはグループ “<domain>\<user>” が見つかりませんでした。名前を再確認してください。
このエラーが発生する原因は、まぎれもなく SID の重複です。以下のKBご覧ください。
エラー 15401 のトラブルシューティング方法 http://support.microsoft.com/kb/324321/ja
VHD を sysprep 無しに流用してしまったので、当然 SID が重複しています。
ものぐさなんかするんじゃなかったと後悔しつつ、再インストール中です…。
ITがコストセンターを脱却し戦略的資産と化した姿を、マイクロソフトは「Dynamic IT」と呼んでいます。
ビジネスニーズに合わせて柔軟にその姿を変えることができるITは、ご存知の通り「仮想化テクノロジー」によって支えられています。SQL Server は Dynamic ITにおけるデータ収集エンジンおよびレポートエンジンとして機能し、多くのマイクロソフトサーバー製品群が基盤データベースとして採用しています。
こうした背景もあり、ここ5年余り、SQL Server の基本コンセプトは「データプ ラットフォーム」から「情報プラットフォーム」へと変化しました。つまりSQL Serverは、格納されているデータを可視化し、ビジネスは当然のこと、ITシステムにもフィードバックができるプラットフォームであることをめざしています。SQL Server 2008 以降、各機能のエンハンスにはそうした考えが強く反映されており、以前にもご紹介したセルフサービスBIは、ビジネスを加速させる情報分析ツールとして、情報プラットフォームビジョンを支える顕著な例です。SQL Server 2008 R2には、これ以外にも情報プラットフォームとして重要なエンハンスがなされています。
今回は、SQL Server 2008 R2の「管理性」、その中でも「インスタンスの正常性を監視する機能」にスポットを当てて「情報プラットフォーム」ビジョンを支える機能をご紹介していきましょう。
おなじみの管理コンソール。複数のSQL Server インスタンスを1つの管理コンソールから集中的に監視、操作が可能。SQL Server 2008 R2 の管理コンソールでは、SQL Azure への接続も行える。また、[データベース] や [セキュリティ] などの各ノード、およびサブノードを右クリックすると必ず Windows PowerShell でのスクリプティング - スクリプトセンター コマンドが用意されているなど、きめの細かい変更も加えられている。
SQL Server Management Studio に新たに追加されたタブで、「ユーティリティコントロールポイント（UCP）」および「データ層アプリケーション（DAC）」の監視と管理を行うことができる。 UCPとは、複数のサーバーに散在した多数のインスタンスを集中的に監視する単一ポイントであり、特定のインスタンスにデータウェアハウスを作成し、各インスタンスのパフォーマンス情報を集めることができる。 集めたパフォーマンスデータは、事前に定義されている「ポリシー（インスタンスの負荷、データベースの容量）」と照らし合わせ、インタンスが正常値の範囲内かどうかが判定される。その結果はレポートとして表示され、ひと目で全インスタンスの正常性を判断することができる。 ポリシーは、運用に合わせてインスタンス単位で変更することができる。そのため、従来はパフォーマンスログとにらめっこして検証しなければならなかった正常性が、たった1秒で完了できる。
SQL Server Management Studio に新たに追加されたタブで、「ユーティリティコントロールポイント（UCP）」および「データ層アプリケーション（DAC）」の監視と管理を行うことができる。
UCPとは、複数のサーバーに散在した多数のインスタンスを集中的に監視する単一ポイントであり、特定のインスタンスにデータウェアハウスを作成し、各インスタンスのパフォーマンス情報を集めることができる。
集めたパフォーマンスデータは、事前に定義されている「ポリシー（インスタンスの負荷、データベースの容量）」と照らし合わせ、インタンスが正常値の範囲内かどうかが判定される。その結果はレポートとして表示され、ひと目で全インスタンスの正常性を判断することができる。
ポリシーは、運用に合わせてインスタンス単位で変更することができる。そのため、従来はパフォーマンスログとにらめっこして検証しなければならなかった正常性が、たった1秒で完了できる。
なおレポートは、単にインスタンス群の現状を把握するだけでなく、以下に示す「次のアクション」への誘導灯となる。 新しいデータベース（データ層アプリケーション）の展開先の判断 データベース（データ層アプリケーション）を負荷の適切なインスタンスに移動
なおレポートは、単にインスタンス群の現状を把握するだけでなく、以下に示す「次のアクション」への誘導灯となる。
データベースサーバーの負荷が高い場合、負荷を分散させるためいくつかのデータベースを別のサーバーに移行したいと考えることがある。前出のユーティリティエクスプローラーを使用すると、インスタンスの状況をひと目で判断できるため、対策が必要なインスタンスや移行先候補のインスタンスを容易に割り出すことができる。 ただし、問題は移行の方法だろう。単にテーブルを移行するだけならさほど出ないにしても、ストアドプロシジャーやアクセス権など、データベースオブジェクトに含まれるあらゆる要素を調査するのは容易ではないし、その移行作業も面倒だ。 SQL Server 2008 R2 の SQL Server Management Studio（SSMS）には、データベースオブジェクトを「データ層アプリケーション」として、容易に抽出してパッケージ化できる機能を提供している。 データベースを右クリックして [タスク] - [データ層アプリケーションの抽出] を選択すると、選択したデータベースオブジェクトに含まれている要素群を拡張子「.DACPAC」というファイルに保存することができる。 抽出した .DACPAC は別のインスタンスに再配置できるので、用意に移行が可能だ。ただし、現時点では、中身のデータは別途バックアップして移行しなければならない。それでも面倒なデータベースオブジェクトの定義を一瞬でパッケージ化できることはとても大きなメリットだろう。 ちなみに、DACPAC は、SQL Server 2008 R2 の SSMS を使用すれば、SQL Server 2000、2005、2008 上のデータベースオブジェクトからでも作成することができる。つまり、古いデータベースエンジンからの移行が容易に行えるということだ。 なお、データベースは「データ層アプリケーション」として UCP の監視下に置くことができる。つまり、インスタンスだけでなく、その上で動作しているデータベースをも個々に監視対象とすることができる。UCP の監視下に置くには、SSMSのオブジェクトエクスプローラーでデータベースオブジェクトを右クリックして、[タスク] - [データ層アプリケーションとして登録] を選択するだけだ。 Visual Studio 2010 を使用している開発者は、「SQL Server データ層アプリケーション」 テンプレートを使用して、データ層アプリケーションを作成することができる。また、Visual Studio の中から、直接インスタンスにデータ層アプリケーションを発行することができる。
データベースサーバーの負荷が高い場合、負荷を分散させるためいくつかのデータベースを別のサーバーに移行したいと考えることがある。前出のユーティリティエクスプローラーを使用すると、インスタンスの状況をひと目で判断できるため、対策が必要なインスタンスや移行先候補のインスタンスを容易に割り出すことができる。
ただし、問題は移行の方法だろう。単にテーブルを移行するだけならさほど出ないにしても、ストアドプロシジャーやアクセス権など、データベースオブジェクトに含まれるあらゆる要素を調査するのは容易ではないし、その移行作業も面倒だ。
SQL Server 2008 R2 の SQL Server Management Studio（SSMS）には、データベースオブジェクトを「データ層アプリケーション」として、容易に抽出してパッケージ化できる機能を提供している。 データベースを右クリックして [タスク] - [データ層アプリケーションの抽出] を選択すると、選択したデータベースオブジェクトに含まれている要素群を拡張子「.DACPAC」というファイルに保存することができる。
抽出した .DACPAC は別のインスタンスに再配置できるので、用意に移行が可能だ。ただし、現時点では、中身のデータは別途バックアップして移行しなければならない。それでも面倒なデータベースオブジェクトの定義を一瞬でパッケージ化できることはとても大きなメリットだろう。
ちなみに、DACPAC は、SQL Server 2008 R2 の SSMS を使用すれば、SQL Server 2000、2005、2008 上のデータベースオブジェクトからでも作成することができる。つまり、古いデータベースエンジンからの移行が容易に行えるということだ。
なお、データベースは「データ層アプリケーション」として UCP の監視下に置くことができる。つまり、インスタンスだけでなく、その上で動作しているデータベースをも個々に監視対象とすることができる。UCP の監視下に置くには、SSMSのオブジェクトエクスプローラーでデータベースオブジェクトを右クリックして、[タスク] - [データ層アプリケーションとして登録] を選択するだけだ。
Visual Studio 2010 を使用している開発者は、「SQL Server データ層アプリケーション」 テンプレートを使用して、データ層アプリケーションを作成することができる。また、Visual Studio の中から、直接インスタンスにデータ層アプリケーションを発行することができる。
このように、SQL Server の管理者は、どれか1つの監視用インスタンスのユーティリティエクスプローラーから、ネットワーク上の全てのインスタンスおよびデータ層アプリケーションを集中監視することができます。
※（注意）ここから先は完全に私見です
SQL Server 2008 R2 は Sysprep に対応し、Windows Server とともに簡単に仮想環境に展開できるようになりました。さらに、うれしいことに Live Migration にも対応しました…。このような背景を考えると、今回の UCP によるデータ層アプリケーションおよびマルチサーバー管理機能は、きっと次の新たなステップへの布石のような気がします。
それは、データ層のみの Live Migrationです。あるインスタンスから、適切なリソースを持つインスタンスに、負荷や容量に応じて自動的に移行される。それも、データ層のみが。
そんな理想的な環境が、将来、きっと実現されるだろうと期待しています。
まずはこちらをご覧ください。SQL Server プロダクトマネージャー 北川がBLOGに投稿した記事です。
都市伝説 (Urban Legends) を読み解く - 必要なデータをフィルタリングする方法は!?
この中で「PowerPivot で必要なデータをフィルタリングする方法は!?」の項で触れられているレポーティングサービスからのデータ取込みについて補足しておきたいと思います。
PowerPivot for EXCEL 2010 を使用したセルフサービスBIは、今後確実に現場ではやるテクノロジーだと思います。MS社内でも、特に社員教育があったわけでもないのに、気が付けばエンジニアではない多くの社員がマーケティングデータや売り上げデータを PowerPivot を使用して分析しており、「現場は正直だなぁ」と思った次第です。
ただ、セルフサービスBIを社内に浸透させるうえで注意しなければならないことがあります。それはテーブルへのアクセス権です。以前、このBLOGでも触れたことがありました。以下の投稿では、SQL Server のテーブルへの接続権限をエンドユーザーに与える方法について書いたものです。
【SQL】PowerPivotを使用してデータベースに接続するとアクセスが拒否される
SQL Server に直接アクセス権を与える方法は確かに手軽ですが、分析に不必要なデータまで提供してしまうことになります。2007年度の分析を行いたいのに、2001年のデータまで含まれていたりとか。また、生データなのでエンドユーザーから見れば無駄なカラムあったり、テーブル構造がエンドユーザーには理解しずらかったりと、その問い合わせによって管理者の手間を増やしてしまう可能性もあります。
そこで、お勧めの方法として用意されているのが、「SQL Server Rporting Service（SSRS)」を使用した方法です。都市伝説を読み解く記事で、北川が触れている方法です。
右の図に書かれている通り、社内の CRM や ERP システムのデータをそのままPowerPivotのデータソースとするのではなく、一端 SSRS を介することで「整理された生データ」として公開することができます。
管理者にとっては、レポートビルダー 3.0 を使ってテーブルを作ってあげるだけですから、エンドユーザーが多くなればなるほどテーブルへのアクセス権を与えるよりもはるかに作業が軽減されます。
レポートビルダー3.0に用意されているデータソースとの接続性は以下の通りです。
SSRSの構築手順とレポーティングサービス3.0を使用したレポートの発行手順については、以下の記事をご覧ください。MVPの松本さんと杵島さんによるものです。いずれも、とてもわかりやすく手順が解説されています。
SQL Server 2008 R2 に新しく実装された「ユーティリティコントロールポイント（UCP）」はお使いでしょうか。インスタンス群をまとめて監視できるので、とても便利です。
で、作成したUCPをいったん削除したい場合にはどうしたよいか？（実はつまづきました（恥））
答えは以下に書いてありますが、ここでも簡単に手順をご紹介しておきます。
ユーティリティ コントロール ポイントを削除する方法 (SQL Server ユーティリティ) http://technet.microsoft.com/ja-jp/library/ff487180.aspx
以上で削除完了です。