SHAREPOINT2 0 1 6導入準備完全ガイド

目 次

はじめに

移行準備: SharePoint 2016 インストール要件

SharePoint 2016 への移行とアップグレード

SharePoint 2016 へのアップグレード方法

SharePoint 2016 への移行方法

SharePoint / ファイル サーバー連携

付録 A:表

会社概要

2

3

3

4

7

10

18

11

はじめに

2

2001 年に Project Tahoe として産声を上げた SharePoint は、2003、2007 (MOSS)、2010、2013 とバージョンを重ね、エンタープライズ向けコラボレーション プラットフォームとしての地位を確立しています。

そして今年、いよいよ最新バージョンである SharePoint 2016 が発売となりました。例えば OneDrive for Business との連携強化やデータ損失防止 (DLP) 機能の向上、そして2,047 MB以上のサイズのファイル アップロード/ダウンロードが可能になる など、米国では既に市場の大きな話題となっています。SharePoint 2016 が、これまでのバージョンの機能をさらに便利に進化させた強力なツールとして、組織の運営を支える屋台骨となる強力なパワーを秘めていることには余地がありません。

しかし、「最新版だからきっと良いに違いない」「他社が入れるようなら我が社にも」 などの安易な理由により、よく考え抜かないまま開始された移行プロジェクトは、ほぼ必ず失敗に終わります。

特に 「Office 365 / SharePoint Online と SharePoint Server との切り分けをどうするか」 という課題をきちんとクリアしないまま SharePoint 2016 に移行してしまえば、組織に無用な混乱を招き、深刻な生産性の低下を引き起こす恐れさえあります。

また、単に 「移行」 といっても、既存のコンテンツを全て新環境に投げ込むだけでは、せっかくの SharePoint がすぐに 「ゴミ箱化」 してしまいます。移行を機に、レガシー システムのコンテンツをアーカイブ・削除するなど、SharePoint を最適な状態で使い続けられる工夫が是非とも欲しいところです。

SharePoint 2016 の長所を最大限に引き出し、組織にマッチした運用管理を実現するためには、移行の計画段階から移行先プラットフォームの仕様や長所はもちろんのこと、「どの機能をどのように使っていくか」 などの組織のニーズをしっかりと把握し、綿密なプランを立てて臨む必要があります。

本ドキュメントは、SharePoint 2016 の導入を検討中の企業・組織に向け、2001 年の発売当初から SharePoint と並走してきた AvePoint が考える 「SharePoint 2016 への移行・導入前に是非検討しておくべきこと・知っておきたいこと」 をまとめたガイドです。移行計画づくりや検討材料にご活用いただければ幸いです。

SharePoint 2007/2010 など、SharePoint 2013 以前のバージョンを使用中である場合、SharePoint 2016 への移行には、ハードウェア・OS・データベースのアップデートも同時に実行する必要がある場合があります。移行の準備・実行前に、各要件を以下で確認しておきましょう。

SharePoint 2016 のデータベース サーバーは、 Microsoft SQL Server 2014 および Microsoft SQL Server 2016 がインストールされている 64 ビット バージョンで使用可能です。

これは、 現在 SQL Server 2008 R2 および SQL Server 2012 で SharePoint 2013 を使用している場合は、 SharePoint 2016 へのアップグレード前に、 データベース サーバーを SQL Server 2012/2014 にアップグレードする必要があるということを意味します。

ただし、 SharePoint 2016 ファームを作成する必要があることを考慮すると、 レガシー データベースをアップグレードするよりも、 新規データベース サーバーを立てたほうが効率がよいといえます。SharePoint 2016 を小規模環境で使用する場合、Web フロント

エンドおよびアプリケーション サーバーの最小要求サイズは RAM 12-16 GB と 4 件の 64 ビット コアとなります。

しかし最小のサイズでは、実環境での使用に耐えられないケースも散見されるため、少なくとも 16 - 24 GB の RAM を用意することを推奨します。 また、中規模以上の環境では、CPU コアを 8 件に増設することを推奨します。

SharePoint 2016 では、ストレッチド ファーム形式のアーキテクチャ デザインが使用可能です。高可用性ソリューションとして動作させるには、以下の要件を充たす必要があります。

ハードウェア要件

移行準備: SharePoint 2016

インストール要件

SharePoint 2016 は、64 ビットの Windows Server 2012 R2 もしくは Windows Server 2016 テクニカル プレビュー版で動作します。.NET フレームワークの最小要件は、Windows Server 2012 R2 で 4.5.2、Windows Server 2016 テクニカル プレビュー版で 4.6 です。

注意: 2016 年 1 月 13 日以降、使用可能な .NET フレームワークのバージョンは 4.5.2、および以降のバージョンのみとなります。

ハードウェア要件

