今見えているOAの未来とはどんなものでしょう。

想像ではなく、現実に発売しているOSやアプリを組み合わせると、ある事が見えてきます。

RemoteApps を外部から、例えば社外から社内に接続する場合、VPN を用いずにTS Gateway という手法で接続する事が出来ます。

この手法は、RDP(リモートディスクトップ)の制御を SSL を介して行うもの(RDP over HTTP)で、安全性は NAP という機能で保護されます。

NAP は接続クライアントがセキュリティポリシーの充足をリアルタイムで監視する機能を持ち、必要であればネットワークを遮断したり、セキュリティセンターに誘導します。

RemoteApps は、あたかもクライアント上で動くアプリケーションとして振る舞いますが、実態はサーバー側で動いているわけですから、軽量でパフォーマンスの小さい PC でも動作します。

この事から、サーバーはより負荷に耐えられる高性能なものになり、クライアントは軽薄短小で、よりデザイン性や操作性が重要視されるでしょう。

しかも、サーバーが１台とは限りません。

クラウド・テクノロジーにより、あなたはどのザーバー上のアプリケーションを使っているのかを知る必要がありません。

必要な機能が必要なサーバーから提供されるからです。

もちろん、それが自分の会社のサーバーとも限らないのです。

あなたは、そこが社外であろうがなかろうが、環境を意識することなく、必要な情報を得ながら自分のジョブを継承できるのです。

さて、費用は？

驚く事に、そのほとんどが Windows Server 2008 R2 に標準で搭載されているのです。

あなたが購入するのは、ライセンスという知的所有権だけです。

さあ、乗り遅れてはいけませんよ。

雑談です。

会社から家に戻る途中には、立ち寄れるコンビニがあります。

忙しかった日は疲れからお弁当を買う事が多いのですが、そのお弁当にちょっと不満があります。

味？ではないのです。

メニュー？でもないのです。

何を隠そう、「電子レンジで温める時間」です。

私のレンジ君、ピザも焼ける石釜オーブンレンジなのですが、1600W、1000W、500W の切り替えなのです。

お弁当って、1500Wと500Wでの目安なんですよね。

1600W っていったい・・・

その上、時間単位が「分・秒」なのです。

ある日の帰り、セブンイレブンでお弁当を買いました。

1500Wと500W なので、正確さをモットーとする私としては、500W を選択し、時間をセット・・しようかと。。。

時間・・・130秒。

んー。。。

疲れてる時に、１分が60秒だから・・・んー２分10秒ね。。。

考えるの面倒だなぁ。。。

一日中頭を使って仕事をしてるのに、お弁当位は何も考えずに食べさせてほしいなぁ。

翌日、昨日の秒計算を思い出し、ミニストップにしました。

さて、案の定 500W ね。。。

僕の電子レンジは 500W 専用みたいなもんだと思いつつ・・・

時間・・・

1分25秒！

５秒単位なんてあるかい！

120秒にセットしました。。。

私の電子レンジは、コンビニでお弁当を買うような人を対象にしていないらしいですね・・・。

そもそもあの時間って、コンビニに設置している電子レンジで設定し易いようにしているだけで、食べる人の事を考えていません！

と、まあ、そんな愚痴でした。

「温めてもらえばいいじゃない」って突っ込みは無しで。

仕事のお話です。

最後のサーバーインストールが終わりました。

SharePoint Server 2007 SP2 と ASSIST を組み合わせた資産管理用システムです。

SCCM から解析データをコネクト(データ取得)し、SharePoint Service の構成サイトから分析データを参照できるというものです。

ASSIST 自体は SCCM の収集データを視覚としてより良く見せるレポート的要素がありますので、有用なアプリです。

ですが、この SharePoint というシロモノは、いつも悩ませてくれます。

今回は Microsoft の専門コンサルの方と共同して行ったので、トラブルがあるとは思わなかったのですが、私の勇み足でパスワードのトラブルがあったり、何気に設定したドキュメントフォルダのPathを間違えたり･･･。

