-
Notifications
You must be signed in to change notification settings - Fork 0
MS_OfficeServerSideAutomation
- 戻る(サービス・タスク系のいろいろ、Visual Basic for Applications (VBA))
- Office サーバー サイド オートメーション
- Microsoft Office
Office サーバー サイド オートメーションの危険性について
- マイクロソフトはサポートしない。
- ライセンス違反にも該当する。
- 技術的な観点からもこれらの実装は危険。
サーバー サイド オートメーションとは、
-
正確には、
「非対話型のセッション、ウィンドウ・ステーション、デスクトップ
で起動されたアプリケーションからの Office オートメーション」であり
-
サーバーサイドのコード
- Windows サービス
- ASP (Active Server Pages)
- DCOM、MTS、COM+
- ASP.NET
から Office オートメーションを起動する事を言う。
-
簡潔に言って Office が、非対話型の、
セッション、ウィンドウステーション、デスクトップ
上で実行される事を想定して設計実装されていないため。 -
現在のすべてのバージョンの Microsoft Office は、
クライアント ワークステーション上でエンドユーザー製品として
実行するように設計、テスト、および構成されています。- これらの製品では、下記の実行コンテキストを必要としています。
- 対話型デスクトップ
- ユーザー プロファイル
- 無人実行されるように設計されたサーバーサイド コンポーネントの必要性を
満たすのに必要なレベルの再入可能性やセキュリティは提供されません。
- これらの製品では、下記の実行コンテキストを必要としています。
-
非対話型に該当する状態
- プログラムの実行中にユーザがパソコンの前にいない状態
- ユーザーがログオフした状態で実行される場合
- プログラムが対話的なログオン セッション以外で実行される場合
-
このためサーバ上での実装に限定されず、
- 通常のクライアント環境で対話型ウィンドウ・ステーション以外の
非対話型ウィンドウ・ステーションから Office オートメーションが
起動されるような実装を行ったとしても、この処理はサポートされない。 - 例:タスク スケジューラによって SYSTEM アカウントの下で
実行されるコードから実行される Office オートメーション
- 通常のクライアント環境で対話型ウィンドウ・ステーション以外の
補足(「サーバーで動かさなければ大丈夫」ではない): ここが
本ページで最も誤解されやすい点である。
問題はサーバーかクライアントかではなく、
対話型セッションかどうかである。
実行方法 対話型か Office オートメーション ユーザーがログオンして手で実行 ○ サポートされる タスク スケジューラ「ログオンしているときのみ実行」 ○ 動く(ただし要注意) タスク スケジューラ「ログオンしていなくても実行」 × サポート外 Windows サービス × サポート外 IISのワーカ プロセス × サポート外 「開発機では動いたのに本番のバッチで固まる」という典型的な事故は、
この行の違いによる。詳細は
サービス・タスク系のいろいろの
「セッション 0 分離」も参照。
- 不安定な動作
- デッドロック
- etc.
以下、詳細。
-
多くのサービスは、ユーザー プロファイルがないアカウント
(SYSTEM アカウントなど)で実行されます。
そのため、起動時に Office が適切な初期化に失敗する場合があります。 -
IIS 7 以降では、アプリケーション プールに
ユーザー プロファイルをロードできる(loadUserProfile)。loadUserProfile
Specifies whether IIS loads the user profile for an application pool identity.
-
何らかのオートメーション機能を適切に実行するために、
アプリケーションには表示が必要になることがあります。- Office は、予期しないエラーが発生した場合
- または機能の実行に必要なパラメータが未指定になっている場合
には、ユーザーに操作内容を確認する
「モーダル ダイアログ ボックス」が表示されるように設計されています。 -
非対話型デスクトップでの「モーダル ダイアログ ボックス」は
閉じることができません。
これが原因となり、そのスレッドが応答しない (ハング) ままになります。
補足(これが最も多い障害): 実務で遭遇する Office オートメーションの
障害は、ほぼこれである。
- 誰にも見えないダイアログが出る
- スレッドがそこで止まる
EXCEL.EXEがプロセスとして残り続ける- 蓄積してメモリを食い潰し、最終的にサーバーが不調になる
しかもダイアログが出る条件は多岐にわたる
(更新リンクの確認、読み取り専用の推奨、フォントの置換、
マクロの有効化確認、修復の提案…)ため、
「テストでは出なかったダイアログ」で本番が止まる。
DisplayAlerts = Falseで消せるものもあるが、全部は消せない。
Office アプリケーションは、リソースを多用する各種機能を
単一のクライアントに提供するように設計された、
再入不可能な、STA ベースのオートメーション サーバーです。
(STA:生成したスレッドのみが使用できるタイプの COM)
- サーバーサイド ソリューションとしてのスケーラビリティは低く
- グローバル リソースを使用するため同時実行可能なインスタンス数が制限される
このため、マルチクライアント環境下で利用する場合は
競合が発生する可能性があるため、Office アプリケーションへのアクセスの
"プール" またはシリアル化を検討して、
デッドロックまたはデータ破損の可能性を回避する必要がある。
エンドユーザー製品としての Office の障害許容力を高める
Microsoft Windows インストーラ (MSI) テクノロジによる自己修復機能が
- パフォーマンス低下
- ダイアログ ボックス表示
- テストされていない
等の理由から安定性を損なう。
- 着信要求の認証を行わない。
- 問題のある VBAマクロを実行してしまう可能性がある。
- クライアントの認証情報をキャッシュできる。
クライアントサイド コンポーネント(Simple MAPI、WinInet、MSDAIPP)を
多用するため、1 つのインスタンスで複数のクライアントに
サービスを提供する場合、なりすましにより、
許可されていないアクセス権限を取得する可能性がある。
以下の理由で採用され易い方式となっています。
- クライアント・アプリケーションとして使い慣れている
Office アプリケーションに要件を実現するための機能が実装されている事を
設計者が知っている事が多いため。 - Office ドキュメントの作成と編集(または印刷)に、
安価で便利なミドルウェアが存在しないため。 - 設計者が Office サーバー サイド オートメーションの問題を知らない。
Office サーバー サイド オートメーションの殆どのケースが
Office ドキュメントの作成と編集(または印刷)であると言う。
- 参考:帳票印刷
補足(現在の代替策): 「安価で便利なミドルウェアが存在しない」という
当時の前提は、現在では成り立たない。
Open XML(.xlsx/.docxは ZIP + XML)を直接操作するライブラリが
揃っており、Office のインストール自体が不要である。
用途 ライブラリ 備考 Excel 生成・編集 ClosedXML MIT。最も手軽 同上 EPPlus 5.0 以降は商用有償 同上 NPOI Apache 2.0。Java の POI 移植 Word / Excel 共通 Open XML SDK Microsoft 純正。低レベルだが確実 PDF 生成 QuestPDF / iText コードで定義 HTML → PDF Playwright / Puppeteer(ヘッドレス Chromium) Web の表現力をそのまま使える // ClosedXML の例(Excel 不要・サーバーで安全に動く) using var wb = new XLWorkbook(); var ws = wb.AddWorksheet("Sheet1"); ws.Cell("A1").Value = "売上"; wb.SaveAs("report.xlsx");「テンプレートの
.xlsxを読み込んで値を埋めて保存する」という
帳票の定番パターンも、これらで問題なく実現できる。
今から Office オートメーションを選ぶ理由は無い。
補足(クラウド側の選択肢): Microsoft 365を
利用している場合は、次も選択肢になる。
手段 内容 Microsoft Graph API OneDrive / SharePoint 上のブックをサーバーレスに操作 Power Automate ノーコードで Office ファイルの生成・変換 Office Scripts Excel on the web 上で動くスクリプト ただし Microsoft 365 のライセンスは「人」に紐づくため、
サーバー処理専用にライセンスを 1 つ割り当てて回す、という運用は
ライセンス上適切ではない点は Office オートメーションと同じである。
Tags: 移行, あるある, アカウント, 障害対応, デバッグ, Microsoft Office
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。