ソフトウェアへのアクセスが拒否される13の理由

ライセンスプールが空になると、それ以上のチェックアウト要求に対応できなくなります。この問題を解決する一般的な方法は、(a) より多くのライセンスを購入する、または (b) ライセンスの使用を最適化する、の2つです。

新しいライセンスを購入することは、古典的なアプローチです。しかし、ますます厳しくなるビジネス環境では、すべての経費にビジネス上の価値と見返りがなければならない競争力が求められています。現在では、より効果的なライセンス管理システムの鍵は、ソフトウェアの真の使用状況をより深く理解することであることが広く理解されています。この理解により、ライセンス使用量の最適化という 2 つ目のソリューションが生まれました。現在、効果的なソフトウェア資産管理には、これまで以上に、リアルタイムのモニタリングと過去の使用状況の分析が不可欠になっています。

ソリューションとして、より多くのライセンスを購入することと、ライセンス使用の最適化は、お持ちのツールとその使用方法によって、互いに補完し合うこともあれば、矛盾することもあります。

しかし、中にはライセンスが「漏れている」ライセンスサーバーが確認されたこともありました。つまり、実際には利用可能なライセンスがすべてチェックアウトされていないにもかかわらず、ユーザーにライセンス不足が通知されたのです。このような場合、サービスを再起動することで一時的に問題が解決することがあります。

80 年代初頭、ソフトウェアライセンスは圧倒的にノードロック方式でした。ソフトウェア業界がしなやかなライセンシングシステムと管理の必要性に気付いたのは、最初のソフトウェアライセンスサーバーが商標登録された1989年になってからでした。今日、フローティングライセンスとその主要な技術的要件であるライセンスサーバーシステムは、公共および民間組織の両方で増大するソフトウェアニーズに対応するための既定の手段となっています。

それから約30年経った今でも、これらのシステムは完璧とは言い難いです。サーバー上の問題はそれほど頻繁ではありませんが、「サーバーシステムから返された無効なデータ」や「ライセンスサーバーシステムに接続できない」といった拒否は、今でもユーザーにとって一般的なものです。これらの問題は、ライセンス サーバーとクライアント間のデータ通信システムの障害であることを念頭に置いてください。

最初の問題は、クライアントが古くなったプログラムやシステム構成で動作している場合や、ファイアウォール、セキュリティ制限、その他のアンチウイルスプログラムなど、ライセンスサーバーとクライアントマシンの間にサードパーティによるブロックがある場合に現れます。
(a) クライアントを新しいバージョンにアップグレードする、
(b) 問題のあるソフトウェア をアンインストールしてからマシンを再起動する、
(c) 修正プログラムやパッチを検索してダウンロードする、などが手っ取り早い解決策です。

2つ目の問題は、通常、ライセンスサーバーがオフラインまたは未起動である場合、ライセンスファイルとサーバーのMACアドレスが不一致である場合、サードパーティ製ソフトウェアが原因でライセンスマネージャが誤って設定されている場合に発生します。まず、サーバーがオンラインかオフラインかを確認します。lmutil lmstat -aをサーバー上で実行し 、成功すれば、サーバーはアクティブです。もしそうでなければ、サーバーのlmutilの出力にリストされているポートがクライアントのものと一致しているかどうかを確認します。サードパーティの問題については、ファイアウォールを閉じるか、問題のあるソフトウェアをアンインストールしてからマシンを再起動してください。 ファイアウォールを介してサーバーベースのライセンスを設定する方法 として、これらの方法も役に立ちそうです。

その他にも、様々な環境でライセンスサーバーの問題が発生しています。企業にとって、自社のソフトウェア資産に最適なライセンスサーバーモデルをテーラーメイドする ことが重要です。