単純なミスですが、SharePoint というシロモノは、そのミスを発見するのに時間がかかる複雑な構造をしています。

けっこう私にとっては呪われたアプリです。

まあただ、自分でも SharePoint のアプリを組み上げた事があるので、経験がものを言いました。

トラブルも無事解決し、マイクロソフトの方もなんとか最終の新幹線には間に合ったようです。

もし泊まることになったら、ビールでも飲みながら、SharePoint の愚痴大会だったかもですね。

これからはチューニングの段階に入ります。長丁場で孤独な戦いですが、最良の調整をすべく頑張ります。

Trend Micro に LDAP が1000件しか読み込まない件のつづき。

実際に聞いてみました。

なんと、件数は Active Directory の仕様で、設定値を変更すれば可能とのこと。Active Directory 側の問題だったのですね、失礼しました。

それなら身に覚えがありますので、設定を変えてみたいと思います。

まずは コマンド プロンプト を開きます。

開いたら、ドメインコントローラで ntdsutil と打ち込みます。

ntdsutil: とプロンプトが表示されます。

すると、ldap policy: とプロンプトが表示されますので、

connections と打った後に、connect to server “ドメインコントローラ名” と入力します。

これで接続し、設定変更の準備が整いました。

quit で1つ前のプロンプトへ戻り、show values と打ち込みます。

現在の設定内容が表示されます。今回修正するのは MaxPageSize で、その値を8000に変えてみます。

まずは set MaxPageSize to 8000 で設定値を変更し、続いて commit changes で設定値をコミット(有効化)します。

再び show values で設定されたか確認します。

先ほどの MaxPageSize の値が 1000 から 8000 に変わっている事が読み取れます。

以上で設定が完了しました。

この設定は１台のドメインコントローラに対して行いますが、適用されるのは全台になりますのでご注意ください。

んー。

1000 以上の表示が必要というのもなかなかありませんよね。

自宅のクライアントに設定して使っています。

最近の Web 事情は、多くの広告や関連情報が１枚の画面に付加されており、場合によってはたった1つの Web 画面において、数十から数百もの DNS クエリ、いわゆる名前解決が行われています。

例えば、Windows の 「コマンド プロンプト」 から、

nslookup

と打ち、続いて

set type=D2

と、デバック目的である趣旨のコマンドを打ち、

softonhouse.jp

と打ってみてください。

おそらく、かなり連続した(意味不明とも思える)レスポンスが画面に表示されることでしょう。

これが DNS による名前解決で、URL をブラウザに打ち込むと、この動作が「1つのドメイン名に対して必ず」行われています。

DNS の名前解決は、URL から実 IP アドレスへの変換を行っていますが、その URL が複雑な場合は、たったひとつの URL(名前) 解決にいくつものクエリがインターネット上に放出されているのです。

プリフェッチとは、あらかじめ URL を IP アドレスに変換しておき、実際にその URL を参照する場合には、クエリを使わずにキャッシュされた IP アドレス情報を使うものです。

一般に、一度照会された URL の情報は TTL と呼ばれる期限に基づいてローカルコンピュータや DNS サーバーに登録されていますが、これを事前に行ってしまうのがプリフェッチです。

従って、実質的な WEB の表示速度が改善されるだけではなく、多くの人々が Google Public DNS を使う事は、インターネット上の膨大なクエリ放出を減らす試みにもなるという事です。

但し、企業や組織などでは、DNS にローカルサーバー(組織サーバー)が登録されているのが普通であるため、組織内クライアントの DNS 設定を勝手に Google Publid DNS へ登録してしまうと、何らかの障害が発生する恐れがあります。

また、今回は「個人的なテストを目的」としているため、企業でこの　Google Public DNS  を使う時は十分に注意した方が良さそうです。

参考のため、DNS Setting Data を掲載しておきます。

下手な ISP の DNS よりはよほど高速かもしれません。

ぜひお試しください、但し個人的に。