カテゴリー別アーカイブ: Windows

Office Web Apps Serverでファイルを開くとエラーになってしまうときの対処法

現在、SharePoint Foundation 2013を用いたシステムを運用している。
Excelブック等のOfficeファイルを今時風にブラウザ上で閲覧、編集したいという要望が出てきた。
確かにSharePoint Onlineでできるのだから、Foundationでもできそうである。

調査したところ、Office Web Apps Serverを別途立てればできるということが分かった。
Office Web Apps サーバーの概要

ボリュームライセンスが要るので、個人ではまず無理だと思う。
幸いこの会社ではライセンスを持っていたので、Office Web Apps Serverを立て、ブラウザ上での閲覧、編集ができることを確認した。

しかし、運用して数ヶ月、突然「ブラウザーで閲覧」をするとエラーが発生するようになった。
エラー画面は
「’/x’ アプリケーションでサーバーエラーが発生しました。」
で以下、ランタイムエラーである旨が記述されている。

イベントログを見たが、SharePoint Server側には特にエラーはなかった。
が、Office Web Apps Server側にはアクセス毎にエラーログが出力されていた。
詳細な内容は割愛するが、「ファイルが見つかりません」というもの。

Office Web Apps Server自体、かなり資料が少なく、調査に難航したが、
何とか解決できた。
なお、既に数回この現象には遭遇しており、それぞれの対処法を記述する。

・再バインドする

調査したところ「Office Web Apps Serverを再インストールすればいい」という回答があった。
Web Apps Server ASP .NET error code 3005 event ID 1309 same key already added
しかし、今回、問題のOffice Web Apps Serverと連携している別のSharePoint Serverがあり、こちらは問題なく動作していた。
よって、これはOffice Web Apps Server側ではなく、SharePoint Server側に問題があると思われ、この回答は当てにならなかった。

さらに回答を辿ると、再バインドでも解消する場合があるという記載があった。
これに従い、以下のコマンドをSharePoint管理シェルから実行して再バインドを行った。
なお、Office Web Apps Serverを「OWA-Server.company.com」とし、SSL通信を前提とする。

なんと、これだけで解消した。
どんだけ不安定なソフトウェアなんだ。。。

・FWで弾かれている

上記対応から数日後、また再発したが、今度は上記の方法では解消しなかった。
途方に暮れていると、ネットワーク管理者がFWの設定を変更したとの情報が。
確認したところ、SharePoint Serverへのアクセスを特定部署のIPのみに制限していた。
一見問題なさそうなのだが、その結果、Office Web Apps ServerからSharePoint Serverへのアクセスができなくなり、
「ファイルが見つかりません」エラーが発生していた。

Office Web Apps ServerからSharePoint Serverへの443ポートを開放してもらい、問題は無事解決した。


MS製品の情報は少ないものもあり、あまり仕事という責任が伴う場では使いたくないのが正直なところ。
責任がなければ、色々実験できて楽しいんだけど。

IEのイントラネット識別方法

Internet Explorerでは、現在アクセスしているページが
以下のように4種類に分類される。

* インターネット
* ローカルイントラネット
* 信頼済みサイト
* 制限付きサイト

「信頼済みサイト」は手動で任意のサイトを登録して初めて分類される。
例えば、ある程度権限が無いと上手く動作しないサイトでは
ユーザーに予め登録をお願いし、セキュリティを弱くすることでサイトが正常に動作するようにすることができる。
「制限付きサイト」はその逆と考えて差し支えない(業務上、今まで使たことは無いが)。

ただ、そんなセキュリティを弱くしないといけないほどのシステムなんて、大抵は社内イントラネットだ。
なので、普通ならは信頼済みサイトへの登録なんてせずとも、自動でローカルイントラネットに識別され、システムは問題なく動作する。
(デフォルトでは「ローカルイントラネット」の方が「信頼済みサイト」よりセキュリティが弱く設定されている)

・・・と思っていたが、色んな会社を回っていると、どうもそうとも限らないらしい。
社内システムの筈なのに、IE上は「インターネット」に分類されている場合がある。
そこで、この分類され方について調べてみた。

