2014年12月09日

SharePoint 検証環境構築 〜Windows Server 2012 R2 その2〜

こんにちは、ソノリテの費です。

SharePoint 検証環境構築の続きです。
2台の Hyper-V 専用のサーバー機の環境構築を行っていますが、初号機の方に AD をセットアップしてドメインを構成しているので、弐号機をそのドメインに参加させます。


Sonorite Bullet 優先 DNS サーバーで名前解決出来ないサーバーへのドメイン参加

通常の環境において、DHCP で IP アドレスの割り当てされれば、DNS サーバーも紐づいて、その先にあるドメイン コントローラーにアクセス可能なはずなので、苦も無くドメインに参加させることが出来ますが、ネットワーク的に別セグメントであったり、既存ネットワーク上に独立したドメイン コントローラーを構成している場合、明示的にドメイン コントローラーを指定することで、ドメイン参加が出来るようになります。

具体的には、lmhosts の作成と、優先 DNS サーバーの明示的な指定になります。

lmhosts については、以下のような記述を追加します。

<IPアドレス> <サーバー名> #PRE #DOM:<ドメイン名>
<IPアドレス> "<ドメイン名> \0x1b" #PRE

IPアドレス: ドメイン コントローラーの IPアドレス
サーバー名: ドメイン コントローラーのサーバー名
ドメイン名: ドメイン名

2行目の " " (ダブルクォート) の中の記述の仕方は少々特殊です。

\0x1b の前は、合計で15文字になるように、ドメイン名の後ろにスペースで埋める必要があります。
例えば、sonorite というドメイン名であれば、以下のような記載になります。

192.168.1.1 "sonorite       \0x1b" #PRE

sonorite が 8文字なので、後ろにスペースを 7文字埋めます。

%windir%\system32\drivers\etc に lmhosts を保存したら、nbtstat -R で再読み込みを実行しておきます。

その他の詳しいことは、こちらのサポート技術情報を参照して下さい。

・TCP/IP および LMHOSTS ファイルを使用したドメイン ブラウジング
http://support.microsoft.com/kb/150800/ja

後は、ネットワーク アダプターのプロパティで、優先 DNS サーバーとして、ドメイン コントローラーの IP アドレスを設定するだけです。
元々の DNS サーバーについては、ドメイン コントローラーに構成している DNS サーバーにフォワーダーとして追加されているので、変更しても特に問題ありません。

network_property_ipv4.png

ちなみに、昔は、ドメイン構成して、DNS が構成された時に、自分でフォワーダーを設定していた記憶があるのですが、今は、勝手に、元々のネットワーク構成を取り込んで設定してくれるようです。


Sonorite Bullet IPv6 混在環境でのドメイン参加

昔は IPv6 のアドレス割り当てが無かったので意識しなかったのだと思いますが、IPv6 のアドレス割り当てがあると、Windows Server 2008 以降では、IPv6 の方が優先されるようです。
このため、上記の設定では名前解決に失敗して、ドメイン参加出来ないという状況が発生します。

このことに気が付くまで、しばらく悩みました・・・

恐らく、IPv6 を無効化するとか、IPv4 の方を優先させるとか、という設定を行えば良いのだと思いますが、今回は、IPv6 の優先 DNS サーバーを設定してしまうというアプローチで解決しています。

network_property_ipv6.png

こちらに、ドメイン コントローラーの IPv6 の IP アドレスを優先 DNS サーバーに設定します。

IPv6property3.png

これで、ようやくドメイン参加が完了。
分かってしまえば、何のことはないのですが、1カ月半前に、この問題を解決するのに 2時間以上掛かってしまった・・・


ここまでで、ようやくドメイン参加の設定が終わります。

次は、Hyper-V を使うための設定などになりますが、続きは、また次回ということで・・・


Kokuho Hi (Sonorite / SharePoint Technology Center)


posted by kunitaka at 14:26| Comment(0) | テクニック

2014年12月06日

SharePoint 検証環境構築 〜Windows Server 2012 R2 その1〜

おはようございます、ソノリテの費です。

検索小話が続くかと思いきや、諸事情で滞っていた SharePoint 検証環境の構築を再開したので、遭遇したポイントを書いておきます。


Sonorite Bullet オンボード Intel 82579V Gigabit LAN コントローラ

