Qubes Tools for Windows 3.0.2-1 released

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi all,

The second public build of our Windows Tools for Qubes R3 is now
uploaded to the "unstable" repository. This should still be considered
experimental, so backup your VMs before installing.

The package can be installed by issuing the following command in dom0:

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable
qubes-windows-tools

Then proceed as usual:
https://www.qubes-os.org/doc/WindowsAppVms/#installing-qubes-support-too
ls-in-windows-7-vms

Known issues include:
1) It's recommended to set qrexec timeout for Windows HVMs to at least
120 (2 minutes) because in R3 dom0 doesn't try to reconnect if the
timeout elapses. I have it set to 300 on all my Windows VMs. The main
reason is that during the second reboot after tools installation user
profiles directory is being moved to the VM's private disk. This
operation is performed *before* VM's qrexec agent is started and can
take some time. To set this preference, use qvm-prefs:
qvm-prefs -s vmname qrexec_timeout 300

2) It's recommended to set the VM to automatically log on a user on
start (Win+R -> netplwiz -> uncheck "users must enter user name and
password...", provide credentials). This is due to changes on dom0
side causing that VM's gui daemon is only started after a user is
logged on in the VM. This will be fixed in the next release. If you
can't use autologon, you can manually start the VM's gui daemon in dom0:
/usr/bin/qubes-guid -d `xl domid vmname` -N vmname -Q
If you start the Windows VM using qvm-start from console you will see
when it's waiting for VM user logon.

3) Xen disk pvdrivers are disabled by default. This is because they
seemed to cause random, frequent BSODs during my testing. If you feel
adventurous you can enable them during installation by choosing
"custom" installation. Be warned, this will probably make your VM
unusable (but I welcome reports, maybe my hardware is faulty). I'm
working with the Xen folks to fix this issue. Unfortunately, this
means that *qvm-block will not work for Windows VMs*. If you need to
transfer files, use network or inter-VM file copying by qrexec.

4) Currently dom0 fully synchronizes VM's appmenus on every start.
This means that for a while after VM's start its menu in dom0 may be
unavailable or changing. This will be improved in the future.

If you're migrating from R2, here are instructions on how to uninstall
the old (R2) Windows Tools:
https://github.com/QubesOS/qubes-doc/blob/master/UninstallingWindowsTool
s2.md

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJVx6qXAAoJEIWi9rB2GrW7rxQH/jtRGEP2D9oBgYEOMA/SA7+7
JdLJCcG0tdEyYmbtdKyL7Tis+Drjzh7UUf6es8LMqw080dNqU9GpFbjj2ZiSnP3n
HrCOJh/0UIWJSJzDN/NBKidtLl7nicLb4fjHF+QWLvpmVIz+nKi53EJhVn3Xnaxt
/9TbDouVW6bhjAFhRBnP+rzJ2V5QN3ls8RUp8+QFJUn05Et7jo80Dfzo3atPSX3j
DmqB2n6aG0gIKsnRqw5teoEyrX0Q//NyWq8gFvzaypfaYOqQTB/us2uxUKW/NFtC
mPY/xLMyYUo6bmljf3eVlciwUhN6t7KWAnwrtCxQq6rBctxTtYdpEGg/iX00bSw=
=Gcud
-----END PGP SIGNATURE-----

[Vít Šesták]

I've updated form the precious publicly available unstable version.

