サブスクリプション（Subs）ライセンスがリリースされたが…
現時点ではSubsライセンスは、既存のライセンス期間が残っている場合には移行できない縛りがあります。
この記事はライセンス期間が残っているオーガナイゼーションをSubsライセンスへ移行する計画を立てる際のモデルケースと方法について説明をさせていただきます。
この記事で紹介するモデルケースは移行例であり、このモデルケースを参考にお客様側の実情に沿った移行計画を策定いただくことを期待して作成しております。
なお、Subsライセンスに関する概要は下記のコミュニティ記事でまとめられておりますので、下記のコミュニティ記事をご参考にください。
サブスクリプション（Subs）ライセンスに移行するための条件
移行前がPDLライセンス、Co-termライセンスに関わらず、ライセンスが全て切れている状態で移行する必要があります。
Co-termライセンス形態の場合
Co-termライセンス形態であれば、オーガナイゼーションライセンスの有効期限が切れ、30日間のライセンス猶予期間に突入した段階で移行を行うことでSubsライセンス形態へ移行できます。
PDLライセンス形態の場合
PDLライセンス形態では、Co-termライセンス形態のように同時にライセンスが切れる状況を作り出すことは容易ではありません。
このガイド上では移行計画の一例を以下の項目で説明します。
PDLライセンス形態からサブスクリプション（Subs）形態への移行計画
PDLライセンスの有効期限が切れたデバイスから順次移行していく手法を取り、おおよそ数年をかけて移行を行う想定です。
これには事前準備が必要であり、設定変更が必要な場合があります。
なお、これはあくまでも参考であり、Meraki ユーザのネットワーク構成に沿った移行計画を作成していただくことを推奨いたします。
移行作業は大きく分けて4つのステップです。
1.Co-termライセンス形態のオーガナイゼーションを新規作成
移行先となるSubsライセンス形態のオーガナイゼーションの受け皿を作ります。
MSPポータルがダッシュボード上に表示されている場合には、MSPポータルから新しいオーガナイゼーションを作成ください、
MSPポータルの表示がない場合には、ダッシュボードログイン画面から「Create an account」をクリックし、既存のユーザIDを入力することで新規にオーガナイゼーションを作成できます。
2.新規オーガナイゼーションで、ネットワークを作成し既存のオーガナイゼーションと同じネットワーク設定を行う
手動での構成となりますが、APIを使用することで既存のオーガナイゼーションのネットワークの構成を引き抜き、新規オーガナイゼーションのネットワークに適応することができます。
Meraki Developer HubのSearch ツールにAIが実装されており、このAIに対してスクリプトの例を要求することで参考スクリプトを得ることができます。
Introduction - Meraki Dashboard API v1 - Cisco Meraki Developer Hub
※MerakiサポートではAPIのスクリプトに関するお問い合わせを受け付けていない状況であります。
APIのスクリプトおよび開発に関連するお問い合わせについては下記のMerakiのAPIコミュニティよりお問い合わせください。
グローバルのAPIチームから直接の回答が期待されますので、ご活用をいただけますと幸いでございます。
Developers & APIs - The Meraki Community
MerakiダッシュボードAPIの導入については下記のドキュメントをご参考にください。
Cisco Meraki Dashboard API - Cisco Meraki Documentation
3.PDLライセンス形態のオーガナイゼーションで有効期限が切れたデバイスを新規オーガナイゼーションへデバイス移動
有効期限が切れたデバイスのみを新規オーガナイゼーションへデバイス移動します。
PDLオーガナイゼーションから
ネットワークから削除されたデバイスが再度利用可能に なるまでに、システムが同期するのに最大 60 分かかる場合があります。
4.Subsライセンスを購入し、手順1で作成したオーガナイゼーションをSubs形態に移行させる
購入するSubライセンスのSKUは、PDLライセンス形態のオーガナイゼーションから移動してきたデバイス数量分でご購入をください。
下記のドキュメントのマニュアルに沿ってダッシュボード上の操作を行い、Co-termからSubsにライセンス形態を変更します。
Subscription - Licensing Claim Cloud - Cisco Meraki Documentation
以上で初回の移行作業は完了します。
これ以降では、PDLライセンス形態のオーガナイゼーションのデバイスの有効期限が切れるたびに、Subsライセンス形態のオーガナイゼーションに移動させ、必要となるSubsライセンスを新たに契約するか、既存のSubsライセンスを拡張するかを、選択的にライセンスを追加いただきます。
初回作業以降のデバイス移行作業は上記の繰り返しとなります。
Subsライセンスでは柔軟にライセンス数量を拡張・縮小することができ、利用する端末に合わせて必要な分量だけの課金となります。
PDLやCo-termの携帯に比べて無駄なライセンス消費が減るため他、ライセンス更新作業がなくなるため、より経済的かつ簡単にライセンス管理をいただくことが可能です。
移行時の構成上の注意点
・MXのMeraki Auto VPN
Meraki Auto VPNは同じオーガナイゼーション同士でのみ構成が可能となるため、オーガナイゼーションを跨ぐMeraki MX同士のサイト間VPNにはIPsecを使用したNon-Meraki VPNを使用する必要があります。
Site-to-Site VPN Settings - Cisco Meraki Documentation
・MRのAir Marshal
同じサブネットが異なるダッシュボードネットワークで使用されている場合、MR同士でAirMarshalの封じ込めを行ってしまいますので、ダッシュボードボードネットワークを跨ぐ場合にはAirMarshalのSSIDをSSID Allow listに追加いただくか、ダッシュボードネットワークごとにサブネットを分ける必要があります。
Air marshal 構成時の注意点について - The Meraki Community
・グループポリシーを利用したアクセス制御
グループポリシーを利用したMacアドレス制御の場合、クライアント情報は移行されないため、制御ができなくなるため、
認証方式やアクセス制御方法を変更することを検討する必要があります。
Using a Sign-on Splash Page to Restrict Wireless Access by MAC address - Cisco Meraki Documentation
EntraIDを使用し、サードパーティでユーザアイデンティティを管理することでオーガナイゼーションを跨いでユーザの管理を行うことができます。
アーリーアクセスではありますが新しいソリューションであるアクセスマネージャーをご検討ください。
※記事作成時点では試用版の機能であるため、利用できるオーガナイゼーションが限られております
Access Manager - Architecture And Example Use Cases - Cisco Meraki Documentation
