These are some ideas on how to troubleshoot StoreFront (SF) issues
Open a Power Shell (PoSh) command prompt
Type: Import modules.ps1
If SF MMC console is not launching 1st validate that PoSh execution level is set to unrestricted. The command to check that is:
Set-ExecutionPolicy unrestricted
To reset the configuration of StoreFront, run the following command:
Clear-DSConfiguration (This should remove all the services and set your SF console into initial setup mode. Warning: Make you have a snapshot of the server since you will lose all prior configuration done on the server! This will allow you to create a new deployment or join the server to an existing SF cluster.
StoreFront runs with minimum of. 1.5 Gb of RAM. Validate if RAM is not an issue when opening a MMC console.
If SF doesn’t have Internet access for some security reason, you can disable Assembly Verification using PoSh commands as follows:
- Add PS Snapin Citrix.DeliveryServices.Frameworks.commands
- Set-DSAssemblyVerification $false
Troubleshooting issues Opening the SF MMC
If you are having issues opening the MMC console, make sure to capture the error details by running DebugView while opening the console and looking for any errors generated in the MMC process
Troubleshooting Issues when trying to join a SF server to a Server Group or Cluster
If having issues joining a SF server to a SF server group, check the following
- Validate the date and time and the time zone of the server joining the group
- Make that the machine(s) joining the group is(are) in the same version of SF
- Validate that all network ports are open between the machines in the group
- Validate that each SF server can resolve each server’s hostname and/or disable NetBios on the NIC
- On item, 3 above keep in mind that SF servers use TCP port 808 to communicate among themselves. They also may use any otherramdom port for different types of communication. Therefore keep the firewall disabled on those servers
- Confirm that NT Service\CitrixConfigurationReplication and NT Service\ClusteService are both part of the Local Administrators Group
- Make sure the user account used to join the server to the group must have security privileges to be able to create self-signed certificates. You can open the Local Security Policy to validate that
If none of these suggestions work, there are some additional tools that can be used to locate the root causes of SF malfunction:
– Storefront Verbose Logs (CTX139592)
– Wireshark traces from the Storefront server (make sure it is decrypted; some companies encrypt the traces generated by Wireshark traces)
– Debug View logs on the Storefront server
– Always collect timestamp, username affected, IP addresses of client device and SF server. The event viewer logs will list username and timestamp, so if you have that info it will facilitate further investigation
– Event Viewer logs (Application, Citrix Delivery services)
Manually Removing Server from a Group
To manually remove a server from a server group, make sure to backup the feature.config file from the C:\Programs Files\Citrix\Receiver StoreFront\ClusterManagement
Then, open the feature.config file and remove the entries that state the following two items: member and thumbprint:
<member hostname=”[hostname]” servername=”[hostname]”
certficateThumbprint=”[40-character long thumbprint-Id]” />
Additionally, remove the server from CitrixClusterMembers Group Local Security Group under “Computer Management”
Finally, make a backup of the Citrix.DeliveryServices.PeerResolution.ServiceHost.exe.config, located in the C:\Programs Files\Citrix\Receiver StoreFront\Services\PeerNameResolution folder
Edit the config file and remove the line stating:
<add name=”[serverHostname]” url=”net.tcp://badserver/Citrix/PeerResolverService/Replicaton” />
Save the file
Troubleshooting Propagation Issues
- Make sure that the Citrix Configuration Replication Service has started in all servers in the server group
- Validate that the NT Service\CitrixConfigurationReplication account is included in the Local Administrators Group in the SF server (check under Computer Mgmt\ Groups\Administrators Group)
- Make an attempt to set the CitrixConfigurationReplication Service properties under the Logon Tab to logon as the Local System Account or identity by selecting the radio button next to it (be default it is set to network service account)
- Reboot the SF server to take the new permission settings or restart all Citrix services
- Validate the IIS is using the same disk, drive and “inetwwwroot” folderi in all SF Servers
- Check the Event Viewer logs for errors and look under C:\Programs Files\Citrix\Receiver StoreFront\Admin\trace for the traces logs for the Configuration Replication Serviceand serach for any exceptions in the traces logs. Erros that could prevent replication could include but not limited to folders already and need to be created (so delete the folder and try again), or IIS application exists that need to be created (to fix this remove the IIS application in question and try it again); If a Windows service exists that needs to be created after a previous failed attempt (us the sc delete command)
Troubleshooting Logon Issues
The Credential Wallet service is in charge of managing the logon flow which includes engaging LDAP in AD for domain controller validation and engaging the Delivery Controller for Resources Enumeration
When troubleshooting login issues, check under Services.msc (Services Console) if the Credential Wallet service and the default domain service are running. If they are in stopped state, make an attempt to start both services or try to restart them, if they are already running. Note that SF versions 2.5 and older had issues with the Credential Wallet Service, so make sure the version of SF installed is SF 3.12 (for LTSR deployments) or SF 3.16 (for Current release deployments) . This is true as of January 2019.
Troubleshooting Receiver for Web Login Failures
One of the most infamous login failure messages in SF is the “Cannot Complete your Request” message
The causes may vary. Citrix has created a very good KB article listing possible causes.
The article number is CTX207162. It is one of the most well written articles by Citrix. It contains 36 possible root causes for the error that encompasses StoreFront by itself and also the errors caused by the Citrix Gateway and by a Load Balancer when used in conjunction with SF.
Always check if the version of StoreFront is the latest like 3.12 (for LTSR deployments) or SF 3.16 (for Current release deployments) as described earlier. Older version of SF have a bug in the Citrix Credentail Wallet. Restarting the Credential Wallet service and the Default Domain services is always a good troubleshooting step.
Troubleshooting Other SF issues
These are great questions to asking when troubleshooting ANY SF related issues:
- Can you authenticate via SF?
- Can you enumerate the applications and desktops?
- Are the applications and Desktops able to launch?
- Are you using any Citrix Gateway solutions?
Knowing the answer for those three questions is a great starting point. You can focus on the components associated with one of three steps above, which will help simplify the troubleshooting steps
Example:
- Authentication Issues. Check the Credential Wallet and the Default Domain service in the SF server. Also check to make sure the AD Domain Controller(s) is/are up and running when the issue occurs. These two components are usually common cause of authentication failures. Validate that ports 389 and 636 are open between the SF servers and the Domain Controllers. Check the Event viewer logs in the SF server(s) for errors.
- Enumeration Issues. Check the list of Deliver Controllers in the SF console. Make sure all the Delivery Controllers are up and running. Check certificates, Also check AD DC’s. Check ports that communicate between SF and the Delivery Controllers. Finally check event viewer logs (always important).
- Resources launching issues. Check communication with the VDA’s or VDI’s. Check on the end point device for errors, Check the version of Citrix Receiver or Citrix Workspace App, check if the ICA file was properly downloaded into the VDA (The SF server is responsible for generating the ICA file and sending it to the end point device. Withou ICA file the resource WILL NOT be launched). Check the Event Viewer logs!
- If Citrix Gateway is in use. Isolating the issue further may be necessary. For example. Does the behavior occur when using the SF server ipaddress or hostname directly? Can you modify the hosts file in the SF server and enter the ip address of the local SF server for the FQDN of the URL? You can use Fiddler or Debug View or SF Verbose Logs along with Debug View to see the HTTP headers for hints of the issue. The HTTP header should show if the connection is coming from a Citrix Gateway connection. The Event viewer logs in SF should also provide hints whether or not Citrix Gateway is involved.
We hope this helps!
Apttech's Blog 