HrsTのあれこれ: SharePoint

ラベル SharePoint の投稿を表示しています。すべての投稿を表示

SharePoint アイテム保管ライブラリをのぞいてみよう（2025年12月改訂）

※2025年コンテンツ検索等の機能がリニューアルされましたので修正しました。
※2023年アカウント移行に失敗し画像を失ったので再度取得し改訂しました。
Office 365 Advent Calendar 2021 の12月16日投稿です。

警告：

個人的な理解に基づく内容、表現です。疑いを持って取り扱ってください。
SharePoint と OneDrive の保持の詳細 - Microsoft 365 Compliance | Microsoft Docs

SharePoint Onlineをご利用の方にとっては普通？の機能ですが、SharePoint Server 2010以前から利用している方にとっては2013からの新機能「インプレース保持」で使われる「アイテム保管ライブラリ」をちょっとのぞいてみようという内容です。

Exchangeのインプレース保持とSharePointの保持は違うよ～

Exchange のインプレース保持はごみ箱から消えたメッセージを含むすべてを保持することができるのですが、SharePointでは対象外アイテムが存在しますし、編集についてはバージョン履歴に依存しています。また、情報管理ポリシーの「ごみ箱に移動する」が動作しなくなるなど利用者への影響もありますので注意が必要です。また、保持してることを内緒にしたくてもサイト管理者にはバレバレな点は認識しておかないとね。あとE3相当以上の方はExchangeは容量無制限ですけど、SharePointはしっかりと契約容量に含まれているので上司の方から説明のたびに叱られる可能性がありますね。

SharePointの保持は、Exchangeが連携して利用する大容量添付ファイル送信やTeamsメッセージの添付ファイルを保持する目的のために存在する機能なのかな～という感じがします。SharePointの情報調査や監査という意味では、バックアップ製品などでこまめに世代管理する必要があると感じます。

SharePointで削除されたアイテムは各サイトの「アイテム保管ライブラリ」にコピーされ設定期間保持されます。

各サイトというのがミソですね。しかも、サイト管理者から参照可能な場所に保持されるため、保持について理解のないサイト管理者はこのライブラリのアイテムURLを見ることができないユーザーに渡すなど困った行動を起こす可能性があります。

それでは保持を確認するために保持されるアイテムを準備します。
そうそう、アイテム保持ポリシーの対象にするのを忘れないでください。

下図では状態が「有効（保留中）」になっていますので、（保留中）が消えるまで1日程度待ちましょう。

2つのファイルを作成し、何度か編集した後に削除します。

ごみ箱に入っていますね。

「アイテム保管ライブラリ」が作成されていますが、サイトコンテンツには表示されなくなりました（2023年時点）ので、サイトURLに「/PreservationHoldLibrary」を追加すると開くことができます。

~~ライブラリではなくリストらしいです。~~ライブラリです。

※仕様が変わった際にリストからライブラリに変わったようですね。ということは、保持ポリシーが適用された時期によって違うかもしれません。

ごみ箱に入っている2つのファイルがアイテム保管ライブラリにも存在することがわかりますね。（2021年12月時点ではバージョンごとにファイルが保存されていましたが、2023年では1つのファイルにまとまっています。）

バージョン履歴を確認するとすべてのバージョンが維持されています。

一応念のため・・・アイテム保管ライブラリ内のファイルを削除してみようと思います。

当然、消せないのですけど。

リストの保持を見てみよう

リストアイテムはアイテム保持ポリシーではサポートされていません。保持ラベルを利用しましょう。（保持されてるっぽいけど…）

リストを作成します。

1月4日を消してみた。

ちゃんとごみ箱に入っています。

アイテム保管ライブラリにもありますね。

開いてみると…文字化け・・・

直接開かず文字コード指定ができる方法で開けばちゃんと表示されます。

バージョン履歴がこのファイルにまとめられて保持されてるとよかったんですけどね～残念です。

まとめ

