tech.guitarrapc.cóm

Technical updates

PowerShell の Set-ExecutionPolicy 設定時のスコープ対処

PowerShell をシェルとして利用するときに誰もが一度はひっかかるのが ExecutionPolicy です。

今回は、Set-ExecutionPolicy RemoteSignedをしようとしたら、以下の警告が出た場合の対処です。

ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand : セキュリティ エラーです。

目次

ExecutionPolicy の目的

敢えて長い間ふれてきませんでしたが、そもそもに触れましょう。

スクリプトは信頼できることのセーフガード、VBScript など過去の経験、そして JEA に見られるような必要な権限を必要な時にという考え、あるいは 「あ、間違えて実行しちゃった!」を防ぐための機能として ExecutionPolicy があると説明されています。*1

大事なのはこの辺です。

  • What you are trying to protect. In PowerShell’s case, this is almost entirely "code execution.”
  • Sources of data, and how that data flows. In PowerShell’s case, these are scripts sent to you through email, scripts downloaded from the internet, your profile, user input, and other similar sources. From there, this data flows through many PowerShell features – the parser, cmdlet invocation, formatting and output, etc

  • Boundaries between untrusted data and trusted data

    • PowerShell doesn’t trust scripts that you download from the internet
    • PowerShell doesn’t trust a random script or executable lying in the current location of your hard drive
    • PowerShell does trust user input
    • PowerShell does trust the administrator of the machine
  • PowerShell does trust a running script

blogs.msdn.microsoft.com

blogs.msdn.microsoft.com

blogs.msdn.microsoft.com

コンセプト自体は理解できるのですが、ちょっと心が折れそうになることが多いのではないでしょうか。

中にはデフォルトから変更しないことをすすめる記事もあります。これはこれで有益です。特に PowerShell.exe -ExeuctionPolicy RemoteSigned -Command "なにか処理やps1"は 私自身よく利用しています。

qiita.com

他にもバイパスする手段は数多くあります。

blog.netspi.com

「バイパスされるようなものなんて」といいたくなる気持ちが湧いた方もいらっしゃるでしょうが、Windows Server 2012R2 ではデフォルトが RemoteSigned なあたりに考えの変化も見て取れます。*2

Office365 や Exchange Online などは、相変わらずのようですがMicrosoft 社内でも見解はそれぞれなのでしょう。

https://powershell.office.com/scenarios/setting-execution-policies-on-windows-powershell

どうするといいのか

ExecutionPolicy とは、というのは結局のところ利用シーン次第です。

  • グラニでは、RemoteSigned に変更してしまいます。それは背景に、Disposable な環境で一度きりの環境構築、以降は構成変更があれば捨てて新しく立てる。 という仕組み、コンセプトが根付いているからです。このケースにおいて、Restricted + -ExecutionPolicy などでやる意味は乏しいのはご理解いただけるでしょう

  • PowerShell スクリプト開発をされる方にとっては、当然のように RemoteSigned にしたくなるでしょう。*3

  • しかし、スクリプトも実行しないようなPCまで強制する必要はありません。Restricted でいいでしょう

多くの方にとって、それぞれの利用シーンがあります。ExecutionPolicy が面倒なのは事実ですが、背景はまず共有しておきたいと思います。

Set-ExecutionPolicy

さて、今回の記事は、Set-ExecutionPolicy を実行すると、ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand と出た場合の対処です。

Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by
a policy defined at a more specific scope.  Due to the override, your shell will retain its current effective
execution policy of RemoteSigned. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more
information please see "Get-Help Set-ExecutionPolicy".
At line:1 char:1
+ Set-ExecutionPolicy Unrestricted
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException
    + FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand
Set-ExecutionPolicy : Windows PowerShell により実行ポリシーは正常に更新されましたが、設定は範囲がより明確に定義されたポ
リシーで上書きされました。この上書きにより、シェルで現在有効な実行ポリシー Restricted が保持されます。実行ポリシーの設
定を表示するには、「Get-ExecutionPolicy -List」と入力してください。詳細については、"Get-Help Set-ExecutionPolicy" を参
照してください。
発生場所 行:1 文字:1
+ Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException
    + FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand

結論からいうと、このエラーが出る場合は設定しようとしたスコープよりも下のスコープで制限している ことが原因です。

見てみましょう。

PowerShell の実行権限スコープ

Get-ExecutionPolicy -List をすることで一覧がみれます。MachinePolicy と UserPolicy は、GPOに関連するので触りません。

この場合、既に LocalMachine で RemoteSigned になっています。

権限スコープは、Process < CurrentUser < LocalMachineの順に広くなります。

権限スコープ 範囲 設定箇所
Process 現在のPowerShell セッションのみ。別のPowerShell セッションには影響を与えません。 環境変数 PSExecutionPolicyPreference
CurrentUser 現在のユーザーのPowerShell実行のみ。別のユーザーには影響を与えません レジストリ HEKY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
LocalMachine マシン全体のスコープ。どのユーザーで実行しても、同一の権限になる。 レジストリ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

例えば、PowerShell.exe -ExecutionPolicy RemoteSigned などは、Process スコープの変更です。

ここまで理解できれば話は簡単です。

狭いスコープから変更していく

エラーが示しているのは、変更しようとしたスコープよりも低いスコープで制限されていることを意味します。

たとえば、CurrentUser スコープがRestricted にします。

この状態で、LocalMachine スコープを RemoteSigned にしようとするとエラーがでます。

対処は簡単です。CurrentUser を先に RemoteSigned などにしてから、LocalMachine を変えましょう。

Process スコープが Restricted になっていた場合でも、同様に Process スコープを RemoteSigned などにすれば回避できます。

怒られませんね。

まとめ

Disposable なら ExecutionPolicy も気にせず済むので、オススメです。

*1:Twitter上での Jeffery Snover 御大の発言は時期によって意味が変わるので切り取りません

*2:Windows 10 のようなクライアントOSではRestricted なのもそれなりに理解はできます

*3:このブログはそういった方を対象にしているのも自明です

PowerShellGet の PSGallery が消えた場合の対処

PowerShellGet のデフォルトのPSRepository は、PowerShell Gallery です。

PowerShell Gallery | Home

デフォルトなので、何もせずとも設定されているのですが、過去に2回設定が消えたことがあります。原因がいまいちつかめていないので、復旧方法のメモだけ。

目次

PowerShell Gallery

通常は、Get-PSRepository を実行すると、PSGallery が表示されます。

結果、Find-ModuleInstall-Module といった PSGallery を使ったモジュールの検索、インストールが可能になります。

対処方法

しかし、状況によって、Get-PSRepository をしても PSGallery がないことがあります。

その場合、以下を PowerShell で実行しましょう。

gist.github.com

実行後に、PSGallery が復活することを確認します。

Find-Module も使えますね。

まとめ

単純な設定なのですが、面倒なものです。

OneGet や PowerShellGet の更新は、結構ほそぼそしているのですが、開発は続いています。今後がどうなることか、というところですが、明らかにサーバー展開時のモジュールやパッケージの導入が楽になります。

ぜひ WMF5 や PowerShellGetを試して貰えるといいですね。

PowerShell でディスクの初期化からフォーマットを行う

Windows のディスクを管理したいとき、古の時代から diskpart コマンドがあります。

DiskPart Command-Line Options | Microsoft Learn

www.atmarkit.co.jp

しかし現在これらのdiskpart 操作をを使うことはありません。PowerShell でより高度、安全に操作できるからです。

こういったディスクの初期化処理は、AWS や Azure においてディスク追加するときにも必要になることがあります。

そこで今回はその例を少し見てみましょう。

目次

GUI のディスク管理

Windows 10 を例にします。 Win +x > k によって ディスクの管理 を起動できます。

例えば以下のディスク構成があります。

この中のディスク3 は、現在は プライマリパーティション1つの 単一パーティション構成です。こういった場合は GUI でボリュームの削除を行って綺麗に構成可能です。

しかし、以前OSをインストールしていたディスクの場合は GUI で行えることに制限があります。*1

ディスクの管理では、OSインストール時に自動構成された回復パーティションを削除できません。

そこで古代においては、diskpart を使って操作を行うことがありました。

今回は、OSが入ったりした ディスク3 を「完全に消去 > 単一パーティション > NTFSフォーマット」まで構成してみましょう。

diskpart

コマンドプロンプトから diskpart を入力すると、管理者へのUAC昇格と共に diskpart の対話モードが開始します。

まずは list diskでディスク一覧を呼び出して対象を把握します。

次に操作対象ディスクを select disk 3 で選択します。

操作内容として、回復パーティションも含めて綺麗にするので、clean コマンドでディスクを消去します。

という感じです。

PowerShell で初期化する

PowerShell には、Disk や Partition、Volume 操作用の Cmdlet があります。これらをパイプラインで繋げれば、初期化からフォーマットまでワンライナーで綺麗に完了します。*2

gist.github.com

どうでしょうか?先のディスク3の初期化も一発です。かつ、ディスクの製品名から指定もできたり、BootDisk を除外してまとめて行ったりも可能です。

操作も Cmdlet が明確に意図を示しています。

Cmdlet やっていること
Get-Disk ディスク一覧の取得
where FriendlyName -Match ST3500 ST3500という製品名に該当するディスクにフィルタ
Clear-Disk -RemoveData -RemoveOEM -PassThru ディスクを消去
Initialize-Disk -PartitionStyle MBR -PassThru ディスクを MBRで初期化
New-Partition -UseMaximumSize -AssignDriveLetter 新規パーティションをディスク全体を単一として、ドライブレターを自動付与で作成
Format-Volume -FileSystem NTFS -Force 作成したボリュームを NTFS でフォーマット

簡単ですね。

まとめ

diskpart しかできないという操作はそうそうありません。回復コンソールなど、極めて限定的なシーンでの利用となるでしょう。

こういったWindowsシステム系の操作は PowerShell だと本当に楽に書けるのでぜひ試してみるといいと思います。

*1:OSインストール時やパーティション操作ソフトを除きます

*2:PowerShellを管理者権限で起動する必要があります

AWS Windows 自動化ラウンドテーブルのセッション資料公開

2016/5/13 に、アマゾン ウェブ サービス(AWS) 様主催で、AWS で Windows を扱っている方を集めてのクローズドなラウンドテーブルの第1回が開催されました。

私も、AWS Solution Architect の@keisuke69さんにお誘いいただき登壇させていただきました。今回の資料を作るきっかけを与えていただき、本当にありがとうございます。当日参加して下さった方もありがとうございます。

今回は、ラウンドテーブルで用いた資料と、グラニのインフラの基本的な考え方を紹介します。

目次

Simple Windows Architecture on AWS

グラニは3年以上に渡りAWSでインフラ環境を構築しています。

神獄のヴァルハラゲートのリリース当初はPHPだったためAmazon Linux でしたが、2013年7月のある晩にサービス運営中のコードベースをC# にリプレースし、以降は Windows Server を中心としています。

当時と現在では、大きくインフラ構成が異なります。最も大きな変更が、インフラコンポーネントを Disposable *1 にしたことであり、よりシンプルにすることの追求です。

なぜ構成を公開するのか

今回の構成は、かなり踏み込んだ部分まで公開しています。グラニのインフラ構成を公開したのは、自分達の現状の整理と戒めを強く意識しています。

過去もそうですが、現在のインフラ構成にも多くの不満があり直したいことが山積みです。しかし直すにあたっても、そもそも私の考えが間違っていることが非常に多い自覚があります。

資料の補足と現状の理解を確認することを兼ねて少し現在の考えを書きますが、この資料や記事を読んでいただいた素敵な皆様がおかしいと感じられたことをご指導いただけると本当に嬉しいです。

Cloud Design Pattern

Cloud Design Pattern というと、AWS Cloud Design Patterns をぱっと思い浮かべることが多いと思います。しかし同時に Azure Design Pattern も浮かべる方も多いのではないでしょうか?私は、それぞれのデザインパターンを次のように大雑把に捉えています。

Cloud Design Pattern 大雑把な解釈
AWS-CloudDesignPattern インフラコンポーネント構成に関するデザインパターン
アンチパターンでないパターン集
Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications | Microsoft Learn サービス設計に関するデザインパターン
ベスト プラクティスパターン集

インフラ環境をDisposable(いつでも捨てられるよう)にする。これを実現するためにAWS上の構成変更を躊躇わず、マネージドサービスを積極的に利用し、インフラ全員がコードを書いています。しかし巷に溢れる優れたサービスを無差別に採用はできません、自分達にあったサービスを選択するための原則がないとすぐにカオスな状況に陥ります。

コード設計、サービス取捨選択の原則としている考え方が Azure の Cloud Design Pattern にある、Retry PatternExternal configuration store Pattern です。

Retry Pattern

AWS にかぎらず、パブリッククラウドにおける大原則であることが多いように思います。

そのための手法も多く公開されています。

docs.aws.amazon.com

azure.microsoft.com

グラニも同様に失敗しても再施行によって成功する構成を目指しています。*2

失敗時の処理方法を共有するのではなく、もう一回やればいい。

このシンプルさは失敗に対する心理的障壁を下げるだけでなく、チームに対しても単純で伝えやすいです。

External configuration store Pattern

グラニのインフラは、インスタンスを1台たてるのも100台立てるのも構成方法と処理時間に大きな違いがないようにしています。この担保をしている重要な要素が External configuration Pattern であり、スケーラビルティに大きく寄与すると思っています。

インフラは多くのミドルウェアが動きます。*3自分たちのコードもその1つです。そんな時に利用するのが External configuration store Patternです。

ミドルウェアをインスタンスに配置するにあたり、構成ファイルをデプロイ自体に含めるのではなく、S3 や Blob、場合によっては Github など外部に寄せるようにする。

もちろん自動デプロイ/再デプロイが高速、容易な場合はその限りではありません。またコードを書くにしても、AWS LambdaAzure Functions といった Serverless を利用できないかまず検討しています。*4

Github に push すれば、全サーバーの構成が速やかに自動的に変わるというのは楽なものです。

Stamp Pattern

さて、インフラ視点のクラウドデザインパターンとして採用しているのが Stamp Pattern です。*5

ウェブサーバーに限らず、事前構成に時間が掛かる役割のEC2は Stamp パターンを用いてることで、全て同一構成に揃うようにしています。

https://aws.clouddesignpattern.org/index.php/CDP:Stamp%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

この辺は過去にも記事で書いたことがあります。

gihyo.jp

個人的には柔軟性、展開速度、シンプルさの観点からStamp Pattern はかなり嫌いです。*6Amazon AMI に Configuration Management を適用するだけで済む場合は、Stamp Pattern を利用せず CM を適用するだけで構成しています。

このあたりはWindows版 Docker が Windows Server 2016 で出るのを心から待っています。リリースされたらすぐに乗り換えて、全サーバーコンポーネントを一新します。

他の基本としている要素

Design Pattern とは少し違いますが、基本としている要素があります。

速度

先日のセッションと公開した資料の中で、「何度も、素早く繰り返すこと」(高速なイテレーション)を重視していることを述べました。

リトライするにしても、1回の処理に30min もかかっていては繰り返し自体が困難です。なるべく一回の施行は高速に、そして短いスパンで繰り返せることを目指しています。

もちろん何でも速さが正義ではありません。頻度との兼ね合いで、一日1回しか実行しないなら数分、数秒に大きなこだわりを出しても仕方ないと思っています。

副作用を伴う改善は極力選択しない

「課題A」を改善するために、「回避不可能な別の課題B」を生じる。

そんな改善は選択しないように気をつけています。*7

もちろん程度問題なので、課題B が限定的だったり無視できるようなデメリットなら採用することが多いです。また、短期的にデメリットがあっても、すぐに改善するとわかっているなら課題の大きさによっては待たずに即採用もあります。*8