従来、ソフトウェア業界では、あらゆるビジネス上の理由から、顧客にアドオンを押し付けることが幸せな時代でした。ソフトウェア市場の成長に支えられたライセンスモデルの進化により、機能やアップグレードがオプションとなる、より合理的なセットアップが可能になりました。それでも、アップデートがソフトウェアを生かすという事実を無視することはできません。企業は、技術革新のペースに追いつくために、アップデートを購入する必要があります。アップデートから次のアップデートへの移行プロセスでは、製品ベンダーとその顧客、そしてその間にあるすべての関係する資産に絶え間ない調整が課されます。このため、機能アップデートは、技術的なバグに起因する金銭的な負担の原因としてよく知られています（サポートされていない機能や機能のサポートされていないバージョンによる拒否）。

サポートされていない機能の場合、ツールはライセンス サーバに正常に接続されますが、これらのサーバはクライアントが使用しようとしている機能をホストすることができません。複数のライセンスサーバーに接続しているクライアントでも、この問題が発生することがあります。プロフェッショナル版またはアップグレード版のライセンスにのみ提供される独占的な機能に、標準ライセンスでアクセスできない。これは、ライセンスをアップグレードすることで解決します。また、クライアントが検索パスで間違ったサーバーを指定している可能性もあります。この問題を解決するには、接続を実行する前に、パスを確認し、ライセンスの構文を一致させてください。また、検索パスは複数のライセンスソースを指定するために使用することができることに注意してください。詳細については、このリンクが役に立ちます。

機能のサポートされていないバージョンの場合、ツールは、クライアントが要求した機能をホストするライセンス サーバーに正常に接続しますが、正しいバージョンではありません。通常、これは、ユーザが現在のツールで古いライセンスにアクセスしようとしていることを意味します。これに関連する理由として、使用されている製品のリリース日が、ライセンス ファイルに記載されているメンテナンス日より先である場合があります。ユーザーは、チェックアウトの状態に関係なく、ライセンスサーバーのログにこのメッセージを見ることができます。チェックアウトが正常に行われた場合は、このポップアップを無視してもかまいません。そうでない場合は、メンテナンスを適用する必要があります。ライセンスキーの生成または再生の方法については、こちらのステップバイステップをお試しください。

"Licensing for this product has stopped working."このようなエラーは、ベータ版やプレリリース版のプログラムで、試用期間に記載されている最大時間まで動作している場合に多く発生します。これは、指定された機能の有効期限が切れたことを意味する場合もあります。ライセンスファイルに含まれるすべての機能の有効期限が切れた場合、サーバーの起動に失敗します。

この場合の解決策としては、以下のようなものがあります。(a) ライセンスサービスのアップデートを適用する (b) ライセンスサービスのデータフォルダのパーミッションを再設定する (c) ソフトウェアを再インストールする などがあります。もちろん、本当にライセンスが失効しているのであれば、更新や再交渉が必要です。

製品もそのアップデートも、決して安いものではありません。安いものもあれば高いものもありますが、それでも1ライセンスあたり数千ドルの話です。しかも、組織がある製品から別の製品に変更するのは簡単なことではありません。習得が必要なエンジニアリングソフトウェアを使用する場合はなおさらです。エンジニア、アーキテクト、プログラマーが、市場に出回っているソフトウェアをすべて習得するとは誰も思っていません。製品を変えることが問題外である以上、企業は「本当に必要な機能は何か？」。

賢い解決策は、使用されていない機能や十分に活用されていない機能から、人気のある便利な機能やアップグレードに予算を再配分することです。これにより、ライセンス環境が整理されるだけでなく、コスト削減の機会も得られる。ライセンス環境から厳密なデータを取得するためのメカニズムを実装したツールは少ない。これらのツールでは、キーボードやマウスからの操作を含むワークステーションの動作を測定できます。さらにまれに、I/OデバイスやCPU自体の動作を測定できるツールもありますが、これは実際の使用状況を判断する上で重要なことです。

NOT INCLUDEとEXCLUDEは同じものでしょうか？どちらも、クライアントのユーザー名、ホスト名、または表示名のいずれかが、製品へのアクセスを制限されていることを示すと考えれば、そうです。また、どちらも使用中のライセンスソフトウェアで設定可能です。しかし、オプションファイルのEXCLUDE行は、クライアントが製品にアクセスできないことを意味し、ログファイルのNOT INCLUDED構文は、優先ユーザーまたはグループの予約が行われたことを意味するという違いがある。これにより、グループ外のクライアントが製品にアクセスすることが制限されます。

