"SharePoint 2013" にカテゴリー登録されている115 投稿

[SharePoint] Wiki ページライブラリの "ホームページ" について

SharePoint 上でチーム サイトを作成すると Wikiページライブラリが 「サイトのページ」という名称で自動作成されます。Wikiページライブラリはサイト内に複数追加できるため、用語集、製品情報などの情報で分類したりもできます。

さて、この Wiki ページライブラリには "ホーム ページ" があります。"ホーム ページ" というと、インターネットに公開されているWebサイト全般のことを思い浮かべる方も多いかもしれませんが、"最初に表示されるページ" という狭義が本来あります(厳密にはサイト内の特定のページまでアドレス指定しなくてもサイトのURLまで指定すれば勝手に表示される既定のページです)。

Wiki ページ ライブラリを新規に追加すると次の 2つのページが同時に自動生成されます。

  • ホーム.aspx
  • このライブラリの使用方法.aspx

このうち、ホーム.aspx が Wiki ページ ライブラリのホームページであり、Wiki ページライブラリのURLまで指定したときに最初に表示されるページとなります。サイドリンクバーなどに[最近使った項目]見出し配下に表示される Wikiページ ライブラリのURLをクリックすると既定では ホーム.aspx が表示されます。

さて、ここから開発面でのお話です。

Wiki ページライブラリのRootFolderオブジェクトには WelcomePageプロパティがあります。新規作成のWikiページライブラリなどは既定値が "ホーム.aspx" になっています。この値は変更できるため、同一ライブラリ内の任意のWikiページをホームページとして設定できます。たとえば、「Wikiページライブラリのホームページとなるページのタイトルが常に "ホーム" と表示されるのは、サイトのホームページと混同するので変えたいといったニーズがあれば、知っていると役立ちます。

JavaScript Object Model の例)