Exchangeと違って全部を保持する機能ではないので注意
バージョン履歴が保持されるのはライブラリのアイテムだけ
リストはバージョン履歴は保持されないよ。削除したバージョンだけ
リストアイテムの添付ファイルはバージョン履歴の対象外だよ
~~ライブラリって言ってるけど種類はリスト。どう見てもライブラリ。~~

おまけ。コンテンツ検索でエクスポートしてみよう。

2025年8月にコンテンツ検索は廃止され、電子情報開示にまとめられました。

検索条件は場所でサイトを選択するだけで全部を対象にしました。

よい子のみんな、試すときは監査責任者など権限のある人といっしょにしようね。

コンテンツ検索、電子情報開示(Standard, Premium)が廃止され、新しい電子情報開示にまとめられ、以前よりわかりやすくなったのかな？

「検索の作成」を選択し、複数の検索を管理できます。

データソースを追加することで特定の情報を検索対象に設定します。

「エクスポート」を選択し、名前を付けたら、エクスポートする条件を選んでいきます。

この辺がSharePointに関連する設定になります。

Select document versionsで「All versions」を選択すると一時的に別の内容に変更する悪さなどを見つけることができるかもしれません。

設定が終わったら「エクスポート」を選択します。

すぐにはダウンロードできないのでおとなしく待ちます。

コンテンツ検索の「エクスポート」を選択すると、実行したエクスポートの状態が確認できます。

目的のエクスポート名を選択すると、ダウンロードできます。

以前は、ダウンロードツールを使った面倒な作業がありましたけど、普通にダウンロードが始まります。

エクスポートするとSharePointのフォルダー構成そのままが再現されます。

「PreservationHoldLibrary」ってのがアイテム保管ライブラリです。

エクスポートするとファイルがちゃんと分離されますが、どのバージョンかはファイル名を見て判断するしかなさそうですね。

(2023)今回、画像を再収集するために再現操作していたのですが、以前と変わった部分がありますね。

(2025)そういえばPurviewの画面がめちゃ変わったよな～とこの記事を更新したわけですけど、しばらく使っていないと操作を忘れてしまったり、役割の設定方法とか、画面遷移が変わったこともあり、ちょこっとキャプチャして～って感じにはならないですね。めったに触らない機能なので仕方がないですが、クラウドサービスって・・・って思う。

というわけで、アイテム保管ライブラリ~~という名のリスト~~について書いてみました。

よいお年を！！

消えた「アイテム保管ライブラリ」

確か2022年の年末あたりのアップデートで表示されなくなったんだよな～

それまでは、「サイトコンテンツ」の一覧に「アイテム保管ライブラリ」が見えていたので、何が保持されているのか確認することができたし、第2のごみ箱からも消えたファイルを確認することも復活させることもできたんですよね～

テナント管理者としての立場からすると、サイトの管理者は”サイトの権限設定を委任した利用者”なだけで、一般の利用者と大差ない。だから削除されたはずのファイルを気軽にみられて復活する行動はちょっといただけない。だから、このアップデートは賛成です。

とはいえ、保持対象のファイルをわざわざ検索しなくても確認できる方法というのは気軽にできてよいですよね～（検索の条件設定がしっかりと機能していればよいのだけど）

実際のところ、非表示になっただけなので「PreservationHoldLibrary」をサイトURLに付加すれば簡単に開くことができます。

ライブラリのURLを覚えていなくても、[サイトコレクションの管理]-[記憶域メトリックス]を開くとファイルの一覧等は確認できます。

ここでアイテム保管ライブラリを開いてURLを確認すると「/sites/hold/_layouts/15/storman.aspx?root=PreservationHoldLibrary」となっており、「/sites/hold/PreservationHoldLibrary」に書き換えればいつものライブラリを開くことができます。

もうちょっと非表示にしてくれるとよいのにな～と思いますね。

オンプレミスSharePoint Serverのバージョンアップに備える5 まとめ

