nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

F5のBIG-IPを使用してArcGIS Enterpriseの「Base Deployment」へのアクセスを提供する

DannyKrouk_ps

はじめに

この記事は、プリプロダクション環境でよくある基本的なユースケースについて説明します。すべてのArcGIS Enterpriseコンポーネント（Portal、Server、およびData Store）は、内部ネットワーク上の単一マシンに存在します。BIG-IPリバースプロキシは、すべてのクライアントトラフィックをBIG-IPアプライアンス経由でルーティングしながら、システムを別のネットワーク（内部クライアントネットワークまたはパブリックネットワーク）に提示できるようにします。

この記事は3つの主要なセクションに分かれています。最初のセクションはArcGIS Enterprise管理者向けで、彼らが理解する言語と用語でタスクの方向付けを行います。2番目のセクションはBIG-IP管理者向けで、彼らが理解する言語と用語で説明しています。最後のセクションは両方の管理者に適した追加のオプションと詳細について述べています。

この記事の目的は、ArcGISとF5の管理者が協力して作業できるように、協力のための実証済み手順セットを説明することです。この記事はArcGIS管理者がF5を自分で設定できるようにすること（またはその逆）を目的としていません。ArcGIS管理者はArcGISの専門家であり、詳細についてはEsriのドキュメントに依存していると想定しています。同様に、F5管理者はBIG-IPの専門家であり、詳細についてはF5のドキュメントに依存していると想定しています。

ユースケースは「基本的」ですが、取り組みは「単純」ではありません。成功には複数の専門分野（Esri技術、F5技術、ネットワーキング、証明書など）の技術と知識を統合する必要があります。この記事の手順があなたの組織環境で実行可能なほど明確でない場合、それは外部コンサルティング支援が有益であることを示しているかもしれません。

この記事は以下のユースケース仕様に基づいています：

F5のBIG-IPを「OSI Layer 7」または「フルプロキシ」として使用すること
Windowsオペレーティングシステム上のIISでWeb Adaptorを展開したArcGIS Enterpriseを使用すること

ArcGIS管理者向け指示

ArcGIS管理者の焦点は、F5 BIG-IPリバースプロキシによってプロキシされる準備ができた状態でArcGIS Enterpriseを展開することです。展開目標は以下の図に示されています。

特定の要件によっては、リバースプロキシを使用する場合にWeb Adaptorsを展開する必要がない場合もあります。しかし、以下の理由から展開することを推奨します：

Web Adaptorsを使用するとBIG-IPリバースプロキシ内の構成複雑性が軽減されます。
Web Adaptorsによりリバースプロキシとは独立してArcGIS Enterpriseシステムの正確性を検証できるため、トラブルシューティング時に非常に有用です。
Web AdaptorsはJava Web Serverを使用してLinuxベースシステム上にも展開できますが、この初期ガイドではWindows上のIISで展開される頻度が高いため、そのパターンに焦点を当てています。

ステップ1：設計決定とF5管理者との連携

この構成では、クライアントはリバースプロキシ経由でArcGIS Enterpriseにアクセスします。リバースプロキシはCNAME（「DNSエイリアス」、下図では緑色）を提示し、クライアントからのHTTPSセッションを終了します。その後、自身からWeb AdaptorsをホストするWebサーバーへの新しいHTTPSセッションを再開始します。Webサーバーは通常、BIG-IPリバースプロキシから来るHTTPSセッションを終了するAレコード（ホスト名、下図では赤色）名義の証明書を提示します。

システム展開前に以下の決定が必要です：

リバースプロキシがArcGIS Enterpriseシステムを表す（「DNSエイリアス」）は何か？
Portal for ArcGISおよびArcGIS Server Sites用の「コンテキスト」（「Web Adaptor名」、下図では青色）は何か？

CNAMEについて合意し、そのCNAME上でHTTPS通信を終了できるTLS証明書があることをF5管理者と協力して確認する必要があります。同時に、Webサーバーが稼働し要求が転送されるマシン名（Aレコード）もF5管理者と共有できます。

ステップ2：TLS証明書付きWebサーバーの展開

ArcGIS Enterprise自体に直接手を付ける前に、まずWebサーバーを展開しHTTPSトラフィック用TLS証明書で構成することが有用です。これによりWebサーバーでHTTPSが機能していることを確認でき、F5管理者も早期にリバースプロキシ設定が可能になります。TLS証明書とHTTPS経路の早期検証につながります。

