How To Configure Standalone SQL Server, Database Mirroring, and Always on High Availability.

For the Standalone SQL Server Connection String: “Server=SQLServerName; Initial Catalog=DBName ; Integrated=True ”

User-added image

For the Database Mirroring Connection String: “Server=PrimarySQLServerName; Initial Catalog=DBName ; Integrated=True ; Failover Partner=SecondSQLServer”

User-added image

For Always on High Availability: “Server=ListenerName; Initial Catalog=XDdb;Integrated Security=True; MultiSubnetFailover=True”

User-added image

Steps to Update the Connection Strings:

  1. Take the Backup of the Databases and snapshot of all the Controllers.

  2. Only on 1st Controller, stop and clear the Datastore connections:

    Set-LogSite -State “Disabled”

    Set-MonitorConfiguration -DataCollectionEnabled $False

    Set-MonitorDBConnection -DataStore Monitor -DBConnection $null -AdminAddress $Localhost

    Set-LogDBConnection -Datastore Logging -DBConnection $null -AdminAddress $Localhost

  3. On all the other Controllers, reset their datastore configuration (which reads the cleared setting above)

    Reset-MonitorDataStore –DataStore Monitor –AdminAddress $Localhost

    Reset-LogDataStore –DataStore Logging –AdminAddress $Localhost

  4. On every Controller you need to disconnect all the services from the database, note that the order here is important, the last two cmdlets must be at the end:

    Set-SfDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-EnvTestDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-MonitorDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-BrokerDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-ProvDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-HypDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-AcctDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-ConfigDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-AnalyticsDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-LogDBConnection -DBConnection $null -AdminAddress $Localhost

    Set-AppLibDBConnection -DBConnection $null -AdminAddress $Localhost (For 7.15)

    Set-OrchDBConnection -DBConnection $null -AdminAddress $Localhost (For 7.15)

    Set-TrustDBConnection -DBConnection $null -AdminAddress $Localhost (For 7.15)

    Set-AdminDBConnection –Force -DBConnection $null -AdminAddress $Localhost

  5. At this stage your site will have no db connectivity. The next step is to hook all the services back up to the site database:

  6. $csSite =” Server=<ListenerName>; Initial Catalog=<DBName>; Integrated Security=True; MultiSubnetFailover=True”

    $csMonitor =” Server=<ListenerName>; Initial Catalog=<Monitor_DBName>; Integrated Security=True; MultiSubnetFailover=True”

    $csLog =” Server=<ListenerName>; Initial Catalog=<Log_DBName>; Integrated Security=True; MultiSubnetFailover=True”

    Set-AdminDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-LogDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-AnalyticsDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-ConfigDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-AcctDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-HypDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-ProvDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-BrokerDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-MonitorDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-EnvTestDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-SfDBConnection -DBConnection $csSite -AdminAddress $Localhost

    Set-AppLibDBConnection -DBConnection $csSite -AdminAddress $Localhost (For 7.15)

    Set-OrchDBConnection -DBConnection $csSite -AdminAddress $Localhost (For 7.15)

    Set-TrustDBConnection -DBConnection $csSite -AdminAddress $Localhost (For 7.15)

  7. Then on one Controller only, set the datastore connections and enable them:

    Set-MonitorDBConnection -DataStore Monitor -DBConnection $csMonitor -AdminAddress $Localhost

    Set-LogDBConnection -Datastore Logging -DBConnection $csLog -AdminAddress $Localhost

    Set-LogSite -State “Enable”

    Set-MonitorConfiguration -DataCollectionEnabled $True

  8. And on all the other Controller, reset their datastore configuration

    Reset-MonitorDataStore –DataStore Monitor –AdminAddress $Localhost

    Reset-LogDataStore –DataStore Logging –AdminAddress $Localhost

Related:

  • No Related Posts

How to Create a Platform Layer in App Layering 4.x

The first thing that’s important to understand is that a platform layer is the highest priority layer in a published image. So a setting or file in the platform layer will be the last applied when the file system and registry are merged during image creation. However, one thing to note is that, just like regular application layers, any changes made to the local SAM database will not be captured in the platform layer.

The general flow for creating a platform layer is as follows (PVS, MCS, and Horizon View are covered in more specific details near the end of this article)

  1. Install Special Drivers like NVIDIA
  2. Install the Broker Agent
  3. Join the Domain. This is done to configure the registry as a domain joined machine would be. Each broker is actually responsible for joining the desktops/Xenapp servers to the domain.
  4. Install any SSO software you may use. We do this because both the broker agents and SSO software modify Windows Logon Providers and we don’t want the platform layer to just overwrite the SSO settings from another layer.
  5. If the platform layer will be used cross platform, meaning for example that you package on vSphere but you will be deploying to XenServer, then you install the cross platform hypervisor tools as well. Your primary hypervisor tools should be installed in your OS layer.
  6. If you are using PVS, make sure you install the PVS tools last, as required for PVS with or without App Layering

