サブスクリプション（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  ... View more

Air Marshalの機能概要と利点 無線のセキュリティ機能、Air Marshal は不正アクセス ポイントからMerakiのネットワーク保護します。 この機能概要については下記のMeraki ブログで詳細な説明とともに紹介されています。   不正アクセス ポイント | Meraki ブログ https://meraki.cisco.com/blog/2017/09/rogue-access-point/   不正な AP を識別するために、すべてのMRは専用の「リスニング」無線を利用して RF を継続的に監視します。 このリスニング無線はMRに実装されているユーザ通信向けのアンテナではなくモニター専用のアンテナを持つモデルで実装されています。 ※MR20等のモデルはモニター専用のアンテナが実装されていません   不正なSSIDの定義 不正アクセス ポイントをMerakiネットワークのMRと同じLAN 上に存在すると認識され、そのAPが ブロードキャストしているSSID を不正なSSIDとして定義しています。   封じ込めの動作 Air Marshal は「コンテインメント」と呼ばれる技術を使用します。 Meraki AP に不正な SSID が含まれている場合、次の 3 つのフレーム タイプが使用されます。   ブロードキャスト 802.11 認証解除フレーム： AP が不正な AP になりすまし、不正なAPに接続された Meraki AP の範囲内にあるすべてのクライアントに BSSID から切断するように指示します ターゲットを絞った 802.11 認証解除フレーム： この場合もAP が不正な AP になりすまし、 Meraki AP は不正な SSID の BSSID の MAC を偽装し、それに関連付けられているクライアントの MAC アドレスに 802.11 認証解除を送信します。 相互にターゲットを絞った 802.11 認証解除および関連付け解除フレーム： Meraki AP が不正な SSID に接続されていたすべてのクライアントの MAC アドレスを偽装し、各クライアントの認証解除フレームを不正なアクセス ポイントの BSSID に送信することが含まれます。 つまり、MRは不正なSSIDに接続したクライアントと、不正なSSIDをブロードキャストするAPの双方になりすましてDeauthenticationパケットを送信し接続後間も無く切断をさせます。   実際にMeraki MRの封じ込めをされた際のユーザエクスペンスとしては、 無線SSIDを選択し接続→接続成功→直後に切断 となり、何度接続してもこれを繰り返すことになります。 自動再接続が有効な場合は延々とこれを繰り返します。     Air Marshalの検知対象と除外対象 検知対象は不正なSSIDであり、定義は上記で記載されている通りです。 他ベンダーのAPが同一LAN上に存在した場合には、不正なSSIDとして検知されることが期待されます。   MerakiMRは同じネットワーク内のMRは検知しませんが、同じオーガナイゼーション内の別ネットワークのMRを不正なSSIDとして検知し封じ込めをしてしまう場合があります。 ※ダッシュボード上ではこの検知結果が表示されません   下記の図のように同じサブネットで、異なるMerakiダッシュボードネットワークで管理している場合が該当します。 MRは同じネットワーク内のMRのMACアドレス情報をAir Marshalの検知範囲から除外するホワイトリストとして保持していますが、 他のダッシュボードネットワークのMRについては保持していません。   これにより、同じサブネットで管理されている別のダッシュボードネットワークのMRが不正なSSIDの定義に一致するため、これを封じ込めてしまうという状態に陥ります。 ※繰り返しますが、ダッシュボード上ではこの検知結果が表示されません     MR1とMR2はMR3を不正なSSIDとして検知し、MR3はMR1とMR2を不正なSSIDとして検知し、互いに封じ込めを行なってしまいます。     Meraki MR同士で封じ込め事象の回避策 上記のため、同じサブネットが異なるダッシュボードネットワークで使用されている場合、MR同士でAirMarshalの封じ込めを行ってしまいますので、ダッシュボードボードネットワークを跨ぐ場合にはAirMarshalのSSIDをSSID Allow listに追加いただくか、 ダッシュボードネットワークごとにサブネットを分ける必要があります。   ファームウェア管理のベストプラクティス  同一サブネットの一部のMRのみファームウェアの検証エリアを設ける場合があります。 これはファームウェア管理のベストプラクティスで紹介されているファームウェア検証のモデルケースであります。   この場合、同じサブネット内のゲストエリアのMRを検証エリア用のネットワークとして設けてファームウェア検証を行うケースがありますが、この状態でAirMarshalを有効にしますと、上記のため社内エリア用のMRとゲストエリア用のMRが封じ込めし合うことになります。 ゲストエリア用にゲストサブネットを設けていただくなど、上記の回避策を講じていただく必要があります。   「DIRECT-（文字列）」という名前が付いたSSIDが大量に表示されることがある Windowsなどでは近距離共有機能に無線を使用する場合があります。 「DIRECT-（文字列）」という名前が付いたSSIDでブロードキャストされることがあります。   該当のWindowsPCが有線LAN/無線LANに接続している状態でこのSSIDをブロードキャストすると、不正なSSIDの定義に一致するためにAirMarshalによって検知されることがあります。   このSSIDはWindowsのワイヤレス サブディスプレイ機能が有効な場合に、 プロジェクション用に「Microsoft Wi-Fi Direct Virtual Adapter」がWindowsに追加されることでこのSSIDが送信されるようです。 PC の「Windows の設定」を開き、システム＞この PC へのプロジェクション ページから「常にオフ」に設定することで無効にすることができます。 参考URLリンク 不正アクセス ポイント | Meraki ブログ https://meraki.cisco.com/blog/2017/09/rogue-access-point/ エアマーシャル - Cisco Meraki ドキュメント https://documentation.meraki.com/MR/Monitoring_and_Reporting/Air_Marshal   ... View more

現地対応者向けMX交換マニュアル 現地対応者の方向けに詳細な手順について以下に説明させていただきます。 こちらの手順については参考であり、環境ごとに適切な手順書をご用意いただくことを推奨します。   なお、このマニュアルでは同じモデルでの交換を想定しております。 別モデルでの交換の場合、ポートアサインが異なるため、交換の前後で接続ポートを変わることが想定されます。 MX Cold Swap - Replacing an Existing MX with a Different MX - Cisco Meraki Documentation https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX MXは、プライマリ MX が事前に構成されたオンラインのセカンダリ MX にスムーズにフェイルオーバーする ウォームスペア を設定できますが、これは事前にセカンダリをスペアに設定されていない状態でプライマリ MX が故障した場合や、ネットワークで異なるモデルの MX にアップグレードする場合、ネットワーク管理者は「コールドスワップ」を実行する必要があります。   お客様のダッシュボードに故障機(既存機)がネットワークに登録されている状況から、 必要な作業として、以下のステップに従い交換作業をください。   交換手順 1,代替機をオーガナイゼーションに登録 オーガナイゼーション＞インベントリ ページより、「申請」から新しいデバイスのシリアルナンバーを入力し、インベントリに追加します。 2,故障機のMXをネットワークから削除 まず最初に、ネットワーク上で登録されている既存機を一度削除する必要があります。 セキュリティ&アプライアンス＞アプライアンスステータス ページにて、「ネットワークからアプライアンスを削除…」をクリックし、既存のデバイスをネットワークから削除します。 これにより、ネットワーク上から不要なデバイスを取り除き、新しい機器を登録するためのスペースを確保します。 ※ネットワーク上で稼働可能なMXは1台のみであるため 3,代替機のMXをネットワークに登録 故障機が削除された後、代替機のMXをネットワークに新たに登録します。 オーガナイゼーション＞インベントリ ページより、登録したいデバイスのチェックボックスにチェックを入れ、左上の「追加…」からネットワークを選択し追加します。 これにより、代替機がネットワーク上で正しく認識され、使用可能な状態になります。 4,PPPoEを使用したIP構成の設定 ※DHCP IPアドレス取得の場合はStep 5にスキップください MXに電源ケーブルを接続し、ステータスLEDがオレンジ色になったことを確認してから、事前設定を行います。 ※この時点ではケーブルは交換しないでください お客様の既存のMXはPPPoEを使用しているため、ローカルステータスページにアクセスし、 ConfigurationタブからISP（プロバイダー）から提供されているPPPoE認証用の「ユーザー名」と「パスワード」を、設定することが必要です。 ※回線に変更がない場合には、使用する認証情報は既存のMXに設定されている内容と同じものを使用します。 電源が投入されたMXに作業用のPCを直接接続し、インターネットブラウザから http://mx.meraki.com または http://wired.meraki.com にアクセスすることでローカルステータスを開くことができます。 ※ローカルステータスページはMerakiダッシュボードではなく、Meraki機器内部に存在する構成用GUIです Configurationタブを開く際に、ログイン情報を求められます。 その際のログイン情報は、工場出荷状態である場合、ユーザ名は機器のシリアル番号、パスワードは空欄です。 ※PPPoE認証のユーザ名とパスワードと混同しないようにご注意ください ISP（プロバイダー）から提供されているPPPoE認証用の「ユーザー名」と「パスワード」を、設定しSaveすることで 交換用MXのインターネット接続の準備が完了します。 ※固定IPアドレスも同等の作業手順となり、差異としては構成内容がPPPoEから固定IPアドレスに変わるのみです。 5,設定完了後の物理的接続 設定がすべて完了したら、物理的に既存のMXから交換用MXにケーブルの差し替えをします。 既存のMXに接続されているケーブルを全て、交換機のMXに差し替えます。 この段階で、すべてのケーブル接続が正しく行われていることを確認することが重要です。 物理接続後にMXのステータスLEDが白色に点灯するまでお待ちください。 ※工場出荷状態のファームウェアからネットワーク上で構成されているファームウェアにアップグレードが自動的行われます。 ダウンロードにかかる時間がほとんどですが、完了まで10分〜15分程度かかります。 6,オンライン状態の確認 最後に、すべての設定と接続が完了した後、ダッシュボード上でMXがオンラインになっているか確認します。 オンラインになっていれば、問題なく作業が完了したことになります。 その後、業務用の通信が可能かどうかテストを行い、問題なく動作するかどうか確認をいただますと幸いでございます。   7,故障機の返送 (RMAの場合) 交換品に同梱されている手順書に沿って、同梱されている返送用伝票を使用して30日以内にご返送をください。     関連するドキュメント MXのコールドスワップでご参考にいただける写真付きマニュアルの用意がございますので、下記のドキュメントもご参考にいただけますと幸いでございます。 MX コールドスワップ - 既存の MX を別の MX に交換する方法 - Cisco Meraki Documentation https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX_jp また、ローカルステータスページのアクセス方法については下記のドキュメントにマニュアルの用意がございます。 Using the Cisco Meraki Device Local Status Page - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page ... View more