I've encountered many BSODs, so I looked at the HDD's driver. IT seemed to be the PV driver, so I uninstalled it and rebooted the computer. No BSOD so far, but Windows seems to install the PV driver automatically and want to a reboot :( Is there any way to prevent it?

Regards,
Vít Šesták 'v6ak'

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/10/2015 06:31 PM, Vít Šesták wrote:
> I've updated form the precious publicly available unstable
> version.
>
> I've encountered many BSODs, so I looked at the HDD's driver. IT
> seemed to be the PV driver, so I uninstalled it and rebooted the
> computer. No BSOD so far, but Windows seems to install the PV
> driver automatically and want to a reboot :( Is there any way to
> prevent it?
>
> Regards, Vít Šesták 'v6ak'
>

Try rebooting in safe mode and manually delete old xendisk.sys and
xenvbd.sys from windows32\drivers.

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJVyOKDAAoJEIWi9rB2GrW7sqcH/2akxkunnSlM7TcUsNEf+XhA
vl9DeOWty9/HPOjd0ZrI+nSWBZ8aVzGALH1jCRMGxu5K088BTvwR8uMsUyUvxEpf
j4x/YacoJ7qO9EaqKGQBZi8nLgMffOsaalqwCKc6D7RyYXXDYszKDiJAEEerg63z
Lf2Yo4dAW/Rp808UNXTx246sXwcd6CFFksQzS62HBmI4VV+xH3ULMO+ZxzQjTdCl
/IkaJeCUMinw/sHcvGdqaDMBXccCP/hOVe4XzGv5c8wkXVcM6ycRCFLIUvdhiIiF
wWzGSUtOSGuJndLk1m2ss6f1FQGxjFdixxF3Pa0HU7G8TpHaBdAvIHWVEGeQ5bE=
=XPii
-----END PGP SIGNATURE-----

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/10/2015 07:42 PM, Rafał Wojdyła wrote:
> On 08/10/2015 06:31 PM, Vít Šesták wrote:
>> I've updated form the precious publicly available unstable
>> version.
>
>> I've encountered many BSODs, so I looked at the HDD's driver. IT
>> seemed to be the PV driver, so I uninstalled it and rebooted the
>> computer. No BSOD so far, but Windows seems to install the PV
>> driver automatically and want to a reboot :( Is there any way to
>> prevent it?
>
>> Regards, Vít Šesták 'v6ak'
>
> Try rebooting in safe mode and manually delete old xendisk.sys and
> xenvbd.sys from windows32\drivers.
>

Should be Windows\system32\drivers.

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJVyOLOAAoJEIWi9rB2GrW7s+IH/A2sLFzNlQGIOGBb9OhPRpc2
CtzzoTH1rjN7FU1j4eOvlolvAKN/HYqvpWvKrsG8wK2vZi95w31G1D8KbCn7XbXO
+DMEU+C1Byn2+aZkTMz+uVFNlSa9UIJ8/LwqECqpo1GfFQ6z/hiKZK+MJOnFA7fF
8IWZGMvo+SEMArTIg4P8GifohRxXD4i5AojI7xktRt9r7ODeVNbtCN5y2oEJJdvw
1MQvWFjqA5/bqAGJ4Q7RXkznPx9ATh2SVW1yduL/iw3eBdRWX10V89bApLbT0xTP
e/60H80i32Nma1kYS2uE0dgA/+CSfnwr4sH5T/wLyrLpIZjDJzIjqVNSgHx5F7k=
=vAW+
-----END PGP SIGNATURE-----

[Vít Šesták]

Thank you. Removing those two files seems to have solved the BSODs. (I've done it without safe mode. The drivers were promised to be used after restart, so I suppose this to be safe in such situation.)

One issue I haven't mentioned. I have a StandaloneVM, so I don't care about it much. But it is somehow suboptimal…
During some installation phase, it tried to copy c:\users to d:\users. But it froze. It took many time without any HDD activity and without any indication of system liveness (although my profile is probably not that huge). So I killed the VM and started again. The script run again, but it had skipped moving c:\users, as d:\users had already existed. So my user profile is on c:.

Regards,
Vít Šesták 'v6ak'

[raf...@elitemail.org]

On 08/10/2015 11:20 AM, Vít Šesták wrote:
> Thank you. Removing those two files seems to have solved the BSODs. (I've done it without safe mode. The drivers were promised to be used after restart, so I suppose this to be safe in such situation.) > > One issue I haven't mentioned. I have a StandaloneVM, so I don't
care about it much. But it is somehow suboptimal… > During some
installation phase, it tried to copy c:\users to d:\users. But it froze.
It took many time without any HDD activity and without any indication of
system liveness (although my profile is probably not that huge). So I
killed the VM and started again. The script run again, but it had
skipped moving c:\users, as d:\users had already existed. So my user
profile is on c:. > > Regards, > Vít Šesták 'v6ak' >

Did you set the qrexec_timeout first? I just installed the latest QWT
in to a standaloneVM and had no issues (with qrexec_timeout=300).


(from the original message):

[Vít Šesták]

Yes, I did.

Even if I didn't, I saw the boot screen (because I was running it in non-seamless and debug mode) and no HDD activity.

I am not sure if the freeze is related to QWT. But I'd like to suggest that QWT recover from such situation better. Maybe something like that (pseudocode):
if not exists d:\Users (
    rmdir /s d:\Users.working
    copy c:\Users d:\Users.working
    ren d:\Users.working Users
    rmdir /s c:\Users
)
if not exists c:\Users (
    symlink d:\Users c:\Users
)

I am not sure about detailed Windows FS semantics (reordering), so there might be something wrong with such code (the code might require manual sync in order to be correct), but I hope the idea is clear. If there is no reordering issue, it should recover from such crash (or power outage or so…) correctly.

The code is pseudocode that reminds batch files. I don't remember all the details about batch files. (OK, there should be “xcopy” with some switch (maybe /E) instead of just “copy”. Well, rmdir maybe requires /Q instead of /s, not sure. And I don't remember how can one create a symlink on Windows.) It is some time ago I was regularly using Windows shell and writing batch files.

Regards,
Vít Šesták 'v6ak'

[Vít Šesták]

It seems to be somehow more stable and fluent than the previous release. Network works without reconfiguring.

Issues I've encountered:
* Both receiving and sending files seem to work. However, when the VM receives a file (or a directory), the sending VM shows e.g. “sent 0/215 KB”, even if all the files are transferred.
* Seamless mode does not work for me. The VM starts and exits after some time, but I've no idea what happens in the meantime.
* I sometimes get messages like this one:
The Dom0 GUI daemon do not support protocol version 2057:60528, requested by the VM '×××××××'.
To update Dom0, use 'qubes-dom0-update' command or do it via qubes-manager

Regards,
Vít Šesták 'v6ak'

[Manuel Amador (Rudd-O)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/09/2015 12:31 PM, Rafał Wojdyła wrote:
> > Hi all, > > The second public build of our Windows Tools for Qubes R3
is now > uploaded to the "unstable" repository. This should still be
considered > experimental, so backup your VMs before installing.

Forgive me for asking something that may have already been asked, but is
there a guide to slipstream the Windows Tools into a Windows installer
or somesuch?

Sorry if the question has been asked before.

- --
Rudd-O
http://rudd-o.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVzuPQAAoJEFmZwbV7vYQ22LAP/04DqM1Pw9644+sceUYTVmkJ
3nuT82z5VB/moyqsWGML82CMoJPYM5DLodZzNiCXX7IoLze5Mv1zbBcRZ22rbEjh
ptwvo1ImdxQHDFE4FfuMgLoN0AFHOETzcZi865PjfuGziwYit6QCxRoJQ5Y3UAeZ
RWCHYb5esHbv67OxzstRGJw3eFPmLyMYysucd+xTBR9dUiAll9aL1UMXfV+MUDdW
rDWh6ke8h6SEAix7hBHMt446ZcsJ3g6RTSW18Iyae0qJ496DJ+hN+A/cEmxMRp7o
apcMHV4AL8YdzmtKXfgKC8H9KcVLjRQ6ub3YCX5x36lZE3I3CxiLNY6GfEOuMM0s
hi14fDDu7T9USxIPA97OYU9q/bTi+1HJA95BpyISrSpfJkS5P5/S+7zZejET6K+O
iSBMDxsT37/MBWIxRtBX27ksHMWIvopVP5M6TSsYhL4Cr4BDMYDjGmpy2rOrztdw
Ixt3gyF/0r27wmgk5N6aRW5WE0Qec9oz8mOEk4Vspye5pEb0yC6II/q6X18f/i28
T+MS9scO1BO9tqXwObiLhpr8ZT1UbUFwvozw9JJgq38duVydjyLozJPEpw3yhyTW
3UGyCQhMfOT6FxIdaxmy8d4YCGNYCquKBLmwTk5H6MvWq62HKZRjjojg7G++tcjy
JEDwXdpIHHnpLC/GgkNV
=CR/b
-----END PGP SIGNATURE-----

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-08-15 09:01, Manuel Amador (Rudd-O) wrote:
>
> On 08/09/2015 12:31 PM, Rafał Wojdyła wrote:
>>> Hi all, > > The second public build of our Windows Tools for
>>> Qubes R3
> is now > uploaded to the "unstable" repository. This should still
> be considered > experimental, so backup your VMs before
> installing.
>
> Forgive me for asking something that may have already been asked,
> but is there a guide to slipstream the Windows Tools into a Windows
> installer or somesuch?
>
> Sorry if the question has been asked before.
>

I'm not sure what you mean - are you asking for a way to create a
custom installer that includes our Windows Tools?

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJVzxuPAAoJEIWi9rB2GrW7KAEH/iD9dT7ozK1uBo7/o7mXe0V2
JmyLZp8ICS7UI7zFOunlGnh3nej4Y94GLoLxmOsDUOb1vTYrfjiNKKHKOqvKhRSI
tGOeMmmPDC6xGLeh9OHif4PEmvmz8Yn/4IkOR7aPb21VZ+8DHJ0uQe8ozN2YR/i4
/Hqi33QgubKIkY+Y+NIcb2wM4xYwIBGTyGWN6TmQiY4tUK5ZVeqc91GiLXK88Hxo
0X1It6wlrJkoqao9rORZuGJzfruow4SPNtmP27aebIv5LCJbccjfOejMp9rxtw3+
UR5gHK5pTn0U60GDn2F3lBWS8FCD1v8VrM9oxU5HC8gt0eUDGi/w0HYJOfeeqjk=
=6gko
-----END PGP SIGNATURE-----

[Jason M]

I finally got around to converting my Qubes Release 2 'Windows VM' to Release 3.  I think I followed your instructions exactly but they first few times I ended up with BSOD on reboot, even with safe-boot.  [Make sure to clone a copy of it first; first time I did not and had to restore from backup :)]

There were were a few hiccups with the provided uninstall script.  First off, I did not run it with 'Administrative Privileges' so maybe that why I had an issue. 

The first issue was getting the script on the Windows VM.  No real instructions on how to do that.  Also the script provided on web site is not formatted properly.  I was able to 'view source' of the web page then edit out HTML tags and convert the double and single quotes to normal ASCII quotes at which point I put it on a web site so I could download it with explorer.  I would suggest the script to be placed on github so users can enable safe mode with networking and then grab it.

I broke the script up into 8 smaller scripts to run each section at a time, and manually fixed where the script did not work. 

I had to run regedit and manually delete these keys:

reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E96A-E325-11CE-BFC1-08002BE10318} /v UpperFilters /f
reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318} /v UpperFilters /f
reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E97B-E325-11CE-BFC1-08002BE10318} /v UpperFilters /f

The following file would not delete since I had not permission to delete.  I therefore changed directory and owner permissions and deleted the file, then changed permissions back.  Maybe if I ran command prompt as 'Administrator' this would not have happened?

del /q /s "%windir%\system32\qvgdi.dll"

Finally the script missed a oem.inf{pnf} pair in the /wiindows/inf directory.  I manually opened all the oem.* files looking for Qubes or Xen and deleted them.  This could be since the last time I used the R2 image was last year since I upgraded to R3 in about January, 2015.

Everything seems fine so far except I have no sound.  Is this expected?  I did not install Xen PV drivers as recommended.

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<https://github.com/QubesOS/qubes-doc/blob/master/UninstallingWindowsToo
l>
>
> s2.md <http://s2.md>
>
>
> I finally got around to converting my /Qubes Release 2/ '/Windows
> VM'/ to /Release 3/. I think I followed your instructions exactly

> but they first few times I ended up with BSOD on reboot, even with
> safe-boot. [Make sure to clone a copy of it first; first time I did
> not and had to restore from backup :)]
>
> There were were a few hiccups with the provided uninstall script.