If you are using Receiver and Workspace Environment Management in your XenDesktop or XenApp environment include those in the Platform Layer as well. Receiver has an SSO component and WEM can be affected by the scrubbing we do between hypervisors if it is not installed in the Platform layer.

There are some problems that also need to be handled via GPO/GPP because of the SAM database update issue with layering. Since we join the Domain here in the Platform Layer you will not automatically have Domain Admins in the local Administrators group and Domain Users in the local Users group. The easiest way to deal with this is to create a Group Policy Preference (GPP) to fix that using those groups or whatever groups you desire to assign administrators and users to your machines.

The Citrix VDA also adds two services into local groups. These can also be added via GPP.

The NT ServiceCitrixTelemetryService is added to the local Performance Log Users group.

The NT ServiceBrokerAgent is added to the local Performance Monitor Users group.

If you want to allow direct access via RDP to VDA’s add a Domain group to the local Direct Access Users group.


If you are using Citrix App-V integration, the VDA will create a local user (CtxAppVCOMAdmin), then give access for that local user to a DCOM object (Citrix.VirtApp.VDA.Com.AppVObject).

The way to handle this is to create the local user in your OS layer (before you create the platform layer), give it a password and document the password. Then after you install the VDA :

Open Component Services

goto DCOM Config

Open Properties of Citrix.VirtApp.VDA.Com.AppVObject, click the Identify tab and change the password to the one you set in the OS layer.

A word on optimizations:

Since the platform layer is the highest priority layer you may think it would be the best layer to include optimizations. However, with Windows 10 any optimization that remove “Windows Apps” will only work if run in the OS layer because otherwise the app removal does not work because the apps are integrated with the Windows Store and the store can only be modified in the OS layer. Recently Citrix has developed an excellent Optimizer (CTXOE). This tool is highly recommend to use for optimizations as it applies them and it can also reverse most of them.

One last note that is very helpful, during your process of rebooting the platform layer after you join the domain logon once with a network user account, then reboot and logon next as administrator and delete the profile created. When the first network user logs on some system files must be updated and by following this procedure you will significantly speed up logons because these files will no longer need to be modified.


Here are the general best practices for creating a Platform layer for the most popular methods of provisioning:

PVS

  1. Install NVIDIA Drivers if using (Should configure the packaging machine with your NVIDIA profile before installing)
  2. Install the VDA
  3. Join the Domain
  4. Log on as a network user, reboot, logon as admin, delete network user profile
  5. Install hypervisor tools if using cross platform
  6. Install any SSO Software, Citrix Receiver if it wasn’t installed with the VDA and WEM if you are using it.
  7. Optionally run the App Layering Optimizer
  8. Reboot
  9. Install PVS Tools. Unselect the option to Launch Imaging Wizard, and reboot.
  10. Optionally run the Provisioning Services Device Optimization Tools
  11. Finalize

The App Layering Optimizer should be run in the Platform Layer for any last-minute specializations. However, it should run before the PVS Target Software. The Target Software should be the last thing you install. Normally, PVS will run the Device Optimization Tools as the last step when imaging, but that step does not run in App Layering. If you don’t run the Device Optimization Tools, some important PVS-specific settings (like disabling Active Directory machine account password changes) might not be made.

MCS

  1. Install NVIDIA Drivers if using (Should configure the packaging machine with your NVIDIA profile before installing)
  2. Install the VDA
  3. Join the Domain
  4. Log on as a network user, reboot, logon as admin, delete network user profile
  5. Install hypervisor tools if using cross platform
  6. Install any SSO Software, Citrix Receiver if it wasn’t installed with the VDA and WEM if you are using it.
  7. Reboot
  8. Finalize

Horizon View

  1. Install NVIDIA Drivers if using (Should also configure the packaging machine with your NVIDIA profile before installing)
  2. Install the View Agent
  3. Join the Domain
  4. Log on as a network user, reboot, logon as admin, delete network user profile
  5. Install hypervisor tools if using cross platform
  6. Install any SSO Software
  7. Reboot
  8. Finalize

Please note, some nVidia devices/drivers may require special handling in the platform layer. See https://support.citrix.com/article/CTX241448 .

Related:

ShareFile Recycle Bin

Any files or folders that are deleted from your account will be moved to the Recycle Bin. Deleted files will remain in the recycle bin for a brief period. Files in your recycle bin do not count toward your storage limits.

Important

  • It is not possible to recover a file after 45 days. If you delete a file from the Recycle Bin before the end of this 45 day period, your file cannot be recovered.
  • Only Employee users may access the Recycle Bin.

Folder Recycle Bin

