HrsTのあれこれ

Webパーツよ、もっと目立て！！

久々ですね。相変わらずSharePoint2010が対象です。
SharePoint2007を使ったことがあるユーザーが2010を見ると色のメリハリがなく見難くなったとのご意見をよくいただきます。2013になったらもっと色は薄いですよ～って見せると、フォントサイズと余白のメリハリがしっかりしていて意外と好評。

ってことで、SharePoint 2010の画面を見やすくするためのチョイカスタマイズを紹介します。今回はWebパーツのタイトル部分の背景に色を付けてパーツの始まりを目立つようにしたいと思います。

結構ありふれたカスタマイズなので、一工夫して設定したテーマに合わせて色が変わるようにしてみました。方法はいろいろあると思うけど、パッと見のわかりやすさということで、jQueryを使っています。

<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.10.2.min.js" type="text/javascript"></script>
<script type="text/javascript">
 _spBodyOnLoadFunctionNames.push("getbgcolor");
 function getbgcolor(){
  var color = jQuery('div.s4-title').css('background-color');
  jQuery('TR.ms-WPHeader').css('backgroundColor',color);
 };
</script>

とりあえず、採用したい色を設定しているタグを探し、背景色を取得することから始めます。取得する方法はいくつかあると思うのですが、s4-titleクラスから取得することにしました。
次に取得した色をタイトルのセルを含むテーブルの行の背景 tr.ms-WPHeaderに設定します。

最後に適当な場所にコンテンツエディタWebパーツを設置し、このスクリプトを入力すればOK。

これで設置後にテーマを変更されても大丈夫ですね！！

Webパーツに影を付けたらかっこいいかも！！とか思ってるのですが、これについてはもうちょっと研究が必要なようです。

訂正！！データソース名変更は簡単だった！！

先日、MRTGで作成するRRDTool形式のファイルのデータソース名を変更すのは、一度XMLに変換して編集する必要があると投稿しましたが、rrdtuneの存在をすっかり忘れていました。
めったに使うことがないコマンドなので申し訳ない。

rrdtool.exe tune filename --data-source-rename old-name:new-name

これで簡単にできます。

RRDToolからCactiにトラフィックデータを変換する場合は、ds0をtraffic_in、ds1をtraffic_outに変換してすればいいから次のコマンドでOK。

rrdtool.exe tune filename --data-source-rename ds0:traffic_in -r ds1:traffic_out

このコマンドをBATファイルにしておけば、簡単に変換できるね

これさえあれば、ファイル名を変更して上書きする作業も入れても十数秒なので、5分間隔の取得処理の間にやるにしてもかなり余裕のある作業ですね。

RRDToolからCactiへ

MRTG+RRDTool+14all.cgiからCactiへ移行する場合、何も考えずに作業すると、データを含めゼロからの再スタートとなります。

CactiはRRDToolを使うといっても、データ取得のための設定はMRTGとは異なります。
だって、Net-SNMPを使ってデータを取得してRRDToolを使って保存しますからね。

そういうわけで、設定ファイルは作り直す必要があります。
でもね、データ自体はRRDTool形式のファイルなんですよ。
だから、今までのデータをそのまま移行さすことは不可能ではない！！はず。

とりあえず、やってみましょう

Cactiで依然と同じ情報を取得できるように設定しグラフが生成できることを確認

MRTG+RRDToolのrrdファイルをCactiの設定に合わせる作業を行う。
- rrdtool dump filename.rrd filename.xml
- xmlファイルをテキストエディタで開き、データソース名(ds-name)をCactiに合わせて変更
  ds-nameはMRTGを使っていればDS0とDS1ですね。
- rrdtool restore filename.xml newfilename.rrd

Cactiのrrdファイルを前項で作成したrrdファイルで上書きします。

この作業をrrdファイル分すべてを実施し、5分間のポーリングの間に実施すれば、データの欠落もなく、移行することができます。

まぁ、数が多いと移行作業も大変だろうけど、この手のデータは過去と比較して異常を察知するものなので、やる価値はありますね。

実は、もう一つ方法があって、Cactiのデータソーステンプレートを編集してds-nameをMRTGのDS0とDS1に合わせてしまうという方法。この方法だと、ファイルの上書きだけで移行できますよ。

IIS8でRRDTool

時代はWindows Server 2012ですよ。半年もすれば2012R2でIIS8.5になるらしいですけど、まぁ、ここはIIS8でいいや。

気を付けることは、Active Perlの5.10を入手すること。
Perlは32bit版。RRDsが32bit版なので合わせる必要がある。

RRDToolはできれば最新の！！って言いたいけど、Windows版は1.2.30が最新みたい。
まぁ、ここは仕方がないよね。

色々と設定は必要だけど、ほとんどIIS7.5と一緒。
気を付ける必要があるのはアプリケーションプールの詳細設定で32ビットアプリケーションの有効化をTrueに変更すること。
これさえ忘れなければOK。

ActivePerlの5.10さえ入手できれば問題ないってことだね。

それにしても、Network系のお仕事をするうえで、Linuxを禁止されているとこういうツールを使うときにつらいよなぁ～優れたツールが無償で利用できるのにね！！Syslog Serverとか・・・

メールの延長

NotesからSharePointへの移行において、大変だよね～といわれるのが、ワークスペース上のアイコンとか未既読の扱い。

未既読。

ユーザー視点で一番目につく最も困るのが未読数と未既読表示だと思います。

Notesではワークスペース上のアイコンに未読数が表示され、どのアイコンを開くべきなのかが一目瞭然。掲示板を開けば未読文書は赤く表示されるので、読むべき文書も一発で分かります。

