From c9e6ffa91c459587e47f16e03bb13bfcab6b23a6 Mon Sep 17 00:00:00 2001 From: DanHam Date: Mon, 16 Oct 2017 02:45:56 +0100 Subject: [PATCH] Add warning note about using the 'winrm quickconfig -q' command A lot of examples out there on the web make use of this command to configure the instance to allow connections over WinRM. Since the danger is not immediately obvious and the failure because of its use intermittent, we should do our best to advise against its use here. --- .../intro/getting-started/build-image.html.md | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/website/source/intro/getting-started/build-image.html.md b/website/source/intro/getting-started/build-image.html.md index 2cdddf544..c66b04d04 100644 --- a/website/source/intro/getting-started/build-image.html.md +++ b/website/source/intro/getting-started/build-image.html.md @@ -408,6 +408,29 @@ Start-Service -Name WinRM Save the above code in a file named `bootstrap_win.txt`. +-> **A quick aside/warning:** +Windows administrators in the know might be wondering why we haven't simply +used a `winrm quickconfig -q` command in the script above, as this would +*automatically* set up all of the required elements necessary for connecting +over WinRM. Why all the extra effort to configure things manually? +Well, long and short, use of the `winrm quickconfig -q` command can sometimes +cause the Packer build to fail shortly after the WinRM connection is +established. How? +1. Among other things, as well as setting up the listener for WinRM, the +quickconfig command also configures the firewall to allow management messages +to be sent over HTTP. +2. This undoes the previous command in the script that configured the +firewall to prevent this access. +3. The upshot is that the system is configured and ready to accept WinRM +connections earlier than intended. +4. If Packer establishes its WinRM connection immediately after execution of +the 'winrm quickconfig -q' command, the later commands within the script that +restart the WinRM service will unceremoniously pull the rug out from under +the connection. +5. While Packer does *a lot* to ensure the stability of its connection in to +your instance, this sort of abuse can prove to be too much and *may* cause +your Packer build to stall irrecoverably or fail! + Now we've got the business of getting Packer connected to our instance taken care of, let's get on with the *real* reason we're doing all this, which is actually configuring and customizing the instance. Again, we do this