WebサーバーでHTTPSを構成する

HTTPS有効化手順はWebサーバーブランドによって異なります。IISは非常に一般的なWebサーバーなので、EsriはWeb Adaptorインストールガイド内でIIS向けHTTPS構成手順を提供しています：https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/enable-https-on-your-web-server-server-.htm.

WebサーバーでHTTPSを有効化するときにはTLS証明書が必要です。証明書にはSubjectやSubject Alternative Names (SAN)など属性があります。証明書SubjectはBIG-IPリバースプロキシがWebサーバーへアクセスするときに使う名前と一致すべきです。これは多くの場合Aレコード（図中ではmachine1.domain.local）です。SANには代替名一覧があります。SANとして含める良い慣行例：

Subject名（例：machine1.domain.local）
Subject名短縮版（例：machine1）
可能ならばリバースプロキシが提示するCNAME（例：gis.domain.com）

組織ごとの認証局やポリシーによってSANへCNAME記載可否が異なります。記載するとリバースプロキシとは独立してArcGIS Enterprise検証能力が向上します。

検証

WebサーバーがHTTPS対応になったら設定検証してください。まずブラウザから直接HTTPSプロトコルでWebサーバーへアクセスし検証します。次にF5管理者がBIG-IPリバースプロキシ設定済みならばブラウザからリバースプロキシ仮想サーバーエンドポイントへもHTTPSアクセスし検証します。それぞれの場合とも証明書警告なし・ページ正しく表示されること確認してください。

通常Webサーバーにはルートアクセス時返却されるデフォルトページがあります。それでも良いですがより良い方法として状況把握しやすいページ展開があります。showHeadersページ（ASPX/IIS用とJSP用あり：https://github.com/dannykrouk/showHeaders）では多く有用な詳細情報が返されます：

showHeadersページをWebサーバールートへ展開し、それをWebサーバーおよびリバースプロキシ両方テスト対象として利用することをご検討ください。ルート配下へ展開した場合テストURL例：

ステップ3：ArcGIS Enterprise の展開および構成

ここで扱うArcGIS Enterprise展開は「単一マシンベース展開」です（https://enterprise.arcgis.com/en/get-started/latest/windows/base-arcgis-enterprise-deployment.htm#ESRI_SECTION1_690F8D4A3ABE4FB8AE926C118E9F8299）。

基本のインストールと構成

インストール手順を案内するドキュメントはEsriのウェブサイトで入手可能です：https://enterprise.arcgis.com/en/documentation/install/。

この記事では、Portal for ArcGISのWeb Adaptor名（「コンテキスト」）は「/portal」であり、Hosting ServerのWeb Adaptor名は「/server」です。ホスティングサーバーサイトをPortal for ArcGISとフェデレートするとき、Web Tier認証を使用していない限り、サービスURLと管理URLの両方にWeb Adaptorを使用できます（https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-servers.htm）。Web Tier認証を使用している場合、管理URLは次のパターンに従う必要があります：https://machine1.domain.local:6443/arcgis。

基本の検証；「システム信頼性チェック」

Web Adaptorsが構成され、Hosting Serverがフェデレートされたら、コア機能が正しく動作することを確認するために簡単な「システム信頼性チェック」を実行すべきです。

典型的なシステム信頼性チェックには以下が含まれます：

これらのステップで確立される「信頼」は、展開されたシステムに基本的な操作を妨げる根本的な構成上の欠陥がないことを意味します。

システム信頼性チェックで作成したもの（例：公開したサービス）は続行前に削除してください。

リバースプロキシの最終構成

最終構成ステップはPortalとHosting ServerのWebContextURLを設定することです。このプロパティは各EsriサーバーがクライアントがBIG-IPリバースプロキシ経由でアクセスする名前を知る方法です。

Portal for ArcGIS: https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm#ESRI_SECTION1_7C753FB1F19349A398E5FFCC6079A821

{
  "WebContextURL": "https://gis.domain.com/portal"
}

ArcGIS for Server: https://enterprise.arcgis.com/en/server/latest/deploy/linux/using-a-reverse-proxy-server-with-arcgis-server.htm#ESRI_SECTION1_13680C9069E14B1F8AE5793BE1ED25A6