> First off, I did not run it with '/Administrative Privileges/' so

> maybe that why I had an issue.
>

Exactly, it needs to be run with admin privileges, I somehow forgot to
mention this.

> The first issue was getting the script on the /Windows VM/. No

> real instructions on how to do that.

True... It should probably be on the tools .iso image.

> Also the script provided on web site is not formatted properly. I

> was able to '/view source/' of the web page then edit out HTML tags

> and convert the double and single quotes to normal ASCII quotes at
> which point I put it on a web site so I could download it with

> explorer. I would suggest the script to be placed on /github/ so

> users can enable safe mode with networking and then grab it.
>

Strange, apparently the website parser doesn't accept the standard
markdown for preformatted text. I'll fix it.

> I broke the script up into 8 smaller scripts to run each section at
> a time, and manually fixed where the script did not work.
>
> I had to run regedit and manually delete these keys: reg delete
> HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E96A-E325-11CE-BFC1-08
002BE10318}
>
>
/v UpperFilters /f
> reg delete
> HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08
002bE10318}
>
>
/v UpperFilters /f
> reg delete

> HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E97B-E325-11CE-BFC1-08

002BE10318}
>
>
/v UpperFilters /f
>
> The following file would not delete since I had not permission to
> delete. I therefore changed directory and owner permissions and
> deleted the file, then changed permissions back. Maybe if I ran