日本語窓口営業時間外でのお電話対応について   日本語サポートの電話番号 - 03-4540-4174 にお電話をいただいた際、日本語対応窓口の営業時間外、あるいは日本語対応窓口が輻輳している場合には海外の英語対応窓口に転送されます。  ※ 音声ガイダンスの後、カスタマー番号もしくはCase番号の入力が求められます。 日本語対応窓口の営業時間である平日9:00~20:00の期間であれば海外のエンジニアが日本語窓口まで転送をされることがありますが、日本語窓口の営業時間外でのお電話される場合では通訳サービスを利用することが前提となります。 このサービスを受けるには、通訳サービスが必要であるとグローバルエンジニアが判断する必要があります。 この判断材料としては、お客様からのどの言語の通訳サービスが必要なのか、お客様からの申告に依存します。 申告がない状態で日本語で説明をいただくと内容が理解できないため、海外エンジニアに伝わらず、間違い電話やイタズラと受け止められる可能性があります。   お電話をされた際に明確に英語でどの言語の通訳サービスが必要なのか、ご申告いただく必要があります。 ※英語圏のグローバルエンジニアは日本語、中国語、韓国語など聞き分けが困難な場合があるため   恐れ入りますが、日本語窓口の営業時間外でのお電話の際には、下記の例文をご参考にグローバルエンジニアに対してご申告をください。 こちらのページや、下記の内容に相応する文言を事前にご用意いただくことを推奨いたします。 「Japanese Translator Please」 「Please Japanese interpreter」 「あのー」「えーっと」「すみません」等の日本語を発するのを避け、「Japanese Translator Please」を数回お伝え頂き、保留になるまで無言でお待ち頂く事をお勧めします。 Cisco Meraki テクニカルサポート - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Support/cisco_meraki_support_jp#.E9.80.9A.E8.A8.B3.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9 ... View more

