再作成するしかありません。2つのエラーが修復されました。いうプロセスがあることを確認します。3この他の情報はこちらを参考にしてください。オブジェクトがランダムに表示される。コンテナを開いてみると、オブジェクトが不規則に並んでいるという症状です。いうことなのでバグでしょう。sp7)では必ず発生し得るようです。立ち上げると直るかも知れません。そのうちフィックスされるでしょう。起動するとこの現象は解決できます。Patch2で修正されています。プログラム3本をフィックスすると直りました。ロックモードで修復されるので、ライセンスが正しく動く場合があります。再起動直後にこの現象が出るようですが、特定できる文書はありません。最後に入れておくと良いでしょう。場合、ライセンスは必ず消費するユーザオブジェクトと同じコンテナか、より上位のコンテナにおかなければならないという「決まり」があります。バージョンアップした場合は必ずはまりますからご注意ください。ユーザがログイン認証を受けると、自動的にそのユーザのコンテナのライセンスオブジェクトを探して、なければ上位にサーチを掛ける仕組みです。読ませたい時に覚えておくと便利です。27日ケーススタディ:IT運用部門が社長賞を受けた日IT部門において、私のようなインシデント管理、システム運用、トラブルシューティングを行い、システムの構築、移設や、ヘルプデスクなどを担当する職業の人間は、IT部門でも低く見られる傾向があります。エライのはシステム開発部門のSE、PM。システム運用、オペレーション、ヘルプデスクの担当者は彼らが作ったシステムを動かしてこそ評価されども、トラブルを起こすと誰もが文句を言って評価が下げられます。システムを運用している影の人達の苦労を考えたことはありますか。確かに日本の新幹線は優秀です。新幹線を動かしているのは運転手ではありません。列車制御装置をにらみつけ、僅かな夜間に的確に路面をメンテナンスする技術者たちが40年間大事故なしのシステムを動かしているのです。ヘルプデスクはIT部門の顔です。エンドユーザが抱える問題はヘルプデスクで受け付けられ分類され、その組織が抱えている情報システムの欠陥や問題を一番的確に指摘できる部署なのです。C社はブランド品を世界的に販売する企業で、よくそのロゴマークはレーシングカーなどによく見られます。D社を買収することになりました。ドメインを使っていました。2000年問題が片付いた頃のことです。スタンダードとして決めていました。その計画を聞いた私はびっくりしたものです。ある3連休を使って、会社を合併させて、オフィスも移転するというのです。C社より、販売会社のほうが規模は遥かに大きく、まぁ、小さな魚が大きな魚を咥えたようなものです。C社のシステム部のマネージャIさんはとりあえずでいいから1ヶ月常駐してくれと要求されたのは、合併を半年後に控えた頃でした。合併を前にして、既にC社のエンドユーザ数名がD社のオフィスに常駐していました。両社の間には専用線が接続されています。ドメインなのでC社から出向してきた社員はD社のシステムを使うことはできません。いってC社のサーバにも重要な資料があるため、彼らは両方のシステムをアクセスしなければなりませんでした。ひとつ重要な点として、C社は多国籍大企業の日本現地法人であったにも関わらず、C社が推進するスタンダードなシステム構成ではなかったのです。製品を深く知らないベンダーが「なんとなく作ってしまった」ようなシステムだったのです。ユーザの命名規則も定まっておらず、非常に使いづらい、また問題の多いシステムでした。そこでマネージャのIさんは・まずD社内にC社のスタンダードなシステムを構築し、D社のシステムを先に移行する。・次に新規に出来たD社のシステムにC社のシステムを新規に接続し、データを移行する。・引越しのタイミングで2拠点のシステムをマージしC社のグローバルスタンダードを作る。・古いC社のサーバは破棄するという手順を考えていました。私に与えられたのは分厚い英語の資料です。資料は教科書通りに良く出来ており、英語が得意とは言えない私でもなんとか理解できるレベルのものでした。D社にC社のグローバルスタンダードな構成のシステムを構築するのは容易でした。そこから、ヘルプデスク、運用チームと協力して、D社の社員にC社のシステムポリシーをトレーニングします。ログインの方法、マイコンピュータに現れたドライブの意味、(共有か私有か)最後にパスワードの変更を行ってもらい、×月×日(月)よりこのシステムで使ってもらうということを宣言して、ユーザトレーニングは終わりです。導入して、データを移行してD社のシステム構築は終わりました。スクリプトを用意して、ヘルプデスクはバッチファイルをキックするだけでインストール、セッティング再起動を自動化しました。春が来て初夏のある日、C社のIマネージャに再び呼び出された私はいよいよC社D社の本社移転と統合のフェーズ2のプランを打ち合わせしました。-現在D社で動いているスタンダードを元にC社側に新規にシステムを構築する。-旧C社サーバのトラスティ、グループ、ユーザアクセス権を徹底的に調べて、必要なものだけ新サーバに移行する。-擬似的にC社D社の両拠点を1拠点に見せかけるようにシステムを作りこむ。C社、D社に拠点で分割されているOUをひとつにまとめる。2箇所にある人事部はひとつの人事部に、2箇所に分かれている営業、マーケティングはひとつに統合する。-最後にディスクのバックアップを完全に取り、新しいオフィスに移動する。いうことで、一週間かけて徹底的に誰がどこにアクセス権限を持っているかを調べ上げ、ヘルプデスクと協力して必要なもの、必要ないものを分類しました。グループ名の命名規則を定め、フォルダの命名規則を定め、このアクセス権限の変更は文書によるものというルールを作りトップシークレットも含むフォルダ、グループを作りました。VPクラスのユーザは大抵の場合、秘書が付いています。この秘書をどうやってVPのファイルにアクセスさせるかも徹底的に議論しました。用のスクリプトをバッチ化して、このバッチを走らせると、自動的に全ユーザが新しい部署に配置されるように準備しました。行いC社のサーバにあったデータは全て新生C社のシステムに移行が完了していましたのは金曜日の午後7時ごろです。あとはバックアップを取って、搬送するだけです。引越しと同時に新しいことをするべからず。事前に済ませておくこと。して、3連休の前の金曜の夕方から、引越し大プロジェクトは開始されました。企業合併に関してどういったポリシーがあったのかはわかりません。新しいC社のオフィスにPCをセットアップしていて気が付いたのですが、旧C社、旧D社といった区別がなく、新しいパーティションの中では両社の旧従業員が混然と割り当てられていたようです。ユーザでログインするだけでほとんどの作業は終わりです。ラックの配置設計に問題があり、ケーブルが届かないといった事態があったり、配線が雑だったり、形が合えばつながるものは何でもいいといった態度が作業員にあり、私が担当するシステムだけでもと思い配線は全部やり直しました。サーバが動き始めない限りヘルプデスクチームが動けないのです。ラック配置は十分設計すべし、職人任せじゃなく、SEが監督しなければならない。新しい机、パーティション、PC、それから椅子。「こんな椅子に金かけるくらいならスイッチングHUBのひとつでも買ってくれよなぁ」と激怒するIさん達を横に見ながら、私はアーロンチェアに座ると途端に眠り込んでしまいました。椅子はなるべくいい椅子を買うべし。働く人の士気は全然違うぞ。2,3の不具合、ハードウェアの故障などがあったものの、連休明けと共に出勤したエンドユーザさん達はPCの電源を入れ、メールのチェックをしながら引越し荷物を片付けています。--それから半年後、新生C社の忘年会が盛大に都内のホテルで行われました。その中で、表彰があり、運用、ヘルプデスク部門を担当したIマネージャが最高の社長賞を受賞しました。導入が計画されました。私もプランの立ち上げには参加したものの、結局、日本法人のC社でADがきちんと稼動するまで、それ以降2年の月日がかかったそうです。私は2人月でC社のディレクトリを作りました。移行するためには実に2年の年月、新しいハードウェア、高額なコンサルタント、動かないソフトウェア対策が必要でした。外注分だけでも数十人月の工数がかかったはずです。その結果に満足できたか、という問いにIさんは「ずっと使いづらいものになった」と答えています。いう開けないけど見えちゃう共有名、貧弱なログオンスクリプト、OU単位でしか設定できないグループポリシー。どれもIさんにとっては満足できなかったそうです。駄目なんだ、とは言うつもりはありません。これだけ圧倒的なシェアを持つ以上、無視するわけにはいかないのです。それぞれのビジネスニーズに従ってそれぞれのシステムは作られるのです。オープン系の開発技術者がエライという風潮もちょっと変だなぁと思います。運用、オペレーション、ヘルプデスクを担当するエンジニアがいなければシステムは稼動できません。それだけに社長賞を取ったIさんの誇りたい気持ちは十分理解しています。ショートカットキーが使えるようになるので、これを最大限利用しましょう。エラーが出てドライブがマップできないというような現象がでることがあります。単純に説明されていますが、要するにライセンスのエラーなのです。ディレクトリしか見えないというトラブルが発生する場合があります。