何とこれ、実際にイントラネットかは全く判定していなかった。
URLに.(ドット)が入っていない場合は「ローカルイントラネット」、入っている場合は「インターネット」を分類しているに過ぎなかった。
FQDN または IP アドレスを使用すると、イントラネット サイトがインターネット サイトとして判別される

だから、社内システムでもURLが「http://CompanySystem.com」みたいになっている場合は「インターネット」識別になっていたのだ。
極端な話、hostsファイルを弄って「http://google」で「http://google.com」にアクセスするように設定去れば、
Googleのページすら「ローカルイントラネット」判定される。

いくら何でも雑な分類すぎませんかね。。。
まぁ、もうIEも消えてゆくはずだし、いいか。

Windows Server(Core)でエクスプローラを使う方法

Windows Serverは基本的にGUIがついているが、
Windows Server(Core)や、Hyper-V Server等、CUIしかないものも存在する。

これらはサイズも軽く、負荷も少ない(多分)という面で便利なのだが、
エクスプローラもないため、ちょっとしたファイルコピー、フォルダ権限付けを行いたいときもイチイチコマンドで行わなくてはならない。
共有フォルダなら外部のエクスプローラからアクセスすればよいが、そうでないとやはりコマンドでの実行になってしまう。正直、ちょっとした作業なのに一々コマンドを打つのも面倒だ。

ややハック的だが、Coreサーバーでもエクスプローラ(的)なものを使う方法がある。

1. コマンドプロンプトでnotepadと入力し、Enterを押下する
2. メモ帳が起動するので、「ファイル」の「開く」をクリックする
3. このダイアログ上でエクスプローラとほぼ同等の操作ができる

ちょっとした操作ならこの方がミスも少ないと思う。
ネットワークの共有フォルダを見たい場合は「ファイル名」の部分に「\\<アドレス>」を入力すればアクセス可能だ。
ex)\\TEST_Server

僕はcopyコマンドでコピー元とコピー先と間違える阿呆なので、この方法をよく使う。

IISRESETを行うbatが動かない・・・と思ったら(2017年初投稿)

本当に更新を定期的に実行するのは難しい。
今日は多分、今まででも1,2を争うレベルのくだらないミス。


WindowsでWebサーバーを構築する場合、
一般的にはIIS(インターネットインフォメーションサービス)を利用すると思う。
そして、キャッシュの開放や、IISで実行するコンポーネントを変更した場合には、IISを再起動するケースは多々ある。

IISの再起動は大変容易で、コマンドプロンプト(管理者権限)で
IISRESET
と入力し、Enterを押下するだけでよい。

夜間、定期的にIIS再起動行うするために、IIS再起動batを作成した。

間違えるような要素もないので、まず問題ないだろうと思っていた。
しかし、このbat、実行すると思うような動作をしてくれない。
下記のようになってしまう。

何故上手く実行されないか悩んでいたが、原因は単純だった。
ファイル名を「IISRESET.bat」にしていることが問題だった。
IISRESETにより、「IIS再起動」ではなく「IISRESET.bat」が再帰され、無限ループになっていた。

なので、「IISRESET実行.bat」とか、適当な名前に変更し、問題は解消した。


気付きそうで気付かないことろでした。これで1時間ぐらい悩んでしまった。。。

生存報告

ブログを放置しすぎた。
とりあえず、以前ちらっと書いたHyper-V Server 2012 R2の構成方法についてでも書くか。
・・・と思ったけど、結局は下記リンクを観たほうが手っ取り早いんだよね。
Hyper-V ServerをGUIで使い、仮想マシンを作成してみる

一応、プロビジョニングもどきのScriptを書いてみた。
参考程度に。

実際、仮想マシンを立ち上げて遊んだりしているが、もっぱらの用途はファイルサーバーだ。
Hyper-V Serverは無料だがファイル共有機能はついているので、これだけで簡易なファイルサーバー用途は十分に満たせるのだ。


最近は仮想マシンとしてにWindows Server 2012 R2 評価版を入れ、ドメイン構成したりSharePointインストールしたりと無意味なことをしている。
技術的な進展はない。

作ろうとしていた書籍管理DBも面倒くさくて停滞中。
ASP.NETを勉強して、入力フォームちゃんと作ろうかしら。

