Error “Could not update master user list” while saving the LDAP Configuration on Xenmobile server

Unable to save LDAP configuration and getting Error “Could not update master user list”

For sample logs :

2017-08-21T09:21:30.411-0700 | 3811F15F6AE686BC | INFO | http-nio-14443-exec-11 | com.citrix.cg.identity.ldap.LdapManager | Given baseDN ‘dc=global,dc=example,dc=com’is valid:true

2017-08-21T09:21:30.921-0700 | 3811F15F6AE686BC | ERROR | http-nio-14443-exec-11 | com.citrix.xms.oca.imil.service.impl.MasterUserListServiceImpl | Could not update Master User List.

com.citrix.xms.oca.imil.exception.IMILException: Invalid input data in Group base DN

or

error:User ” bind failed with domain ‘global.avaya.com’ Reason:Xxx.yyy.zzz.ddd

From the :3269 – We can see the global catalog is rejecting the configuration.

or

In XenMobile Server logs you will come across the following error messages:

2015-12-30T13:20:27.476+0100 | BFEA67E3D920C0B3 | ERROR | http-nio-14443-exec-1 | com.citrix.xms.oca.imil.service.util.LDAPUtils | Check LDAP details validation fails:javax.naming.CommunicationException: simple bind failed: svw-ads01.hbz.local:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetat sun.security.ssl.Alerts.getSSLException(Alerts.java:192)Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetat sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)2015-12-30T13:20:27.478+0100 | BFEA67E3D920C0B3 | ERROR | http-nio-14443-exec-1 | com.citrix.xms.oca.imil.service.util.LDAPUtils | Error in inputvalidation:com.citrix.xms.oca.imil.exception.InputDataValidationException: simple bind failed: svw-ads01.hbz.local:636at com.citrix.xms.oca.imil.service.util.LDAPUtils.checkMasterUserList(LDAPUtils.java:424)2015-12-30T13:20:27.479+0100 | BFEA67E3D920C0B3 | ERROR | http-nio-14443-exec-1 | com.citrix.cg.bo.spring.impl.InternalUserListServiceImpl | Input Data validation Failed in updateMasterUserList: Please upload the certificate before enable secure connection for LDAP2015-12-30T13:20:27.482+0100 | BFEA67E3D920C0B3 | ERROR | http-nio-14443-exec-1 | com.citrix.xms.oca.imil.service.impl.MasterUserListServiceImpl | Failed to update Master User List to ZDMcom.citrix.xms.oca.imil.exception.IMILException: Please upload the certificate before enable secure connection for LDAP

Related:

Studio shows “Error: Failed to validate the Central Configuration Service location. You do not have sufficient permissions to administer this Site using Studio.”

Procedure:

1. Use the following PowerShell commands to find the SID of the user account currently in use on the machine where Studio is installed:

$objUser = New-Object System.Security.Principal.NTAccount(“<DomainUserName>”)

$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])

$strSID.Value

2. Check if the SID found in step 1 matches with the SID(s) contained in the DAS.Administrator table of the XenApp/XenDesktop Site Database in the SQL server

Perform below steps to find the SID stored in the database:

– Open SQL Management studio >> Connect to SQL server instance

– Expand Databases>> [SiteDatabase] >> Tables >> DAS.Administrators

– Right click on DAS.Administrators > Select Top 1000 Rows.

This will display the SIDs of the Administrator objects configured for the Site.

If the SIDs do not match, then it means that the user account currently in use on the machine where Studio is installed is not a Citrix Administrator account and does not have sufficient permissions to administer the XenApp/XenDesktop Site using Studio.

In that case you need to login in the server with a user account that is a Citrix Administrator.

You can use the following PowerShell commands to find what user account or AD object belongs the SID(s) found in the DAS.Administrators table (Step 2) of the Site Database in the SQL server to then login on the server using that account:

