クライアント展開作業計画のポイントについて
今回はクライアント展開作業計画のポイントについての話です。クライアントをまとまった台数で入れ替える…というのは、機器が古くなり、OSが新しくなって古い物がサポートされなくなる以上、未来永劫ずっと続く作業です。全体的な流れも大切ですが、作業時間が長くなってしまいがちなのがこの作業です。計画作成時のポイントについてまとめてみます。 雛形の作成 端末を入れ替えるにあたっては、旧端末で動作するアプリケーションや各種設定等はすべて引き継ぐようにするのが基本路線となるでしょう。もちろんOS自体のメジャーバージョンアップ時や何かコンセプトを変更することを目的に作業する場合には必ずとは言えないですが、一度動き始めてしまったらずっと使い続ける事が「安全」ととらえてしまう人が多いのも現実であり、すべて引き継ぐことが非常に多いはずです。 多数のアプリケーションや多数の設定をすべて１台づつ行うわけには当然行きませんので、企業での端末展開では - 雛形を作成する - 雛形を展開して個別の機器を作る ということはほとんどの案件で実施されると思います。 さらに単純ミスや仕様変更ふくめて雛形には多数修正が入ります。雛形自体の修正はしないで展開後に修正作業を行う事も可能ですが、効率を考えるとやはり雛形の段階でできるだけ多くの設定を取り入れておくべきであり、現実的には「雛形の修正を簡単に行える環境および雛形展開方法」を取っておくのが望ましいです。 - 雛形作成用のマスター端末は案件終了時まで確保しておく - 雛形作成後のイメージはCD,DVD等に焼くのではなく、ネットワーク経由での配布ができる環境を整えておく(CD,DVDを焼く時間、メディアを入れ替える時間が短縮できる) また、雛形の種類は極力少なくしておくべきです。機器構成や、ソフトウェア構成上どうしても複数の雛形になってしまうケースもあるとは思いますが、何か修正をするたびにすべての雛形への修正を間違えずに確実に行えるように管理しなくてはいけません。できれば1種類にしておきたいですね。 ミスや仕様変更発生時の自動修正ポイントを作っておく 前述のようになるべく雛形の修正や雛形への追加作業を行うのが望ましいのですが、それを確実にやって行ったとしてもどうしてもどこかでミスは発生してしまう物です。展開作業がある程度はじまった後でミスが発覚し、修正を行う必要が発生することも想定しておかなくてはいけません。 そのために - 雛形展開後、自動的にファイルサーバーの特定の場所にあるスクリプトを実行する - 展開作業中にファイルサーバーの特定の場所にあるスクリプトを実行するように手順書に明記し、チェックポイントとする など、「修正を盛り込む場合にはここに盛り込む」というものを作っておくのがおすすめです。 もちろん構成がきちんとしていて、あとからグループポリシーやクライアント管理ソフトウェア等を使って修正を対象端末に確実に適用できるならそれで良いのですが、そういう事が文化的に、あるいは運用ルール的に難しいお客様の環境(他チームへの依頼事項となってしまう等)もあると思います。あらかじめ用意しておくとスムーズです。 雛形展開後のセットアップ作業は極力自動化する これは私の好みなのですが、セットアップ作業は極力「自動化」しておくべきだと思います。なぜかというと、「人間はミスをする」からです。もちろん自動化してもその自動化プログラム自体にバグ、間違いが紛れ込むことはあるのですが人間の多種多様な間違い方やなれからくる油断のようなものとはプログラムは無縁ですから。分厚い手順書を毎日毎日同じ人間にずっとやらせるのは危険だと思います。 ただし、自動化する際にも「そこで何をしているのか」ということは別途明確にしておく必要があります。これを怠ると、自動化したものがうまく動いている間は良いのですが一度なにかの原因で動かなくなると作業が完全にストップしてしまいます。手動作業バージョンの手順書と自動化バージョンの手順書の両方が用意されているのが理想的です。 そして、自動化したものも間違いや修正が発生するのが世の常ですので、すぐに修正がきちんとできる状態にしておくのが望ましいです。一番はじめの処理でファイルサーバー上から最新バージョンを取得する仕組みにしておいて、修正はファイルサーバー上の１カ所で修正すればよいようにしておくなどの方法が考えられます。 作業の流れを工夫する 作業の中で時間短縮のためには流れを工夫する必要がでてきます。作業には主に以下の４つの種類があります。 - 雛形に組み込めるもの - 管理者権限があればできるもの - ドメインに参加した状態が必要なもの - ユーザーアカウントで設定が必要なもの 雛形に組み込めるものはもちろん雛形に組み込めば良いでしょう。 管理者権限があればできるものにはドメイン参加やソフトウェアのインストール等があります。雛形に組み込めないこの手の作業は雛形展開後に自動実行されるのが望ましいです。 ドメイン参加後にしかできない作業はドメイン参加後に自動化して実施します。ドメイン参加後の再起動からの自動的なログオン、自動的なコマンド実施等自動化の流れを作ってしまうのが良いと思います。場合によっては先にドメイン参加してその上で設定後、ドメインから外した上で雛形を作成する……という荒技も場合によっては選択肢になります。(一応動くようです。) 最後にユーザーアカウントでの設定が必要な物ですが、ここが一番作業には効いてきてしまいます。 ユーザーアカウントで入った後にしかできない設定をどうするか？ ユーザーアカウントでログオンし、作成されたプロファイルに対して設定を行う必要がある…というものが結構な量存在するはずです。ソフトウェアの構成しかり、ユーザーの保持しているデータしかり。ユーザーアカウントに依存してしまうので、雛形の段階で組み込んでおく事もできません。なので、必ずユーザーの席に設置したあとでユーザーにログオンしてもらったあとで作業する必要がある……というのが自然な流れなのですが、その作業が1時間も2時間もかかるようだと時間的に問題になる可能性が高いです。 どのように時間短縮をすることが可能かというと、以下のような選択肢があると思います。 - ユーザーに長時間のセットアップを我慢してもらう。 - 事前にユーザーアカウントでログオンし構成を済ませる。 - ユーザーにログオンしてもらう。 - パスワードを教えてもらう。 - パスワードをリセットさせてもらう。 - 作業用のDCを別途作成し、そこでパスワードをリセットする。 - 手順書を用意し、ユーザー自身に行ってもらう。 どの方法で行くかは実際に作業に必要な時間やその会社の文化によって選ばれる事になると思います。何が正しい、正しくないという事もありません。ただ、引き出しは沢山持っておいた方が良いでしょう。 3の「作業用のDCを別途作成」というのは例えばネットワーク的に切り離した環境にDCをバックアップからリストアし、そのDCに対してクライアントを接続し、ログオンし、プロファイルを作成してしまうという荒技です。SIDがきちんと同一の物になるので本番環境のユーザープロファイルとひもづきますし、何も気にせずにユーザーのパスワードをリセットしてしまう事ができます。ただ、展開中に新規で作成されたユーザー等に関しては対応できないので、注意が必要です。 ユーザーデータの移行はどうするか? クライアント展開作業で実際のところ時間の振れ幅が多く読みづらいのはユーザーデータの移行作業だと思います。ユーザーによっては全くデータを持っておらずすぐに終わるユーザーもいれば、しこたまデータを溜め込んでいるユーザーまで千差万別だと思います。さらに顧客によってデータはそもそもローカルに保存すること自体が禁止で、すべてファイルサーバー上に保持しているところもあれば、デスクトップ、マイドキュメントなどユーザープロファイルの場所に置く文化の所、どこに何があるかわからない無法地帯になっているところまで本当に色々です。移行に対する方針も顧客ごとにまちまちになりますが、多いのは以下のようなパターンでしょうか。 - ファイルサーバー等を使って、ユーザーデータはユーザー自身が移行する。 - 事前に移行が必要なデータはすべて指定した場所(マイドキュメントフォルダの中など)に移動しておいてもらい、それ以外は移行しない。 - 拡張子で移行対象を決定し、すべてのデータを検索したうえで移行する。 - 特定のアプリケーションの特定のデータはきちんと作業員が確認した上で移行する。(OutlookのPSTファイル、辞書ファイル等) 特にケアが必要なのは「ユーザーが普通認識していないが重要なユーザーデータ」です。ブラウザのお気に入りの情報や辞書ファイルなどが該当し、ユーザーが使用しているアプリケーションを把握した上でどこまでのデータを移行させるのかきちんと合意しておく必要があります。 ...