2014年6月6日金曜日

多言語対応のデフォルト言語について

サイト利用者のデフォルト言語を指定するには、サイトコレクション作成時に指定する必要がある。
※作成後は、変更できないと思う。

クライアント環境(IE10)の不具合

IE10のみ発生する不具合(IE7,8,9,11は問題なし)

○不具合内容
IE10のクライアントから、リストへアイテムを追加する際、「保存」ボタンが押下できない(押下しても応答しない)
※上記以外にもドキュメントライブラリにアイテムを追加できない、サイト作成時にエラーとなる等、多々問題があるよう。

○原因
Sharepointは、Asp.netベース(.NET Framework 3.5)で出来ており、クライアントから送信されるUser-Agnet 文字列を解析してブラウザーを判定する機能がある。その機能にIE10を解釈する処理が漏れており、発生する問題。

○修正パッチ
http://support.microsoft.com/kb/2600100/ja

2012年3月29日木曜日

リスト又はドキュメントライブラリに固有権限を付与する場合の注意

サイト内で、各リスト又は、各ドキュメントライブラリごとに固有の権限を設定したい場合、サイト自体に権限を付与せず、リスト又はライブラリにユーザー・グループを追加するとサイトの権限に「制限付きアクセス(Limited Access)」として自動的に登録される。

この動作は、サイトに最低限のアクセスが行えないと、目的のリスト又はライブラリにたどり着けないための仕様かと思う。
※リスト又はライブラリのURLを直打ちすれば別だが。。

この仕様のお陰で、権限管理は、各リスト、各ライブラリだけで行えば良いかと安易に考えていた。

しかーし、問題が、、
リスト又はライブラリで編集権限以上の権限を付与したとしても、アイテムを削除した場合、ごみ箱機能が利用できない。(そもそも、ごみ箱が見えない。)
なぜなら、サイトに対し権限が「制限付きアクセス」となっており、ごみ箱を利用できる権限がない。

よって、各リスト、ライブラリの編集権限以上を付与する場合、サイトにも同等の権限を付与する必要あり。

2012年3月9日金曜日

Search Server 2010 ExpressでPDFをクロール

MSさんのサイトで、SharePoint 2010でPDFをクロールする方法が掲載されています。
http://blogs.technet.com/b/sharepoint_support/archive/2011/04/01/sharepoint-2010-pdf.aspx

掲載例は、SharePoint標準のサーチサービスによる実現方法で、Search Server 2010 Expressでクロールする場合は、若干方法が違います。


1. PDF iFilter のインストール
2. ファイルの種類を追加する
3. レジストリを編集する
4. SharePoint Foundation Search V4 サービスを再起動する
5. PDF アイコンを追加する
6. 動作確認


上記の、「2.」、「3.」、「4.」を変更する必要あり。

「2.」の変更箇所
変更前) Set gadmin = WScript.CreateObject("SPSearch4.GatherMgr.1", "")
変更後) Set gadmin = WScript.CreateObject("OSearch14.GatherMgr.1", "")

「3.」の変更箇所(コマンドで追加するように変更)

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf" /t REG_MULTI_SZ /d {E8978DA6-047F-4E3D-9C78-CDBE46041603}

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.pdf" /v Extension /t REG_SZ /d pdf
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.pdf" /v FileTypeBucket /t REG_DWORD /d 1
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\Filters\.pdf" /v MimeTypes /t REG_SZ /d "application/pdf"

「4.」の変更箇所
変更前) spsearch4
変更後) osearch14

以上です。


2012年3月8日木曜日

リストにアップロード可能な添付ファイルのサイズ


ドキュメントライブラリも同様だが、デフォルトでは50MBとなっている。

設定変更は、「サーバーの全体管理」より対象のWEBアプリケーションを選択し、「全般設定」より「アップロードの最大サイズ」で指定できる。

しかし、指定したサイズ以下のファイルでも、アップロードしようとすると「予期せぬエラーが発生しました。」だって。
再現性を確認すると、50MB以上のファイルで発生する。ってことは、設定が反映(有効)になっていない?
そこで、調べてみると、MOSS又はWSS3.0で情報がありました。