私の所有している検証用 PC には Intel X79 Express チップセット マザーボードが使われています。
Intel X79 Express チップセット マザーボードに搭載されている 82579V Gigabit LAN コントローラのドライバーがサーバーでは認識されないんですよね。
これは、Windows Server 向けのドライバー定義が含まれていないためです。

仕方が無いので、以下よりドライバーをダウンロードして、展開した後に定義ファイルを修正して認識されるようにします。

・Network Adapter Driver for Windows Server 2012 R2
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23073&lang=jpn&ProdId=3299

ダウンロードした PROWinx64.exe を実行すると、解凍後にセットアップが実行されてしまうので、解凍ソフトで解凍しておきます。

解凍後の \PRO1000\Winx64\NDIS64 フォルダ内にある e1c64x64.inf ファイルを開いて、以下のように編集します。

・[ControlFlags] セッションの 3行をコメント化
・[Intel.NTamd64.6.3.1] セクションの %E1503NC.DeviceDesc% で始まる4行を [Intel.NTamd64.6.3] セクションの下にコピーします。

inf_file_update.png

後は、以下のコマンドを実行してマシンの再起動を行います。

bcdedit -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit -set TESTSIGNING ON

デバイスマネージャーから、ネットワーク アダプターのドライバを更新します。

その後、以下のコマンドを実行してマシンの再起動を行います。

bcdedit -set loadoptions ENABLE_INTEGRITY_CHECKS
bcdedit -set TESTSIGNING OFF


ちなみに、こちらの記事が参考になります。

・Enable Intel 82579V NIC in Windows Server 2012 R2
http://www.alexanderchen.net/2014/07/31/enable-intel-82579v-nic-in-windows-server-2012-r2/

これで、ネットワーク アダプターが認識され、ネットワークが利用可能な状態になります。


Sonorite Bullet ネットワーク共有をパブリックからプライベートに変更する

ネットワーク アダプターが認識されて、ネットワークに接続出来るようになった時に、ネットワーク種別がパブリックになっている場合があります。
これをプライベートに変更するには、Windows Server 2012 R2 では、「ネットワークと共有センター」で変更出来なくなっているようなので、ローカルセキュリティポリシーで変更します。

「ローカル セキュリティ ポリシー」を起動して、「ネットワーク リスト マネージャー ポリシー」を選択して、該当するネットワーク名のプロパティを開きます。
「ネットワークの場所」タブを選択して、「場所の種類」で「プライベート」を選択して、「OK」を選択します。
最後に、gpupdate /force を実行して、ポリシー適用を反映させます。

細かい手順については、こちらのページが参考になります。

・Windows Server 2012 R2でネットワークの種別(NetworkCategory)を変更する方法
http://kiyokura.hateblo.jp/entry/2014/03/09/154551

これで、ネットワーク種別をプライベートに変更出来ます。


Sonorite Bullet ping 応答 (ICMP 通信) 有効化

次に、ネットワークの疎通確認をするための設定です。
OS セットアップ終わったばかりの素に近い状態だと、ping 応答返してくれないので、まずは、これを有効化しておきます。
今時は IPv4 と IPv6 の両方に対応しておいた方が良いかもしれません。

設定は、「セキュリティが強化された Windows ファイアウォール」になります。
こちらの「受信の規則」に対して、「ICMPv4」と「ICMPv6」のプロトコルに対して接続の許可を行います。

WindowsFirewall.png

細かい手順については、Windows Server 2008 の画面ですが、こちらのページが参考になります。

・Ping 応答を許可する
http://www.server-world.info/query?os=Windows_Server_2008&p=first_conf&f=7

これで、ping が通るようになります。


ここまでで、ようやくネットワークの基本的な設定が終わります。

次は、初号機にドメインを構成して、弐号機をドメイン参加させるのですが、続きは、また次回ということで・・・


Kokuho Hi (Sonorite / SharePoint Technology Center)


posted by kunitaka at 10:44| Comment(0) | テクニック

2014年12月02日

検索小話 (検索結果 Web パーツ)

こんばんは、ソノリテの費です。

ここ最近、検索カスタマイズの仕事をしていました。

コンテンツ Web パーツの 表示テンプレートは、今までにある程度、触っていましたが、今回、検索に関する表示テンプレートを初めて、本格的に取り組みました。
今回は、表示テンプレートについてではなく、検索リクエストについてのお話です。

検索結果ページを編集すると分かりますが、検索結果の一覧は、「検索結果」Web パーツによって表示されます。
ひと検索の場合は、「ひとの検索の主要結果」Web パーツですね。

