Came across this on the Citrix forums and only as I’d seen it with my own two eyes in the not-so-recent past thought I’d impart.
Got tickets internally for issues using Google Chrome in our published desktop environment. Basically had broken on us post update but nothing in the recently added MS patches (only updates added to image) pointed to an issue relating to it.
Fix eventually lead to Citrix API hooks and its relationship with the application. By disabling chrome.exe via the instructions given in :
It lead us to chrome goodness…now why…
Although theoretically possible in vSphere 6.0 VM secure boot support only officially supported with vSphere 6.5. Interesting thing with 6.5 is the range of improvements made in the security space with the hypervisor. Been good too that VMware have been listening to the user community in simplifying the adoption of a lot of these features.
An example being VM secure boot support which is easy to setup.
I) Requires EFI firmware support
II) Works for Windows and Linux virtual machines
To setup simply:
i) edit your virtual machine properties
ii) Choose VM Options tab
iii) Make sure EFI is choosen under the Choose which firmware should be used to boot the virtual machine
iv) Tick the tick box beside Secure Boot (EFI boot only) and ok
And your done
Thankfully citrix have released this. Been doing a pilot with users’ using the receiver with positive feedback. Only caveat would be time zone issues. Thankfully resolved with latest update:
Recently came across a good MS blog article that covers some of the improvements made in VM monitoring at a cluster level in Windows Server 2016:
Good to see MS taking note of these “softer” type failure scenarios that occur more often in the VM space.
A re-thread but worth re-iterating this one as can stir you out of a pickle with your XenApp 6.x DB without you knowing it.
First make sure you have a backup taken of your citrix datastore database. Then run following commands :
DSCheck /full servers /silent >c:\servers.txt
DSCheck /full apps /clean> c:\apps.txt
DSCheck /full printers /clean> c:\printers.txt
DSCheck /full groups /clean> c:\groups.txt
For xenapp 6.x environments run the additional command
DSCheck /full worker groups /clean > c:\workergroups.txt
Recently came across an issue trying to assign a static IP address to an OVA file. Was going to post it on the VMware communities site but someone had raised a post asking same question. Turns out the fix is a little more involved than assigning one to an OVF file. Good VMWare discussions article came to my (and some other folks’) rescue: