stsadmなしのSharePointバックアップ/復元
Stsadmを使用したサイト/サイトコレクションの復元で見つかった問題（ワークフローから生成されたタスクは復元されませんでした）のため、バックアップ/復元には別のルートを使用しました。 SPサイトの大幅なカスタマイズを計画しており、インストールが失敗した場合にロールバックできるようにバックアップを取りたいと考えています。システムテスト（本番環境ではない）環境では、12 Hive、IISがSharePointを指す仮想ディレクトリ、およびSQLのSharePointデータベース（SQLサーバーを使用してデータベースのバックアップを実行）をバックアップしました。 ）。
Visual Studioで構築されたカスタムイベントハンドラーとワークフローがあり、dllをバージョン2（Visual Studioで署名およびバージョン管理）としてGACに展開します。したがって、デプロイするとき、GACにはワークフローの2つのバージョン（バージョン1とバージョン2）が含まれます。デプロイ中に、SPstsadm機能を使用してWFをインストール/アクティブ化します。また、各ライブラリに移動して、新しいバージョン2のWFを追加します。これにより、バージョン1のWFが新しいインスタンスを「許可しない」（これが必要なもの）に自動的に設定され、バージョン2がアクティブとして設定されます。
インストールが完了すると、障害が発生したと見なし、同じマシン（1つのサーバーではSharePoint、別のサーバーではSQL）に復元しようとします。まず、GACからバージョン2 WFをアンインストールし、IISをリセットし（これらのバージョン2 WF dll 'のキャッシュをクリアするため）、12-Hiveフォルダーと仮想ディレクトリフォルダーを復元します。次に、SQLデータベースを復元します。これはすべて、読んだときと同じように手動です。ここにはstsadmはありません。復元後はすべて機能しているようですが、復元は成功したようです。インストール中に列名やデータの変更などに加えた変更はすべて、元のインストール前の状態に戻ります。 1つの例外を除いて。ワークフローを実行すると、常に失敗し、12-Hiveのログは、WFがまだバージョン2のdllを使用しようとしていることを示しています（System.IOファイルが見つかりませんエラー）。 Sharepointのすべての移動部分をバックアップして復元しましたが、ここに何かが欠けています。SharePointのすべてのフォルダーとデータベースを復元したにもかかわらず、バージョン2 WFdllがまだ参照されている理由を誰かが知っていますか？ ？
ありがとう、ケビン
ケビン、
操作の順序を正しく理解している場合、1つの大きな質問があります。コンテンツデータベースを復元しますが、復元中にファーム構成データベース（およびSSPデータベースなどの他のデータベース）はそのままにしますか？答えが「はい」の場合、構成データベースがワークフローのv2への参照を保持しているため、SharePointが適合をスローしていると思われます。これが発生している可能性があります。
SharePointファームに機能をインストールすると、SPFarm.FeatureDefinitionsコレクション（ファーム構成データベースに保持されます）が更新され、追加した内容が反映されます。これには、機能に含まれると予想されるすべての標準情報（名前、スコープ、ID、バージョンなど）が含まれます。また、FeatureReceiverアセンブリ情報とRootDirectory値なども保持されます。 RootDirectoryプロパティは、機能の機能マニフェストが配置されている12-Hive内のフォルダーを指します。
V2ワークフロー機能をファームに追加してアクティブ化すると、構成データベースが更新されます。コンテンツデータベースのv2より前のワークフローバージョンを復元した場合でも、構成データベースレベルで維持される機能の関連付けにより、ファームはワークフローのv2を探します。 v2 Featureフォルダーがまだ12-Hiveに存在し、そのマニフェストがGACのv2アセンブリを指している場合、問題が発生する可能性のある場所を簡単に確認できます。
同時に、ワークフローFeatureがFeatureReceiverを利用している場合、その情報は、FeatureにFeatureDefinitionsコレクションのReceiverAssemblyプロパティにも（構成データベースに）格納されます。インストールされています。
私が間違っていて、実際にファーム全体（構成データベースを含む）をインプレースで復元している場合、私が書いた内容は適用されません。その場合、私も少し頭をかいてしまいます。 :-)
これがお役に立てば幸いです。
私はそれを使ったことがありません（Sharepointの人でさえも）が、これはあなたのために働くかもしれません。 CodePlexでつまずいた...
インストールの完了後にリストからワークフローバインディングを削除してみてください。最初にリストからすべてのワークフローの関連付けを削除し、次にGACからV2 dllを削除し、次にdllを再デプロイしてから、ワークフローを再関連付けします。ワークフローへの残りのすべての参照が（コンテンツデータベースと構成データベースの両方から）なくなり、SharePointにワークフローの関連付けを再バインド/再構成するように強制します。
P.S.ワークフロー関連のタスクが復元されないのは非常に奇妙です。それらはコンテンツにすぎず、コンテンツデータベースにあるはずです。ワークフロータスクは正しく復元されていないワークフローにバインドされていると思います（ワークフローの関連付けは両方に保存されているため、コンテンツワークフローと構成ワークフロー...）。復元が行われると、ワークフローは基本的に再初期化され、新しいGUIDなどが取得されます。共有ポイントとしては、これは新しいワークフローのように見えるため、古いワークフローに関連するタスクをバインドできません。もう）。
カスタムソリューションを作成するのではなく、実際の問題を深く掘り下げることをお勧めします。
ワークフロー関連の復元/パッケージングの問題とワークフローが実際に保存/作成される方法の詳細については、 このサイト および この記事 を参照してください。