サブスクリプションライセンスとは サブスクリプションライセンスをご検討される方向けに構成しております。 この記事ではサブスクリプションライセンスの概要とメリットとデメリットを中心に、サブスクリプションライセンスの仕様についてまとめます。   サブスクリプションライセンスの概要 サブスクリプションライセンスは、ご契約いただいたサブスクリプションごとに異なる有効期限の設定が可能です。 ネットワーク単位で各サブスクリプションへ紐付けを行うため、従来のライセンスモデルよりも柔軟かつシンプルに管理を行うことができます。 ライセンス期間は12ヶ月以上から受付を行なっており、上限120ヶ月まで"1ヶ月単位"で拡張することができます。 従来のライセンスモデルでは実現が困難だった、ライセンス期間を柔軟に設定いただけます。   メリット   ネットワーク単位でのライセンスエディションの変更が可能！ 同一のOrganizationで、複数のライセンスエディションを混在させることが可能になりました。 その上で、ネットワーク単位で個々のプロダクトファミリー毎にライセンスエディションを割り当てることができるため、 複数拠点を展開する中で、セキュリティーを重視したい拠点とそうでない拠点でエディションを使い分けることができます。 ただし、同一ネットワーク内でのプロダクトファミリー内でエディションの混在はできません。 ※プロダクトファミリー：MX、MS、MRなどのモデルカテゴリを指します     ライセンス期間中のライセンスの追加、ライセンスエディションのアップグレード、有効期限の延長が可能！ ライセンスの終了日はそのままにライセンス数を追加、ライセンスのエディションのアップグレードが可能になりました。 すでに割り当て済みの他のサブスクリプションライセンスへの影響なしで、サブスクリプションライセンスの延長更新が可能です。 いままでのライセンスモデルでは予算や会計、ご契約パートナーなどの都合により、複雑化していたライセンス管理枠がネットワークの増強に合わせて柔軟に対応できるようになりました。   ネットワーク内のプロダクトファミリーごとにエディションを変更することができます。   ・ライセンスの型番が75％削減されシンプル化！ 以前まではMRのみライセンスの使い回しが可能でしたが、サブスクリプションでは同一のライセンスレンジ内のプロダクトであれば、MRと同様にライセンスの付け替えが可能となりました。   プロダクトファミリーのMeraki-SUBライセンスの一覧は下記の通りです。 記事作成時点での内容であるため変更される場合があります。詳細なモデルレンジは下記の公式ドキュメントをご確認ください。 Top SKU: MERAKI-SUB   どのライセンスが、どのモデルを包括しているのかについては下記のドキュメントの「Subscription Licensing SKUs」にそれぞれのライセンスのモデルレンジが記載されておりますのでご参考にください。 Subscription - Licensing Overview - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Licensing/Subscription_-_Licensing_Overview#Subscription_Licensing_SKUs   ・ライセンスが切れた場合もネットワークは停止せず、デバイスのモニタ機能のみが制限される 従来のライセンスモデルではライセンスが切れた場合には、猶予期間を経てオーガナイゼーションはシャットダウンされ、ユーザ影響が発生しますが、サブスクリプションモデルの場合ではユーザー影響は発生しません。   ダッシュボードからのモニター機能が制限され、ダッシュボード上ではMerakiデバイスのステータスがオフラインの表示となり、トラフィック状況や設定変更など、管理機能のみが動作しなくなります。   ・信頼に基づくコンプライアンスの強化 サブスクリプション期間満了時 or ライセンス不足時のコンプライアンス問題の適用範囲は、お客様が直近で追加したネットワークやデバイスを対象に適応されます。 これにより、管理制限がかかった理由やそのトリガーが従来のライセンスモデルより可視化され、分かりやすくなります。 例えば、サブスクリプションライセンスの数量が15台に対して、ネットワークに追加されているデバイスが16台であった場合、そのプロダクトファミリー単位でOut of Complianceの管理制限を受けますが、同一のサブスクリプションでも他のプロダクトファミリーに対しては影響はありません。     サブスクリプションライセンスの一覧ページでOut of Complianceになっている場合は、対象ネットワークがコンプライアンス違反となっていることがステータスから管理できます。 Subscription - License Compliance Cloud Experience - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Licensing/Subscription_-_License_Compliance_Cloud_Experience     ・柔軟なライセンス開始日 開始日はオーダーから7日後〜最長90日後までご指定をいただけます。   ・包括力の高いライセンス Meraki ポートフォリオに存在する全製品のプロダクトファミリーを跨ぎ、異なるライセンスエディションを同じサブスクリプションに包括することが可能です。 サブスクリプションは期間とライセンスを必要とする機器の数量、およびライセンスレベルから構成されます。   注意点としては、上記例のSubAとSubBを同じネットワークに混在させることができないことです。 上記の場合、それぞれサブスクリプションごとにネットワークを分ける必要があります。   ・お支払い方法の柔軟性 お支払いは月毎、四半期毎、年毎、前払いに対応しております。 なお、各パートナー様側の販売規約によって選択可能なお支払い方法が異なる場合がありますので、適時ご確認をお願いします。     デメリット ・1つのネットワークに複数のサブスクリプションは適応不可 管理単位はネットワーク単位もとい、プロダクトファミリーごととなります。 上述の例の通り、SubAとSubBを同じネットワークに混在させることができません。   ・販売パートナーはサブスクリプションごとに固定 ご契約に紐づいてサブスクリプションライセンスは管理されるため、複数の代理店を同じサブスクリプションで包括管理することはできません。 また、サブスクリプションを分けた場合に、サブスクリプションを跨いでライセンスを移動させることはできません。     サブスクリプションの操作 下記ドキュメントに写真付きのマニュアルがございますのでご参考にください。 Subscription - Licensing Claim Cloud - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Licensing/Subscription_-_Licensing_Claim_Cloud   ライセンス更新時のダッシュボード操作 初回の登録以降は自動更新されるため、エディションの変更等がない限りダッシュボード上での操作は不要となります。     FAQ Q. 現在Co-termもしくはPDLを使っているOrganizationをサブスクリプション型に変更することは可能か？ A. Co-termもしくはPDLで有効なライセンスが残っている間にサブスクリプションを適用することはできません。 更新のタイミングでご検討をお願いします。 なお、サブスクリプションからCo-termもしくはPDLへの変更はできません。 Q. サブスクリプションを変更したい場合はどうすればよいのか？ A. サブスクリプションを販売されたパートナー様にて、CCW上でご変更をいただく形になります。(Dashboardには変更が自動反映されます) なお、サブスクリプションの変更（数量・期間・種類）は販売されたパートナー様でのみ可能です。 Q. サブスクリプションライセンスでのトライアルは可能か？ A. 現時点ではサブスクリプション型でのトライアルは対応しておりません。Co-term型での貸し出し対応となります。 Q. サブスクリプションのライセンス数量を減らす、もしくは期間を短くすることはできるか？ A. サブスクリプションの期間中におけるキャンセルや数量や期間の減少する方向での変更には原則としてできません。 また、支払いオプションの変更に関しても、支払いの間隔が長くなる方向にのみ可能で、短くなる方向にはできませんのでご注意ください。（月払い→四半期払い：OK｜四半期払い→月払い：NG） Q. 2つのサブスクリプションを1つに統合することは可能か？ A. 2025年1月現在は統合に対応しておりません。     関連するドキュメント サブスクリプションライセンスに関するドキュメント一覧は下記のリンクからご確認をください。 Licensing - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Licensing     ... View more

  Meraki Auto VPNとNon-Meraki VPNの併用について Meraki Auto VPNとNon-Meraki VPNを併用は可能です。 それらの併用は可能ですが、冗長構成を構築することは苦手な側面があります。 MXの仕様によりどのような通信が可能なのか、不可能なのか、 混乱することがありますので、代表的な例を交えてコミュニティ記事としてまとめます。   この記事での前提構成 Full Mesh構成のMeraki Auto VPNがA,B,Cの３拠点で構成されており、同時にNon-Meraki VPNでNon-Meraki VPN peer拠点と接続した構成を想定しています。また、IPv4デフォルトルートは構成していないものとします。 以下に3つのパターンに分けて動作を説明します。   パターン1 Non-Meraki Peerと接続を許可された拠点はAのみの場合。 サポートケースとしても最も多い問い合わせの一つです。許可されたA拠点はNon-Meraki Peerと通信が可能ですが、そのほかの拠点は通信ができません。 理由としては、A拠点がNon-Meraki VPN peerへのスタティックルートを他のB,C拠点に再配送しないためです。 Meraki Auto VPNは自身のLANサブネット以外のルートについては再配送しません。       パターン2 NonMeraki Peerと接続を許可された拠点は全てであり、C拠点がMeraki Auto VPNの接続を全て失った場合。 MXがHUBとして動作している場合、A,B拠点への接続を失ったとしてもそれらをトラッキングしておらず同じルートを保持し続けます。 そのため、同じルートにパケットを送信し続けることになり、仮にNon-Meraki peerがルーティング機能を持っていたとしても、それを介しての通信はできません。     パターン3 NonMeraki Peerと接続を許可された拠点は全てであり、C拠点がNon-Meraki peerとの接続を失った場合。 パターンAを踏まえると、これは不可能な通信であることが分かります。 こちらも同様にHUB拠点はNon-Meraki VPN peerへのスタティックルートを他の拠点に再配送しないため、A,B拠点を経由して通信はできません。       関連するドキュメント Meraki Auto VPN の一般的なベスト プラクティス - Cisco Meraki ドキュメント https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/Meraki_Auto_VPN_General_Best_Practices#VPN_Mesh   Site-to-Site VPN Settings - Cisco Meraki Documentation https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings ... View more

    利用できるファームウェアがMX17.x以上になります コンテンツフィルタリングは2024年の末から、MX17.x以上のファームウェアバージョンでのみ利用可能な機能となります。 なぜ、MX17.x以上に限定されるのか、またコンテンツフィルタリングとはどのような機能なのかについて下記にて簡潔に説明します。     コンテンツフィルタリングとは MX Advanced security ライセンスで利用可能になる機能です。 コンテンツ フィルタリングを使用すると、ユーザーが適時構成したポリシーに基づいて、クライアントからのHTTP および HTTPS のClient Hello packetから、特定のカテゴリのWebサイトをブロックできるようになります。   例えば、ゲームに関連するWebサイトにアクセスできないようにしたい場合には、ゲームカテゴリをポリシーに選択することで、 ゲームに関連するWebサイトの閲覧をしようとしたユーザーは、アクセスをブロックされ閲覧できなくなります。 また、カテゴリに分類されないWebサイトについても、特定のURLをブロックまたは許可リストに登録することで制御を行うことができます。     コンテンツフィルタリングの仕組み MX のコンテンツ フィルタリング機能は、Cisco Talos によって分類された Web コンテンツと脅威カテゴリに基づいて URL を分類します。 クライアントからのHTTP および HTTPS のClient Hello packetをCisco Talosに送信し、ポリシーのカテゴリリストにマッチするかどうかを照合し、クライアントに対して応答を返すという仕組みです。 HTTPとHTTPSでフローが若干異なりますが、いずれもClient Hello packetをトリガーに動作する機能であります。 また、コンテンツフィルタが動作した際のユーザー側でのブラウザの見え方が異なります。   HTTPの場合はブロックページへリダイレクトされMerakiのブロックページが表示されますが、HTTPSの場合はブロックページにリダイレクトしないため、ブラウザのデフォルトのアクセス失敗ページが表示されます。 Cisco Talos によるコンテンツ フィルタリング - Cisco Meraki ドキュメント https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering_Powered_By_Cisco_Talos HTTPでの例↓     サポートされるファームウェアバージョン MX17+ 2024年の末からBright Cloudとの連携が終了し、Cisco Talos Intelligence に一本化されます。 これに伴い、Bright Cloudとのカテゴリインテリジェンスソースを利用するMX17.xより以前のファームウェアバージョンでは、Cisco Talos intelligenceをサポートしていないため、自ずとコンテンツフィルタリング機能のサポートが終了になります。 上記のため、MX セキュリティ アプライアンスは、ファームウェア MX17.x以降で動作している必要があります。   今後は、MX のコンテンツ フィルタリング機能はCisco Talosによって分類された、Web コンテンツと脅威カテゴリのみ基づいて分類されます。      ファームウェア制限にかかった場合の挙動 コンテンツフィルタリング機能は動作しません。     ファームウェアバージョンのアップグレードの方法 ファームウェア アップグレードのスケジュールのマニュアルについては下記のドキュメントをご参照ください。 Managing Firmware Upgrades - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Managing_Firmware_Upgrades     ファームウェアEOL 最新安定版ファームウェア以外を、Vintage Firmwareの位置付けとなり、最新の安定版ファームウェア以外で仕様変更のために修正パッチが入ることはないため、コンテンツフィルタリングを利用したい場合にはMX17.x以上のファームウェアにアップデートをいただくしかない状況となります。 ただし、セキュリティに関する重大な脆弱性に関する修正対応は Vintage Firmware に対しても提供されます。 Cisco Meraki ファームウェアの EOL ポリシーに関するよくある質問 - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_EOL_Policy_FAQ_jp     製品別のファームウェア制限について レガシーMXについては、そもそもMX17.x以上のファームウェアにアップデートできないものがあります。 モデルによって実行可能な最大ファームウェアバージョンが設けられておりますので、 ご利用のMXがレガシーMXに該当しないかどうか、ご確認をください。 製品別のファームウェア制限 - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Product_Firmware_Version_Restrictions_jp     関連するドキュメント Content Filtering - Cisco Meraki Documentation https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering Content Filtering Powered By Cisco Talos - Cisco Meraki Documentation https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering_Powered_By_Cisco_Talos BrightCloud Content Filtering Deprecation FAQ - Cisco Meraki Documentation https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/BrightCloud_Content_Filtering_Deprecation_FAQ ... View more

      MXの冗長構成について MXはVRRPプロトコルを使用して高可用性（HA）ペアを構成することができます。 セットアップする方法については下記のドキュメントにマニュアルがございますのでご参照いただけますと幸いです。 こちらのコミュニティ記事では、HAペア構成時に予測される間違った構成や、その動作について説明します。   冗長構成に最低限必要なもの ・スイッチ1台 ・MXのライセンス1個 ・同じモデルのMX2台 ・LANケーブル   MXのVRRPの仕様   HA 構成の MX ペアは、VRRP アドバタイズメントを使用して、現在のアクティブ MX の状態を監視します。 動作状態では、アクティブ MX は 1 秒ごとに VRRP アドバタイズメントを すべてのVLANから送信しており、パッシブ MX が 3 秒間アドバタイズメントを受信しない場合（すべてのVLANでVRRPのハートビートを3発ロストした場合）、アクティブ MX に障害が発生したとみなし、パッシブMXは新しいアクティブ MX として引き継ぎます。     注意！構成上で抑えておかなければならないポイントについて   MX同士は直接接続してはいけません 上記のVRRPの仕様から、なぜ直接接続してはいけないのかを紐解いていきます。   簡単な構成例で説明します。 MXはすべてのVLANでVRRPのハートビートを送信しているため、例えば専用のアクセスポートかつ専用のVLANを作成して直接接続をした状態としますと、このハートビートを直接交換することになります。 一見問題ないように見受けられますが、パッシブMXがアクティブになる条件は、すべてのVLANからハートビートを受信しなくなった段階であることを考えると落とし穴があることに気が付きます。 プライマリが故障などでダウンした場合にはこの構成でも機能します。 しかし、プライマリとスイッチを繋ぐLANケーブルやポートでなんらかの障害が発生した場合、直接接続されたケーブルでVRRPのハートビートが到達しているため、セカンダリMXはパッシブを維持してしまい、いつまで経ってもフェイルオーバーしなくなります。 その間、secondaryMXはARP応答を返さないため、クライアントのゲートウェイはprimaryMXを向いたままとなります。     複数スイッチでの構成例 MXの配下に複数スイッチを設置する場合にはスパニングツリープロトコル(STP)を考慮する必要があります。 公式のドキュメントには接続ポートに関する記載はありませんが、primary MXへの接続ポートは若番を接続し、 secondary MXへの接続ポートは老番を接続する必要があります。 下記にて構成例を示します。   なぜ、接続ポートに注意しなければならないのかを下記にて説明します。   ・ベストプラクティスの構成の例 STPにより右側スイッチのポート2,3がブロッキングポートとなり、primary MXとは直接接続での通信となります。 ※Meraki としては、効率的な構成であるMXとMSは直接接続で使用いただくことを推奨としております。 この構成で障害時の動作 ・primary MXが障害によりダウンした場合 右側スイッチのport2がブロッキングポートから復旧し、secondary MXと直接接続での通信ができるようになります。 ・primary MXとの接続ケーブル、ポートが障害が発生した場合 Root bridgeのport1がダウンした場合、右側スイッチがRoot bridgeとなりport3がブロッキングポートから復旧し通信を継続できます。 右側スイッチのport1がダウンした場合でも、port3がブロッキングポートから復旧し通信を継続できます。   ・ベストプラクティスではない構成の例 MXとMSが直接接続はされていますが、そのポートはブロッキングポートとなり、右側スイッチはRoot bridgeを介してMXに到達することとなります。 同様の構成のスイッチが増えますと、その数だけ数珠繋ぎの状態となり遠回りする形で通信を行うことになります。   また、2台程度であればL2のトラフィックであるため、これによる影響は軽微であるものと存じますが、これが増えて来た場合にはRoot bridgeに無駄な負荷がかかることになります。 さらに、例にあげた構成であれば障害時の冗長こそ取れるものと存じますのが、万が一ルート ポートがセカンダリ（パッシブMX）に接続されてしまった場合にはトラフィックは転送されなくなってしまいますので、ポートアサインは、上記のベストプラクティスに準拠いただくことを推奨しております。   MXに接続できるL2スイッチの上限 2台以上のL2スイッチを接続する場合には、3台目以降のL2スイッチのブロードキャストドメインを区切る必要があるため、 実質、複数スイッチかつトランクポートでの構成はL2スイッチは2台までが限度となります。 L2スイッチを3台以上導入する環境においては、L3スイッチを間に挟みMX単体のドメインに分けるか、L2スイッチ配下に接続する構成を取る必要があります。     関連するドキュメント   MX Warm Spare - 高可用性ペア - Cisco Meraki Documentation https://documentation.meraki.com/%E6%97%A5%E6%9C%AC%E8%AA%9E/Security_and_SD-WAN/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair   MX レイヤー 2 機能 - Cisco Meraki ドキュメント https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality#Spanning_Tree_Protocol_(STP       ... View more

セーフコンフィグ「安全な設定(Safe Configuration)」について   Meraki デバイスにはセーフコンフィグ「安全な設定(Safe Configuration)」の概念があります。 ※以降セーフコンフィグと呼称 これはMeraki デバイスが安定的に接続できている、実績のあるコンフィグをMerakiデバイス内部に保存され、 以降、このセーフコンフィグがデフォルトの構成として利用されます。 こちらの記事は、Meraki ノード上に存在するセーフコンフィグについて理解を深めることを目的としております。     セーフコンフィグの概要   ダッシュボード上で変更された設定内容はダッシュボードに同期したタイミングでデバイス上にダウンロードされ、保持されるものとなります。 このとき、変更された設定をダウンロードした後、30分間再起動が行われなかった場合に対象の設定はセーフコンフィグとしてマークされ、次回再起動後にこの設定ファイルを読み込む動作となります。 ※この時点で、セーフコンフィグとランニングコンフィングは同じものとなります。 一方、変更後30分以内に再起動が発生した場合、最後に同期された設定は上記のセーフコンフィグとしてマークされないため、 次回再起動後は最後にセーフコンフィグとしてマークされた設定内容を読み込み起動するものとなります。 　 よくあるパターンとして、導入前のキッティングなどで上記のセーフコンフィグとしてマークされていない状態で、デバイス再起動やオフラインとしてしまい、設定内容がキッティング前に巻き戻ってしまうなどです。 ※セーフコンフィグが一つもない場合は工場出荷状態のものを使用します ※事例については後ほどの「よくある失敗事例」をご参考にください。 セーフコンフィグで起動した場合でも、デバイスがダッシュボードに同期したタイミングで、ダッシュボード上の最新のコンフィグがダウンロードされ、読み込まれるものとなります。 こちらについて、再起動後の同期まで10分〜1時間ほどかかる場合がございます。 お急ぎの場合、他の箇所の設定変更を行うことで最新の状態が反映される場合がございますが、 多くの場合自動的にダッシュボードの最新の状態を反映していくものとなります。     セーフコンフィグに保存されるまでの時間は？ 安定的な接続の実績としてサポートより1時間や2時間、4時間など回答に差がある場合があります。   これはモデルによってセーフコンフィグになるまでの時間が異なるほか、デバイスがダッシュボードに同期したタイミングで、ダッシュボード上の"最新の設定がデバイスに読み込まれて"から、タイマーがスタートするためです。 そしてタイマーがスタートした後で行われる、"次回"の設定の同期時にセーフコンフィグとして保存されます。   上記により、セーフコンフィグに保存されるまでに、30分以上の時間がかかることが想定されます。   そのため、確実にセーフコンフィグに保存されるように、安全をみて1時間〜4時間とサポートから案内を行う場合もあります。   公式のドキュメントには30分と記載があるが。。。 公式のドキュメントでは、下記のように記載がありますが、これは説明としては不十分な内容ではありますので、確実にセーフコンフィグとして構成したい場合には上記を参考にホールドタイムを確保いただけますと幸いでございます。 Note: 安全な構成とは 、「デバイスがクラウドに接続されており、構成変更後 30 分間再起動されていない」ことを意味します。つまり、安全な構成とは、デバイスがクラウドから受信した最後の構成であり、その後 30 分以内に再起動されていません。            新しいコンフィグが反映されない Meraki デバイスはセーフコンフィグを使用しており、構成の変更によってデバイスがオフラインになったり再起動したりした場合に、最後の正常な構成ファイルとして、セーフコンフィグに戻る動作を取ります。 ※一連の動作をコンフィグの検証とされています   この時、ダッシュボードからダウンロードした新しいコンフィグに「問題」があると判断された新しいコンフィグはバットコンフィグとみなされます。 バットコンフィグでは、ランニングコンフィグおよびセーフコンフィグになれません。 この時、ダッシュボード上の設定ステータスはOut of date (reverted to safe config) になります。     セーフコンフィグが消えることはあるの？ 工場出荷時設定にリセット（初期化）すると前述の構成ファイルがすべて削除され、プロセスが新規として開始されます。 これ以外ではセーフコンフィグが削除されることはありません。     よくある失敗事例 以下、工場出荷状態からのダッシュボードを使ったキッティングを想定 検証環境と現場環境のサブネットが違うことを想定   １、事前キッティングの際に、ダッシュボード上で構成しオンラインとせずに実装した 　→デバイスには設定はダウンロードされていないため、初期状態で起動します。   ２、事前キッティングの際に、オンラインとしたが、セーフコンフィグに保存される前にオフラインとした 　→セーフコンフィグがないため、初期状態で起動します。   ３、事前キッティングの際に、検証環境の構成でオンラインを維持しセーフコンフィグに保存、出荷前に現場環境の構成に変更しホールドタイムを設けずオフラインにした 　→セーフコンフィグには検証環境の構成となり、現場環境では検証環境の構成で起動します。   ４、事前キッティングの際に、検証環境の構成でオンラインを維持しセーフコンフィグに保存、検証環境で出荷前に現場環境の構成に変更してホールドタイムを設けてから実装した。 　→検証環境と現場環境のサブネットが異なり、Out of date (reverted to safe config) となり、セーフコンフィグとして保存されず、セーフコンフィグには検証環境の構成で起動します。     セーフコンフィグが保存されるまで待ちたくない！　[打開策] MRに固定IPアドレスを割り当てたい場合を想定   最も確実な方法としては、ローカルスタータスページに直接設定を行うことです。 ローカルステータスページの設定内容はセーフコンフィグとは別で管理されており、ローカルコンフィグとして使用されます。 Using the Cisco Meraki Device Local Status Page - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page   ゼロタッチで実装したい場合、現地環境にキッティング用のDHCPサーバーを設け、ダッシュボード上に投入したい構成を事前に設定いただくことです。 現地環境でオンラインとなり次第設定が反映され、そのまま現地環境で稼働させる方法です。 キッティング用のDHCPサーバーは以後撤去で問題はありません。   あるいは、実装環境にDHCPサーバーを実装している場合、DHCPサーバーから固定IPアドレスを払い出すことでも、ゼロタッチでの構成が可能です。   関連するドキュメント Cisco Meraki クラウドへの接続が失われたときの動作 - Cisco Meraki ドキュメント https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Behavior_during_Connection_Loss_to_Cisco_Meraki_Cloud ... View more

  はじめに 現在、PDLライセンスの仕様を誤認されていたり、Co-termに比べ管理が複雑であるためか意図した動作とならずトラブルを抱えるお客様が多く見られます。 仕様を知らずに操作を行い、ライセンスが減少したり意図しないラインセンス期間となった場合、サポートにご相談をいただいたとしても、恐縮ではございますが「ライセンス管理の問題」として対応せざるを得ない状況となります。   PDLライセンスを利用していく上での、注意事項と仕様についてご理解を深めていただくために、このコミュニティ記事にまとめました。 この記事をブックマークしていただき、PDLライセンスにおけるトラブル回避のためにご活用いただけますと幸いです。   CO-termからPDL にライセンス形態を変更したときの動作 この記事をご覧の方はすでにご承知と存じますが、ライセンス形態は一度PDLへ変更すると、 いかなる理由であってもCo-termへ戻すことはできかねます。 PDLライセンスへの移行方法について - The Meraki Community Co-termからPDL へ移行した際のライセンスの動きとしては、Co-termでのライセンス期間が、 オーガナイゼーションのネットワークに追加されているすべてのデバイスで按分されて適応されます。 ライセンスごとに按分されるわけではありません。 Co-termで100日間の残日数があった場合には、すべてのデバイスが100日間の有効期間とされます。   PDLライセンスのライセンスの消費開始日  PDLライセンス形態の場合、ライセンスの消費開始日はライセンスがCiscoからメールにて発送されてから90日経ってからです。 ライセンスをご購入されますと、Ciscoからメールにてライセンスキーの発送通知が届きます。   Co-termに比べ、ライセンス適応までの猶予はございますが、 PDL についても更新の際にはライセンスの期限を待たずにライセンスキーの通知メールが届き次第、 なるべく早くオーガナイゼーションに登録し、デバイスに適応することを推奨しております。 理由については後述いたします。     PDL ライセンス形態でのライセンス適応時の注意点 この項では、PDL ライセンス形態でご利用されている、システム管理者が把握しておくべきライセンス操作時の注意点について記載します。 PDL ライセンス形態でライセンスを登録する方法については、 下記のドキュメンにマニュアルのご用意がありますので、ご参考に願います。   ネットワークに追加したばかりのデバイスであれば、ライセンスを適応の操作を行うと、即時に適応されます。 ※過去に一度もオーガナイゼーションに登録し、ネットワークに追加したことがないデバイスに限る   しかし、すでにライセンスが適応されているデバイスに対して、Unusedライセンスを適応する場合、ライセンスは適応の操作が行われた時点から消費が始まるわけではありません。 7日間の猶予期間の後に適応されます。 この7日間はお客様が「間違ってライセンスを適応してしまった」場合の救済処置のための期間です。 下記のライセンスが消費されてしまうパターンは、すべてお客様の「ライセンス管理の問題」として取り扱われる、よくある事例です。   1、 猶予期間がない状態で適応される事例 ライセンス期間365日より少ない場合、ライセンスが切れた際に猶予期間が設けられません。 即座にライセンスが存在しない状態（None）の状態となり、この状態でライセンスを適応すると、30日間即座に減ります。 例えば、ライセンスが切れる5日前にライセンス(365days)を適応した場合、ライセンス(365days)がアクティブになるのは7日後ですので、適応から６日目だけライセンスが存在しない状態（None）となります。 上記のため、7日目にライセンスがActiveの状態になる際には、ライセンスが存在しない状態（None）ととなっているため、30日間即座に減少します。 これはライセンスの不具合ではなく仕様による動作です。   ライセンス期間365日より少ない場合とは？ デバイスを追加してからライセンスを適応するまでにタイムラグがある場合、デバイスをネットワークに追加してから猶予期間がスタートするため、10日後に適応すれば、適応したライセンスは355日分として認識され、ライセンス切れになった際に30日間の猶予期間に入らず、ライセンスが存在しない状態（None）となります。   2、 猶予期間中に適応している事例 30日間より少ない日数で減少しているものは、ライセンスが切れてからの猶予期間中に適応しているものです。 この場合、消費した期間分減少しますので、仕様による動作です。   3、 そもそも追加せずに使用していた事例 デバイスを追加後、一度もライセンスを適応せずに１ヶ月以上使い続けている状態で、 ライセンスを適応したことで、仕様により30日間減少した場合です。     覚えていただきたいのは有効期限がNoneとなっている場合にライセンスを適応すると30日間ライセンス期間が消費されることです。この消費されてしまった期間はサポートによる修正、および補填はいたしかねてしまいます。     上記の事例を回避する唯一の方法は、ライセンスの有効期限の8日以上前にライセンスを適応することですが、 この回避策でも事象が再現される場合があります。 なお、適応タイミングが有効期限が切れる1ヶ月前だったとしても、残りの日数は再計算時に有効期間に加算されます。 これによりライセンス期間を無駄なく利用できるため、早めの適応による損失はありません。     ライセンスの付け替えについて PDLライセンス形態ではライセンスの付け替えの概念があります。 また、デバイスから外されたライセンスはUnused Activeのステータスであるため、すでにライセンス適応済みのデバイスに対してこのライセンスを追加適応することはできません。 ※ライセンス適応済みのデバイスに対してライセンスを適応できるのはUnusedのステータスのライセンスのみです   ライセンスの付け替えの手順について １、オーガナイゼーション＞ライセンス情報＞デバイス のページを開き、ライセンス数の列を表示させます。   ２、ライセンス数の列にある数字をクリックすると、現在適応されているライセンスの状況が確認できます。 ３、Active licenseのポップアップのUnassignをクリックして、ライセンスをデバイスから取り外します。 ４、ライセンスタブから取り外したライセンスのActionsのプルダウンメニューからAssaign licensesをクリックします。 ５、ライセンスを割り当てる ページが表示されますので、割り当てたいデバイスのSelect of licensesのプルダウンメニューから割り当てる数量を指定し、次へを押下して表示されるサマリーで割当を押下することで適応が完了します。    その他、参考となるドキュメントやツール   デバイスごとのライセンス(PDL) - 設定・操作 - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Per-Device_Licensing_-_Configuration_jp   デバイスごとのライセンスの背後にある科学 - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Per-Device_Licensing_Overview/The_Science_behind_Per-Device_Licensing   ... View more