> command prompt as '/Administrator/' this would not have happened?

> del /q /s "%windir%\system32\qvgdi.dll"
>
> Finally the script missed a oem.inf{pnf} pair in the/wiindows/inf
> directory. I manually opened all the oem.* files looking for

> /Qubes/ or /Xen/ and deleted them. This could be since the last
> time I used the /R2/ image was last year since I upgraded to /R3/

> in about January, 2015.
>
> Everything seems fine so far except I have no sound. Is this

> expected? I did not install /Xen PV drivers/ as recommended.
>
Yes, we don't have sound virtualization for Windows yet, but it's
planned for the future.

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJV0O7yAAoJEIWi9rB2GrW792EIALQ9s/u5Fwcxec6UISH0Blcz
oFjm+HaKqravHAo/q1LLqa4ZtAbvPNGDI47d7prMz+vhQrBhuE6SaNrdhFOrEzzF
bR+LMYX41u61fErDd92TwyxMBIwOwRMGbxkCVYN1lDzjrQNReDdFy7tKEnISHXZ2
08uvcQFQPTJQInlSwDnrDBwrQYxloF6bz0igJx9CXEKChvj9gpp8GDRJDNuTpayX
DACAmHns40z0Mvz6r2A6W99Ftavqw2zUHpZ/iotL/2kM66msz9vrWAdgJdGi/VFS
1kVjt+O3jD669IQiuVfgf7Vv/lMerY6SFA9+OtFBrhF7L/8flgFm4IcIEdixOQI=
=jcEz
-----END PGP SIGNATURE-----

[Jason M]

@omeg

One other thing I noticed was that when Windows 7 is booted and the `desktop` is in focus the complete bottom toolbar does not respond to click events.  The top 5-10% of the toolbar does respond to click events on items in toolbar such as the `Start` menu while the bottom 90%ish does not respond to any click events which means I have to take care to click the top of any toolbar icon to launch, or increase toolbar since when I want to access time.

The interesting fact is that the area that does not respond to click events is the same size as my KDE toolbar that is located at the bottom on the screen, which also auto-hides.

Do you want me to create an issue of this or is it expected behaviour?

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, Id's say that's a bug.

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJV1iEHAAoJEIWi9rB2GrW7ZhwH/3BjQtMMCKx2KuAM4ErJEuo4
QXSIyKz4wW+9HS+33kM82yDqUQ/x1INRa4g2otwiOVFzhuotPaur7ABJ1UQ7CDl8
LBlS4MQVnCiBSMrt5JiSL0Y+pBa+qHBeYF3XqJ2zk4+ZCLlU2WwwKEq0C8iTEbGa
fWhNYSDR/lxcKuLipyyYPwvNDCp5OtLuA4g3flSLEg0a5yu+FWiDkrfj+EBYRlYo
onu4iN5JLKRFY8oDiTS7JGhMlN3KboqjrMEW2oqw8x2pryTHV0n9I4aGn37ILa+K
iyySRLFL8ZFKUYm+G5kogp8oV6bXB4+vOX9Dwm4V1Cna1L/VYOdoIy6RtnJ0cB4=
=d0V4
-----END PGP SIGNATURE-----

[cprise]

After following the instructions here and at the doc/WindowsAppVms page,
I had a problem with the network access. Network/sharing center reported
'Unidentified network' and 'No network access' when using the Xen PV
NIC. After 2 or 3 more reboots network access was restored.

Also, Device Manager says there is a 'XS0001 XENBUS VBD' without a
driver, but I suppose that is intentional (this is the problematic block
device you mentioned?).