ファーム間待機時間が片道 1 ms 未満の状態が、10 分間のうち 99.9% 維持できること: ファーム間待機時間は、一般的にはフロント エンド サーバーと Web サーバー、データベース サーバーの間で定義されます。

帯域速度が最低でも 1 ギガビット / 1 秒であること

SharePoint 2016 では、 MinRole という新機能が導入されました。 Minrole は、 ファームの要件に応じ、 適切なインフラストラクチャとロール ( 役割 ) を展開する機能です。

SharePoint 2016 サーバーの機能を定義し、 必要なコンポーネントだけをインストールすることができるため、 最適なパフォーマンスの維持が可能になります。 また、 各ロールのサーバーが使用に適しているかどうかのチェックも可能になります。

各サーバー ロールと機能については、付録 A の 表: 3 をご覧ください。

MOSS 2007、 SharePoint 2010/2013 などを使用している組織では、 「移行」 と 「アップグレード」 のどちらを実行するのかを決定する必要があります。

アップグレードの場合は、 Microsoft から出ているアップグレード ツールを利用しますが、 移行ではサード パーティ ベンダーのツールを使用する必要があります。

しかし、 アップグレードと移行のどちらを実行するかの決定には、 多方面からの慎重な検討が必要となります。 まず、 「SharePoint 2016 を何のために導入するのか」 を改めて考えることが必要です。導入の目標によって、 必要となる SharePoint 2016 の物理的アーキテクチャ ・ 情報アーキテクチャは大きく変化します。

データベース要件

導入シナリオ

SharePoint 2016 への移行とアップグレード

3

レガシー システムからの SharePoint 2016 への移行については、次章移行で解説します。本章では、既定で使用できるアップグレード方法について説明します。

SharePoint 2016 への移行の際に使用できるアップグレードの方法は、現在使用している SharePoint のバージョンによって異なります。

繰り返しとなりますが、SharePoint 間であってもバージョンを飛ばした移行 (2007 から 2016 など) は不可であることに留意してください。

既存のコンテンツ データベースを SharePoint 2013 から 「デタッチ」 し、2016 に 「アタッチ」 するという方法です。アタッチされたコンテンツ データベースはアップグレードされ、データベースの内容が 2016 で利用できるようになります。

データベースのアタッチ (既定のアップグレード方法)

例えば、 「現在 SharePoint 2010 のチーム サイトを部門別のコラボレーション プラットフォームとして使用しているが、 2016 の導入をきっかけに、 コンテンツ管理とアプリケーション開発のプラットフォームとしても使用したい」 というニーズを持った組織であれば、 新規ニーズを念頭に置きながら現行のアーキテクチャを再検討し、 スケールアップで新しいニーズに対応できるかどうかを見極める必要があります。

SharePoint の再構成 ・ 再構築が目的である場合は、 最小単位移行が可能になるツールを導入することにより、 移行と同時に再構築を実行することや、 コンテンツを移行先の情報アーキテクチャに正確に移行することが可能になるため、 組織のニーズにより合致した方法での移行と再構築を効率よく実行することができます。

この際、 注意したいポイントは以下のとおりです。

SharePoint 2016 では、インプレース移行および段階的アップグレードは使用できない: インプレース アップグレードを使用しており、かつ Microsoft の規定のアップグレード機能を使用したい場合は、すべてのバック エンド・フロント エンド機能が SharePoint 2013 までアップグレードされている必要があります。

Microsoft から提供されているアップグレード機能では、バージョンを飛ばして移行することはできない: SharePoint 2007/2010、もしくはそれ以前のバージョンを使用している場合は、まず SharePoint 2013 までのアップグレードを実行し、そこから 2016 にアップグレードする必要があります。

SharePoint 2016 へのアップグレード方法

この方法は、SharePoint 2013 でのみ利用可能です。正確には、SharePoint 2013 環境、かつデータベース バージョンが 15.0.4481.1005 以降であるもののみ対応しています。

また、アタッチされる各データベースのサイト コレクションは Share-Point 2013 モード (互換レベル 15) である必要があります。

データベース アタッチを検討している場合は、以下の点に留意してください。

新規ファームをビルドする必要があります。使用しているカスタム コードやサード パーティ ソリューションは、新規ファームに適用が必要となります。

データベース アタッチでは、壊れたり孤立したりしたサイト コレクション / サイトを修復することはできません。

SharePoint の前バージョンからのアップグレードのみが実行可能となります。

アップグレードは、データベースごとの作業となります。個別のサイトやサイト コレクションのみをアップグレードすることはできません。

使用しているサーバー、特に SQL サーバーによっては、同時に複数のデータベースをアップグレードすることが可能である場合もあります。このプロセスはパラレル データベース アップグレードと呼ばれています。

SharePoint 2013 や SharePoint 2016 へのアップグレードには、PowerShell を使用し、Mount- SPContentDatabase コマンドレットを実行することになります。