{
  "WebContextURL": "https://gis.domain.com/server"
}

ステップ4：システム検証

ArcGIS管理者にとって4番目で最後のステップはBIG-IPリバースプロキシとは独立した「システム検証」です。この方法で検証し、リクエストがリバースプロキシ経由で流れる際に何か問題があれば、その原因はリバースプロキシ構成にあります。この方法で検証しないと問題の原因特定が非常に複雑になる可能性があります。

Webサーバーマシン上で名前解決を一時的に変更する

この検証のコツはCNAME（gis.domain.com）がArcGIS Enterpriseマシン（machine1.domain.local）にあると一時的にシステムに認識させることです。machine1.domain.localマシンのローカル管理者権限があればhostsファイルを編集できます。machine1.domain.localのIPアドレスが10.0.0.10の場合、hostsファイルエントリは次のようになります：

10.0.0.10       gis.domain.com

これは「gis.domain.comは10.0.0.10にあります」と示しています。

このファイル（通常はC:\Windows\System32\drivers\etc\hosts）への編集完了後、コマンドプロンプトを開きpingコマンドで設定が有効か確認してください：

C:\>ping gis.domain.com

Pinging gis.domain.com [10.0.0.10] with 32 bytes of data:

Reply from <machine1のIPアドレス>: bytes=32 time=22ms TTL=124

…

pingコマンド結果はhostsファイル内のIPアドレス（上記で強調表示されたプレースホルダー値）であるべきです。

Webサーバーマシン上のブラウザでテストする

次にmachine1.domain.local上でウェブブラウザを開き、「システム信頼性チェック」を再度実行します。今回はCNAME（https://gis.domain.com/portal/home/）でシステムにアクセスします。

この方法でシステムが正常に動作すればhostsファイル変更を元に戻し、F5管理者に設定作業完了を依頼してください。

F5管理者向け指示書

BIG-IP視点から見るとこれは単純な構成です。ArcGIS Enterpriseシステムには複数コンポーネントがありますが、リバースプロキシから見るとHTTPS/443で待機する単一バックエンドウェブサーバーノードがあります。他のシステムと異なる可能性がある唯一の構成要素はArcGIS EnterpriseがX-Forwarded-Hostヘッダーをリバースプロキシに含める必要があることです。

大まかには、プロキシ構成はすべてのHTTPSトラフィックをgis.domain.comCNAMEへ終端し、単一バックエンドノードmachine1.domain.localへHTTPSを再開始します。このアドレス上のウェブサーバーはArcGIS Enterprise主要コンポーネントそれぞれ用の2つの「コンテキスト」、すなわち/portalと/serverをサポートしています。

この記事冒頭で説明したように、BIG-IPプロキシにはクライアントネットワーク、サーバーネットワーク、および管理ネットワークという3つのネットワークが関連付けられていると仮定しています。

この記事ではBIG-IP管理者として専門家であり、この仮想サーバーおよびバックエンドプールを最適な順序で設定するための手順だけを示すことを想定しています。

ステップ1：ウェブサーバーへのプロキシ設定

このシステム用CNAMEはあなたにより確立済みか通知済みであるべきです。そのCNAME用TLS証明書も提供されているべきです。証明書発行機関はこのシステムクライアントから信頼されている必要があります。

TLS証明書のインストール

BIG-IP内仮想サーバー用TLS証明書（例：Subject gis.domain.com）をインストールします。

System > Certificate Management > Traffic Certificate Management > SSL Certificate List > Import SSL Certificate

クライアントSSLプロファイル作成

gis.domain.com名用証明書上でクライアントTLS接続を終了するためクライアントプロファイルを作成します。

Local Traffic > Profiles > SSL > Client > Create

Simple Monitor付きプール作成