vMXとMXの切り分け作業の差異 vMXの場合、オンプレミスのMXに比べ、トラブル発生時の復旧に際してのご担当者さまの作業負荷が高い状況です。 トラブル発生時に、一通りのトラブルシューティングを実行しても改善がない場合にはサーバー再起動や、 vMXを再度SetUpしていただく必要があります。   具体的には、vMXに対してダッシュボードからデバイスの再起動は可能ですが、初期化はできません。 オンプレミスであれば初期化ボタンを押下するのみであるところ、vMX初期化を実行するには上記のように再度SetUpを行うという対応となります。   その際のSeyUpマニュアルがお使いのサーバーやクラウドによって異なり、弊社の公式ドキュメントが多岐にわたる状況です。 このコミュニティ記事では、初期化復旧時に参考となるマニュアルをまとめさせていただきます。   vMXをご利用いただいているお客様は、vMXのSetUpに必要なvMX認証トークンをダッシュボードから、その都度生成していただく必要がございます。 vMX認証トークンは、 生成後 1 時間以内に入力する必要があります。 それ以外の場合は、新しいトークンを生成する必要があります。      プラットフォームごとのSetUpマニュアル一覧 vMX Setup Guide for NFVIS vMX Setup Guide for Alibaba Cloud vMX Setup Guide for Microsoft Azure vMX Setup Guide for Amazon Web Services (AWS) vMX Setup Guide for Amazon Web Services (AWS) China [deprecated] vMX Setup Guide for Google Cloud Platform (GCP) vMX Setup Guide for Cisco UCM Cloud (UCMC) ... View more

