Vmware

Last month, I wrote about a very annoying issue, that I discovered during a Windows 10 VDI deployment: Roaming of the AppData\Local folder breaks the Start Menu of Windows 10 Enterprise (Roaming of AppData\Local breaks Windows 10 Start Menu). During research, I stumbled over dozens of threads about this issue.

Today, after hours and hours of testing, troubleshooting and reading, I might have found a solution.

The environment

Currently I don’t know if this is a workaround, a weird hack, or no solution at all. Maybe it was luck that none of my 2074203423 logins at different linked-clones resulted in a broken start menu. The customer is running:

Disclaimer: The information from this blog post is provided on an “AS IS” basis, without warranties, both express and implied.

Last week, I had an interesting discussion with a customer. Some months back, the customer has decided to kick-off a PoC for a VMware Horizon View based virtual desktop infrastructure (VDI). He is currently using fat-clients with Windows 8.1, and the new environment should run on Windows 10 Enterprise. Last week, we discussed the idea of using Windows Server 2012 R2 as desktop OS.

One of my customers has started a project to create a Windows 10 Enterprise (LTSB 2016) master for their VMware Horizon View environment. Beside the fact (okay, it is more a personal feeling), that Windows 10 is a real PITA for VDI, I noticed an interesting issue during tests.

The issue

For convenience, I adopted some settings of the current Persona Management GPO for Windows 7 for the new Windows 10 environment. During the tests, the customer and I noticed a strange behaviour: After login, the start menu won’t open. The only solution was to logoff and delete the persona folder (most folders are redirected using native Folder Redirections, not the redirection feature of the View Persona Management). While debugging this issue, I found this error in the eventlog.

TL;DR: There’s a script at the bottom of the page that fixes the issue.

Some days ago, this HPE customer advisory caught my attention:

Advisory: (Revision) VMware - HPE ProLiant Gen8 Servers running VMware ESXi 5.5 Patch 10, VMware ESXi 6.0 Patch 4, Or VMware ESXi 6.5 May Experience Purple Screen Of Death (PSOD): LINT1 Motherboard Interrupt

And there is also a corrosponding VMware KB article:

ESXi host fails with intermittent NMI PSOD on HP ProLiant Gen8 servers

Today, I had a very interesting discussion. As part of an ongoing troubleshooting process, console screenshots of virtual machines should be created.

The colleagues, who were working on the problem, already found a PowerCLI script that was able to create screenshots using the Managed Object Reference (MoRef). But unfortunately all they got were black screens and/ or login prompts. Latter were the reason why they were unable to run the script unattended. They used the Get-VMScreenshot script, which was written by Martin Pugh.

Last Wednesday, VMware has published a list with the vExperts for 2017.

The wait is over, vExpert 2017 has been announced at https://t.co/lNE1KzAG3n. Thank you to everyone who applied. pic.twitter.com/N466wz1p29

— VMware vExpert (@vExpert) February 8, 2017

I’m on this list. I’m on this list for the fourth time, which makes me very happy and proud. I was surprised that I’m on this list. I have written only a few blog posts last year. I sometimes tweet about VMware, and I am active in some forums. The focus of this blog has shifted.

Certificates are always fun… or should I say PITA?  Whatever… During a small Horizon View PoC, I noticed an error message for the View Connection Server.

That’s right, Mr. Connection Server. The certificate subject name does not match the servers external URL, as this screenshot clearly shows.

As part of a project, I had to deploy a VMware EUC Access Point appliance. Nothing fancy, because the awesome VMware Access Point Deployment Utility makes it easy to deploy.

Unfortunately, the deployed Access Point appliance was not working as expected. When I tried to access my Horizon View infrastructure behind the Access Point appliance, I got a HTTP 504 error. The REST API interface was working. I was able to exclude invalid certificates, routing, or firewall policies. I re-deployed the appliance using the the IP address of the connection server, instead of the FQDN. And this worked… I checked the name resolution with nslookup and the name resolution failed. So that was probably the problem.

Today, I have stumbled upon a fact that is worth being documented.

TL;DR: Use the “Windows Srv 2016 DataCtr/Std KMS” host key (CSVLK), if you want to activate Windows 10 Enterprise LTSB 2016 using KMS. Or use AD-based activation. For more information read the blog post of the Ask the Core Team: Windows Server 2016 Volume Activation Tips.

A customer wants to deploy Windows 10 Enterprise LTSB 2016. A Windows Server 2012 R2 is acting as KMS host, and successfully activates Windows Server 2012 R2 and Microsoft Office 2013 Professional Plus. The “Windows Srv 2012R2 DataCtr/Std KMS for Windows 10” CSVLK was successfully installed. Nevertheless, the “current count” value does not increase. The client logged the event 12288:

Nearly a month ago, a tweet caught my attention:

New Blog Post: Discounted VCP7-DTM Beta Exam for a Limited Time https://t.co/IkwLTDdvO5

— VMware Learning (@VMwareEducation) October 4, 2016

These beta exams are a cost-effective way to achieve certifications. The last beta exam I took, was the VCP6-DCV beta. Because I already had the VCP6-DTM on my to-do list, the new VCP7-DTM beta exam was released just in the right moment.

As already mentioned in the blog post of the VMware Education and Certification Blog, there are primarly three reasons to take this beta exam: