司会:
説明:
書記:川添・徳永
参加者:サポーターn名
オレンジ色の部分は、ミーティング中に挙げられたコメント等です。
最近の事例から
ECCSクラウドメール(Google Workspace)
回答: https://www.ecc.u-tokyo.ac.jp/announcement/2021/09/10_3355.html でフォーム2を出したあとも返信がないとのことなので、起票してECCS担当に割り当てた。
回答: メールアドレスが自動生成されること、そのアドレスで引き継ぎフォームにログインすることを案内する文案を作成する途中で引き継ぎ。
回答: 新規UTokyoAccountには自動的に新規ECCSクラウドメールが生成されること、またその確認方法を案内する文案を作成した。
回答: 新しいUTokyo Accountでの初期設定から知る旨を案内する文案をレビュー・そのままGO
- 参考:UTokyo Accountが変更されても以前のECCSクラウドメールアドレス等を使用したい場合の手続きについて(ECCS広報)
- 上記広報に記載のフォームより申請を行い、その後の手順は、申請後に届くメールに記載されている
- ECCS担当の方より申請の流れをご提供いただきました(サポーター限り)
- 上記ドキュメントに記載の通り、フォーム申請時にアクセスできるアカウントにより、以下の3通りに分かれる:
- 引継ぎ希望のECCSクラウドメールでログインしていた場合
- 2回目のフォームのURLと申請ID、トークンが届く
- 新しいUTokyo Accountの初期設定が済み次第、新しいECCSクラウドメールで2回目のフォームに申請ID、トークンやその他必要事項を回答
- 正しく申請が完了していたら、ECCS担当の方が繋ぎ替え作業を実施
- 新ECCSクラウドメールでログインかつ引継ぎ希望のECCSクラウドメールの転送設定ありの場合
- 2回目のフォームのURLと申請ID、トークンが引継ぎ希望のECCSクラウドメールに届く
- 新しいECCSクラウドメールで2回目のフォームに申請ID、トークンやその他必要事項を回答
- 正しく申請が完了していたら、ECCS担当の方が繋ぎ替え作業を実施
- 新ECCSクラウドメールでログインかつ引継ぎ希望のECCSクラウドメールの転送設定なしの場合
- これで申請者本人の作業は終了
- ECCS担当の方が在籍確認の上で、繋ぎ替え作業を実施
- 在籍確認は大変なので、できれば旧アカウントの失効前に申請してほしいそう
- 引継ぎ希望のECCSクラウドメールでログインしていた場合
- ちなみに繋ぎ替えは手作業で行っていて、2時間くらいかかる
ITC-LMS
回答: |-
教職員用マニュアルのコースグルーピングの記述と比較したときに気になる点(履修者のときとそうでないときで挙動が変わる?)があったため、LMS担当に回すように提案.結果,LMS担当の**さんが直接電話してほぼ解決したが,一応クローズ文面にも**さんの説明内容をほぼそのまま記載した.
回答: グルーピングによってそうなっているので問題ないこと、履修登録した学生にはそれぞれのコース名で表示されることをお伝えしました。
- ITC-LMS 教員マニュアル (ver. 2.0.13) の「10.5.1. 代表コース名変更」に以下の記述がある:
-
グルーピングしているコースの場合は、グルーピングしているコース名が表示されます。グルーピング内で代表コース名を変更することができます。
代表コース名は、担当教員が「コースTOP」画面を表示した時に表示されるコースの名前です。
履修者の「コースTOP」画面には、ここで設定した代表コース名にかかわらず履修しているコース名が表示されます。 - 代表コースに指定されたコース=親コース
- 担当教員でも履修者でもないユーザーからの表示については確かに明記されていない?
-
- LMS担当からも簡単にコメントをいただいていたが、以下ではもう少し正確かつ詳細な仕様を紹介
- 以下の説明で用いる「履修者」という語は特に断りのない限り、ITC-LMSにおいて「履修者」の権限を持つコース参加者のことを指す
- UTASで履修登録をしている学生に限らず、ITC-LMSで自己登録や担当教員登録などの方法によりコースに「履修者」として参加したユーザーを含めるということです
- 以下の説明で用いる「履修者」という語は特に断りのない限り、ITC-LMSにおいて「履修者」の権限を持つコース参加者のことを指す
- 前提:グルーピングされたコースへの参加について
- グルーピングされたコースのうちどのコースに参加しているかという情報を持っている
- 「担当教員」:上記の「コース参加者一覧」画面では科目名が指定されていないように見えるが、「コース参加者登録」において参加させるコースを指定できる
- 例えば、コースのグルーピングを解除したりすると、確かにこの時指定したコースのみに残る
- 「TA」:担当教員と同様、コース参加者画面では科目名が指定されていない。が、コース参加者登録において、権限を「TA」とした場合は、「科目選択」がグレーアウトしてしまうようで、やや教員とは異なる模様。
- この場合、コースのグルーピングを解除すると、いずれのコースにも残る
- 「履修者」:上記の「コース参加者画面一覧」の「科目名」から参加しているコースもわかるし、コース参加者登録において追加する科目を指定できる
- UTAS連携の場合は、当然UTASで登録しているものから連携されたコースへの参加となる
- 自己登録の場合については後述
- グルーピングされたコースのうちどのコースに参加しているかという情報を持っている
- 本題:コースの表示について
- 検索結果:コースがグルーピングされている場合でも、検索結果にはすべてのコースが、元のコース名で表示される
- 「コースTOP」(コースを開いた結果):コース参加の有無や、コース参加者として与えられた権限によって異なる
- 「担当教員」:「代表コース名」が表示される
- 自分の参加するコースは関係ない
- 「TA」:「代表コース名」が表示される
- 「履修者」:自分の参加するコース名が表示される
- コース参加者以外:「代表コース名」が表示される
- 「担当教員」:「代表コース名」が表示される
- 「出講表」/「時間割」:コース参加の有無や、コース参加者として与えられた権限によって異なる
- 「担当教員」:自分の参加するコースがすべて表示される
- 典型的には、コースのグルーピングを行った「担当教員」(=グルーピングされたいずれのコースにも参加)には、グルーピングしたコースが並ぶ形で表示される
- グルーピングされたコースのうち全てに参加していない場合は、参加しているコースのみが表示される
- つまり例えば、子コースのみに参加している場合、コースを開くと、出講表で表示されているコース名とは異なるコース名のコースTOPが表示される、ということになる
- 典型的には、コースのグルーピングを行った「担当教員」(=グルーピングされたいずれのコースにも参加)には、グルーピングしたコースが並ぶ形で表示される
- 「TA」:「代表コース名」が表示される
- 「履修者」:自分の参加するコース名が表示される
- 「担当教員」:自分の参加するコースがすべて表示される
- おまけ:自己登録について
- 上述の通り、コースに参加していない場合は、グルーピングされているいずれのコースを開いても、「代表コース名」のコースTOPが開く
- そのコースTOPで自己登録を行うと、その時点で「代表コース名」と設定されているコース=親コースに参加することになる
- サポーターでも実験できると嬉しい?
- UTASで複数看板の両方に登録されている(ことがありえたとした場合、)学生はどうなる?
- 同じ時間に複数履修できることはできるのか?
- 複数同時に「履修登録」はできないけど「お気に入り登録」はできる
- 同じ時間に複数履修できることはできるのか?
- ○○語一列と二列をグルーピングしたら、両方に同じ履修者がいることになる?
- (10/20追記)上に挙げていただいたような場合、グルーピングするときには一度被っている履修者を削除していただくことになるが、UTASで履修登録/お気に入りとして登録している場合は、早朝のデータ連携によりLMSのコース参加も復活し、複数コース参加の状態になるとのこと。
- コースをグルーピングするタイミングで「TA」や「履修者」が被っているとエラーになるが、グルーピングした後に複数コースに参加する状態になっても特に問題ないそう。
- ちなみにこの場合、履修者には代表コースが表示されるらしい。
回答: グルーピングされる方が親科目でメインに利用する科目となる。 という内容でレビューへ
回答: |-
(レビュー)
・構成の変更
・「親と子はシステム側で決められている」という誤解を解く文言を追加
・解決しなかった場合の文言を追加
GO。
- グルーピングの親子関係については、回答の通り、担当教員の方で決めていただければOK
- (上記勤務報告には出ていないが、)併せて「履修者が重複している場合、親と子のどちらの履修者を削除すべきか?」という質問を受けていた
-> LMS担当からの基本方針:本登録(UTAS連携で登録されている)のコースと仮登録のコースがあれば、仮登録の方を削除する- 親か子かというのは関係ない
- 本登録のコースを削除してしまうと、本登録のはずなのに仮登録になっている?!と不安に感じさせてしまうため
- とは言え、この操作を間違えたからと言って取り返しのつかないことになるわけではなく、UTAS連携分も翌日になれば復活し、本登録に戻る
- (参考)UTASとLMSは1日に1回連携
- 深夜2時頃のUTASの最新データが早朝(5時とか6時)に連携される
- UTASから来るのは差分ファイルではない
- 各ファイル内のデータが含まれなくなっても、ITC-LMS上の該当データが削除されることはない
回答: 担当教員が「履修者範囲設定」を「常に仮登録者を許可」にすれば可能であることをお伝えしました。
回答: https://www.sodan.ecc.u-tokyo.ac.jp/faq/itclms-allow-audit/ の補足をもとに仮登録への変化や履修者範囲の変化など、デフォルト設定でなぜこれが起こるのかの仕組みを案内する文案を書いていただきレビュー・GO
- 9月末に履修者範囲設定の仕様が変わりました
- 「履修者範囲設定」の選択肢が以下の3つになりました
- 「常に仮登録者を許可」
- 「履修確定日まで仮登録を許可」
- これを選択していた場合、履修確定日を過ぎると、自動的に「常に履修登録者のみ」に変わる
- 「常に履修登録者のみ」
- (上記の挙動には違和感を持たれるかもしれませんが……)
回答: 「問い合わせを完了する」ボタンを押さなくても「回答済み」に変わるが、「問い合わせを完了する」にすることでやりとりが終了した合図になることをお伝えしました。
その他: “”
回答: メッセージ機能で学生とのやりとりをして、そのやりとりが終わったことを示すものである旨の文案をレビュー・そのままGO
- ※ただの小ネタです
- 「問い合わせを完了する」ボタンを押すとステータスが「完了」になる
- 完了済みにしたユーザー名も表示される
- ステータスには、以下の3つがある
- 未回答
- 回答済み
- 完了
- メッセージはステータス順に並ぶので、「問い合わせを完了する」と一番下に行く
- 以前TAをやった授業で、「このボタンを押さないと問い合わせが送信できないのかな」と思ったのか、メッセージを送るたびに「問い合わせを完了する」を押してくる受講生がいた
UTokyo Account
“You can’t reset your own password because you haven’t registered for password reset”と表示される。
回答: |-
再登録用メアドが登録されていない可能性があるので、その方法をご案内しました。
https://www.sodan.ecc.u-tokyo.ac.jp/en/faq/if-you-have-forgotten-your-password/
回答: |-
・英語表現の修正
・今後のためにUTASにメールアドレスを登録してね、という文面を追加
GO。
- Microsoftの組織アカウント(学校または仕事アカウント)= Azure ADのSSPR (Self-service Password Reset)
- メールアドレスが登録されていない状況でパスワードリセットを行おうとすると以下のエラーとなる
-
パスワードのリセットを登録していないため、自分でパスワードをリセットすることはできません。
サインインできない場合、管理者に問い合わせて、パスワードをリセットしてもらう必要があります。
将来、再びサインインできるようになった後で、セルフサービス パスワード リセットに登録し、自分でパスワードをリセットできるようにします。
-
- ちなみに、#helpでは入力する「メールまたはユーザー名」を間違えている可能性が指摘されていたが、その場合は以下のようなエラーとなる
-
電子メール アドレスは、user@contoso.onmicrosoft.com または user@contoso.com という形式で入力してください。
-
ここで Microsoft アカウントや個人の電子メール アドレスを使用することはできません。職場または学校アカウント (例: user@contoso.com) を入力してください。Microsoft アカウントのパスワードを変更するには、ここをクリックしてください。
-
入力したメールまたはユーザー名が存在しません。メールまたはユーザー名が正しく入力されていることをご確認ください。
-
- ちなみにUTokyo Accountが失効している場合も以下のエラーとなりパスワードリセットができない
現在、お使いのアカウントはブロックされているため、サインインできません。 そのため、パスワードのリセットは現在行えません。お客様の組織の管理者に連絡し、アカウントのブロック解除を依頼してください。
回答: 操作しているMicrosoft アカウントが UTokyo Account ではないことを回答
- UTokyo Accountのほかに、ECCSクラウドメールのアドレス((任意)@g.ecc.u-tokyo.ac.jp)を利用してMirosoftアカウントを作成することができる
- 作成ページ: https://www.microsoft.com/ja-jp/education/products/office/default.aspx
- 普通にMicrosoftアカウントにサインアップする画面で作ろうと思うと以下のエラーになるので上記ページで作成する
職場や学校のメール アドレスを使ってサインアップすることはできません。Gmail や Yahoo! などの個人用メールを使うか、新しい Outlook メールを作成します。
- 普通にMicrosoftアカウントにサインアップする画面で作ろうと思うと以下のエラーになるので上記ページで作成する
- 用途
- Office 365が利用可能
- UTokyo Accountでは学生向けには無効化されているTeamsが利用可能
- UTokyo Microsoft Azure Dev Tools for Teachingを利用するのに必要
- ライセンスの提供方法が変わったために今年度はライセンスの更新手続きができておらず利用不可
回答:
1. Microsoft Authenticatorであればワンタップで認証が行える
2. ブラウザを閉じなければ認証頻度は24時間に一回なので、ブラウザをなるべく開いたままにする
- UTokyo Accountの再認証頻度について整理
- Shibboleth(UTAS、ITC-LMSなど)の場合
- 多要素認証を有効化しているか否かで挙動は変わらず、24時間に一度サインインを行う必要がある
- ブラウザのウィンドウを閉じるとセッションが終了して24時間を待たずに再認証が掛かってしまう
- Azure AD(Zoom、Office、Webexなど)の場合
- 多要素認証を有効化している場合は、現在(2022年10月時点)は14日に一回の認証
- 8月ごろは24時間に一度の設定だった
- 注意: 「ブラウザでのサインインの際はサインインの状態を維持しますか?」というダイアログに「はい」と答えないとセッションがCookieに記憶されないためブラウザを開くたび再認証が発生
- 多要素認証を有効化していない場合はAzure ADのデフォルト設定
- Officeでは永続(90日)、ブラウザはセッション永続化なし(開くたびに再認証)
- 多要素認証を有効化している場合は、現在(2022年10月時点)は14日に一回の認証
- Shibboleth(UTAS、ITC-LMSなど)の場合
Microsoft 365 (Office)
回答: 案内ページ( https://www.sodan.ecc.u-tokyo.ac.jp/faq/wam-prompt/?utm_source=rss&utm_medium=rss&utm_campaign=wam-prompt )を案内した。
- 推奨される操作としては以下
- 「組織がデバイスを管理できるようにする」のチェックは外す
- 東大ではデバイス管理機能を有効化していないためチェックを入れても何か機能的な違いが発生するわけではない。ただし、チェックを入れると無用なエラーメッセージ(80180018など)が発生することが確認されている
- 「いいえ、このアプリのみにサインインします」をクリックする
- 「OK」をクリックするとデバイスにUTokyo Accountが登録されて、Office以外のアプリ(OneDriveクライアントなど)でのサインイン時に自動的にUTokyo Accountが選択されるようになる。ただし、この場合にもエラーメッセージ(135001、700003など)が発生することが確認されている
- 「組織がデバイスを管理できるようにする」のチェックは外す
その他
回答: UTokyo Slackに招待する際は(共通ID10桁)@utac.u-tokyo.ac.jpを招待する必要がある旨案内した
- 案内ページ
- UTokyo Slackのワークスペースにユーザーを招待する際は、(共通ID10桁)@utac.u-tokyo.ac.jpに招待を送る必要があり、(任意文字列)@g.ecc.u-tokyo.ac.jpに招待を送っては参加できない
- (共通ID10桁)@utac.u-tokyo.ac.jp宛に送られた招待メールは(任意文字列)@g.ecc.u-tokyo.ac.jpに転送されるため、招待メールを受け取った側では同様の招待メールに見える
- もしサインインできない場合は招待メールの宛先が(共通ID10桁)@utac.u-tokyo.ac.jpになっているか確認し、もしなっていない場合は再度招待を依頼
回答: 人事情報システムは学内アクセス限定であること、その実現手段としてはECCS端末(個人アカウント)とUTokyo VPNがあることを案内
- 人事情報システムや就労管理システムなど、一部の事務系のシステムは多要素認証が求められない一方、学内アクセス限定になっている
- ゲストでは学内アクセス扱いにならない
- UTokyo-Guestは学内アクセス扱いにならない
- ECCS端末(ゲストアカウント)でできることは限定されている