この 2つの Web パーツの実体は同じで、ResultScriptWebPart で構成されています。

・ResultScriptWebPart class
http://msdn.microsoft.com/en-us/library/microsoft.office.server.search.webcontrols.resultscriptwebpart(v=office.15).aspx

実際には、Web パーツの設定で、クエリの選択 (検索先) などで、異なる設定が埋め込まれていて、それによって動作の違いが生まれています。

さて、今回は、ひとの検索のカスタマイズを手掛けていたのですが、検索リクエストや検索結果を確認する時に、有用なツールと言えば SharePoint 2013 Search Query Tool ですね。
いつの間にか、バージョンが 2.2 になっていました・・・

・SharePoint 2013 Search Query Tool
https://sp2013searchtool.codeplex.com/

SharePoint 2013 Search Query Tool

このツールは、SharePoint 2013 で提供されている検索 REST API を利用しているので、リモートからリクエスト出来るので、オンプレミスでも SharePoint Online でも使えるという点でとても良いツールです。

・SharePoint 検索 REST API の概要
http://msdn.microsoft.com/ja-jp/library/office/jj163876(v=office.15).aspx

前職時代に関わった案件でも、開発段階からトラブルシューティングまで、かなりお世話になったものです。

唯一の難点?を挙げるとしたら、お客様環境などで、勝手にダウンロードして実行出来ないようなシチュエーションでは利用出来ないことです。
まぁそんな時はブラウザ上で、直接、検索 REST API をリクエストすれば良いので、致命的に困ることは無いです。

普通に、以下のような URL に対して、検索キーワード等のパラメータを指定するだけです。

http://<サーバー名>/_api/search/query

検索 REST API 実行結果


そんなこんなで、いろいろとカスタマイズを実装していると、今まで、全く意識していなかったのですが、ひとの検索では、通常の文書の検索と違って、微妙にパラメータが異なることに気が付きました。
既定の「ローカル SharePoint の結果」検索先にはユーザープロファイルは含まれていないので、検索先が異なるのは当たり前なのですが、検索結果の内容に影響がある設定としては、ひとのあいまい検索、および、重複の削除でしょうか。

通常の文書検索では、ひとのあいまい検索は無効で、重複の削除は有効になっています。
そして、検索 REST API での既定の設定はこの文書検索と同じになっているようです。

実際にひとの検索の検証やテストしていて、検索結果ページでの結果と検索 REST API での結果に相違があって、どうにもこうにも悩んでいた所、気が付いた訳です。

ところで、「検索結果」Web パーツの設定は、Web パーツの編集での、Web パーツの設定だけだと思っていますか?

検索結果 Web パーツ設定1
検索結果 Web パーツ設定2
検索結果 Web パーツ設定3

いやいや、検索での重要なパラメータは、Web パーツ定義ファイルの DataProviderJSON というプロパティの中に隠れています。
検索結果」Web パーツと「ひとの検索の主要結果」Web パーツでの違いについては、こちらの通りです。

検索結果 Web パーツ DataProviderJSON プロパティ比較

この中で、EnablePhonetic と EnableNicknames がひとのあいまい検索の設定で、TrimDuplicates が重複の削除の設定です。
ちなみに、重複の削除については、2014年7月 CU の適用により、「クエリの変更」から「設定」タブの中で UI 上で設定変更可能になっているようです。

例えば、ひとのあいまい検索を無効化するには、Web パーツをエクスポートして、Web パーツ定義ファイルの該当箇所を修正した上で、Web パーツのアップロードによりインポートすることで、変更を反映することが出来ます。
なお、この時に操作方法によっては、「絞り込み」Web パーツと「検索ボックス」Web パーツの設定で、「検索結果」Web パーツとの関連付けが失われることがあるので、その場合には、再設定が必要になります。

この他に、興味深い設定として、FallbackLanguage というのがあります。
こちらは、既定では -1 になっていて、ブラウザの言語の優先順位に従って自動的に言語が選択される形になりますが、明示的に ロケール ID を設定すると、指定した言語を固定して検索させることが出来ます。


ということで、小話と言いつつ、少々書き過ぎたような気がしますが、しばらく、検索小話は続く予定です。


Kokuho Hi (Sonorite / SharePoint Technology Center)

posted by kunitaka at 18:29| Comment(0) | テクニック