大事にしているのは、「根本の問題がなんなのか、原因を分析」することです。その場ですぐに解決できなくても後日ヒントや解決策に気づけるように意識づけています。

コスト意識

AWS EC2 なら、Lambda や S3 など「実行時課金」の Serverless へ変更できないかいつも考えています。

もしEC2でやるしかなくても、Spot Instance を積極的に採用しています。EC2 オンデマンドだったり、他のリソースなら Reserved Instance を検討します。

グラニのインフラにおいて、AWS 利用コストは当初と比較して劇的に改善しました。今も、不定期に構成を見なおして改善できないか検討しています。

自動化を常に考慮する

マネージドサービスを導入する際は、自動化できることを強く評価しています。Webhook、APIを含めて、サービス間連携できることが自動化手段を提供しているかどうかは重要です。

逆に、.NET SDK がなくとも APIが公開されていれば問題とすることがあまりありません。*9

そういえば AWS でウェブコンソールを使って最後にEC2を立てたのは3年前です。ずっと SDK 経由で作成しかしていません。

デプロイ戦略

今回構成したインフラ構成において、アプリは C#6.0、ASP.NET MVC 5.3.2 です。

そのため、2013年当時は MSDeployを用いていましたが、内製ツールのRapidHouse へと一年以上前に切り替えました。

残念ながらRapidHouse の公開は今のところ予定にないのですが、当初の構想通りデプロイが 1秒で終わるようにできたのは体感できるインパクトが大きくよかったと思っています。

ずっと言っているのですが、Windows におけるシンボリックリンクの重要性は極めて高く、インフラ構成を「柔軟、簡素」にできる可能性が高いのでぜひ検討してください。

mamiya の発表を見た時に、ほとんど同じ発想だったのでどこの環境でも同じことを考えるのだなぁと思い、ブラッシュアップのため参考にさせていただきました。

github.com

資料も非常に分かりやすかったので、セッション資料でも参考にしています。

speakerdeck.com

インフラ基盤を C#へ

RapidHouse によって 各Windowsサーバーの操作がAPI公開されているので、サーバーの管理は PowerShell Remoting から HTTP(S)経由に完全移行し、C# がフル活用できるようになっています。

察しの良い方は気づかれた通り、昔のグラニは PowerShell をインフラの中心としていましたが、現在はC# が中心になっています。

もちろんPowerShell も利用しますが、ただのツールです。PowerShell DSC の Configuration や ワンライナー、補助スクリプトがメインで長大なコードは次々とC#にリプレースされています。

構成図の見直し

今回は、ヴァルハラゲートの構成図でしたが、最初期からみてどんどん変わっていっています。

変化は大事だと思っています。停滞はサービスの死に直結します。

そして変化の記録と公開も同様に大事にしています。弊社のサービス構成図は、CTOのスライド でも度々引用されています。

少し時系列で並べて見ます。構成図にない変化がかなりあるのですが、ここでは触れません。

時期 構成図
2013年3月
2013年9月
2014年1月
2015年12月
2016年5月

構成図自体も変化しています。従来は構成図を Visio で書いていましたが、現在は CloudCraft に移行しています。Visio、昔から使っていますが、ついにトドメを刺せました。

だれでも直感的に使えて再利用も共有も可能。しかも、コンポーネントの違いも3D で表現しやすい構成図。CloudCraft はそんなサービスだと思います。

cloudcraft.co

まとめ

どうでしょうか?目新しいことがない、ふつーの構成ではありませんか?Windows を AWS で使うのがツラい、Linux にしたいという声をよく聞きますが、私達は Unix/Linux でのふつーをWindows でも十分に構築できると考え実践する努力をしています。インフラの多くのコンポーネントは、実は Serverless だったりもします。

AWSにロックイン、ということもよく耳にしますが一切そんなことはありません。AWS じゃなくても、いつでも Azure や Google Cloud Platform に移行できる体制でもあります。それでも AWS を使うのは全てのバランスとAurora などの各リソースの強力、安定さからです。

グラニのインフラが目指しているのは、Windowsでうんぬんより、ユーザーにサービスをよりよく楽しんでもらえることです。そのためにできることをチーム全員が積極的に挑戦しています。Linux には、共有するという文化から始まり、多くの面でインフラのトレンドを突き進んでいます。新しい考え方、手法にはサービスがより良くなることが多く秘められています。それが Windows でできないということは誰も言っていません、だから採用する努力をしています。

あ、あと、グラニのこんなインフラを変えたい、もっと良くしたいとお考えの方をインフラ一同心からお待ちしています。

*1:Immutable Infrastructure というより Disposable Infrastructure という方がグラニには適しています

*2:失敗したらリトライ可能な状態にロールバックする、冪等性を担保するなど、多くのやり方があるでしょう

*3:なるべく動かしたくないですし、減らすことを常に図っていますが!

*4:AWS Lambda が C# に対応してくれれば、Azure Functions にある不満が API Gateway/Lambda で強く改善できるので変更するのですが...

*5:いわゆるゴールデンイメージですね

*6:正確にはEC2が嫌いです

*7:それでも失敗します……

*8:なるべく待ちますが

*9:特に Swagger に対応していると嬉しいです

Remote Desktop Web Access の Remote Apps が重複する問題の対処

Remote Desktop Service (リモートデスクトップサービス) には、RD Web Access (RD Web アクセス) と RD Session Host (RD セッションホスト)呼ばれる機能があります。

これらの機能を使うことで、Remote Desktop Service で展開している Remote Apps を公開できます。

今回は、この Remote Apps が重複して表示される問題への対処について。

目次

Remote Apps の公開

たとえば、以下のような RD Web Apps 公開設定します。

すると、Web Access に対してブラウザ経由でアクセスした際に 通常は以下のようにRemote Apps が公開されます。

このRemote Apps の実行はあくまでも Remote Desktop Service サーバーで実行されているので、一見すると Windows や iOS、Android など OS を問わず実行が可能です。

重複した表示

しかし、Remote Desktop Service の機能をアンインストールしてからインストールし直した場合に「RD Web Appsが重複して表示」される場合があります。

正確には、前回の構成で表示していた RD Web Apps が表示されてしまいます。つまり以下の状態。

この状態は利用者からするとかなり厄介で、今回の Remote Desktop Service 構成で設定した RD Remote Apps ではないアプリを選択するとエラーが発生します。Feed 表示でも同様に重複していることから、キャッシュによるものでもありません。しかも見た目で判断は不可能です。

2件ほど似たような事例がありますが、どれも違う場合に役に立つでしょう。

問題となった設定を探す

インストールの流れを疑ってみましょう。

Server Manager の GUI 表示

設定にしたがって Server Manager > Remote Desktop Service > Collection から設定した RD Web Apps を見て見るでしょう。しかし、重複はありません。

PowerShell での Collection 表示

また、PowerShell で RD Session Collection が重複しているか見ても重複はありません。

gist.github.com

CollectionName                 Size ResourceType       CollectionDescription
--------------                 ---- ------------       ---------------------
<設定した CollectionName>      1    RemoteApp プロ...  RD Session Collection
RDWeb のフォルダ状態

RDWeb の IIS 設定は、 %WinDir%\Web\RDWeb に中身があります。

当然キャッシュもなく、Default.aspx、Default.aspx.cs にも異常はありません。

つまり、物理構成でも論理構成でもないということです。

原因はレジストリ

RD Remote Apps の実態は、設定するとレジストリに登録されます。大事なのは、PublishFarms 以下です。

PowerShell を使うと楽でしょう。

gist.github.com

通常は上記のように設定した コレクション名のエントリのみになります。しかし重複している場合は、PublishedFarms 配下に設定していないコレクション名が存在しています。

対処

レジストリから設定していないコレクション名を削除して、Remote Desktop Service を再起動してください。*1これで Remote Apps の重複が修正されます。

もしこれでダメな場合は、Remote Desktop Service の機能を入れなおせば間違いなく治ります。

まとめ

Remote Desktop Service を入れなおした時は、レジストリが汚いままなので気をつけましょう。

*1:あるいはサーバー再起動でもいいです