投稿

Intuneで配布するWi-Fi設定の接続名ってなんだろう

イメージ
  IntuneでWi-Fiに関する構成プロファイルを設定していると "接続名"って項目がある。 上のWi-Fi名(SSID)は。「SSIDね」ってわかるけど "接続名"ってなに?SSIDとは別なの?ってなった。 とりあえずMicrosoftドキュメントを参照 https://docs.microsoft.com/ja-jp/mem/intune/configuration/wi-fi-settings-windows --- 接続名: この接続のユーザーフレンドリーなWi-Fiします。 入力するテキストは、ユーザーがデバイスで使用可能な接続を参照するときに表示される名前です。 たとえば、「ContosoWiFi」と入力します。 --- わかりそうでわからん。 日本語ちょっと変なので、英語のほうを見てみる。 https://docs.microsoft.com/en-us/mem/intune/configuration/wi-fi-settings-windows --- Connection name: Enter a user-friendly name for this Wi-Fi connection. The text you enter is the name users see when they browse the available connections on their device. For example, enter ContosoWiFi. --- 書いていること変わらんかった。 まぁ、そうだよな。 とりあえずやってみりゃわかるか、ということで SSIDとは別の文字列を入れてみる。 KaisyanoWiFi (会社のWiFi)にとりあえずしてみる。 んで、配布。 結果。 構成プロファイルが配布されたデバイスからはWi-Fiの表示名が 設定した接続名で表示される。 当たり前だけど、関係ないデバイスではSSIDそのままで表示されている。 メリットはSSIDを適当な文字列にしておいて どの会社のWi-Fiか予測できないようにしつつ 社員は自社のWi-Fiにつながっていることが目視できるってところでしょうか 他になにかあるかなぁ。今のところ思い当たらない。

WindowsデバイスをIntuneに登録しようとするとエンドポイントを検出できなかったっと出た

イメージ
  Windows10を自動登録なしの手動で登録しようとしたら "入力されたユーザー名と一致する管理エンドポイントを自動検出できませんでした。ユーザー名を確認して、やり直してください。管理エンドポイントのURLがわかっている場合は、それを入力してください。" (We couldn’t auto-discover a management endpoint matching the username entered. Check your username and try again. If you know the URL to your management endpoint, enter it.) と出てきた。 ハァ?なんで? Intune登録要求リダイレクトのCNAMEレコード外れたのか?と思って確認してみると 問題なさげ。 問題が起きる原因として思い当たるのは お名前ドットコムからGoogleDomainsにドメインを移した ぐらいしか心当たりがない。 とはいえ、いろいろちゃんと動いているし、 と、思いながらポチポチしてると CNAME検証できるじゃん 結果をみると大丈夫っぽい とりあえずCNAMEは置いといて MDMサーバーURLってなに入力すればいいんだろ? ということで とりあえずネットで検索。 MSのドキュメントも見たけど "IT サポート担当者に問い合わせ、正しい URL (例: ) を取得します" とか。あまり良い情報が見当たらない。 ITサポート担当者ってこの場合、ワイやんけ。知らんよ。 他にもネットで検索したけど CNAME登録れば解決するよ、って情報ばかりで・・・。 CNAMEは登録されてるんだよねぇ。。。と思いながら 日本語の情報はあきらめて 英語で検索し始めたけど、同じくCNAME、CNAME、で 3件ぐらい見たところであきらめて 心当たりある文字列をとりあえず入力してみる、に切り替えた。 結果、 入力する値はコレ https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc 答えがわかってしまえば、まぁ、そうだよね。ってなる。 入力してみる サインインページに移動 認証が入る ちなみに認証後にエラーが出たので MDM...

Microsoft365で使っているドメインをお名前.comからGoogleDomainに移行

イメージ
とあるドメインが期限切れ間近だったので、更新するか捨てるか迷ったのですが、 お名前ドットコムから持っているドメインをすべて移行することも考えていたので、この機会を使ってM365に使っているドメインの移管がどんなもんか試そうかと お名前ドットコムはIDパスワードログインだけだったのでちょい危ないから移管しようか、と思いながらもしばらくそのまま放置してた そうしている間に2要素認証ができるようになったのでそのまま使っていたのですが、 検証用で一時的に取得した捨てドメインの自動更新を停止していたはずなのに、なぜかいつのまにか自動更新ONになっていたり、挙動がなんか怪しい。 メールとかも1日10~20来てウザい。 ということでGoogleDomainsに移行しようと。 とりあえずGoogleDomainsを開く 1,400円かかると書かれていて、移管って有料なのかと一瞬思ったが、 期限切れ間近だからかわからんが更新料が発生するっぽい。まぁ、更新してもよいので問題なし。 お名前ドットコムから認証コードを取得して入力する必要があるっぽいので、 お名前ドットコムにログイン。 認証コードがどこで入手できるかわからんけどこの辺かな、と開いたページ お名前.comから移管が無い。 お名前.comへの移管はあるけど、お名前.comから移管が無い。 入口はあるけど出口が無い。 ヘルプでも見るか。 https://help.onamae.com/answer/8593 認証コードはお名前.comではAuthCodeらしい。 「管理画面にてAuthCodeと~~」 管理画面のどこなのか説明せいよ。 他のヘルプ見てみる。 https://help.onamae.com/answer/8581?btn_id=new_domain_transfer 「管理画面にてご確認いただくことができます」 だから、管理画面の何処なのかちゃんと記せって 「確認方法は以下ガイドをご参照ください。」と案内があるので、そこに移動 https://www.onamae.com/guide/p/80?_ga=2.19385016.1602961654.1651044809-1853170378.1651044809 AuthCodeに関する記載がここ↓と ここ↓にふんわり登場するだけ。こことか画像なので検索にも引っかからな...

