To resolve this issue, you must first manually delete some of the content which has been incorrectly created. This example will use ‘Microsoft Excel for iOS’ as the affected app which is in need of manual steps to remove. This example also assumes that Citrix Endpoint Management is in use for MDM functions. Once fully removed, the app can then be deployed again, gracefully, by using modified settings.
To manually remove the affected app and related settings:
– Log on to Citrix Cloud Library with an administrator account (requires Citrix Endpoint Management permissions and also Library permissions)
– Open the Library and delete the app, if it is found (the app will likely be missing from this screen, though it is best practice to delete the app from the Library if it is found in the Library)
– Log on to Microsoft Azure using a suitable account with administrative privileges (require permissions to manage applications)
– Find the following elements and manually delete them:
1) Under Intune App Protection > Apps > Delete the affected app if it is found
2) Under Intune App Protection Policies > Delete any entries for the app here also (if any are found)
3) Under Intune App Configuration Policies > Delete any entries here too (if any are found)
The steps listed above will remove the app and related settings from Intune only.
– Log on to Citrix Endpoint Management console (if in use) and delete the following entries
1) Under Configure > Apps > Delete the affected app if found
2) Under Configure > Delivery Groups > Delete the Delivery Group, which has been created for the app, if one is found
The steps listed above will fully remove the app from Microsoft Azure and also from Citrix Endpoint Management service. Only after the app has been removed, will attempts to publish it again succeed as intended.
When publishing the app again, take care to enter the configuration details in the same way as described at: https://docs.microsoft.com/en-us/intune/app-protection-policy-settings-ios.
For ‘iOS Minimum operating system’, the detail should be entered as ‘major dot minor’ (for example, enter 12.0, not 12).
In this example, entering ‘12.0’ for ‘Require minimum iOS operating system’ meets the syntax requirements for Intune MAM. Using this value does not result in ‘500 internal server error’ being received.
I have been tasked with moving our CMS solution from our datacentre to AWS. I have seen a few sugggestions around restoring the current DB and selecting that during build then using the migrate tool to get all packages across. Another option discussed was to set up a hierarchy and once we have everything synched to the new NS and package servers to remove the hierarchy.
A few questions for a bit of advice
Has anyone moved to AWS from in house, and if so what method did you use?
Can the Symantec ITSM AWS AMI be configured to use an existing DB or is it a default configuration on startup?
Any thoughts on the migration tool, is it reliable?
I know this is not how hierarchy is designed to work but would there be any problems with using this method?
We have a pretty small estate under 5000 devices but also a small IT team so we need to get this right
Any advice would be appreciated, Thanks in advance
- Access to the XenApp and XenDesktop Service of Citrix Cloud.
- An Azure Subscription.
- An Azure Active Directory (Azure AD) user account in the directory associated with your subscription, which is also co-administrator of the subscription.
- An ARM virtual network and subnet in your preferred region with connectivity to an AD controller and Citrix Cloud Connector.
- “Microsoft Azure” host connection
- To create an MCS machine catalog, XenDesktop requires a master image that will be used as a template for all the machines in that catalog.
Creating Master Image from Virtual Machine deployed in Azure Resource Manager
Create a virtual machine (VM) in Azure using the Azure Resource Manager gallery image with either the Server OS or Desktop OS (based on whether you want to create Server OS catalog or Desktop OS catalog).
Refer to Citrix Documentation – install Citrix VDA software on the VM for more information.
Install the applications on the VM that you want to publish using this master image. Shutdown the VM from Azure Portal once you have finished installing applications. Make sure that the power status for the VM in Azure Portal is Stopped (deallocated)
When creating MCS catalog we need to use the .vhd file that represents OS disk associated with this VM as master image for the catalog. If you have the experience of using Microsoft Azure Classic connection type in XenDesktop, you would have captured specialized image of the VM at this stage, but for Microsoft Azure connection type you don’t have to capture the VM image, you will only shutdown the VM and use the VHD associated with the VM as master image.
Create MCS Catalog
This information is a supplement to the guidance in the Create a Machine Catalog article. After creating master image, you are all set to create MCS catalog. Please follow the steps as described below to create MCS catalog.
Launch the Studio from your Citrix Cloud client portal and navigate to Machine Catalogs in the left hand pane.
Right click Machine Catalogs and click on Create Machine Catalog to launch the machine creation wizard.
Click Next on the Introduction page.
On the Operating System page Select Server OS or Desktop OS based on what type of catalog you want to create and click Next.
On the Machine Management page, select Citrix Machine Creation Service (MCS) as the deployment technology and select the Microsoft Azure hosting resource and click Next.
Master Image Selection – This page provides a tree view which you can navigate to select the master image VHD. At the topmost level are all the resource groups in your subscription except those which represent the MCS catalog created by XenDesktop. When you select and expand a particular resource group, it shows the list of all storage accounts for the Azure Umanaged Disks in that resource group. If there are no storage accounts in that resource group, there will not be any child items under that resource group. If you have manually created number of resource groups and storage accounts to host your manually created VMs in your subscription, the master image page will show all those resource groups, storage accounts, containers and VHDs even though not all those VHDs are master images that you want to use for the provisioning. Select the storage account that has your master image. When you expand the storage account, it shows list of containers inside the storage account. Expand the container that has master image VHD and select the VHD that you want to use as master image for the catalog.
In the case of Azure Unmanaged Disk, you need to know the VHD path in order to select it. If you have stood up a VM in Azure and prepared it to be used as a master image and you want to know the VHD path, follow the steps below:
Select the resource group that has your master image VM.
Select the master image VM and click Settings
Click on Disks then Click OS Disks and copy the disk path.
OS disk path is structured as https://<storage account name>.blob.core.window.net/<container name>/<image name>.vhd
You can use the disk path obtained in the step above to navigate the tree view to select image.
In the case of Azure Managed disk, it will be available directly under the Resource Group that you had created or as a part of the Virtual Machine’s Resource Group, as show below:
Note: If you don’t shutdown the master image VM and select the corresponding VHD to create a catalog, the catalog creation will fail. So make sure if you are selecting the VHD which is attached to running VM instance, the VM is in Stopped(deallocated) state.
Storage type selection – XenDesktop supports Locally Redundant Standard or Premium storage for provisioning VMs in Azure. Your master image VHD can be hosted in any type of storage account, but for the VMs to be provisioned in Azure, XenDesktop will create new storage accounts based on storage type you selected.
XenDesktop will provision maximum 40 VMs in single storage account due to IOPS limitations in Azure. For example if you want to create 100 VM catalog, you will find 3 storage accounts created and VM distribution in each storage account will be 40, 40 and 20.
VM instance size selection – XenDesktop will show only those VM instance sizes which are supported for the selected storage type in the previous step. Enter number of VMs and select the VM instance size of your choice and click Next.
Network Card Selection – Select network card and the associated network. Only one network card is supported.
Select resource location domain and enter machine naming scheme.
Enter credentials for your resource location Active Directory.
Review the catalog summary, enter the catalog name and click Finish to start provisioning.
Once the provisioning is complete, you will find new resource group created in your Azure subscription which hosts, all the VMs, storage accounts and network adapters for the catalog you provisioned. The default power state for the VMs after provisioning is Stopped(deallocated).
Once the provisioning is complete, you will find new resource group created in your subscription that has VM RDSDesk-01 as per the naming scheme we provided, NIC corresponding to that VM and a storage account that XenDesktop created to host the OS disk and the identity disk for the VM. The VM will be hosted on the same network as that of the selected hosting resource during catalog creation and the default power state of the VM will be Shutdown(deallocated).
The resource group created by XenDesktop during the MCS provisioning will have following naming convention
To find out which resource group in the Azure portal corresponds to the catalog you created from studio, follow the steps below.
- Connect to your XenApp and XenDesktop service using Remote PowerShell SDK. Please visit this link to find our how to interact with your Citrix Cloud environment using Remote PowerShell SDK.
- Run command Get-ProvScheme -ProvisioningSchemeName <Catalog Name>
- Note down the ‘ProvisioningSchemeUid’ from the output of the above command.
- Go to the Azure portal and search for the resource group name that contains ‘ProvisioningSchemeUid’ you obtained in step 3.
As a best practice you should always create a copy of your master image and use the copied image as input to the provisioning process. In future if you want to update the catalog, you can start the master image VM and make necessary changes, shut it down and again create a copy of the image which will be your update image. This helps you to use the master image VM to create multiple image updates.
Remember to shutdown the master image VM from Azure portal before starting to create the catalog. The master image needs to be copied into catalog’s storage account once provisioning starts, so we need to make sure it is not in use by any VM, otherwise it will lead to image copy failure and eventually provisioning failure.
- Make sure you have sufficient cores, NIC quota in your subscription to provision VMs. You are most likely going to run out of these two quotas. You may not be able to check your subscription quota limits,
- If your master image VM is provisioned in the Premium storage account then just shutting down the VM from the portal isn’t enough. You also need to detach the disk from the VM to use it as master image in provisioning. But in Azure Resource Manager you can not detach the disk while the VM is still available. So you need to delete the VM from the portal, this will only delete the VM but keep the OS disk in the storage account. The NIC corresponding to the VM also needs to be deleted separately.