How to Configure Email-Based Account Discovery for Citrix Receiver.

Configuring Email-Based Account Discovery

1 Add DNS Service Location (SRV) record to enable email based discovery

During initial configuration, Citrix Receiver can contact Active Directory Domain Name System (DNS) servers to obtain details of the stores available for users. This means that users do not need to know the access details for their stores when they install and configure Citrix Receiver. Instead, users enter their email addresses and Citrix Receiver contacts the DNS server for the domain specified in the email address to obtain the required information.

To enable Citrix Receiver to locate available stores on the basis of users’ email addresses, configure Service Location (SRV) locator resource records for Access Gateway or StoreFront/AppController connections on your DNS server. If no SRV record is found, Citrix Receiver searches the specified domain for a machine named “discoverReceiver” to identify a StoreFront/AppController server.

You must install a valid server certificate on the Access Gateway appliance and StoreFront/AppController server to enable email-based account discovery. The full chain to the root certificate must also be valid. For the best user experience, install either a certificate with a Subject or Subject Alternative Name entry of discoverReceiver.domain, or a wildcard certificate for the domain containing your users’ email accounts.

To allow users to configure Citrix Receiver by using an email address, you need to add a SRV record to your DNS zone.

  • Log in to your DNS server
  • In DNS > Right-click your Forward Lookup Zone
  • Click on Other New Records

  • Scroll down to Service Location (SRV)
  • Configuring Email-Based Account Discovery
  • Choose Create Record

  • Click in the Service box and enter the host value _citrixreceiver
  • Click in the Protocol box and enter the value _tcp
  • In the Host offering this service box, specify the fully qualified domain name (FQDN) and port for your Access Gateway appliance (to support both local and remote users) or StoreFront/AppController server (to support users on the local network only)

Note: Your StoreFront FQDN must be unique and different from the Access Gateway virtual server FQDN. Using the same FQDN for StoreFront and the Access Gateway virtual server is not supported. Citrix Receiver requires that the StoreFront FQDN is a unique address that is only resolvable from user devices connected to the internal network. If this is not the case, Receiver for Windows users cannot use email-based account discovery.

You can use nslookup to check if the SRV record is configured correctly in DNS:

  • Open command prompt
  • Type nslookup
  • Type “set type=srv“
  • Type “_citrixreceiver._tcp.mycompany.com“

The response from your external DNS should be something like this:

_citrixreceiver._tcp.mycompany.com SRV service location:

priority = 0

weight = 100

port = 443

svr hostname = vpndemo.mycompany.com