管理者は、プロジェクト、ロケーション、優先度の高いユーザーなどに基づいてライセンス許可を設定することができます。この機能により、優先度の高いユーザーが拒否されることはなく、逆にグループ外のユーザーが拒否されることもありません。

そこで、この拒否を解決するために、ライセンス管理者に連絡することを検討してください。この場合、なぜそのユーザーにとってそのソフトウェアへのアクセスが必要なのか、おそらく説明が必要でしょう。

この観点から、この設定がユーザーの行動に良くも悪くも直接影響を与えることは明らかで、前者が望ましいと言えます。今や、ピープル分析は、経営、リーダーシップ、人事で行われるほぼすべてのことの中心的存在になっています。設計されたすべてのプログラム、展開されたすべてのインセンティブ、そして直面するすべての構造的変化や組織の課題は、データによってもたらされるべきものです。このような背景から、SAMツールは、ライセンス独占やライセンスキャンプなどのユーザーの習慣を検出するメカニズムを改良してきました。まず第一に、ソフトウェア資産管理は複雑に思えるかもしれないが、専門家はソフトウェア資産管理を通じて生産性を向上させる方法について、すでに革新的な輝かしい解決策を考案している。

より専門的な話になりますが、使用中のライセンス サーバがオプション ファイルを使用して起動するかどうかを確認することもできます。オプションファイルへのパスは、ライセンスファイルのVENDORまたはDAEMON行の4番目のフィールドとして、次のように表示されます：
- VENDOR ibmratl /path_to_ibmaratl_daemon /any_paty/any_name.opt.

VENDORまたはDAEMON行でパスを省略すると、ベンダー デーモンはライセンス ファイルと同じディレクトリにある vendor.opt という名前のファイルを自動的にスキャンします。
(a) オプションファイルを適切に更新し、ライセンスサーバーのlmgrdを停止して再起動する。
(b) lmrereadユーティリティを実行して、VENDORデーモンにオプションファイルを再読させる。

構文は以下のいずれかを含むことができます。EXCLUDE、EXCLUDEALL、EXCLUDE_BORROW、INCLUDE、INCLUDEALL、INCLUDE_BORROW、MAX、およびRESERVE。制限の対象は、USER、HOST、DISPLAY、INTERNET、PROJECTのいずれかです。

この理由による拒否は、一般に、システムの日付、時刻、ゾーン（TZ）の設定が正しくない可能性があることを意味します。また、システムの現在の時刻よりも新しい作成日を持つシステムファイルが原因である可能性もあります。または、タイムゾーン変数が、それをサポートするプラットフォーム上で間違って設定されている可能性があります。明確には、ライセンスマネージャは異なるタイムゾーンに対応するように設定されています。ただし、ライセンス サーバとマシンの間のオフセット時間は、4 時間が許容される最大時間であることに留意する必要があります。

この拒否理由には、サーバーとクライアントの両方のワークステーションが関与しているため、どちらか一方または両方で調整が必要になる可能性があります。サーバーとクライアントはグリニッジ標準時に同期している必要があります。異なるOSのクライアント間では、複雑な問題が発生する可能性があります。サーバーとワークステーションの間で時間を同期させる方法については、こちらの議論をお試しください。こちらも参考になるかもしれません。

このメッセージは、ほぼ全員がすぐに理解できる。過去60年間で、コンピュータの販売台数は、1960年に2千台、1980年に90万台、1990年に700万台、2003年には1500万台以上、2017年には四半期あたり6200万台以上と増加しています。このような生産と出荷が続くと、コンピューターも他の機械と同様に、定期的な設定、修理、メンテナンス、陳腐化や破損、そして最終的には買い替えを余儀なくされることは自明です。実際、コンピュータの基本価格は総所有コスト(TCO)の20%未満であることが調査で明らかになっています。ハードウェア、ソフトウェア、適切なライセンスの正確なインベントリーを構築し、維持することは、技術コストを削減するための重要なステップとなります。