助かります。
http://blog.sharepoint-factory.net/article/2532293.html

対象のWEBアプリケーションのweb.configも修正が必要とのこと。


サイズを200MBに設定したい場合
<httpRuntime  maxRequestLength="200000" />

さらに、利用環境で回線環境が貧しい場合、アップロードに時間がかかり、タイムアウトが発生する場合、下記のようにする。

※タイムアウトを30分(デフォルトは2分)

<httpRuntime executionTimeout="1800" maxRequestLength="200000" />


> MSさん
いつも思いますが、「予期せぬ・・・」の多用はやめてほしいです。
正しいハンドリングで、正しいエラー内容をお願いします!!


2012年1月31日火曜日

非AD環境にスタンドアロンで利用する場合のSQL Serverエディションについて

非ADでFoundationをインストールする選択肢は、スタンドアロン(単一サーバ)のみだが、その場合、同時にインストールされるDBは、SQL Server 2008 Express Edtionとなる。

Expressは、4GBまでの制限があるため、WorkGroup以上のエディションを利用したいと考え、Standardエディションを購入し、構築を試みた。

MSの推奨は、Expressのインスタンスは残したまま、構成データベースとコンテンツデータベースをバックアップし、Standard環境のインスタンスに復元し、SQL Serverの別名で、Expressのインスタンス名を割り当てる方法であった。

何故、こんな面倒な方法をとる必要があるのか?
SQL Serverのインストールセンターより、ExpressのインスタンスをStandardにアップグレードしてしまえば良いのではと考え、やってみた。

とりあえず、アップグレードは成功し、コンテンツにアクセスもできるし、特に問題がないように感じた。

っが、
何らかの変更やSP適用などで、構成ウィザードを実行すると失敗する。
その時は、原因わからず、Sharepoint自体を一度アンインストールしようとしたが、アンインストールも失敗する。
インストール前にOSのバックアップも当然なく、仮想環境であれば、スナップショット機能などで切り戻しができるが、実機のため、どうしようもない。(かなり冷や汗。。)

いろいろ弄くりまわした結果、
SQL Serverのインスタンスをアンインストールし、その後、Sharepoint自体のアンインストールを行ったところ、正常にアンインストールすることができた。

結論!
MSの推奨通りの構成にするか
又は、コンテンツデータベースのみ、Standardを利用するが良いらしい。

但し、今回の構築案件では、後日、AD化することとなったため、ファーム構成でStandardを指定し構築した。(ADにSQL Serverのインストールは、非推奨らしいが、そこは強行)


2012年1月30日月曜日

ログインが非常に遅い(遅かった)

初回ログイン(リサイクル後)が遅いのは、既知の事実ですが、毎回のログインが非常に遅く(最低20秒以上)、とても利用する気になれないレベルであった。

そこでハイブ配下のLogsフォルダのログファイルと睨めっこしてみた。
すると、ログイン処理後に以下のログがどうもログイン遅延の原因と特定

Leaving Monitored Scope (SPCertificateValidator.Validate).

開発環境というかVMで作った環境では、ログインはサクサク動き、上記のログも出力されない。

お客様のネットワーク環境のみ?なのかわからないが、対策をググったところ、海外で同様の事例あり。

対策方法は、以下の通り。

1.gpedit.mmcより「コンピューターの構成」-「Windowsの設定」-「セキュリティの設定」-「公開キーのポリシー」-証明書パス検証の設定を開く


「コンピューターの構成」-「Windowsの設定」-「セキュリティの設定」-「公開キーのポリシー」-証明書パス検証の設定


2.「ネットワークの取得」タブを開き、「これらのポリシーの設定を定義する」をチェックする。さらに、「Microsoftルート証明書プログラムで証明書を自動更新する」のチェックをはずす。


「ネットワークの取得」タブより


上記、方法で、「Leaving Monitored Scope (SPCertificateValidator.Validate).」のログは出力されなくなり、ログインもサクサクできるようになった。

ところで、「証明書パス検証の設定」ってなんだとう?詳しい方は、フォロー願います。。