アップグレードが成功したかどうかの確認には、Test-SPContent-Database コマンドレットが使用できます。 このプロセスでは、移行元のデータベースには変更は行われず、データベースが新規ファームと互換性があるかに関するレポートを作成するだけとなります。

移行元・移行先ファームの間で発生するダウンタイムを最小限に抑えるため、移行元ファームを 「読み取り専用」 に設定することも一般的です。これにより、ユーザーは移行元ファームのコンテンツを、アップグレードの途中でも読み取ることができます。この操作は、SQL Server Management Studio のデータベース レベル、もしくは 「サーバーの全体管理」 を使っているサイト コレクション レベルで実行できますが、データベースの各サイト コレクションは 「読み取り専用」 に設定しておく必要があります。

4

フォーム ベース認証を使用して環境のアップグレードを実行する

クラシックの認証からクレーム ベースの認証へ移行する

SQL Server が 2014 以前のバージョンであるか、SQL Express であるか、スタンドアロンの SharePoint である場合は、最小データベース要求の求めるサイズにアップグレードする必要がある

カスタム マスター ページや CSS などの大規模なカスタマイズ、もしくはカスタム コードを使用した環境をアップグレードする

SharePoint 2013 14.5 サイト コレクションで、SharePoint 2010 モードで使用しているものがある (2013 へのアップグレードが必要となります)これらの SharePoint 2013 サイトは、直接 2016 に移行するか、データベース アタッチ メソッドを使用してアップグレードすることが可能です。

SharePoint データベース全体のサイズ

ハードウェア (特にデータベース サーバー)

アップグレードの前に必要な作業 (ヘルス チェック、クリーンアップ、バックアップ)

アップグレードの完了後に必要な作業 (サイトの検証、サービス アプリケーションの作成、ひとの検索やクロール、サイト コレクションのアップグレード、エンド ユーザー向けトレーニング、新機能の活用方法など)

システムのダウンタイムの周知、およびエンド ユーザーとの折衝

サイト コレクションのアップグレード

前述したように、 すべてのサイトは、 SharePoint 2013 Server データベースを SharePoint Server 2016 ファームにマウントする前に、2013 にアップグレードされている必要があります。 アップグレードが完了していれば、 SharePoint Server 2016 へのアップグレードは、 既存の 15 モード サイトから、 複雑な操作の必要なく完了するはずです。

互換モードは存在せず、 検証サイト作成やテストは必要ないため、使用中の SharePoint 2016 サイト コレクションは、 必ず最新版になっている必要があります。 最新バージョンの常時使用は必須です。

サイト コレクションのアップグレード方法については、章末の表を参照してください。

アップグレードの際に検討すべきポイント

この章の前半で説明した、旧バージョンの SharePoint から SharePoint 2016 への移行は、ハードウェア・OS・データベースがすべて最新バージョンに更新されており、Microsoft の最新版プラットフォーム リリースに対応できるという仮定を前提としています。

まだ完了していない場合は、そちらを優先して実行されることを強く推奨します。

「以前の構成内容はどのようなものか」「構成内容が SharePoint 2016 でも使用可能かどうか」 により、追加の操作が必要となる場合もあります。以下はその例です。

また、どのアップグレード方法を使用するか決定する前に把握しておきたいデータや、時間的・スペース的な制約も存在します。

また、アップグレードの期間中は、データベース トランザクション ログのサイズが非常に大きくなります。 この問題を抑制するため、アップグレード中はデータベース リカバリー レベルを 「単純」 に設定し、完了後に 「完全」 に変更することを推奨します。

この操作は、SQL Server Management Studio で実行可能です。

5

手動トリガー (B2B アップグレードのの規定)

データベース アップグレード (V2V アップグレードの規定)

ファースト ブラウズ (データベース アップグレード後)

Mount-SPContentDatabase コマンドレットを使用してデータべースをアップグレード

Upgrade-SPContentDatabase コマンドレットを使用してサイト コレクションをアップグレード

サイトのアップグレードを遅らせたい場合は、SkipSiteUpgrade パラメーターが使用可能

サイト数が少ないデータベース、いま持っているサイトのほとんどを使用している企業に最適

アップグレードが必要なサイトは、データベースのアップグレード後、最初に閲覧された際にアップグレードされる

ほとんどのサイト コレクションは、数秒から数分でアップグレードが完了する (速度はサイズと複雑性によって異なる)

検証期間中は、サイトは読み取り専用となる

Upgrade-SPSite コマンドレットを使用してサイト コレクションをアップグレード

サイト数が多いデータベース、いま持っているサイトの一部のみを使用している企業に最適

6

サイト コレクション アップグレード方法

コンテンツを SharePoint 2016 に移動する 2 番目の方法は 移行 です。アップグレードでは、Microsoft の既定アップグレード機能が使用されるのに対し、移行ではそれ以外の方法が使用されます。しかし、どちらの方法も 「SharePoint 2016 にコンテンツを移行する」 という意味では、根本的には同質であるといえます。

