Yes, I know it's not yet supported...but I'm curious how your testing is going with the new Win10 Fall Creators Build 1709. (Insider Fast Ring)
We've played around with it, but cannot get composer to successfully finish provisioning. We think it's due to all of the new Security Features backed into the OS. We will slowly disable them until we are successful. How's your testing going?
Thanks, nice find.
Did not need to change DependOnService.
Only deleted subkey security
Thanks, great job
Thank you Scott. Deleting the Security subkey works like a charm!
Worked excellent for us, kthxbye!
I do not see a Security Subkey on my Win10 1709 master image...but removing the dependency on the BFE worked great!
Windows 10 Falls Creator build working for me under Horizon 6.2.2.
EDIT: The Subkey finally showed up...not sure why it was missing. I deleted it, and I'm back in business.
Worked for me as well. Removed the Security Subkey for the BFE Service.
Thanks for this find!
After Upgrade to 7.3.2 my vm (Build 1709) stuck in customizing and not joining to domain and other sysprep setting (I deleted security subkey in BFE on golden image)
everything is good on 7.3.1 !
any update for the new problem?
Two strange things with 1709 build and linked clone pool (Horizon 7.3.2)
1- User login into the pool and the session is locked ?? (ask for Ctrl-Alt-Del) user enter password and all is OK
2- User credentials are not passed to Office 365, when starting MS application, ask for a login to activate the license (shared computer license specified)
Property Name="AUTOACTIVATE" Value="1"
Any ideas ?
Tried the same golden image with an "Instant clones" pool and no problems
Thanks in advance
Having the same issue here, but only after a certain snapshot it started to be an issue. I'm currently looking for the possible cause. .
Currently having the same issue.
I have mad the registry changes recommended above but still having the same problem.
Has Vmware released any more info re this issue?
Horizon 7.4, Linked-Cloned, Windows 10 1709. I'm getting the same problem. When logon into a Desktop Pool, the session is locked, asking for Ctr-Alt-Del. The workaround is to do a manual reboot the VM after the recomposed process and then, the logon will land on the desktop, not the lock screen. I am at a lost to which logs to look at to determine the root cause.
There is also a problem with our zero clients and VMware Tools 10.2.0 or the Horizon Agent 7.4, or both.
The mouse cursor does not change when changing the column width in Windows explorer and in Excel for example. is stays a mouse arrow.
Possibly a new driver both have that could be the cause..
With 7.3.2 agent en 10.1.10 tools the cursor is acting normal.
Any news or updates on this?
for people following this thread.
vmware is officially supporting 1709 now with horizon view (agent)
Jeroen235 We are seeing the cursor animation issue on Windows 10 1703 and Windows 7 (64-bit) since upgrading to Horizon Agent 7.4.0. We previously had VMware Tools 10.2.0/Horizon Agent 7.1.0 and did not see it. Did you open a SR?
I've not yet created a SR with VMware.
The problem is also mentioned in the Teradici forum: https://communities.teradici.com/questions/8976/cursor-not-changing-in-office-products.html
I've done some further testing and noticed that when using vGPU there is no cursor issue when using the 7.4 agent on a zero client.
When setting the 3D to Disabled in the pool, the mouse cursor is wrong again. So it seems the vmware svga driver has a part in this.
Currently we are running the Windows 10 1709 environment using:
Horizon View 7.4
ESX 6.0.0, 5572656
Samsung Zero client with Teradici firmware 5.5.1
Windows 10 1709
I have not yet tested the setup with ESX 6.5, but i will upgrade soon.
Not sure if it is Windows 10 1709 related, but i've discovered another problem when using vGPU.
Is seems that the PCoIP server services causes around 30% GPU load on the nvidia GRID K1 card when idle. Causing it to max out all GPU cores very fast.
Also a known problem when you look at the release notes in the GRID driver:
6.13. nvidia-smi shows high GPU utilization for vGPU VMs with active Horizon sessions
vGPU VMs with an active Horizon connection utilize a high percentage of the GPU on
the ESXi host. The GPU utilization remains high for the duration of the Horizon session
even if there are no active applications running on the VM.
Partially resolved for Horizon 7.0.1:
‣ For Blast connections, GPU utilization is no longer high.
‣ For PCoIP connections, utilization remains high.
We are currently forced to disable vGPU for the CAD Virutal desktops because it only slows down the experience.
There seem to be a lot of troublesome bugs at the moment which are not getting fixed. Could this be because VMware is putting more effort in the BLAST protocol?
The dare I doubt Working together still does not work properly 10 1709 VMware Agent 7.4.0. We are currently still on 1703 and wait if there will be improved
We opened a SR and VMware confirmed that they can reproduce the cursor animation issue. We were provided with a registry fix which we are testing now. We have the 3D renderer disabled.