atコマンドの強化版、schtasksでは色々細かくオプションが設定できるのですがその中に、ID,passwordの項目も存在します。というわけで、これも一つのadministrator権限でコマンドを実行するためのテクニックの一つです。でも、スケジュールタスクなので、即座に実行は出来ないんですけどね。 runasは時間差とフォーカスが気になるし、WMIはリモートマシンでしか権限を変更できない、schtasksはスムーズに実行できない・・・。 どれもいけてないですねぇ・・・。 追記 関連記事はこちらにまとめてあります。 ebi’s webpage - Windows自動化バッドノウハウ
仕事の話を日記に書いてみるテスト。嘘がふんだんに盛り込まれている可能性大ですので、ご注意ください。 こんなところに書いてなにかいいことがあるのか? どうでしょうね・・・。 ActiveDiretoryとは何者か?(認証、アカウント管理の視点から) ActiveDirectoryというと、色々な要素があり、なかなかとらえずらいですが、まずはひとつの見方として、認証、アカウント管理の視点からその進化の過程を見ていこうと思います。(※あくまでもひとつの見方です。) スタンドアロンPC まず、スタンドアロンPCではローカルでのユーザー管理、アクセス制御を行います。ローカルにユーザーを作成することが出来、NT系のOSではローカルにユーザーを複数つくり、それぞれプロファイルを切り替えて使うことで1台のパソコンを共有する仕組みが備わっています。 その上で他のひとに見られたくないファイルには自分だけがファイルにアクセスできるようにアクセス権を設定することが出来ます。 1台のWindowsマシン上で、マシンの共有とリソース権限の確保が実現されています。 複数のPCがあると困ること 複数のWindowsPCが存在すると、ユーザーアカウントデータベースはそれぞれのPCに個別に保持されます。アカウントとパスワードの組み合わせを複数覚える必要があるので少々不便になります。同じIDとパスワードにしてしまうことも考えられますが、ユーザーの登録作業は必須です。 また複数PC間でリソースの共有ができないので、不便です。 ワークグループでのリソース共有 リソースの共有を実現するために、WindowsPC同士をネットワークでつなぎます。具体的にはNetBEUI、TCP/IPなどのネットワークプロトコルを構成し、相互に通信可能な状態にします。そのうえで、複数のマシンがネットワークに参加します。ネットワークに参加してしまえば、共有したいリソースを「共有」し、他のPCに見せることが出来ます。 しかし、ここでアクセス制御に少々こまったことが起きます。 ワークグループでのリソース共有で困ること リモートのPCで共有されているリソースにアクセスしようとすると、IDとパスワードを聞かれてしまいます。これは他のPCにアクセスするためにはそのPCで有効なIDパスワードを入力し、そのPCのユーザーとしてアクセスする必要があるからです。 複数のパソコンで複数のIDが管理されており、パスワードも一致していないとしたら・・・かなり混乱します。 これを避けるために、全てのIDを全てのWindowsPCに登録し、パスワードもそろえてしまうという運用方法があります。これなら他のPCのリソースにいちいちID/Passwordを入力しなくてもアクセスすることが出来ます。 しかし、ある程度大きな規模でこれを実現しようとすると、1人新しく人が加わっただけで全てのPCにユーザーを登録して回らなくてはいけません。 さらにセキュリティ対策のために、定期的にパスワードを変更する必要がある・・・などとなったら面倒でやっていられません。 アカウントデータベースの一元管理(NTドメイン) そこでアカウントのデータベースを個別のWindowsPCに持つのではなくて、一括してどこかにまとめて管理してしまおうという発想が出てきます。これがWindowsドメイン(NTドメイン)ですね。 NTドメインによって、認証やネットワーク資源の一元管理を行うことが出来るようになりました。 ユーザーはドメインに登録し、コンピューターはドメインに参加することで、ドメインに管理をゆだねます。これで、どのPCにでも誰でもログオンでき、別のPCにあるリソースにアクセスする際に、一々ID,パスワードを入力する必要がなくなりました。 !!!!(余談)ローカル管理から一元管理への流れ ホスト名の解決にしても、NETBIOS名の解決にしても、データベースにしても、たいていのものはローカルでの管理から始まって、共有の方向に向かっているように思われます。 NTドメインの問題点 こうしてNTドメインにアカウント情報が共有され、クライアントPCもドメインのリソースとして登録すれば、どのPCにでもログオンできるし、リソースの管理も一元化できます。 しかし、以下の問題点が・・・。 !!!!扱えるオブジェクト数の限界 NTドメインでは単一のドメイン内で扱えるオブジェクト数がそれほど多くなく約4万が限界でした。そのため大規模な環境の場合、アカウントを登録するドメインとは別にリソースを登録するドメインを分ける・・・ということを余儀なくされることがありました。 !!!!管理者の権限 ドメイン内において管理者は全てのオブジェクトに大しての権限を持つことになります。本来であればひとつの拠点や部署などもっと小さな単位で管理権限を与えたい場合でも、不必要に強い権限を与えなくてはいけませんでした。それを避けるためには、これまたドメインを分割する必要がありました。 !!!!信頼関係の管理 上記のようにドメインを分割した場合には相互に連携するために、信頼関係を結ばなくてはいけません。この信頼関係はドメインが増えるたびに全て追加で登録の必要があったため、維持、管理に問題がありました。 !!!!シングルマスタ アカウントの管理は一元化されたものの、大規模に展開するためには、そのデータベースを複数用意し、参照できる必要があります。NTドメインではこれはPDCがマスター、BDCがバックアップといった具合に実現されています。 しかし、データベースの更新処理自体はPDCにしか行えず、PDCのデータのコピーをBDCが保持するという形態になっていたため、運用上少々不便でした。 ActiveDirectoryでの改善 ActiveDirectoyでは上記の問題点が解消されています。 !!!!扱えるオブジェクト数の限界 ActiveDirectoryでは単一のドメインで扱えるオブジェクトの数が100万オブジェクト以上となり、事実上オブジェクト数のみを問題としてドメインを分割する必要はなくなりました。 !!!!信頼関係の管理 ActiveDirectoryでは「ActiveDirectoryフォレスト」というものを形成し、自動的に推移的な信頼関係を構築するので、信頼関係の維持管理にかかるコストが減少しました。 !!!!管理者の権限 ActiveDirectoryでは単一のドメインの中にOUという管理組織を作成することができ、その中にオブジェクトを格納できます。その上でそのOUに対して管理の委任を行うことができ、「このアカウントにはこのOUの管理を任せる」ということが出来るようになりました。 !!!!シングルマスタ ActiveDirectoryではドメインコントローラーが対等な立場として存在し、そのドメインコントローラーでも情報の更新が行えるマルチマスタモデルになっています。たとえばDNSなどもADに取り込まれており、マルチマスタでの情報の更新が可能になっています。 ただし、全ての機能が対等に存在しているわけではなくて、4つの機能に関しては単一のドメインコントローラーが保持しています、これはFSMO(フィズモ)の役割などと呼ばれます。FSMOに関しては別のところで述べます。 ActiveDirectoryのいけてないところ これで終わるとあまり意味が無いので悪いところも・・・。 !!!!扱えるオブジェクト数の限界 扱えるオブジェクト数の限界は増えたものの、その分データベースにしわ寄せが来ている印象があります。データベースエンジンはMicrosoftおなじみのExtensible Storage Engine(ESE)です。(Exchangeなどでも使われているものです) それぞれのオブジェクトが消費するデータベースが結構大きく、削除済みのオブジェクトも規定で60日間、今度のR2では180日間保持されます。 なので、オブジェクトの絶対数はそれほどでもないけれども、毎日大量に削除〜作成を行うようなシステムでは容量は要チェックです。(あまりないと思いますが) !!!!信頼関係の管理 フォレスト内での信頼関係はいいのですが、その他のNTドメインや別フォレストと信頼関係を結ぼうとすると、結局以前のNTドメインの際の問題に直面します。ある意味仕方ないのかもしれませんが・・・。 ※ただし、フォレスト間の信頼関係に関してはWindowsServer2003で改善されています。 http://www.microsoft.com/japan/windowsserver2003/evaluation/demos/flash_animations/01forest.htm !!!!管理者の権限 OUを分けることで管理を委任できる・・・というところが売りなのですが、OUに対していかに効率的にリソースを移動、配置するかという点はあまりサポートされていません。 たとえば、コンピューターオブジェクトは普通にドメイン参加するとComputersコンテナに作成されるので、そこから手動でOUに移動する必要があります。 ドメイン参加の際にコンピューターオブジェクトが作成される規定の場所を変更することは可能ですが、それも別の1箇所に変更するのみであって、条件によって振り分けるようなことは出来ません たとえば、あるOU以下しか管理権限がない場合に、単純にドメイン参加すると、Computerオブジェクトが管理下にないOUに作成されてしまい、手も足も出なくなってしまいます。このような場合、先にコンピューターオブジェクトを管理下のOUにつくっておけば問題は回避できますが・・・。 OUへのオブジェクトの配置は今のところ独自にアプリケーションを開発するなどして管理してあげる必要があります。 !!!!シングルマスタ 複数のDCに書き込めることのメリットも確かに沢山あるのですが、複数に書き込めるようになった分だけその整合性を取るところでおかしなことが起きます。 書き込んだつもりの情報があとから更新された情報によって上書きされたり、削除したはずのオブジェクトを再作成しようとすると、まだ削除の情報が全てのDCに伝わっていないためにエラーではじかれてしまったり。 最悪なのはDC間の同期がおかしくなった場合です。この場合完全に全ての最新の情報を救うのは絶望的になります。DC間の同期の正常性の確保は非常に重要です！ ...
ちょっと更新に間が空きましたが、社内にXoopsを立ててました。会社の性格上、WindowsにXoopsを入れてたのですが、色々とはまってしまいました。その恥をここでさらしてみます。センスないなぁ・・・俺・・・。
バッチファイルなどで、定期的に情報を出力する際にまったく同じファイル名では上書きor追記になってしまうためファイル名に日付をつけたいようなときがあります。このような際に、標準のDosの機能だけでは実現できないように思いがちですが、実はDosの機能だけで実現できてしまいます。 f f f o o o r r r / / / f f f " " " t t t o o o k k k e e e n n n s s s = = = 1 2 1 , , d 3 2 e l d d i e e m l l s i i = m m / s s = = " / : % " " % i % % % % i i i n i i n n ' d a ' ' t d t e a i t m / e e t ' / / ) t t ' ' d ) ) o d d s o o e t s s e e y t t e a d t r a i = y m % = e % % = i % % i % % i % % j % j 上記のコマンドを実行すると環境変数のyear, day, timeにそれぞれ値を取得できます。あとは、情報の出力先のファイル名に、これらの環境変数を使ってあげればOKです。 ...
とりあえずダウンロードして叩いてみたら、すごくシンプルな画面になりました。さて、どんなデスクトップにしようかな〜♪
なんか色々あってよくわかりませんが、フォーラムでの投稿数が一番多かったことを理由にbbleanを導入してみることにします。 下の画像は現在のデスクトップです。もちろん最先端をいく私はLonghorn導入済みです(嘘)。 ブラウザはSleipnir β3。メーラーはThunderBird。仕事用にOutlook。Launcherはmoonlight。Google Desktopも使ってます。
http://www.konfabulator.com/ ふむ。なかなかよいものらしいので、入れてみようかな。
http://221bbakerstreet.org/archives/2004/02/15_1802.php http://qwerty777.s57.xrea.com/winunix/desk.htm ふむ。shell変えてみようかな・・・・・・会社の支給PCで・・・。
MSN Messenger 7.5がでてたので、version up。なぜ「新バージョンでたよー」って宣伝してないのだろう?? どうやら新バージョンでは音声メモなんかを簡単に記録できるようになったらしい。・・・けどやり方がわからない。デマ・・・?
仕事で、暇なので(?)パフォーマンスログをCSVではいておいて、そのファイルをExcelから読み込み、自動的に表やグラフにして、傾向を簡単に報告できるようにするものを作ってます。ほぼ趣味ですが・・・。 なかなかExcelってやつもVBAをつかうといろんなことができるもんですなぁ・・・。