SharePointが稼働しているサーバーに静的ドキュメント用のサイトを追加する。
ポート8080とかで追加するパターンが多いようなのでそれに倣う。
基本中の基本の設定と思うのだが、素人の悲しさ、やけに戸惑ってしまったのでメモしておく。
まずはドキュメント公開用のフォルダを作成。(D:\TEST)
IISマネージャを立ち上げ、「サイト」を右クリックして「Webサイトの追加」をクリック
「Webサイトの追加」ダイアログで以下のように指定。
サイト名：TEST
アプリケーションプール：DefaultAppPool
物理パス：D:\TEST
ポート：8080
アプリケーションプールはサイト名と同じ名前で新規に仮定されるが、分けるほどではないと思うのでここでは「DefaultAppPool」に突っ込む
TESTフォルダの中に適当なHTMLファイルを置いて参照してみる。
とりあえず良さそう
次に外部PCから確認
っと、デフォルトのままではダメぽ
FireWallですかね・・・。
さて、どうやって穴を開けるのか。
「FireWall.cpl」でファイアウォールを起動し、
現在稼働している「SharePoint」の受信規則を見てみると以下のようになっている。
これ自体を修正して「80」ポートに「8080」ポートを追加するという感じでもないので、別途新しい規則を追加してみる。
右側の操作ペインから「新しい規則」をクリック
「ポート」を選択して「次へ」
「特定のローカルポート」として「8080」を指定して「次へ」
「接続を許可する」を選択して「次へ」
規則の適用対象に「ドメイン」を指定して「次へ」
適当な名前を付けて「完了」
アクセス確認
OK
なお、どうやって作ったのか記憶にないのだが、ローカルユーザーにアクセス権の無いフォルダ（ドメインユーザーのみにアクセス権）があり、エラーとなるケースがあった。
IIS自体はローカルユーザー（IIS_IUSRS?)としてアクセスするので、このユーザーもしくはローカルのUsersグループにファイルアクセス権を付けておく必要がある。
めでたしめでたし、と思ったのだが、次の日試してみるとなぜか認証ダイアログが表示されて何を入れても通らない状態になってしまった。(><)
半日ほどああでもないこうでもないと調べた挙句やっと原因が判った。
実は、この手順を纏めているときはDefaultAppPoolを使っていたのだが、最終的に本物を作る時にはデフォルトのままサイト名と同じアプリケーションプールを使用してしまった。
直接的にそれ自体悪いことではないのだが、何かしらアプリケーションプールによっては（偶然？）今回のような現象を引き起こす不具合があるようなのだ。
TechNet Blogs
回避するためのパッチも出ているようだが、さしあたって実行アカウントを「NetworkService」にすることによって回避できるらしい。
なんともいただけない・・・。
「trustworthy」自体悪くはないのだが、それ以来権限に絡むMS製品の不具合は飛躍的に増えてトラブルばかり・・・。
ちなみに、「承認規則」で拒否に追加したサイトにアクセス不能になったりしても同じ現象（ログインできない）を引き起こすので注意が必要。
本番サーバーで突然こんな状態になったら大事故だな・・・。