Teamsのデータ保存場所がアジア太平洋だったので日本に変更

イメージ
 ふと検証環境Office365サービス群のデータ保存場所を見てみたら Teamsの保存場所がアジア太平洋だった まぁ、このテナントを使い始めたのは4、5年前なので、その頃は日本に保存がそもそもなかったようなあったような こっちより新しい検証環境テナントはぜんぶ日本になっていた。 ある時を境に日本で契約したテナントのデータ保存場所は日本になるのだろう、と。 今は日本に保存ができると聞いているので変更しよとヘルプサポートに連絡 (5,6回、メールや電話でやりとりしていますが、はしょって書いています。また、サポート担当者はとても丁寧に対応してくれました) 「変更方法教えてください」 「自動移行のリクエスト締め切っています。それでもどうしてもというなら相談可能です」 リクエスト締め切った?そもそも受付してたことさえ知らんかった どうしてもなら相談可能ってことは、やってもらうための根拠が必要ということだろう 「法的に問題なければアジア太平洋でも問題ないです。例えば個人情報保護法に対し、アジア太平洋でも法的に問題ない根拠などの公開情報などあれば教えてほしいです」 「規約上、法的観点はサポートできないです。御社の法務とご相談お願いします」 規約 https://www.microsoft.com/licensing/terms/product/PrivacyandSecurityTerms/all なるほど。まぁ、そうか 「では、アジア太平洋とは具体的にどこの国々がはいっていますか?」 「香港特別行政区、日本、マレーシア、シンガポール、韓国になります」 Microsoft 365 顧客データの保存場所 https://docs.microsoft.com/ja-jp/microsoft-365/enterprise/o365-data-locations 香港かぁ。特別行政区っつても一国二制度崩壊したから実質中国に保管とかわらんとして・・・、コレだめだろ 韓国ってGDPR十分性認定どうなったんだっけ? どっちにしろアジア太平洋だめだ 「法的にNGです。移行相談させてください」 「ちょうどいま、データ移行リクエスト受付再開してます。手順に従って行ってください。なにかわからないことあったら連絡ください。申請期限は 2月25日です。」 「あざす」 データ移行をリクエストする方...

EndpointManagerを使ったWindows11へのアップグレード

イメージ
 EndpointMangerを使ったWindows11へのアップグレードを動作確認目的の検証。 動作確認メインはエンドポイント分析のWindows 11 へのハードウェアの準備状況(Hardware Readiness)の表示確認だったのですが、 ついでにやってみたEndpointManagerの更新リングで「Windows10デバイスを最新のWindows11リリースにアップグレードする」でちょっとはまりました。 自動でアップグレードするのを放置して待っていたけど、アップグレードされない。 調査してみようとアップグレード対象VMのイベントログでも見てみようかしらと思いながらポチポチしながら WindowsUpdateをよく見てみると、アップグレードが表示されない。 なるほど。評価版Windows10はアップグレード対象ではないっぽい? 評価版をアップグレードするなら最初から評価版Windows11使えってことかな ならば製品版で、ということで 製品版のWindows10のVMを作って確認。 EndpointManagerに登録し、アップグレード対象グループに入れて放置。 1週間放置していたけどアップグレードされてなかった 正しい動きの成功例を持っていないので更新リングの設定が間違っているのかわからない。 正しい設定と動きがわかれば切り分け簡単なのだが、今は設定もデバイスもなにが正解かわからない。 とりあえず原因は何だろうと調査。 CPUが対応していない。 ネットで調べてHyper-VのVMであれば 仮想TPMつけてセキュアブートでCPUコア数とクロック数、メモリ容量クリアできていればけると思っていたけどそうではなく、結局、元となるハードも要求されるらしい。 ハードが対応していなくてもアップグレードする方法はあるらしいが、今回の目的ではないのでそこはスルー 手元にWindows11対応CPUが載っているパソコンはあるにはあるので、 そこにHyper-VでVM作るか、と思ってたところSurface7+を借りれることになったので そのまま物理PCをアップグレードすることにした。 今まではVMだったり評価版だったりで、アップグレード対象デバイス自体に問題があるのか、タイミングが悪いだけなのかよくわからない。 切り分けしようにも正解がわからんので、要因となり得そう...