レガシー プラットフォームや SharePoint の以前のバージョンから、最新バージョンへの移行には、大きく分けて 手動移行、スクリプト移行、サード パーティ ツールでの移行 の 3 種類の方法が存在します。本章では、これら 3 種類の移行方法について解説していきます。

手動移行では、SharePoint 管理者が SharePoint 2016 を個別のハードウェアにインストールし、新規ファームを作成・構成します。

各ユーザーは、新環境の準備が整ってから、自分の所有しているコンテンツを手動で新環境に移行します。場合によっては、パワー ユーザーやサイトの所有者が大きなデータを手動移行することもあります。

手動移行を使用する場合は、ファーム管理者が移行のタイミングをコントロールすることは困難です。このため、新旧環境を両方維持しなくてはならない期間を算出することも困難となります。

非常に厳しい締め切りを設け、超過した場合の対策を周知して実行しない限り、ダラダラと移行期間が続くことにもなりかねません。

また、ほとんどの場合、ユーザーに対する移行操作のトレーニングを設けることも必要となります。例えば両方のシステムでコンテンツを維持したり、旧環境と整合性を取ったりという作業が要求されるため、エンド ユーザーへの負担が大きくなるのもマイナス ポイントです。

そして、手動移行をよりシンプルに実行するために使用できるツールはほぼ存在しません。ファイルを 1 件ずつ移行することになるため、旧バージョンや監査履歴、メタデータ、アクセス権限は失われてしまうことになります。

手動移行のメリットとデメリット、適している場合などについては、付録 A の 表 4 をご覧ください。

SharePoint 2016 への移行方法

手動移行

スクリプト移行では、開発者が移行に必要なスクリプトを作成し、移行作業そのものは自動で実行されます。SharePoint は数多くの API や PowerShell コマンドレットに対応しているため、スクリプト移行は堅実な方法といえます。

スクリプト移行

また、移行元となるレガシー システムによっては、カスタム スクリプトをシステムに統合し、構成内容やコンテンツのメタデータを保持したまま移行を実行することも可能な場合があります。

しかし、この方法を使いこなすためには、SharePoint 開発 (API か PowerShell スクリプト、可能であれば両方) に対する知識が豊富な開発者がいることが前提条件となります。

加えて、コードはカスタマイズ作成する必要があるため、自動・手動どちらの場合でも、ユーザーや組織全体の要求にこたえるレベルの移行を実行するためには、非常に綿密なテスト・検証が必要となります。

この種類の移行は、開発と検証テストだけで数か月間に加え、スクリプトが確実に動作することが確認できるまでの数回の反復移行も必要となります。このため、予想よりも長い期間がかかるケースが数多くあります。

スクリプト移行のメリットとデメリット、適している場合などについては、付録 A の 表 5 をご覧ください。

この方法では、SharePoint ファームの管理者が SharePoint 2016 を新ハードウェア、もしくは新ファームにインストールします。

エンド ユーザーに移行を丸投げしたり、開発者に自動スクリプト作成を依頼するのではなく、サード パーティが作成した移行用ツールが使用されます。

サード パーティ ツールを利用してレガシー コンテンツ・レポジトリから SharePoint 2016 への移行を実行する場合は、SharePoint の旧バージョンから新バージョンへの移行とほぼ同じ考え方で進めることができます。

移行は、おおよそ以下のような手順で進行します。

1. SharePoint 2016 ファームを作成する2. 移行用サード パーティ ツールをインストールする (ツールのベンダーもしくは製品によっては、移行先と移行元の両方にインストールする必要がある場合もある)3. レガシー レポジトリから、アクセス権限・構成・カスタマイズしたコンテンツのマッピングを実行する4. テスト移行を実行する5. コンテンツ・構成内容・アクセス権限が正常に移行されているかの検証を実行する6. 移行の設定を再確認し、再検証を実行する7. 設定されたスケジュールに従い、本番環境に対する移行を反復的に実行する

サード パーティ ツールを使用した移行ソリューション

7

DocAve SharePoint 移行 は、アイテム、サブサイト、サイト レベルで、データを完全忠実な状態のまま新環境に移行するツールです。レガシー コンテンツを、メタデータも含めた状態でマッピング・移行することができます。また、DocAve 移行は、既定の機能では不可能である、SharePoint 2007/2010 から SharePoint 2016 への直接移行にも対応しています。

対応する移行元ソースは以下のとおりです。

移行プロジェクトに DocAve 移行のようなサード パーティ ツールを使用する場合の、各段階での利点については、次のページの表を参照してください。

HTTP/HTTPS でアクセスできる Web コンテンツ

Documentum eRoom (v6.0 以上)

EMC Documentum (v6.5 以上)

Exchange パブリック フォルダ

ファイル システム

Notes/Domino Server (v6.5 以上)

ネットワーク ベースのファイル サーバー

Open Text Livelink (v.9.5 以上)

Open Text Vignette (v.7.2 以前)

Oracle Stellent (v7.x 以上)

8

SharePoint 2016 ファームを作成する

移行プロセス サード パーティ ツール (例: DocAve 移行)

移行用サード パーティ ツールをインストールする

DocAve 移行は、現在使用されているインフラストラクチャを最大活用しながら移行を完了できる Web ベース ツールです。

アクセス権限や構成などを SharePoint 2007/2010/2013 から SharePoint 2016 にマッピングする

移行元 SharePoint 環境から、マッピング先となる SharePoint 2016 のエレメントにコンテンツを自動移行します。

コンテンツに関する重要な情報は保持したまま移行できるため、メタデータや権限も元の環境の状態のまま、使用を継続することが可能です。

フォルダーの構造、ドキュメント プロパティ、関連メタデータ、権限、アクセス制御は、すべて完全忠実に保持されます。

プレスキャン ツールは、禁則文字やユーザー権限、ユーザー名、ユーザー ドメイン、その他移行前にマッピングの必要な要素などのあらゆる情報を検出し、SharePoint 2016 への移行作業をサポートします。

ジョブの構成や管理は、環境全体をカバーする管理コンソールですべて実行することが可能です。Web ベースのため、管理者はいつでも、どこからでもコンソールにアクセスし、移行に関係するタスクを実行することができます。

9

サード パーティ ツール使用の利点

「ファイル サーバーもしくはネットワーク接続ストレージ (NAS) のコンテンツを SharePoint に移行したい」 は、非常によくある移行シナリオのひとつです。

ファイル サーバーからの移行は、前述の方法 3 種類のどれを使用しても実行可能です。しかし、ここで注意したいのは、現在使用されているファイル サーバーは 「ごみ箱化」 しており、不要になったコンテンツや重複したコンテンツでいっぱいになっている可能性が高いという点です。

また、ファイル サーバーから SharePoint へコンテンツを移動する際に問題となりうるのが、SharePoint 内のコンテンツに対して発生する 10GB のサイズ制限です。

もちろん、移行前のコンテンツ検証の段階で 10GB 以上のコンテンツを検出・分類し、必要に応じてアーカイブすることも可能ではあります

ファイル サーバー内で新規アップロード、もしくは作成されるファイルは、SharePoint ライブラリを示す参照ポインターと一緒に保存されます。コネクタでは、ビデオ コンテンツのストリーミングも対象とすることができます。

対して DocAve どきゅなび は、ファイル サーバーに保存したコンテンツに SharePoint を利用してアクセスすることを可能にするツールです (SharePoint Online の場合には、DocAve どきゅなび Online が対応しています)。ただし、バージョン履歴、チェックイン / チェックアウト等、一部対応していない機能も存在することに留意してください。

どきゅなびはフレキシブルなソリューションで、DocAve コネクタにはない 「ダウンロード不要でファイルをプレビュー」「外部にホストされたファイルへのダイレクトリンクを発行」 などの機能を備えています。 移行と接続の差については、付録 A の 表 6 をご覧ください。

これらの問題を一気に解消するのが、「ファイル サーバーに置いたコンテンツに SharePoint 経由でアクセスする」 という方法です。

この場合、バージョン履歴や Web (HTTP) を利用したアクセスなど、SharePoint の機能を利用できるほか、コンテンツへのアクセスに使用される 「窓口」 をひとつに統一することも可能になります。

このような 「いいところ取り」 のシステムを求めるお客様のご要望にお応えすべく、AvePoint は以下 2 種類のソリューションを提供しています。どちらも、レガシー ファイル サーバーからの移行の必要がないところがポイントです。

DocAve コネクタ は、SharePoint へコンテンツを移行・アップロードする必要なく、ファイルを表示・管理することのできるツールであり、ファイル サーバーのコンテンツを SharePoint のドキュメント ライブラリに保存されているかのように表示します。大きいサイズのメディア ファイルやドキュメントにも対応可能です。

ファイル本体はファイル サーバーに置きながら、チェックインやチェックアウト、バージョン履歴、権限の管理、監査、メタデータなど、Share-Point のほとんどの機能をファイルに適用することが可能です。

SharePoint / ファイル サーバー連携

が、このコンテンツが重要であり、継続使用したい場合は、Share-Point に移行する以外の方法を考える必要があります。

この際に発生する可能性のある問題点は以下のとおりです。

1. 新環境に重複データや古いデータが蓄積され、ごみ箱化を繰り返して しまう2. エンド ユーザーに、SharePoint ではなく各自のデスクトップからコンテンツにアクセスしてもらう必要がある

10

付録 A: 表

SharePoint 2016

推奨ケース 非推奨ケース

