OK, after unsuccessfully trying all methods mentioned here, I finally got it working. Basically, the missing step was to write a proper boot sector to the USB stick, which can be done from Linux with ms-sys or lilo -M. This works with the Windows 7 retail version.
Here is the complete rundown again:
Install ms-sys - if it is not in your repositories, get it here. Or alternatively, make sure lilo is installed (but do not run the liloconfig step on your local box if e.g. Grub is installed there!)
Check what device your USB media is assigned - here we will assume it is /dev/sdb. Delete all partitions, create a new one taking up all the space, set type to NTFS (7), and remember to set it bootable:
# cfdisk /dev/sdb or fdisk /dev/sdb (partition type 7, and bootable flag)
Create an NTFS filesystem:
# mkfs.ntfs -f /dev/sdb1
Write Windows 7 MBR on the USB stick (also works for windows 8), multiple options here:
# ms-sys -7 /dev/sdb- or (e.g. on newer Ubuntu installs)
sudo lilo -M /dev/sdb mbr (info)
- or (if syslinux is installed), you can run
sudo dd if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdb
Mount ISO and USB media:
# mount -o loop win7.iso /mnt/iso
# mount /dev/sdb1 /mnt/usb
Copy over all files:
# cp -r /mnt/iso/* /mnt/usb/ ...or use the standard GUI file-browser of your system
Call sync to make sure all files are written.
Open gparted, select the USB drive, right-click on the file system, then click on "Manage Flags". Check the boot checkbox, then close.
...and you're done.
After all that, you probably want to back up your USB media for further installations and get rid of the ISO file... Just use dd:
# dd if=/dev/sdb of=win7.img
Note, this copies the whole device! — which is usually (much) bigger than the files copied to it. So instead I propose
# dd count=[(size of the ISO file in MB plus some extra MB for boot block) divided by default dd blocksize] if=/dev/sdb of=win7.img
Thus for example with 8 M extra bytes:
# dd count=$(((`stat -c '%s' win7.iso` + 8*1024*1024) / 512)) if=/dev/sdb of=win7.img status=progress
As always, double check the device names very carefully when working with dd.
The method creating a bootable USB presented above works also with Win10 installer iso. I tried it running Ubuntu 16.04 copying Win10_1703_SingleLang_English_x64.iso (size 4,241,291,264 bytes) onto an 8 GB USB-stick — in non-UEFI [non-secure] boot only. After execution dd reports:
8300156+0 records in
8300156+0 records out
4249679872 bytes (4.2 GB, 4.0 GiB) copied, 412.807 s, 10.3 MB/s
Reverse if/of next time you want to put the Windows 7 installer onto USB.
First of all when you get a new device I can recommend writing data to it and verify the data afterwards using md5sum/sha1sum/... Especially cheap USB devices tend to be broken. :( It's not that unusual that USB pens work fine on the first few (hundred) MBs but tend to dataloss on the last MBs. Sadly many users aren't aware of that and notice problems too late: when the USB pen is getting full.
The problem you're speaking of is usually located at the USB chipset (though sometimes it's visible only when using special combinations of hardware). If it works with Windows but fails with Linux using the same hardware this sounds like there's a workaround in the Windows driver that does not exist in the Linux kernel (yet). And whereas Linux uses max_sectors=240 by default (being 120kB) it seems to be 64kB transfers (max_sectors=128) for Windows, according to http://www.linux-usb.org/FAQ.html#i5 (where some problems with the adapters made by Genesys Logic are mentioned as well).
To automatically set the max_sectors: use udev for this task. It allows you to configure max_sectors for just the devices you want to adjust it for.
You can retrieve the necesssary information about your usb device running:
# udevadm info -a -p /sys/class/block/sda/
or for older udev versions:
# udevinfo -a -p /sys/class/block/sda/
Then grab the attributes you'd like to use for your rules and create a new file like 42-fix-max_sectors.rules and place it under /lib/udev/rules.d (when using recent udev versions) or /etc/udev/rules.d (for older udev versions). To get an idea how this configuration file could look like:
SUBSYSTEM=="block", ATTRS{model}=="Voyager Mini ", RUN+="/bin/sh -c '/bin/echo 64 > /sys/block/%k/device/max_sectors'"
Make sure to reload udev after writing your rules file (through running /etc/init.d/udev reload). For testing your configuration file I can recommend using:
# udevadm test /sys/class/block/sda/
PS: I prefer to replace hardware if I notice any problems because usually it's not worth the effort to work on any workarounds (and I'm sure you're aware of murphy who will catch you anyway as soon as you think you've got it working ;)).
Best Answer
to implement group policy you do not need to reboot. Running gpupdate /force (twice) at the client is enough (use psexec for that, for instance).
If you want to revert the policy, just unlink it from the ou and re-run gpupdate /force on the client (again with psexec).
If the computers are not in AD and you cannot implement group policies, you still can get the same results with register imports. Take a look at the adm template you would use in AD and import the register changes with reg.exe and psexec. Another option would be using wpkg (http://wpkg.org) where you have a xml definition of actions for installing/deinstalling stuff. It works great and costs nothing.