Every ShareFile folder has a Recycle Bin you can use to view recently deleted items, as well as restore items if needed. Folder Recycle Bin access requires the Admin permission on the specific folder. To restore an item deleted by someone else, access the Folder where the deleted file was stored.

  1. At the Folder menu, select More Options.
  1. Select Recycle Bin from the list of options.
  2. To restore a file in your Folder Recycle Bin, check the box beside the appropriate file
  3. Click the Restore button. The item will be restored to its original location within the folder.

View Another User’s Recycle Bin

Viewing another user’s Recycle Bin requires the following permissions:

Without the above permissions, you will not be able to see the “Access Recycle Bin” button in the screenshot below.

To view another user’s Recycle Bin:

  1. People > Browse Employees
  2. Access the desired user’s profile page, then, under Actions > Folder & Activity:, click View Folders and Activity Logs.
  1. Under Folder Access, click Access User’s Content.
  1. Select Recycle Bin.

Related:

  • No Related Posts

Citrix Hypervisor Export Running VM – Export snapshot to file

Find the VM that you want to backup: xe vm-list

Snapshot the VM, see https://docs.citrix.com/en-us/xencenter/7-1/vms-snapshots-take.html

Find the snapshot to export by listing snapshots and their corresponding VMs: xe snapshot-list params=uuid,name-label,snapshot-of

Set the snapshot to be exportable: xe snapshot-param-set is-a-template=false uuid=<snapshot uuid>

Export the snapshot to a file: xe vm-export uuid= filename=<snapshot uuid>

Later, it can be imported: xe vm-import filename=<path> preserve=true force=true sr-uuid=<uuid> (xe sr-list to find the sr uuid)

Related:

  • No Related Posts

How to configure MSS when using EDT on networks with non-standard MTU

Create UDPStackParameters registry key, which is missing by default:

HKCUSOFTWARECitrixICA ClientEngineConfigurationAdvancedModulesUDPUDPStackParameters

User-added image


If using Receiver for Windows 4.7 / 4.8 / 4.9 / 4.9 CU1 / 4.9 CU2 / 4.9 CU3:

There is a legacy issue in these Receivers for Windows where OutbufLength, when passed in an ICA file, is ignored.

Even if the registry value is modified to “*”, meaning accept everything from the ICA file, the ICA file setting is still ignored.

For this to work, in addition to creating the “UDPStackParameters” key as mentioned above, it is also necessary to modify the OutbufLength value in the registry and set it to the desired value determined above (1480 in the example):

Related:

  • No Related Posts

Hotfix XS71ECU2004 – For XenServer 7.1 Cumulative Update 2

Who Should Install This Hotfix?

This is a hotfix for customers running XenServer 7.1 Cumulative Update 2.

Note: This hotfix is available only to customers on the Customer Success Services program.

Information About this Hotfix

Component Details
Prerequisite None
Post-update tasks Restart the XAPI Toolstack
Content live patchable** No
Baselines for Live Patch N/A
Revision History

Published on Mar 15, 2019

** Available to Enterprise Customers.

Issues Resolved In This Hotfix

This hotfix resolves the following issues:

  • If you attempt to reboot a Windows VM from XenServer at the same time as you attempt to reboot the Windows VM from within the VM, the reboot can fail with the following error: “You attempted an operation on a VM that needed to be in state ‘Running but was in state ‘Halted’.
  • Scheduled metadata backups can fail intermittently when the pool backup metadata VDI gets full. The default size of the pool backup metadata VDI has been increased to 500MiB.
  • A VM taking more than 30 seconds to shut down no longer leads to “Domain stuck in dying state after 30s.”
  • While applying a hotfix to a pool, if XAPI restarts on a pool member, it detaches the hotfix update from all hosts in the pool as part of clean-up operations. This can cause the hotfix to fail to apply to other pool members.

Installing the Hotfix

Customers should use either XenCenter or the XenServer Command Line Interface (CLI) to apply this hotfix. As with any software update, back up your data before applying this update. Citrix recommends updating all hosts within a pool sequentially. Upgrading of hosts should be scheduled to minimize the amount of time the pool runs in a “mixed state” where some hosts are upgraded and some are not. Running a mixed pool of updated and non-updated hosts for general operation is not supported.

Note: The attachment to this article is a zip file. It contains the hotfix update package only. Click the following link to download the source code for any modified open source components XS71ECU2004-sources.iso. The source code is not necessary for hotfix installation: it is provided to fulfill licensing obligations.

Installing the Hotfix by using XenCenter

Choose an Installation Mechanism

There are three mechanisms to install a hotfix:

  1. Automated Updates
  2. Download update from Citrix
  3. Select update or Supplemental pack from disk

