Application Discovery Load Balancer Service EndpointFailure（topology.svc）

sharepoint.stackexchange https://sharepoint.stackexchange.com/questions/119191

  •  29-09-2020
  •  | 
  •  

質問

ショートバージョン： ApplicationDiscoveryおよびLoadBalancer Service Application Proxyの「ServiceEndpointUri」を変更するにはどうすればよいですか？サーバーを変更すると、古いサーバー（もう存在しない）のコンピューター名が表示され、Windowsイベントログに複数のイベントが作成されます。

A failure was reported when trying to invoke a service application: EndpointFailure
Process Name: OWSTIMER
Process ID: 13248
AppDomain Name: DefaultDomain
AppDomain ID: 1
Service Application Uri: urn:schemas-microsoft-com:sharepoint:service:7ef0d151811845ae8907ddfb3f524183#authority=urn:uuid:bdbf864d34e5409    58698ce45b524e982&authority=https://old-appserver:32844/Topology/topology.svc
Active Endpoints: 1
Failed Endpoints:1
Affected Endpoint: http://new-appserver01:32843/7ef0d151811845ae8907ddfb3f524183/ProfileService.svc

ロングバージョン： SPファームを2台から4台のサーバーに拡張しました。まず、4台の新しいサーバーをファームに追加し、サービスアプリケーション（検索など）を移行しました。次に、[プログラムの追加と削除]（Windowsのコントロールパネル）からSharePointをアンインストールして、2台の古いサーバーを削除しました。

もちろん、分散キャッシュサービスを修正する必要がありましたが、アプリケーション検出とロードバランサーサービスアプリケーションを除いて、すべて正常に機能するようになりました。上記のように、イベントログにはEventId 8313が表示されます。また、次のPowerShellコマンドは次のようになります。

(Get-SPTopologyServiceApplicationProxy).ApplicationProxies | Format-List *

間違った「ServiceEndpointUri」が表示されます。これは古いアプリケーションサーバーです。

ServiceEndpointUri          : https://old-appserver:32844/Topology/topology.svc

十分ではありません。CAでは、プロキシはアプリケーション検出およびロードバランササービスアプリケーションの下にリストされていません。プロキシは、サービスアプリケーションリストのほぼ最下部に配置され、スタンドアロンです。

enter image description here

そして：このコマンドを実行すると、4つの新しいSharePointサーバーのみが表示され、古いappserverは表示されません...

Get-spserviceinstance | Select TypeName, Server

誰かがこれらのイベントログを取り除き、私のサービスアプリケーションを修正するのを手伝ってもらえますか？

どうもありがとうございました！

役に立ちましたか？

解決

方法はありますが、サポートされておらず、ファームの構成データベースのオブジェクトテーブルの行を直接変更する必要があります。

まず、を使用して変更する必要があるプロキシのGUIDを取得します

(Get-SPTopologyServiceApplicationProxy).ApplicationProxies | Format-List *

次に、SQL Server管理コンソールを開き、ファームの構成データベースをホストするサーバーとインスタンスに接続し、クエリウィンドウを開いて、そのデータベースのオブジェクトテーブルに対して次のクエリを発行します。

SELECT        Id, ClassId, ParentId, Name, Status, Version, Properties
FROM          Objects
WHERE         Id = '[YOUR PROXY GUID HERE]'

これで1行引き戻されます。その行の[プロパティ]列に関心があります。それをかなりすばやく拡張して、障害のあるサーバーを検索できます。単にそれを既知の良好なサーバーと交換してください。エントリのプロパティ列の元のテキストをコピーして、参照する必要がある偶然の場所に保存することは、おそらく悪い考えではありません。

Enterキーを押して変更を保存し、サーバーの全体管理に移動して、[サービスアプリケーションの管理]を更新します。これで、プロキシが適切に配置されます。

私はこれについてマイクロソフトと時間を過ごしましたが、これを行うための「サポートされている」方法はありません。構成ウィザードはこれをチェックし、それに応じて構成データベースを更新するツールである必要があるため、バグとして開くように依頼しました。さらに、プロパティ自体は読み取り専用であるため、これを行うPowershellの方法はありません。基本的に、これを設計した人は誰でも、ファーム内の最初のサーバーの削除を予期していなかったようです。これにより、サーバーが削除されないか、この問題に苦しむことになります。さらに厄介なことに、この問題は、特にPerformancePoint Webパーツの場合、ファームのパフォーマンスに非常に現実的な結果をもたらすように見えます。

他のヒント

（問題を解決する）答えに加えて：Config DBの行を照会した後は、データを編集できません。ただし、別のSQLクエリを使用してコンテンツを更新できます。

UPDATE Objects
WHERE Id = '[YOUR PROXY GUID HERE]'
SET Properties = '[YOUR UPDATED COLUMN CONTENT]'
ライセンス： CC-BY-SA と 帰属
所属していません sharepoint.stackexchange
scroll top