「セキュリティ上の要件」「クラウド移行が不可のデータが存在する」 などのポリシーのため、クラウド移行が不可能、もしくは困難である

オンプレミスで情報環境を運用管理するための予算、スタッフ、データ センター、ハード / ソフトウェアなどを問題なく用意できる

組織外 (モバイル機器を使用したアクセス、顧客やパートナーからのアクセスなど) からのアクセスが不必要

クラウドで使用できないカスタマイズ内容が存在する

データセンターのキャパシティが使用できない

データセンターを全く持っていない

サーバー、ネットワーク、ストレージ、スタッフに関する予算が全く取れない

組織外からのアクセスが必要

使用できる生産性向上ツールがない、もしくは同時に使用中の複数のツールを一本化したい

ソフトウェアの配信・アップデートを管理したくない

シン クライアント モデルからエンド ユーザー コンピューティングまでを標準化

クラウド移行を妨げる組織のポリシーが存在する

組織外からのアクセスが不必要

クラウドで使用できないカスタマイズ内容が存在する

SharePoint Online

ポリシー上、クラウド移行には問題がない

スタッフ、データ センター、ハード / ソフトウェアの予算がない

組織外からのアクセスが必要

クラウドで使用できないカスタム化コンテンツ、もしくはサード パーティ ツールは使用していない

クラウド移行を妨げる組織のポリシーが存在する

組織外からのアクセスが不必要

クラウドで使用できないカスタマイズ内容が存在する

ハイブリッド クラウド

ポリシー上、クラウド移行には問題がない

現状を変えずにいることは予算の関係上問題がないが、IT サービスを拡大したいと考えている

組織外からのアクセスが必要

クラウドで使用する必要のないカスタマイズ内容が存在する

表: 1 自社に最適のサービス・環境

11

環境

Office 365

環境

Office 365

表: 2 ISV ソリューションの利点

操作の難易度が低く、簡単に使用できます。

SharePoint サイト・リスト・ライブラリを、サーバー間で迅速かつ付加情報を保持したまま、完全忠実に移行することが可能になります。

効率性アップが期待できる

ホストされているサービスのバージョンに合わせるため、オンプレミス環境のアップグレードを実行する必要がなくなります。直接移行

接続されていないコンテンツ データベースや稼働中のサイトからも、コンテンツを移行することができます。アクティブ状態の移行元からも移行可能

組織で使用している SharePoint コンテンツを、移行を機に再構成することができます。再構成

組織で最もトラフィックの少ない時間帯を狙い、スケジュール設定をして実行できるため、通常業務への影響を最小限に食い止めることができます。

通常業務への影響抑制

ハイブリッド クラウドや全面クラウドに移行することにより、インフラストラクチャ保守管理のコストが浮くため、大幅なコストカットが実現します。コストカット

SharePoint 2003/2007/2010 から SharePoint 2016 へ、直接移行することが可能です。レガシー移行

簡単に使用できる

12

サーバー ロール 機能の説明

表: 3 Min Role Servers

ユーザーからの要求に応答するサービス アプリケーション、サービス、コンポーネント低待機時間を実現するために最適化されている

バックエンドからの要求 (バックグラウンド ジョブ、クロール) に応答するサービス アプリケーション、サービス、コンポーネント高スループットを実現するために最適化されているアプリケーション

分散キャッシュ用に必要となるサービス アプリケーション、サービス、コンポーネント分散キャッシュ

MinRole と統合しないカスタム サービス アプリケーション、サービス、コンポーネントファーム管理者は、どのサービス インスタンスがカスタム ロールにアサインされたサーバーを動かすことができるかに関する完全なコントロールを持つ

MinRole は、どのサービス インスタンスがこのロール用に展開されるかを制御しない

カスタム

シングル マシン ファームに要求されるサービス アプリケーション、サービス、コンポーネント

開発、検証、限定された本番環境として使用

シングル サーバー ファームの場合は、ファーム内で持つことのできる SharePoint サーバーは 1 台のみ

シングル サーバー ファーム

検索に必要となるサービス アプリケーション、サービス、コンポーネント検索

フロント エンド

13

表: 4 手動移行: メリットと問題点

最適な対象 メリット 問題点 / リスク

移行作業に参加できるユーザーが多ければ、早く作業が進む可能性あり

古いデータの移行を防ぐため、必要なコンテンツのみを移行

レガシー環境が保持できる

ダウンタイムはないが、ユーザーが新環境に切り替える必要がある

コンテンツの大部分が移行不要である環境

移行元が SharePoint 以外の環境 (Documentum、Notes など)

手動で実行するため、大きなリソースが必要となる

ユーザーのモチベーションを保ちながら、移行の締め切りまでに作業を完了してもらう必要がある

旧バージョン、監査履歴、アイテムのメタデータ、固有の権限などは保存されない

