メインコンテンツへスキップ
見出し画像

SAMの基本設定(導入後に行う設定、システムプロパティなど)


    SAMをApplication Managerから導入した直後、Software Modelsやレポートの画面を開いても中身が動き出さず、何から手を付ければいいか迷う担当者は少なくありません。決めるべき設定は実質2つに絞られます。 第一がSAM Professional(com.snc.samp)の有効化、第二がSoftware Models側でのLUM(License Under Management)設定と製品紐付けです。残りのプロパティ5件と週次照合ジョブは、既定値のまま触らなくても動きます。Australia PDIの実機で、この2つの必須設定と、確認だけでよい項目を切り分けました。

    検証環境:Australia PDI / OOTB / 2026-08-23 確認。Software Asset Management(sn_itam_samp v4.1.4)に加え、SAM Professional(com.snc.samp)を有効化した状態

    SAMとは:Software Asset Management(ソフトウェア資産管理)の略です。購入したライセンスの権利と、実際にインストールされているソフトウェアの実態を突き合わせ、過不足を計算する仕組みです。

    導入の手順はで扱いました。導入して何が増えるかの実測は、SAMの位置づけはでそれぞれ整理しています。この記事はその続きとして、導入が終わった直後に何を設定すれば照合を動かせる状態になるかだけに絞ります。

    SAM導入前は、ライセンス台帳と実態を名前でしか突き合わせられなかった

    SAMが無い環境でも、購入したライセンスの記録(alm_license)と、実際にインストールされたソフトウェアのCI(cmdb_ci_spkg)はそれぞれ存在します。買ったライセンス数と実際のインストール数をalm_license・cmdb_ci_spkgから読んだ記事では、この2つを正式に結ぶ参照フィールドが無いことが示されています。突き合わせは製品名の文字列一致に頼るしかない実態です。文字列一致には限界があります。同じ製品でも表記ゆれ(バージョン表記の有無、社名の略記など)があると、突き合わせが崩れてしまうためです。SAMが持ち込むのは、この名前頼みの突き合わせを構造化する仕組みです。権利側はSoftware Model経由でパブリッシャー・製品・バージョンに紐付き、実態側はDiscovery Modelを経て同じSoftware Modelに正規化されます。導入後の設定は、この「名前ではなく構造で結ぶ」仕組みを実際に機能させるための作業だと捉えると、何を設定すべきかが見えやすくなります。

    導入しただけでは、まだ何も計算されない理由

    SAMをStoreアプリとして導入すると、Software ModelsやEntitlementsの画面自体はすぐに開けます。しかし実際に照合(Reconciliation)を走らせても、権利と実態を突き合わせた結果は1件も出てきません。原因は2つの重なりです。1つ目は、権利と実態を突き合わせる照合エンジン本体(SAM Professional)が既定で無効になっていること。2つ目は、突き合わせの対象となるSoftware Model側で、どの製品を管理対象にするかがまだ何も指定されていないことです。この2つを設定するまで、SAMは「入っているのに動かない」状態のままになります。


    画像

    導入後に決めることは、大きく分けるとこの4点です。

    • SAM Professionalの有効化:既定はinactiveで、有効化しない限り照合の計算対象は常に0件

    • プロパティ5件の確認:Software Asset Management Propertiesという1画面に集約されている。既定値のままで動く

    • 週次照合ジョブの確認:導入直後からactive=trueのまま動いている。設定は不要

    • Software Modelsの設定:LUMをtrueにし、対象のproductを紐付ける

    このうち実際に手を動かす必要があるのは、最初と最後の2点だけです。

    SAM Professionalを有効化しない限り、照合は空振りする

    SAM ProfessionalはApplication Managerの検索窓に入力しても候補に出てこず、Storeアプリの依存としても配布されません。GlidePluginManagerで状態を確認すると、Storeアプリ導入直後はcom.snc.sams(Foundation)がtrueなのに対し、com.snc.samp(Professional)はfalseのままでした。この状態で照合を実行すると、進行ログにはNumber of licensable installs and subscriptions: 0という記録が残ります。権利のレコード自体は認識できているのに、計算対象になるインストールがゼロという状態です。さらにヘルスチェックにはinvalid table name: samp_scan_findingというエラーも記録されていました。Professional側のテーブルがまだ存在しないことを、別の角度からも確認できます。有効化の手順そのものはで実機確認済みです。 この記事では「初期設定として最初に必要な1手」という位置づけで扱います。

    プロパティ5件は、1つの設定画面に集約されている

    SAM関連のシステムプロパティは合計16件増えますが、そのうちcom.snc.samp.*系の5件だけが、Software Asset Management Propertiesという専用の設定画面にまとまっています。残りはCMDB側の正規化系プロパティ(glide.cmdb.canonical.*)などで、個別の業務画面から触る性質のものではありません。システムプロパティ(sys_properties)が設定値の置き場である仕組みを先に押さえておくと、この専用画面がなぜ特別扱いなのかが分かりやすくなります。


    画像

    画面に並ぶ5件と、公式のDescription(原文)はこうでした。


    画像

    (訳)

    • カスタムライセンスメトリックをすべて使って照合を実行する

    • Microsoftスイートで構成ライセンスが不足したとき、コンポーネントライセンスで補ってコンプライアンスを最適化する

    • 照合結果のデバッグを有効化する。デバッグを有効にするとパフォーマンスに影響がある点に注意

    • 照合を並列実行するスケジュールジョブの数を入力する

    • SuiteEngineの並列処理におけるバッチサイズを入力する

    引用元: /sys_properties_list.do?sysparm_query=nameINcom.snc.samp.recon.enablecustommetrics,com.snc.samp.use_component_licenses,com.snc.samp.debug,com.snc.samp.recon.max_workers,com.snc.samp.recon.suite.min_batch_size

    5件とも既定値のまま照合が動く設計です。 カスタムライセンスメトリックを使う設定だけ最初からYesになっています。あとの4件は「デバッグを増やす」「並列度を上げる」「バッチサイズを変える」といった、環境の規模やトラブル対応に応じて後から調整する項目です。導入直後は既定値のまま様子を見て、必要になった時点で触れば十分です。

    週次照合ジョブは、この時点ですでに動いている

    SAM関連のスケジュールジョブは9本あり、いずれも導入と同時に登録されます。


    画像

    このうち照合の本体であるSAM - Software License Reconciliationは、active=true・Weekly のまま稼働します。実行時刻は月曜02:00で、追加の操作は要りません。日次で動く整備ジョブ(Deduplicate Install Table、Set client pull schedulesなど)も含めて9本あります。このうちactive=falseなのはSAM - Apply latest content changes(On Demand用)の1本だけでした。「照合を毎週走らせる設定をする」という作業自体は発生しません。 導入前に決めるのは、有効化とSoftware Models側の紐付けだけです。実行タイミングは製品側がすでに決めています。

    ジョブが本当に動いているかは、この画面の外で確認する

    active=trueという表示は「予約されている」ことを示すだけで、「実際に1回でも走った」ことまでは保証しません。ServiceNowのスケジュールジョブが本当に動いているかをrun_countとnext_actionで見分ける記事で扱った方法がそのまま使えます。SAM関連ジョブのrun_countは今回の検証範囲では確認していませんが、初回の週次実行を待つ前に、この2項目をsysauto_scriptから確認してください。

    照合対象にするなら、Software Models側でLUMと製品を紐付ける

    Software Managementのもう1つの必須設定は、Software Models(cmdb_software_product_model)側にあります。この画面はProduct Modelクラスを継承したテーブルで、CMDBの製品モデル体系の一部として実装されています。


    画像

    Product列が空欄のままだと、そのモデルは照合の対象になりません。フィールドの公式説明(原文)はこうでした。

    product: Select the software product for the publisher
    license_under_management: License under management

    (訳:product:パブリッシャーに対応するソフトウェア製品を選択する/license_under_management:ライセンス管理対象にするかどうか)

    引用元: /sys_documentation_list.do?sysparm_query=name=cmdb_software_product_model^elementINproduct,license_under_management

    実機で紐付けを試すと、product(コンテンツ由来のサンプル製品マスタ)を設定した瞬間に変化が起きました。Publisher Result・Product Result・License Metric Resultが初めて生成されたのです。モデル名もBusiness Rule(Calculate software model name)によってpublisher・product・versionから自動で再計算され、表示名が変わります。 LUMをtrueにするだけでは足りず、productまで紐付けて初めて照合対象に入るという2段構えの設定です。

    Software Modelは、CMDBのどこに位置するテーブルか

    Software Model(cmdb_software_product_model)は、CIがcmdb_ciの102クラスのどこに入るかを実機で確認した記事で扱ったCIクラス階層とは別系統です。実際にインストールされたソフトウェアの実体はcmdb_ci_spkg側のCIとして登録され、Software Modelはその「製品としての定義」を持つ側という役割分担になります。資産(alm_asset)とCMDB(cmdb_ci)をあえて別テーブルに分けている理由を先に押さえておくと、権利・実態・製品定義という3層がなぜ別テーブルに分かれているのかが理解しやすくなります。

    ロール3種は、直接ACL件数と権限の強さが一致しない

    SAM関連のロールはsam_developer・sam_admin・sam_userの3種類で、一直線に権限を継承しています。


    画像

    3ロールの公式説明(原文)はこうでした。

    sam_developer: Grants a user the script writing capabilities on the ServiceNow platform which are comparable to the script writing privileges granted to a sys_admin. This user must be a ServiceNow trained administrator.

    (訳:ServiceNowプラットフォーム上でのスクリプト作成能力をユーザーに付与します。これはsys_adminに付与されるスクリプト作成権限に匹敵します。このユーザーはServiceNowのトレーニングを受けた管理者である必要があります)

    sam_admin: This role grants a user full access to the respective features of the Software Asset Management application including the ability to create Custom Products and Pattern Normalization Rules.

    (訳:このロールは、Software Asset Managementアプリケーションの各機能へのフルアクセスをユーザーに付与します。Custom ProductsとPattern Normalization Rulesを作成する権限も含みます)

    sam_user: This role grants a user access to the Software Asset Management application. This user would not be able to perform sam_admin functions.

    (訳:このロールは、Software Asset Managementアプリケーションへのアクセスをユーザーに付与します。このユーザーはsam_adminの機能を実行できません)

    引用元: /sys_user_role_list.do?sysparm_query=nameINsam_developer,sam_admin,sam_user

    直接ACLの件数だけを見ると、いちばん権限が強いはずのsam_developerが4件と最少でした。 参照用のsam_userはむしろ122件と最多です。sam_adminはさらにmodel_manager・contract_manager・assetを包含しています。sam_userはcmdb_read・workspace_user・report_userを別途包含する構成です。名前の強そうな順にACL件数が並ぶわけではないため、権限を配る担当者には「件数ではなく役割の説明」で伝える必要があります。

    包含している他ロールは、自分の環境でも再帰的にたどれる

    sam_adminやsam_userが他のロールを包含している事実は、sys_user_role_containsテーブルを再帰的にたどると確認できます。itilロールが実際に何を含むかをsys_user_role_containsで再帰的に数えた記事の手順を、そのまま応用できる場面です。誰がどのロールを持っているかという横のつながりは、ユーザー・グループ・ロールを中間表からたどる記事の方法で確認します。縦の包含関係(ロールが何を含むか)と横の割り当て(誰が持つか)は別のテーブルを見る必要があるという点は、SAMに限らずロール設計全般で押さえておきたい区別です。

    実機で気づいたこと

    症状・原因・回避策を3点にまとめます。

    プロパティは16件増えるのに、業務画面から触れるのは5件だけです。 残りの11件はCMDB側の正規化系プロパティ(glide.cmdb.canonical.*など)で、SAM単体の設定画面には出てきません。原因は、SAMのプロパティ増分にCMDB共通基盤側の設定が混ざっていることです。回避策は、初期設定のチェックリストにSoftware Asset Management Properties画面へ表示される5件だけを対象と明記し、残り11件は他機能と共有の設定として除外することです。

    Software Modelsは92件あるのに、Product列は導入直後は全件空欄です。 空欄は設定ミスではなく、コンテンツライブラリ由来のモデルが既定で未紐付けのまま配布される仕様が原因です。紐付けは導入作業に含まれず、運用開始前の個別設定として残されています。回避策は、初期設定のチェックリストに「Product列が空欄なのは正常な初期状態」と明記することです。1件紐付けるとBusiness Rule(Calculate software model name)がモデル名をpublisher・product・versionから自動で再計算します。少数のモデルで先に紐付けを試して表示名の変化を確認してから、対象を広げてください。

    直接ACL件数はsam_developer4件・sam_admin41件・sam_user122件の順で、権限の強さの直感と逆になります。 原因は、sam_developerの権限の大半がACLではなく、sys_admin相当のスクリプト作成権限という別の仕組みで付与されていることです。回避策は、権限を配る担当者にACL件数ではなく役割の説明(開発者権限・管理者権限・参照権限)で伝えることです。件数だけを基準にすると、sam_developerの権限を過小評価します。

    実務では何に使えるか

    ここまでの内容を、今すぐ決めることと後回しでよいことに分けます。


    画像

    今すぐ決めること

    • SAM Professional(com.snc.samp)を有効化する:しない限り照合は常に空振りします

    • Software ModelsでLUMをtrueにし、productを紐付ける:紐付けない限りそのモデルは照合対象に入りません

    確認だけでよいこと

    プロパティ5件は既定値のまま運用を始めても動作します。並列度やバッチサイズは、対象台数が多い環境で処理時間が問題になった時点で調整すれば十分です。週次照合ジョブも設定変更は不要で、稼働タイミングを把握しておくだけで足ります。

    小さく始める順番

    1. com.snc.sampを有効化する

    2. Software Asset Management Properties画面を開き、5件が既定値のままであることを確認する

    3. SAM - Software License Reconciliationがactive=trueであることを確認する(変更は不要)

    4. 対象にしたいSoftware ModelsでLUMをtrueにし、productを紐付ける

    5. ロール3種の担当者への配布方針を、直接ACL件数ではなく役割の説明で決める

    6. ここまで終えたらRun Reconciliationを実行し、結果が出ることを確認する

    権利の登録から照合1件を実際に処理する手順はで扱います。この記事で決めた設定は、あくまで「照合が動く状態にする」ところまでです。実際に権利を何件登録し、どの部署に何台配分するかという運用ルールの設計は範囲外になります。設定と運用ルールを混同すると、初期設定の担当者が運用フローまで抱え込む事態になりやすいため、最初に線引きしておくと後の作業分担が楽になります。

    用語

    • SAM Professional(com.snc.samp) … 権利と実態を突き合わせる照合エンジン本体。既定はinactive

    • LUM(License Under Management) … Software Model単位で、そのソフトウェアをライセンス管理対象にするかどうかのフラグ

    • Software Model(cmdb_software_product_model) … Product Modelクラスを継承する、照合の対象単位となるソフトウェア定義

    付録:自分の環境で確認するときのURL

    インスタンスのURLに続けて開いてください。

    • SAM関連プロパティ一覧:/sys_properties_list.do?sysparm_query=nameLIKEcom.snc.samp

    • Software Asset Management Properties画面:/samp_properties.do

    • SAMロール一覧:/sys_user_role_list.do?sysparm_query=nameINsam_developer,sam_admin,sam_user

    • Software Models一覧:/cmdb_software_product_model_list.do

    • SAM関連スケジュールジョブ一覧:/sysauto_script_list.do?sysparm_query=nameSTARTSWITHSAM

    引用元: フィールドの公式説明/sys_documentation_list.do?sysparm_query=name=cmdb_software_product_model^elementINproduct,license_under_management

    検証範囲とおことわり

    Australia PDI(OOTB+TPRM導入済み)に、Software Asset ManagementとSAM Professionalを導入した直後の状態で確認しました。プロパティ・ロール・ジョブの値はいずれもこの導入直後の初期値であり、他のアプリ導入やアップグレードを重ねた環境では異なる可能性があります。Software Modelsの紐付けはコンテンツ由来のサンプル製品を使った検証であり、実際の自社ソフトウェア資産での紐付け作業とは対象データが異なります。

    確認していない範囲は次のとおりです。

    • プロパティの並列度・バッチサイズを実際に変更した場合の処理時間への影響と、LUMをtrueからfalseへ戻した場合の照合結果への影響

    • ロール3種を実在ユーザーへ割り当てた場合のUI上の見え方の違い

    • SAM関連スケジュールジョブのrun_count(初回実行が完了しているかどうか)と、本番相当の台数・パブリッシャー数を投入した場合の並列度プロパティの実効的なチューニング値

    関連記事

     
     
    ServiceNowのPDI(Personal Developer Instance)を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