The Automated Updates feature is available for XenServer Enterprise Edition customers, or to those who have access to XenServer through their XenApp/XenDesktop entitlement. For information about installing a hotfix using the Automated Updates feature, see the Applying Automated Updates in the XenServer documentation.

For information about installing a hotfix using the Download update from Citrix option, see Applying an Update to a Pool in the XenServer documentation.

The following section contains instructions on option (3) installing a hotfix that you have downloaded to disk:

  1. Download the hotfix to a known location on a computer that has XenCenter installed.
  2. Unzip the hotfix zip file and extract the .iso file
  3. In XenCenter, on the Tools menu, select Install Update. This displays the Install Update wizard.
  4. Read the information displayed on the Before You Start page and click Next to start the wizard.
  5. Click Browse to locate the iso file, select XS71ECU2004.iso and then click Open.
  6. Click Next.
  7. Select the pool or hosts you wish to apply the hotfix to, and then click Next.
  8. The Install Update wizard performs a number of update prechecks, including the space available on the hosts, to ensure that the pool is in a valid configuration state. The wizard also checks whether the hosts need to be rebooted after the update is applied and displays the result.
  9. Follow the on-screen recommendations to resolve any update prechecks that have failed. If you want XenCenter to automatically resolve all failed prechecks, click Resolve All. When the prechecks have been resolved, click Next.

  10. Choose the Update Mode. Review the information displayed on the screen and select an appropriate mode.
  11. Note: If you click Cancel at this stage, the Install Update wizard reverts the changes and removes the update file from the host.

  12. Click Install update to proceed with the installation. The Install Update wizard shows the progress of the update, displaying the major operations that XenCenter performs while updating each host in the pool.
  13. When the update is applied, click Finish to close the wizard.
  14. If you chose to carry out the post-update tasks, do so now.

Installing the Hotfix by using the xe Command Line Interface

  1. Download the hotfix file to a known location.
  2. Extract the .iso file from the zip.
  3. Upload the .iso file to the Pool Master by entering the following commands:

    (Where -s is the Pool Master’s IP address or DNS name.)

    xe -s <server> -u <username> -pw <password> update-upload file-name=<filename>XS71ECU2004.iso

    XenServer assigns the update file a UUID which this command prints. Note the UUID.

    b8992e46-3131-11e9-b455-4fc310f582d8

  4. Apply the update to all hosts in the pool, specifying the UUID of the update:

    xe update-pool-apply uuid=b8992e46-3131-11e9-b455-4fc310f582d8

    Alternatively, if you need to update and restart hosts in a rolling manner, you can apply the update file to an individual host by running the following:

    xe update-apply host=<host> uuid=b8992e46-3131-11e9-b455-4fc310f582d8

  5. Verify that the update was applied by using the update-list command.

    xe update-list -s <server> -u root -pw <password> name-label=XS71ECU2004

    If the update is successful, the hosts field contains the UUIDs of the hosts to which this patch was successfully applied. This should be a complete list of all hosts in the pool.

  6. The hotfix is applied to all hosts in the pool, but it will not take effect until the XAPI service is restarted on all hosts. On the console of each host in the pool beginning with the master, enter the following command to restart the XAPI service:

    xe-toolstack-restart

    Note: When this command is run on the Pool Master, XenCenter will lose connection to the pool. Wait for 30 seconds after losing connection, and then reconnect manually.

  7. Use the update-pool-clean command to remove the update files from all hosts in the pool. This command frees up space on shared storage and does not uninstall the update.

    xe update-pool-clean uuid=b8992e46-3131-11e9-b455-4fc310f582d8

Files

Hotfix File

Component Details
Hotfix Filename XS71ECU2004.iso
Hotfix File sha256 047506fbe1bba202634c237bf3f69ac3f81949c4fa1e6092d9b4f34a7c5dbe8d
Hotfix Source Filename XS71ECU2004-sources.iso
Hotfix Source File sha256 ab6cdc7b609b22f316108a3519c94332040ac6b15f90e48b8a98cb6a4a43ccbe
Hotfix Zip Filename XS71ECU2004.zip
Hotfix Zip File sha256 e7fbb0d10891679aff088d021a90c6c2e77366c7329ad96fccff1b6c2ffa45c1
Size of the Zip file 36.25 MB

Files Updated

xapi-core-1.14.47-1.x86_64.rpm
xapi-tests-1.14.47-1.x86_64.rpm
xapi-xe-1.14.47-1.x86_64.rpm
xenopsd-0.17.13-1.el7.centos.x86_64.rpm
xenopsd-xc-0.17.13-1.el7.centos.x86_64.rpm
xenopsd-xenlight-0.17.13-1.el7.centos.x86_64.rpm

More Information

For more information, see XenServer Documentation.

If you experience any difficulties, contact Citrix Technical Support.

Related:

  • No Related Posts