モニターキャプチャとは 無線LANアダプターを「モニターモード」状態にすることで、指定したチャンネルの無線パケットを全て収集することです。 無線環境の問題に遭遇した時に、トラブルシューティングの1つとしてモニターモードキャプチャが必要となることがあります。 主に必要となるユースケースは、無線においての接続の問題などに有効となることがあります。   Meraki ダッシュボードからワイヤレスのパケットキャプチャを取得することができますが、 ワイヤレスインターフェースを指定した場合、MR自身から送信した無線パケットは取得されないという仕様があるため、モニターモードキャプチャとして取り扱うには不十分です。   モニターモードキャプチャは、第三者となる調査用端末が、アクセスポイントとクライアント間の無線パケットをキャッチするものです。 無線LANのパケットキャプチャーはこれまで、調査用端末として、Macを使うか専用の無線LANアダプターを使うのが基本であり、Windows PCしかない場合や専用の無線LANアダプターを用意することが難しく、モニターキャプチャを取得することが困難な状況が多々あります。   この記事では調査用端末をMRで代用して、モニターキャプチャを取得する方法についてご案内します。   MRでモニターキャプチャを取得する方法 前提条件として、MRは必ず2台隣接して存在している環境であることです。  ※理由は先述の通り 全体の簡単な手順としては下記の通りです。     ①ダッシュボードでチャネル設定 隣接する2つのAPを同じチャネルに設定します。 何かしらの事象が発生しているAPが利用しているチャネルにもう一方を合わせます。 チャネル指定の方法については下記の通りです。 使用チャネルを手動で設定する方法についてご案内いたします。   (1)「ワイヤレス」 > 「設定」 > 「無線設定」＞「RFプロファイル」ページで、MRに適応しているRFプロファイルの編集画面から、チャネル幅を20MHzに指定し、保存する (2)「ワイヤレス」 > 「設定」 > 「無線設定」ページで 、「バンド」ドロップダウン メニューから5Ghzを選択し、設定変更したい任意のMRの無線を見つける (3)任意の無線の 「チャネル」列でチャネル番号のリンクをクリック (4)ポップアップが表示されるため、「チャネル設定を変更する」を押下 (5)手動を押下して、テスト用MRで選択されていた同じチャネルを選択し、保存 以上で、手動設定は完了します。 より詳細な手順や、説明が必要な場合は下記のドキュメントに写真付きのマニュアルがございますので、ご参考にください。 Transmit Power and Antenna Configuration - Cisco Meraki https://documentation.meraki.com/MR/Radio_Settings/Transmit_Power_and_Antenna_Configuration#Manual_Power   注意：チャネル変更時にチャネル変更をしたMRに接続しているクライアントは一時的に切断されます。 業務時間外やクライアントが少ないタイミングでの設定変更を推奨いたします。     ②物理的な準備 下記の図のように3台を近辺に配置し、テスト用のMRとClientが必ず接続する状況としてください。 ※モニターキャプチャを行うMRに接続しないように 場合によっては、モニターキャプチャを行うMRからSSIDを送信しないようにすることが効果的です。 ＊SSIDの稼働設定機能を使って特定のMRから特定のSSIDを送信しないように設定することができます。 設定手順は下記の通りです。 (1)「ワイヤレス > アクセスポイント」で、一覧より該当のAPに対してタグを設定 (2) 「ワイヤレス > SSID」で使用していない「Unconfigured SSID 」を有効化し、設定を実施 (3) 「ワイヤレス > SSIDの稼働設定」で、以下の内容で、変更内容の保存を実施 　　- SSID: (2) で設定したSSIDを選択 　　- 公開設定：　このSSIDを非公開にする 　　- APごとの公開設定：　「次のタグを持つAPでのみ有効」で(1) のタグを指定 　　- 利用可能時間の設定： 無効 ※通信切断は発生しない想定とはなりますが、運用影響の少ない時間帯で設定変更を行うことを推奨いたします。   ③パケットキャップ開始 モニターキャプチャ用のMRと、テスト用のMRを2つ指定して、   ワイヤレスインターフェースを指定してパケットキャプチャを実行します。 2つのMRを指定することで、モニターキャプチャの取りこぼしを防ぎます。   パケットキャプチャのページの詳細な利用方法については、下記のドキュメントをご参考にください。 パケット キャプチャの概要 - Cisco Meraki https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview#MR_-_Access_points   ※無線ビーコンパケットが大量に飛び交う環境の場合、MRのメモリ容量がすぐにいっぱいになり、 モニターキャプチャがすぐに終了してしまうことがあります。 その際には、パケットキャプチャを実行時にテスト用ClientのMacアドレスでフィルタ設定をしてから、パケットキャプチャを実行してください。 例：ether host 11:22:33:44:55:66     ④検証 パケットキャプチャを実行中にClientをMRに接続し、検証に必要な通信を発生させてください。     ⑤パケットキャプチャ終了 パケットキャプチャの取得に成功し、正常にダウンロードされれば完了となります。     関連するドキュメント TS-flow-radius - Cisco Meraki https://documentation.meraki.com/MR/Encryption_and_Authentication/RADIUS_Issue_Resolution_Guide/TS-flow-radius パケット キャプチャの概要 - Cisco Meraki https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview#MR_-_Access_points   ... View more

