このトピックでは、アップグレード プロセスがカスタマイズされたページにどのように影響するかについて説明し、Microsoft Office SharePoint Designer 2007 を使用して カスタマイズをやり直す、またはカスタマイズを転送するなど の必要な変更を行う方法を示します。
メモ Microsoft Windows SharePoint Services 3.0 または Microsoft Office SharePoint Server 2007 へのアップグレードを扱う IT 担当者またはサーバー管理者の方は、「参照」セクションにある詳細と総合的な情報へのリンクを参照してください。
このトピックの内容
アップグレードの種類
ユーザー設定の SharePoint サイトの作成に時間を費やしているのであれば、次バージョンへのアップグレード計画は刺激的である一方困難でもあります。新しい機能は必要だと思われますが、アップグレードが現在のカスタマイズにどのような影響を及ぼすのか不安になるかもしれません。このセクションでは、選択可能な 2 種類のアップグレード (一括と順次) について説明した後、両タイプのアップグレードがカスタマイズされたサイトに及ぼすと予測される影響を特定します。
一括アップグレードを選択する状況
一括アップグレードでは、既存のデータベースとサーバーをアップグレードする方法で、システム全体を一度にアップグレードします。このアプローチは、共有サービスを配備していない、またカスタマイズが多く行われていないシングル サーバーまたはスモール サーバー ファームに最も適しています。サイトの URL はアップグレード後も変わりません。一括アップグレードはオフラインの環境で実行する必要があります。元のバージョンは新しいバージョンにより上書きされるため、アップグレード後の環境を以前の状態に戻すことはできません。以前の状態で行ったカスタマイズをアップグレード後のサイトで再現する場合、参照できる以前のバージョンのサイトが存在しないため、メモや記憶を頼りに行うしかありません。
順次アップグレードを選択する状況
順次アップグレードでは、環境全体を一度にアップグレードするのではなく、既存のサーバーで個別に収集されたサイト コレクションをアップグレードします。共有サービスを配備していない中規模から大規模なサーバー ファームを運用している場合、サイトに多くのカスタマイズを行っている場合、またはアップグレードの間、環境全体を停止する余裕がない場合に適したアプローチです。このオプションは、データのアップグレードの前にデータが元のデータベースから新しいデータベースにコピーされているので、必要に応じて元のサイトに戻すことができます。元のデータベースは、サーバー管理者が明確に削除するまで維持されます。順次アップグレードは、多くのカスタマイズを行っているサイトに適したオプションです。サイト開発者は新しい状態でカスタマイズを再現する場合、以前の状態を参照しながら作業を進めることができます。
ページの先頭へ
カスタマイズの方法を決定する
(Microsoft Office FrontPage などを使用して) SharePoint サイトを大規模にカスタマイズしている場合、カスタマイズされたサイトのアップグレード後の扱い方を決定する必要があります。採用するアプローチは、カスタマイズの規模、サイトの複雑さ、アップグレードの目標によりさまざまです。通常、カスタマイズされるページには、次のような種類があります。
- カスタマイズされたページ 最初はサイト定義に基づいて生成され、その後で変更されたページです。たとえば、FrontPage で SharePoint サイトを開き、文字または図をホーム ページに追加している場合、そのホーム ページはカスタマイズされています。
- カスタマイズされていないページ 最初はサイト定義に基づいて生成され、後で変更されていないページです。(サイトに新しいテーマを適用したことがあり、これによってサイトの外観と書式が変更されている場合でも、FrontPage のような互換性のある Web サイト エディタを使用して特定のページのコンテンツを変更していなければ、そのページはカスタマイズされていないと見なされます。)
- 新しいページ 最初からサイト定義に基づいて生成されていないページです。たとえば、Web デザイナはサイトのグラフィック デザインを受け取ると、多くの場合、まず空白のページを開き、グラフィック デザイナの図を追加して外観を構築し、最後に Web パーツを必要に応じて挿入するという流れで作業を進めます。このようなページはサイト定義と関連性を持ちません。
カスタマイズは次の方法のいずれかで処理します。
- カスタマイズを維持する これには 3 つの方法があります。
- カスタマイズを破棄する 次のいずれかの操作を行います。
- カスタマイズをやり直す 次のいずれかの操作を行います。
- 一括アップグレードを実行し、サイト定義にページをリセットしない。既定では、一括アップグレードではカスタマイズが維持され、ページがサイト定義のバージョンにリセットされません。アップグレードの後、サイトを開き、カスタマイズをコピーし (Office SharePoint Designer 2007 を使用)、その後でサイト定義にリセットし、最後にカスタマイズを新しい機能とカスタマイズの両方に再度適用します。
- 順次アップグレードを実行し、その後、アップグレードされたサイトで、カスタマイズされたページをサイト定義にリセットする。サイトに、Office SharePoint Designer 2007 を使用してカスタマイズを元のサイトから新しいサイトに転送する。
メモ
- 一括アップグレードを実行する場合、アップグレードでは以前のバージョンのサイトは維持されません。サイトの古いバージョンと新しいバージョンを両方保存し、Microsoft Windows SharePoint Services 2.0 サイトから Windows SharePoint Services 3.0 サイトにカスタマイズを転送できるようにする場合、順次アップグレードを使用します。または、一括アップグレードを使用する場合は、必ず複製サーバーまたはサーバー ファームで古いバージョンが実行されている必要があります。
- この場合も、サイト定義と同等ではない真のカスタム ページには、サイト定義へのリセットは効果がありません。
ページの先頭へ
アップグレードの前 : 潜在的な問題を特定する
アップグレード プロセスを開始する前に、やり直しが必要になるカスタマイズの数、また予想どおりにアップグレードされないサイトについておおよそのデータを把握しておくことが重要です。次の手順では、アップグレード プロセスの間に発生すると予測される問題を特定し、プロセスの後で適切に対処する方法について示しています
- サーバーでアップグレード前のスキャン ツールを実行し、カスタム サイトまたはカスタマイズされたページ (適宜) を特定します。
カスタマイズされたサイトとページを効率的に特定するために、アップグレード前のスキャン ツールを実行する必要があります。たとえば、カスタマイズされたサイト テンプレートやカスタマイズされた Web パーツなどの問題は、アップグレードをスケジューリングする前に適切なサイトの所有者、設計者、開発者に報告し、問題を調査し準備作業を行う時間を与える必要があります。開発者は大幅にカスタマイズされた Web パーツを再構築することが賢明であるか、アップグレードを実行する前に決定できます。また、アップグレードの終了後に必要に応じて再構築できるように、サイト テンプレートや default.aspx ファイルの変更内容など、サイトへのカスタマイズを記録した方がよい場合もあります。
- 環境にどの問題が当てはまるかを確認する場合は、次のセクションで一覧にした共通の問題を参照してください (推奨、ただしオプション)。
次のセクションのリストでは、現在の環境で発生する可能性のある共通の問題をすばやく見つけることができます。またアップグレードの終了後に、問題に対処する方法について説明しています。
- バックアップ サイトまたは複製された (読み取り専用) サイトを使用して、トライアル アップグレードを実行します (推奨、ただしオプション)。
この方法は予測される問題を特定するのに最も適しています。アップグレード プロセス全体をプレビューし、問題を見つけ、アップグレードを開始する前に問題に対処できます。少なくとも、どのような状況が予想されるかを把握することができます。トライアルを実行する場合、多くの時間とハードウェアが必要となります。ただし、そのようなリソースに投資できる場合、実際のアップグレード プロセスは非常に容易になります。
ページの先頭へ
アップグレードの後 : カスタマイズをやり直すまたは転送する
テスト アップグレードを実行している場合、またはアップグレード前のスキャン ツールを実行している場合、次の共通の問題がサイトに 1 つまたは複数見つかる場合があります。このような問題が見つかるサイトが複数ある場合、順次アップグレードを実行することをお勧めします。影響を受けるサイトの元のバージョンと新しいバージョンをいずれも利用できたり、また、元のサイトに戻したり、新しいバージョンを有効にする前に新しいサイトを更新することができるからです。一括アップグレードを使用する必要がある場合は、アップグレードを実行する前に、必ずサイトのバックアップを作成するようにしてください。サイトのバックアップの詳細については、「SharePoint サイトをバックアップ、復元、または移動する」を参照してください。
SharePoint サイトを Windows SharePoint Services 3.0 にアップグレードする場合、次のような問題が 1 つまたは複数発生する場合があります。
-
カスタマイズされたページの外観が変更される サイトのホーム ページ、またはサイトの他のページが、サイトのアップグレード前と違って表示される場合があります。たとえば、Windows SharePoint Services 2.0 のテーマは、サイトのフォントと書式を制御する業界標準のカスケード スタイル シートのコレクションでした。Windows SharePoint Services 3.0 と Office SharePoint Designer 2007 では、更新された各テーマが 1 つのカスケード スタイル シートに結合され、このカスケード スタイル シートにもさらにスタイルと更新されたスタイルが収められています。アップグレード後、Windows SharePoint Services 2.0 のテーマのサイトのスタイル シートは、アップグレードされたサイトに継承されますが、既定のテーマは Windows SharePoint Services 3.0 の既定テーマに変更されます。Windows SharePoint Services 2.0 のテーマはスタイルが更新されておらず、新しいスタイルのクラスも割り当てられていないため、テーマを更新して Windows SharePoint Services 3.0 サイトへの適用が正しく行われるようにする必要があります。または、テーマを更新しない場合、希望する外観の Windows SharePoint Services 3.0 のテーマを適用することができます。
さらに、サイト設計者はサイトのカスタマイズされたページ以外に、新しい SharePoint リストまたはライブラリを作成したときに生成される既定ページについても、外観を制御できる新しいマスタ ページを実装することができます。たとえば、Windows SharePoint Services 2.0 サイトが現在ダイナミック Web テンプレートを使用して、ページに一貫した外観と書式を適用している場合、ダイナミック Web テンプレートはサイトの特定のページにのみ適用されます。Office SharePoint Designer 2007 では、既定のマスタをカスタマイズすることも、カスタム マスタ ページを作成し、ここにページを適用することもできます。
- ダイナミック Web テンプレートをマスタ ページと置き換える必要がある 現在、ダイナミック Web テンプレート (DWT) を使用して編集可能な領域を定義し、ページの外観を設定している場合、Windows SharePoint Services 3.0 で引き続き DWT を使用できます。ただし、マスタ ページは適用された個々のページ以外に、SharePoint の既定ページ ([サイトの設定] ページと [ドキュメントとリスト] ページなど)、および新しいページの書式も制御するため、ダイナミック Web テンプレートをマスタ ページに置き換える方を選択してもかまいません。また、マスタ ページを使用する場合、適用されたページでユーザーが変更できるコンテンツ領域グループを指定できます。詳細については、「ASP.NET マスタ ページの概要」を参照してください。
- FrontPage を使用してページに行ったカスタマイズは維持されるが、SharePoint の新しい機能は失われる SharePoint の新しい機能 ([ごみ箱] やサブサイトにリンクされる水平タブなど) を、カスタマイズされたページに追加する必要が生じる場合があります。この場合、カスタマイズされたページをサイト定義にリセットし、その後で、カスタマイズを各ページに再度適用します。このオプションの詳細については、「カスタマイズしたページをサイト定義にリセットする」を参照してください。
- ハードコーディングされた URL の Web サービスが正しく機能しない データ ソース ライブラリでデータ ソースとして追加した Web サービスは、新しい URL 方式と新しい機能が使用されるように、再構成が必要になる場合があります。たとえば、順次アップグレードの実行中、サーバーの URL は一定の期間、一時サーバーにリダイレクトされます。この期間、アップグレードが行われているサーバーへのリンクは壊れている可能性があります。
- カスタマイズされたサイト定義が正しく機能しない サイトが大幅にカスタマイズされたサイト定義を基準にしている場合、アップグレードの前にサイト定義を新しく作成し、その後、アップグレード プロセスで元のサイト定義要素を新しいサイト定義にマップするためのマッピング ファイルを作成することをお勧めしています。また、カスタム ドキュメントの種類、ファイルの種類、または編集アプリケーションをサイト定義に登録している場合、これらのカスタマイズを新しいサイト定義に再度適用する必要があります。
- 開いたり表示できなくなるファイルがある
拡張子が .asmx、.rem、.resx、.soap、または .ashx のファイルは、アップグレード後、表示したり、開いたりできなくなります。これらのファイルの拡張子は、ブロックされるファイル拡張子のリストに追加されています。上記の拡張子を持つファイルのアップロードまたはダウンロードをユーザーに許可する場合は、リストから該当する拡張子のエントリを削除します。
- [Outlook に同期] がビュー ページに表示されない
ビュー ページで、このコントロールのような新しいユーザー インターフェイス コントロールを取得する場合は、ページをサイト定義にリセットする必要があります。このオプションの詳細については、「カスタマイズしたページをサイト定義にリセットする」を参照してください。
- [ようこそ] ページが default.aspx にリセットされている
[ようこそ] ページの取り扱い方法は、新しいバージョンで変更されています。サイトを現在のサイトの外部 (外部 URL など) に存在する [ようこそ] ページに設定している場合、アップグレードの間に、[ようこそ] ページが default.aspx にリセットされます。アップグレード後、ナビゲーションを変更して外部 URL を追加するか、リダイレクト ページで default.aspx を外部 URL にリダイレクトします。
- 新しいページは、サイト定義にリセットできません。 サイトにまったく新しいページを追加している場合 (たとえば、既存の default.aspx ファイルを変更するのではなく、default.aspx を完全に異なるファイルと置き換えている場合など)、新しいページはサイト定義と関連性を持たないため、リセットできません。カスタム ページをサイト内の他のページと同じ外観に設定する場合は、サイト定義に基づいて新しいページを作成し、その新しいページにカスタマイズの内容を転送する方法を検討してください。
- アップグレード プロセスの間、サイトがオフラインになる
サーバー ファームに対して一括アップグレードを実行する場合、アップグレードの間、すべてのサイトがオフラインになります。この間、これらのサイトへのアクセスおよび編集ができなくなるためです。現在の SharePoint 環境が大規模な環境であれば、順次アップグレードでサイトへのアクセスが不可になる時間を最小限に抑えることをお勧めします。それ以外の環境では、アップグレード スケジュールに従ってユーザーに警告し、オフライン時間に合わせて計画できるようにする必要があります。
- Office SharePoint Designer 2007 だけは、アップグレードされたサイトを開いて編集できる
今後、チーム メンバを含むユーザーは、 Microsoft Office FrontPage 2003 を使用して Windows SharePoint Services 3.0 サイトを開き、編集できなくなります。Windows SharePoint Services 3.0 サイトと Office SharePoint Server 2007 サイトを編集およびカスタマイズする場合、Office SharePoint Designer 2007 を使用する必要があります。
- カスタマイズに失敗する場合、ページをサイト定義にリセットできます。 Windows SharePoint Services 2.0 では、ホーム ページをカスタマイズし、その後でサイト定義にリセットする必要が生じた場合、ホーム ページのコピーを保存していなければ、いらいらする状況に陥っていました。Windows SharePoint Services 3.0 では、いつでもカスタマイズしたホーム ページをリセットし、新しいサイト定義を使用できます。したがって、サイトのホーム ページをカスタマイズした後、Windows SharePoint Services 3.0 のホーム ページの新しい外観が気に入った場合、カスタム ホーム ページをリセットし、サイト定義を使用することができます。このオプションの詳細については、「カスタマイズしたページをサイト定義にリセットする」を参照してください。
メモ サイトにまったく新しいページを追加している場合 (たとえば、既存の default.aspx ファイルを変更するのではなく、default.aspx を完全に異なるファイルと置き換えている場合など)、新しいページはサイト定義と関連性を持たないため、リセットできません。カスタム ページをサイト内の他のページと同じ外観に設定する場合は、サイト定義に基づいて新しいページを作成し、その新しいページにカスタマイズの内容を転送する方法を検討してください。
- サイト構造の変更は、URL と権限に影響する Windows SharePoint Services 3.0 でサイト構造が変更されたため、SharePoint リスト内またはライブラリのハイパーリンク フィールド内のハードコーディングされた URL の一部は、アップグレードの間に変更される場合があります。たとえば、Microsoft Office SharePoint Portal Server 領域のパスに /C2/ または /C16/ が含まれる場合、代わりに /sites/ をパスで使用できます。このような場合、リンクが存在する Web パーツを探し、新しい場所を示すようにリンクを更新する必要があります。
ページの先頭へ
日本
印刷用ページの表示
共有