//Wiki ページライブラリのホームページの確認
...
var ctx=new SP.ClientContext();
//リストのオブジェクトを取得
var list = ctx.get_web().get_lists().getByTitle("Wikiページライブラリの名前");
var rootFolder=list.get_rootFolder();
ctx.load(rootFolder);
ctx.executeQueryAsync(function(){
//成功時のハンドラ
alert("結果 : rootFolder.get_welcomePage());
//set_welcomePage()メソッドの引数に任意のページを指定すればよい。最後RootFolderのupdate()メソッドを忘れずに!
},
function(){//失敗時のハンドラ});

[初心者向け] SharePoint の種類を把握しよう !

最近 SharePoint の種類について同じような説明をする機会が増えたので、念のためブログにも記載しておきます。あまりシステムに詳しくない方向けです。

SharePoint には次の2種類があります。

  • オンプレミス : On-premise (社内設置) 版
  • クラウド版

SharePoint Server 2013 や SharePoint Server 2016 といった "Server" と名前がついているのはオンプレミス版の SharePoint です。オンプレミスとは、自社内にサーバーを構築しメンテナンスなどは自社内で行います。

一方クラウド版は SharePoint Online というサービス名となっています。クラウド版は、平たく言えば、Microsoft 社がクラウド環境に SharePoint サーバーを構築し、インターネット越しにサービスを利用できるようにしているものです。ですから、サーバー自体のメンテナンス等はMicrosoft社任せであり、機能更新などが継続的に行われています。SharePoint Onlineはこのサービスだけを単独で契約することもできれば、Office 365 Business, Office 365 Enterprise などのような契約プラン内に含まれている場合もあります。実際に利用されているケースでは、後者が多いようです。ちなみに、他のサービスとしては Exchange Online や Skype for Business Online 、最新の Office クライアント アプリケーション(Word, Excel, PowerPoint) などがあります。Exchange Online が利用できると Outlook と組み合わせて電子メールが利用できたり、個人の予定を管理したりできます。Office 2010, 2013, 2016 に含まれている Outlook とは別に、Web版のOutlook があり、これは Outlook on the Web と呼ばれますが、 Exchange Online を契約しているとこれも利用できます。

SharePointVersions1

オンプレミス版とクラウド版ではそれぞれ良し悪しがあるため、組織によってはどちらか一方を使っていたり、組み合わせて利用していたりします。たとえば、大きな違いとしては、オンプレミス版の場合は、インターネット越しに利用させないようにしているケースも多く、社外から簡単にはSharePoint サイトにアクセスできないようになっていたりします。一方のクラウド版はインターネットへの接続環境があれば、原則、どの端末からでもアクセスできます (最近、SharePoint Online も特定のネットワーク環境からのアクセスを制限する設定もできるようになったため、"原則"と書きました)。たとえば、カフェや空港などにあるインターネット接続端末からアクセスしたり、iPad, iPhone その他、携帯端末からも Webブラウザーがあれば、アクセスできます。もちろん、ユーザー認証が必要であるため誰でもアクセスできるという意味ではありません。

さて、機能的な視点で補足しておきましょう。少し技術的な話です。

現在のSharePoint Online は、もともとは SharePoint Server 2013 がベースとなっていたため、利用できる機能も画面操作もオンプレミス版の SharePoint 2013 と当初はあまり変わりませんでした。逆に、SharePoint Online の方がいくらか利用できる機能が制限されている面もあったのです。しかし、クラウド環境である利点を生かし、SharePoint Onlineは継続的に機能アップデートを続けて進化しており、現在は SharePoint Online や Office 365 と組み合わせないと利用できない機能が多くなってきています。そして、昨年春に登場した最新のオンプレミス版の SharePoint が SharePoint Server 2016 です。このバージョンは、SharePoint Online のノウハウをそのままオンプレミス環境で利用できるようにしているものであるため、利用できる機能や見た目が SharePoint Online に近いものになっています。ただし、社内設置型は頻繁にアップデートされるわけではないため、SharePoint Online の新機能の一部は SharePoint Server 2016 には搭載されていなかったりするのです。たとえば、このブログでもよく取り上げている、モダンUIなどへの対応はほんのごく一部です。

SharePoint Server 2013 も 2016 も1か月ごとに、主にバグ修正を行う更新プログラムが提供されています。ただし、SharePoint Server 2016 には特殊な更新プログラムである Feature Pack が適宜提供されるようになっており、これを適用することで SharePoint Online や Office 365 で提供されている機能の一部が使えるようになるような大幅な機能拡張がされるようになっています。最初の Feature Pack は 2016年11月に公開され、これにより SharePoint Server 2016 の OneDrive for Business にのみモダンUIが導入されています。今年も、Feature Pack が提供される予定となっているようです。

SharePointVersions2

 


分散キャッシュのサービス アカウントの変更

SharePoint Server 2013 以降では分散キャッシュサービスが導入されています。

分散キャッシュサービスの既定のアカウントはファームアカウントであるため、必要に応じて変更します。Health Analyzer はこの状態を検知し、他の管理アカウントに変更するようにメッセージを表示します。

2016-10-18_7-32-27

分散キャッシュサービスのアカウントはサーバー全体管理サイト>[セキュリティ]>[サービス アカウントの構成]で確認できます。

2016-10-18_7-36-28

しかし、この画面からアカウントを変更しようとするとエラーになります。分散キャッシュのアカウントはPowerShellから変更する必要があるためです。

2016-10-18_7-16-46

変更には次のコマンドを実行します。

$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}
$accnt = Get-SPManagedAccount -Identity domain_name\user_name
$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$cacheService.ProcessIdentity.ManagedAccount = $accnt
$cacheService.ProcessIdentity.Update()
$cacheService.ProcessIdentity.Deploy()

[出典] https://technet.microsoft.com/en-us/library/jj219613(v=office.16).aspx

 

 


継続クロールを指定しても増分クロールが実行される理由

SharePoint 2013 から導入された検索サービスの継続クロールですが、これを設定すると既定では15分間隔でクロールが実行されます。対象は SharePoint 上のコンテンツに限ります。ところが、この設定をしても必ず4時間おきに増分クロールがスケジュールされます。これはな何をやっているのか?

2016-07-15 10-48-54

カギはユーザー プロファイルの検索にあります。ユーザー プロファイルは継続クロールの対象外であり、必ず増分クロールでないとインデックスが生成されないそうです。ちなみに、ユーザー プロファイルはフルクロールでもダメ。必要なのは増分クロールです。

つまり、ユーザー プロファイルを更新しても最大4時間待たないと検索結果に反映しないということ。

これは、SharePoint 2016 でも同様で、何より SharePoint Online も該当します。オンプレミスであれば、4時間おきですし、ファーム管理者が適宜必要なタイミングで増分クロールを実行することもできます。やっかいなのが、SharePoint Onlineです。こちらは、夜間は2時間おき、日中は最大8時間だそうですが、その日中が日本時間とは限らないため全く読めません。

結論としては SharePoint Online の場合は、ユーザープロファイルを更新してから結果が反映されるまで「一晩の寝かせる」くらいの感覚でいた方がよさそうです。漬物みたいですけどね。以前、SharePoint Online でユーザーの検索結果のカスタマイズを試していて、はまりまくりました。皆さんもお気を付けください。

[参考]

Course-Banner-SearchShort
 


[SP2013] トラブルシューティング : 突然 SharePoint サイトにアクセスできなくなる

昨日、研修用のデモマシンで突然 SharePoint サイトにアクセス出来なくなるトラブルに遭遇したため、備忘録として、その経緯を記載しておきます。トラブルシューティング方法の流れを確認するには参考になるのではないかと思います。

※とはいえ、これは滅多にないと思いますが。ちょうど先週はサーバー内部のファイル構造などを説明する研修を行っていたので(SharePoint Server 2013 周辺技術の基礎コース) このときデモしながら、なんか、やってしまったかも。

現象と調査過程

サーバー全体管理サイトをはじめ、すべてのSharePointサイトにアクセスできなくなる。しかも、アクセスすると 404 エラーで、サーバーにはアクセスできたが、指定したファイルがないという。

2016-06-21 5-14-34

そこで、何が起きたのか確認しようとまずイベントログを見るが特に問題は上がっていない。そこで、早速問題の切り分けを試みた。

  • ネットワーク設定は正常か
  • IISは正常に稼働しているか
  • SharePoint の DB 側は正常に稼働しているか

ネットワーク設定に問題がない。IISについては、新規に単純なIISサイトを作ってアクセス出来るか確認すると問題がない。アプリケーション プールも正常稼働している。アプリケーション プール IDも変更はない。ということは、SharePoint Web アプリケーションが使っている仮想ディレクトリにはアクセスできるということか? たとえば、<サイトURL>/_layouts/15/Images/spcommon.png などを試すと、アクセスできる。ということはサイトの設定ページにはアクセスできるということ。 <サイトURL>/_layouts/15/settings.aspx などはOK。

では、念のためDB側はどうか。アプリケーション プールIDに対して各SharePoint DBが持つべき権限を確認する。他ファームの正常なサーバーと設定比較しても、これも問題ない。次に、PowerShell から、サイトコレクションやサイトのオブジェクトを取得してみる。これも問題ない。サイトの設定変更など試みる。これも問題なくできる。ということは、SharePoint サーバーのIIS 経由でのアクセスがだめなだけで、SharePoint の本体であるDB側は問題ないよう。念のため、手持ちのSharePoint Server Side Object Model を使って作っているアプリで、サイト内のアイテムなども取得出来るか確認するがこれも問題ない。

イベントビューアにもSharePointに関するクリティカルなエラーは出ていないため、となると、やはり IIS 側が怪しい。IISに関わるローカルグループの設定も確認する。ローカルの IIS_IUSRSグループメンバー、WSS_WPGグループメンバーなど設定は既定のままだ。そこで再び、サイトの設定ページにアクセスする。サイトの権限設定ページをクリックすると、エラーとなった。

2016-06-21 5-18-05

ここで関連付けIDを得られたので、当該する日付のSharePoint の URL ログを確認してみる。先ほど得た 関連付けID を元に一致する Correlation ID を持つログを確認する。どうやら seattle.master を探しに行って見つからなかったといっているようだ(ついでに、SharePoint 2013 だけでなく、過去のサーバーエディションのフォルダーも想定して探しに行っていることがわかって驚いた。15は SharePoint 2013 だが、14は SharePoint 2010 、12は SharePoint 2007, 60は SharePoint Portal Server 2003用のディレクトリ) 。

2016-06-21 5-22-08

このファイルが存在しているか、確認してみたほうがよさそうだ。ということで、 SharePoint ルートディレクトリをたどっていくと、Global フォルダーごとごっそりなくなっていた。これが原因か? ゴースト化されたマスターページが参照出来なかったので、404 エラーとなっていたといこうとでつじつまも合う。

解決

他の正常稼働しているSharePoint ファームのサーバーから Global フォルダーをコピーし、デモ用マシンに再配置。これで、問題なく、どのサイトにもアクセスできるようになった。

ちなみに、今回のトラブルシューティングに関わるような内容を学べるのが、弊社オリジナルの "Microsoft SharePoint Server 2013 と周辺技術の基礎" コースです(ついでに宣伝です)。