はじめに このコミュニティ記事は、共同終了（Co-term)ライセンス形態を利用されている、システム管理者に向けた、 ライセンス管理および、操作、更新に関するガイドです。 基本的な部分をまとめた内容ですので、詳細な説明が必要な場合にはドキュメンテーションをご参照ください。     ライセンスの消費開始日について 共同終了ライセンスの場合、ライセンスの消費開始日はライセンスがCiscoからメールにて発送された日からです。 ライセンスをご購入されますと、Ciscoからメールにてライセンスキーの発送通知が届きます。   無駄にライセンスが消費されてしまう前に、ライセンスキーの通知メールが届き次第、 なるべく早くオーガナイゼーションに登録することを推奨しております。   ライセンスをご購入されただけではライセンスは登録されません。 必ず、ダッシュボードからライセンスの登録をお願いいたします。 ※登録されず無駄に消費されてしまった分については、補填はできかねますのでご了承ください。     共同終了ライセンス形態でのライセンス登録操作について オーガナイゼーション > 設定 > ライセンス情報 ページから、Add another license（別のライセンスを追加） リンクをクリックすると、管理者はオーガナイゼーションにライセンスを追加できます。  この後の操作は「新たに機器を追加新設される場合」と、「ライセンスを更新される場合」で操作が異なります。 ・新たに機器を追加新設される場合 License more devices（デバイスライセンスの追加）を選択します。 追加するライセンスキーは追加するデバイスと同じ数量必要です。 なお、追加済みのライセンス数に余剰がある場合は不足分の追加で問題ありません。 参考：https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#Adding_New_Licenses   ・オーガナイゼーションのライセンスを更新する場合 Renew my Dashboard license(ダッシュボードのライセンスの更新)を選択します。 この時、注意いただきたいこととしては、更新する際に購入するライセンスの数量は、 ライセンス情報ページの「ライセンス数」ではなく実際に利用している「現在のデバイス数」であることです。   ライセンスの更新には現在稼働しているデバイスと同じモデルで同じ数量のライセンスをご購入いただく必要がございます。 参考：https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#Renewing_Your_Dashboard_Licensing   注意！ 誤って、License more devices（デバイスライセンスの追加）を選択して登録をしますと、 従来のライセンス数と更新分のライセンス数の合算でライセンスを按分するため、想定よりも短いライセンス期間となります。 例）10個の1Year ライセンスで10台のデバイスを稼働しているオーガナイゼーションのライセンスが期限が近いため、更新しなければならない。 しかし、誤って、新たに購入した10個の1Year ライセンスをLicense more devices（デバイスライセンスの追加）で登録してしまった。 →この場合、新たに購入した10個の1Yearライセンスを20台で按分することになり、約半年しか期間が伸びません。   ライセンスの取り消し 誤って追加してしまった場合には、ライセンス履歴から赤いロールバックマークで表示されている 「ライセンスの取り消しボタン」の操作を行うことで復旧できます。 ライセンス登録取り消しボタンが有効になるのは、ライセンスが適用されてから7日の間です。 ライセンス登録後のライセンス期間が想定と相違がないか必ずご確認をください。   元のライセンスキーを無効化し、同じ内容のライセンスキーを新たに発行するという動作をします。 取り消し実行時に、新たに発行されたライセンスキーが表示されますので、そちらのメモなどに控えてください。   なお、取り消し時に表示される新たに発行されたライセンスキーを見落としてしまった場合には、 オーガナイゼーション＞変更ログ のページにてから改めて確認することができます。 Meraki同時終了ライセンスの概要 ライセンス取り消し操作について- Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#Removing_and_Undoing_License_Claims     ライセンスの按分のメカニズム 共同終了ライセンスの仕様上、ライセンス期間はライセンス数で按分されております。 Co-Term は1つオーガナイゼーションで利用できるデバイスの上限を、ライセンス数によって決定するだけなので デバイスを消す = 上限が減る とはならず、上限にあわせて有効期限が設定されます。   また、それぞれのモデルとライセンスには、それぞれの金額に基づいた価値が付けられています。 その価値に伴って按分されるウェイトも異なるため、最も価値の低いMR ENTライセンスを1つ追加しても、1日程度しか伸びないということがあります。   共同終了ライセンスにおける計算方法やイメージについて詳細な説明が必要な場合は下記のドキュメントが参考になります。 ライセンスの共同終了の背後にある科学 - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview/The_Science_behind_Licensing_Co-Termination       ライセンスが切れてしまった場合の動作 ライセンスを更新し忘れてしまった場合、購入したものの間に合わない場合についてです。 ライセンス期限が切れたとしてもすぐさまオーガナイゼーションがシャットダウンされるわけではないので、ご安心ください。 ライセンスが切れた日から30日間のシャットダウンまでの猶予期間が設けられています。 この期間内にライセンスを購入いただき登録の操作までをお願いいたします。   Meraki同時終了ライセンスの概要 猶予期間について - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#The_30-Day_Grace_Period     その他、参考となるドキュメントやツール ライセンス更新時、あるいは追加時にどの程度のライセンス期間が見込まれるのか計算することができます。 下記のドキュメントよりライセンス計算機をご活用ください。 Using the License Calculator - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Using_the_License_Calculator   オーガナイゼーション間でライセンスを移動したい場合には下記のマニュアルが参考になります。 How to do a License Transfer in Cotermination - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/How_to_do_a_License_Transfer_in_Cotermination ... View more

はじめに こちらは、Upgrade RMA(旧Meraki Now)をご契約されているお客様に向けたコミュニティ記事です。 この記事のフォーカスとしてはフィールドエンジニア（FE）付きのサービスをご契約いただいている際の Upgrade RMA(旧Meraki Now)を申請した際に、お客様側で必要な対応についてです。   Upgrade RMA(旧Meraki Now)のサービスについてはドキュメントをご参考にください。 Cisco Meraki RMA Only Service -Meraki Now     Upgrade RMA(旧Meraki Now)の申請に際して Upgrade RMA(旧Meraki Now)ご契約機器の交換申請時は、原則としてお電話にてお問い合わせいただくようお願いいたします。 また、お電話いただく際はUpgrade RMA(旧Meraki Now)のご契約の有無についても担当者までお伝えいただくようお願いいたします。 メールにてご依頼いただきますと、通常のケースと同じ取り扱いとなり、対応開始までお時間がかかることがあります。   また、4時間目標など時間目標付きのご契約に関しては、時間目標はサポートにてUpgrade RMA(旧Meraki Now)の処理が完了した段階からの目標時間となります。 https://meraki.cisco.com/product-collateral/meraki-now-at-a-glance/?file https://www.cisco.com/c/dam/en_us/about/doing_business/legal/service_descriptions/docs/meraki-rma-only-service.pdf   翌営業日が目標時間のご契約の場合には、当日15時までにUpgrade RMA(旧Meraki Now)の処理が完了していなければなりません。 この時刻を過ぎますと、翌々営業日の到着となりますのでご了承ください。   ご依頼時に必要な情報の問診票をご用意しておりますので、ご活用いただけますと幸いでございます。 問診票に記載された情報を事前にご教示いただけますと、サポートによる切り分けに非常に有効に活用されます。   また、機器の設置位置や、入館時のセキュリティチェックに必要な書類などの情報をあらかじめご教示いただきたく存じます。 ※機器の作業位置が2m以上の場合、FEのサポート対象外となりますので、あらかじめご了承ください。 　高さ 2m 以上の高所での作業（床面から 2ｍを越える場所に上がっての作業は高所作業となります。） ※所管の法令規制により、オンサイト作業の対象範囲外となります。 Case作成時に必要な情報（問診票） - Cisco Meraki       FEの作業範囲について FEの作業範囲としては、管理者権限の不要な作業全般となります。   この作業範囲には、ローカルステータスページの設定が含まれておりますが、 この設定内容についてはお客様側にて事前にご用意をいただき、FEに設定情報をお伝えいただく必要がございます。   例）交換機器にStatic IPが割り振れられている場合など IP address：x.x.x.x Subnet：x.x.x.x Gateway：x.x.x.x Primary DNS：x.x.x.x Secondary DNS：x.x.x.x   ローカルステータスページの概要と、アクセス方法、操作については下記のドキュメントをご参考にください。 Cisco Merakiデバイスのローカル ステータス ページの使用 - Cisco Meraki     管理者権限が必要なMeraki ダッシュボード上の操作はFEでは対応できかねますのでご了承ください。 管理者権限が必要な操作でご不明点などがございましたら、ケース起票時にMerakiサポートにお問い合わせをいただくか、 Merakiのドキュメンテーションを参考にいただけますと幸いです。   ※MSの交換時には設定の複製などの作業が見込まれますので、下記のコミュニティ記事をご参考にいただけますと幸いです。 MSの交換方法について - The Meraki Community   なお、その他、FEが実施できない作業については下記のご利用ガイドをご参考にください。 Cisco テクニカルサービス ご利用ガイド https://www.cisco.com/c/dam/global/ja_jp/support/loc-tac-guide/pdf/cisco-ts-startup-guide.pdf     Ciscoテクニカルサービス規約について Tools & Resource 1次店　/　ディストリビュータ - Cisco https://www.cisco.com/c/m/ja_jp/partners/partner-with-cisco/services-partner-program-cspp/tools-resources-1.html       ... View more