この問題を解決する一つの方法は、ハードウェアの支出やその他に関する欠陥やオーバーキルを報告するようなプロアクティブツールを使用することであります。これらのプログラムは、特にITAMの一環として、ハードウェア資産の監視とインベントリ作成のために開発されたものです。東洋の国々は、西洋の国々に比べてより大きな用途を見出していますが、それらが利用可能であることを知っておくことは良いことです。これらのツールは、ハードウェアのコストを効果的に削減する上で好評を博しています。

では、この問題を解決するための技術的な方法をご紹介します。まず、すべてのマシンがアクティブで動作していることを確認します。稼動している場合は、フローティングライセンスのクライアントマシンの設定を確認します。また、クライアントマシンの設定や接続に問題がある場合もありますので、そちらも確認してください。また、ファイアーウォールの問題が関係している場合もあります。このエラーは、複数のライセンスシステム上で動作するライセンスサーバーでも発生することが知られています。この問題を解決するには、ライセンス ファイルの SERVER 行の最後にあるポート番号を指定します。

このエラーでは、ツールはライセンスサーバーに問い合わせることができますが、ベンダーデーモンは応答しません。これは、アプリケーションデーモンがクラッシュしたことだけを意味します。この場合、すでにアクティブなプロセスで競合が発生するため、プログラムが断続的に機能することがあります。クライアントマシンがライセンスサーバーを参照するのに、IPアドレスではなくホスト名を使用している場合、その名前に対応するIPアドレスで接続に失敗している可能性があります。

(a) サーバマシンでライセンスマネージャが動作しているか、また起動中のソフトウェア に対して適切なライセンスが提供されているかを確認します。
(b) クライアントマシンが適切な設定で動作しているかを確認します。
(c) ファイアウォール設定を確認します。
(d)ゲストIDを確認します。
(e) 必要に応じてクライアントプロセスを構成してください。

ライセンスサーバーとベンダーデーモンのTCPポートをライセンスサーバーのマシンから変更することで問題が解決する場合もあります。ここに記載されているいくつかの解決策については、対応するリンクに詳細が記載されています。

が初期化できません：ライセンス ファイルに SERVER 行がありません。.この問題は、一般的にライセンス形式が破損していることが原因で発生します。具体的には、ライセンス ファイルが編集されているか、誤って削除されているため、サーバー行がありません。license.dat ファイルをチェックして、USE_SERVER 行が空か不完全であるかどうかを確認します。ライセンスファイル内のホスト名が欠落している可能性があります。その場合は、オンラインの可能性のあるソースからオリジナルのライセンスファイルを再ダウンロードしてください。

また、サーバーラインを持たないノードロックされたライセンスが原因で拒否されることもあります。この問題を解決するには、ライセンスマネージャを停止します。この例では、ライセンスマネージャを起動または停止する方法を示しています。最後に、ライセンスマネージャを必要としないため、サーバーラインを持たないライセンス（ラップトップライセンスなど）もあります。ノードロックされているライセンスを除いて、もうひとつ考えられる理由は、ライセンスマネージャが動作していることです。

ライセンスサーバーマネージャーのスタートアップに失敗しました。CreateProcessエラーです。ここでは、ライセンスマネージャが起動し、ライセンスを解析しています。ベンダー デーモンを起動しようとしましたが、実行ファイルの場所がわかりません。このエラーが発生するということは、ライセンス ファイルのパスが間違っていて、バイナリが自分のディレクトリに見つけることができなかったことを意味します。この問題を解決するには、ライセンスファイルlicense.datを編集し、DAEMON行を更新してバイナリの正しいパスを指定します。例えば、DAEMON MLM "C:ʻProgram FilesʼMATLABʼR2010bʼetc\win32ʼmlm.exe "のようにします。変更を適用するには、ライセンスマネージャを再起動してください。ライセンスマネージャーの問題を解決するためのその他のアイデアはこちらです。