[Manuel Amador (Rudd-O)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/15/2015 03:59 AM, Rafał Wojdyła wrote:
> On 2015-08-15 09:01, Manuel Amador (Rudd-O) wrote: > > > On 08/09/2015 12:31 PM, Rafał Wojdyła wrote: > >>> Hi all, > >
The second public build of our Windows Tools for > >>> Qubes R3 > > is
now > uploaded to the "unstable" repository. This should still > > be
considered > experimental, so backup your VMs before > > installing. > >
> Forgive me for asking something that may have already been asked, > >
but is there a guide to slipstream the Windows Tools into a Windows > >
installer or somesuch? > > > Sorry if the question has been asked
before. > > I'm not sure what you mean - are you asking for a way to
create a > custom installer that includes our Windows Tools? > >

Yes.

- --
Rudd-O
http://rudd-o.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV2mCQAAoJEFmZwbV7vYQ2BqwQAIrI46icT7Zd0QilVJi2INKc
xLJV9VB9kiNYj8XLbL5O/IZXGrqlVtRtq9yB6NTbnMAIWRo42INcp9DBfz5R1kbI
Kz2D77r5+iPXlY5rohujf6qClncKVfMke1KzZsW+hYiUNm5E/aIf5v9GmlsKYmhT
EG+zyxF8ADMbq1BUTDI89Kmuf9aygCbFpt9dh6rerHFFEMqkNia/l7VY5FiZKp7j
5qWVWG+r6XKUgL/XgtFGgKGu6mHujPdhhGWONeP8ApLLQJg7SuQ7580/Gq64g5hH
cs146+hNSNrzew2byhiFIHGQNVZaAJxsjsPL9lwt88df9qqKWlHhlI+Nosx9QGsu
J38AwGRf7jEoYARNlcWAWT9V856mgg3jaconYEW+fLTWkB2TR8u13cnLSpYHI1dy
katSPZtVO4O99gpNs1wE/NFAPMk0jtqS4csjos4DGpM+U1H5unGY8BlbZ/zRZKBe
cHfg0t1MAS1tvbXz//4gGGciQ/N0vcXlYNKC228RR12V+Bzf+V3pf8CBeHNjoI4N
xKELxiBlvegSM6f3WZo2WLGhBZNJIrA8D2BqvGGeQkVk7WBFEs0d81RPDJsVgzLs
d+zfiaVNWo56PuxS/iOTeJTOlvwHbN04GQHF+ODHgbIXuQEphXsw2r0m8yDuvOsX
o8yR/UZ3y06NfO2psFfn
=raMr
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I'm not sure about removing original c:\Users - AFAIR it should be left
there for initializing d: of additional VMs. But the idea about
intermediate directory looks good. Rafał, what do you think?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV3SlgAAoJENuP0xzK19csRoQH/A/IK+ekOEp/tUXc7+4l+4db
YJ3IC3EjWzsh1RuMqMrjMkbZGFwly0bXYyjRYQ92u+PpkX/lrob19iMBTw74lFVO
57hC52XQLTfHLVBgvq+INYtPmVbiNjb/r2xE2u8nIp9/y0y/aVt359ZoWNhTcK+U
J+Cw5ptzuZEpKCd5l5ivBpfaW+FI0QlptWFdqaYO9HVLc495DCc6SNfQ+MGCXFSS
ZlZ6U4VeSfzt+rv8u35Z0arM0snd7inPruK68u8AZfnvfAChaPwwlXJR3Mb7Ps4F
Lka09C2GMIiQ5ITpTOeaip9J8MHBUhARNRF1PnbuNf8Qud5+Vdr75akUP+cDJsc=
=f+Pu
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Aug 12, 2015 at 11:09:51AM -0700, Vít Šesták wrote:
> It seems to be somehow more stable and fluent than the previous release.
> Network works without reconfiguring.
>
> Issues I've encountered:
> * Both receiving and sending files seem to work. However, when the VM
> receives a file (or a directory), the sending VM shows e.g. “sent 0/215
> KB”, even if all the files are transferred.
> * Seamless mode does not work for me. The VM starts and exits after some
> time, but I've no idea what happens in the meantime.
> * I sometimes get messages like this one:
> The Dom0 GUI daemon do not support protocol version 2057:60528, requested
> by the VM '×××××××'.
> To update Dom0, use 'qubes-dom0-update' command or do it via qubes-manager

Looks like windows gui agent send some garbage instead of proper hello
message... Rafał, did you encounter this problem before?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV3SuIAAoJENuP0xzK19csY1cIAJGcn/h36ZxiTiiNwjwyKthD
mw8ZyXJY9dDAgC7Cj9vlvC5yYNhode2pbtZEHs6eHaMdh6ZITX++n8m++DPpCWtB
BAztWR0RmeNe9Oy48y4IjNrl133Y5VohteOpdYV/mHYjvryZKI1BuHfcnwIVeLdX
bVmEuWI4QzLb1b86FOukiAcuxvZtK998wqFu0y9Ctcn4aTjdX2GsQIOT7d0JfVeO
toOjay/k+8ALaHYBX8B1hUGYi0EcEivF9XcFF9F1YZObUXXwpPm/V+qvQaUOrfQe
5USWZ9DicMMOMqA/RrFcnvCrdkTMmlZnaE9RPkBuV69N9D8TC4aqg0lxMxhTQHM=
=+TWr
-----END PGP SIGNATURE-----

[Alex]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/26/2015 04:50 AM, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 10, 2015 at 02:40:18PM -0700, Vít Šesták wrote:

>> [...] if not exists d:\Users ( rmdir /s d:\Users.working copy

>> c:\Users d:\Users.working ren d:\Users.working Users rmdir /s
>> c:\Users ) if not exists c:\Users ( symlink d:\Users c:\Users )
>

> I'm not sure about removing original c:\Users - AFAIR it should be
> left there for initializing d: of additional VMs. But the idea
> about intermediate directory looks good. Rafał, what do you think?

Sorry if I hijack your question to Rafał, but I think symlinking the
users directory is not probably the best way to proceed.

And if you wanted to keep the logical overlay structure from the linux
AppVMs to windows ones, you'll have to move also C:\ProgramData, which
is something like /usr/local in Fedora.

You may consider checking
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS
NT\CurrentVersion\ProfileList which is the actual "recommended" way of
changing the location of the Users directory and ProgramData; a sample
article can be found at
http://www.nextofwindows.com/how-to-change-user-profile-default-location
- -in-windows-7/
but AFAIK (direct experience) the procedure goes something like this:
- - create a throwaway administrator user
- - log in as that user (needed because logged users have locked files
in their home)
- - copy everything from C:\Users into D:\Users, skipping files from the
throwaway user folder
- - copy everything from C:\ProgramData into D:\ProgramData, signaling
locked files to the users -> they must be taken care of manually, e.g.
skipping windows files (they'll be likely re-created) or program files
(they could just be plain lock files)
- - set the registry keys accordingly (all four of them,
ProfileDirectory=D:\Users, ProgramData=D:\ProgramData,
Public=D:\Users\Public, Default=D:\Users\Default)
- - reboot
- - log in as one of the existing administrator accounts (not the throwawa
y)
- - remove the throwaway profile

This way you'll have a situation similar to that of the others AppVMs,
but please note it takes a great amount of work and I don't know if it
can be automated after the setup.

During the setup phase of windows one may pass an Unattended Answers
file, which - as far as I remember, at least with Windows 2000 it
could - can set a different location for ProgramData and user profiles
directory. Doing this at the setup phase is the easiest way to
proceed, everything will be set up by the Windows setup itself, and
any location in the user home or ProgramData that may have been
written somewhere else will just be correct, because there will never
have been directories in the wrong place.

My memories of unattended installations are faint; you may want to
start checking from
https://technet.microsoft.com/en-us/library/cc786944%28v=ws.10%29.aspx
or https://technet.microsoft.com/en-us/library/cc732280%28v=ws.10%29.asp
x

- --
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV3WbKAAoJENNOJZnNP8uDhTMP/jrQNcQrotS7ETSV/TTucWgb
RiAW8rv0NPS7K9Qe8hMQwbZ+7CvmKQvm+NK57g5EiArzcYOjxTr76EYo+5Xih7gY
cB6S9kWNEqsa4XRxQpIgEmVG0QN6YAxCgE+cB7+pQO3xx7AeoRRmNNZbrdZThus/
bomTZH7AtY61hZAsgoSatmW1c6L6ZNaOPpZCgNfXIs8+w0QUDOodHW5oRn2TR9QU
Ajr0lKnCVKFJ1RdbbEww6Eh6l+/bQ3dVHpYE/8ciRxF/T7xdKb0aOXihQgrJnLRZ
GsmQzGghr+zjFqrd4UE/5Qnbl2KwioFXxzWdORynUKZE0C1sbxK8sB0NeNdfjGat
WA7V1ZXcybcHiRHJlaqF3NpHoaATq6ejyr/WCKwWFNylgG3K3oXiKV05+hI1VkiD
3okOlS1NrQAvnHTUsDjy6YfIytNQasgvNP08dGf1D1Y+od/9avVu0rkvig/OgZJ6
DihDwhnuZyzHAYCYqK/fZR3FDm8lxmBeD51uSLp5CVw8xu6nE8XxrO9CxmqxC/q8
y4wIt/LABDCz12siYLjekuAfYu0+wU+U76j0h8TuGL5A4SduWRd/82ikG9+4L2SY
7sKRGTZCdXQIfxBDc3VgKxdBpLG36SNn19tbzpDEM9mKnIyZdVl4umIsDFtkwyKG
6KfCceyMn7fa+N2M0Lxk
=kRfB
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Aug 26, 2015 at 09:12:10AM +0200, Alex wrote:
> On 08/26/2015 04:50 AM, Marek Marczykowski-Górecki wrote:
> > On Mon, Aug 10, 2015 at 02:40:18PM -0700, Vít Šesták wrote:
> >> [...] if not exists d:\Users ( rmdir /s d:\Users.working copy
> >> c:\Users d:\Users.working ren d:\Users.working Users rmdir /s
> >> c:\Users ) if not exists c:\Users ( symlink d:\Users c:\Users )
> >
> > I'm not sure about removing original c:\Users - AFAIR it should be
> > left there for initializing d: of additional VMs. But the idea
> > about intermediate directory looks good. Rafał, what do you think?
> Sorry if I hijack your question to Rafał, but I think symlinking the
> users directory is not probably the best way to proceed.
>
> And if you wanted to keep the logical overlay structure from the linux
> AppVMs to windows ones, you'll have to move also C:\ProgramData, which
> is something like /usr/local in Fedora.
>
> You may consider checking
> HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS
> NT\CurrentVersion\ProfileList which is the actual "recommended" way of
> changing the location of the Users directory and ProgramData; a sample
> article can be found at
> http://www.nextofwindows.com/how-to-change-user-profile-default-location

> -in-windows-7/
> but AFAIK (direct experience) the procedure goes something like this:
> - create a throwaway administrator user
> - log in as that user (needed because logged users have locked files
> in their home)
> - copy everything from C:\Users into D:\Users, skipping files from the
> throwaway user folder
> - copy everything from C:\ProgramData into D:\ProgramData, signaling
> locked files to the users -> they must be taken care of manually, e.g.
> skipping windows files (they'll be likely re-created) or program files
> (they could just be plain lock files)
> - set the registry keys accordingly (all four of them,
> ProfileDirectory=D:\Users, ProgramData=D:\ProgramData,
> Public=D:\Users\Public, Default=D:\Users\Default)

> - reboot

> - log in as one of the existing administrator accounts (not the throwawa
> y)
> - remove the throwaway profile
>
> This way you'll have a situation similar to that of the others AppVMs,
> but please note it takes a great amount of work and I don't know if it
> can be automated after the setup.

I think there was some problems with this approach, but don't remember
what. Especially about having ProgramData on per-VM drive - which means
that changes made there in the template would not be propagated to the
VMs. Rafał?

Anyway the current implementation doesn't use symlinks, but rather
reparse points (IIUC something similar to "mount --bind").

> During the setup phase of windows one may pass an Unattended Answers
> file, which - as far as I remember, at least with Windows 2000 it
> could - can set a different location for ProgramData and user profiles
> directory. Doing this at the setup phase is the easiest way to
> proceed, everything will be set up by the Windows setup itself, and
> any location in the user home or ProgramData that may have been
> written somewhere else will just be correct, because there will never
> have been directories in the wrong place.
>
> My memories of unattended installations are faint; you may want to
> start checking from
> https://technet.microsoft.com/en-us/library/cc786944%28v=ws.10%29.aspx
> or https://technet.microsoft.com/en-us/library/cc732280%28v=ws.10%29.asp
> x
>

- --

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV3YIkAAoJENuP0xzK19csRrEH/i9W8obMZNRCu9YZTiC5hb3S
Ch8iVaFUD1F4yhyjoQcIZlM23NsCne3cuRMEpRCjv9huk9H+Qxyiryjoabo8VfO/
NmzQinMQcWr7iMt3j6sGJtLLVTWaKcfimUg2pmCKNB3smM0RI+nTsz8Jb/CwkUzr
m1/E0j3Y8brR1Olr37V8G7Whkj3aS/QMg6kawTI8xgsK7BHUYhy5pyNhvYXSemsv
YXdybC9kc/pnF70S0R4WGFAoaiuhvtr3c5DKzsgA+yfYV1D4kkwIB+BoQxaXec3P
lrPlqToiDi9bu6q40tE8QS4vpSGAC6LLlJ6CcwqHCC/LRLGpRMwEnJc/vJogRfs=
=Z+Ib
-----END PGP SIGNATURE-----

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-08-26 04:59, Marek Marczykowski-Górecki wrote:
> On Wed, Aug 12, 2015 at 11:09:51AM -0700, Vít Šesták wrote:
>> It seems to be somehow more stable and fluent than the previous
>> release. Network works without reconfiguring.
>
>> Issues I've encountered: * Both receiving and sending files seem
>> to work. However, when the VM receives a file (or a directory),
>> the sending VM shows e.g. “sent 0/215 KB”, even if all the files
>> are transferred. * Seamless mode does not work for me. The VM
>> starts and exits after some time, but I've no idea what happens
>> in the meantime. * I sometimes get messages like this one: The
>> Dom0 GUI daemon do not support protocol version 2057:60528,
>> requested by the VM '×××××××'. To update Dom0, use
>> 'qubes-dom0-update' command or do it via qubes-manager
>
> Looks like windows gui agent send some garbage instead of proper
> hello message... Rafał, did you encounter this problem before?
>

Haven't seen that in a while... Remember to post relevant Windows
Tools logs when possible [1], in this case qga*.log and QgaWatchdog*.log
.

[1] http://www.qubes-os.org/doc/WindowsTools3/

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJV3abtAAoJEIWi9rB2GrW7TNMIAIcHm5gMIMC1ay23au+pWB2X
8uNtSSbZ6+ToSMCEvX7dKtSVHM1uH3sd4zOcP7dMHDQzKlH3mc9dQ9EZJ98DhaoW
3tvU86f7pDYVPRjCyRysNsnEH5CZxeTMl7FuA36vLfZrVwBdiDTXSKk+vlijtm0N
ryDjLKaCG5Ar+hJppILuMcCH9gfOZtD4yYKbWQj6jmDr/bb2lyVYGjVTaSHu5YLa
/X1pFI13qMNfwnJ54PN4HqEDclIPQR1vvZB6vFVH38hNLKwENqNMH/jG6dCE3NKp
gw5+SKAlohTUE/eg7b3IzgHDXhLRJQTy8SQGK5JJLzkYeyx6t4cRGrpSbXykcrI=
=B66I
-----END PGP SIGNATURE-----

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-08-26 11:08, Marek Marczykowski-Górecki wrote:
> On Wed, Aug 26, 2015 at 09:12:10AM +0200, Alex wrote:
>> On 08/26/2015 04:50 AM, Marek Marczykowski-Górecki wrote:
>>> On Mon, Aug 10, 2015 at 02:40:18PM -0700, Vít Šesták wrote:
>>>> [...] if not exists d:\Users ( rmdir /s d:\Users.working
>>>> copy c:\Users d:\Users.working ren d:\Users.working Users
>>>> rmdir /s c:\Users ) if not exists c:\Users ( symlink d:\Users
>>>> c:\Users )
>>>
>>> I'm not sure about removing original c:\Users - AFAIR it should
>>> be left there for initializing d: of additional VMs. But the
>>> idea about intermediate directory looks good. Rafał, what do
>>> you think?

The current algorithm is roughly this:
1) If c:\Users is a directory junction, abort.
2) If d:\Users exists, abort.
3) Copy c:\Users to d:\Users. If anything fails along the way, abort
(the incomplete target directory is left as-is, it should probably be
deleted).
4) Delete everything in c:\Users because a reparse point source must
be an empty directory. At this point we're sure that d:\Users is a
complete mirror of the original directory. If anything fails during
the deletion, try to copy d:\Users back to c:\Users ignoring all errors.
5) Make c:\Users a reparse point pointing to d:\Users.

