Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.8.3) E51441-03 |
|
![]() 前 |
![]() 次 |
この章では、Microsoft OfficeとWebCenter Portal 11g (11.1.1.1.0)以降との統合の構成に必要なシステム管理作業の概要について説明します。Microsoft OfficeをWebCenter Portalとともに使用する方法は、『Oracle Fusion Middleware Oracle WebCenter Portalの使用』の「Microsoft OfficeおよびExplorerの統合での作業」を参照してください。
この章には次のトピックが含まれます:
権限: この章のタスクを実行するには、次のロールが付与されている必要があります。
第1.8項「管理操作、ロールおよびツールの理解」も参照してください。 |
図26-1は、標準のMicrosoft Office統合トポロジを、トポロジ内における各コンポーネント固有の構成関連のメモとともに示しています。Microsoft Office統合の構成方法の詳細は、第26.2項「Microsoft Office統合の構成」を参照してください。
Microsoft Office統合を構成すると、WebCenter Portal環境内からMicrosoft OfficeアプリケーションおよびMicrosoft Office Enterprise Editionアプリケーションと対話できるようになります。Windowsの各バージョンに対応したアクティビティは、『Oracle Fusion Middleware Oracle WebCenter Portalの使用』の「Microsoft OfficeおよびExplorerの統合での作業」に記載されているマトリックスを参照してください。
Oracle HTTP Serverおよびロード・バランサ
OHS (または、ロード・バランサ)は、リクエストがSharepointサーブレットにルーティングされるように、適切に構成する必要があります。シングル・サインオンを使用している場合は、第33.6項「仮想ホストを使用したSSOの構成」の説明に従って、SSOによって保護されていない仮想ホストを作成する必要があります。これは、トポロジのエッジ・サーバーで行います(つまり、ロード・バランサまたはOHSのいずれか)。-Dnon_sso*
javaパラメータは、第33.6.5項「仮想ホスト用のWebCenter Portalの構成」の説明に従って、非SSO保護仮想ホストをポイントするように設定する必要があります。
SSL有効化エントリ・ポイント
SSLは、ロード・バランサまたはOHSのうちトポロジのエッジ・サーバーである方に対して構成する必要があります。
Microsoft Officeクライアント
SSLを使用しないとセキュリティ・リスクが発生するため(ユーザーの資格証明が暗号化されずに渡される)お薦めしませんが、各クライアント・マシンのレジストリを構成してMicrosoft OfficeをHTTPで認証するようにできます。詳細は、第26.3項「非SSL統合の構成」を参照してください。
WC_Spaces管理対象サーバー
適用できるJVM引数を示し、特にどの引数がどのような条件で必要なのかについて確認します。詳細は、第26.2項「Microsoft Office統合の構成」の手順2を参照してください。
SSLがエッジ・サーバー(OHSまたはロード・バランサのいずれか)で有効になっている場合、エッジ・サーバーのSSL資格証明の「信頼できる証明書」をWC_Spaces
サーバーのキーストアにインポートする必要があります(第26.4.3項「SSLの使用でドキュメントのチェックアウトが不可能になる」を参照)。
Internet Explorerまたはサポートされているブラウザ
Internet Explorerでは、ActiveXを有効にする必要があります。FirefoxやGoogle ChromeなどのInternet Explorer以外のブラウザでは、Javaプラグインをインストールする必要があります。詳細は、第26.4.1項「Officeで「編集」をクリックしてもWordが起動しない」を参照してください。
Windows/WebCenter Portalユーザー・アカウント
Windowsユーザー・アカウントとWebCenter Portalログイン・アカウントは同等の関係である必要があります。Microsoft Officeとの統合を稼働する方法によっては、WebCenter Portalユーザー・アカウントをWindowsユーザー・アカウントに独自に関連付ける必要があります。特にWindows 7では、Windows 7 WebClientによりユーザー資格証明書がWindows 7ユーザー・コンテキストにキャッシュされ、その結果、Windows 7のユーザーごとに1つのWebCenter Portalユーザーしかサポートできなくなります。詳細は、第26.4.2項「ドキュメント・ライブラリからのドキュメント編集に関する問題(Windows 7)」を参照してください。
この項では、Microsoft Officeをデスクトップ統合に対して構成する方法を説明します。その構成手順に従うには、次の要件を満たしている必要があります。
Oracle WebCenterのフロントにWeb層(Oracle HTTP Server)がインストールされている。Oracle HTTP Serverインストールの詳細は、『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』のOracle Web層のインストールと構成に関する項を参照してください。
Oracle HTTP Server (1つが使用されている場合にはロード・バランシング・ルーター)でSSLが構成され有効化されている。デスクトップ統合でMicrosoft Office 2010を使用している場合、SSL設定は必須です。Microsoft Office 2007を使用している場合、SSL設定をお薦めしますが必須ではありません。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』の「SSLを使用したブラウザからWebCenter Portalへの接続の保護」を参照してください。
証明書がcacerts
またはWebLogicデフォルトのトラスト・ストアでシード済の既知の認証局で発行されたものではない場合、使用しているSSL証明書の公開証明書がWebLogicトラスト・ストアにインポートされている。詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalの管理』の「SSLを使用したブラウザからSpacesへの接続の保護」の項を参照してください。
WebCenter PortalがOAMで構成されている場合、OAMの管理者はリソースURLを、保護レベルをExcluded
に設定して追加する必要があります。
/wcsdocs* /wcsdocs/.../* /_vti_*
リソースURLの設定の詳細は、Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイドのポリシーで使用するリソース定義の追加と管理に関する項を参照してください。
OHS構成で呼び出されるOAM保護は、メイン接続ポートに限定的に適用する必要があり、後述の手順で構成するセカンダリの保護されていないSharePointポート(この例では、4444
)に適用しないでください。webgate.conf
(場合によっては、httpd.conf
)からOblixの値を削除し、メインのWebCenter接続(ポート80
または7777
)に対する有効な仮想ホスト・コンテナで、それらの値を置換する必要があります。その後で、後述の手順1および2で新しい仮想ホストを作成すると、ポート(この例では、4444
)が作成されます。SharePointのプロトコルは、このポートを使用してOAM SSOなしで通信できます。詳細は、第33.6.4項「OAM 11g用の仮想ホストの構成」を参照してください。
注意: WebCenter PortalのMicrosoft Officeとの統合は、Microsoftによって確立されたSharePointサーバーとやり取りするMicrosoftデスクトップ・アプリケーション用のモデルに従います。WebCenter Portal統合では、 クライアント側では、WindowsにログインしたユーザーがWebCenter Portalにログインする際に使用するユーザー・アカウントに関連付けられる可能性があるため、同一のWindowsユーザー・アカウントを使用した複数のWebCenter Portalアカウントへのログインを避けることが重要です。特にWindows 7 WebClientサービスでは、エミュレートされたSharePointサービスのエンドポイントにログインするために使用した資格証明書がキャッシュされるため、同一のWindowsユーザー・アカウントからWebCenter Portalへの様々なログイン・アカウントをサポートすると予期しない結果を生じます。詳細は、第26.4.2項「ドキュメント・ライブラリからのドキュメント編集に関する問題(Windows 7)」のトラブルシューティングの説明を参照してください。 |
デスクトップ統合でWebCenter Portalを構成するには:
webtier mod_wl_ohs.conf
ファイル(OHS_HOME
/Oracle_WT1/instances/
instance1
/config/OHS/ohs1
ディレクトリにあります)に、次のマッピングが存在することを確認します。
<Location /wcsdocs> SetHandler weblogic-handler WeblogicHost webcenter.example.com WeblogicPort 8888 </Location> <Location /_vti_bin> SetHandler weblogic-handler WeblogicHost webcenter.example.com WeblogicPort 8888 </Location>
ここで、webcenter.example.com
は、WebCenter Portalがインストールされているホストを指します。
サンプルのOHS mod_wl_ohs.conf
ファイルは、付録B「WebCenter PortalのOracle HTTP Server構成」を参照してください。
環境がクラスタである場合は、仮想ホスト設定を使用して、SharePointルート・アプリケーションにルーティングすることをお薦めします。
注意: 単一ノード設定を指定している場合は、SSOが構成されている場合でも仮想ホストは必要ありません。 |
クラスタ環境では、httpd.conf
ファイル(OHS_HOME
/Oracle_WT1/instances/
instance1
/config/OHS/ohs1/
ディレクトリにあります)に、次のエントリが存在することを確認します。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerNamewebtier.example.com
</VirtualHost> <VirtualHost *:7777> ServerNamewebtier-spaces.example.com
<Location /> SetHandler weblogic-handler WebLogicHostwebcenter.example.com
WebLogicPort 8888 </Location> <Location /webcenter> Deny from all </Location> <Location /webcenterhelp> Deny from all </Location> <Location /rest> Deny from all </Location> </VirtualHost>
ここで:
webtier.example.com
は、OHSホストを指します。
webtier-spaces.example.com
は、仮想ホストを指します。webtier-spaces.example.com
のエントリでDNSを更新していることを確認してください。
webcenter.example.com
は、WC_Spaces
管理対象サーバーがインストールされているホストを指します。
環境でSSO設定を指定している場合は、SSOをバイパスできるように仮想ホストを構成します。詳細は、第33.6項「仮想ホストを使用したSSOの構成」を参照してください。
domain_home
/bin/setDomainEnv.sh
(UNIX)、またはdomain_home
\bin\setDomainEnv.cmd
(Windows)に、次の必須パラメータを追加します。
EXTRA_JAVA_PROPERTIES= "${EXTRA_JAVA_PROPERTIES} -Dnon_sso_protocol=http -Dnon_sso_host=webcenter.example.com
-Dnon_sso_port=8888 -Dsso_base_url=http://webtier.example.com
:7777" export EXTRA_JAVA_PROPERTIES
ここで:
non_sso_protocol
は、Microsoft OfficeアプリケーションからWC_Spaces
管理対象サーバーにアクセスする際に使用するURLのプロトコルです。
non_sso_host
は、WC_Spaces
管理対象サーバー(webcenter.example.com
)、または仮想ホスト(webtier-spaces.example.com
)をポイントするホストです(設定されている場合)。
non_sso_host
は、WC_Spaces
管理対象サーバーのポート8888、または仮想ホストのポート7777をポイントするホスト・ポートです(設定されている場合)。
sso_base_url
は、SSOまたはOHSにアクセスするためのURLです(通常、WebCenter Portalで使用されるものと同じ)。
なんらかの理由でSSLをOHSまたはロード・バランサで構成しないインストールについては、各クライアントに対してクライアント・レジストリ情報を構成してMicrosoft Office製品に組み込まれた制限をオーバーライドする必要があります。次のMicrosoftのサポート・サイトを参照して、下の手順に従ってください。手順は、Windowsのバージョン間で多少違うことに注意してください。
http://support.microsoft.com/kb/2123563
この項には次のサブセクションが含まれます:
問題
Microsoft Officeの「編集」機能で、Internet Explorer以外のブラウザを使用した場合、Wordまたは関連のOfficeアプリケーションが起動されません。
解決策
Microsoft Office統合をIE以外のブラウザで作業するには、Javaプラグインが必要です。ブラウザでJavaプラグインを有効化してあることを確認してください。Javaプラグインのインストールの手順は、ブラウザのドキュメントを参照してください。
問題
Windows 7への最初のユーザーのログインでは、Microsoft Office統合機能を問題なく使用できます。ところが、それ以降にユーザーが同じWindows 7ログインで同じデスクトップのWebCenter Portalにログインすると、特にドキュメントのチェックインとチェックアウトの際に、問題が発生することがあります。これらの問題は、すべてのブラウザとMicrosoft Officeを停止しても解決されません。
この問題はWebClientサービスによるものです。Windowsネイティブ・サービスによりオペレーティング・システムでHTTPリクエストとWebDAVリクエストが送信され、それにより最初の資格証明書がキャッシュされます。WebClientサービスでは、他のWindows機能による使用(ユーザーがネットワークの場所を追加するなど)が対象であるため、このサービスにアクセスするたびに資格証明書が要求されるのではなくキャッシュされます。しかし、資格証明はWindows 7のログイン・ユーザーとの関連でキャッシュされ、Spacesログインとは連携していません。
したがって、WebClientサービスでは最初のユーザーの資格証明を使用して、リクエストがWebCenter Portalドキュメント・サービスに送信されます。2番目のユーザーの場合、WebCenterセキュリティ・モデルにより2番目のユーザーがアクセスしているフォルダ上のドキュメントに最初のユーザーの資格証明がアクセスできない(必要な権限がない)ため、この問題が発生します。正常にアクセスできても、最初のユーザーがチェックアウトしたように表示されます。
解決策
この問題を解決する手順は次のとおりです。
2番目のユーザーがこの機能を使用する前にマシンを再起動します。
Windowsからログアウトして、異なるWindows 7ユーザーを使用してログインします。
WebClientサービスを再起動します。
これらの解決策による問題は、システム管理者の権限が必要であり、WebClientサービスがその他のWindows 7機能によって使用されるため、サービスを停止するとそのWindows 7機能が影響を受けることがあります。この問題を回避する最も簡単な方法は、同じデスクトップとWindows 7ログインを複数のWebCenter Portalのユーザー・アカウントやFusionアプリケーションのユーザー・アカウントで共有しないようにすることです。
問題
Officeで「編集」をクリックすると、ドキュメントをチェックアウトできなかったことを示すダイアログが表示されます。数回ログインを試行すると、Microsoft Officeは開きますが、ドキュメントは読取り専用モードでチェックアウトされていません。
解決策
この問題は、特に次の環境に関連しています。
ブラウザがInternet Explorerである
OHSまたはロード・バランサがWC_Spaces
サーバーのフロントに設定されていない
SSLがOHS上で有効であり、OHSで終了する(OHSからWC_Spaces
サーバーへの接続が非SSLであるなど)
この症状が発生するのは、バックエンド(WC_Spaces
サーバー)からOHS (またはロード・バランサ)へ2つ目のHTTPSリクエストがあるためで、WC_Spaces
サーバーが信頼されていないことが原因でSSLキーの例外がスローされます。このリクエストにより、ドキュメントのチェックアウトが実行されます。
この問題を解決する手順は次のとおりです。
信頼できる証明書をOHSまたはロード・バランサからWC_Spaces
サーバーへインポートします。
次の手順に従って、信頼できる証明書をOHSウォレットからエクスポートします。
OHSを管理するFusion Middleware Controlインスタンスにログインします。
「Web層」→「OHS1」を選択します。
「OHS」ドロップダウン・リストから、「セキュリティ」→「ウォレット」を選択します。
「デフォルト」をクリックします。
CN="\"Self-Signed Certificate for ohs1 \"", OU=OAS, O=ORACLE, L=REDWOODSHORES, ST=CA, C=US
を選択します。
「エクスポート」をクリックします。
ファイルを保存します("ohsTrustedCertificate"などとして)。
ファイルをWC_Spaces
サーバーのローカル・ディスクにコピーします。
次のkeytoolコマンドを使用して、OHSの信頼できる証明書をWLS DemoTrust.jks
にインポートします。
JAVA_HOME/bin/keytool -importcert -v -alias ohscert -file /mycert/ohsTrustedCertificate -keystore /my_mw_home/wlserver_10.3/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase
DemoTrustKeyStorePassPhrase
はDemoTrust.jks
のデフォルトのパスワードです。
キーストアのパスを検出する手順は、次のとおりです。
WLSコンソールにログインします。
「環境」→「サーバー」→「WC_Spaces」を選択します。
「構成」タブを開き、「キーストア」を選択します。
問題
Internet Explorerでドキュメントの「Officeで編集」をクリックすると、Microsoft Officeが作業ウィンドウにタブを1つのみ表示して起動します。
解決策
この問題が発生するのは、ドキュメントを開いたときに「マイ・ローカル・ドラフト・フォルダを使用する」オプションがInternet Explorerで選択されたためで、その結果、ファイルはサーバーに接続されずにユーザーのローカル・フォルダにコピーされます。それ以降そのファイルにチェックインしないと、他のユーザーがFirefoxやChromeなど他のブラウザでそのドキュメントを編集する際にも同じ症状が発生します。この問題を回避するには、Internet Explorerで「マイ・ローカル・ドラフト・フォルダを使用する」オプションのプロンプトが表示されたら、どのユーザーも必ず選択を解除してください。その他のすべてのブラウザでは、「オプション」→「保存」を各MS Officeアプリケーションで必ず使用してください。
問題
Firefox使用時にWebCenter PortalからMicrosoft Officeアプリケーションに接続できません。
解決策
Java 7でのセキュリティ問題のため、Firefoxではプラグイン・リストで有効化と表示されている場合でも現在Javaプラットフォーム・プラグインがブロックされています。そのため、Microsoft Office統合が無効になります。
JavaおよびMicrosoft Officeの統合をFirefoxで使用するには、さらにプラグインのアイコンをクリックする必要があります(図26-2参照)。
ブラウザの左上のURLバーの近くに表示され、必要なサイトで明示的にJavaを有効にします。