MSの交換方法 MSの交換の手順と注意時点について記載しております。 予備機やRMA時の代替機との交換作業時の、実地作業のご参考になればと存じます。   MSの交換に際して、シングル構成かスタック構成か、Warm spare構成なのかで手順が異なります。 それぞれの手順で注意していただきたい事項、Catalyst SWと混同してしまうケースが多々あるため、 こちらの記事でご紹介している手順をご参考にしていただけますと幸いでございます。   前提条件として、交換機を事前にオーガナイゼーション＞インベントリに登録済みとしております。 デバイスをインベントリに追加いただいてから下記の作業をご実施いただくようにお願いいたします。 インベントリの操作方法については下記のドキュメントをご参考にください。   Using the Organization Inventory - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Inventory_and_Devices/Using_the_Organization_Inventory     シングル構成の場合 ダッシュボードより代替機をネットワークに追加いただき、故障機から設定を複製をお願いします。    1.「スイッチ」タブにて代替機の「スイッチ追加」 。 　（上記によって、「スイッチ」タブにて代替機が表示される）  2.「スイッチ」タブにて、設定複製、タグ内容など設定。 ※3 　PDLの場合、上記によって、障害機のライセンスを代替機に付け替えが必要。 3.故障機の電源OFF。  4.代替機の電源ON。代替機にて初期設定、ローカルステータスページの設定内容があれば。なければスキップ。  5.ステータスオンライン状態にすると設定がダウンロードされファームウェアがアップデートされる。  6.代替機の詳細ページにて設定ステータスが最新となっているか確認。  7.物理配線を新しいスイッチに付け替え。 8.故障機を「スイッチ」タブと「インベントリ」タブから両方削除 ※1※2 9.故障機取り外し        スタック構成の場合 この手順では、ファームウェア不一致によるスタック失敗を回避することを考慮して作成しております。  また、LAGをスイッチを跨いで設定している状況ですと、交換時にスタックメンバーで通信断が発生する事象が確認されています。  ※MS15.21.1まで事象発生、MS16.1以降にて修正済み そのため、交換にはメンテナンス時間を設けて実施をお願いいたします。    1.「スイッチ」タブにて代替機の「スイッチ追加」  　（上記によって、「スイッチ」タブにて代替機が表示される）  　PDLの場合、上記によって、障害機のライセンスを代替機に付け替えが必要。 2.スイッチ＞スタックスイッチ＞【対象スタック名】＞複製とメンバーの交換＞スタック内のスイッチの交換にて故障機と代替機を交換。 ※設定は自動的に複製されます スタックメンバーが3台以上の場合は、設定複製を行い新規スタックメンバとして代替機を追加、スタックメンバから故障機の削除する手順でも可能です。 3.故障機の電源OFF、故障機からスタックケーブルを外す。 4.代替機の電源ON。代替機にて初期設定、ローカルステータスページの設定内容があれば設定を行う。 　※なければスキップ。 5.ステータスオンライン状態にすると設定がダウンロードされファームウェアがアップデートされる。  6.MSの詳細ページにて設定ステータスが最新となっているか確認。  　※最新でないままにスタックケーブルを接続すると、ファームウェアや設定が不一致の状態となり、スタックに失敗することがあります。  7.物理配線を新しいスイッチに付け替え、スタックケーブルを接続して復旧。  8.故障機を「スイッチ」タブと「インベントリ」タブから両方削除 。※1※2 9.故障機取り外し 。 10.スイッチ＞スタックスイッチ＞【対象スタック名】＞メンバー管理 にてスタックステータスにエラーやアラートがないか確認。    ※ただしくスタックができていないというアラートが発生していることがありますが作業途中で発生したアラートが残っていることがあります。  実機の方でステータスランプが緑色であれば正しくスタックができているため、無視して問題ありません。  時間経過で解消されます。       Warm spare構成の場合 1.「スイッチ」タブにて代替機の「スイッチ追加」 。 　（上記によって、「スイッチ」タブにて代替機が表示される）  2.「スイッチ」タブにて、設定複製、タグ内容など設定。 ※3 　PDLの場合、上記によって、障害機のライセンスを代替機に付け替えが必要。 3.故障機の電源OFF。  4.Meraki ダッシュボードで[スイッチ] > [スイッチ]ページにてWarm Spare設定を、 古いスイッチから新しいスイッチに変更。 MS Warm Spare (VRRP) Overview - Cisco Meraki https://documentation.meraki.com/MS/Layer_3_Switching/MS_Warm_Spare_(VRRP)_Overview 5.代替機の電源ON。代替機にて初期設定、ローカルステータスページの設定内容があれば設定を行う。 　※なければスキップ。 6.ステータスオンライン状態にすると設定がダウンロードされファームウェアがアップデートされる。  7.設定のダウンロード及び、Firmwareアップグレードが完了したことを確認。 8.物理配線を新しいスイッチに付け替え。 9.故障機を「スイッチ」タブと「インベントリ」タブから両方削除 。※1※2 10.故障機取り外し 。   ※ただしくWarm spareが構成できていないというアラートが発生していることがありますが作業途中で発生したアラートが残っていることがあります。  実機の方でステータスランプが緑色であれば正しく構成ができているため、無視して問題ありません。       デバイスの設定がMerakiCloudと同期できているかを確認する方法 該当のMSの詳細ページを開いていただきますと、画面左側にMSのステータスが順に表示されております。 各ステータスの中に、CONFIG（設定）の項目があり、そちらがUp to date（最新）となっていれば同期がされていることがわかります。       参考資料 ※1[オーガナイゼーション インベントリの使用方法]  https://www.cisco.com/c/m/ja_jp/meraki/documentation/general-administration/inventory-and-devices/using-the-organization-inventory.html  ※2[ダッシュボードのネットワークに対するデバイスの追加と削除]  https://www.cisco.com/c/m/ja_jp/meraki/documentation/general-administration/inventory-and-devices/adding-and-removing-devices-from-dashboard-networks.html  ※3[設定の複製方法] https://documentation.meraki.com/MS/Other_Topics/Switch_Cloning_jp ... View more

PDL変換の新規のご依頼は6月25日をもって対応終了となりました。   現在、PDLへの変更をご希望の場合、現在サポートに「英語」でケースを上げていただくことで変更機能の有効化を行っています。 お客様側でPDLへの変換が出来なくなった経緯とこの一連の手順については、以下のドキュメントページでもご案内しております。 EN:How to convert an org from Co-term to Per Device licensing - Cisco Meraki   PDLへの変換をご希望の場合、上記ページの注意事項をご確認いただいた上で、 以下の5つの情報を英語で記載した新規ケースをオープンしていただけますでしょうか。   ＊PDLへ変換する前に ・すでにPDLの組織を保有している場合は、MSPポータルの機能でPDLの組織のクローンを作成することで、このフローをスキップすることができます。 ・PDL と共同期間の間でライセンスを移動できないことをご留意ください。 ・2 つのライセンス モデルの管理は複雑になる可能性があるため、すべての組織で一貫して 1 つのライセンス モデルを使用することを推奨しております。 ・組織が PDL モデルの検証に使用したい場合、本番の組織がすでにPDLであればMSPポータルから組織のクローンを作成することができます。     ＊PDL変換の全体の流れ 1. PDL変換依頼のための英語でのケースオープン 2. 海外のライセンス担当チームでの確認 3. ライセンス担当チームでの機能有効可処理とケース上での報告 4. お客様側で確認及びダッシュボードでの変換実施     1のケース起票時に必要となる情報は以下のとおりです。 下記の5つの項目を英語の情報でご用意いただき、通常通りダッシュボードからケースをオープンしてください。 下記にテンプレートをご用意しておりますので、ケース起票時にご活用ください。 ※日本語は削除してご利用をお願いいたします 件名： Convert License model to PDL ・Reasons to Convert to PDL（PDLへ変換する理由） 　... お客様のビジネス上、PDL形式への変換が求められる理由をご記載ください。 ・Agree with considerations（PDL変換へ同意いただける旨のお返事） 　... Co-terminationからPDLに変換後、原則としていかなる場合もCo-terminationに戻すことはできません。 　この旨にご了承いただける旨のお返事が必要となります。 ・Administrator（該当オーガナイゼーションの管理者ユーザ情報） 　... 管理者ユーザ名、ご登録のメールアドレスをお送りください。 ・Support Passcode（上記管理者ユーザのサポート用パスコード） ・Sales representative（該当オーガナイゼーションの Meraki営業担当者） 　... Meraki 営業担当者の氏名とメールアドレスをご記載ください。 　営業担当者は以下の手順でご確認いただけます。 　ダッシュボード上部「ヘルプ」 ＞ メニュー内「ヘルプ」 ＞ ページ下部「ドキュメントでお探しの情報が見つからなかった場合」 をクリック ＞ 「ドキュメントでお探しの情報が見つからなかった場合」をクリック 　営業担当者の情報が表示されない場合、この項目はスキップしてください。   なお、サポート用パスコードに関しては、毎日変更されるものとなります。   ご提出いただく時間によっては、翌日に再度確認していただく必要がある可能性がございます。   [Meraki 顧客番号やサポート用パスコードを確認する方法]     　上記内容でケースを起票いただくことで、ライセンス担当チームから追ってご連絡をいたします。 場合によって追加の情報を求められる場合がございますので、英語でお返事をいただけますと幸いでございます。 なお、ケース内で組織名などの固有名詞以外で日本語を用いると、システムにより正しい担当者への割り当てに時間を要する場合がございますので、ご了承ください。 お手数ではございますが、ケースの起票からライセンス担当チームと会話まで、全て英語でご記載いただくようにお願いいたします。 ... View more