Users cannot log on to a system using Active Directory credentials and the following error message appears: “The trust relationship between this workstation and the primary domain failed.”
Users/Citrix Admins might see this error on VDIs or App servers. Below are the solutions for the same:
This issue is seen when the session logon is attempted through Remote Desktop Protocol, ICA, or directly at the console. Only logons using local accounts are successful.
XenApp 6.5 has reached end of maintenance and with the end of life date only a few months away, migrating your existing 6.5 environment(s) to XenApp & XenDesktop 7 is highly recommended.
This also means moving from the IMA architecture to FMA. In earlier 7.x versions, some 6.5/IMA features were not available, but rest assured, they were added throughout new releases. Because some features have been rebranded or have gone through some design changes and improvements, this blog article may assist you in finding the XenApp 6.
There are different ways to deploy outlook app, like deploying the app via citrix xenapp, or installing outlook in user’s VDI.
Whatever deployment method we choose, we still have some questions related to outlook. Should I enable cache mode or leave in online mode? Should I save my data on user’s VDI locally or redirect to different share etc.. lets discuss these options.
Lets understand the differences between online mode vs cached exchange mode
User opens Netscaler page and enters their credentials over 443. User’s credentials are sent from the netscaler gateway to active directory domain controllers over: LDAP or secure LDAP using TCP ports 389 or 636 Global catalog request / TCP 3268 and 3269 (if necessary) TCP or UDP ports 1645, 1812 and 1813 (if using RADIUS) Once authenticated, user’s request is forwarded to StoreFront over 443 by Netscaler. Once validated, the Netscaler gateway interacts with StoreFront to continue the authentication process.
Symptoms or Error Intermittently few Server VDA’s remain shutdown and do not turn on automatically after scheduled reboot. On the Delivery Controller below series of events are logged: Event ID 3012 - Warning; “The Citrix Broker Service detected that power action ‘Shutdown’ (origin: Schedule) on virtual machine’domain\severname’ failed.”
Event ID 3104 - Information; “The Citrix Broker Service has completed the processing of the ‘GroupReboot’ for ‘xxxx’. The reboot cycle (UID = ‘160’) successfully completed.
The major difference between the two is the type of desktop. XenApp delivers a one-to-many Windows Server (e.g. Windows Server 2008 or 2012) machine that is shared by many users. XenDesktop delivers a one-to-one Windows desktop machine (e.g. Windows 7 or 10) that is used by a single user.
At a high level, this fundamental difference has meant:
XenApp users share the CPU, GPU, memory, and disk resources with all of the other users on the same server.
Resource locations contain different resources depending on which Citrix Cloud services you are using and the services that you want to provide to your subscribers.
Typical resources include:
Active Directory domains Citrix NetScaler appliances Hypervisors like Citrix XenServer Virtual Desktop Agents (VDAs) StoreFront servers Machines hosting the Citrix Smart Tools Agent Resource locations also contain Citrix Cloud Connectors which are required for enabling communication between your resources and Citrix Cloud. For more information about using Cloud Connectors in your resource location, see Citrix Cloud Connector.
Recently, we had to change the display name for one of our delivery groups. This group is deployed as static assignment group, meaning private assignment, one user to one VDI, assigned on their first login to that VDI.
When you create delivery group, you set a display name for your desktops/VDIs that you want users to see when they login to your citrix portal.
Below are some points to note:
The process of creating machines in XenDesktop via MCS can be split into 2 sections.
Provisioning Scheme Machine creation. Let us understand provisioning scheme step by step here:
What is Provisioning Scheme?
Provisioning Scheme can be seen as a “template‟ used to store the parameters and create the VMs. It includes details like the CPU Count of the Master Image VM, the Memory Size of the Master Image VM as well as the location of the Master Image VM used in this provisioning scheme.
In XenDesktop version 5.0, MCS used only one way to create VDIs i.e., using fast clone way. This will have one base disk(master image disk) and all the machines created from this disk will have a delta disk which contains changes like user installed apps, data etc as shown in below image:
This method has its own pros and cons as given below.
Pros:
Small disk for delta file as it only has the updates.
