We have set up Exchange 2010 that contains all the roles. We also have Forefront TMG server installed to our DMZ with NIC's to LAN and Internet.
We are able to access OWA logon screen from Internet but the authentication fails with error "Unable to logon to Forefront TMG. Make shure that the domain name, username and password are correct and try again.".
From LAN I get error that the page can not be displayed.

In TMG the listener settings are:  HTML Form authentication, Windows (Active Directory). I have single network "Perimeter" with Specified IP Address. The address is static and set to a NIC pointing to external network dedicated only for this.
In Client connection type I have selected "Enable SSL (HTTPS) connections on port: 443".  In Certificates we have selected to use a single certificate for the listener.

The OWA policy Authentication Delegation is set to Basic Authentication. Rule applies to all authenticated users.

I have gone through different scenarios about setting up Exch 2010 with TMG but can't get the authentication to work.

We have multiname unified communications certificate from Digicert set up to Exchange and TMG servers.

Could you please provide some pointers on where to start looking for the problem?  

asked 12/06/2011 08:17

Lipevakala's gravatar image

Lipevakala ♦♦

8 Answers:
is your internal NIC has internal DNS server on it?

can you  change the referneces to the CAS server in the rule\listener config to the IP address, not the name  of the CAS and see if you can get to OWA then..
also check this link :



jordannet's gravatar image


The internal NIC has DNS configured. The DNS contains all necessary A records.

I tested setting the IP address of the CAS to the TMG server OWA rule settings but that didn't make any difference.

I went throung the link you mentioned and tried to find some configuration hints. The problem is that the setup he uses differs from what I have.

We have Exchange 2010 with all roles set up to LAN. DC and DNS resides in LAN. TMG server is placed in DMZ with NIC's both LAN and External. We have a firewall between TMG and Internet that does NAT for the DMZ addresses.

Now in I can see that the certificate works ok and the external name works with public DNS.

When accessing OWA from a machine that is connected to Internet I'm able to access the logon screen so something must work to get this far.

In Exchange the OWA and ECP authentication settings I have "Use one or more standard authentication methods" selected but no tabs on the authentication methods.

The TMG server is not joined in domain. It can ping all intenal addresses and resolve names via NIC that's connected to the LAN.

With this config I can access the owa logon screen but receive the error as mentioned in the original post.

Inspired but the link you gave I did some testing.

If I understood correctly I can't use Form based authentication since the TMG server is not in the domain?
I tested the OWA rule Listener with authentication setting HTTP - Basic authentication, LDAP as validation. I have my DC server configured as LDAP server to TMG.
When I access the OWA from Internet I get prompted for username and password but then I get error: The page can not be displayed, Explanation: The web server connection was closed.
And in the technical Information: Error code 64: host not available

When I run the "Test rule" button in TMG in my OWA rule it fails with error 64 - The specified network name is no longer available.

I have no idea what to test anymore.

answered 2011-12-07 at 06:08:18

Lipevakala's gravatar image


can you make extra test using :

and post the results here.

answered 2011-12-09 at 00:29:28