外付けHDDに常用ファイル置いて、それを毎晩ファイルサーバーにバックアップしているんだけど、
もう外付けHDDやめてファイルサーバーを常用化したほうがいいのかねぇ。
なんだか無駄な構成に思えてきた。


あと、そろそろ軽井沢に転勤になる。
本当は来月だったんだけど、会社の都合で再来月になりそう。
住居契約済ませたあとなのに、なんというタイミング。

まとまりねぇなぁ。

Windows ServerにGoogle Driveをインストールするときの注意点

以前の記事で触れたまま放置していたので一応書いておく。

Google DriveはWindows Server系は正式サポートしていないが、普通にWindowsクライアントのインストールが可能だ。
しかし、インストールした後、いざ認証しようとしてアカウントを入力すると以下のようになる。

GD

どうやらCookieが無効なようなので、有効化しよう。
・・・としても、これが何のブラウザなのかさっぱりわからないのでどうしようもない。

調べてみると、どうやらEdgeではなくてInternet Exploereとして動作しているようだ。
そこで、IEのインターネットオプションの設定を変更してみたが、どうもうまくいかない。

最終的に、
IEのhttps://accounts.google.com/を信頼済みサイトに登録する
という方法で解決はした。

要するにインターネットオプションのどこかでどこか設定不備があったのだろう。
しかし、どこだったのか。Cookie系の項目は全て有効にしていたと思うのだが。
どうしても腑に落ちないが、とりあえずこれで認証ができるようになったので、メモしておく。

Googleドライブはシンボリックリンクに対応しきれていない。

ファイルのバックアップのために、毎晩ローカルのファイルを自宅ファイルサーバーにコピーするように設定している。
しかし、自宅ファイルサーバーと言っても所詮は安物サーバーなので、完全に安心はできない。
そもそもローカルもサーバーも同じ「自宅」になる以上、自宅がどうにかなるともうだめである。

そこで、自宅ファイルサーバー(今はお試しを兼ねてWindows Server 2016 Previewを利用)の内容をさらにGoogleドライブにコピーするように設定しようとした。
結果としてできなかったのだが、それまでの過程を記述する。

  • 試行1 – Googleドライブにファイルコピーする
    単純にGoogleドライブのクライアントをサーバーにインストールし、
    ローカルのGoogleドライブ内にファイルをコピーしようと考えた。

    しかし、ファイルは1T近くあるため、こうするとバックアップのためだけに余分にもう1TBも
    容量をとられる結果となる。
    よって、これは却下した。

  • 試行2 – WevDavでGoogleドライブに接続する
    有料ソフトが多く、使ってみると実際はローカル上にファイルをおいているものもあり、却下した。
  • 試行3 – Googleドライブ内に同期したいファイルのシンボリックリンクを作成する。
    シンボリックリンクならファイルの実態は1つのままだし、
    作成も容易なので、コレでうまくいくと思った。

    実際、Googleドライブ内にシンボリックリンクを作成したところ、
    アップロードが実行された。

    これで問題解決、と思ったが、そううまい話ではなかった。
    初回同期後、ファイルを変更したり、追加、削除しても、Googleドライブには一切同期されなかった。
    やはり、ファイルの実態がないため、同期が働かないようだ。
    よって、これも却下となった。

  • 試行4 – Googleドライブをファイルサーバーパスに設置する。

    多分、これが最善策です。
    ただ、ファイルサーバーのファイル階層が変わるのが嫌なので敬遠している。
    バックアップスクリプトも変えなきゃだし・・・
    まぁ、今夜にでもやってみようかな。


ちなみに、Windows ServerにGoogleドライブをインストールすると、実はログインで躓く。
そうそう需要のある操作ではないかもしれないが、このあたりは今度書いておこう。

KB3114399でKB3055034の不具合が修正された

Windows UpdateによりOfficeファイルがWebDAVで開けなくなる問題だが、
ようやくMicrosoftが修正アップデートをしたようだ。

https://support.microsoft.com/en-us/kb/3114399

一応、直ったという報告もある。
https://www.reddit.com/r/sysadmin/comments/3vzmia/kb3114399_fixes_sharepoint_office_web_integration/

自分の環境ではまだ試せてないので、試してから追記する。


検証した。
どうやら問題なくWebDAVでのファイルオープンや保存ができるようになった模様。
[解決] KB3055034 適用後、Office 2010 アプリケーションがクラッシュする問題について


追記(2015/12/14)

自分の環境では再現できていないが、一部環境では「名前をつけて保存」時にまだ不具合がある模様。
HOME-BOX2
(「【HOME-BOX2】Office 2010 WebDAV接続不具合に関するご案内(12/10)」の項)

う~ん。これは困った。


追記(2016/02/24)

上記現象もKB3114750でようやく解消した模様。
https://support.microsoft.com/ja-jp/kb/3114750
よかったね。おめでとう。

Hyper-Vの仮想マシンのネットワークを制限する方法

仕事でHyper-V上で複数マシンを立ちあげて管理している。
一応、各ゲストマシンはそれぞれ無関係なので、ゲストマシン間の通信は行えないようにしたい。
ただ、現実問題として使える仮想ネットワークアダプタは限られているので、
どうしても同じネットワークアダプタを使わざるを得ない。

何とか良い通信制御方法は無いかと探していたら、Hyper-VでAcl(アクセス制御)ができることが分かった。
ホストマシンでコマンド実行するだけなので、一度わかればかなり楽に設定が可能である。
なお、Windows Server 2012からの機能なので、恐らくWindows Server 2008 R2とかその世代のものではできないと思う。


ホストマシンからPowerShellで以下のコマンドを実行すると設定等が実行できる。
なお、ここで「VM名」と言っているのはHyper-Vマネージャ上で表示されている仮想マシンの名称のことである。

  • 設定を確認する
  • 設定を追加する
    ・<Action>・・・接続拒否ならDeny、接続許可ならAllow、計測ならMeter。
    ・<Direction>・・・VMへの入力方向ならinbound、VMからの出力方向ならoutbound、VMの入出力両方ならBoth。
    ・<VM名>・・・対象のVM名を指定する。コンピュータ名でなくVM名なことに注意。
    ・<対象IPアドレス>・・・対象のIPアドレス。CIDR表記での設定も可能。
  • 設定を削除する
    要するに、addしたものと同じ設定を指定してDeleteする必要がある。何と面倒な。

例えば、192.168.0.1がルータで、192.168.0.xが別のゲストマシンの場合、
以下のようにすれば、「ルータ(=インターネット)にのみ接続し、他の同ネットワーク上マシンとは通信しない」という設定が可能である。

以下のページがより詳しいので参照すると良い。
僕はこのページが無くては詰んでいました。ありがとうございます。
参考: Windows Server 2012 Hyper-VでPort ACL・その1


いよいよ日本に帰任しそう。
引越し手続きとか全部やってくれないかね。
自分で手配するの面倒臭いし絶対何かミスしそう。

Windows Server 2012のRDPでサーバー証明書を設定する方法

RDP(リモートデスクトップ)でキチンとセキュアな環境を整えるためには、
サーバー証明書を設定する必要がある。
設定する理由と、設定しない場合の弊害は下記記事を参照するとわかりやすい。
参考: リモート・デスクトップ接続のサーバに「正しい」証明書を割り当てる

さて、それでWindows Server 2008 R2であればGUIで簡単に割り当てられるのだが、
Windows Server 2012では同様の項目が見つからなかった。
調べた結果、どうもPowerShellを使うぐらいしか方法が見つからなかったので、その方法を記載する。

  1. 新しい証明書をダブルクリックし、インポートする。
  2. PowerShellを管理者として実行する。
  3. 以下を実行し、新しい証明書のThumbprintを確認する。
  4. 以下を実行する。これは単にパスを設定するだけである。
  5. 以下を実行し、証明書の割当を変更する。

以上の手順で証明書を設定できる。
実行後、特にエラーが起きないことを確認したら、RDPを切断し、再度RDPで接続できることを念の為に確認する。
RDPしたときのウィンドウ上の鍵マークをクリックすれば、設定した証明書が利用できているか確認できる。

他に方法はあるはずだと思うけど、上記手順で行えたので調査は打ち切りです。
こんな操作すること滅多にないしね。


こういう作業の何が嫌かって、万が一ミスってRDPできなくなったときだね。
データセンターのサーバーに対してやる場合、最悪データセンターに行かなくてはならなくなる・・・