なんとなくシリーズ化させて書いていますが、簡潔にまとめます。
文字が増えると間違いも増えるので注意が必要だ。

パスベースのサイトコレクションが増えるとバージョンアップで確実に困る。
ホスト名付きサイトコレクションなら何とかなる。

ホスト名付きサイトコレクションだ！！

と個人的には思ってます。
少なくとも私はホスト名付きサイトコレクションに救われました。
ぜーんぶホスト名付きサイトコレクションにしたら多分不幸になるのでやりすぎは注意。

オンプレミスSharePoint Serverのバージョンアップに備える4

ところで・・・

構成A
http://contoso/sites/TeamA

http://contoso/sites/TeamB

http://contoso/sites/TeamC

http://contoso/sites/TeamD

http://contoso/sites/TeamE

構成B
http://TeamA.contoso/

http://TeamB.contoso/

http://TeamC.contoso/

http://TeamD.contoso/

http://TeamE.contoso/

構築が簡単なのはどっち？
答えは構成A

サイトコレクションを作成するとき楽なのはどっち？
答えは構成A

ユーザーにサイトコレクションを自由に作成させたい。楽なのはどっち？
答えは構成A

バージョンアップするときに楽なのはどっち？
答えは構成A。

バージョンアップ中の更新禁止時間が長いのはどっち？
答えは構成B（たぶん）

毎週土曜日に、一つずつバージョンアップすることができるのはどっち？
答えは構成B（たぶん）

答えが構成Bのとき「たぶん」ってあるけどなんで？
「できるよ」っていうSharePoint神がいたとき対策。
異なるSharePointバージョンで同じホスト名を使って運用する方法を知らないんだ。

バージョン混在でも全く疑問を感じない構成Bがおすすめってこと。

http://TeamA.contoso/　192.168.0.1　SharePoint2007

http://TeamB.contoso/　192.168.0.2　SharePoint2010

http://TeamC.contoso/　192.168.0.3　SharePoint2013

http://TeamD.contoso/　192.168.0.4　SharePoint2016

http://TeamE.contoso/　192.168.0.5　SharePoint2019

大事なことは、「ホスト名付きサイトコレクションは知らないと損」
だまされたと思って調べてね。損はない。いや、知らないことが損。

オンプレミスSharePoint Serverのバージョンアップに備える3

コンテンツデータベース内のサイトコレクション数っていくつが良いの？
　偉い人教えて～～～

個人的な意見ですが、どんなに詰め込んでもよいのでは？と思ってます。
とはいえ、100GBを超えないようにするのが良いようです。
100GBに近づいてきたら Move-SPSiteで一部のサイトコレクションを別のコンテンツデータベースに移動させることをお勧めします。

もし、一つのサイトコレクションのサイズが100GBを超えそうな状態なら、それ以上サイズが増えないように、何かを頑張ってください。

URLが変わってもよいという協力的なユーザーに恵まれているなら、Export-SPWeb, Import-SPWebでサブサイトを別のサイトコレクションにコピーして、サイズを減らしましょう。

とりあえず、運用中は1対1がベストだし、バージョンアップ時は、コンテンツデータベースが少ないほうが楽。だと思う。

オンプレミスSharePoint Serverのバージョンアップに備える2

データベース接続方式って素晴らしいよ。

SharePointのサイトコレクションはコンテンツデータベースに保存されていて、サーバー構成情報とは分離しているので、このサイトコレクションで新バージョンや検証サーバーしたいと思ったら、該当のコンテンツデータベースのバックアップを作成し、新環境のデータベースにリカバリして接続すれば、サーバー名が異なっても問題なく動作する。
サーバー名が異なるのでリンク切れとか発生する場合もあるけど、普通に動作する。

サイトコレクションの変更はすべてコンテンツデータベースに保存されるので、やり直したいときも、コンテンツデータベースを差し替えるだけでよい。

いろいろ試したいなぁと思ったときにすぐできるのが非常に良い。