これは通常、複数のライセンスサーバーと異なるアプリケーションを同じマシンから実行している場合に発生します。同じライセンスファイルを異なるサーバーで使用することはできません。また、lmgrdが無意識に閉じられた場合、プログラムが実行され続ける可能性があります。

この問題を解決するには、ライセンスファイルをマージして、単一のインスタンスのサーバーソフトウェア からホストしてください。さらに、製品のインスタンスが酷使されていないか確認し、それらを終了させます。これは、Windowsのタスクマネージャで行うことができます。

これは、ライセンスファイルのSERVER行にあるポートが使用されていることを意味し、通常はlmgrdプロセスが既に実行されているときに発生します。他のアプリケーションがそのポートを使用しているために、サーバーの実行には成功しても、実行の継続やアクティブな状態の維持に失敗することもあります。また、設定上の問題（特にホスト名）がこの問題の原因となっている場合もあります。また、OSの設定によってポートがブロックされている場合もありますが、これはLinuxクライアントでよく見られる現象です。最後に、ライセンスマネージャがクラッシュした場合、OSがポートを保持している可能性があります。これは、ライセンスサーバーがシャットダウンした後、すぐに再起動した場合です。

解決方法としては、まず、ライセンスファイルを見て、そのポート番号が他のプロセスで使用されていないかどうかを確認します。netstat - anpコマンドを実行して確認してください。何か出力があれば、ポートの競合があることを示しています。ホスト名を修正するには、/etc/hosts にホスト名が記載されているかどうかを確認します。以下は、ホスト名の構文の例です。

myserver.oldcompany.comがホスト名です。ファイルに127.0.0.1や::1がない場合も同様のエラーが発生します。Linuxでの設定ミスの場合は、SELinuxがdisabledかpermissiveかをcat /etc/sysconfig/selinuxで確認してください。SELINUX status: を permissive -SELINUX=permissive に設定してください。その他、ステータスが表示されない場合は、root でログインした状態で sestatus-v を実行してみてください。最後に、クラッシュしたライセンスポートやまだロード中のライセンスポートについては、再起動する前に、シャットダウンした時点から少なくとも1分は待ってください。これにより、OSがライセンスポートの構成を認識し、利用できるようになるまでの時間が確保されます。

この場合、サーバーのホスト名やMACアドレスが正しくないと、ライセンスファイルも正しく生成されないことを知っておく必要があります。さらに、ライセンスファイル、サーバーのホスト名、MACアドレスを含むライセンスインクリメント間の不整合も、認証の競合を引き起こす可能性があります。ライセンスファイルが編集されている可能性もあります。編集できるのはライセンスファイルの一部のセクションだけであり、それ以外のセクションを変更すると、何らかのエラーが発生することを覚えておいてください。

基本的な解決策としては、ライセンスファイルに記載されているサーバー情報が、LMTOOLSのシステム設定タブに記載されている情報と一致しているかどうかを確認することです。また、ライセンスを再ホストすることも効果的です。このクイック ガイドでは、ライセンスを再ホストするための基本的な手順を説明します。ライセンスファイルが間違って編集されている場合は、オンラインソースからライセンスファイルを再ダウンロードしてみてください。オートデスクなどの一部の製品では、以前のライセンス ファイルを無効にすることなく手動でライセンス ファイルを編集できない場合があります。このような製品の場合、新しいライセンスファイルを入手するためには、ベンダーにリクエストを提出する必要があるかもしれません。

残念ながら、このエラーメッセージはあまり参考になりません。これは通常、サーバーがノードロックされたライセンスを渡した場合に発生します。前述のとおり、この構成はサポートされていません。このエラーは、クライアントがライセンスを使用しようとしたときにのみ検出され、ライセンスが解析されたときには検出されません。

サーバまたはクライアントでlmutil lmstat -aを実行して、このことを確認します。サーバ上にノードロック ライセンスが存在する場合、lmstat の出力には以下のような行が 1 つ以上含まれます。