「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
サポート †
Office サーバー サイド オートメーションの危険性について
http://blogs.msdn.com/b/office_client_development_support_blog/archive/2012/04/12/1-office.aspx
- マイクロソフトはサポートしない。
- ライセンス違反にも該当する。
- 技術的な観点からもこれらの実装は危険。
技術的背景 †
サーバー サイド オートメーションとは、
- 正確には、
「非対話型のセッション、ウィンドウ・ステーション、デスクトップ
で起動されたアプリケーションからのOfficeオートメーション」
であり
- サーバーサイドのコード
- Windowsサービス
- ASP (Active Server Pages)、
- DCOM、MTS、COM+
- ASP.NET、
からOfficeオートメーションを起動する事を言う。
サポートされない理由 †
- 簡潔に言ってOfficeが、非対話型の、
セッション、ウィンドウステーション、デスクトップ
上で実行される事を想定して設計実装されていないため。
- 現在のすべてのバージョンの Microsoft Office は、
クライアント ワークステーション上でエンドユーザー製品
として実行するように設計、テスト、および構成されています。
- これらの製品では、
下記の実行コンテキストを必要としています。
- 無人実行されるように設計されたサーバーサイド コンポーネントの必要性
を満たすのに必要なレベルの再入可能性やセキュリティは提供されません。
非対話型に該当する状態 †
- 非対話型に該当する状態
- プログラムの実行中にユーザがパソコンの前にいない状態
- ユーザーがログオフした状態で実行される場合
- プログラムが対話的なログオン セッション以外で実行される場合
- 通常のクライアント環境で対話型ウィンドウ・ステーション以外の
非対話型ウィンドウ・ステーションからOfficeオートメーションが
起されるような実装を行ったとしても、この処理はサポートされない。
- 例：
タスク スケジューラによって SYSTEM アカウントの下で
実行されるコードから実行されるOfficeオートメーション
発生し得る問題 †
以下、詳細
ユーザー プロファイル †
- 多くのサービスは、ユーザー プロファイルがないアカウント
(SYSTEM アカウント、IWAM_[servername] アカウントなど)で実行されます。
そのため、起動時に Office が適切な初期化に失敗する場合があります。
- IIS7 では application pool に user profile をloadできる。
Managing, Tuning, and Configuring Application Pools in IIS 7.0
http://technet.microsoft.com/en-us/library/cc745955.aspx
[loadUserProfile?]
Specifies whether IIS loads the user profile for an application pool identity.
When set to True, IIS loads the user profile for the application pool identity.
Set to False when you require IIS 6.0 behavior.
デスクトップでの対話的処理 †
- 何らかのオートメーション機能を適切に実行するために、
アプリケーションには表示が必要になることがあります。
- Office は、予期しないエラーが発生した場合、
- または機能の実行に必要なパラメータが未指定になっている場合には、
- ユーザーに操作内容を確認する
「モーダル ダイアログ ボックス」
が表示されるように設計されています。
- 非対話型デスクトップでのモーダル ダイアログ ボックスは閉じることができません。
これが原因となり、そのスレッドが応答しない (ハング) ままになります。
再入可能性とスケーラビリティ †
Office アプリケーションは、リソースを多用する各種機能を
単一のクライアントに提供するように設計された、
再入不可能な、STA ベースのオートメーション サーバーです。
（STA：生成したスレッドのみが使用できるタイプのCOM）
- サーバーサイド ソリューションとしてのスケーラビリティは低く
- グローバル リソースを使用するため同時実行可能なインスタンス数が制限される
このため、マルチクライアント環境下で利用する場合は競合が発生する可能性があるため
Office アプリケーションへのアクセスの "プール" またはシリアル化を検討して、
デッドロックまたはデータ破損の可能性を回避する必要がある。
障害許容力と安定性 †
エンドユーザー製品としての Office の障害許容力を高める
Microsoft Windows インストーラ (MSI) テクノロジによる自己修復機能が
- パフォーマンス低下、
- ダイアログ ボックス表示、
- テストされていない
等の理由から安定性を損なう。
サーバーサイドのセキュリティ †
- 着信要求の認証を行わない。
- 問題のあるVBAマクロを実行してしまう可能性がある。
- クライアントの認証情報をキャッシュできる。
クライアントサイド コンポーネント(Simple MAPI、WinInet?、MSDAIPP)
を多用するため、1 つのインスタンスで複数のクライアントにサービスを提供する場合、
なりすましにより、許可されていないアクセス権限を取得する可能性がある。
採用され易い理由 †
以下の理由で採用され易い方式となっています。
- クライアント・アプリケーションとして使い慣れているOfficeアプリケーションに
要件を実現するための機能が実装されている事を設計者が知っている事が多いため。
- Officeドキュメントの作成と編集（または印刷）に、
安価で便利なミドルウェアが存在しないため。
- 設計者がOffice サーバー サイド オートメーションの問題を知らない。
代替策 †
Office サーバー サイド オートメーションの殆どのケースが
Office ドキュメントの作成と編集（または印刷）であると言う。
Tags: :あるある, :アカウント, :障害対応, :デバッグ
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
