Windows Server 2008 のターミナルサービスにユーザライセンス(CAL)を追加しようとしたところ、ターミナルサービスライセンスサーバが無効になっていたため、アクティブ化しようとしたら次のようなエラーが発生しました。
そこでイベントビューアでエラーを調べてみると、以下のような ID 38 のエラーが連続で記録されていました。
次のエラーのため、ターミナル サービス ライセンス サーバーはターミナル サービス クライアント アクセス ライセンス (TS CAL) をクライアントに発行できません: 証明書をストアに追加できません。エラー c0010020
ID 38 の情報を調べまわったところ、以下の方法で対処できることがわかりました。
【ID 38 エラーの解消方法】
1. ターミナルサーバーライセンスサービスを停止する。
2. regedit でレジストリエディタを開き、以下の 3 つのキーを削除する。
HKEY_LOCAL_MACHINE\Software\Microsoft\TermServLicensing\Certificates
HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\TermservLicensing\Parameters\Certificates.000
HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\TermservLicensing\Parameters\Certificates.001
3. ターミナルサーバーライセンスサービスを開始する。
4. ターミナルサーバーライセンスマネージャを起動し、ライセンスサーバが有効化していることを確認する。
ちなみに、Microsof Open License のサイトにある問い合わせ電話番号から問い合わせをしようとすると、自動音声サービスで、ライセンスの技術情報に関するサポートは有償になると言われるので要注意です。
参考:
“The License Server Activation Wizard encountered an internal error from the license server. Message Number: 0xc0110011″(英語)
2011-08-15
2010-03-27
『売上猫くん on MySQL』開発日記 - 2 - 開発環境
『売上猫くん on MySQL』の開発環境は以下の通り。
アプリケーションファイル(NekoApp.fp7)は、FileMaker Server Advanced 10(以下、FMServerAdv)上に置き、開発PC1、2、3及び開発Mac 10.6 の FileMaker Pro Advanced 10(以下、FMPA)からそのファイルにアクセスして開発を行う。FMServerAdv を使用する理由には、複数人が開発を安定して行えること、オンラインバックアップがスケジュールできる、という2点が挙げられる。
サーバ側にODBCをインストールしておけば、クライアント(開発PC)にはODBCは不要である(例外は後述)。 アプリケーション/ODBCの配布・アップグレードの容易さを考えれば、この構成は運用においても一考の価値はあると思う。
なお、図の「開発PC3 Win2008/TS」は Terminal Service を載せたWindows Server 2008機で、各クライアントがリモートデスクトップ接続によりFMPAを起動し、FMServerAdv にアクセスできるようにしている。(もともと、FileMaker は Terminal Service との相性が良く、Ver5位より常用しているが、近年のTerminal Service はローカルプリンタへの印刷、ローカルディスクの利用も格段に簡単にできるようになり、加えて接続遮断時にも接続を自動で復旧してくれたりする)。
前述のように FMSA (FileMaker Server無印も同様)にODBCをインストールすればクライアントにODBCを入れる必要はないが、例外がある。それは「SQLを実行」スクリプトステップを使用する場合である。 FileMaker は通常、開発者自らSQLを記述する必要はないが、FileMaker が用意していないコマンドを実行する場合は「SQLを実行」を使用する。また、FileMaker の外部DBに対する処理の中には非常に遅いものがあり(激遅処理)、その典型的なものに多数のレコードに及ぶ一括処理がある。CSV等のファイル取込、全置換、ループ等がそれである。 その回避策として 「SQLを実行」スクリプトステップにSQL文を埋め込み実行すると直接外部データベースに素のSQLが送られるので、FileMakerのレコード取込やループ処理を使うのに比べれて、桁違いにパフォーマンスが向上する。尚、FileMaker の外部DB使用時の激遅処理については、機会を改めて書きたい。
さて、開発PC1、ここには予備用のMySQLを入れ、リストアやリカバリをテストを行うので、データベースを全部削除したりとか無茶をやる。無茶をやると「あー、なるほど」と新たな発見もあったりする。また、ローカルにアプリケーションファイル(NekoApp.fp7)を置いても、FMSAサーバの環境と同様に諸機能が動作するかのチェックも行う。
以上
サーバ側にODBCをインストールしておけば、クライアント(開発PC)にはODBCは不要である(例外は後述)。
なお、図の「開発PC3 Win2008/TS」は Terminal Service を載せたWindows Server 2008機で、各クライアントがリモートデスクトップ接続によりFMPAを起動し、FMServerAdv にアクセスできるようにしている。(もともと、FileMaker は Terminal Service との相性が良く、Ver5位より常用しているが、近年のTerminal Service はローカルプリンタへの印刷、ローカルディスクの利用も格段に簡単にできるようになり、加えて接続遮断時にも接続を自動で復旧してくれたりする)。
前述のように FMSA (FileMaker Server無印も同様)にODBCをインストールすればクライアントにODBCを入れる必要はないが、例外がある。それは「SQLを実行」スクリプトステップを使用する場合である。 FileMaker は通常、開発者自らSQLを記述する必要はないが、FileMaker が用意していないコマンドを実行する場合は「SQLを実行」を使用する。また、FileMaker の外部DBに対する処理の中には非常に遅いものがあり(激遅処理)、その典型的なものに多数のレコードに及ぶ一括処理がある。CSV等のファイル取込、全置換、ループ等がそれである。 その回避策として 「SQLを実行」スクリプトステップにSQL文を埋め込み実行すると直接外部データベースに素のSQLが送られるので、FileMakerのレコード取込やループ処理を使うのに比べれて、桁違いにパフォーマンスが向上する。尚、FileMaker の外部DB使用時の激遅処理については、機会を改めて書きたい。
さて、開発PC1、ここには予備用のMySQLを入れ、リストアやリカバリをテストを行うので、データベースを全部削除したりとか無茶をやる。無茶をやると「あー、なるほど」と新たな発見もあったりする。また、ローカルにアプリケーションファイル(NekoApp.fp7)を置いても、FMSAサーバの環境と同様に諸機能が動作するかのチェックも行う。
以上
2008-07-28
Windows Server 2008 のインストールと Terminal Service 設定
Windows Server 2008 を弊社にもインストールしてみました。対象サーバ機は Dell PowerEdge SC440 です。
インストール自体はものの 30 分もあればできたのですが、最初の Administrator パスワード指定でちょっと手こずりました。Windows Server 2008 では、ローカルセキュリティポリシーの「パスワードは複雑さの要件を満たす必要がある」が有効に設定されているため、以下の条件を満たすようにパスワードを決定する必要があります。そしてようやくログインに成功。
ユーザーのアカウント名またはフルネームに含まれる 3 文字以上連続する文字列を使用しない。
長さは 6 文字以上にする。
以下の 4 つのうち 3 つの条件を満たす必要あり。
英大文字(A ~ Z)
英小文字(a ~ z)
10進数の数字(0~9)
アルファベット以外の文字(!、$、#、%など)
次にリモートデスクトップ接続を有効にするための機能を設定しました。ターミナルサーバーのインストールですが、サーバマネージャの「役割」というメニュー項目から追加します。
今回はターミナルサーバー、TS ライセンス、TS Web アクセスをインストールしました。
さて設定ですが、ちょっと勉強が必要になってしまいました。
RDP --- Terminal Service もしくはリモートデスクトップ接続を従来のように使えるようにするが、セキュリティレベルは落ちる。
ネゴシエート --- クライアント側で SSL が有効になっている場合は SSL を使って接続するが、有効になっていない場合には RDP を使う。
SSL(TLS 1.0) --- 常に SSL を使って接続する。
ネゴシエートにしておけば、従来の TS/リモートデスクトップ接続と Windows Server 2008/Vista 対応の TS/リモートデスクトップ共有を混在させることができる模様です。ただ、SSL に特化すればおそらくセキュリティが一番高くなるのでこれができることに越したことはないと思います。
SSL を使えるようにするには、TS/リモートデスクトップ接続のクライアント側がリモートデスクトッププロトコル 6.1 をサポートしている必要があります。この条件を満たすクライアントは次のとおりです。
Windows Server 2008
Windows Vista with Service Pack 1
Windows XP with Service Pack 3
ただし、XP with Service Pack 3 の場合は、ネットワークレベル認証がサポートされていないため、ターミナルサーバ構成で「ネットワークレベル認証でリモートデスクトップを実行しているコンピュータからのみ接続を許可する」のチェックを外しておく必要があります。
インストール自体はものの 30 分もあればできたのですが、最初の Administrator パスワード指定でちょっと手こずりました。Windows Server 2008 では、ローカルセキュリティポリシーの「パスワードは複雑さの要件を満たす必要がある」が有効に設定されているため、以下の条件を満たすようにパスワードを決定する必要があります。そしてようやくログインに成功。
ユーザーのアカウント名またはフルネームに含まれる 3 文字以上連続する文字列を使用しない。
長さは 6 文字以上にする。
以下の 4 つのうち 3 つの条件を満たす必要あり。
英大文字(A ~ Z)
英小文字(a ~ z)
10進数の数字(0~9)
アルファベット以外の文字(!、$、#、%など)
次にリモートデスクトップ接続を有効にするための機能を設定しました。ターミナルサーバーのインストールですが、サーバマネージャの「役割」というメニュー項目から追加します。
今回はターミナルサーバー、TS ライセンス、TS Web アクセスをインストールしました。
さて設定ですが、ちょっと勉強が必要になってしまいました。
RDP --- Terminal Service もしくはリモートデスクトップ接続を従来のように使えるようにするが、セキュリティレベルは落ちる。
ネゴシエート --- クライアント側で SSL が有効になっている場合は SSL を使って接続するが、有効になっていない場合には RDP を使う。
SSL(TLS 1.0) --- 常に SSL を使って接続する。
ネゴシエートにしておけば、従来の TS/リモートデスクトップ接続と Windows Server 2008/Vista 対応の TS/リモートデスクトップ共有を混在させることができる模様です。ただ、SSL に特化すればおそらくセキュリティが一番高くなるのでこれができることに越したことはないと思います。
SSL を使えるようにするには、TS/リモートデスクトップ接続のクライアント側がリモートデスクトッププロトコル 6.1 をサポートしている必要があります。この条件を満たすクライアントは次のとおりです。
Windows Server 2008
Windows Vista with Service Pack 1
Windows XP with Service Pack 3
ただし、XP with Service Pack 3 の場合は、ネットワークレベル認証がサポートされていないため、ターミナルサーバ構成で「ネットワークレベル認証でリモートデスクトップを実行しているコンピュータからのみ接続を許可する」のチェックを外しておく必要があります。
登録:
投稿 (Atom)