jordannet's gravatar image


       ExRCA is testing Exchange ActiveSync.
       The Exchange ActiveSync test failed.
              Test Steps
              Attempting the Autodiscover and Exchange ActiveSync test (if requested).
       Testing of Autodiscover for Exchange ActiveSync failed.
              Test Steps
              Attempting each method of contacting the Autodiscover service.
       The Autodiscover service couldn't be contacted successfully by any method.
              Test Steps
              Attempting to test potential Autodiscover URL
       Testing of this potential Autodiscover URL failed.
              Test Steps
              Attempting to resolve the host name in DNS.
       The host name resolved successfully.
              Additional Details
       IP addresses returned:

       Testing TCP port 443 on host to ensure it's listening and open.
       The port was opened successfully.
       Testing the SSL certificate to make sure it's valid.
       The SSL certificate failed one or more certificate validation checks.
              Test Steps
              ExRCA is attempting to obtain the SSL certificate from remote server on port 443.
       ExRCA wasn't able to obtain the remote SSL certificate.
              Additional Details
       The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.

       Attempting to test potential Autodiscover URL
       Testing of this potential Autodiscover URL failed.
              Test Steps
              Attempting to resolve the host name in DNS.
       The host name resolved successfully.
              Additional Details
       IP addresses returned:

       Testing TCP port 443 on host to ensure it's listening and open.
       The port was opened successfully.
       Testing the SSL certificate to make sure it's valid.
       The certificate passed all validation requirements.
              Test Steps
              ExRCA is attempting to obtain the SSL certificate from remote server on port 443.
       ExRCA successfully obtained the remote SSL certificate.
              Additional Details
       Remote Certificate Subject:, OU=ICT ja Kehitys, O=Company Oy Ab, L=Helsinki, S=Uusimaa, C=FI, Issuer: CN=DigiCert High Assurance CA-3,, O=DigiCert Inc, C=US.

       Validating the certificate name.
       The certificate name was validated successfully.
              Additional Details
       Host name was found in the Certificate Subject Alternative Name entry.

       Certificate trust is being validated.
       The certificate is trusted and all certificates are present in the chain.
              Test Steps
              ExRCA is attempting to build certificate chains for certificate, OU=ICT ja Kehitys, O=Company Oy Ab, L=Helsinki, S=Uusimaa, C=FI.
       One or more certificate chains were constructed successfully.
              Additional Details
       A total of 4 chains were built. The highest quality chain ends in root certificate CN=DigiCert High Assurance EV Root CA,, O=DigiCert Inc, C=US.

       Analyzing the certificate chains for compatibility problems with versions of Windows.
       No Windows compatibility problems were identified.
              Additional Details
       The certificate chain has been validated up to a trusted root. Root = Secure Server Certification Authority, OU=(c) 1999 Limited, incorp. by ref. (limits liab.),, C=US.

       Testing the certificate date to confirm the certificate is valid.
       Date validation passed. The certificate hasn't expired.
              Additional Details
       The certificate is valid. NotBefore = 11/29/2011 12:00:00 AM, NotAfter = 12/3/2012 12:00:00 PM

       Checking the IIS configuration for client certificate authentication.
       Client certificate authentication wasn't detected.
              Additional Details
       Accept/Require Client Certificates isn't configured.

       Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
       Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
              Test Steps
              ExRCA is attempting to retrieve an XML Autodiscover response from URL for user
       ExRCA failed to obtain an Autodiscover XML response.
         Tell me more about this issue and how to resolve it

              Additional Details
       An HTTP 403 error was received because ISA Server denied the specified URL.

       Attempting to contact the Autodiscover service using the HTTP redirect method.
       The attempt to contact Autodiscover using the HTTP Redirect method failed.
              Test Steps
              Attempting to resolve the host name in DNS.
       The host name resolved successfully.
              Additional Details
       IP addresses returned:

       Testing TCP port 80 on host to ensure it's listening and open.
       The specified port is either blocked, not listening, or not producing the expected response.
         Tell me more about this issue and how to resolve it

              Additional Details
       A network error occurred while communicating with the remote host.

       Attempting to contact the Autodiscover service using the DNS SRV redirect method.
       ExRCA failed to contact the Autodiscover service using the DNS SRV redirect method.
              Test Steps
              Attempting to locate SRV record in DNS.
       The Autodiscover SRV record wasn't found in DNS.
         Tell me more about this issue and how to resolve it

(I replaced our company domain name with in this result)

answered 2011-12-09 at 01:12:07

Lipevakala's gravatar image


am just trying to figure it out , almost i finished , you have to answer 3 questions :

