See plenty of pain on this one in the field. Not quite sure what is going on with chrome as seen as same from my own machine.
Anyways in order to circumvent message below which is what greets you launch simply need to do the following:
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –no-sandbox –disable-infobars –disable-gpu
Editing the shortcut is the simple method. Use shift+right click to edit the one on the taskbar. Sure there is noise in the forums on this but been busy to check what root cause is/ultimate fix but above should get you over the hump for now.
Recently been tasked with migrating a fair ton of apps from Win7->10. One of the challenges in this space is testing. Previously with Windows 7 the guys worked on static persistent VM’s rolled out to testers to run their updated app through it’s paces. Few obvious problems with this approach
I) Quite a bit of VM admin to do – clean up post test of apps
2) Quite a bit of email admin to do – separate mails tailored for specific app owners detailing their specific machine to test etc
Luckily things have moved on a bit most importantly regards “delivery” of the apps. By that I mean previously was hamstrung with only allowing a VDI-type scenario being of use to cover app-v sequenced apps as they where using the “follow-the-user” model (user added to SCCM user collection and deployment type set to include VDI. As such at the time experience was limited with app-v which meant a VDI solution wasn’t practical for testing as vast majority of apps where MSI’s.
To that end we have been able to get over that hurdle by publishing the MSI’s as applications in SCCM rather than packages this gives us the flexibility to use the same follow-the-user approach as with app-v sequences. That being so a Win10 VDI then would have merit.
So recently got going on standing one up (XenDesktop 7.13 back-end). Tested adding a few of the team to a few random app-v sequences / MSI’s applications and noticed horrible download performance for all our apps/packages in Software Center. For example a 200mb MSI took 40 minutes to download.
Issue was put down to the BITs client configuration. For all workstations in general in an environment there is a cap on download speed. Enclosed illustrates what’s in my lab environment
as you can see there is cap’s on performance at certain times of the day. That makes sense for the general workstation population in an environment particularly for remote users over VPN as SCCM does not have an elegant way to identify a user that roams between local and VPN.
As such of course for VDI its not a requirement so in order to switch off I inserted a GPP into my GPO to set no limit on download rate. Registry key is called EnableBitsMaxBandwidth and set to 0 (located under HKLM \Software \ Policies \ Microsoft \ Windows \ BITS)
once I place was rocking and rolling and downloads flew along
With the release of XenApp 7.1 a change to the FMA architecture meant that the local host cache (LHC) was effectively done away with. Over the course of the many upgrades in the 7.x version (up to version 13 at time of writing) citrix more and more re-integrated the “features” that came with the original IMA local host cache. With version 7.12 effectively it was restored to its former glory.
That said, in order to troubleshoot issues relating to synchronization it was quite different from 6.x. With 7.x a few different tools were introduced. Following article gives a nice overview of the architecture.
Relating to troubleshooting tools the pertinent information :
CDF tracing: Contains options for the ConfigSyncServer and BrokerLHC modules. Those options, along with other broker modules, will likely identify the problem.
Report: You can generate and provide a report that details the failure point. This report feature affects synchronization speed, so Citrix recommends disabling it when not in use.
To enable and produce a CSS trace report, enter:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
The HTML report is posted at C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html
After the report is generated, disable the reporting feature:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Export the broker configuration: Provides the exact configuration for debugging purposes.
Export-BrokerConfiguration | Out-File < file-pathname>
For example, Export-BrokerConfiguration | Out-File C:\BrokerConfig.xml.
Recently being carrying a review of our usage across the various desktop/application virtualization platforms and noticed an interesting trend in that our usage figures have pretty much tapered off as such “hitting a crossroads”.
Was interesting in our instances for the following reasons:
- previously we had some nasty outages which obviously heavily impacted both user experiences and management perceptions of the product
- been over 2 years since such outages so from that viewpoint the service is both running very reliably and from a server/host resource point of view performing well within tolerances
- Headcount was risen quite appreciably in the past 2 years so not withstanding the user groups who had a non-VDI requirement certainly quite a few user groups who had employed VDI previously that where moving back to a traditional platform.
Which bought up an interesting article posted up on the Citrix blogs relating to customer centricity.
In a way the tapering off effect has given us an opportunity to provide a fresh perspective on the product and see what we can do to improve it but this time with a much more customer-based focus. In terms of the interviewing pieces had some of my slants to add (will be reaching out to business owners soon).
So to that end reviewed with the help of human resources a break-up of the major groups in the organization (any team with >500 being the rationale) and from there looking at fitting them into a persona breakdown.
What are persona’s you say?
In essence they are a practical way to identify the requirements of your end user base.
Why are they important?
Understanding how users’ operate on their day-to-day work activities. How long using mail, custom app requirements, slow performance “kinks” experienced throughout the day.
Typical persona’s include:
Plenty of Persona templates out on the web. Below gives a breakdown of some of the key factors to consider when assessing the suitability of a user to using a VDI platform as opposed to a traditional platform. Below is an example of the breakdowns. Still gathering data my end and interviews to start soon.
An interesting feature within W2k16 within the clustering framework is the cloud witness. Quorum maintenance being one of the most important parts of any cluster design. With DR can be a design challenge as MS recommend that the quorum is located in a 3rd data center. As a lot of companies operate using 2 data centers this can pose a problem.
With the tech preview edition of 2016 it introduces a new feature called the cloud witness that looks to address this problem.
Creating one is simple and via the usual means to create a quorum using the Cluster Quorum wizard. The pre-requisites are straightforward enough too. Need:
i) An active Azure subscription
ii) Storage account
To launch the wizard:
i) Right-click the server in the Failover Cluster Manager
ii) Point to More Actions
iii) Select Configure Cluster Quorum Settings
iv) Select the Quorum Witness option
v) Select the Configure a Cloud Witness option
vi) On the next page provide the name of your Azure storage account, copy the key from the Azure Portal to the clipboard and type the Azure service endpoint
When the wizard is completed you’ll see the cloud witness displayed in the Cluster Core Resources pane in the Failover Configuration Manager snap-in.