（ノーツなら掲示板の設計とコンテンツが分離されていて、デザイン変更も安心だぜ！！なんて思っている人にとっては物足りないけどね～）

気軽にいろいろできるデータベース接続方式だけど、ちょっと考えないといけない点がある。

1つのサイトコレクションは、複数のコンテンツデータベースにまたいで保存することはできない。
一つのコンテンツデータベースには、複数のサイトコレクションを含むことができる。

運用中はあまり気にしなくてもいいんだけど、データベース接続方式って言葉を聞く段階では大きな問題になってることもあるから注意が必要。

例えば、一つのサイトコレクションの作業をしたいのに、1000個のサイトコレクションが同じ一つのコンテンツデータベースに保存されているとき。

別のサーバーで使うにはコンテンツデータベースのコピーを使うので、一つしかいらないのに不要な999個のサイトコレクションもおまけについてくるんだ。

データベースを接続する際には、チェックとかアップグレード処理が動くので、999個分の無駄な処理が動き、当然待ち時間も増えてしまう。

だから、一つのコンテンツデータベースには一つのサイトコレクションが無駄がなくてよいよね。

でも、全部バージョンアップするときは、1000個のコンテンツデータベースのバックアップを取って、接続してって処理が必要になるので、多すぎるのも面倒。1個のコンテンツデータベースのほうが接続時の処理が1度に終わるので、実質こっちのほうが時間は短いのかな？どうなんだろうね。

オンプレミスSharePoint Serverのバージョンアップに備える１

もう経験した？いまだに2007使ってる？
準備は大変だし、待ち時間ながいし、停止時間長いと怒られるし・・・

私はWSS3.0から使い始めて、今は2016だよ。
うん、頑張った。
WSS3.0から2016にバージョンアップした際は、なんて無茶するんだろう？なんて思ったし、スキップしちゃだめだとかその時は思ったけど、結局2010から2016に2013スキップしちゃう自分がいる。実は2019まで行っちゃおうか？なんて本気で考えていたけどね。（さすがにMicrosoft Docsで日本語翻訳されていないタイミングは早すぎると）
正直に言うと2013は運用したことない。あれは2016への通過点だから動けばよかった・・・2010から2013にバージョンアップして何が変わるか細かくは知らないんだよね・・・通過点だからどうでもよかったし～

SharePointのバージョンアップってテータベース接続方式だから、スキップしたとしてもそんなに難易度が上がるってことはなくて、単純に作業量が一気に来るだけなんだよね～
WSS3.0からだと、コンテンツデータベースをSharePoint2010に接続して切断、つぎに2013に接続して切断、さらに2016に接続するだけで作業が終わる。途中のバージョンに合わせて修正する必要がないのでトータル的には作業量は少なく済む。複雑なことしてなければほんと簡単なんだよなぁ～

はっきりいって、メンテナンス中のコンテンツ更新禁止時間に文句が出なければバージョンアップしない理由なんてない。
作業を始めたら終わるまでコンテンツ更新できないんだよね～

だから、とりあえず、テスト環境でバージョンアップ時間を計って、許容範囲か確認したらよいと思うよ。

ドキュメントライブラリーは上書きを防げ

ドキュメントライブラリは何も考えずアップロードすると上書きされてしまいます。

これを防ぐ方法としては、上書きするチェックボタンのチェックを外すカスタマイズを行う必要がありますが、私はワークフローでファイル名を変更して、同じ名前になる確率を下げる方法を取っています。
ファイル共有フォルダーとして使っている場合は上書き問題はあまり発生しないのですが、○○報告書の保存のために用意すると、上書きする可能性が高くなります。

それにファイル名の統一性がないと見た目も汚いですよね。

だから、新規保存をトリガーにファイル名を変更するワークフローを使って一定のルールに従ったファイル名に変更してしまいます。
例えば、「○○報告書　＋　報告日　＋　報告者」とかにすることで、同じ日に違う人が報告を上げても大丈夫なようにします。

先日気が付いたのですが、この方法が使いにくいパターンがあることに気が付きました。
それは・・・

テンプレートファイルから保存した場合。

定型文に記入してもらって保存する

という、ユーザーに優しい方法を取った時にファイルを保存して、Officeアプリを終了しても、しばらくの間、ファイルがロックされていると認識され、ワークフローがロック解除を認識するまで中断してしまう問題を確認しました。

このロック解除するまでの時間は数秒から数分と結構ばらつきがあって、中断している間に上書きされてしまう可能性があるのです。

テンプレートから作成したドキュメントのファイル名は「テンプレートファイル名1」がデフォルトになっており、そのまま保存すると、上書きされてしまうのです。

この動作を見越して、ファイル名を変更するワークフローを動かしているのに、たった数分の中断によってグッドアイディアだったこの方法が微妙な感じに・・・

ファイルをアップロードしたときはほぼ即時に反映されるので、直後の一覧更新で変わっているんですけどね～

どうにかならないものでしょうかねぇ～

Microsoftさんよ～～～

近々リリース予定のワークフローで権限書き換えを行うSharePoint リストの準備で、マニュアルを作ってるんだけど、クリップアートの提供がなくなったじゃん？
アバターと建物のクリップアートが使いたいんだけど・・・ないじゃん？
Bing検索だとろくなのないじゃん？
クリップアートはよく使ってたけど、まぁ、Bing検索でクリップアート探せばいいじゃん？って簡単に思ってたんだけど、クリップアート集かフリー素材が必要な感じ・・・ライセンス的に気を付ける必要があるので、結構ダメージでかかった。

ってのは置いといて、先週末に打ち合わせでリストの名前が変わりました。
ということで、関連するリストとかワークフローの名称も変えてたんですよ。
そしたら通常のワークフローは動作するんだけど、権限を書き換える処理があるワークフローがエラーになるんだよね。

え？リリース間近なのに原因不明の不具合発見！！ってかリスト名しか変えてないのに動かなくなるって一番やばいじゃん！！
今までチェックしてた時はちゃんと動いてたのに・・・なんで？？

ってワークフローの見直しとか、権限の確認とかいろいろやってたんだけど、条件的には問題ないんだよな～～
権限以外は問題なく動作してるし・・・あせるわ～～～

まぁ、こういう時は一からワークフローを書き直してみるのが一番で、全く同じのを作ってみたらわかりました。原因が・・・

このリストね、アイテムごとに条件によってSharePoint グループの権限レベルを変更する処理を行っていまして、そのグループ名も変更してたんです。
普通ね、こういう変更をしてもSIDとか内部IDで管理されるので、名称変更しても影響がないと思うよね。
少なくとも私はそう思ってたの。
SharePoint DesignerのGUIで設定してるし・・・

だけど、SharePoint Designerの権限設定には古いSharePoint グループ名が表示されていたの。
でもSharePoint ってActive Directoryユーザーやグループの名称変更しても、ユーザープロファイルの同期までは古い名前のままで動いていたりするので、特に気にしてなかったんだけど、SharePoint グループはちょっと違うみたい？いや、アイテムに設定された固有のアクセス権は名称が変わっているので、SharePoint Designerの問題だと思うんだけど、ワークフロー内で扱うユーザー名やグループ名って表示名とかで定義されているのかなぁ～～なんて思ってます。

よくよく考えると、そんな気がしてきた・・・。Visual Studioでワークフローを作成したらSIDとかで指定するはずないもんね。
いくら専用の編集ツールとはいえ、外部ツールなんだよね。だから、内部IDじゃなく表示名を使うのは当然だよね～～
気を付けんといけんね～

今回はSharePoint 2010の気付きでした。

毎回悩む

Lotus Domino/NotesからMicrosoft SharePointにコンテンツ移行する際に毎回悩むのが、
ディスカッション掲示板の応答文書の扱い。

Notesの場合、ビューに親アイテムに紐づくアイテムとして表示されるので、
例えば、カテゴリーっぽい使い方、補足文書、関連文書など応答文書をかなり独立した目的で作成することができるので、SharePoint のディスカッションに移行してしまうと、本来の目的からかけ離れてしまう。

かといって、カスタムリストに移行すると、親文書との連携ができない。
親文書をカテゴリとして空文書で応答文書だけだとカテゴリに置き換えてやればいいのですが・・・

答えとしてはケースバイケースなんで、正しい対応方法というのもないけれど、
どちらがあってるのかなぁ～と悩んでしまいます。

さて、今回はどちらにしようか・・・

筆の選択に悩む

Lotus Notesなら簡単なスクリプトで実現できることを、SharePointで実現しようとすると、いろいろ難しいですね。

ってのは、言い訳みたいなところもあるけれど、こだわりというか・・・自分でブレーキをかけているのは分かるんですけどね～

ノーツって一つの掲示板を作るために、デザイナーツールを使う必要があって、このツールが最上級の機能を提供しているため、利用者の能力によって様々な掲示板というかアプリケーションを作ることができる。これはとってもいいことで、ちょっとこの項目を右に寄せたいよな～なんて思ったら簡単に実現できるし、この項目は○○のデータを引用して加工して代入することもできる。だからいつの間にか多機能な掲示板に発展(暴走)してしまう。

それに比べ、SharePointはWeb設定、SharePoint Designer、Visual Studioの3つから選ぶことになる。Web設定だけで実現できることは限られているので、必要な項目を追加、変更することは出来ても、プログラミングみたいなことはできないから、暴走してしまうことはあまりない。

基本機能で満足できない時にDesignerを使うことになるんだけど、Designerでカスタムフォームを作っても、Web上で列を追加したり変更したりすることができるので、フォームに存在しない列が出来たりすることがある。

だから、フォームのカスタマイズはあまりしない様にしたいなぁ～という意識が生まれてくる。

ノーツで当たり前のようにやってたフォームの編集や@関数だと書くの大変だから、Lotus Scriptで書いちゃえ！！みたいなことが、やったらダメ！！みたいな感じになって、自分の首を絞める。

ノーツだったらもっと早く、簡単にリリース出来ているよなぁ～と比べてしまい自己嫌悪。

「選べる」ことはいいこと反面、「選択が必要」なので、いろいろ考えてしまってなかなか前に進めない。

優柔不断な人間にとって、選択するって大変なんだよ～

とりあえず、SharePoint はDesignerで設定したリストはWebで設定できない様にロックをかけてくれるとありがたいなぁ～と思うのでした。

古い楽天市場系APIがやばい

私の管理するSharePointで使っている図書一覧で画像を表示するためのスクリプトに影響があるみたいです。
「api.rakuten.co.jp」で提供しているAPIの廃止について

今使っているAPIはまさに対象となっているバージョン。きっと忘れたころに動かなくなって気が付くんだろうなぁ～
気が付くほど利用頻度があればいいのですが・・・

ってことで、対応作業を行いました。
ただね、JSONP形式の応答内容がガラッと変わっておりまして、新しいアドレスに変更しただけだとまったく動かない。
エラー処理関係も違うので、ほとんどの場所を書き換えることに・・・

使っているAPIの管理ってのも必要ですよね～。

Webパーツよ、もっと目立て！！

久々ですね。相変わらずSharePoint2010が対象です。
SharePoint2007を使ったことがあるユーザーが2010を見ると色のメリハリがなく見難くなったとのご意見をよくいただきます。2013になったらもっと色は薄いですよ～って見せると、フォントサイズと余白のメリハリがしっかりしていて意外と好評。

ってことで、SharePoint 2010の画面を見やすくするためのチョイカスタマイズを紹介します。今回はWebパーツのタイトル部分の背景に色を付けてパーツの始まりを目立つようにしたいと思います。

結構ありふれたカスタマイズなので、一工夫して設定したテーマに合わせて色が変わるようにしてみました。方法はいろいろあると思うけど、パッと見のわかりやすさということで、jQueryを使っています。

<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.10.2.min.js" type="text/javascript"></script>
<script type="text/javascript">
 _spBodyOnLoadFunctionNames.push("getbgcolor");
 function getbgcolor(){
  var color = jQuery('div.s4-title').css('background-color');
  jQuery('TR.ms-WPHeader').css('backgroundColor',color);
 };
</script>

とりあえず、採用したい色を設定しているタグを探し、背景色を取得することから始めます。取得する方法はいくつかあると思うのですが、s4-titleクラスから取得することにしました。
次に取得した色をタイトルのセルを含むテーブルの行の背景 tr.ms-WPHeaderに設定します。

最後に適当な場所にコンテンツエディタWebパーツを設置し、このスクリプトを入力すればOK。

これで設置後にテーマを変更されても大丈夫ですね！！

Webパーツに影を付けたらかっこいいかも！！とか思ってるのですが、これについてはもうちょっと研究が必要なようです。

メールの延長

NotesからSharePointへの移行において、大変だよね～といわれるのが、ワークスペース上のアイコンとか未既読の扱い。

未既読。

ユーザー視点で一番目につく最も困るのが未読数と未既読表示だと思います。

Notesではワークスペース上のアイコンに未読数が表示され、どのアイコンを開くべきなのかが一目瞭然。掲示板を開けば未読文書は赤く表示されるので、読むべき文書も一発で分かります。

この未既読機能を中心に業務を行っているといっても過言ではないでしょう。この未既読がないSharePointに移行した時、ユーザーは口をそろえて新しい、更新された文書がどれかわからないと言います。メール通知やOutlook連携など作成や更新の情報を受け取ることができる機能はありますが、Notesのシンプルさはありません。

SharePointを推進する立場からすると、どうにかして乗り越えたい課題です。
どうすれば乗り越えられるのか？

Notesの脅威ともいえる未既読ですが、いくつかの問題を抱えていると考えています。

まず、編集によって未読になるってこと。
普通の編集は便利なんですよ。以前確認した文書が編集されたことを気が付けるので、情報の取得漏れがないんです。でもね、文書の有効期限の変更や非表示項目の変更、何も変更せずに保存したとかでも未読に切り替わるんです。これらの変更はユーザーには一切関係なく、改めて読むものじゃない。作業依頼の文書だったりしたら、その作業を再実施してしまうユーザーもいます。そして問い合わせが来る。未読表示の悪い点です。

次に、メールと掲示板の役割が明確になっていない。
本来、相手に伝えたいことはメールで確実に伝えるべきだと思うのですが、未読表示を使うことで、メールを使わなくても、相手に伝えることができるのです。（はい、便利です）
伝える相手が1人ならメール、複数なら掲示板という感じになります。
掲示板を使うと同時に通知も完了するので、掲示板を使ってすべての情報をNotesに集めようよ！！ってのが簡単に実現できます。それ自体はグループウェアの目的であり問題ないのですが、あまりにも掲示板が便利すぎて、メールで通知すべき内容が掲示板に記載されることが多いのです。
ず～っと使っているユーザーはさほど問題ないのですが、新規ユーザーは有効期限の切れた情報も未読になっており、過去の経緯なんて要らないのに読んでしまいます。そして、過去の間違った情報をもとに行動してしまう可能性もあるのです。

Notesを使っていくってのは、ユーザーは未読数を0にすることが仕事で、それがメールだろうが掲示板だろうが何でもよくて、未読文書を読んで仕事をして未読数が0になると仕事が終わる。そういう仕事の仕方を永遠に続けていくってことなんだよ～

今見る必要がない情報だってたくさんあるはず。未既読に依存するってことは、届いたメールはすべて、スパムメールも内容も確認していますってのに似ているんじゃないかと。