$objSID = New-Object System.Security.Principal.SecurityIdentifier `

(“<SID in question>”)

$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])

$objUser.Value

In the case that the SIDs match, then it means that the SID of the Citrix Administrator account is corrupted in the database. In that case you will have to delete the SID.

Related:

Error “Windows cannot verify the digital signature for this file referencing unirsd.sys

When trying to edit a layer or pblish an image with any Elastic Layering option turned on (basically, any operation where our filter drivers are involved), the machine will have a boot failure, referencing File: Windowssystem32DRIVERSunirsd.sys, Status: 0xc0000428, Info: Windows cannot verify the digital signature for this file.

Boot failure

This may also be related to a warning attempting to run setup_x64.exe to initially install the drivers on a new Gold Image, complaining also about unirsd.sys, saying “Windows requires a digitally signed driver.” You can ignore this warning and continue with the installation, but when you go to create layers, you will see the boot failure above.

Installer error

Related:

How to Grant XenApp & XenDesktop Access to Your Azure Subscription

In this document we will explore different ways of granting XenApp & XenDesktop access to your Azure subscription. It describes how to connect to Azure Resource Manager in XenApp & XenDesktop using Subscription Scope Service Principals and includes a detailed description of the authentication process.

Azure Service Principals

Support for Azure Resource Manager (ARM) is encapsulated in a component known as the ARM Plugin and it is a standard feature of XenApp & XenDesktop. In order to provision machines in Azure, the ARM Plugin must be granted access to your Azure subscription via a service principal that has been assigned permissions to the relevant Azure resources. A service principal serves the same basic purpose as a user account: it provides the ARM Plugin with an Azure Active Directory identity; credentials for authentication and permissions on Azure resources. Just like user accounts, service principals are configured using Role Based Access Control (RBAC).

Depending on how permissions are defined, we classify service principals as:

  1. Subscription Scope Service Principals; or
  2. Narrow Scope Service Principals

Subscription Scope Service Principals

Subscription Scope Service Principals have Contributor permissions on all resources in the subscription which makes them easy to create and manage. In fact, Citrix Studio automates the process of creating Subscription Scope Service Principals or they can be created manually in PowerShell. Another benefit is that they allow the ARM Plugin to create Azure Resource Groups and completely automate the management of resources. The disadvantage is that the ARM Plugin may have permissions to resources in the subscription that are unrelated to the resources that the ARM Plugin is tasked with managing.

Using the Contributor role allows the ARM Plugin to create, delete, read and write all resources in the subscription, but permissions do not extend to objects in any Azure Active Directory nor are Subscription Scope Service Principals allowed to grant other users or service principals access to resources.

Narrow Scope Service Principals

Narrow Scope Service Principals allow the ARM Plugin access to a limited set of resources defined by you. Azure requires subscription scope permissions in order to create resource groups and the ARM Plugin is therefore unable to create resource groups when using Narrow Scope Service Principals. This means that, in addition to the service principals, you are required to provide a pool of resource groups for each catalog into which machines are to be provisioned.

At the time of writing, Citrix Studio does not support creating Narrow Scope Service Principals or catalogs using Narrow Scope Service Principals so both of these tasks must be performed using PowerShell. However, once a catalog has been created, it can be managed like any other catalog in Studio including adding and deleting machines. If at some point you wish to use an existing Narrow Scope Service Principal with a new pool of resource groups, you must explicitly add permissions to the service principal using PowerShell.

Defining Your Azure Subscription Access Requirements

The techniques and examples in the following sections are intended to demonstrate various options in a reasonably simple manner and may need to be adapted to your particular circumstances. Here are some guidelines to help you define your requirements:

Consider using a Subscription Scope Service Principal if:

  • you want the simplest management experience.
  • you want to avoid using PowerShell and manage everything in Citrix Studio.
  • your Azure subscription is dedicated to a single XenApp & XenDesktop service.
  • you are doing a proof of concept XenApp & XenDesktop installation.
  • your XenApp & XenDesktop administrators have contributor access at Azure subscription scope.

Consider using a Narrow Scope Service Principal if:

  • your Azure subscription is hosting multiple unrelated services.
  • your Azure administrators have different subscription permissions depending on their role.
  • your company has security standards that require access control at a fine-grained level.
  • you have an existing process for creating Narrow Scope Service Principals

It is also worth noting that you can create “child” subscriptions that are billed as part of your primary subscription and refer to the default Azure Active Directory in your primary subscription. This provides another mechanism for controlling access to unrelated resources.

Planning a Narrow Scope Service Principal Catalog

The key decision that must be made before creating a Narrow Scope Service Principal catalog is deciding how many resource groups are required to host the initial and future number of virtual machines. Due to a limitation in the Machine Creation Services that drives the ARM Plugin, it is not possible to add resource groups once a catalog has been created.

Citrix recommends provisioning one catalog per resource group pool.

The ARM Plugin will create the necessary infrastructure in each resource group consisting of storage accounts, security groups, network interfaces, virtual machines etc. Storage accounts are created on demand as needed when and if machines are added to the catalog. This means that the size of a catalog can grow to an upper limit set by the size of the resource group pool and Azure subscription quotas. Once a storage account has been created, it is not deleted until the catalog is deleted. Since any virtual machine can be deleted, it is possible to end up with empty storage accounts. This however is rare because virtual machines tend to be randomly distributed over the available storage accounts so machines have to be tediously selected by inspecting the content of storage accounts in order to deliberately empty a storage account.

Azure limits the number of virtual machines in a resource group to 800, but the ARM plugin uses a different measure. A standard Azure disk has a limit of 500 IO operations per second (IOPS) and a standard storage account has an IOPS limit of 20,000. For this reason, the ARM Plugin provisions no more than 40 machines to a storage account. This limit is currently applied to both standard and premium storage. In addition, the ARM Plugin will create no more than 19 storage accounts in a resource group.

The basic formula for calculating the number of resource groups based on the maximum number of machines is therefore:

Number of resource groups = ceiling( Maximum number of machines / (40 * 19) )

The ARM Plugin assumes that it has exclusive use of the resource group pool, i.e., there should be no user created resources in any of the specified resource groups.

Basics of Azure Role Based Access Control (RBAC)

Access to Azure resources are granted by assigning an RBAC role to a service principal at a certain scope where scope can be a subscription, a resource group or a specific resource. Resources are arranged in a containment hierarchy and the permissions defined by the role apply to all resources below the scope where it is applied. For example, a role applied on a subscription is applied to all resources in the subscription and a role applied to a resource group is applied to all resources contained in the resource group.

An implication of the Azure resource hierarchy is that only service principals with subscription scope permissions are allowed to create resource groups. This is not ideal because it prevents applications like the ARM Plugin from creating resource groups on demand to logical group and manage resources unless they have broad permissions on the full subscription.

Azure has a large selection of built in roles and additionally supports the definition of custom roles.

Refer to the Microsft KB Article for more information on Custom Roles in Azure RBAC.

Creating a Subscription Scope Service Principal

This example shows how to create a Subscription Scope Service Principal. The details can subsequently be to used to create an Azure connection in Citrix Studio by electing to use an existing service principal or an Azure connection can be created manually in PowerShell.

param(

[string]$applicationName = “SubscriptionScopeSP”,

[Parameter(Mandatory=$true)][string]$applicationPassword,

[Parameter(Mandatory=$true)][string]$subscriptionId

)

$application = New-AzureRmADApplication -DisplayName $applicationName -HomePage “https://localhost/$applicationName” `

-IdentifierUris “https://$applicationName” -Password $applicationPassword

New-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId

# Wait for the service principal to become available

Start-Sleep -s 60

New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId `

-scope “/subscriptions/$subscriptionId”

Write-Host (“Application ID: ” + $application.ApplicationId)

Creating a Basic Narrow Scope Service Principal

In this section we will create the simplest possible Narrow Scope Service Principal where permissions are assigned at the resource group scope.

The ARM Plugin needs permission to the following resources:

  1. The master image VHD

  2. The virtual network for the machines

  3. The resource groups into which the machines are to be provisioned.

To simplify the script, we make an assumption that Contributor access can be granted at resource group scope. This means that the ARM Plugin will have contributor permissions on the resource group where the image VHD is stored, the resource group that contains the virtual network and the resource group pool where the machines are to be provisioned.

param(

[string]$applicationName = “BasicNarrowScopeSP”,

[Parameter(Mandatory=$true)][string]$applicationPassword,

[Parameter(Mandatory=$true)][string]$subscriptionId,

[Parameter(Mandatory=$true)][string[]]$resourceGroups

)

$application = New-AzureRmADApplication -DisplayName $applicationName -HomePage “https://localhost/$applicationName” `

-IdentifierUris “https://$applicationName” -Password $applicationPassword

New-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId

# Wait for the service principal to become available

Start-Sleep -s 60

New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Network-Usage-Reader -ServicePrincipalName $application.ApplicationId `

-scope “/subscriptions/$subscriptionId/”

foreach ($rg in $resourceGroups)

{

New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId `

-scope “/subscriptions/$subscriptionId/resourcegroups/$rg”

}

Write-Host (“Application ID: ” + $application.ApplicationId)

Creating a Narrow Scope Service Principal using Custom Roles

Azure comes with a large set of built in RBAC roles and we made use of the Contributor role in the previous section. As noted, that gave the ARM Plugin slightly broader permissions than strictly required. In this section, we will define a custom role and further tighten access. If desired, access can be completely locked down using additional custom roles and applying roles directly to the image and network resources.

The required permissions are subject to change as we continue to improve the ARM Plugin and add new features. We will use the permissions listed below and define a custom role for granting access to the virtual network and the master image at the resource group scope.

The master image VHD

For catalog creation:

  • Microsoft.Storage/storageAccounts/read
  • Microsoft.Storage/storageAccounts/listKeys/action

For Future Citrix Studio support:

  • Microsoft.Resources/subscriptions/resourceGroups/read

The virtual network for the machines

  • Microsoft.Network/virtualNetworks/read
  • Microsoft.Network/virtualNetworks/subnets/join/action

The resource groups into which the machines are to be provisioned

We could create another custom role with the following permissions, but to keep the example simple, we will continue to use the Contributor role for the machine resource groups. These resource groups should not contain any resources not created by the ARM plugin and using the contributor role makes it less likely that changes to the ARM plugin will require changes to the service principal.

  • Microsoft.Compute/virtualMachines/*

  • Microsoft.Network/networkInterfaces/*

  • Microsoft.Network/networkSecurityGroups/*

  • Microsoft.Resources/deployments/*

  • Microsoft.Resources/subscriptions/resourceGroups/read

  • Microsoft.Storage/storageAccounts/*

  • Microsoft.Storage/storageAccounts/listKeys/action

XenApp & XenDesktop Custom Access Roles

We create a new custom role by first defining it in JSON:

{ "Name": "Citrix-Custom-Reader", "Description": "Grants access to Citrix XenDesktop images and virtual networks.", "Actions": [ "Microsoft.Storage/storageAccounts/read", "Microsoft.Storage/storageAccounts/listKeys/action", "Microsoft.Network/virtualNetworks/read", "Microsoft.Network/virtualNetworks/subnets/join/action" ], "NotActions": [ ], "AssignableScopes": [ "/subscriptions/<YOUR-SUBSCRIPTION-ID>" ]}

We can now create the role by referencing the JSON definition:

New-AzureRmRoleDefinition -InputFile citrix-custom-reader.json

Finally, we can use our new custom role when creating a service principal:

param([string]$applicationName = "NarrowScopeSP",[Parameter(Mandatory=$true)][string]$applicationPassword,[Parameter(Mandatory=$true)][string]$subscriptionId,[Parameter(Mandatory=$true)][string[]]$machineResourceGroups,[Parameter(Mandatory=$true)][string]$imageResourceGroup,[Parameter(Mandatory=$true)][string]$networkResourceGroup)$application = New-AzureRmADApplication -DisplayName $applicationName -HomePage "https://localhost/$applicationName" `-IdentifierUris "https://$applicationName" -Password $applicationPasswordNew-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId# Wait for the service principal to become availableStart-Sleep -s 60New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Network-Usage-Reader -ServicePrincipalName $application.ApplicationId `-scope "/subscriptions/$subscriptionId/"foreach ($rg in $machineResourceGroups){ New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId/resourcegroups/$rg"}New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Custom-Reader -ServicePrincipalName $application.ApplicationId `-scope "/subscriptions/$subscriptionId/resourcegroups/$imageResourceGroup"New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Custom-Reader -ServicePrincipalName $application.ApplicationId `-scope "/subscriptions/$subscriptionId/resourcegroups/$networkResourceGroup"Write-Host ("Application ID: " + $application.ApplicationId)

Creating XenApp & XenDesktop Azure Connections

While it is reasonable to create a XenApp & XenDesktop Azure connection in Citrix Studio using an existing service principal, it is equally reasonable to create the connection in PowerShell.

Here is an example of creating a connection in Powershell. This is particulary the case as, at the time of writing, Studio does not support creating catalogs using connections based on a narrow scope service principal.

param([string]$connectionName = "AzureConnection",[Parameter(Mandatory=$true)][string]$applicationId,[Parameter(Mandatory=$true)][string]$applicationPassword,[Parameter(Mandatory=$true)][string]$subscriptionId,[Parameter(Mandatory=$true)][string]$subscriptionName,[Parameter(Mandatory=$true)][string]$tenantId)Add-PsSnapin Citrix*$customProperties = @"<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Property xsi:type="StringProperty" Name="AuthenticationAuthority" Value="https://login.microsoftonline.com/"/> <Property xsi:type="StringProperty" Name="ManagementEndpoint" Value="https://management.azure.com/"/> <Property xsi:type="StringProperty" Name="StorageSuffix" Value="core.windows.net"/> <Property xsi:type="StringProperty" Name="TenantId" Value="$tenantId"/> <Property xsi:type="StringProperty" Name="SubscriptionId" Value="$subscriptionId"/> <Property xsi:type="StringProperty" Name="SubscriptionName" Value="$subscriptionName"/></CustomProperties>"@$connection = New-Item -ConnectionType "Custom" -CustomProperties $customProperties -HypervisorAddress @("https://management.azure.com/") `-Path @("XDHyp:Connections$connectionName") -Persist -PluginId "AzureRmFactory" -Scope @() `-SecurePassword (ConvertTo-SecureString -AsPlainText -Force $applicationPassword) -UserName $applicationIdNew-BrokerHypervisorConnection -HypHypervisorConnectionUid $connection.HypervisorConnectionUid

At this point you need to add resources to the connection which again can be done in Studio or in PowerShell.

Creating XenApp & XenDesktop Catalogs

The following example uses the Citrix PowerShell Snap-Ins to create a XenApp & XenDesktop catalog.

As Narrow Scope Service Principals do not allow the ARM Plugin to create resource groups, we must:

  1. Create a pool of resource groups.
  2. Assign the service principal permissions on all the resource groups in the resource group pool.
  3. List each resource group in the resource group in a custom property when creating the provisioning scheme.

The custom property is named ResourceGroups and the value is a comma separated list of resource group names. An example of how to define this custom property is shown below.

Note that only resource groups that are intended for machines should be listed in the custom property. The resource group(s) where the image and/or virtual network is located should not be included. If they are specified, the ARM plugin will attempt to provision machines into those resource group which will likely cause some unintended behaviour.

In this example, machines will be provisioned in two resource groups named xd-sales-1 and xd-sales-2.

Add-PsSnapin Citrix*# The hosting unit name is the name of the Azure connection resources that should be used for this catalog$hostingUnitName = "AzureHostingUnit"$domain = "citrix.local"$controllerAddress = ("ddc." + $domain)$adminAddress = ($controllerAddress + ":80")$catalogName = "catalog-name"$network = "network-resource-group.resourcegroupnetwork-name"$subnet = "subnet-name"$serviceOffering = "Standard_A4"$template = "image-resource-group.resourcegroupimagestorage.storageaccountimages.containerimage-name.vhd"$customProperties = @"<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Property xsi:type="StringProperty" Name="StorageAccountType" Value="Standard_LRS" /> <Property xsi:type="StringProperty" Name="ResourceGroups" Value="xd-sales-1, xd-sales-2" /></CustomProperties>"@$identityPool = New-AcctIdentityPool -AdminAddress $adminAddress -AllowUnicode -Domain $domain ` -IdentityPoolName $catalogName -NamingScheme "vm-#" -NamingSchemeType "Numeric" -Scope @()$brokerCatalog = New-BrokerCatalog -AdminAddress $adminAddress -AllocationType "Random" -IsRemotePC $False ` -MinimumFunctionalLevel "L7_9" -Name $catalogName -PersistUserChanges "Discard" -ProvisioningType "MCS" -Scope @() ` -SessionSupport "MultiSession"Write-Host $brokerCatalog$provScheme = New-ProvScheme -AdminAddress $adminAddress -CleanOnBoot -CustomProperties $customProperties ` -HostingUnitName $hostingUnitName -IdentityPoolName $catalogName ` -MasterImageVM "XDHyp:HostingUnits$hostingUnitNameimage.folder$template.vhd" ` -NetworkMapping @{"0"="XDHyp:HostingUnits$hostingUnitNamevirtualprivatecloud.folder$network.virtualprivatecloud$subnet.network"} ` -ProvisioningSchemeName $catalogName -Scope @() -SecurityGroup @() ` -ServiceOffering "XDHyp:HostingUnits$hostingUnitNameserviceoffering.folder$serviceOffering.serviceoffering"Write-Host $provSchemeSet-BrokerCatalog -AdminAddress $adminAddress -Name $catalogName -ProvisioningSchemeId $provScheme.ProvisioningSchemeUidAdd-ProvSchemeControllerAddress -AdminAddress $adminAddress.com -ControllerAddress $controllerAddress -ProvisioningSchemeName $catalogName

At this point you can refresh the catalog page in Citrix Studio, add machines and manage machines as with any other catalog.

User-added image

Related:

Error: “Cannot Complete Your Request” When Connecting to StoreFront

Where to Start Troubleshooting

In order to identify what steps need to be followed when troubleshooting the error, you will have to identify where the issue is occurring by performing the following 3 tests:

User-added image

  1. Do you get the error when connecting directly to the StoreFront server? If yes, start troubleshooting from step 1.

Perform this test by adding the StoreFront base URL and the StoreFront server local IP address to the Hosts file of the internal machine you will be testing with. For more information about editing the Hosts file refer to the following article – How to use a Hosts file to test a site that uses host headers on an Intranet.

  1. Do you get the error connecting through a load balancer? If yes, start troubleshooting from step 13.

From the testing machine open the command prompt and ping the StoreFront base URL FQDN. The FQDN should resolve to the IP address of your load balancer. If it does not then verify your DNS settings or the Hosts file on the local machine.

  1. Do you get the error only when connecting through your NetScaler Gateway? If yes, start troubleshooting from step 19.

From the testing machine open the command prompt and ping the NetScaler Gateway FQDN. The FQDN should resolve to the IP address of your NetScaler Gateway. If it does not then verify your DNS settings or the Hosts file on the local machine.

Troubleshooting Steps

Troubleshooting the Storefront Server Connection

User-added image
  1. On the StoreFront server open the StoreFront MMC > Server Group > Base URL and confirm that the StoreFront base URL has a full FQDN and not a Host name or IP address. To change the base URL refer to Citrix Documentation – Configure server groups

  2. Open the Command Prompt on the StoreFront server and ping the StoreFront base URL. The base URL should resolve to the StoreFront server local IP address. Add an entry to the Hosts file on the StoreFront server to make sure that the base URL resolves to itself.

    Note: StoreFront 3.x has the loopback feature, for configuration guidance refer to Citrix Blog –
    What’s New in StoreFront 3.0.

  3. Open the IIS console on the StoreFront server click the server > Server Certificates > double-click the certificate that you are using for StoreFront.

    Make sure that the certificate on the StoreFront server is not expired.

    Make sure the “Certificate Issued To” name matches the StoreFront base URL.The certificate should also contain a private key. If using a SAN certificate, make sure the StoreFront Base URL is listed under the subject alternative names. Wildcard certificates are also supported.

View the Certification Path tab on the certificate and confirm that all the Intermediate and Root certificates are properly installed in order to complete an SSL Handshake. For more information regarding certificates see article – Server Certificates.

  1. Open the IIS console on the StoreFront server and go to Sites > Default Web Site > Bindings. Make sure there is a binding for HTTPS over port 443 with a certificate that matches the StoreFront Base URL assigned to it. Leave the host name field empty. For more information regarding adding a binding refer to article – SSL Bindings

  1. On the IIS console go to Application Pools and confirm that Citrix Delivery Services Authentication app pool is configured to use .NET CLR Version 4.0. If the app pool is not using .NET 4.0, refer to Microsoft article – Specify a .NET Framework Version for an Application Pool (IIS 7) and restart the Citrix Credential Wallet Service.

  1. Open the StoreFront MMC > Authentication and make sure user name and password is enabled. To enable it click Add/Remove Methods > check the User Name and Password box > click OK.

  1. On the StoreFront MMC, click Receiver For Web > Choose Authentication Methods and make sure that User Name and Password is also enabled. To enable it, check the User Name and Password box and click OK.

  1. On the StoreFront server open the Services console and confirm the following:

  • Verify if the Citrix Default Domain Services Windows Service is running. By default, the startup type will be set to Automatic (Delayed Start). Confirm the service is running after the StoreFront server reboots.
  • Verify if the Citrix Credential Wallet Service is running. By default, the startup type will be set to Automatic (Delayed Start). Confirm the service is running after the StoreFront server reboots.
  1. Telnet from the StoreFront server to the domain controller over ports 88 and 389 to confirm they are open. For more information refer to article CTX139039 – Communication Ports for StoreFront 2.0.

  1. In Active Directory confirm the User Logon Name matches the User Logon Name (pre-Windows 2000). For more information refer to article – User Name Formats.

  1. Verify if antivirus firewall is installed on the StoreFront server. Disable the antivirus firewall and test the connection. Exclude the StoreFront ports within the antivirus firewall. For more information refer to the following links:

  1. Confirm that you are not using a proxy when testing the connection to StoreFront. If you are receiving the error when the proxy is in place refer to the proxy configuration.

Troubleshooting the Load Balancer

User-added image

  1. If you are load balancing StoreFront, then Open the command prompt from the testing machine and ping StoreFront base URL FQDN to confirm if it is resolving to the load balancing IP address. Open a browser on the testing machine and go to the StoreFront base URL to confirm the correct certificate is bound to the load balancing VIP.

  2. Confirm that the certificate bound to the load balancer is properly linked to the root and intermediate on NetScaler. For more information refer to article CTX128539 – How to Link an Intermediate Certificate to the Server Certificate on NetScaler/NetScaler Gateway.

  1. On the NetScaler load balancing VIP confirm that the Persistence is set to SOURCEIP and the Method is set to LEASTCONNECTION. For more information see refer to Citrix Documentation – About Persistence

  1. View the Services bound to the load balancing VIP and go to Settings > Header to confirm X-Forwarded-For is specified. To add it, edit the load balancer Service settings > Settings > Check Client IP > Add X-Forwarded-For to the Header textbox.

  1. Confirm TLS 1.0 is enabled under the SSL Parameters on the load balancing VIP and load balancing services. StoreFront 3.0.1 and prior versions do not support TLS 1.1 and TLS 1.2.

  1. On NetScaler go to under System > Settings > Configure Basic Features > Integrating caching and confirm that it is disabled.

Troubleshooting NetScaler Gateway

User-added image

  1. Open the StoreFront MMC > NetScaler Gateway > Select the Gateway you configured > Change General Settings > NetScaler Gateway URL and confirm external users are using the same URL for external access on the browser and Citrix Receiver.

  1. On the StoreFront server open the Command Prompt > Ping NetScaler Gateway FQDN and confirm it resolves to the correct gateway IP address.

  1. On the StoreFront server open a browser and navigate to the NetScaler Gateway URL to confirm there are no certificate errors. For more information refer to article CTX128539 – How to Link an Intermediate Certificate to the Server Certificate on NetScaler/NetScaler Gateway.

  1. Open the StoreFront MMC and go to NetScaler Gateway > select the gateway you are configuring > Change General Settings > Subnet IP address and remove it. The subnet IP address is only needed if you are using a NetScaler 9.x firmware or under certain use cases concerning GSLB as mentioned here. Specifying the VIP of a NetScaler Gateway (not SNIP) may be required if the StoreFront implementation supports multiple NetScaler Gateways with the same URL (such as the same URL being used internally and externally, but resolving to different NetScaler Gateways) along with unique callback URLs. That being said, only certain use cases and the use of NetScaler 9.x firmware necessitate populating the Subnet IP address field which should otherwise be left blank.

  1. On the same Change General Settings window from step 22, confirm the Logon Type is set to Domain if using LDAP authentication on the NetScaler Gateway. For more information to Citrix Documentation – Configure NetScaler Gateway connection settings.

  1. On the same Change General Settings window from step 22, confirm the Callback URL FQDN listed resolves to the NetScaler Gateway VIP by using the ping command on the Command Prompt from the StoreFront server. Once you verify it resolves to the correct gateway IP address, open a browser on the StoreFront server and navigate to it and confirm there are no certificate errors.

  1. On the NetScaler Gateway VIP go to Authentication > LDAP Policy > Edit Server and confirm the following settings:

    For more information refer to – User authentication.

    1. Server Logon Name Attribute: sAMAccountName
    2. Group Attribute: MemberOf
    3. Sub Attribute Name: CN
    4. Security Type: PlainText
    5. Keep SSO Name attribute: blank (sometimes having some attributes set as SSO name attribute cause SSO failure if not a multi domain environment)
  2. Go to the Session Policy bound to the NetScaler Gateway VIP > Edit Profile > Client Experience > Single Sign-on to Web Applications and confirm that it is checked. Then go to the Published Applications tab > Single Sign-on Domain and confirm the correct domain is specified.

    Note: For domain users in a multi-domain environment, add the SSO Name Attribute field as UserPrincipalName under LDAP Policy configuration and uncheck the Single Sign-on Domain for the authentication on the session profile.

  1. Check the NetScaler Gateway VIP > SSL Parameters > TLSv1 and confirm that it is enabled. StoreFront 3.0.1 or prior does not support TLS 1.1 and TLS 1.2. Make sure the Callback VIP has TLS 1.0 enabled.

  1. On the NetScaler Gateway VIP verify the “No Rewrite Clientless” policy on the NetScaler Gateway VIP is configured to use the expression TRUE.

  1. On the NetScaler go to Security > Application Firewall and confirm the feature is disabled. If it is enabled bypass the policies during testing. If successful re-enable the Application Firewall in learning mode,so it can Learn and Allow the necessary StoreFront traffic. For more information refer to article CTX117003 – How to Configure Learning Parameters on the Application Firewall.

Other Scenarios

  1. If you only get the error when accessing the server for first time after an idle time or running an antivirus scan then disable the File Change Notification feature on the IIS server where StoreFront is running.

    User-added image

For .NET 4.0 and Lower

Find app bitness from appPool advance settings.

64 bit: To enable this hotfix, you must add the following DWORD value of 1 at the following registry key:

HKLMSoftwareMicrosoftASP.NETFCNMode

32 bit: If you are running a 32-bit process on an x64-based system, add the following DWORD value of 1 at the following registry key:

HKLMSOFTWAREWow6432NodeMicrosoftASP.NETFCNMode

For .NET 4.5 and Higher

Note: Starting with the Microsoft .NET Framework 4.5 and later versions, FCNMode can be configured by using the httpRuntime settings as follows:

<httpRuntime fcnMode=”Disabled”/>

For more information refer to the following blogs:

ASP.NET File Change Notifications, exactly which files and directories are monitored?

ASP.NET Performance issue: Large number of application restarts due to virus scanning

  1. Is there an error in the Event Viewer for “An unexpected error occurred storing the credentials” (Event ID 8) or “An error occurred during authentication” (Event ID 3)?

    User-added image

    If so, run the following PowerShell command:

    cd ‘C:Program FilesCitrixReceiver StoreFrontScripts’

    $certlist = @(Get-DSCertificate)[0] | where { $_.Subject -Match “Credential Wallet Replication Identity” }

    foreach ( $cert in $certlist ) { Add-DSCertificateKeyReadAccess $cert “NT ServiceCitrixCredentialWallet” }

    And then restart the Citrix Credential Wallet Service.

  2. If any timeout settings have been modified manually through the web.config file located under C:inetpubwwwrootCitrixAuthenticationweb.config then make sure the SessionState timeout field is set to the default value of 5.

    For example – <sessionState mode=”InProc” cookieName=”Citrix_AuthSvc” timeout=”5″ />

  3. If using Microsoft NLB as a load balancer; it has been reported that using Microsoft “NLB” type load balancing with unicast mode might trigger this issue. Switching to multicast mode helps resolve this issue.

    User-added image

  1. When a single FQDN configuration is used then refer to the following Citrix Documentation to verify if any step is skipped or misconfigured – Create a single Fully Qualified Domain Name (FQDN) to access a store internally and externally. You can potentially get the cannot complete request error.

  1. If you were configuring Optimal Gateway for launching applications, make sure the configuration on the web.config file has a proper closing HTML tag. For more information regarding Optimal Gateway configuration then refer to Citrix Documentation – Configure optimal NetScaler Gateway routing for a store.

  1. If you experience the error after publishing a new application or customizing an application’s icon, check the event viewer on the StoreFront server and look for the following errors:

    Event 1 = There was an error during a resources List request. System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

    The remote server returned an error: (500) Internal Server Error.

    Event 7 = Unhandled exception thrown for route “DazzleResources/List” System.ArgumentException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.

    The workaround is to go to Studio > Delivery Groups > Applications > view the properties of the application recently added > Delivery > Application Icon > Change and choose from any of the Citrix default icons.

  2. If you received this error during implementation of ADFS, Azure and FAS then consider the following – SAML authentication does not use a password and only uses the user name. Also, SAML authentication only informs users when authentication succeeds. If SAML authentication fails, users are not notified. Since a failure response is not sent, SAML has to be either the last policy in the cascade or the only policy.

    So when you configure SAML authentication along with LDAP authentication on NetScaler, use the following guidelines – if SAML is the primary authentication type, then disable authentication in the LDAP policy and configure it for group extraction. Now, bind the LDAP policy as the secondary authentication type.

  3. If this error occurs after an upgrade, then go to IIS > Default Site > StorenameWeb > Default Files > delete default.html and recreate default.html file manually.

  4. Disable self-recycling for the following application pools:

    Citrix delivery services authentication

    Citrix delivery services resources

    Citrix receiver for web

  5. Verify if all the required network is reachable from NetScaler Gateway. Routing table should also look complete.

  6. Examine the logs on NetScaler Gateway to verify if it is blocking any cookies, in case expression for cookie header is used in the session policy.

  7. If the issue occurs specially after an HA failover of NetScaler Gateway, then verify the time on both the nodes. The time on nodes should be in sync. Examine the ntpd process and sync the time if the nodes are not in sync.

User-added image

Related:

How to analyze log for Android for Work Unenroll Process

Using the default logging on the XenMobile server, we can follow the unenroll flow in the debug.log to confirm the process completed successfully.

Steps and process flow explanation:

The admin initiates the unenroll flow from XenMobile Server.

2018-01-23T11:08:44.518-0800 | 1905A0F8D1DC7441 | INFO | http-nio-14443-exec-10 | com.citrix.controlpoint.rest.AndroidWorkResource | AndroidWorkResource.deleteEnterprise() – Attempting to initiate delete enterprise flow

2018-01-23T11:08:44.560-0800 | 1905A0F8D1DC7441 | INFO | http-nio-14443-exec-10 | com.citrix.controlpoint.service.impl.AWConfigServiceImpl | AWConfigServiceImpl.deleteEnterprise() – marking enterprise as deleted.

2018-01-23T11:08:44.560-0800 | 1905A0F8D1DC7441 | INFO | http-nio-14443-exec-10 | com.citrix.controlpoint.rest.AndroidWorkResource | AndroidWorkResource.deleteEnterprise() – Admin successfully initiated delete enterprise flow

XenMobile server goes into a state where any Android For Work related task will also check whether the enterprise is valid by calling Google APIs. If the enterprise is valid, that means the admin has not completed the XenMobile Tools portion of the unenroll flow. If the enterprise is not valid, that means the admin has completed the XenMobile Tools portion.

After the check in which it is discovered that the enterprise is not valid, the cleanup process will begin.

2018-01-23T11:10:00.39-0800 | 1905A0F8D1DC7441 | ERROR | http-nio-14443-exec-9 | com.citrix.android.aw.apis.enterprises.EnterpriseImpl | getEnterprise: statusCode=403

2018-01-23T11:10:00.41-0800 | 1905A0F8D1DC7441 | INFO | http-nio-14443-exec-9 | com.citrix.android.aw.workers.AndroidWorkImpl | AndroidWorkImpl.deleteUsersForEnterprise() – 0 users were deleted while deleting enterprise

Enabling Advanced logging

If you are experiencing issues with this feature, it is recommended to enable TRACE level logging for the com.citrix.android.aw logger.

User-added image

This will provide more details in the logging, including the setting of the flag indicating that the admin has initiated the unenroll process, the checks for whether the enterprise is valid, and more.

Related:

  • No Related Posts

Adjusting XenApp/ XenDesktop Machine Agent Configuration in Large Citrix Environment

If you are using Citrix SCOM MPs and plan to monitor VDI performance (machine and/or session) in your XenApp/XenDesktop environment, this article will assist you to configure SCOM XAXD Machine Agent service, which is used for VDI performance data collection.

Background

In large Citrix environments, Citrix MPXAXD Machine Agent might not be able to collect all VDI performance data, using default configuration.

This issue usually happens when too short VDI data collection period and/or too short data collection cycle are configured, causing VDI session to times out, or, due to large number of VDIs, not all VDIs are processed within default sampling interval (5 minutes).

A missing VDI performance data can be identified in SCOM by:

  • Running VDI related reports and observing gaps in presented data

    User-added image

  • Executing Check Requirements and Configuration for Citrix MPXAXD Machine Agent task and having high number of Check failed VDIs in the Citrix MP Machine Agent – Runtime section

    User-added image

Fine-tuning MPXAXD Machine Agent Configuration

When a MPXAXD Machine Agent is installed, a new sub-key, HKEY_LOCAL_MACHINESOFTWAREComtradeXenDesktop MP Machine Agent, containing various application settings is added to the Windows Registry.

User-added image

Beside the default settings, there is a set of user-invisible registry values (refer to the image above), which can be used to improve MPXAXD Machine Agent data collection performance with one of the following optimizations:

  • Modify VDI connection timeout period

  • Increase data collection interval

  • Adjust number of threads collecting performance data

  • Narrow the set of collected performance data

Modify VDI connection timeout period

Citrix MPXAXD Machine Agent uses WinRM protocol to create a session to connect to VDI and collect performance data. WinRM session timeout period is set to 10 seconds by default and it might not be long enough to collect required performance data. In order to increase timeout interval create WinRMSessionTimeout registry value (REG_DWORD) under HKEY_LOCAL_MACHINESOFTWAREComtradeXenDesktop MP Machine Agent and set new data (e.g. 30) for maximum time interval to collect single VDI data sample, in seconds.

Note: In order to apply new settings, restart Citrix MPXAXD Machine Agent service.

In case that a value for SamplingInterval is changed, the following SCOM workflows, responsible for storing VDI data into SCOM DW (Data Warehouse), must override their IntervalSeconds parameter to match new data collection interval, i.e. 600:

  • Publish Session Performance (x) (Performance DW) (where 1 < x < 12)
  • Publish Server OS Machine Performance (x) (Performance DW) (where 1 < x < 3)

Note: All instances of above rules must be either enabled or disabled.

Adjust number of threads collecting performance data

The main reason for changing a number of threads is to utilize all CPU cores and reduce the time needed for VDI data collection. Since a thread creation is expensive operation, there must be a high number of VDIs (1000+) to be contacted and collected data from (a lot of I/O operations), in order to overcome the initial cost of creating the threads.

To increase the parallelism there are two registry values under HKEY_LOCAL_MACHINESOFTWAREComtradeXenDesktop MP Machine Agent that can be adjusted to achieve the best performances:

  • DiscoveryThreadsMin – represents the number of requests to the thread pool that can be active concurrently. All requests above that number remain queued until thread pool threads become available.
  • DiscoveryThreadsMax – is the maximum number of asynchronous I/O threads in the thread pool.

DiscoveryThreadsMin and DiscoveryThreadsMax are REG_DWORDs with default values set to 32.

Narrow the set of collected performance data

A VDI performance data collection consists of three phases, each of which can be excluded to reduce the amount of collected data (lowers resource consumption) and satisfy customers VDI monitoring needs. These phases are:

  • Machine monitoring – collect performance data from Server OS machines
  • Server sessions – collect Server OS session performance data
  • Desktop sessions – collect Desktop OS session performance data

In order to narrow the scope of VDI data collection, the MonitorType registry data value (REG_DWORD) should be set under HKEY_LOCAL_MACHINESOFTWAREComtradeXenDesktop MP Machine Agent to any of the following basic options

  • 0 – collects all performance data
  • 1 – collects only machine monitoring data
  • 2 – collects only Server OS session data
  • 4 – collects only Desktop OS session data

or as a combination of them (bitmask), for example:

3 (11) –> & 2 (01 & 10– Server OS machines and Server OS sessions are monitored)

5 (101) –> 1 & 4 (01 & 100 – Server OS machines and Desktop OS sessions are monitored)

Note: VDI performance monitoring offers insight into the VDI health of the XenApp/XenDesktop environment, impact of VDI configuration changes, performance and capacity trends and it can help you determine future environment capacity requirements.

Related:

Citrix Receiver – Fall back from TCP to UDP fails / displays SSL Error when Disconnecting and Reconnecting session via NetScaler

If HDX Adaptive Transport Policy set to Preferred on DDC and when attempting to connect to an Application or Desktop using Citrix Receiver for Windows 4.10 or Citrix Receiver for Mac 12.8 or Citrix Receiver for iOS 7.5 and above, you may encounter below issues:

  • Session will get disconnect if initial connection established using TCP protocol
  • Session launch may fail by displaying SSL error when you try to Disconnect and Reconnect a session

Citrix has identified this behavior with Receiver for Windows 4.10, Receiver for Mac 12.8, Citrix Receiver for iOS 7.5 and above, and with specific NetScaler firmware versions having HDX Insight or SmartControl functionality enabled. The following table covers the NetScaler builds, which are affected.

Release train Affected Builds
11.1 51.x, 52.x, 53.x, 54.x, 55.x, 56.x, 56.x

Related:

ShareFile Employee Permissions

For a list of Admin-level permissions, click here or skip to the bottom of this article.

For E-Signature related permissions, click here to skip to that section of this article.

How to Manage Permissions

  • People > Manage Users (or Browse Employees or Browse Clients)
  • Browse or search for your user. Click the user or the Manage icon on the right to open the user profile.
  • Modify permissions as needed, then Save.

Default Employee Permissions

When creating a new employee, the following permissions are granted by default. You can modify these settings during the user creation process.

Note: A grayed setting indicates a permission that the creating user does not have access to or is not permitted to give to others – therefore, they cannot grant that permission to another user.

User Access


Basic Information:

Date Created, Email Address, First Name, Last Name, Company name.

Notifications

Modify the user’s default Notification frequency settings.

Default Email Language

Modify the user’s default email notification language.

Bandwidth Limit

You may select a maximum monthly bandwidth allowance for the employee. This limit will prevent the employee from personally uploading and downloading more data than you allow them. It will also apply to all of their folders, so that they may not share files with others more than you would like for them to. Note: Employee bandwidth limits can also affect clients that the employee works with by limiting how much they may download from the employee’s folders. This is used by some accounts where employee use may need to be limited to prevent bandwidth overages.

Authentication

Whether the customer is utilizing ShareFile Credentials or Two-Step Verification.


User Access:

General

Change their password

If a user may change their password, they can use the ‘Forgot Password’ link on the login screen if they ever forget the password. If this is not marked, they will need to contact an employee who can manage employee permissions for help logging in.


Access Personal Settings

In personal settings a user can manage their name, company name and avatar. They will be able to update or change their password on this page if they have the permission to change their password.


Access company account permissions

This will allow the user to access and change the account wide permissions. For a full detailed list of the options they will be able to access, see article here.


Files and Folders

Create root-level folders in “Shared Folders”

Employee users may be allowed to set up their own folders in the “Personal Folders” section on the account. Some accounts choose to allow employees to set up their own folders within the “Shared Folders” page if they will need to set up their own individual employees or clients. If you have a main administrator who would prefer to set up and manage the folder structure for all users, this can be disabled. Please note that employee users may also be able to create subfolders within folders where they have ‘Upload’ access.

Use personal File Box

The File Box is a personal storage space where employees may store files for a limited period of time. This space is not generally a collaborative or shared space, although some users may be given access to see other employee’s File Boxes. If you do choose to take away a user’s access to the File Box, they will not be able to use any email plugin tool or add files from their computer when creating a Share message or Link.


Be added to file drops

This will only be available if File Drop is enabled on your account. This will allow users who create new file drops to list this employee as a contact that clients may select to send files to through a form.


Access other users’ File Boxes and Sent Items

Allowing the employee access to the File Box and Sent Messages of other users allows them to check into what other users have stored outside of the primary folder structures and what has been sent from the account.

E-Signature

Depending on your account features, you may see options for E-Signature users in this section. If you don’t have this feature and would like to learn more about this, please contact our sales team to see how you can get this on your account – 1-800-441-3453


Send document for e-signature

*Uses one e-signature license*: This setting provides an employee user the ability to send documents for an electronic signature. Without this permission the user will not see the options “Send for Signature” or “Sign Yourself”.

View all e-signature documents:

This permission will provide the user access to all documents sent for e-signature.

Manage e-signature templates:

This permission will provide the user the ability to manage all e-signature templates.


People

Manage Clients

This will allow the employee to see the People tab in the navigation bar and to add new users to the account. They will also be able to edit settings for any clients that they create. Note: Editing a client user’s email address requires the Manage Employees permission.


Manage Employees

Employees may be allowed to create other employee users on the account and edit employee user access. This permission is also required for editing a client user’s email address that the user did not create themselves. Please note that this only allows employees to grant other employee users the Basic permissions that they themselves have on the system. To grant another user Admin Privileges, you must have the Delegate admin privileges to other employee users permission.


Delegate admin privileges to other employee users

Allow the user to grant Admin Privileges to other employees. Employees will only be able to allow others privileges that they themselves have been granted.

Edit the shared address book

The Shared Address Book is available to employee users on the account so that they may quickly and easily pull up contact information for users on the account. If this is checked, the employee will be able to add users to the Shared Address Book to allow others to see their contacts on the system.


Share distribution groups

If this permission is enabled, the employee user will be able to create a Shared Distribution group.


Edit other users’ shared distribution groups

When setting up a new Distribution Group, users will have the option to share the group with all employees. If this permission is enabled, the employee user will be able to add more users to a group that has been created on the system and shared with others.

Manage Super User Group membership

Allow the user to add or remove employee users from the Super User Group. Members of the Super User Group are added to all folders on the account (including personal folders) with admin level access.

Company Account Info

Edit account appearance

Allow the user to configure account branding and appearance settings.


Access reporting

Reports on many aspects of account use including general activity and folder access are available in the Settings > Admin Settings > Company Account Info > Reporting section to employees with this permission enabled.


View notification history

Allow the user to view the history of email messages sent from ShareFile, including system notifications.

Configure Single Sign-On Settings

Allow the user to configure SSO settings in Admin Settings > Security > Login


Billing

View/edit billing information

Allow the user to view and modify billing information for the account. This permission also authorizes the user to contact ShareFile Support for billing assistance.


Request Plan Changes

Allow the user to submit plan changes in the Admin Settings section of the account.


View receipts and billing notifications

The Receipts & Billing Notifications link in the Admin Settings > Billing section will allow any user with this permission enabled to download copies of any receipt or invoice for the account.

*You may or may not see the below settings on your user page. These settings will display only if you have the feature enabled on your plan type.


Advanced Preferences

Manage folder templates

Enabling this setting will allow the employee to see available Folder Templates in the Admin section and to edit or make new folders. This is generally recommended to employees who will be setting up or assisting with managing many client folders.


Manage remote upload forms

Allow the user to create and manage Remote Upload Forms in Admin Settings > Advanced Preferences.

Manage file drops

This permission allows the user to see the File Drops link in the Admin section and to create links that allow users to upload files to a specific employee of their choosing.

Connectors

Create and manage Connectors

This permissions grants the user the ability to create and manage new Connectors. This permission is only available to ShareFile users on select plans.

Create Network Share Connectors

This permissions grants the user the ability to create and manage new Network Share-type Connectors. This permission is only available to ShareFile users on select plans.

Create SharePoint Connectors

This permissions grants the user the ability to create and manage new Sharepoint-type Connectors. This permission is only available to ShareFile users on select plans.

StorageZones

Create and manage Zones

This permissions grants the user the ability to manage which zone a folder’s data is housed within. This permission is only available to ShareFile users on select plans.

Select StorageZone for root-level folders

In order to change another user’s default storage location, membership to the Super User Group is required. This permission is only available to ShareFile users on select plans.

Admin Permissions
Access company account permissions
Create root-level folders in “Shared Folders”
Access other users’ File Boxes and Sent Items
Manage employee users
Delegate admin privileges to other employee users
Manage Super User Group
Access reporting
View notification history
Configure single sign-on settings
View/edit billing information
Request plan changes
Manage folder templates
Manage remote upload forms
Manage file drops
Create and manage connectors
Create and Manage Zones

Related:

MCS created VMs do not get new Image after Catalog Update

Tradução automática

Эта статья была переведена автоматической системой перевода и не был рассмотрен людьми. Citrix обеспечивает автоматический перевод с целью расширения доступа для поддержки контента; Однако, автоматически переведенные статьи могут может содержать ошибки. Citrix не несет ответственности за несоответствия, ошибки, или повреждения, возникшие в результате использования автоматически переведенных статей.

Related:

  • No Related Posts