(例：https://machine1.domain.local/)ウェブサーバー用バックエンドプールを作成し、ノードリソースが「稼働中」か「停止中」か判定するSimple Monitorを設定します。

Local Traffic > Pools > Pool List > Create

<\/span><\/H3> <\/P>HTTP Services Profile の作成（X-Forwarded-Host ヘッダーの追加）<\/H3>X-Forwarded-Host ヘッダーは、ArcGIS Enterprise が BIG-IP に到着した Host ヘッダーの値を認識できるようにします。 ArcGIS Enterprise システムは、この値を設定と照合し、クライアントが適切な方法でアクセスしていることを確認します。 X-Forwarded-Host ヘッダーが存在しないか、誤った値が含まれている場合、ArcGIS Enterprise は HTTP リダイレクトを発行して、どのようにアクセスすべきかを示そうとします。これによりリダイレクトループが発生する可能性があります。ArcGIS Enterprise がリダイレクトループを検出した場合、それを解除してエラーを返します。<\/P>iRule を使って X-Forwarded-Host ヘッダーを含めることができます:<\/P>when HTTP_REQUEST {

HTTP::header insert X-Forwarded-Host [HTTP::host]

}<\/PRE> <\/P>このディレクティブは、到着したリクエストの Host ヘッダーの値を取得し、それをデフォルトプールへの X-Forwarded-Host ヘッダー値として設定します。<\/P>仮想サーバーの作成<\/H3>Local Traffic > Virtual Servers > Create<\/P>仮想サーバーのタイプとして「Standard」を選択します。以前に作成した SSL 証明書付きの SSL Profile (Client) を指定します。サーバープロファイルを指定する際の目的は、バックエンドへの TLS トンネルを確立することです。これは BIG-IP のデフォルト設定「serverssl」で実現できます。「Source Address Translation」は Auto Map に設定してください。<\/P><\/span><\/P> Resources タブで、先に作成したプールを選択します。<\/P><\/span><\/P> <\/P>ステップ 2: ArcGIS Enterprise へのプロキシ検証<\/H2>この構成の有効性を検証するには 2 つのステップがあります。 <\/P>信頼性とヘッダーの検証<\/H3>バックエンド Web サーバーに showHeaders.aspx ページが展開されていると仮定し、Web ブラウザで https:\/\/gis.domain.com\/showHeaders.aspx<\/A> にアクセスしてください。ブラウザには証明書の信頼警告が表示されないはずです。このページのレスポンスボディは、X-Forwarded-Host ヘッダー構成の有効性を証明します。<\/P>
<\/span><\/P> <\/P>この時点で、ヘッダーがバックエンドに正しく流れていることが確認できたため、showHeaders.aspx ツールは不要になります。本番環境や情報公開が望ましくない環境では、このツールは削除すべきです。<\/P>

ArcGIS Enterprise での有効性検証<\/H3>Web ブラウザで https:\/\/gis.domain.com\/portal\/home\/<\/A> にアクセスし、「Sign in」リンクをクリックしてください。認証情報入力ページが表示されれば、X-Forwarded-Host ヘッダーと ArcGIS Enterprise の設定との整合性が確認されたことになります。このテストに失敗した場合、最も考えられる原因はヘッダー値と ArcGIS Enterprise の WebContextURL 設定との不一致です。<\/P>
任意の検証ステップとして以下があります:<\/P>
2 番目の ArcGIS Enterprise サーバーロール（ArcGIS Server）がアクセス可能か確認:
https:\/\/gis.domain.com\/server\/rest\/services<\/A>..<\/>SPAM>サポートされていないコンテキスト（例: https:\/\/gis.domain.com/not-a-real-context\/<\/>）使用時の挙動確認。この場合、プール内 Web サーバーから HTTP 404 コードが返されることを期待します。<\/>LI>
これでシステム構成は完了し、受け入れテストへ進めます。<\/>P>

最後に<\/>H2>ここまでの手順を完了すると、F5 の BIG-IP リバースプロキシ経由でアクセス可能な完全な ArcGIS Enterprise システムが構築されています。おめでとうございます。<\/>P>この記事では以下の締めくくりの考察を提供します。<\/>P>テスト<\/>H3>これらの手順では展開・構成プロセス全体で「システム信頼チェック」と検証が規定されています。これらは次の手順へ進む妥当性を判断するためのものであり、システムが受け入れ可能であることを証明するものではありません。最終的にはシステム全体が機能していることを前提としています。言い換えれば、これらのテストはシステムの機能的一貫性を確立します。<\/>P>次に適切なステップは受け入れテストに渡すことです。受け入れテストの目的は展開されたシステムがビジネス目標に適合しているか測定することです。<\/>P>ヘルスチェック<\/>H3>F5 管理者向け手順に含まれる Simple Monitoring により、BIG-IP はノード（例：machine1.domain.local）がダウンまたはアクセス不可の場合に ArcGIS Enterprise システムへのリクエスト転送を停止できます。このような単一バックエンドプールメンバーの場合、Simple Monitor が推奨されるヘルスチェックの全範囲となります。<\/>P>原理的には BIG-IP はアウトオブバンドヘルスチェックとして ArcGIS Enterprise ソフトウェアに健康状態確認や特定 HTTPS リクエスト成功・レスポンス検証を要求する設定も可能です。例えば Portal for ArcGIS コンポーネントは以下エンドポイントを公開しています: https:\/\/developers.arcgis.com/rest/enterprise-administration/portal/health-check-portal.htm<\/>A>. 単一ノードシステムではヘルスチェック問題への応答はシステム全体へのアクセス遮断につながります。その利点はリバースプロキシがシステム停止中である旨の一般的なエラーをクライアントに提供できることです。不利な点は一時的・部分的問題や誤解釈によるヘルスチェック結果不良が多くの場合サービス可能な状態でも全アクセス遮断につながることです。正式・複雑なヘルスチェックによる偽陰性（不健康判定）の確率は単純ノード監視による偽陽性（健康判定）よりもユーザーへの信頼性低下につながる可能性があります。言い換えれば単一ノードシステムでは複雑さは信頼性の敵なので Simple Monitor を使うべきです。<\/>P>

謝辞<\/>H3>この記事は Esri プロフェッショナルサービスコンサルタント Roger Schlogel の業績に基づいて作成されました。<\/>P> <\/>P> <\/>

タグ付けされた投稿をもっと見る

Configuration & Integration

Architecture & Security

AndreaB_

Fantastic, thank you!!

MatejVrtich

@DannyKrouk thanks for the great explanation.

Would it be possible to describe the configuration of F5 BIG-IP without the use of ArcGIS Web Adaptors?

Thanks,

Matej

DannyKrouk_ps

@MatejVrtich Thank you for the appreciation.

I don't have plans to write such an article. Much of the work would be the same. The main difference is that you have to re-write the 3xx series response location headers whenever they contain the back-end machine name/native port combination. This is only needed for the front-side channel, not the admin pathways. This document notes the need to do so (but leaves the implementation up to the reverse proxy admin ... because reverse proxies all have different ways of doing such things): https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm.

AndreaB_

Hi again @DannyKrouk ,

I just read this https://enterprise.arcgis.com/en/portal/11.1/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm

Does this contradict your blog post? I'm confused on this one.

Thanks!

DannyKrouk_ps

Hello @AndreaB_ - Thanks for the question.

I am not sure how this statement in the doc, "Portal for ArcGIS does not support SSL offloading through a reverse proxy server/load balancer. Therefore, if your configuration uses a reverse proxy server, it must forward traffic to either the ArcGIS Web Adaptor or directly to Portal for ArcGIS over HTTPS" is in conflict with this blog post.

The blog post describes how to forward traffic "to the ArcGIS Web Adaptor" (really to the web server hosting it). So, that seems in alignment.

The bit about "does not support SSL offloading" is, perhaps, confusing because "SSL offloading" can mean different things. But, both F5 and Wikipedia agree with the sense that I think Esri means in its documentation. "Offloading" does not mean "terminate and re-initiate TLS sessions". Rather, "offloading" means "terminate TLS sessions and leave the back-end traffic unencrypted". This post does not describe an "SSL offloading" configuration; it describes a "terminate and re-initiate" configuration ... which is what Esri supports.

Am I missing something?

AndreaB_

Hi @DannyKrouk,

Thank you for the extra information. I'm sure it's not you that's missing something...I'm sure it's me! 🙂 This isn't my strong area so all of the extra information and explanation I can gather the better. Yes, you answered the parts that were confusing me. I'm finding some of these IT terms are used pretty loosely, interchangeably, or generally, and that's not helping. If you know of any other videos or training in this area I would greatly take that advice also. I come from the Esri side so I'm missing some of the parts of the IT side that would help with this. I'm starting to wrap my head around it though and it's been fun to learn a new side of the Enterprise set-up.

Thanks!

DannyKrouk_ps

@AndreaB_ I hope the additional explanation is helpful to you and others. I suspect you are not the only person with a question like this. Regarding other resources, I confess that I've not reviewed the content myself, but this is a big new offering from Esri that seems like it would have information in this space: https://architecture.arcgis.com/en/introducing-the-arcgis-architecture-center.html?rsource=https%3A%2F%2Fwww.esri.com%2Fcontent%2Fdam%2Fesrisites%2Fen-us%2Fmedia%2Ftechnical-papers%2Farchitecting-the-arcgis-system.pdf (The Well Architected Framework).

AndreaB_

Thank you so much for that link, @DannyKrouk. The intended audience for the ArcGIS Architecture Center website, https://architecture.arcgis.com/en/overview/well-architected-framework/mission-and-intended-audience.html , states as below:

"While the primary audience of this site is intended to be IT professionals, architects, and support teams, GIS professionals will also benefit from the topics covered here, as they increasingly are asked to learn and understand IT principles and concepts as part of their work in modern enterprise GIS systems."

I feel seen, thank you! Happy Holidays 🙂

TimWillson

Not sure why my post was marked as spam. I'll try again.

@DannyKrouk, this is well detailed article that will be very helpful to our deployment. One question, how does the directions differ if Portal and Server are on separate servers? Thanks for your insight!

DannyKrouk_ps

@TimWillson "It depends"? 😉

If the Portal and Server Web Adaptors are not on separate servers, then nothing about the load balancing approach would be different ... because BIG-IP is balancing the web servers, not the Esri software servers themselves.

If the Web Adaptors are on separate servers, there are many design alternatives. Maybe you are presenting them on a single VIP and using path-based routing to land on separate backend pools. Maybe you are exposing two VIPs, each routed to its separate backend pool.

I think, for there to be a specific answer, there needs to be a more detailed specific design. And, that level of detail (in question and in answer) is a bit outside the intent of this article. That is, this article is focused on foundational education such that you can work out the details with your team of F5 and GIS admin experts.

TimWillson

@DannyKrouk No worries. I wasn't sure if it was simple tweak. 👍 I will be giving this a shot. Thanks for your reply!

TimWillson

@DannyKrouk when federating the portal and server, do you use the machine1 URL or gis.domain URL to the server web adapter? I can access the maps thru Field Maps but not the layers in the map since it seems pointing to machine1 for the rest services.

DannyKrouk_ps

When you federate, you provide Portal with two parameters: (a) the ServicesURL and the ServerAdminURL. The ServicesURL *must* be through the proxy (F5, which then goes to the Web Adaptor, which then goes to ArcGIS Server). The ServerAdminUrl is up to you. It is *private* to the system's administrative communications. You can send it through the proxies or not.

FieldMaps is one application among many ... and can be hard to study when compared to a web browser. I would recommend that you study the problem from a web browser client. If you cannot repro a problem with your browser, then the issue might be with FieldMaps ... or networking that is not part of your proxy configuration.

TimWillson

Thank you. That cleared it up and it is working as intended now. I appreciate all of the help.

KrystalPhaneuf4

Hi @DannyKrouk this is super helpful.

We are running into an issue with our F5 configuration with client to server calls to Enterprise.

Our Portal has a federated server that is also the hosting server. Portal and Server are on separate machines. Let's say the Portal URL is portal.city.org/portal and the federated Server URL is server.city.org/server.

We have used different DNS aliases for third party cloud hosted applications that are accessing our GIS services. If the services are secured and server tries to authenticate with Portal with this different DNS (thirdparty.city.org/server) it fails because Portal is only allowing authentication requests from server.city.org.

My question is, is there a way to use the F5 the change the host name and referer before it gets to the generate token request on Portal?

DannyKrouk_ps

What you are describing, where different clients use different CNAMEs to access the same ArcGIS Enterprise components is, as far as I know, not supported (Esri Tech Support is the authority on that).

To your specific question, F5 sales reps and informed observers agree (in a rare reversal of the typical relationship between sales reps and informed observers -- ha, ha!) that F5's BIG-IP can do almost anything. BIG-IP has been changing HTTP headers for years.

So, with considerable effort and great responsibility, you can 'middleware' your way to make ArcGIS Enterprise think that all requests come from the same CNAMEs. But, I don't think Esri Tech Support would help you do that. And, I would not be able to "talk you through" the principles or procedures here.

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.