martinturner's Posts

My issue is that it works fine in the base image. I've already attempted the cleanup and I've just tried the appx command given and neither seem to do anything on the base image. I've also tried runn... See more...
My issue is that it works fine in the base image. I've already attempted the cleanup and I've just tried the appx command given and neither seem to do anything on the base image. I've also tried running it as a user (so when the shell is broken) and it doesn't fix it (and also seems to require an elevated shell before it stops erroring). I'm on new install number 3 now (from the 21H1 ISO) with various options included and excluded. I have done a fresh install and removed nothing from the base image at all, and its still breaks.   I'm starting to wonder if its just 21H1 that im having issues with. My current plan is to wait for 21H2 and see if its still broken, but that only helps me if it magically fixes it.
I'm having a little bit of an issue with the windows 10 notification side bar (the thing that slides out from the right hand side and shows you all the emails and AV updates you are ignoring). I can ... See more...
I'm having a little bit of an issue with the windows 10 notification side bar (the thing that slides out from the right hand side and shows you all the emails and AV updates you are ignoring). I can see I have new notifications but when I click on the icon nothing happens, and by nothing I mean the application tries to do its thing and instead logs a crash report in the windows log.   Background: We have multiple floating VDI pools using Windows 10 LTSC (1809) and Horizon 7.13.1 (latest for 7). As this is pretty much end of life now and has started causing issues with office I am attempting up upgrade the base images to Windows 10 Enterprise 21H1 (nice big upgrade and also supported). The notification window has been working absolutely fine using 1809 but I have noticed in 21H1 the 'app' is now a windows store app. The windows store doesn't exist on the LTSC version (I cant remember if its been removed or if its just not there) so its been all fun and games getting things to work in 21H1. I was removing some apps but as I thought this was causing the issue for testing I have removed absolutely nothing and im still getting the error above. Everything else appears to be working as expected. Really annoyingly, in the base image this works. I can get the notifications just fine. It only seems to be an issue once Horizon has cloned the machines (or I guess I'm logging in as a 'new' user). I have however tried a complete rebuild of the base image from scratch just to see if the issues goes away, and it doesn't. I actually doubt most users will even notice this issue but I can guarantee some manager will notice and then it'll be the worst fault ever.   The logged error (happens every time you click on the notification icon): Faulting application name: ShellExperienceHost.exe, version: 10.0.19041.1151, time stamp: 0x6985bf98 Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf Exception code: 0xc0000409 Fault offset: 0x000000000007286e Faulting process id: 0x2e34 Faulting application start time: 0x01d7c931b15bb97e Faulting application path: C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe Faulting module path: C:\Windows\System32\ucrtbase.dll Report Id: ee79dede-182c-419a-8ea8-1c23d88049cf Faulting package full name: Microsoft.Windows.ShellExperienceHost_10.0.19041.1023_neutral_neutral_cw5n1h2txyewy Faulting package-relative application ID: App
Depends on your support situation. If you still have an active support contract you can upgrade all the way to the latest version of Horizon 8. Latest version of Horizon 7 in 7.13.1
There isnt an ARM version of the Horizon client available anymore. Both TLXOS and Stratodesk use a custom version of the client which they presumably develop in house (I assume vmware assist some... See more...
There isnt an ARM version of the Horizon client available anymore. Both TLXOS and Stratodesk use a custom version of the client which they presumably develop in house (I assume vmware assist somewhere), neither of which are free. There USED to be an open source version of the client which you could compile for ARM but this hasn't been around for long enough that it no longer works with modern Horizon. I too would love to be able to use the horizon client on a Pi board, but its not going to happen without paying for a license to one of the above OSs (and then you lose all the rest of your OS).
We pretty much exclusively use the Horizon Helpdesk fling from flings.vmware.com (Horizon Helpdesk Utility | VMware Flings ). It gives us a quick and easy breakdown of how everyone's VM is going,... See more...
We pretty much exclusively use the Horizon Helpdesk fling from flings.vmware.com (Horizon Helpdesk Utility | VMware Flings ). It gives us a quick and easy breakdown of how everyone's VM is going, their network stats and if there is an issue a quick and easy shortcut to the windows remote assistance tool. We are located in Australia and have staff in both Singapore and the UK and generally we have found Horizon using Blast to be well fast enough for staff to effectively work on even high bandwidth software (Audio processing in this case).
Restriction aside (at least in my environment users tend to have a dozen or less apps, with the "common to everyone" apps in the base image) you can indeed already do this with the exist appvolum... See more...
Restriction aside (at least in my environment users tend to have a dozen or less apps, with the "common to everyone" apps in the base image) you can indeed already do this with the exist appvolumes. I in fact already do this with the existing appvolumes and we haven't upgraded to 4.0 yet. My understanding was it was more of a logical change in that you now get apps in the interface with versions listed under each app, rather than the existing version were you just get a big long list of appstacks split up however you happen to be naming them. I know I'll be using the versioning quite heavily when we eventually upgrade as I've already pretty much started to use my own versioning system in the current version (i include a date a build number in the appstack name). I was hoping the 'under the hood' changes they were making would have speed up app stack attachments to the point where having 20-30 appstacks per user wouldn't be an issue. Right now its bearable to log in (at least on my setup) with 5-10 appstacks but realistically anything past that makes logging in take so long you start to get complains. In my head I've been treating 4.0 more like 2.19 (with 2.18 being LTS anyway) with the caveat that once you've upgraded there is no going back.
So for migrations VMWare have a fling for this: App Volumes Migration Utility | VMware Flings It'll (hopefully) take an existing app stack and just convert it to the new 4.0 format, meaning you... See more...
So for migrations VMWare have a fling for this: App Volumes Migration Utility | VMware Flings It'll (hopefully) take an existing app stack and just convert it to the new 4.0 format, meaning you can migrate now and then slowly re-provision your apps in to single appvolumes over time. I mean you are updating the apps anyway right? I'm holding off until I see 4.1 (or 4.0.1 at least) as its supposed to bring back the 'limit attachments' checkbox which we actually use here (I have a small 3 machine dev pool to test various updates/changes)
Right now there isn't a massive difference. v4 looks to be migrating away from the idea of managing collections of apps and instead individual apps with versioning (allowing you to have different... See more...
Right now there isn't a massive difference. v4 looks to be migrating away from the idea of managing collections of apps and instead individual apps with versioning (allowing you to have different people have different versions of the app if there are compelling reasons to do this, say plugin compatibility). 2.18 is LTS though so it'll be supported for a bit longer yet (2.18.1 is out already). You should probably be looking at plans to move away from view 6 though (even if its new hardware migration) because eventually none of it is going to be supported and its better to be ahead of the game.
We were originally running 3vCPUs with LTSC 1809 but after adjusting the scheduler to get around all of the Intel cross thread compromises I realized it was just going to waste 1 thread per machi... See more...
We were originally running 3vCPUs with LTSC 1809 but after adjusting the scheduler to get around all of the Intel cross thread compromises I realized it was just going to waste 1 thread per machine anyway so I increased it to 4. We didn't really notice any difference between 3 and 4 vCPUs. We DID notice a huge difference when upgrading them from 4GB RAM to 6GB, and another smaller difference when upgrading them again to 8GB. With the exception of 2 apps everything is now running great. (And those 2 apps are just bad apps, they run terribly on dedicated hardware as well)