参加者の意欲とトレーニングが必要となる

元の URL をそのまま保持したい場合は、さらに追加の作業が必要となる

新コンテンツのため、サーバー ファームと SQL Server のストレージ スペースが必要となる

14

これらの問題を一気に解消するのが、「ファイル サーバーに置いたコンテンツに SharePoint 経由でアクセスする」 という方法です。

この場合、バージョン履歴や Web (HTTP) を利用したアクセスなど、SharePoint の機能を利用できるほか、コンテンツへのアクセスに使用される 「窓口」 をひとつに統一することも可能になります。

このような 「いいところ取り」 のシステムを求めるお客様のご要望にお応えすべく、AvePoint は以下 2 種類のソリューションを提供しています。どちらも、レガシー ファイル サーバーからの移行の必要がないところがポイントです。

DocAve コネクタ は、SharePoint へコンテンツを移行・アップロードする必要なく、ファイルを表示・管理することのできるツールであり、ファイル サーバーのコンテンツを SharePoint のドキュメント ライブラリに保存されているかのように表示します。大きいサイズのメディア ファイルやドキュメントにも対応可能です。

ファイル本体はファイル サーバーに置きながら、チェックインやチェックアウト、バージョン履歴、権限の管理、監査、メタデータなど、Share-Point のほとんどの機能をファイルに適用することが可能です。

表: 5 スクリプト移行: メリットと問題点

最適な対象 メリット 問題点 / リスク

どのコンテンツをいつ、どのように移行するかについては、柔軟に決定が可能である

自動化できるため、ユーザーを巻き込む必要がないレガシー環境が保持できる

ダウンタイムなし、ユーザーが新環境に切り替える必要はある

高度にカスタム化された環境である、もしくは移行先でも移行元のコンテキスト (権限など) を保持するため、ミスのない移行方法が必要である

手動、もしくはサード パーティによる移行が現実的に難しい

手動で実行するため、大きなリソースが必要となる

ユーザーのモチベーションを保ちながら、移行の締め切りまでに作業を完了してもらう必要がある

旧バージョン、監査履歴、アイテムのメタデータ、固有の権限などは保存されない

参加者の意欲とトレーニングが必要となる

元の URL をそのまま保持したい場合は、さらに追加の作業が必要となる

新コンテンツのため、サーバー ファームと SQL Server のストレージ スペースが必要となる

15

移行 統合

表: 6 移行ソリューション VS 統合ソリューション

データが SharePoint で使用できる

データは移行元環境 (レガシー システム) に残される

データが SharePoint で使用できる

データが SharePoint に移行される

ファイル サーバーのバリューを高めることにより、使用を継続する

ストレージの負荷はファイル サーバーにかかる (費用が割安となる)

ファイル サーバーの代替として SharePoint を導入する

ストレージの負荷は SharePoint にかかる (費用が割高となる)

ファイルに対する変更は元のシステムに反映される

接続して考えるのをやめる

変更は SharePoint のコンテンツ データベースに保存される

移行して使用停止

16

表: 7 推奨される移行方法

アクティビティ

カスタマイズしたコンテンツの移行

本番環境への移行

コンテンツ マッピング

移行計画

試験的移行

テストと検証

変更内容の同期

ユーザー移行

デザインやコード、構築などをやり直し、移行先環境で使用可能な状態にします。

移行元環境のフォーマットやレイアウトと移行先環境の情報アーキテクチャを統一します。列タイプ、コンテンツ タイプ、テンプレート、フィルター、権限などがマッピングの対象となります。

移行をフェーズや期間で区切り、移行が通常業務にどのような影響を与えるかを検証します。

また、必要なリソースや担当者に対するトレーニング、移行のスケジュール作成などもここで実行します。データ クリーンアップが必要かどうか、必要な場合は移行前・移行中・移行後のどの時点で実行するかどうかも検証します。

本番環境のデータ セットを代表する各セグメントを使い、移行のシナリオを作成します。その後、本番環境の外で各サンプル データを使い、各シナリオをテストします。

これにより、移行が技術的に実行可能であるかどうかの確認、起こる可能性のある問題の検知と対策、移行チームの実地トレーニングなどを実行することができます。

コンテンツの実際の移行がどのような流れで進行するかをシミュレーションできるばかりでなく、移行元から移行先までのデータの流れを最初から最後まで確認することにより、アクセス権の移し替え等から生じる問題を未然に防止し、結果を記録し、数値を収集することが可能になります。

加えて、最も効率のよい移行のスケジュールや方法のテストや、ロールバック テストをこのタイミングで実行するのも効果的です。

デザインやコード、構築などをやり直し、移行先環境で使用可能な状態にします。

移行先環境が問題なく使用できるか、問題なく移行作業が完了したかの検証を実行します。

この時点で出た数字と試験的移行で出た数字に大きなズレがあった場合は、何らかの問題が疑われます。内容を検討し、修正を試みます。

各フェーズごとに移行作業を繰り返します。

移行開始からユーザー移行までの間に、移行元環境で実行された変更内容を、移行先に同期します。

各フェーズごとに移行作業を繰り返します。

移行元環境をある時点で 「完全停止」 状態にし、変更内容を移行先に同期し、ユーザーを移行先環境に移行します。

ユーザーはこの作業の完了後から、移行先環境をメイン環境として使用開始することになります。

各フェーズごとに移行作業を繰り返します。

説明

17

AvePoint = Microsoft クラウド エキスパート.これまで全世界 15,000 社以上、300 万名以上のクラウド ユーザーに対し、Office 365 / SharePoint データの移行・管理・保護を提供しています。 AvePoint は、クラウド・オンプレミス・ハイブリッド クラウドすべてをカバーするソリューションを展開し、Microsoft のパートナー・オブ・ザ・イヤーを 2 回受賞するという栄誉に輝いています。日本に拠点を置き、日本語でのサポートも提供しています。6 大陸で事業を展開しており、顧客企業・組織の事業内容も多岐にわたります。Microsoft クラウドへの移行・IT 関連生産性の向上・ガバナンスやコンプライアンスなど、幅広いソリューションを展開しています。

Microsoft のパートナー・オブ・ザ・イヤーを 2 回受賞している AvePoint は、 成長著しい米国企業ランキング “Inc. 500/5000” に 6 回ランクインを果たしている他、テクノロジー分野において北米で急速に成長中の 500 企業をランキング形式で紹介する Deloitte Technology Fast 500™ にも 5 回選出されています。 AvePoint は Microsoft 認定グローバル ISV パートナーであり、ゴールド アプリケーション開発パートナー・ゴールド認定クラウド プラットフォーム パートナー・ゴールド認定 コラボレーション・コンテンツ パートナー・米国政府戦略パートナーシップ GSA プロバイダーです。2001 年にニュージャージー州ジャージーシティに本社を設立し、日本では 2008 年から事業を展開しています。

会社概要

18

V: 05242016_JP_01

通知この発行に含まれている資料は AvePoint, Inc に所有または提供され、 AvePoint およびそのライセンス提供会社のプロパティであり、著作権、登録商標ならびに他の知的所有権に関する法律によって保護されています。本書に掲載する通知および著作権の情報のいかなる削除ならびに変更も禁じます。

著作権Copyright © 2016 AvePoint Japan K.K. All rights reserved.本書の著作権は AvePoint Japan 株式会社に帰属します。本書に掲載されている情報はすべて日本著作権法において保護されており、内容の無断複製、更新、転載を禁じます。本書のいかなる部分、いかなる書式および電子通信、機械的送信、複写、記録などのいかなる方法、あるいは AvePoint Japan 株式会社 (〒 108-0074 東京都港区高輪 4 丁目 10-18 京急第一ビル 11 階)、ならびに本書に掲載する情報がサード パーティに所有される場合サード パーティによる事前の文書による許諾なしに複製、保存、送信を禁じます。また上記の如何に関わらず、本発行物内の AvePoint 関連の情報 (派生物及び変化物を含む) の何人による複製及び転載も禁じます。また、如何なる複製物並びに転載物も自動的にAvePoint に属するものとし、該当者または継承者、担当者、相続者、恩恵者、実行者のいずれも該当複製物並びに転載物を直ちに AvePoint へ返却し、必要書類に署名することに同意するものとします。

登録商標AvePoint®、DocAve®、AvePoint ロゴおよび AvePoint ピラミッド ロゴは AvePoint Japan 株式会社による日本特許庁登録済みの商標です。これらの登録商標および本書に使用されている他の商標はすべて AvePoint の専有プロパティであり、文書による許諾なしには使用できません。Microsoft、MS-DOS、Internet Explorer、Office、Office 365、 SharePoint、Windows PowerShell、SQL Server、Outlook、 Windows Server、Active Directory、Dynamics CRM 2013 はマイクロソフト株式会社の商標または登録商標です。Adobe Acrobat、および Acrobat Reader は Adobe Systems、Inc の商標です。その他本書に掲載されている商標はすべて該当の所有者のプロパティであり、許諾なしに使用することを禁じます。

変更本書は情報の提供のみを目的とし、通知なしに変更または更新される場合があります。当社では最新、そして正確な情報を提供するよう努力しておりますが、あらゆるコンテンツの誤りもしくは脱落に起因する間接的、派生的に生じた損害に対し、一切の責任を負わないものとします。当社は、ユーザーに対し予告、通知をすることなく AvePoint ソフトウェアのグラフィック ユーザー インターフェイスを変更する権利を所有しています。

〒 108-0074 東京都港区高輪 4 丁目 10-18 京急第一ビル 11 階

19

http://www.avepoint.jp/