1- do you have SRV record in your domain management panel (i mean the company who hosted your domain "" ? go to domain management then DNS check if there is record called SRVpoint to , if its not add new record SRV record , type _tcp -> points to ""
save , back to A record if there is any A record points to delete it , just keep SRV record.
2- please post the results of the following commands :
get-ClientAccessServer |fl
get-AutodiscoverVirtualDirectory |fl

3- please also check in your SSL licenese is it installed on IIS , go to IIS the SSL Certification , check its its installed , then go to default website , on right pane -> binding -> edit SSL port 443 -> check if there is certificate assigned.
4- in your SSL certificate of course there is CN name and alternative names .. can you post them here?

answered 2011-12-09 at 01:32:54

jordannet's gravatar image


Answers to your questions:

1. We created the SRV record and removed the A record.

[PS] C:\Windows\system32>get-ClientAccessServer |fl

RunspaceId                           : 60de1d78-7186-4f8b-95ba-446a95878f08
Name                                 : SRVHKI45
Fqdn                                 :
OutlookAnywhereEnabled               : False
AutoDiscoverServiceCN                : SRVHKI45
AutoDiscoverServiceClassName         : ms-Exchange-AutoDiscover-Service
AutoDiscoverServiceInternalUri       :
AutoDiscoverServiceGuid              : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
AutoDiscoverSiteScope                : {Helsinki}
AlternateServiceAccountConfiguration :
IrmLogEnabled                        : True
IrmLogMaxAge                         : 30.00:00:00
IrmLogMaxDirectorySize               : 250 MB (262,144,000 bytes)
IrmLogMaxFileSize                    : 10 MB (10,485,760 bytes)
IrmLogPath                           : C:\Program Files\Microsoft\Exchange Server\V14\Logging\IRMLogs
MigrationLogLoggingLevel             : Information
MigrationLogFilePath                 :
MigrationLogMaxAge                   : 180.00:00:00
MigrationLogMaxDirectorySize         : 10 GB (10,737,418,240 bytes)
MigrationLogMaxFileSize              : 100 MB (104,857,600 bytes)
IsValid                              : True
ExchangeVersion                      : 0.1 (8.0.535.0)
DistinguishedName                    : CN=SRVHKI45,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Adm
                                       inistrative Groups,CN=Company,CN=Microsoft Exchange,CN=Services,CN=Configuratio
Identity                             : SRVHKI45
Guid                                 : c363bfdb-d2a1-4b03-ac12-171949accc59
ObjectCategory                       :
ObjectClass                          : {top, server, msExchExchangeServer}
WhenChanged                          : 24.11.2011 10:35:19
WhenCreated                          : 24.11.2011 10:19:15
WhenChangedUTC                       : 24.11.2011 8:35:19
WhenCreatedUTC                       : 24.11.2011 8:19:15
OrganizationId                       :
OriginatingServer                    :

[PS] C:\Windows\system32>get-AutodiscoverVirtualDirectory |fl

RunspaceId                      : 60de1d78-7186-4f8b-95ba-446a95878f08
Name                            : Autodiscover (Default Web Site)
InternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
ExternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity}
LiveIdSpNegoAuthentication      : False
WSSecurityAuthentication        : True
LiveIdBasicAuthentication       : False
BasicAuthentication             : True
DigestAuthentication            : False
WindowsAuthentication           : True
MetabasePath                    : IIS://
Path                            : C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
Server                          : SRVHKI45
InternalUrl                     :
ExternalUrl                     :
AdminDisplayName                :
ExchangeVersion                 : 0.10 (
DistinguishedName               : CN=Autodiscover (Default Web Site),CN=HTTP,CN=Protocols,CN=SRVHKI45,CN=Servers,CN=Exc
                                  hange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Company,CN=
                                  Microsoft Exchange,CN=Services,CN=Configuration,DC=ad,DC=company-IntName,DC=fi
Identity                        : SRVHKI45\Autodiscover (Default Web Site)
Guid                            : 2f194a64-38d0-494a-aad8-294e0b13e01a
ObjectCategory                  :
ObjectClass                     : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory}
WhenChanged                     : 24.11.2011 10:29:37
WhenCreated                     : 24.11.2011 10:29:16
WhenChangedUTC                  : 24.11.2011 8:29:37
WhenCreatedUTC                  : 24.11.2011 8:29:16
OrganizationId                  :
OriginatingServer               :
IsValid                         : True

[PS] C:\Windows\system32>

3. I checked IIS and the certificate was installed. However it was not set in Bindings to the SSL port 443.

CN =


answered 2011-12-09 at 01:39:53

Lipevakala's gravatar image


OWA and Activesync works.

The problem with the authentication somehow relates to the fact that Forefront server was not a domain member. I thought that it should be able to discuss with DC either via access to the LAN or using LDAP.

Well anyways, after joining the TMG to the domain everything worked like they instructed on several internet pages of how to configure Exchange 2010 with Forefront TMG.

Thanks for the effort jordannet!

answered 2011-12-11 at 23:53:27

Lipevakala's gravatar image


Found the solution on my own. Basicly the problem it self is not really solved but I'm more than happy with getting this to work.


answered 2011-12-12 at 23:22:15

Lipevakala's gravatar image


Your answer
[hide preview]

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments



Asked: 12/06/2011 08:17

Seen: 692 times

Last updated: 12/16/2011 05:21