Graeme Gordon

Unfortunately, we had to retire that tool as it was getting very out of date. The individual who originally developed the tool is no longer with Omnissa and at this time we could not commit development resources to redo this. Looking at this from an output perspective, there are a limited set of diagrams that are created. We could potentially just create those in PowerPoint and let you choose the appropriate one.

I saw an internal message that said that this should be resolved now and all users that authenticate to Omnissa Customer Connect should be able to download this.

Turning on Cloud Pod Architecture (CPA) will not affect any existing pools and local entitlements that might be in place. CPA adds the ability to create global entitlements that can include multiple pools, and multiple Horizon pods. But you can still have local entitlements to local pools just as you currently have.

Hi Chris, Apologies for not getting back to you sooner. I also don't have great news on this. This is an issue that I have seen intermittently on several builds of MDT servers that I have done. I haven't spent a huge amount of time trying to debug it but in the time I did spend looking, I wasn't able to spot what was going wrong. I did update the script to use an INI file but that was only to read in default settings, it didn't alter how this writes entries to the MDT database. The relevant field in an entry in the database, is the task sequence. When I looked, that field seemed to be populated correctly, so currently I don't know why that isn't being used properly.

Not sure what is causing your issue as it sounds like sometimes it is showing up and then other times it is not. You may want to create a shortcut for the new Teams client in DEM, probably on the Desktop. Create a new shortcut and define the target as %localappdata%\Microsoft\WindowsApps\MSTeams_8wekyb3d8bbwe\ms-teams.exe

There is no way for an active user Horizon session to fail-over automatically to another UAG appliance. The users protocol session (which is the ongoing session that gets interrupted if a UAG fails) has to go through the same UAG that the user authenticated through. We cannot hand off the protocol session to another UAG as it would not understand who the user was and the state of their authentication. The correct action is for the user to reconnect. See this guide for an explanation of how the Horizon connection works. https://techzone.omnissa.com/resource/understand-and-troubleshoot-horizon-connections#external-connections

Yes, that applies to Horizon 8. I just published a rewrite of that section of the guide to try and make this clearer. Let me know if that makes sense.

I briefly cover this topic in the Pod and Block section of the Horizon 8 reference architecture. https://techzone.omnissa.com/resource/horizon-8-architecture#pod-and-block

This KB article is now available at https://kb.omnissa.com/s/article/6000003

As has been mentioned, I don't think the 404 errors are related to the use of OSOT. But as you asked, there is a way to prevent OSOT from removing the new Teams app. I posted a blog with a workaround, https://techzone.omnissa.com/blog/how-optimize-horizon-golden-image-new-microsoft-teams-client We also have included this in the next release of OSOT so that you can select to keep the Teams app in the UI. That is hopefully due soon.

I've reached out the internal team to find out what happened to this KB article. It looks like there was an issue with the migration of some during the move of content to Omnissa sites. They are actively working to resolve this and make these available.

We recommend that you stop the App Volumes service (temporarily disable it) before applying Windows updates. If you use the OS Optimization Tool to do Windows Updates, it does this for you. Depending on what Windows updates are being applied, we have seen cases where the changes those make to Windows, have meant that you sometimes need to uninstall the App Volumes agent, and then reinstall one all the updates are applied.

It's a while since I did this for Access on-prem using the Avi load balancer. Here are some screenshots showing the main settings for the virtual service and the pool from that environment.

Remember that it is a vSphere host that is actually doing the copying of the package files from one datastore to another. You also don't need all the hosts in each site to be able to connect to the shared NFS datastore. To troubleshoot, you may want to reduce this to just one from each site.

Yes, we are maintaining OSOT, especially as it is part of the product downloads and fully supported. I've been helping with a few bugs and updates, and know that a new version is in the works.