この未既読機能を中心に業務を行っているといっても過言ではないでしょう。この未既読がないSharePointに移行した時、ユーザーは口をそろえて新しい、更新された文書がどれかわからないと言います。メール通知やOutlook連携など作成や更新の情報を受け取ることができる機能はありますが、Notesのシンプルさはありません。

SharePointを推進する立場からすると、どうにかして乗り越えたい課題です。
どうすれば乗り越えられるのか？

Notesの脅威ともいえる未既読ですが、いくつかの問題を抱えていると考えています。

まず、編集によって未読になるってこと。
普通の編集は便利なんですよ。以前確認した文書が編集されたことを気が付けるので、情報の取得漏れがないんです。でもね、文書の有効期限の変更や非表示項目の変更、何も変更せずに保存したとかでも未読に切り替わるんです。これらの変更はユーザーには一切関係なく、改めて読むものじゃない。作業依頼の文書だったりしたら、その作業を再実施してしまうユーザーもいます。そして問い合わせが来る。未読表示の悪い点です。

次に、メールと掲示板の役割が明確になっていない。
本来、相手に伝えたいことはメールで確実に伝えるべきだと思うのですが、未読表示を使うことで、メールを使わなくても、相手に伝えることができるのです。（はい、便利です）
伝える相手が1人ならメール、複数なら掲示板という感じになります。
掲示板を使うと同時に通知も完了するので、掲示板を使ってすべての情報をNotesに集めようよ！！ってのが簡単に実現できます。それ自体はグループウェアの目的であり問題ないのですが、あまりにも掲示板が便利すぎて、メールで通知すべき内容が掲示板に記載されることが多いのです。
ず～っと使っているユーザーはさほど問題ないのですが、新規ユーザーは有効期限の切れた情報も未読になっており、過去の経緯なんて要らないのに読んでしまいます。そして、過去の間違った情報をもとに行動してしまう可能性もあるのです。

Notesを使っていくってのは、ユーザーは未読数を0にすることが仕事で、それがメールだろうが掲示板だろうが何でもよくて、未読文書を読んで仕事をして未読数が0になると仕事が終わる。そういう仕事の仕方を永遠に続けていくってことなんだよ～

今見る必要がない情報だってたくさんあるはず。未既読に依存するってことは、届いたメールはすべて、スパムメールも内容も確認していますってのに似ているんじゃないかと。

情報の伝達と蓄積を分けることができたら、うまく乗り越えられるんじゃないかと思ってます。
どうやって説明し、実現するか。まだ答えは見つかっていないですけど・・・

補足：未既読に依存する事が問題では？との仮説であって、Notesがダメってことではありません。

1000ユーザーの役職情報削除の補足

書き忘れたので補足。

PowerShellでActiveDirectoryを操作するとき、
ActiveDirectoryサーバー上で操作する必要はありません。

ActiveDirectoryに参加しているクライアントでOKです。
もちろん、編集など特別な権限が必要な操作は
その権限を持ったユーザーで操作する必要はありますが、
基本はリモート操作です。

あと、 ActiveDirectoryモジュールが必要なので、
リモートサーバー管理ツール（RSAT）をインストールする必要があります。
クライアントOSにあった適切なRSATをMicrosoft Downloadセンターから入手してくださいね。

RSATは参照目的でも便利なのでサーバー管理者は入れておくことをお勧めします。

1000ユーザーの役職情報を削除しなさい

ActiveDirectoryを管理していると、「1,000ユーザーの役職情報を削除しなさい」なんてオーダーが出る可能性はある。
理由は何でもいい。似たような状況に置かれたと考えてほしい。

Q.急いでいるんだけど、いつまでに完了できる？
A.ん～～1ユーザー30秒かからないとして500分程度。大体8時間
　ちょっと残業すれば今日中に終わると思います。

これ、あなたの答えですか？
先日までは私の答えもこれだったかもしれません。

でも、今の私なら、「それなら30分くらいもらえれば終わります」（余裕）
なぜなら私にはPowerShellという武器があるから。

まぁ、以前から便利なのは知ってたんですけどね、使う機会がなくてスクリプトとしては使っていなかったんですよ。やっても「Export-SPWeb」みたいな単発の命令ばっかりで～

じゃぁ、スクリプトっぽくいくよ～

Import-Module ActiveDirectory
$users = Get-ADUser -Filter *
ForEarch($user in $users)
{
    Set-ADUser -Identity $user -Clear Title
}

あとはActiveDirectoryを編集できる権限で実行するだけ。
5分で書いて1分実行。
ついでに確認用のコマンドをちょっと打って

まぁ、20分は忙しそうなふりして遊びましょうか？

本当に動かすときは、編集対象に問題がないかとか、ちゃんと編集できた確認とか
やるべきことは色々あるけど、たった6行・・・
いや、最小限でいよく

Import-Module ActiveDirectory
Get-ADUser -Filter * | Set-ADUser -Clear Title

2行で終わるかも・・・
つぶしてもいい環境だったらこれでいいよね。

PowerShellの何がすごいかって、
今までの方法だと、サーバーに接続して・・・って言語すらまともに使えないのに～
って感じだったのが、それぞれのコマンドが勝手に必要な手順をこなしてくれるんですよね。
スクリプトやプログラム言語でActiveDirectoryからユーザー一覧を取得する。
これだけでも結構な行数のプログラムを書かなければならなかった？わけなんですが、
Get-ADuser -Filter *
この一行でActiveDirectoryサーバに接続して、取得して、出力するんですよ。

私が言いたいことは、8時間GUIで作業している管理者に
ちょっとした学習時間を確保することでその作業が30分程度に削減できるってことを知ってもらいたいだけ。

注意：このページのスクリプト、コマンドは動作確認を行っておりません。
あくまでイメージですので、動かないからと言って文句を言わないようにお願いします。

登録: 投稿 (Atom)