決してパスワードを生でコードに記載することはおすすめするものではないのですが、Exchange OnlineへのPowerShell接続ができなくて苦労している方をサポートする機会があったのでその際に作成したスクリプトを共有します。…といっても超簡単なものですが。
ドキュメントに書いてあるものそのままなので特に内容に関しては言及することもないのですが、今回の場合
- ドキュメントどおりに実行している
- IDもパスワードも何度も確認した
- 複数の端末でも実行した
- ネットワークも複数切り替えた
という切り分けを行っており、それでもうまく接続できない、という状況でした。
そこで、私がIDとパスワードを教えてもらってドキュメントどおりに試してみるとあっさりと接続できてしまう状況でした。
この場合
- なにかしらのドキュメントにも書かれていない超基本的な部分での前提条件の見落としがある
- ドキュメントどおりに実行しているつもりができていない
- ID,Passwordのうち間違え
- ドキュメントのスクリプトのコピーミス(ボタンもありますが…)
- などなど
- その他のなにか
というくらいの可能性があるわけですが、1なのか、2なのか判別をつけることが重要だと考えました。なので、ドキュメントにかかれていることを全て単一のスクリプトに落とし、全く同じものを実行するだけで同じ結果が得られる状態にして1なのか2なのかの切り分けをするということに主眼をおきました。ですので、IDもパスワードも生で書き込んでそのままスクリプトを渡し、実行してもらいました。(※これでもまだPowerShellを管理者で実行しなくてはいけないとか色々ありますが、コンセプトとして。)
結果、今回の場合はスクリプトの実行では接続に成功しました。ですのでどこかはわからないですが、「2. ドキュメントどおりに実行しているつもりができていない」だったのだろうという事になりました。
これ、PowerShellスクリプトに完全に落とし込む手法じゃなかったらどれだけ丁寧に手順書が書かれていても手順書通りに実行されないリスクがあるんですよね。その点で完全にコードに落とし込んで確認できることは素敵だなと思うのです。
今回の例に限ったことではなく、可能であれば「コード」でのやり取りをインフラの管理者もするようにすると、コミュニケーションコストが低くなるケースはかなりあると思っています。もちろんInfrastructure as Codeという話もあるのですが、日常のオペレーションに関しても、です。
特にクラウドの時代になってほぼ全てのものがコードで表現できるようになりました。コードでなるべく表現することをベースにしていくことの価値や実現性は昔とは比べ物にならないです。個人的には、自分が行う作業は全てコード化するくらいの気持ちでいます。わたしの場合すぐに忘れてしまうので備忘録代わりでもあります。