Cloud 移行を計画する
Atlassian Server または Data Center 製品の移行準備に役立つドキュメント。
移行前にメール ドメインを確認する
すべてのユーザーは、何らかのドメイン (@atlassian .com など) のメール アドレスを持っているはずです。クラウド サイトを安全に保つために、信頼済みのドメインのユーザーのみを移行できます。
移行の前に、次のことを実行する必要があります。
移行アシスタントを使って、ユーザー ディレクトリにあるメール ドメインを表示する
ドメインを確認して信頼済みとしてマークする。移行のために必要な作業です。
ユーザーを削除するか、メール アドレスを他のドメインに変更して、信頼されていないドメインを削除する
移行するには、すべてのメール ドメインを信頼済みとしてマークする必要があります
これには、特定のプロジェクトまたはユーザーのサブセットのみを移行する場合でも、インスタンス内のすべてのユーザーの電子メール ドメインが含まれます。メール ドメインの確認や信頼を行わなくても、移行を作成、実行できますが、すべてのメール ドメインを信頼済みとしてマークするまで移行は失敗します。このページでは、信頼できないドメインをリストから削除する方法について説明します。
すべてのメール ドメインを確認する
メール ドメインは、移行アシスタントで直接確認することも、CSV ファイルを使用して確認することもできます。以下は、移行アシスタントの [すべてのドメインを確認] 画面のサンプルです。
一括アクション: ドメインの数が多い場合は、CSV ファイルを使用してドメインを一括アップデートできます。*これは Bitbucket Cloud では使用できません。
検索とフィルタリング: 特定のドメインを検索したり、列名を選択して順序を変更したり、決定のステータスでフィルタリングしたりできます。これは、レビューが必要なドメインを見つけるのに役立ちます。
ドメイン: このリストには、ユーザー ディレクトリにあるすべてのドメインと、各ドメインのユーザー数、選択された決定、特定のドメインに必要なアクションなどの詳細が含まれます。
目標は、すべてのメール ドメインを信頼済みとしてマークすることです。信頼できないドメインがある場合は、リストから削除する必要があります。信頼できないとマークするだけでは移行できません。
移行アシスタントを使用してメール ドメインを確認する
メール ドメインは Jira と Confluence の移行アシスタントで確認できます。
メール ドメインを確認する方法は以下のとおりです。
Jira または Confluence の移行アシスタントを開きます。
[すべてのメール ドメインを確認する] 画面にアクセスします。
初めての移行の場合は、ホーム画面で [すべてのメール ドメインを確認する] カード を選択してください。
2 回目以降の移行の場合は、移行ダッシュボードから移行を作成または実行してください。メール ドメインを確認するよう求めるメッセージが表示され、ここで [すべてのメール ドメインを確認する] を選択できます。
メッセージが表示されたら、クラウド サイトに接続します。このステップは、ユーザーに関する正確な情報を表示するために必要です。
ユーザー ディレクトリからドメインを見つけて評価するには、[評価を開始] を選択します。
評価が完了したら、各メール ドメインをレビューして、次のいずれかの選択肢をマークします。
稟議書 | この決断をする条件 | 必要なアクション |
|---|---|---|
信頼済みドメイン | このドメインが信頼済みであり、権限のないユーザーがいないことを確認している場合 | 移行を続行できます。 |
信頼していないドメイン |
| これらのドメインのユーザーを変更して、他のドメインにメール アドレスを更新するか、これらのユーザーを削除する必要があります。 |
No decision made | そのドメインが信頼できるかどうか分からない場合 | ドメインが信頼できるかどうかを確認する必要があります。ドメインの確認後、信頼済みドメインとしてマークすると移行を続行できます。 |
すべてのドメインを信頼済みとしてマークしたら、[完了] を選択してドメインの確認を完了します。信頼できないドメインがある場合、そのドメインをリストから削除する方法については、以下をお読みください。
CSV ファイルを使用してメール ドメインを確認する
CSV ファイルを使用して、メール ドメインを一括で確認することもできます。これは、ドメインの数が多い場合に便利です。Assistant で直接行った変更は、ファイルに反映されます。同様に、ファイルをアップロードし直した後でも、さらに変更を加えることができます。*これは Bitbucket Cloud では使用できません。
CSV ファイルを使用するには、次の手順を実行します。
[すべてのメール ドメインを確認する] 画面にアクセスします。詳細な手順については、上記のセクションを参照してください。
[CSV ファイルをダウンロード] を選択します。
ファイルを編集して、各ドメインに決定のマークを付けます。ファイルの詳細は次のとおりです。
CSV ファイルには、ユーザー ディレクトリにあるすべてのメール ドメインが含まれます。
各ドメインの決定は変更できますが、ドメインの追加や削除はできません。
値は、NO_DECISION_MADE、NOT_TRUSTED、TRUSTED のいずれかです。
準備ができたら、CSV ファイルをアップロードして戻します。ファイルの決定が Assistant に反映されます。
すべてのドメインが信頼済みとしてマークされたら、[完了] を選択してドメイン レビューを完了します。信頼できないドメインがある場合、そのドメインをリストから削除する方法については、以下をお読みください。
回避策: すべてのドメインを一括で信頼してクリアする
ドメインを一括で確認して信頼するには、CSV ファイルを使用することをお勧めします。疑わしいドメインがないことが絶対に確実な場合にのみ、この回避策を自己責任で使用してください。
どうしてもすべてのドメインを信頼済みのドメインとして選択するか、すべての選択を解除する必要がある場合は、ブラウザー バーで以下のURLを使用できます。今一度、上記の警告をご確認ください。
すべてのドメインを信頼済みとして選択する場合
1
<Base-URL>/rest/migration/latest/debug/email/trust-all-domainsすべての選択を解除する場合
1
<Base-URL>/rest/migration/latest/debug/email/remove-all-domain-rules信頼されていないドメインを削除する方法
すべてのメール ドメインを信頼しない限り、移行はできません。
メール ドメインが信頼できない場合は、Server またはData Center インスタンスでそのドメインのユーザーを確認し、削除するか、メール アドレスを他のドメインに変更する必要があります。それが完了すると、ドメインはリストに表示されなくなります。
次のいずれかの方法でユーザーの詳細を変更して、移行を実行できるようにします。
Jira と Confluence Server または Data Center のユーザー管理ツール
外部ディレクトリからユーザーを変更する
管理ツールを利用してユーザーを変更する
サーバーまたは Data Center 製品の既存のユーザー管理ツールを使い、信頼しないドメインのすべてのユーザーを確認します。これを行うには、信頼しないドメインで検索し、ユーザーを変更、無効化、または削除します。
[管理 ] > [ユーザー管理] を選択します。
次の [ユーザー] 画面で、信頼しないドメインを検索します。
表示される一覧で、変更するユーザーを選択します。
メール アドレスやユーザー名などのユーザーの詳細情報を編集します。
外部ディレクトリでユーザーを変更する
次のいずれかのアプローチを利用して外部ディレクトリのユーザーを変更します。
信頼しないドメインのユーザーのメール アドレスを、信頼できるドメインのアドレスに変更する
信頼しないドメインのメール アドレスのユーザーを削除する
信頼しないドメインのユーザーのメール アドレスを、信頼できるドメインのアドレスに変更する
必要なアクション | ユーザーの元の場所を見つけ、メール アドレスを変更します。場所には、LDAP、Crowd、または Jira が考えられます。 |
|---|---|
結果 | ユーザーのデータ所有権や、製品内でのユーザー アクションの追跡への変更はありません。 |
どうすればいいですか? | Jira については、「ユーザーの編集」をご参照ください。 Confluence については、「ユーザーの詳細情報の編集」をご参照ください。 Bitbucket については、「ユーザーとグループ」をご覧ください。 |
信頼しないドメインのメール アドレスのユーザーを削除する
Jira |
|
|---|---|
必要なアクション | ユーザーの元の場所を見つけてユーザーを削除します。場所には、LDAP または Crowd が考えられます。 |
結果 | ユーザーを削除すると、そのユーザーが所有しているフィルターやダッシュボードも削除されます。これは、対象のフィルターやダッシュボードが他のユーザーと共有されている場合でも同様です。 ユーザーを削除する前に次の点をご確認ください。
|
どうすればいいですか? | 「ユーザーの削除」をご参照ください。 |
Confluence |
|
|---|---|
必要なアクション | ユーザーの元の場所を見つけてユーザーを削除します。場所には、LDAP、Crowd、または Jira が考えられます。 |
結果 | クラウドの製品内で、ユーザーによるデータの所有権やアクションを追跡することはできなくなります。 外部ディレクトリでユーザーを削除 (かつ同期) した場合、そのユーザーは Jira で無効化されます。無効化されたユーザーはクラウドで有効化され、サイト アクセスは持ちますが製品アクセスは持ちません。 |
どうすればいいですか? | 「ユーザーの削除または無効化」をご参照ください。 |
Bitbucket |
|
|---|---|
必要なアクション | Bitbucket の内部ユーザー ディレクトリや、LDAP、Crowd または Jira Software などの Bitbucket のユーザー ソースになる外部ディレクトリから、ユーザーやグループを削除できます。 |
結果 | これらのディレクトリからユーザーまたはグループが削除されると、Bitbucket はそのユーザーが別のディレクトリ内にまだ存在するかどうかを確認します。
ユーザーを削除する前に次の点をご確認ください。 外部ディレクトリ (例: JIRA または LDAP) からのユーザー、または (内部ディレクトリからの) 内部ユーザーの場合、ユーザーまたはグループは 7 日間保持されます。 これには以下が含まれます。
|
どうすればいいですか? | 「ユーザーおよびグループの削除」をご覧ください。 |
Cloud への移行後にメール ドメインを確認する方法
信頼されていないドメインのメール アドレスをクラウドに移行済みの場合は、次のいずれかを実行できます。
ユーザーの停止。これにより、ID は維持されますが、アクセスはブロックされます。
ユーザーの削除。削除されたユーザーへの参照はすべて、旧ユーザーとして表示されます。
高度: データベース クエリ
次の SQL クエリを使用して、信頼できるとマークしたすべてのドメインからユーザーの数と詳細に関する情報を取得できます。
クエリは PostgreSQL 用です。他のデータベースでは調整する必要があるかもしれません。
クエリには Jira Service Management の顧客は含まれず、一般ユーザーのみが含まれます。
信頼されているドメインのユーザー数
1
2
3
4
5
6
7
8
9
select right(cwd_user.email_address, Strpos(Reverse(cwd_user.email_address), '@') - 1) as email_domain_cwd
, td."DOMAIN_NAME" as email_domain_from_trusted_list
, td."RULE" as decision_for_domain
, count(*)
from cwd_user
inner join cwd_directory cd on cd.id = cwd_user.directory_id
left join "AO_6FF49D_EMAIL_TRST_DMN" td on td."DOMAIN_NAME" = RIGHT(cwd_user.email_address, Strpos(Reverse(cwd_user.email_address), '@') - 1)
group BY 1, 2, 3
order BY 4 desc;信頼されているドメインのユーザーの詳細
1
2
3
4
5
6
7
8
9
select c.email_address as email
, c.active as user_status
, right(c.email_address, Strpos(Reverse(c.email_address), '@') - 1) as email_domain_cwd
, td."DOMAIN_NAME" as email_domain_from_trusted_list
, td."RULE" as decision_for_domain
from cwd_user c
inner join cwd_directory cd on cd.id = c.directory_id
left join "AO_6FF49D_EMAIL_TRST_DMN" td on td."DOMAIN_NAME" = RIGHT(c.email_address, Strpos(Reverse(c.email_address), '@') - 1)
order BY 4 desc;次のステップ
準備ができたら、重複するグループを確認して、それらが引き起こす可能性のある問題と、問題を軽減する方法をご確認ください。重複するグループ名を解決する方法
この内容はお役に立ちましたか?
さらにヘルプが必要ですか?
アトラシアン コミュニティをご利用ください。