情報の伝達と蓄積を分けることができたら、うまく乗り越えられるんじゃないかと思ってます。
どうやって説明し、実現するか。まだ答えは見つかっていないですけど・・・

補足：未既読に依存する事が問題では？との仮説であって、Notesがダメってことではありません。

Export,Import-SPWebのちょいテク

もっと良いほかの方法があったらごめんね。

リストやディスカッションの移動を行うとき、PowerShellのExport-SPWebコマンドレットを使ってエクスポートして、移動先のサイトにインポートするのが通常の作業だと思いますが、リストやディスカッションをインポートするときのItemURLがエクスポート元のURLを引き継ぐ仕様で困ったことってありませんか？

初期のアイテムだと /List/List1/ だったりして、移動先にもすでにList1があって、どうすれば～～とか悩むことがあるかもしれません。または別の名前に変更したいとか

そういう時は Export-SPWeb で -NoFileCompression パラメーターを付けてエクスポートすると、アイテム個々のファイルといくつかのXMLファイルが生成されます。

でXMLファイルの中を見ると /List/List1/ など移動元のItemURLが記述している場所がいくつかあるので、これを新しい名前 /List/NewList/ とかに置換してからインポートすると、そのURLでリストが作成されます。

これで綴りを間違ったりしたときもこれを使って修正することもできますね。

IEでF12を押せ！！

SharePointでjQueryやCSSで画面カスタマイズを行うときは、目的のタグを指定することが重要です。
これができないと、的確な場所を制御できないので、いらんところまで変化してしまうので、カッコ悪い状態になってしまいます。
ってことでどうやってその目的のタグを指定するかってことですが、Internet Explorerには管理者ツールってのが用意されてまして、これを起動するのがF12なんですね。
まぁ、とりあえず、F12を押してみてください。

あとは、マウスカーソルのアイコンをクリックして、目的のタグがあると思う場所をクリックすれば、HTMLソースの該当部分を開いてくれます。
その前後を見て、タグの構造やClassやIDを調べ、それしかない組み合わせをセレクターとして指定すれば成功。
うまくいくまで頑張れば、目的の場所だけ装飾したりすることができます。
まぁ、これが面倒なんですけどね。
ちなみにトップリンクバーは .menu-horizontalでサイドリンクバーは.menu-verticalの中に記述されています。
本文部？は#MSO_ContentTableあたりで囲めばいいのかな？
この辺は目的によって異なりますけど・・・
頑張って探してください。

サイドメニューをアコーディオン化する

SharePoint2010のサイドメニューをアコーディオン化してしまうスクリプトを作ってみた。

基本的には使わないほうがいいと思うけど、管理されたメタデータのツリーが画面からはみ出てしまう場合、ちょっと小っちゃくなってくれると使いやすくなります。

2012/02/15 追記
SP改 by ANK(@SharePoint_X)さんからアドバイスツイートがありましたので、変更しました。

jQuery(document).Ready(～)では動かないことがあるので、_spBodyOnLoadFunctionNames.push("～");を使うほうがいいらしいです。
このコマンドの仕様が見当たらなかったのですが、みなさんこの記述にしていますね。
それにしても、セレクターが美しくない・・・

~~<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6.2.min.js"></script>~~
<script type="text/javascript">
jQuery(function(){
jQuery('div.menu-vertical ul >li > ul').hide();
jQuery('DIV.menu-vertical UL.root > LI').hover(
function(){jQuery('ul:not(:animated)',this).slideDown()},
function(){jQuery('ul',this).slideUp()}
);
});
</script>

オフラインでSharePoint

未読、既読やオフラインでSharePointを利用するにはSharePoint WorkspaceやOutlookとの接続機能を使いますが、リストやライブラリのテンプレートによって使えるアプリが異なります。

ってことで実際に調べてみました。

機能に違いがあるのは分かりますが、分担しなくてもいいのにって思います。