To allow users to configure Citrix Receiver from a remote location you need to add the StoreFront/AppController URL Session Profile of your Netscaler Access Gateway.

  • Log in to the Netscaler management console
  • In the Access Gateway node, create a new Session Profile or open an existing Session Profile for Native Receivers.
  • Click the Published Applications tab
  • Next to Account Services Address, click Override Global and then enter the StoreFront/AppController URL. (Example: https://< StoreFront/AppController URL>/Citrix/Roaming/Accounts)

  • To make this work you have to allow Clientless Access to your Native Receiver Session Profile

  • Verify/Configure Native Receiver Session Policy to request the configured Native Receiver Session Profile

  • Bind the Session Policy to Netscaler Access Gateway Virtual Server.

4 End User Experience

When tries to access the Native Receivers, they just have to provide their email address to activate Receiver.

  • User access Citrix Receiver, provides his email address.

  • Receiver prompts user to enter his Active Directory credentials.

  • User is asked for the confirmation from the user to add the Store information into Receiver.

  • Upon confirmation from the user, store information is added on to Receiver.

  • User can subscribe to their apps from Receiver.

Related:

  • No Related Posts

“Server not found” error when Storefront has an underscore in the FQDN


This is caused by a limitation in the DNS characteres allowed by Windows DNS services. Underscore has a special role, used for SRV records. Although it’s accepted by the DNS servers, it;s nto a good recommendation as it can cause problem resolving the URLs.

DNS host names cannot contain the following characters:

  • comma (,)
  • tilde (~)
  • colon (:)
  • exclamation point (!)
  • at sign (@)
  • number sign (#)
  • dollar sign ($)
  • percent (%)
  • caret (^)
  • ampersand (&)
  • apostrophe (‘)
  • period (.)
  • parentheses (())
  • braces ({})
  • underscore (_)
  • white space (blank)

The underscore has a special role, as it is permitted for the first character in SRV records by RFC definition, but newer DNS servers may also allow it anywhere in a name. For more details, see: http://technet.microsoft.com/en-us/library/cc959336.aspx.

To resolve this problem, remove any underscore from the URL.

Related:

App Layering / Unidesk – Finding the KMS server

To determine what KMS server a machine would use by default, use nslookup (substituting the actual customer domain):

C:> nslookup -q=srv _vlmcs._tcp.domain.com

Server: dc001.domain.com

Address: 10.170.89.2

_vlmcs._tcp.domain.com SRV service location:

priority = 0

weight = 0

port = 1688

svr hostname = kms-srv2.domain.com

_vlmcs._tcp.domain.com SRV service location:

priority = 0

weight = 0

port = 1688

svr hostname = win8-kms-srv.domain.com

kms-srv2.domain.com internet address = 10.170.89.213

win8-kms-srv.domain.com internet address = 10.170.89.214

To see what KMS server has been cached on the current MM, you will need to look in the Registry. I believe that the user account mentioned here will always be the same, but in the worst case, search for keys named “DiscoveredKeyManagementServiceName”.

HKEY_USERSS-1-5-20SoftwareMicrosoftWindows NTCurrentVersionSoftwareProtectionPlatform55c92734-d682-4d71-983e-d6ec3f16059fae2ee509-1b34-41c0-acb7-6d4650168915

DiscoveredKeyManagementServiceName (REG_SZ)

Related:

7020663: Autodiscover: How Retain Connects to Your Exchange Mailboxes

The process for connecting to an Exchange mailbox was specified by Microsoft (see “Autodiscover for Exchange“). This article provides a general overview of the interaction between the Retain Worker and Autodiscover as well as tips on reading the Worker logs to better understand the information Retain is receiving from Autodiscover to help you troubleshoot issues.

General Overview

Exchange Archive Process Through Autodiscover

1. Retain Worker queries DNS to find the AD DS server.

2. DNS server returns the location.

3. Retain Worker queries AD for Autodiscover SCP records.

4. AD provides the Autodiscover URLs.

5. Retain Worker attempts to connect to the Autodiscover service on the CAS based on the URL it was provided. It finds the server through DNS.

6. Autodiscover connects Retain Worker to the EWS.

7. EWS connects Retain Worker the the user mailbox.

8. Exchange provides the mailbox data and passes it through EWS.

9. EWS passes the mailbox data to Retain Worker which passes the data to the Retain Server.


Autodiscover Process

In Retain version 3.x and 4.0, we would use the Autodiscover library provided by Microsoft; however, in some instances – due to configuration issues in the customer’s environment, this would cause lag time in connection with each mailbox, sometimes resulting in 2-minute delays for each mailbox. In Retain 4.0.1, we will use our own adaptation of the Autodiscover process, which has eliminated the delays. If our own process fails, then Retain tries the Microsoft Autodiscover library.

The order of which Autodiscover code gets used can be changed. See, “Changing the Autodiscover Mode“.

The Microsoft Autodiscover process has three phases, but only the first two are used if successful after phase 2:

PHASE 1: Define the Candidate Pool

This is the part where the client (Retain) has to locate the right Autodiscover server for the mailbox to which it is attempting to login. In the case of Retain, we are using the impersonation account you set up in Exchange for Retain to use (see Exchange Module Setup Instructions, “Preparatory Steps” section, steps 2 – 4).

1. It first looks in Active Directory Domain Services (AD DS) for a service connection point (SCP) object, which can redirect Retain to the Autodiscover server.

You can find your SCP record(s) in AD DS. However, you can also run the Get-ClientAccessServer cmdlet in an Exchange Management Shell by typing: Get-ClientAccessServer | fl

If it returns a value for “AutoDiscoverServiceInternalUri”, then an SCP record exists and it is pointing to one of the Autodiscover servers. If you have multiple client access servers (CAS), each should have its own SCP record and unique Autodiscover URL.

This allows Autodiscover requests to be routed to servers based on Active Directory sites. So, if the company is GWAVA and they have several sites, SCP might provide a number of Autodiscover servers:

https://orem.gwava.com/autodiscover/autodiscover.xml

https://
montreal.gwava.com/autodiscover/autodiscover.xml

https://
ahuas.gwava.com/autodiscover/autodiscover.xml

2. Next, it looks at the domain part of the user’s email address (for jdoe@gwava.com, gwava.com is the domain) and comes up with two Autodiscover standard endpoint URL forms using that domain.

Using jdoe@gwava.com, it comes up with:

https://gwava.com/autodiscover/autodiscover.xml

https://autodiscover.
gwava.com/autodiscover/autodiscover.xml

Now it has a compiled list of 5 potential Autodiscover servers:

https://orem.gwava.com/autodiscover/autodiscover.xml

https://
montreal.gwava.com/autodiscover/autodiscover.xml

https://
ahuas.gwava.com/autodiscover/autodiscover.xml

https://
gwava.com/autodiscover/autodiscover.xml

https://autodiscover.
gwava.com/autodiscover/autodiscover.xml

PHASE 2: Try each potential Autodiscover server

It goes through the list of potential Autodiscover servers trying to find the endpoint mailbox. It uses the first Autodiscover server that produces a successful connection. Retain uses the POX Autodiscover service as defined by Microsoft, so an HTTP POST with an Autodiscover request body.

If each of those potential Autodiscover server URLs fail, then we move onto phase 3.

PHASE 3:

Since the URLs gathered in Phase 1 failed during Phase 2, the Microsoft library next tries other alternatives.

1. Sends an unauthenticated GET request derived from the user’s email address in this format:

Using jdoe@gwava.com, it comes up with:

http://autodiscover.gwava.com/autodiscover/autodiscover.xml

This is not an SSL encapsulated request; however, if the server returns a 302 redirect response, we attempt to resend the Autodiscover request to the endpoint URL.

2. If step #1 fails, we try qurying DNS for an SRV record for the Autodiscover service. See also “Creating a DNS SRV Record for Exchange“.

Using jdoe@gwava.com, the record takes the form of _autodiscover._tcp.gwava.com. This query might return multiple records, but we only use records that point to an SSL endpoint and that have the highest priority and weight.

If it fails after completing all three phases, then Retain returns an error, “No Autodiscover/Endpoint found!” error.

TESTING CONNECTIVITY

Microsoft provides a connectivity tester utility. For more details, see https://support2.microfocus.com/kb/doc.php?id=7020687

LOG READING TIPS

The log will show the method it uses to discover Autodiscover. Note in the following example where it states “class=scp3”. In this case, the Autodiscover server was found through SCP. Retain’s logging changes over time, but here are some examples from a log in Retain 3.2:

09:18:02,899 AutoDiscover – The Autodiscover Server is in cache, so that’s good: url=https://[server DNS hostname]/autodiscover/autodiscover.xml,class=scp3

In the following example, the AutoDiscover server is found but the endpoint (or mailbox) could not be found. This means that Retain found AutoDiscover, but AutoDiscover did not provide a valid EWS URL for that mailbox. The reason for this issue is documented in the KB article, “AutoDiscover Errors on Some Mailboxes” (note: this occurred in Retain 3.1 and logging messages may have changed since then for this particular situation):

09:18:02,977 AutodiscoverFunctions – No EWSURL or ASURL in response request for jdoe@xyzcompany.com

09:18:02,977 AutodiscoverFunctions – This will mean we will fail to find an EWS service suitable for this user.

09:18:02,977 AutoDiscover – Not good. No good EWS URL returned… code=connectButNoUrl,payload=[null, -1]

09:18:02,977 ExchangeDredger – No Autodiscover/Endpoint found!

Here is a list of log messages from Retain 3.5 under various circumstances as noted:

Setup Issue: Retain Server’s Primary DNS Not the Same as the CAS Server(s)

2015-03-24 14:16:21,039 ERROR [RTWQuartzScheduler_Archive_Worker-1] com.gwava.retain.worker.rest.client.JobStatusTracker: Unable to send request to server.

org.springframework.web.client.HttpServerErrorException: 503 Service Unavailable

Setup Issue: Basic Authentication Not Enabled on Autodiscover, Impersonation User Password Expired or SRV Record was not setup correctly/missing.

2015-03-24 14:28:41,076 ERROR [RTWQuartzScheduler_Archive_Worker-6] com.gwava.utils.StandardErrorHandleStrategy: reportError: Exception during discover of SRVURLs :: com.gwava.ews.autodiscover.AutoDiscover.getEWSUrl:114 :: javax.naming.NameNotFoundException: DNS name not found [response code 3]; remaining name ‘_autodiscover._tcp.ad.gwavasupport.com’

Setup Issue: Basic Authentication Not Enabled on EWS (but Enabled on Autodiscover)

You will not even get this far for this error unless basic authentication is enabled on Autodiscover; otherwise, you get the error listed for when basic authentication is not enabled on Autodiscover (above). It does not even get to the point of logging in to EWS because it cannot get past authenticating to the Autodiscover service. So, again, if you get the following error, you know that basic authentication is enabled at least for Autodiscover; but, it is not enabled for EWS. The following are snippets of various lines in the Worker log that you’ll find under this error condition:

2015-03-24 14:32:15,453 INFO [RTWQuartzScheduler_Archive_Worker-8] com.gwava.ews.archiveimpl.process.ExchangeUser: discovered: https://exmail.ad.gwavasupport.com/EWS/Exchange.asmx

2015-03-24 14:32:27,199 ERROR [RTWQuartzScheduler_Archive_Worker-8] com.gwava.ews.archiveimpl.process.ExchangeArchiveFactory:

com.sun.xml.ws.client.ClientTransportException: The server sent HTTP status code 401: Unauthorized

2015-03-24 14:32:27,224 DEBUG [RTWQuartzScheduler_Archive_Worker-8] com.gwava.ews.archiveimpl.process.ExchangeArchiveFactory: EWS request failed (checkConnection). Will retry after 2 seconds

Related:

7019538: Creating a DNS SRV record for Exchange / O365 to solve autodiscover errors

Retain requests a connection to the Exchange autodiscover service, which runs on each Exchange client access server (CAS). See “Autodiscover: How Retain Connects to Your Exchange Mailboxes“.

If you only have a single domain in Active Directory (or if multiple domains, there is a trusted relationship between them), then all you have to do is add the Retain server to the domain to which the workstations belong that are running Outlook. Retain connects to EWS through autodiscover just like Outlook.

However, some customers have multiple Active Directory domains and trusts do not exist for various reasons. In such cases, SRV records are required.

Microsoft has a detailed article about the SRV record: Setting up a DNS SRV record


In simple terms:

  1. Go to the DNS Manager
  2. Expand Forward Lookup Zones
  3. Locate and right-click on the external DNS zone and choose Other New Records
  4. Click Service Location (SRV) and enter:

Service: _autodiscover

Protocol: _tcp

Port Number: 443

Host: [your mail host, e.g. mail.gwava.net, usually the AD domain forest found in AD Domains and Trusts on the MS AD server]

  1. Click OK

The Microsoft autodiscover library in Retain expects a URL along the lines of https://autodiscover.[your domain]/Autodiscover/Autodiscover.xml (e.g., https://autodiscover.xyzcompany.com/Autodiscover/Autodiscover.xml), which can be found in the worker log as it attempts to login by searching for “Discovered endpoint:” or “AutoDiscover”.

Related:

Process %1 (PID=%2). An LDAP search call returned a referral – Server=%3 Error code=%4. Base DN=%5, Filter=%6, Scope=%7.

Details
Product: Exchange
Event ID: 2394
Source: MSExchangeDSAccess
Version: 6.5.7596.0
Message: Process %1 (PID=%2). An LDAP search call returned a referral – Server=%3 Error code=%4. Base DN=%5, Filter=%6, Scope=%7.
   
Explanation

This Error event indicates that the Exchange server is unable to process Light-weight Directory Access Protocol (LDAP) requests through Directory Service Access (DSAccess) to query Active Directory information on domain controllers or global catalog servers.

This event may be caused because internal Domain Name System (DNS) servers are also configured as external servers on the domain controllers or global catalog servers. Since internal DNS servers are also configured as external DNS servers, LDAP response time may be slow and queries may return null data.

Note   Active Directory uses DNS as its domain controller location mechanism and leverages the namespace design of DNS in the design of Active Directory domain names.

This error could mean that LDAP read time and overall access to domain controllers from back-end and front-end Exchange servers is slow. Clients could therefore have slow e-mail access.

Note   Directory Service Access (DSAccess) is a shared API that is used by multiple components in Exchange Server 2003 to query Active Directory and obtain both configuration and recipient information. In addition, DSAccess maintains a cache that is used to minimize the load on Active Directory by reducing the number of Lightweight Directory Access Protocol (LDAP) requests that individual components send to Active Directory servers.

   
User Action

To resolve this error, do one or more of the following:

  • Set up an internal DNS server that Exchange can send LDAP requests to.

  • Check that DNS servers on domain controllers or global catalog servers have proper Service Location (SRV) locator resource records and are responding to SRV location requests.

Note   The SRV record is used to map the name of a service (in this case, the LDAP service) to the DNS computer name of a server that offers that service. In a Windows Server 2003 network, an LDAP resource record locates a domain controller.

For more information about verifying SRV records on DNS servers running Windows Server 2003, see Microsoft Knowledge Base article 816587, How to verify that SRV DNS records have been created for a domain controller.

Related:

Process (PID=). Domain controller was not found when DNS was queried for the service location (SRV) resource records for domain The query was for the SRV record for The following domain controllers were identified by the query:Common causes of this error include the following:- The DNS SRV records required to locate a domain controller for the domain are not registered in DNS. These records are registered with a DNS server automatically when a domain controller is added to a domain. They are updated by the domain controller at set intervals. This computer is configured to use DNS servers with following IP addresses:- One or more of the following zones do not include delegation to its child zone:For information about correcting this problem,

Details
Product: Exchange
Event ID: 2124
Source: MSExchangeDSAccess
Version: 6.5.6940.0
Component: Microsoft Exchange Directory Access Cache
Message: Process <process name> (PID=<process id>). Domain controller <distinguished name> was not found when DNS was queried for the service location (SRV) resource records for domain <distinguished name>The query was for the SRV record for <distinguished name>The following domain controllers were identified by the query:<name>Common causes of this error include the following:- The DNS SRV records required to locate a domain controller for the domain are not registered in DNS. These records are registered with a DNS server automatically when a domain controller is added to a domain. They are updated by the domain controller at set intervals. This computer is configured to use DNS servers with following IP addresses:<address>– One or more of the following zones do not include delegation to its child zone:<name>For information about correcting this problem, <text><text>
   
Explanation

This event occurs if Diagnostics Logging on the Topology category of DSAccess is set to Minimum for the server. This event indicates that the SRV records for the specified domain controller cannot be found. This event means that the domain controllers from the specified domain will not be used by DSAccess. As long as there is sufficient capacity in suitable domain controllers in other domains, mail flow will not be interrupted. However, it is recommended that this event be investigated and fixed as soon as possible. If the event contains the name of the local domain, topology discovery cannot be completed, and this will cause mail flow interruption. As mentioned in the text of the event, this is caused if the DNS SRV resource record is not registered in DNS.

   
User Action

Verify that the SRV resource record for the requested domain and service type exists in DNS. You can do this using the DcDiag command-line tool, which must be run on a domain controller for the specified Active Directory domain. Verify DNS zone delegations by using the Nslookup command-line tool.

Related:

Process (PID=). DSAccess is unable to connect to the Domain Controller althoughits service location (SRV) resource record was found in the DNS The query was for the SRV record for The following domain controllers were identified by the query:Common causes of this error include:- Host (A) records that map the name of the domain controller to its IP addresses are missing or contain incorrect addresses.- Domain controllers registered in DNS are not connected to the network or are not running.For information about correcting this problem,

Details
Product: Exchange
Event ID: 2123
Source: MSExchangeDSAccess
Version: 6.5.6940.0
Component: Microsoft Exchange Directory Access Cache
Message: Process <process name> (PID=<process id>). DSAccess is unable to connect to the Domain Controller <name> althoughits service location (SRV) resource record was found in the DNS The query was for the SRV record for <distinguished name>The following domain controllers were identified by the query:<name>Common causes of this error include:- Host (A) records that map the name of the domain controller to its IP addresses are missing or contain incorrect addresses.- Domain controllers registered in DNS are not connected to the network or are not running.For information about correcting this problem, <text><text>
   
Explanation

This event will be seen if Diagnostics Logging on the Topology category of DSAccess is set to Minimum for the server. This event means that the domain controllers from the specified domain will not be used by DSAccess. As long as there is sufficient capacity in suitable domain controllers in other domains, it will not cause mail flow interruption. However, it is recommended that this event be investigated and fixed as soon as possible. If the event contains the name of the local domain, topology discovery cannot be completed, and this will cause mail flow interruption. This event may be logged if the required A (Address) resource records that map the names of the domain controllers to their respective IP addresses do not exist in DNS.

   
User Action

Verify that the required A resource records exist in DNS by using the Nslookup command-line tool.

Related:

Process (PID=). Error 0x occurred when DNS was queried for the service location (SRV) resource record used to locate a domain controller for domain The query was for the SRV record for For information about correcting this problem,

Details
Product: Exchange
Event ID: 2122
Source: MSExchangeDSAccess
Version: 6.5.6940.0
Component: Microsoft Exchange Directory Access Cache
Message: Process <process name> (PID=<process id>). Error 0x<error code> occurred when DNS was queried for the service location (SRV) resource record used to locate a domain controller for domain <name>The query was for the SRV record for <distinguished name>For information about correcting this problem, <text><text>
   
Explanation

This event occurs if Diagnostics Logging on the Topology category of DSAccess is set to Minimum for the server. It means that a non-specific error occurred when DNS was queried for SRV records for the specified domain. This event means that the domain controllers from the specified domain will not be used by DSAccess. As long as there is sufficient capacity in suitable domain controllers in other domains, mail flow will not be interrupted. However, it is recommended that this event be investigated and fixed as soon as possible. If the event contains the name of the local domain, topology discovery cannot be completed, and this will cause mail flow interruption. This can be caused if the required resource records on the DNS server are missing or are incorrect.

   
User Action

Verify that the required SRV and the A resource records exist in DNS by using the Nslookup command-line tool.

Related:

Process %1 (PID=%2). Error 0x%3 occurred when DNS was queried for the service location (SRV) resource record used to locate a domain controller for domain %4 The query was for the SRV record for %5 For information about correcting this problem, %6%7

Details
Product: Exchange
Event ID: 2122
Source: MSExchangeADAccess
Version: 8.0
Symbolic Name: DSC_EVENT_DNS_OTHER
Message: Process %1 (PID=%2). Error 0x%3 occurred when DNS was queried for the service location (SRV) resource record used to locate a domain controller for domain %4
The query was for the SRV record for %5
For information about correcting this problem, %6%7
   
Explanation

This event indicates that an error occurred when Domain Name System (DNS) was queried for service (SRV) records for the specified domain. The domain controllers from the specified domain will not be used by DSAccess. You should investigate the issue and fix it. As long as there is sufficient capacity in usable domain controllers in other domains, there will not be mail flow interruption. If the event contains the name of the local domain, topology discovery cannot be completed and mail flow will be interrupted.

This behavior may occur if the required resource records in DNS are missing or incorrect.

   
User Action

To resolve this event, do one or more of the following:

  • Verify that the required SRV and A resource records exist in DNS by using the Nslookup command line tool.

  • Verify connectivity and then verify that the domain controller is running.

    • Use the Ping or PathPing command line tools to test basic connectivity. Use Ping to isolate network hardware problems and incompatible configurations. Use PathPing to detect packet loss over multiple-hop trips. For more information, see Microsoft Knowledge Base article 325487, How to troubleshoot network connectivity problems.

    • Run the Dcdiag command line tool to test domain controller health. To do this, run dcdiag /s:<Domain Controller Name> at a command prompt on the Exchange server. Use the output of Dcdiag to discover the root cause of any failures or warnings that it reports. For more information, see Dcdiag Overview at the Microsoft Windows Server TechCenter.

Note  If you aren’t already doing so, consider running the tools that Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mailflow, and better manage disaster-recovery scenarios. Go to the Toolbox node of Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.

Related: