joefitzgerald / packer-windows Goto Github PK

On rare occasions I've noticed a race condition between installing OpenSSH and configuring the files it installs:

• C:\Program Files\OpenSSH\etc\passwd
• C:\Program Files\OpenSSH\etc\sshd_config
• C:\Users\vagrant.ssh\environment

Basically the batch file can error out with file not found errors.

Running packer build -only vmware-iso builds the machine but errors at the end with the following:

Build 'vmware-iso' errored: Error compacting disk: VMware error: VixDiskLib: Invalid configuration file parameter. Failed to read configuration file.
Failed to open the disk '/Users/jcastillo/Documents/Git/packer-windows/output-vmware-iso/disk.vmdk' : The specified virtual disk needs repair (0xe00003e86).
Failed to defragment: The specified virtual disk needs repair (0xe00003e86).

==> Some builds didn't complete successfully and had errors:
--> vmware-iso: Error compacting disk: VMware error: VixDiskLib: Invalid configuration file parameter. Failed to read configuration file.
Failed to open the disk '/Users/jcastillo/Documents/Git/packer-windows/output-vmware-iso/disk.vmdk' : The specified virtual disk needs repair (0xe00003e86).
Failed to defragment: The specified virtual disk needs repair (0xe00003e86).

The virtual box build does work.

#61 refers to me making an Windows Embedded 8.1 image with packer on OS X. When I try to vagrant up with that, the VM loads fine. However, it hangs on "Waiting for the VM to finish booting..." and never returns to console.

Any pointers as to what might be causing this would be appreciated. I can ssh to the VM at this point.

First time i tested on the windows 7 and seems that is not installing the updates.

The latest changes added a call to microsoft-updates.bat in the Autounattend.xml for all the systems, but it is only placed on the floppy image for the server OSs, not for windows 7 or 8.
Which is correct - copy it to the floppy for all the systems or remove it from the Autounattend.xml for windows 7 and 8?

Regarding issue #3 comment by @sneal: In fact I'd rather not install Cygwin if I could.

I am having some success using OpenSSH for Windows 5.3 from coming from Chocolatey and also the 6.2 from mls-software.

The initial ssh handshake and scp operation to copy over .vbox_version work great but any subsequent scp operations blow up. I'm hoping it's something I can fix from the sshd configuration side, but it's strange how I can ssh and scp manually just fine but packer can't do more than one run against it. Investigation ongoing....

If there are similar ideas out there, I'd like to hear about it before I go too far down the rabbit hole.

This line, and the ones doing the same following it:

https://github.com/joefitzgerald/packer-windows/blob/v1.11/answer_files/2008_r2_core/Autounattend.xml#L152

Don't work. They fail to set the execution policy because powershell.exe is not in the PATH. Changing the call to the full path of powershell appears to solve the problem,

I dont ahve time for a pull but for virtualbox vm-guest tools i would change the code to this.

:virtualbox

move /Y C:\Users\vagrant\VBoxGuestAdditions.iso C:\Windows\Temp

cmd /c ""C:\Program Files\7-Zip\7z.exe" x C:\Windows\Temp\VBoxGuestAdditions.iso -oC:\Windows\Temp\virtualbox"
:: There needs to be Oracle CA (Certificate Authority) certificates installed in order
:: to prevent user intervention popups which will undermine a silent installation.
cmd /c C:\Windows\Temp\virtualbox\cert\VBoxCertUtil add-trusted-publisher C:\Windows\Temp\virtualbox\cert\oracle-vbox.cer --root C:\Windows\Temp\virtualbox\cert\oracle-vbox.cer
cmd /c C:\Windows\Temp\virtualbox\VBoxWindowsAdditions.exe /S
goto :done

it will register the cer file taht came with the iso and not the one in your a dirve... this fixes the install failure of the guest tools... i think the cer changes in 4.3.10 and above.

