Recently changed our VMware switching from standard to distributed switches. After the change, we were no longer able to deploy new VDIs using MCS. We would get an error on the machine catalog that stated “There is no available network enabled for provisioning in this hosting unit Path not found”
So we consulted the manual (Google) and found this article from citrix. https://support.citrix.com/article/CTX139460. This article gives directions on how to update the hosting unit network after a change on the Hypervisor side. Followed the article and updated the network only to find our that it will not fix our issue. The citrix article even warns that this will not fix any new VDI deployments and they recommend creating a new machine catalog. This thoroughly aggravated me! I should not have to create a new machine catalog to update this parameter! So I called citrix support and well… we know how that turned out.
So fresh off the call with support and unwilling to accept defeat, I found a way! Here is how to fix it! Disclaimer: This is not supported by citrix and does involve modifying the database directly. Proceed with caution!
Follow CTX139460 and update your hosting config.
Create a new machine catalog (dont worry, its only temporary)
Backup your site database – CYA!
Open SQL Management studio and connect to the SQL server
Open your site database and look for a table named DesktopUpdateManagerSchema.ProvisioningSchemeNetworkMap
Right click the table and select top 1000 rows. You will see an output like the below. You should have 1 entry for each machine catalog that uses MCS. Note the bottom record is the new catalog we just created and it has the right network.
Right click the table again and click edit top 200 rows.
Copy the correct values in networkid and networkpath to your other Provisioning schemes that are broken. (Get-ProvScheme to see your schemes, look for the UID that will match what you see in the database.)
After you modify these values you should be able to deploy machines using your existing catalog. You can now remove the new catalog we created in step 2.
Recently we had an outage in our environment which was caused by the license server daemon failing. All of our XenApp servers are provisioned servers and they reboot nightly to pull in a fresh image for the next day. In this particular case, the license server failed sometime in the middle of our reboot cycle so some servers came up and could not contact the license server. This caused the servers to not accept user connections. You might say but “what about the 30 day grace period?”, well yea about that, these are provisioned app servers so the license cache file that XenApp stores locally gets wiped out when you reboot the server. Citrix provided a fix for this back in XenApp 6 as documented in http://support.citrix.com/article/CTX131202. This article is confusing and not written correctly so I thought I would put the steps we followed in our environment out here for your pleasure.
Create a folder on a file server and share that folder
Modify the permission on that folder to add the computer account for each xenapp server in your farm. We created a group in AD with all the computer accounts in the group and then assigned the group to this folder. The accounts need modify permission to this folder. Make sure you check your share permissions as well.
Modify the registry key from step 2 in the citrix article to point to the UNC path of the folder you just created. This key should be modified on your image while it is in private mode.
Commit your image and assign it to your servers.
The next time your XenApp servers boot they will create a file called MPS-WSXICA_MPS-WSXICA_<em>SERVERNAME</em>.ini in your new share. Each server will create its own file, this is the part that the citrix article fails to clarify. The license server must be online during the first boot so the servers can pull a license, you cannot try this in the middle of a license server outage.
After these changes are made if your provisioned servers come online while the license server is down you will then start the grace period and prevent an outage. That is as long as your newly created file share is accessible.
A user found this issue because on his mobile device (IPad) it said he was connected to an app that he did not open. Here is the scenario:
1. copy an existing app named “Calculator1″
2. Rename the copied app to “Calculator2″
3. The web interface and receivers will now show the new name. But when the user connects to calculator2 from an Ipad, goes to “switch apps” button on receiver, it will show connected to calculator1.
Looking into the problem further, I ran a Get-BrokerApplication -name calculator2.
This appears to be a bug in XenDesktop 7. Whenever you copy or rename an app it does not update the BrowserName attribute to the new name. To fix this you can run the below PowerShell script from a DDC. This script will make the BrowserName match what is set for PublishedName for all apps in your farm/site.