Note that this process runs in the early boot phase as SYSTEM, before
the OS opens any other files (same stage as the filesystem checker).
Permissions or locked files are not a problem.

We could probably replace 4) and 5) by updating the registry
(ProfileList key).

>> Sorry if I hijack your question to Rafał, but I think symlinking
>> the users directory is not probably the best way to proceed.
>
>> And if you wanted to keep the logical overlay structure from the
>> linux AppVMs to windows ones, you'll have to move also
>> C:\ProgramData, which is something like /usr/local in Fedora.
>
>> You may consider checking
>> HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS
>> NT\CurrentVersion\ProfileList which is the actual "recommended"
>> way of changing the location of the Users directory and
>> ProgramData; a sample article can be found at
>> http://www.nextofwindows.com/how-to-change-user-profile-default-locat
ion
>>
>>

- -in-windows-7/

>> but AFAIK (direct experience) the procedure goes something like
>> this: - create a throwaway administrator user - log in as that
>> user (needed because logged users have locked files in their
>> home) - copy everything from C:\Users into D:\Users, skipping
>> files from the throwaway user folder - copy everything from
>> C:\ProgramData into D:\ProgramData, signaling locked files to the
>> users -> they must be taken care of manually, e.g. skipping
>> windows files (they'll be likely re-created) or program files
>> (they could just be plain lock files) - set the registry keys
>> accordingly (all four of them, ProfileDirectory=D:\Users,
>> ProgramData=D:\ProgramData, Public=D:\Users\Public,
>> Default=D:\Users\Default) - reboot - log in as one of the
>> existing administrator accounts (not the throwawa y) - remove the
>> throwaway profile
>
>> This way you'll have a situation similar to that of the others
>> AppVMs, but please note it takes a great amount of work and I
>> don't know if it can be automated after the setup.
>
> I think there was some problems with this approach, but don't
> remember what. Especially about having ProgramData on per-VM drive
> - which means that changes made there in the template would not be
> propagated to the VMs. Rafał?
>

Right. ProgramData contains *global* application settings that are not
user-specific. By default c:\Users\All Users is a link to c:\ProgramData
.

> Anyway the current implementation doesn't use symlinks, but rather
> reparse points (IIUC something similar to "mount --bind").
>
>> During the setup phase of windows one may pass an Unattended
>> Answers file, which - as far as I remember, at least with Windows
>> 2000 it could - can set a different location for ProgramData and
>> user profiles directory. Doing this at the setup phase is the
>> easiest way to proceed, everything will be set up by the Windows
>> setup itself, and any location in the user home or ProgramData
>> that may have been written somewhere else will just be correct,
>> because there will never have been directories in the wrong
>> place.
>
>> My memories of unattended installations are faint; you may want
>> to start checking from
>> https://technet.microsoft.com/en-us/library/cc786944%28v=ws.10%29.asp
x
>>
>>
or https://technet.microsoft.com/en-us/library/cc732280%28v=ws.10%29.asp
>> x

This could be a nice solution *if* the unattended installation can
initialize and format the private disk by itself. Still, probably not
all users can go with a fresh installation so a solution that works
for an already installed OS is preferable.

There are some other issues in general. For example, all child VMs
based on a template will have the same Windows host name because it's
stored in the system registry hive which is located in
Windows\system32\config. Of course this hive contains a lot of other
global settings that *should* be inherited from the template. I
imagine this could be solved by creating an explicit list of such
non-inheritable settings. They could be copied from the template by
default but we should provide some way to permanently override them
(maybe a special executable that the user will run once all the
"private" settings are changed, that executable will read those
settings and store them, then our agent will re-apply them on each VM
start).

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJV3bJhAAoJEIWi9rB2GrW7G4sH/1VuFzf36n96OKgRwLhsxmAm
lndJFzPkp8JPZlYlvZCtzGifuljV//lY2wVmFQIvvuaQZqpW24Ot7dhByOHblV0m
OzJh2KClu7s6TZJeCeBSLzrQgtP22NSKvBKmnnTVf7j2LrNVaSEBVZzMHBaRcrt/
XsGM7JfVtVIsx1vunZbQ2blQkofREg8AMFnpM9sKI5Oq4uyzoknQWG8KD/UGF+vt
ZshKKKD6nRB42ct+uabiTgEPkhMm2DVlcQBR1RxweKBSN56UFKcCoSnCc1fApAid
kgVUDOuMREtWjllymCA0joFL0bnGdVtTxxuj4YjsARXXnE3PdvWaMPMycJ8gL7o=
=aKdM
-----END PGP SIGNATURE-----

[mihaig...@gmail.com]

On Saturday, August 22, 2015 at 11:13:14 PM UTC+2, cprise wrote:
> After following the instructions here and at the doc/WindowsAppVms page,
> I had a problem with the network access. Network/sharing center reported
> 'Unidentified network' and 'No network access' when using the Xen PV
> NIC. After 2 or 3 more reboots network access was restored.

Have the same problem, the reason was the IP assigned to the AppVM is the one from the Windows Template (which I blocked via the firewall, no need to let the template go to the internet). Manually changing the IP in AppVM (with the one shown in QVMM) restores network. You say your problem solved by itself?...Thanks

[Rafał Wojdyła]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Try disabling the DHCP Client service in the VM if it's enabled.

- --
Rafał Wojdyła
Qubes Tools for Windows developer
https://www.qubes-os.org/
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJWGS8zAAoJEIWi9rB2GrW7lDIH/RkFUND5OWQJqqBBYlTEcPds
E0vNJIIoRI6cpoAvErNbTnOeOnVaKJxZOYEg/EGem/fe9Xj4Pf56Fpw5tcUo05kq
xVKOmFiPNfcgcEChZ1Z4KsN4cu2bl6b37eQcUDBSeqLJePr/lX/vNw9FnDlQTtxJ
8SamVAPJqBd7UBvRSSj6ymgH9u3Miq7Ew9/gW+c7ElMHSJLKLwhNAsHwTn+Y6ZCv
mjJ3TH9KXjgVGX7Tp3dadirVtALMrIOaxm6aV/6msOxNQNkV1dreOijaNMXuVtd6
WyxgyGApo/VgKoWd4aMVggPYCdoK7edyryyakW9tNKAh9iggmPzqaDS0AS9W6ys=
=2v9q
-----END PGP SIGNATURE-----