問題タブ [moss]

古いポータルシステム（Plumtree）をSharePointに置き換えるプロジェクトに取り組んでおり、可能な限りスムーズに移行したいと考えています。

現在私たちが注目していることの1つは、すべてのガジェット（Webパーツのプラムツリー用語）を取得し、それらがユーザーの新しいMySiteの同じ場所に表示されることを確認することです。

Plumtreeは、ユーザー、ページ、ガジェット、および位置情報を含む単純なテーブルにこの情報を保持します。このテーブルの読み取りと新しいWebパーツのユーザーMySiteへの配置を自動化する方法を見つけたいので、何百人ものユーザーに対して手動で設定する必要はありません。

SQL ServerでSharepointテーブルを直接変更することは、サポートの取り決めに影響を与える可能性があるため、適切なオプションではないと言われていますが、これを手動で行う必要がない場合は、検討します。

頭に浮かぶ他のオプションは、同等のテーブルを作成し、ユーザーが初めてMySiteにアクセスしたときにAPI呼び出しを使用してWebパーツをロードすることです。

より良い提案はありますか？

C# で記述された Sharepoint WebPart では、現在のユーザーの MySite の ID を調べるか、現在のサイトがユーザーの MySite であるかどうかを確認する必要があります。

アイデア？

を使用して SharePoint サイトをプログラム的に作成しています

spWeb を設定して [ナビゲーションにページを表示] オプションをオフにするには、どのコードを実行する必要がありますか?

答え：

MultipleLookupFieldを配置したいMOSS'07サイトのページレイアウトがあります。このフィールドは、ページライブラリを指すカスタムコンテンツタイプの複数のルックアップ列を指しているため、[関連記事]フィールドを使用できます。 。

フィールドが正しく表示されるようになりました。ページが編集モードの場合でも編集可能です。ただし、そこに表示されるリンクをクリックすると、ページ自体ではなく、ページのプロパティビューが表示されます。

コントロールには多くのプロパティがありますが、MSFTにはそれらの機能に関するドキュメントがほとんどありません。

リンクのURLをプロパティビューではなく実際のページに変更する方法を知っている人はいますか？

これが私が使用しているタグです：

<SharePointWebControls：MultipleLookupField ID = "MultipleLookupField1" FieldName = "RelatedIssues" runat = "server"> </ SharePointWebControls：MultipleLookupField>

リンクをクリックすると、次の場所に移動します：/Pages/Forms/DispForm.aspx?ID=6&RootFolder=*

ここに連れて行ってほしい：/Pages/faq1.aspx

ですから、私は少し古臭いかもしれませんが、過去に Web サイトを作成したときは、開発サーバーでサイトを開発してから、ページとファイルを運用サーバーに公開または昇格していました。これは常に、私たちの 1 人が失敗したためにページがめちゃくちゃになったり、サーバーがダウンしたりするのをユーザーが見ないようにするための良い方法であると思われてきました。

しかし、Microsoft が SharePoint を作成したときにこの考えを念頭に置いていたようには見えません...少なくとも、定義されているインフラストラクチャでこれを行う方法を見つけることができませんでした。

SharePoint 開発の管理戦略があるかどうか知っている人はいますか? 開発環境のバックアップを作成し、運用サーバーに復元できることをオンラインで読みました。最初はうまくいくかもしれませんが、運用サーバーへの更新は、運用サーバーでデータが失われる危険を冒さずにそれを行うことはできません。リストのコンテンツ、ページ、およびドキュメントをあるサーバーから別のサーバーに移行するためのツールがいくつか出回っていますが、確かに、それらについてはまだ調査していません。

しかし、私のもう 1 つの懸念事項は、カスタム コンテンツ タイプです。リストがコンテンツ タイプを使用すると、リストからアイテムを削除し、コンテンツ タイプの関連付けを解除し、コンテンツ タイプを再度関連付けないと更新できないようです。コンテンツ タイプをアップグレードする方法はありませんか?

とにかく、これらの現在のジレンマのいずれかについて何か提案があれば、ぜひご連絡ください.

前もって感謝します、

ダン

早々に返事をくれてありがとう。

サイト用に作成されたいくつかの機能と、基本 (コンテンツ タイプ、列など) に向けられた機能をバンドルするソリューション パッケージ、およびブランド化に関係する機能 (ページ レイアウト、マスター ページなど) のための別のソリューションが既にあります。

しかし、これは 1 回限りのショットのようです...基本的に、これでサーバーがセットアップされますよね? 運用環境を使い始めると、ドキュメント、ページ、リスト アイテムがすべてコンテンツ データベースに存在することになり、コンテンツ タイプや列などを更新することはできなくなります。

新しい機能をインストールしてアクティブ化する前に、非アクティブ化してアンインストールする必要がある機能ですよね? 機能定義で Version プロパティを見たことがありますが、私が知る限り、これは何もしません。ソリューションは、バージョン番号を増やすことでアップグレードできるように見えますが、特に使用中の場合、コンテンツ タイプや列などを変更するようには見えません。さらに、ソリューションによるアップグレードがどれほど広範囲に及ぶかはわかりません。

この種のことについては、貴重なドキュメントがほとんどありません。私が読んでいるのは、SharePoint サーバーを最初にセットアップする方法だけのようです...長期的に管理することではありません。

アドバイスや提案はありますか？

ご提案いただきありがとうございます。

しかし、私たちはこのサイトに 1 年以上取り組んできました。私たちは、あなたのほとんどが推奨しているものに従って、すでにセットアップされていると確信しています. コンテンツ タイプ、列、マスター ページ、ページ レイアウト、ワークフローなどをインストールするいくつかの機能が既に用意されています。これらの機能のほとんどは、ソリューション パッケージに含まれています。すべての開発環境を VPC サーバーとしてセットアップしました。

これで、初期展開はほぼ完了しました。私が本当に知りたいと思っているのは、コンテンツの種類や列などをアップグレードする方法です。使用後にコンテンツ タイプを変更することはできますか? 私の最初のテストに基づいて、これが可能であるとは思えないからです。アセンブリは問題なく交換されているように見えるため、アセンブリについては心配していませんが、コンテンツ タイプを更新する唯一の方法は、それらを参照しているアイテム (つまり、ページ ライブラリ内のすべてのページ) を削除することです。コンテンツ タイプを再追加します。

最初の展開後にコンテンツ タイプを更新する方法があるかどうか知っている人はいますか? ...ユーザーが既にデプロイ済みのコンテンツ タイプに基づいてアイテムを作成した場合は?

(私の質問の他の部分は、実際には既存のページを開発サーバーから本番環境に移動することでしたが、それがなくても生きていけます。私の主な心配はコンテンツの種類です。)

SharePoint の AD インポート時に、MOSS はこれを自動的に行います。「Office SharePoint Server 2007 は、上司、同僚、直属の部下を同僚として自動的に追加します」。これを自動的に無効にして、同僚のリストをきれいにするにはどうすればよいですか?

Word 2007 から SharePoint 2007 (MOSS) ドキュメント ライブラリに保存する際に、奇妙な断続的な問題が発生し、ダイアログ ボックスが表示されて消えません。「コンテンツ タイプ」というタイトルで、「使用可能なコンテンツ タイプのリストを取得しています...」というメッセージが表示されます。スクロールし続ける緑色のプログレス タイプのバーが表示されます。これはトレーニング サーバー (別の SQL Server を備えた自己完結型の仮想マシン) で頻繁に発生しますが、より心配なのはライブ プロダクション サーバー (中規模のサーバー ファーム配置 - Web アプリケーション サーバー、検索/インデックス作成用の別のサーバー) で発生しています。 SQL Server)。ファーム内のすべてのサーバーは 64 ビットです。

これは奇妙にランダムです。ユーザーは Word 2007 を強制終了する必要があります。その後、ドキュメントを復元して同じドキュメント ライブラリに保存しようとすると、問題なく保存されます。

ライブサーバーよりもトレーニングサーバーで発生します。ライブ Web アプリケーション サーバーの CPU 使用率が 20% (通常は約 5%) を超えることはめったになく、メモリは利用可能な 4Gb の 2Gb (通常は 1.5Gb) でピークに達するため、リソースの問題ではないと思います。

ドキュメント ライブラリは、ソリューションの機能を使用してカスタマイズおよび展開されます。それらの唯一のコンテンツ タイプは、標準の Documents コンテンツ タイプです。

更新これはサポートの問題として Microsoft に公開されました。これは既知の問題であり、2009 年 2 月に SharePoint の累積更新プログラムの修正プログラム パッケージで対処される予定です。

編集上記の回答を回答にコピーして、この質問に回答済みのフラグを立てることができるようにしました。

複数のドキュメント ライブラリを含むサイトがあります。サイト ユーザーの 1 人がサイトを完全に制御でき、ある時点で、新しいドキュメント ライブラリを作成する代わりに、既定のドキュメント ライブラリの名前を "共有ドキュメント" から "通信" に変更しました。ドキュメント ライブラリを Windows エクスプローラーで開くと、ネットワーク プレースにエントリが追加されます。エントリの名前は「Portal.mydomain.net の共有ドキュメント」であり、「portal.mydomain.net の対応」ではありませんでした。これは、ライブラリのアドレスがまだ「Shared Documents」であるためです。私はユーザーのネットワークの場所に行き、エントリの名前を変更しましたが、将来のユーザーが同じ問題に遭遇しないように、アドレスも変更したいと思います.

ドキュメント ライブラリの設定を調べましたが、アドレスを変更する場所が見つかりませんでした。アドレスは「タイトル、説明、およびナビゲーション」に表示されますが、変更するオプションはありません。[サイトの操作] > [サイトの設定] > [コンテンツと構造] の下を調べて、そこでアドレスを変更する方法があるかどうかを確認してみました。しかし、Correspondence ドキュメント ライブラリをチェックしてアクション メニューをプルダウンすると、[移動] がグレー表示されます。

ライブラリをテンプレートとして保存し、コンテンツを含めて新しいライブラリを適切なアドレスに作成できると思いますが、変更された情報はすべて間違っています。

何か案は？

運用フロント エンド サーバーのイベント ログが次のエラー メッセージでいっぱいになっています。

「ID のフィーチャーの定義を判別できませんでした」

さて、開発サーバーの 1 つで問題のある機能を見つけました。これは、いくつかのコード ビハインドを含む InfoPath フォームです。しかし、実稼働サーバーではどこにも見つかりません。

運用サーバーで次のコマンドを実行してみました: stsadm -o uninstallfeature -id (GUID) -force

変更はありませんでした - エラーはまだ生成されています。

エラーを取り除くにはどうすればよいですか?

サイト アクション メニューをカスタマイズして、「標準」メニュー項目を削除または名前変更するにはどうすればよいですか? サイト アクション メニュー項目はどこで定義されていますか?