MID Server File Synchronisation の仕組み - トラブルシューティングガイド<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 複数の機能およびアプリケーションは、インスタンス内のレコードおよび添付ファイルを MID Server 上のファイルへ同期するために、同じ MID Server プラットフォームコードを共有しています。この記事では、トラブルシューティングを支援するために、関連する手順およびコードについて説明します。 目次 関連するテーブル同期ジョブのトリガー方法 添付ファイルフィールドアクティブフラグ このシステムを使用しているアプリケーションMID サーバーがジョブを処理する方法 ファイルが変更されたことを認識する方法Scripted SOAP ServicesECC Agent Script File の "Checksum" フィールドDomain Separationフォルダー構造 (Folder structure) トラブルシューティングと既知の問題 クローンによって削除された添付ファイルフォームへの添付ファイルのアップロードの問題MID サーバーエージェントログの確認 再同期の強制実行 (Force a resync)ディスクをチェックして何が同期されたかを確認変更を行わずに任意のテーブルの再同期を強制するCode SigningMID Server はフォルダーおよびフィールド由来のファイルは同期するが、添付ファイル由来のファイルは同期しないレコードのフィールドまたは添付ファイルは変更されたが sys_updated_on は変更されなかった同じレコード上の複数の添付ファイルScript File および JAR File には一意の名前が必要JJAR は extlib に手動コピーされたか、それとも lib に配置されたか一般的なヒント既知の制限 関連問題 その他の記事 関連するテーブル このシステムを使用するためには、テーブルが MID Server Synchronized File [ecc_agent_sync_file] を拡張している必要があります。以下は、ITOM プラグインがインストールされた Orlando における MID Server Synchronized File テーブルの拡張のスキーママップです。それ以降にさらに多くのものが追加されています。 同期ジョブのトリガー方法 添付ファイル これらのテーブルのいずれかのレコードに添付ファイルが追加されると、そのファイルは自動的にすべての MID Server の MID Server インストールフォルダーツリー内のディスクに配置されます。 その後、インスタンス内でファイルが変更されると、そのファイルはすべての MID Server と自動的に再同期されます。 同期は通常、Attachment [sys_attachment] テーブル内でレコードが追加、変更、削除された際に作成されるシステムイベントによってトリガーされます。 Events [sysevent] の名前は以下のとおりで、イベントの Parm1 は添付ファイルが属するテーブル名です。 attachment.uploadedattachment.renamedattachment.deleted 各イベントには、すべて「MID Server file synchronization check」という名前の Script Action [sysevent_script_action] があり、そのテーブルを MID Server に再同期するよう指示します。 Script Action は、Script Include「MIDServerFileSync」の「notifyMIDServers」関数を呼び出し、イベントの Parm1 のテーブル名を使用して ECC Queue テーブル [ecc_queue] の output レコードを挿入します。 agent = mid.server.*source = FileChangename = <添付ファイルが存在するテーブル>topic = SystemCommandqueue = outputstate = readypriority = 0 (interactive) ecc_queue 上の「Probe - All MIDs」Business Rule は、その "mid.server.*" レコードをコピーし、各 MID Server ごとに固有の output を挿入します。 MID Server が Up 状態かどうか、または Ready 状態の既存の重複ジョブがあるかどうかに関係なく、すべての MID Server にジョブが作成されます。 フィールド 2013 年以降、フィールドの内容も MID Server 上のファイルへ同期できるようになりました。 この場合、該当テーブル上の Business Rule が FileChange ジョブをトリガーします。 アクティブフラグ 新しい MID Server は inactive なファイルを同期しません。 MID Server の再起動時には同期が行われ、その時点で前回の同期以降に inactive になったレコードに対応するファイルは削除されます。 TODO - 少なくとも Washington の JAR Files テーブルでは、Active のチェックを外しても同期がトリガーされません。これは不具合である可能性があります。 回避策: MID Server を再起動します。起動時に inactive レコードに対応するファイルが削除されます。 このシステムを使用しているアプリケーション 以下のテーブルは、拡張テーブルクラス、それらの名称、それらを使用するアプリケーション、および通常のイベントトリガー同期と異なる点を示しています。その他多くの項目も MID Server のメモリキャッシュへ同期されますが、ファイルにはなりません。 テーブル使用元添付ファイルまたはフィールドディレクトリAgent Client Collector Plugin [sn_agent_asset]ITOM Features, IntegrationHub, Vulnerability response, etc.Attachmentstatic\acc_plugin\ 「Notify MID on Agent Asset Changes」Business Rule は、sn_agent_asset 上で Script Include 「MIDNotificationHandler」の「notifyMIDServers」関数を呼び出し、前述と同様の ECC レコードを挿入します。 注: agent\static\cert\servicenow\SNCertificates.zip ファイルはインスタンスから同期されません。これは ACC Endpoint 拡張機能の起動時、または「Trigger ACC certificate sync」がクリックされた際に、Install Server からダウンロードされます。 Agent Client Collector Configuration File [sn_agent_configuration_file]Data files for ACC pluginsAttachmentstatic\acc_configDiscovery Patterns [sa_pattern]DiscoveryService MappingField: Pattern [ndl]work\ndl 「Notify MID server on NDL change」Business Rule は sa_pattern 上で Script Include 「PatternLibrary」の「notifyMIDs」関数を呼び出します。 sa_pattern の「Synchronize with MID Servers」UI Action は、パターンの sys_updated_on 値を更新することで同期を強制します。 これも Script Include 「PatternLibrary」の「notifyMIDs」関数を呼び出します。 これは /sa_pattern_list.do リストでパターンのチェックボックスを選択した後に利用できるリストアクションです。 MID Server フォームの「Pattern Sync to Mid」UI Action は、Script Include 「PatternLibrary」の関数を使用してパターンおよびその他の Pattern 関連コンテンツを同期します。 これら 3 つの方法はいずれも Script Include 「PatternLibrary」の「notifyMIDs」関数を使用し、この関数が Script Include 「MIDNotificationHandler」の「notifyMIDServers」関数を呼び出して、同様の ECC レコードを挿入します。 MID Server Extension JAR File [ecc_agent_ext_jar]TBCAttachmentTBCMID Server JAR File [ecc_agent_jar]Import Set JDBC DriversOrchestrationExternal Credential StoreCloud ManagementAttachmentextlibMID Server MIB File [ecc_agent_mib]SNMP DiscoveryAttachmentwork\mibsMID Server Script File [ecc_agent_script_file]DiscoveryOrchestration Attachment or Script [script] field. scripts\<parent directories> 対象ディレクトリは、レコードの親レコードによって異なります。 directory=true のレコードはフォルダー構造を定義し、実際のファイルではありません。 添付ファイルテーブル上の他の Business Rule が、Synchronized File レコードを更新します。 Insert/Update: Update MID script on attachment changeDelete: Update MID script on attachment deletion これらは Synchronized File レコード上の以下のフィールドを更新またはクリア/inactive 化します。 script_attachment - Attachment [sys_attachment] レコードを参照する sys_id。このフィールドは、複数のファイルが添付されている場合に重要です。checksum - Attachment テーブル内のファイルの MD5 Checksumuse_attachment - フィールド値ではなく添付ファイルを使用するよう MID Server に指示します。active - ファイルが添付されていない場合は false に設定されます。 Uploaded File [sa_uploaded_file]Discovery and Service Mapping PatternsAttachment work/uploaded_files 「Synchronize with MID Servers」UI Action を使用して同期を強制できます。このアクションは Script Include 「SaUploadedFiles」を呼び出し、その中で Script Include 「MIDNotificationHandler」の「notifyMIDServers」関数を呼び出して、前述と同様の ECC レコードを挿入します。 「GetAllUploadedFiles」Scripted SOAP Service は、すべての Service Mapping のアップロード済みファイルを取得するために MID Server によって使用されます。 MID サーバーがジョブを処理する方法 各 MID Server は、特定のテーブル用の FileChange output を ecc_queue 内に持ちます。 MID Server が UP 状態であり、インスタンスに接続されていて、利用可能な interactive スレッドを持っている場合、そのジョブを ECC Queue から取得して実行します。 注: 以下の処理はすべて MID Server にコンパイルされた Java コード内で実行されるものであり、顧客が確認できるコードではありません。 処理の進行に伴い、一部のログが MID Server Agent ログへ出力されます。 SystemCommand オブジェクトは ECC Queue output の name フィールドを確認し、それが FileChange の場合は、同期対象テーブルを type とする SyncedFileChangeEvent を作成します。 その後、実際の同期用に新しい FileSyncWorker スレッドが作成されます。 この際、同期対象タイプ専用の Syncher が使用され、useAttachment、ターゲットフォルダー、使用フィールドなどの属性が事前定義されています。 JarSyncer、MIBSyncer、ScriptFileSyncer、AssetFileSyncer は AFileSyncer を拡張します。NdlFileSyncer および SaUploadedFileSyncer は DelayedFileSyncer を拡張します。Delayed file syncher は enabled フラグが変更されるまでファイルを同期しません。 その後、MID Server の FileSyncWorker コードがプロセス全体を管理します。 まず、MID Server に同期対象となる指定ファイル群の Snapshot を取得します。 この Snapshot は、インスタンス内の Scripted SOAP Service 「MIDFileSyncSnapshot」[sys_web_service] に要求されます。 その要求が実行された証跡は、Transaction Log [syslog_transaction] の URL: "/MIDFileSyncSnapshot.do?SOAP" として確認できます。 処理はディレクトリごとに再帰的に実行され、1 回に 1 ディレクトリずつ処理されます。 ディレクトリ内では各ファイルが個別に処理され、Snapshot から以下の属性が取得されます。 useAttachment : 添付ファイルが存在する場合は true。どのモードを使用するかを決定します。添付ファイルと script フィールドの両方が存在する場合、添付ファイルが優先されます。複数の添付ファイルが存在する場合、MIDFileSyncSnapshot は最新の添付ファイルのみ返します。フィールドを使用する場合は false が返されます。name : sys_attachment の file_name。添付ファイルがない場合は Synchronized File レコードの name。id : sys_attachment の sys_id。添付ファイルがない場合は Synchronized File レコードの sys_id。time : sys_attachment の sys_updated_on/sys_created_on。添付ファイルがない場合は Synchronized File レコードの sys_updated_on。checksum : ecc_agent_script_file レコードの場合、Synchronized File レコードのフィールドに保存された sys_attachment の MD5 checksum。 モードに応じて、IDownloadedFileWriter 関数は InstanceFormFieldToFileDownloader または InstanceFileDownloader を使用して、以下の Scripted SOAP Service のいずれかに要求を送信し、インスタンスからフィールドまたは添付ファイルを取得します。これもインスタンスの Transaction Log で確認できます。 MIDFieldForFileProvider : InstanceFormFieldToFileDownloader により呼び出されます。MID Server がファイルとして書き出す対象フィールドの値と、そのレコードの作成日時および更新日時を取得します。MIDServerFileProvider : InstanceFileDownloader により呼び出されます。MID Server に同期されるファイルコンテンツを提供します。 /sys_attachment.do も、インスタンスから MID Server へ添付ファイルをダウンロードするために使用される場合があります。 インスタンスレコードに checksum が含まれている場合（ecc_agent_script_file の添付ファイルでは必須）、MID Server はダウンロードしたファイルと checksum を照合します。 ファイルが変更されたことを認識する方法 ファイルを置き換える必要があるかどうかを判断するロジックは次のとおりです。 ローカルファイルが存在し、その「最終更新時刻」がインスタンス内のファイルの timestamp（レコードまたは添付ファイルの sys_updated_on 値）と 4 秒以上異なる場合（古い場合も新しい場合も含む）、そのファイルは異なるものと判断されます。 ファイルを置き換えるかどうかの判断には checksum やサイズは使用されません。 ディスク上から手動削除されたファイルは、このプロセスによって再作成されます。 また、以下の場合にはファイルやディレクトリが MID Server から削除されることがあります。 ファイルがインスタンスに存在せず、MID Server フォルダー内へ手動配置されている場合。そのようなファイルは未承認ファイルとみなされ削除されます。添付ファイルまたはレコードがインスタンスから削除された場合、またはフィールドを持つレコードが削除された場合。インスタンス内で Directory レコードが削除された場合。その親を持つレコードもカスケード削除されます。ディスク上ではフォルダーとその内容が削除されます。ファイルが置き換えられる場合。まず削除され、その後新しいファイルに置き換えられます。 Windows では、起動時に JVM クラスローダーによって設定されるファイルロックのため、JAR ファイルは MID Server の停止後に削除する必要があります。 このようなファイルは PowerShell スクリプトを使用して外部から削除されます。また、この自動削除および置換プロセスは、完了するまでに最大 3 回の再起動を引き起こす場合があります（バッチファイルおよび PowerShell スクリプトについては TBC）。 インスタンスの Transaction Log を確認する場合は、再起動後に MID Server の Session ID が変更されることに注意してください。 San Diego、Rome Patch 4、および Quebec Patch 10 より前のバージョンでは、代わりに以下のバッチファイルが使用されていました。 bin\filesyncdelete.bat この外部削除 PowerShell スクリプトまたはバッチファイルのログは、以下に保存されます。 agent/logs/filesyncdelete.log Scripted SOAP Services MIDFileSyncSnapshot MID Server に対して、ディレクトリツリーを含め、一般的に何を同期する必要があるかを通知します。その後、各ファイルについて、以下のいずれかが個別に要求されます。 MIDFieldForFileProvider : フィールド内にコンテンツを持つレコード用です。MIDServerFileProvider : 添付ファイルを持つレコード用です。 ECC Agent Script File の "Checksum" フィールド Utah リリース以降、script フィールドベース（添付ファイルベースではない）の MID Server Script File で Checksum フィールドに値がないものには、以下によって Checksum が追加されます。 Business Rule「スクリプトのChecksumを生成」修正スクリプト「スクリプトファイルのChecksum生成」アプリのインストール/アップグレードに関連するイベント:- plugin.upgrade : Script Action 「Generate Checksum on Plugin Upgrade」により処理されます。plugin.activated : Script Action 「Generate Checksum on Plugin Activation」により処理されます。 添付ファイルを持つすべてのもの、およびすべての ECC Agent Script File について、MID Server はファイル同期時にこれらの Checksum を検証します。これにより、ディスク上に作成されたファイルの Checksum が、インスタンスレコードのフィールドから計算された値と一致することを確認します。 問題がある場合、以下のメッセージで MID Server Issues レコードが作成されます。 "Checksum validation on MID server for <filepath> failed with checksum - <checksum>" Domain Separation 以下のテーブルは Domain Separation 対応です。 MID Server MIB ファイル [ecc_agent_mib]MID Server JAR ファイル [ecc_agent_jar]MID Server スクリプトファイル [ecc_agent_script_files] 次を参照してください。 MID Server domain separation フォルダー構造 (Folder structure) ecc_agent_sync_file を拡張するすべてのテーブルのレコードには、このフィールドの組み合わせがあります。ただし、これらは 'MID Server Script File' および 'Agent Client Collector Plugin' レコードでのみ使用する必要があります 。 Directory : true の場合、そのレコードはディレクトリを表し、'Name' がフォルダー名になります。Parent : Directory レコードへの参照です。 これによりフォルダー構造を定義し、ファイルをどのフォルダーへ配置するかを指定できます。 たとえば、以下の 3 つの MID Server Script File レコードは、scripts フォルダー配下のサブフォルダー内に配置される PowerShell スクリプトファイルを定義します。 .\agent\scripts\Powershell\SCCMSpoke\ActionAddToDeviceCollection.ps1 Name=ActionAddToDeviceCollection.ps1、Directory=False、Script フィールドにスクリプトが存在、Parent=SCCMSpokeName=SCCMSpoke、Directory=True、Parent=PowershellName=Powershell、Directory=True、Parent= Parent フィールドおよび Directory フィールドは、MIB、JAR、Pattern、およびその他の同期ファイルタイプには設定してはいけません。これらはすべて同じトップレベルフォルダーに配置する必要があります。サブフォルダー内のレコードは MID Server コードから認識されないためです。 PRB2079673 : ecc_agent_jar レコードに Parent が設定されている場合、JAR ファイルは extlib のサブフォルダーに同期され、Java から認識されません。 トラブルシューティングと既知の問題 単一レコードの更新であっても、そのテーブル内のすべてのレコードを再同期するジョブが作成されます。多数の MID Server に対して大量のレコードが同時更新された場合、この重複によってパフォーマンス上の問題が発生する可能性があります。 クローンによって削除された添付ファイル Clone 時に添付ファイルが除外され、保持されなかった場合、Clone 後に添付ファイルが欠落することがあります。これは sa_uploaded_file において複数回確認されています。KB0786475 MID Servers and Clones フォームへの添付ファイルのアップロードの問題 添付ファイルのアップロード中に発生する可能性のあるエラー: ファイルタイプが許可されていないか、mime タイプがファイルコンテンツと一致しません。インスタンスが JAR ファイルを添付ファイルとして許可するように設定されていない場合は、jar がシステムプロパティ glide.attachment.blacklisted.extensions にリストされている可能性があります。 フィールドペイロードに対してコンテンツが大きすぎます。最大長 (ストレージ): 16,777,215、圧縮長: 16,940,311 (またはファイルが何であれ)たとえば、大規模な JDBC ドライバーから。これにより、添付ファイルの追加や MID サーバーへの同期は妨げられません。これは更新セット/バージョンシステムからのプラットフォームエラーで、sys_update_xml/sys_update_versionテーブルの mediumtext の「ペイロード」フィールドを参照します。これは、ecc_agent_jarテーブルのバージョニング/更新セットの追跡をオフにすることで回避できますが、エラーは無視できるため必須ではありません。MID サーバーケース追跡PRB1499103の問題チケット。 添付ファイルのアップロード時に発生する可能性があるエラー: ファイルタイプが許可されていない、または MIME タイプがファイル内容と一致しない。 例えば、jar がシステムプロパティ glide.attachment.blacklisted.extensions に含まれているために、インスタンスで JAR ファイルの添付が許可されていない場合があります。 Content too large for field payload; max length (storage): 16,777,215, compressed length: 16,940,311 (または対象ファイルのサイズ) 大きな JDBC ドライバーなどで発生する場合があります。これは添付ファイルが追加されることや MID Server へ同期されることを妨げるものではありません。 Update Set / Versions システムによるプラットフォームエラーであり、sys_update_xml / sys_update_version テーブルの mediumtext 型 payload フィールドに関連しています。 ecc_agent_jar テーブルの versioning/update set tracking を無効化することで回避できますが、必須ではありません。このエラーは無視できます。 MID Server ケース追跡用 Problem Ticket: PRB1499103 MID サーバーエージェントログの確認 MID Server を再起動すると、起動時にすべてのテーブルが再同期されます。すべてのテーブルが同期され、各テーブル内のすべてのファイルが確認され、必要に応じて同期されます。 特定フォルダー内のファイルはまとめて処理されます。Agent ログは debug を有効化していなくても、起動時または FileChange SystemCommand 実行時に各テーブルの同期を表示します。 2023-10-09T18:37:44.430+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:81] Starting file synchronization: sn_agent_asset...2023-10-09T18:37:45.231+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:141] Synchronizing 2 files to C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all2023-10-09T18:37:45.231+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:174] Synchronizing C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all\app-ci-metrics-acc-commons.tar.gz2023-10-09T18:37:45.241+0200 INFO (FileSync:sn_agent_asset) [FileDownloader:35] Downloading C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all\app-ci-metrics-acc-commons.tar.gz from https://<instance>.service-now.com/sys_attachment.do?sys_id=ae33d183530221102f10ddeeff7b124b2023-10-09T18:37:45.241+0200 DEBUG (FileSync:sn_agent_asset) [AAttachmentFileDownload:45] Downloading attachment using UnsignedAttachmentFileDownload2023-10-09T18:37:45.610+0200 INFO (FileSync:sn_agent_asset) [AAttachmentFileDownload:84] Attachment successfully downloaded 1908 bytes2023-10-09T18:37:45.610+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:174] Synchronizing C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all\acc-f-commons.tar.gz2023-10-09T18:37:45.610+0200 INFO (FileSync:sn_agent_asset) [FileDownloader:35] Downloading C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all\acc-f-commons.tar.gz from https://<instance>.service-now.com/sys_attachment.do?sys_id=f0378b99d1047110f877eca2213bddee2023-10-09T18:37:45.610+0200 DEBUG (FileSync:sn_agent_asset) [AAttachmentFileDownload:45] Downloading attachment using UnsignedAttachmentFileDownload2023-10-09T18:37:45.833+0200 INFO (FileSync:sn_agent_asset) [AAttachmentFileDownload:84] Attachment successfully downloaded 12619 bytes...2023-10-09T18:38:05.534+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:92] Finishing file synchronization: sn_agent_asset 再同期の強制実行 (Force a resync) インスタンス内で何かを変更したり MID Server を再起動したりすることなく、手動で同様の ecc_queue レコードを挿入して再同期を強制することができます。 agent = mid.server.* : Business Rule により、このレコードは自動的に各 MID Server 用に複製されます。source = FileChangename = ＜添付ファイルが存在するテーブル＞ : 例: ecc_agent_jartopic = SystemCommandqueue = outputstate = readypriority = 0 (interactive) : Standard priority でも正常に動作します。 これは、例えば JAR ファイルが inactive に設定されたにもかかわらず再同期が即座にトリガーされなかった場合（潜在的な不具合）に有用です。 ディスクをチェックして何が同期されたかを確認 mid.server.* 宛ての ecc_queue output に以下の DIR コマンドを設定すると、各フォルダーに何が同期されたかを input レコードで確認できます。 Agent: mid.server.*Topic: CommandName:dir /b /s static\*.* dir /b /s scripts\*.*dir /b /s work\mibs\*.*など Queue : outputPayload：<parameters><parameter name="skip_sensor" value="true"/></parameters> 日付、サイズ、権限などを確認するために、dir、ls、chmod その他のコマンドやスイッチの組み合わせを使用できます。 変更を行わずに任意のテーブルの再同期を強制する mid.server.* 宛ての ecc_queue output に以下の SystemCommand を送信すると、顧客インスタンスに変更を加えることなく、そのテーブルの再同期を強制できます。 Agent: mid.server.*Topic: SystemCommandName: sn_agent_assetecc_agent_jarecc_agent_script_fileなど Source: FileChangeQueue: output Code Signing Xanadu 以降、同期対象テーブル内のほとんどの OOTB レコードには、それに対応する OOTB シグネチャが含まれているはずです。 Washington DC 以降、ファイルに対してシグネチャが生成されていない場合、以下のようなエラーが表示されます。 SOAPProcessorThread... SignatureUtil SEVERE *** ERROR *** Unable to find the signature with the sys id, bb3d1f433ca68210b1b3fd8eb2644ca6, for the table, sn_agent_asset. com.glide.codesigning.exception.CodeSigningException: Cannot just-in-time load the signature record: Couldn't find pluginId for documentId: bb3d1f433ca68210b1b3fd8eb2644ca6 with signatureRecordSysId: 16b5e7ab6a3d44b8849161d672273e91 at com.glide.codesigning.output.JustInTimeLoadingEngine.loadSignatureRecordJustInTime(JustInTimeLoadingEngine.java:89) インスタンスで Code Signing を有効化していてシグネチャが存在しない場合、そのファイルは同期がブロックされ、それに依存する機能は動作しません。 一般的な詳細およびまだこの機能をサポートしていない項目については、以下を参照してください。 KB1646201 MID Server and Code Signing - Unable to find the signature / Cannot just-in-time load the signature record / Failed to verify signature MID Server はフォルダーおよびフィールド由来のファイルは同期するが、添付ファイル由来のファイルは同期しない 添付ファイルが存在するにもかかわらず同期されない場合、MID Server ログインユーザーに対する添付ファイルの ACL 問題である可能性があります。MID Server ログインユーザーは、対象テーブルレコードの ACL だけでなく、添付ファイル用の sys_attachment テーブル ACL も通過する必要があります。 例: sn_agent_asset OOTB ではディレクトリツリーといくつかの添付ファイルが定義されています。 Debug Security を有効化する。admin/maint として sys_attachment リストを開き、table IS 対象テーブルでフィルターし、添付ファイルが存在することを確認する。MID Server ユーザーへ Impersonate する（Impersonate を可能にするため、ユーザーの Web service access only=false）。リストを更新し、どの ACL が失敗しているか確認する。attachment 名が CONTEXT に表示される "record/sys_attachment/read" ACL を探します。 5. クリーンなインスタンスと ACL を比較する。 OOTB では、レコードが読み取れる場合にその添付ファイルの読み取りを許可する ACL は以下です。 /sys_security_acl.do?sys_id=0bcf23740a6a38d400c7e02590038464 この ACL にはスクリプトのみが含まれています。 条件は存在しないはずですが、インストールされているプラグインによっては Role 要件が含まれる場合があります。Explicit Roles プラグインがインストールされている場合、mid server ユーザーへ snc_internal ロールを追加する必要があります。Query Business Rule にも注意してください。 レコードのフィールドまたは添付ファイルは変更されたが sys_updated_on は変更されなかった このシナリオには以下の製品拡張 Problem が存在します。 PRB1639539 MID Server sync files with the instance only based on "sys_updated_on" field in the new insert/update xml これは、ServiceNow 開発によって OOTB レコードが変更された場合でも、sys_updated_on が変更されなければ MID Server が変更を認識できないことを意味します。 既存の MID Server は古いバージョンのファイルを保持し続けます。 変更後に初めて同期された新規 MID Server のみ、新しいファイルを取得します。 同じレコード上の複数の添付ファイル 同じレコードに複数の添付ファイルが存在する場合、どの添付ファイルが MID Server に同期されるかはランダムになります。 すべてが同期されるわけではありません。 添付ファイルを使用する場合は、1 レコードにつき 1 添付ファイルのみとする必要があります。 Script File および JAR File には一意の名前が必要 Orchestration Workflow Activity は、PowerShell スクリプトを sys_id ではなく MID Server Script File レコードの名前で参照します。 そのため、これらのレコード名は一意である必要があります。 JAR ファイル添付は添付ファイル名を保持したまま同じ extlib フォルダーへ配置されるため、名前が一意である必要があります。 Windows のファイル名は大文字小文字を区別しないため、このチェックも大文字小文字を区別しません。 Business Rule Prevent Duplicate,Spaces & Colon in nameValidate MID Jar filename uniqueness は、insert および update を中止することでこれを強制します。 ただし XML インポートされたレコード（および場合によっては Update Set）はこのチェックを回避する可能性があります。 JJAR は extlib に手動コピーされたか、それとも lib に配置されたか ecc_agent_jar テーブルに存在しない extlib 配下のファイルは、次回同期または次回 MID Server 再起動時にディスクから削除されます。 これはセキュリティ上の理由によるものです。 インスタンス内で JAR File レコードを作成できる admin ロールを持つユーザーのみが、MID Server に Java クラスを追加できます。 手動で lib フォルダーへコピーした場合も、次回の自動アップグレード時に削除されます。 一般的なヒント 前述の UI Action をクリックすると、多くの同期問題は解決します。 ecc_queue output が表示されない場合、Session Debug を使用して Business Rule が実行されたことを確認できます。また、sysevent テーブルを確認することで添付ファイルイベントが作成されたかどうかを確認できます。 ecc_queue output が存在する場合は、ready 状態のまま止まっていないか確認してください。 MID Server は稼働中で正常ですか。 Agent ログにジョブ実行が表示されていますか。 通常、ジョブ開始および終了に関連する Agent ログには ecc_queue output レコードの sys_id が表示されます。 FileSyncWorker スレッドのログには Snapshot、ダウンロード、およびファイル操作に関する問題が表示されます。 ecc_queue input に MID Server コードからのエラーメッセージが出力される場合があります。 mid.log.level MID Server パラメーターを debug に設定すると、大量のログが Agent ログに出力されます。 レコードごとに添付ファイルが 1 つしか存在しないことを確認してください。Package=MID Server または Pattern Designer の Scripted SOAP Service が最新の OOTB バージョンであることを確認してください。同じホスト上の他の MID Server や別ホストの MID Server と比較してください。新しいクリーンな MID Server をインストールすると、問題箇所の特定に役立つ場合があります。フォルダー権限は現在 MID Server 起動時に確認されますが、古いバージョンでは原因となる可能性があります。Scripted SOAP Service 内の各所へ gs.log() を追加すると、処理対象のファイルや添付ファイルをより詳細に確認できます。Topic=Command の ecc_queue output を使用し、Name フィールドに "dir /s" や "ls -lsR" を指定することで、対象フォルダー内のファイルをリモート確認できます。既存のインストールフォルダーをコピーして新しい MID Server を作成することは避けてください。新規インストールを行い、起動時に完全同期を実行させることを推奨します。ある顧客事例では、古い外部 JVM を使用していたため Pattern が更新されませんでした。Agent ログには明確なエラーはありませんでした。wrapper-override.conf を編集して bundled agent/jre/bin を使用することで解決しました。添付ファイルが完全にダウンロードされない場合や破損してダウンロードされる場合は、インスタンスデータベースの問題である可能性があります。添付ファイルを手動ダウンロードして内容を確認してください。Transaction Log に SOAP Web Service へのリクエストは表示されていますか。App Node の localhost ログに関連するエラーはありませんか。 既知の制限 KB0813383 Can a JAR file be pushed to a specific MID Server instead of all MID Servers? - クイックアンサー: いいえ。これは、ドメインごとの JAR ファイルにも適用されます。KB1182832 Add or replace Java Classes in the MID Server, without using the JAR File synchronisation from the instance 関連問題 PRB1433170 / KB0862383 The jar files for Oracle/MSSQL/MySQL JDBC drivers on MID Servers are in the lib folder, not the JAR Files table, and so can't be swapped out for different versions to be compatible with all versions of those databasesPRB1441208 / KB0862614 Oracle JDBC Driver 11.2.0.3.0 included in MID Server lib folder is old, and incompatible with at least Oracle 8iKB1192296 3rd party Evanios EVAgent JAR file causes Mid Server stack crash for various threads due to log4j and slf4j classes calling each other in an infinite loopKB1646201 MID Server and Code Signing - Unable to find the signature / Cannot just-in-time load the signature record / Failed to verify signatureまた、パターンにも問題があり、新しいバージョンのパターンが古いバージョン (TBC) と同じupdated_on値になります。PRB1811227/KB1703730 Discovery Sensors and Probes do not support Code SigningPRB1770274/KB1707055 ACC Plugins (Assets) cannot be synced to MID Servers if Circle of Trust (code signing) is enabled in the instance, breaking all Agent Client Collector related features その他の記事 KB1553111 MID Server Java classes missing or incompatible after upgrading