web-dev-qa-db-ja.com

ターミナルサービス2008-エラー4105(ライセンスサーバーの問題)

サーバーの概要は次のとおりです。

  • Server2003ドメインでメンバーサーバーとして実行されているServer2008 Standard
  • RemoteAppを使用してPOSアプリケーションにアクセスする必要がある5人のユーザー向けのターミナルサービスの実行
  • 独自のライセンスサーバーの実行:
    • 5 TS Per UserCALがインストールされています
    • 「構成レビュー」では、ライセンスサーバーがDCにインストールされていないことを訴える感嘆符が表示されます。
    • サーバーは、ADの「ターミナルサーバーライセンスサーバー」グループのメンバーです。
    • ユーザーは問題なくログインできますが、ライセンスを配布していないようです

ユーザーがログインすると、次のエラーが表示されます。

ターミナルサービスライセンスサーバーは、ActiveDirectoryドメイン "[domainname]"のユーザー "[username]"のライセンス属性を更新できません。ライセンスサーバーのコンピューターアカウントが、ActiveDirectoryドメイン "[domainname]"のターミナルサーバーライセンスサーバーグループのメンバーであることを確認します。ライセンスサーバーがドメインコントローラーにインストールされている場合、ネットワークサービスアカウントもターミナルサーバーライセンスサーバーグループのメンバーである必要があります。ライセンスサーバーがドメインコントローラーにインストールされている場合は、ターミナルサーバーライセンスサーバーグループに適切なアカウントを追加した後、ターミナルサービスライセンスサービスを再起動して、ユーザーごとのTSCALの使用状況を追跡または報告する必要があります。 Win32エラーコード:0x80070005

これは、RemoteAppユーザーにいくつかの問題を引き起こしているようです。セッションが切断されたようで、システムに完全に黒い画面が残ります。黒い画面を閉じることができません。ターミナルサービスマネージャーを使用してリモートでログオフする必要があります。また、ユーザーがターミナルサーバーにログインしていることを示す[詳細を表示]ウィンドウにRemoteAppをロードするように強制します(説明するのは難しいです。誰かが必要な場合はスクリーンショットを取得します)。

Technetで このスレッドこれ を読みましたが、どちらも次のセキュリティキーを指しています。

  • msTSExpireDate
  • msTSLicenseVersion
  • msTSManagingLS

ライセンスサーバーがユーザーに適切なライセンスを与えることができるように、これらのキーを見つけるために高低を検索しましたが、どこにも見つかりません。ユーザーアカウントのOUを選択し、そこでセキュリティを変更しようとしていますが、変更するキーが見つかりません。

このドメインはServer2000からServer2003にアップグレードされたため、キーが存在しないのかもしれません。何人かの人々は、ユーザーに正しいセキュリティキーを書き込むためにServer 2008マシンからadprepを実行することに言及しましたが、それは私の既存のServer 2003ドメインコントローラーで問題を引き起こすでしょうか?今年の後半まで、ドメインコントローラーをServer2008にアップグレードする予定はありません。

このターミナルサーバーを使用している5人のユーザーにセキュリティキーを手動で追加する方法を知っている人はいますか?これを修正するために他にできることはありますか?

ありがとう!

編集:Server 2003ドメインでServer2008MEMBER SERVERからadprepを実行すると、これが修正されるか、他の問題が発生するかどうかを具体的に知りたいです。誰かが何か洞察を持っていますか?

3
Russ Warren

このリンク および これ によると、あなたが言及した属性は、Windows Server2008で最初に導入されました。そうです、ADスキーマを2008レベルにアップグレードすると、問題が解決するはずです。

2008 DCをドメインにすぐに追加する予定がない場合でも、これは完全に安全な操作です。すべてのDCがオンラインであり、レプリケーションが適切に機能していること、スキーママスターの役割を保持しているDCにアクセスできること、およびエンタープライズ管理者とスキーマ管理者の権限があることを確認してください。

ところで、ADPREPは、2008メンバーではなく、既存の2003ドメインコントローラーの1つで実行する必要があります。サーバ。

1
Massimo

adprep、スキーマの更新などでは、問題は解決しないと思います。スキーマのアップグレードは問題ありません。新しいDCが入ってくる場合にもこれを行う必要があるためです。

私の場合、ネイティブの2008 r2があり、2000から2003、2008 r2、さらに2008 r2 ts、ts lic、2008r2ではすべてが厄介です。

しかし同じ効果。実際の環境では問題は発生しませんが、この情報をtsライセンスサーバーに記録します。

したがって、インフラストラクチャを詳しく調べると、新しく作成されたユーザーアカウントであるアカウントの一部にいくつかのmsTS属性があることがわかります。

実際、属性が欠落している組織単位のすべてのユーザーアカウントが同じグループに属していることがわかります。同じOU。したがって、この問題は、継承可能な権限設定の欠落、セキュリティ設定の欠落など、1つの問題が存在する自己作成の組織ユニットで発生すると思います。

今これをテストしています。

私がみんなに言いたいこと:

このエラー環境のシステムを更新する必要はありません。adprep、schemaprepなど。ユーザーオブジェクトのセキュリティ設定を確認してください。

mathiasrühn-kopyczynski

アドオン:解決策は、terminal-licenseserverグループの3つのmsTS属性(READおよび「WRITEターミナルサーバーライセンスサーバー」)が欠落しているユーザーオブジェクトにセキュリティ権限を付与することでした。

リモートデスクトップまたはcitrixを介して再度ログオンすると、3つの属性が特定のユーザーに作成され、情報が入力されます。

また、新しく作成されたousは、私のインフラストラクチャの1つに問題がありました。私はこの設定を第2レベルで手動で行う必要がありました。

あなたが言及する「セキュリティキー」はLDAP属性のようです(私はこれらの属性に個人的には精通していませんが、標準の命名規則に従います)ので、adsiedit.msc( Windowsで利用可能)を使用する必要がありますServer 2003 Resource Kit )を入手してください。

Adprepによるスキーマのアップグレードは良い考えです。これらの属性をもたらすだけでなく、2008DCに移行する前の期間に新しいスキーマに寝具を提供します。 Massimoが言ったように、これは安全な操作ですが、実行する前にADの実行可能なバックアップがあることを確認してください(また、自分が停電や途中で何か厄介なことが起こった場合に備えて、それから復元できます!)。

スキーマのアップグレードと同様に、TSボックスを新しいOUに移動しましたか?これを行うと、いくつかのMSサービスが不満になり、サービスを再起動していないか、ボックスを再起動していない場合、動作が不安定になる可能性があります。コンピューターの移動操作の後にADと対話するサービスを再起動することは一般的な良い習慣だと思います。

1
Maximus Minimus