This would ensure that a base box does not begin counting down the activation clock until you use it for the first time - at the expense of using up one of the three sysprep /generalize runs that you can do (http://technet.microsoft.com/en-us/library/dd744512(v=ws.10).aspx).

Picking up the conversation where we left off in Dylan's pull request: #1 .

I think there are a few dimensions that are required for a minimally useful packer-windows template:

• Operating System Version
  • Windows 7
  • Windows 2008 R2
  • Windows 8
  • Windows 2012
  • Windows 8.1
  • Windows 2012 R2
• Operating System Edition
  • Desktop
    • Windows 7
      • Starter
      • Home Basic
      • Home Professional
      • Professional
      • Enterprise
      • Ultimate
    • Windows 8
      • Windows 8
      • Pro
      • Enterprise
  • Server
    • Standard
    • Enterprise
    • Datacenter
• Builder
  • VMware
  • VirtualBox
  • Others
• Provisioners
  • Script
  • PowerShell
  • Chef
  • Puppet
  • Other

If we could provide some level of reuse at each level (OS Version, OS Edition, Builder, Provisioner), that would hopefully drastically reduce the number of distinct .json files we manage (because we can generate them).

I agree with Shawn that we need to maintain the ability to customize, which could be achieved via the build process, or by providing hooks for extensibility (e.g. if user defined script x exists, run it after the core provisioning steps). Also, there's nothing stopping someone from taking a .json file we generate and then customizing it from there.

Does that make sense? Do you think I'm missing any obvious requirements?

I have been trying to test a developer machine set up - so switched off Windows updates via the AutoUnattend.xml file. I then added the chocolatey.bat and chocopacks.bat files to the provisioners section of the build (using virtualbox-iso). I am now facing an issue that the Chocolatey elevated permissions as part of the install takes a long time and then the chocopacks.bat file fails as it states the box is not connected.

I assume I am using the Chocolatey scripts as they were intended - or are these intended as Vagrant provisioning scripts rather than Packer scripts? I turned of the Windows updates to enable me to test the provisioning scripts based on the basebox faster. I had previously had success with the Window updates turned on.

I am continuing to investigate the problem I am having, but if anyone has any pointers/ideas that would be much appracited.

For a while now I've been unable to run the Windows 8.1 packer build with Windows Updates enabled and some additional custom provisioners (I'm using it to install Visual Studio etc).

This was successful prior to the upgrade of OpenSSL around the time of heartbleed, however. Is there some trick I've missed with having to swap the order of provisioners around to deal with reboots or similar?

Hi there,

I'm trying to build a Windows Server 2012 R2 Core image using packer. Packer completes successfully, and I get two .box files at the end which successfully boot, however vagrant up yields:

$ vagrant up
Bringing machine 'vagrant-windows-2012-r2-core' up with 'vmware_fusion' provider...
==> vagrant-windows-2012-r2-core: Cloning VMware VM: 'windows-2012-r2-core'. This can take some time...
==> vagrant-windows-2012-r2-core: Verifying vmnet devices are healthy...
==> vagrant-windows-2012-r2-core: Preparing network adapters...
==> vagrant-windows-2012-r2-core: Starting the VMware VM...
==> vagrant-windows-2012-r2-core: Waiting for the VM to finish booting...

It then just hangs forever. If I uncomment the v.gui = true line in the Vagrantfile I can see that it successfully boots and logs in as the vagrant user, it's just that vagrant doesn't seem to notice that this completed.

For the moment I'm going to go ahead and use the Windows 2012 R2 image (not Core) so I can keep moving, but does anyone have any experience as to why this wouldn't work?

I used the Vagrantfile template from the repo for 2012 R2 to spin it up with no modifications (other than renaming it from whatever.template and toggling the comment on v.gui as I mentioned above).

I'm on VMWare Fusion 5.0.5 and OS X 10.8.5 if that helps.

I have an issue with Virtualbox only with the Autounattended.xml file.

https://gist.github.com/lmayorga1980/8462481

I tried uninstalling and reinstalling VirtualBox with no results.

https://github.com/joefitzgerald/packer-windows/blob/master/answer_files/2008_r2_core/Autounattend.xml

32 bit
%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

64 bit
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe

When I use vagrant to init and up a windows_2012_r2_standard box I was getting a password expired message for the Vagrant user.

Note: I'm using the box uploaded to VagrantCloud by @kensykora https://vagrantcloud.com/kensykora/windows_2012_r2_standard

Hi, I'm quite happy to be able to use packer to build Windows images thanks to this project. I want to deploy VMs (actually, VM templates are my end goal) onto a vSphere instance, but haven't managed it yet.

I have modified the packer configuration, adding '"keep_input_artifact": true' to the vagrant builder, and tried running ovftool on the .vmx file that gets created in the output directory.

But ovftool fails because it has a path to floppy0, which doesn't exist.

Error message:

Error: File (/var/folders/zl/57c1vmr532z_ryf1scw53_b9ycmxh7/T/packer964492999) could not be found.

From the .vmx file:

floppy0.filename = "/var/folders/zl/57c1vmr532z_ryf1scw53_b9ycmxh7/T/packer964492999"
floppy0.filetype = "file"
floppy0.present = "TRUE"

So I'm not sure if there's a way to generate the .vmx file without the floppy drive - presumably, once the OS has been installed and we don't need the Autounattend.xml file anymore, it can be detached.

Is there a change needed to the config file to make this work, or something else I could do? I could post-process the .vmx file to disable the drive, but it feels like a hack. Either I'm doing something wrong, or there's an improvement to be made somewhere.

Thanks,
Kief

Since I have to work on other stuff today, I'm dropping in notes for a few issues I'm planning on working on over the next week or so, but someone else can feel free to jump in and let me know if they're not great ideas or not:

Each time the box starts up from a fresh init, the .NET runtime optimization service pegs the CPU for what seems like 10-15 minutes which is a background task with low priority that compiles/optimizes the .Net framework for the current CPU type. This process can and should be forced to complete before the box is packaged up so that users don't have to deal with the CPU pegs on fresh init's.

http://support.microsoft.com/kb/2570538

Right at the end of building a windows 7 VM packer failed with an error from what looks like an internally generated script.

This is Windows 7 building virtualbox. I'm on the latest versions of virtualbox, vagrant and packer. Everything has gone fine building the image (including all updates) and provisioning seems to have completed with the following scripts (all from the packer-windows project):

"./scripts/vm-guest-tools.bat",
"./scripts/enable-remote-desktop.bat",
"./scripts/vagrant-ssh.bat",
"./scripts/puppet.bat"

The console ouput ends with:
==> virtualbox-iso: Provisioning with shell script: ./scripts/puppet.bat
virtualbox-iso:
virtualbox-iso: C:\Users\vagrant>if not exist "C:\Windows\Temp\puppet.msi" (powershell -Command "(New-Object System.Net.WebClient).DownloadFile('http://downloads.puppetlabs.com/windows/puppet-3.5.1.msi', 'C:\Windows\Temp\puppet.msi')" 0<NUL )
virtualbox-iso:
virtualbox-iso: C:\Users\vagrant>msiexec /qn /i C:\Windows\Temp\puppet.msi /log C:\Windows\Temp\puppet.log
virtualbox-iso:
virtualbox-iso: C:\Users\vagrant>set /p ".=;C:\Program Files (x86)\Puppet Labs\Puppet\bin" 0<nul 1>>C:\Windows\Temp\PATH
virtualbox-iso:
virtualbox-iso: C:\Users\vagrant>set /p PATH= 0<C:\Windows\Temp\PATH
virtualbox-iso:
virtualbox-iso: C:\Users\vagrant>setx PATH "C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Puppet Labs\Puppet\bin" /m
virtualbox-iso:
virtualbox-iso: SUCCESS: Specified value was saved.
==> virtualbox-iso: Provisioning with shell script: C:\Users\mbayliss\AppData\Local\Temp\packer-shell448994023
virtualbox-iso: rm: cannot remove `/tmp/TMP000000060D8C519E2AA75846': Device or resource busy
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Script exited with non-zero exit status: 1

Anybody seen this before? Any suggestions for a workaround?

Thanks,

Mike

I'm having some problems where, if I watch the install happen I see flashes of red text.

How can I find out what actually happened? I don't see any logging of the various commands anywhere.

Is there any guidance on debugging issues with the provisioning?

I've spent quite a bit of time trying to debug chef_client issues. Oddly, if I run the batch files or commands directly via ssh vagrant@host they always work. However, the packer provisioner will fail whenever chef_client shells out. I've tried running chef_client as a scheduled task, but now I'm running into the same thing with schtasks where packer doesn't seem to have permissions yet when running the commands directly works without issues. Any thoughts? I'm thinking of trying to switch to a full cygwin install.

This might be a VirtualBox issue with their latest version of the Guest Additions for Windows on 2012R2. Seems that are not installed properly.

Going back to 4.3.7.

guest_os_type at:

Not sure if this has been discussed before. I think that one can get huge some disk savings by running the following script during provisioning:

http://gallery.technet.microsoft.com/scriptcenter/CleanMgrexeKB2852386-83d7a1ae

The drawback is that windows updates could not be rolled back subsequently, but I'm quite sure many people could accept this.

If you're willing to consider this enhancement I could even work myself on a patch as soon as I can.

RDP is disabled for the user 'vagrant' so running the command 'vagrant rdp' fails.

Work Around

Poweroff the VM in VirtualBox and then start it from VirtualBox, this will allow you to use the Windows interface to change the RDP settings for the Vagrant user and allow RDP access.

This might be a well-known problem in the context of Windows boxes, but it took me a good long time debugging this before I realized exactly what the problem was and how to work around it.

As Packer currently only uses an SSH connector through Cygwin, Chef doesn't have a correct set of environment variables to work with for paths. Specifically, I was attempting to add the Chef package 7-zip and it repeated failed as it couldn't locate msiexec.exe.

If these results are accurate, I'm proposing additional documentation in the README so that future developers won't pull their hair out when Chef cookbooks like Git work properly, but other packages fail seemingly for no reason. I don't think it's worth trying to work around this issue outside of just recommending that developers add a second Vagrant step in their pipeline for configuring Chef cookbooks as Packer should receive proper WinRM support in the future.

I've attached my proposed edits to the readme in #102.

Hoping this is just an intermittent issue at Microsoft.

Tried several times with packer and curling directly myself—Microsoft's server resets the connection soon after it starts.

curl -L http://care.dlservice.microsoft.com/dl/download/evalx/win7/x64/EN/7600.16385.090713-1255_x64fre_enterprise_en-us_EVAL_Eval_Enterprise-GRMCENXEVAL_EN_DVD.iso -o 7600.16385.090713-1255_x64fre_enterprise_en-us_EVAL_Eval_Enterprise-GRMCENXEVAL_EN_DVD.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 2976M    0 27.0M    0     0  2228k      0  0:22:47  0:00:12  0:22:35 2066k
curl: (56) Recv failure: Connection reset by peer

Comparing a Cygwin/OpenSSH sshd.conf (https://gist.github.com/joefitzgerald/7914669) with a Standalone/OpenSSH sshd.conf (https://gist.github.com/dylanmei/7914583), there appear to be significant differences.

This may explain the issue #700 @sneal reported in the packer repo. We should discuss the significance of each and resolve those differences that are incorrect.

What I'm trying to do is repurpose the windows_2008_r2.json file by swapping out scripts/chef.bat for scripts/puppet.bat and then calling out to puppet-masterless to install and run my manifests.

The scripts/puppet.bat file is being executed and puppet is being installed correctly. However, once puppet apply is invoked by puppet-masterless the execute_command is shown, but my manifest is not being executed and no additional output/errors are shown (even with PACKER_LOG=1 set).

For testing purposes, I have been using the following custom execute_command:

"execute_command": " \
    {{.FacterVars}}puppet apply \
        --debug \
        --logdest='C:/Windows/Temp/puppet-apply.log' \
        --modulepath='{{.ModulePath}}' \
        --manifestdir='{{.ManifestDir}}' \
        --detailed-exitcodes \
        -e 'include rubyinstaller' \
"

NOTES:

• The spacing and EOL \s were added here for readability purposes only
• I am using packer 0.5.2
• When the execute_command "runs", the logdest file does not get created
• I have even tried specifying the absolute path to puppet's bat file under Program Files just in case the guest OS PATH was not visible at the time puppet-masterless ran -- no effect
• When I pause packer after the puppet-masterless step and I execute the generated execute_command at the guest Windows VM's command prompt, the execution works.
• The (custom) "rubyinstaller" module that I'm using is attempting to install rubyinstaller in "verysilent" mode. Has anyone seen any limitations with puppet-masterless when using an installer on windows that requires a desktop?
• I've also noticed on Windows with packer that if puppet apply fails or a shell script returns a non-zero ERRORLEVEL, packer keeps on going. Any suggestions on how to fail-fast? (EDIT: this bullet looks suspiciously like #45)
• I only know this from the occasional warning that I'm seeing, but It appears that cygwin is being used under the covers by puppet-masterless. Any other gotchas I should keep in mind when working with custom execute_commands?

I realize that some of these questions may be best asked on the packer forum, but since these questions are very windows specific, I'm wondering if other trailblazers here have already encountered and resolved these issues.

On the following lines it seems that is looking for an env variable.(line 6 and 7)

if "%PACKER_BUILDER_TYPE%" equ "vmware" goto :vmware
if "%PACKER_BUILDER_TYPE%" equ "virtualbox" goto :virtualbox

Do i need to set this somewhere or as a environment variable before running packer build?

It doesn't seem to be executed.

==> virtualbox-iso: Provisioning with shell script: ./scripts/vm-guest-tools.bat
    virtualbox-iso:
    virtualbox-iso: C:\Users\vagrant>if not exist "C:\Windows\Temp\7z920-x64.msi" (powershell -Command "(New-Object System.Net.WebClient).DownloadFile('http://downloads.sourceforge.net/sevenzip/7z920-x64.msi', 'C:\Windows\Temp\7z920-x64.msi')"  0<NUL )
    virtualbox-iso:
    virtualbox-iso: C:\Users\vagrant>msiexec /qb /i C:\Windows\Temp\7z920-x64.msi
    virtualbox-iso:
    virtualbox-iso: C:\Users\vagrant>if "virtualbox-iso" EQU "vmware" goto :vmware
    virtualbox-iso:
    virtualbox-iso: C:\Users\vagrant>if "virtualbox-iso" EQU "virtualbox" goto :virtualbox
    virtualbox-iso:
    virtualbox-iso: C:\Users\vagrant>goto :done
    virtualbox-iso:
    virtualbox-iso: C:\Users\vagrant>msiexec /qb /x C:\Windows\Temp\7z920-x64.msi
==> virtualbox-iso: Provisioning with shell script: ./scripts/puppet-enterprise.bat
    virtualbox-iso:

I'm pretty sure this is an issue -- in the latest version the secure delete and defragger was running while windows updates was still doing its thing. In the latest version you updated SSH, this seems to open up SSH as soon as the install finishes?

This happens after almost all steps of installation are done, and chef script is run.

'vmware-iso' errored: remove output-vmware-iso\564dfbe7-d762-be2a-1600-9b769835764e.vmem: Access is denied

Tried powershell, but the result remains the same. Any clues?

I am using a fork with my own JSON for windows embedded 8.1, which is practically windows 8.1.

I believe 7zip is one of the most trusted utilities that allow extract/compress most linux/windows formats and it should remain on the windows machines.

msiexec /qb /x C:\Windows\Temp\7z920-x64.msi

Packer 0.5.1 add config.vm.base_mac = "{{ .BaseMacAddress }}" by default. Leaving this in the template breaks first vagrant up. Next time you run vagrant up this message vill disappear. This can be fixed by removing config.vm.base_mac = "{{ .BaseMacAddress }}" in the templates.

When I build the packer template windows_2008_r2.json, it always builds successfully. However, when I try to run it with the corresponding vagrant file provided in the repo, I always get a BSOD. I'm using the .iso given in the packer template.

Trying to uninstall openssh remotely, has anyone been able to do so? It seems to run but doesn't actually complete. However, running it in a UI session works without issues with "c:\program files\openssh\uninstall.exe" /S. I think it has to do with the uninstaller creating new cmd processes to execute things.

When creating a Windows 7 box once all updates had been made the Waiting for SSH.... would just timeout. I stopped the box and restarted it to find that OpenSSH was disabled as a service.

Is the -Autostart flag that is used when not running windows updates (my SSH problem goes away at this time) needed for the windows update openssh command in the Autounattend.xml?

Hi there, I attempting to use your packer templates for windows 7 64 sp1. I'm being stopped at the following command:

==> virtualbox: Typing the boot command...
==> virtualbox: Waiting for SSH to become available...

Eventually I get a SSH timeout. I've inspected the VM that was created and OpenSSH is installed.

Any ideas as to why packer doesn't see SSH?

Thanks for this project.

TDFord

I tried to debug a windows 2008 r2 core installation with headless = false but it is not working with the latest packer and virtualbox 4.3.6

I'm trying to test out with Vagrant 1.6.2 features now since that code is added in, but I'm running into an odd issue that I'm not sure if it's an issue with Vagrant or the configuration of the Vagrantfile.

When I run vagrant up using the boxes produced the process stalls at the point where it's trying to connect via WinRM. Here's the output when running with info debug level:

Shell: powershell
Command: hostname
if ($LASTEXITCODE) { exit $LASTEXITCODE } else { exit 0 }
Message: execution expired>
 INFO winrm: Checking whether WinRM is ready...
 INFO subprocess: Starting process: ["/Applications/VMware Fusion.app/Contents/Library/vmrun", "list"]
 INFO vmware_driver: Reading an accessible IP for machine...
 INFO vmware_driver: Reading VMX data...
 INFO vmware_driver: Reading DHCP lease for '00:0c:29:3d:ff:e0' on 'vmnet8'
 INFO vmware_driver: DHCP leases file: /var/db/vmware/vmnet-dhcpd-vmnet8.leases
 INFO dhcp_lease_file: Initialized DHCP helper: /var/db/vmware/vmnet-dhcpd-vmnet8.leases
 INFO dhcp_lease_file: Looking for IP for MAC: 00:0c:29:3d:ff:e0
 INFO dhcp_lease_file:   - IP: 192.168.125.161
 INFO provider: Execute capability: forwarded_ports [#<Vagrant::Machine: default (HashiCorp::VagrantVMwarefusion::Provider)>] (vmware_fusion)
 INFO winrmshell: Attempting to connect to WinRM...
 INFO winrmshell:   - Host: 192.168.125.161
 INFO winrmshell:   - Port: 55985
 INFO winrmshell:   - Username: vagrant
 INFO winrm: WinRM not up: #<VagrantPlugins::CommunicatorWinRM::Errors::ExecutionError: An error occurred executing a remote WinRM command.

Shell: powershell
Command: hostname
if ($LASTEXITCODE) { exit $LASTEXITCODE } else { exit 0 }
Message: execution expired>
 INFO winrm: Checking whether WinRM is ready...
 INFO subprocess: Starting process: ["/Applications/VMware Fusion.app/Contents/Library/vmrun", "list"]
 INFO vmware_driver: Reading an accessible IP for machine...
 INFO vmware_driver: Reading VMX data...
 INFO vmware_driver: Reading DHCP lease for '00:0c:29:3d:ff:e0' on 'vmnet8'
 INFO vmware_driver: DHCP leases file: /var/db/vmware/vmnet-dhcpd-vmnet8.leases
 INFO dhcp_lease_file: Initialized DHCP helper: /var/db/vmware/vmnet-dhcpd-vmnet8.leases
 INFO dhcp_lease_file: Looking for IP for MAC: 00:0c:29:3d:ff:e0
 INFO dhcp_lease_file:   - IP: 192.168.125.161
 INFO provider: Execute capability: forwarded_ports [#<Vagrant::Machine: default (HashiCorp::VagrantVMwarefusion::Provider)>] (vmware_fusion)
 INFO winrmshell: Attempting to connect to WinRM...
 INFO winrmshell:   - Host: 192.168.125.161
 INFO winrmshell:   - Port: 55985
 INFO winrmshell:   - Username: vagrant

In this case, the 192.168.125.161 IP is the IP of the Guest OS, and as you can see it's trying to connect on port 55985 rather than 5985. I tried manually opening a connection to 5985 and the box is responding on that port, but I don't know how to change the port in the Vagrantfile or if it's even possible, and is just an issue with Vagrant.

Any ideas?

After the image is boxed up, and a user init's and up's it, it continues to auto login on the vm console when it boots up. This is unnecessary and will use up some memory resources since running vagrant rdp will initiate a new desktop session. It'd be nice if we could remove the auto-login configuration before the box is packaged up.

What do you think about having some user env variables to set the puppet release/version for the provisioning.

"variables": {
    "vagrant_user": "vagrant",
    "vagrant_password": "vagrant",
    "puppet_release": "PUPPET_RELEASE=OPEN",
    "puppet_version": "PUPPET_VERSION=3.6.1"
    },
  ...

    "provisioners": [{
    "type": "shell",
    "environment_vars": [ "{{user `puppet_release`}}",
                          "{{user `puppet_version`}}"
                        ],
 ....

With this approach there will be no need to edit the puppet version in the .bat file

I guess having a lot of logic on the .bat file for the release and version would be a little dirty as well.

Just a though here.

Hi,

I get an ssh handshaking error when disabling the Windows Update XML Nodes but it works when the Updates Get Executed.

Current configuration doesn't support rsync because the RSync client isn't installed in OpenSSH. I tested this out locally by copying the rsync.exe binary from http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/rsync/ and dragged it into C:\Program Files\OpenSSH\bin on the guest (server 2012r2)

I then configured my vagrantfile to rsync a directory:

  config.vm.synced_folder '.', "/cygdrive/c/vagrant-rsync",
    type: "rsync",
    rsync__auto: "true",
    rsync__exclude: [".git/",".vagrant/"],
    id: "vagrant"

the /cygdrive/c/ was necessary to prevent vagrant from interpreting a warning as an error

After that, rsync folders worked on the guest OS with an OSX Host.

I have tried a couple of time to install chocolatey packages using .bat files. But I keep failing. I'm using package build windows_2012.json. And added an extra script like so :

"provisioners": [{
      "type": "shell",
      "remote_path": "/tmp/script.bat",
      "execute_command": "{{.Vars}} cmd /c C:/Windows/Temp/script.bat",
      "scripts": [
        "./scripts/vm-guest-tools.bat",
        "./scripts/chocolatey.bat",
        "./scripts/chocopacks.bat"
      ]
    }, {
      "type": "shell", "inline": ["rm -rf /tmp/*"]
  }]

The chocopacks.bat contains :

set /p PATH=<C:\Windows\Temp\PATH
cinst Dogtail.VisualStudio2012Ultimate
cinst nodejs.install
cinst GoogleChrome
cinst Firefox
cinst git.install
cinst Console2
cinst sublimetext2

Any tips on this would be very welcome!

I noticed today on a fresh box I was spinning up was a runaway CPU issue taking up 50% of the CPU on an otherwise idle box. Task manager showed rundll32.exe at 50% cpu constantly (2-cpu VM). Using Process Explorer and a Stack Trace on the thread I get this:

ntoskrnl.exe!KeSynchronizeExecution+0x2246
ntoskrnl.exe!KeRemoveQueueEx+0x108e
ntoskrnl.exe!KeRemoveQueueEx+0xae9
ntoskrnl.exe!KeWaitForSingleObject+0x22a
ntoskrnl.exe!KeSetBasePriorityThread+0x4ec
ntoskrnl.exe!KeRemoveQueueEx+0x281d
ntoskrnl.exe!KeSynchronizeExecution+0x4133
msi.dll!MsiSetOfflineContextW+0x1254c0
msi.dll!MsiSetOfflineContextW+0x128829
msi.dll!MsiSetOfflineContextW+0x176f9e
msi.dll!MsiSetOfflineContextW+0x176e7d
msi.dll!MsiViewFetch+0xa9
aeinv.dll!UpdateSoftwareInventoryW+0x45245
aeinv.dll!UpdateSoftwareInventoryW+0x45578
aeinv.dll!UpdateSoftwareInventoryW+0x28e63
aeinv.dll!UpdateSoftwareInventoryW+0x27677
aeinv.dll!UpdateSoftwareInventoryW+0xedd4
aeinv.dll!UpdateSoftwareInventoryW+0xc812
aeinv.dll!UpdateSoftwareInventoryW+0xcce8
aeinv.dll!UpdateSoftwareInventoryW+0xcb70
aeinv.dll!CreateSoftwareInventory+0x43b
aepdu.dll!AePduRunUpdateW+0x2fb3
aepdu.dll!AePduRunUpdateW+0x109e
aepdu.dll!AePduRunUpdateW+0x1a39
aepdu.dll!AePduRunUpdateW+0x24d0
aepdu.dll!AePduRunUpdateW+0xc5
rundll32.exe+0x249a
rundll32.exe+0x3e68
KERNEL32.DLL!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x1d

Googling for aeinv.dll reveals that it's part of the Microsoft Application Experience program, which I'm pretty sure you can opt out of. Opening up server manager confirms this (Local Server / Customer Experience Improvement Program - Participating)

I killed the runaway task in task manager and it didn't start back up -- I'm not sure if this confirms what I'm thinking is the issue or not, but I think it'd be best to setup the box to build defaults and opt out of the customer experience program.

Upon building a vmware vagrant box, it always asks for a newer version of the VMWare tools. Is it possible to update

powershell -Command "(New-Object System.Net.WebClient).DownloadFile('http://softwareupdate.vmware.com/cds/vmw-desktop/ws/10.0.1/1379776/windows/packages/tools-windows-9.6.1.exe.tar', 'C:\Windows\Temp\vmware-tools.exe.tar')" <NUL

To pull down a later version? I was trying to find one to update mine locally, but could not seem to find one.