Oulook profile not being created nor loading when proxy is enabled
When did it begin and how often does it occur?
This happens everytime. - When we install a new image via SCCM or even a straight from the CD/ISO installation with no other applications other than installing MS Office 2013 Pro Plus (with SP1) you run Outlook for the first time and get the first time run wizard. The autodiscover pulls in your name and email address. The next screen runs through the three checked tasks but fails on the last task with an error that it cannot find or see the Exchange server or that the Exchange maybe offline.
This is not correct as the exchange server is online and the client machine can ping, push and pull files through the UNC path etc.
This is run whilst the IE Settings > Connections > LAN Settings > Proxy is enabled. When this is DISABLED it works as it should do as you would expect the end client to work and can also send and receive emails. Obviously this is not the fix as the end client must retain the Proxy setting. (This is a third party proxy so nothing I can do to edit or monitor their servers)
We have added the exchange server to the exclusion list but Outlook is still persisting in "thinking" the Exchange server is offline/un-contactable.
The FQDN of the Exchange server is called SRV788.ABC.sub.net So the following has been attempted as exclusions to fix the issue but nothing has worked: (server names obviously sanitised to protect the client)
SRV788.ABC.sub.net
*.ABC.sub.net
*.sub.net
*.net
10.20.1.30 (Private IP of the EXCH)
10.20.1.*
10.20.*.*
10.*.*.*
* (I would expect this to have worked in its worst case scenario as this surely would exclude everything, but still fails.)
What's the environment and are there recent changes?
Same results on:
Windows 10 1809
Windows 10 1903
Windows 10 1909
Windows 10 2004
Windows 10 20H2
The Exchange Server was originally on 2010 and is now in Exchange 2016 but no traces of 2010 in ADSI edit
This is where things get really funky, this all works on an old SCCM build on Win 10 [1909] on the same switch and VLAN etc.So some jiggery pokery must have taken place years ago by the person who previously built tha last image. Un-contactable. Ive been looking through the registry and nothing stands out to me.
We have raised a call with MS premier support which hasnt not been answered yet and I am hoping to crack this by the weekend to meet a deadline.
Your 'hopefully'
Lee
This happens everytime. - When we install a new image via SCCM or even a straight from the CD/ISO installation with no other applications other than installing MS Office 2013 Pro Plus (with SP1) you run Outlook for the first time and get the first time run wizard. The autodiscover pulls in your name and email address. The next screen runs through the three checked tasks but fails on the last task with an error that it cannot find or see the Exchange server or that the Exchange maybe offline.
This is not correct as the exchange server is online and the client machine can ping, push and pull files through the UNC path etc.
This is run whilst the IE Settings > Connections > LAN Settings > Proxy is enabled. When this is DISABLED it works as it should do as you would expect the end client to work and can also send and receive emails. Obviously this is not the fix as the end client must retain the Proxy setting. (This is a third party proxy so nothing I can do to edit or monitor their servers)
We have added the exchange server to the exclusion list but Outlook is still persisting in "thinking" the Exchange server is offline/un-contactable.
The FQDN of the Exchange server is called SRV788.ABC.sub.net So the following has been attempted as exclusions to fix the issue but nothing has worked: (server names obviously sanitised to protect the client)
SRV788.ABC.sub.net
*.ABC.sub.net
*.sub.net
*.net
10.20.1.30 (Private IP of the EXCH)
10.20.1.*
10.20.*.*
10.*.*.*
* (I would expect this to have worked in its worst case scenario as this surely would exclude everything, but still fails.)
What's the environment and are there recent changes?
Same results on:
Windows 10 1809
Windows 10 1903
Windows 10 1909
Windows 10 2004
Windows 10 20H2
The Exchange Server was originally on 2010 and is now in Exchange 2016 but no traces of 2010 in ADSI edit
This is where things get really funky, this all works on an old SCCM build on Win 10 [1909] on the same switch and VLAN etc.So some jiggery pokery must have taken place years ago by the person who previously built tha last image. Un-contactable. Ive been looking through the registry and nothing stands out to me.
We have raised a call with MS premier support which hasnt not been answered yet and I am hoping to crack this by the weekend to meet a deadline.
Your 'hopefully'
Lee
ASKER
The address is actually different from the domain. lets say the domain is abc.sub.net but the promary domain is abc.gov.uk which is an accepted domain in exchange.
When I Ctrl+R.click the outlook icon
on a working machine = connection established
on a 'new' machine = cannot establish
The autodiscover exists for both abc.sub.net and the third party (being a gov) holds the autodiscover for abc.gov.uk. Which ISS log in particular is to be looked at for the home autodiscover?
This autodiscover does exist in DNS and you can ping etc.
Once you connect a machine by disabling proxy, when you re enable the proxy it stops working as in the established connection drops ending comms and also stops you reloading when you shut Outlook down.
When I Ctrl+R.click the outlook icon
on a working machine = connection established
on a 'new' machine = cannot establish
The autodiscover exists for both abc.sub.net and the third party (being a gov) holds the autodiscover for abc.gov.uk. Which ISS log in particular is to be looked at for the home autodiscover?
This autodiscover does exist in DNS and you can ping etc.
Once you connect a machine by disabling proxy, when you re enable the proxy it stops working as in the established connection drops ending comms and also stops you reloading when you shut Outlook down.
ASKER
Here is a sanitised output of "me" connecting to the exchange from what i found in the /inetpub/log/logfiles/w3svc1
ASKER
*Bump*
Can anyone shed some light on this please?
Can anyone shed some light on this please?
Hello Lee,
you did not really show, what I wanted to see...
So first, your AD domain is abc.sub.net, but yur email domain is abc.gov.uk, so you have email addreses like user@abc.goc.uk, right?
So, you need an autodiscover DNS record for autodiscover.abc.gov.uk
You can check autodiscover just bei the URL, i.e
https://autodiscover.abc.gov.uk/autodicover/autodiscover.html
also you may check what
https://autodiscover.abc.sub.net/autodicover/autodiscover.html
delivers.
The sencond option - as I said before.
CTRL + Right Mouse on Outlook Tay Icon --> Test E-Mail Autoconfiguration
There you can test and see, what autodiscover would deliver.
According your Proxy:
Exchange needs a reverse proxy which needs a link translation or the proxy acts a simple router.
If the proxy doesn't work as expected, the client may able to find the exchange but not to route all additional traffic over the proxy as an internal client uses RCP over TCP.
An external Outlook client uses Outlook anywhere to handle the RPC traffic via HTTP.
According to the message above and what I can see in the pictures, It looks like that the autodiscover as well as the connections point to *.net. What looks fine in the first moment.
Bit if I llok into your IIS logs, I see abc.gov.uk. So the question here is, against which DC / domain your outlook client tries to authenticate.
But it also looks like that the traffic fails on the authentication site.
But the proxy has also to pass the right autentication to exchange, it is not just to proxy https traffic.
Or in other words, the proxy setting for Exchange are a little bit more complex than just to route a web site.
You may have a look on the outlook anywhere settings in exchange (if enabled or not), as this would give the client the option to encapsulate RPC into HTTP, but the client also uses the network settings to decide, if the traffic is internal or external.
you did not really show, what I wanted to see...
So first, your AD domain is abc.sub.net, but yur email domain is abc.gov.uk, so you have email addreses like user@abc.goc.uk, right?
So, you need an autodiscover DNS record for autodiscover.abc.gov.uk
You can check autodiscover just bei the URL, i.e
https://autodiscover.abc.gov.uk/autodicover/autodiscover.html
also you may check what
https://autodiscover.abc.sub.net/autodicover/autodiscover.html
delivers.
The sencond option - as I said before.
CTRL + Right Mouse on Outlook Tay Icon --> Test E-Mail Autoconfiguration
There you can test and see, what autodiscover would deliver.
According your Proxy:
Exchange needs a reverse proxy which needs a link translation or the proxy acts a simple router.
If the proxy doesn't work as expected, the client may able to find the exchange but not to route all additional traffic over the proxy as an internal client uses RCP over TCP.
An external Outlook client uses Outlook anywhere to handle the RPC traffic via HTTP.
According to the message above and what I can see in the pictures, It looks like that the autodiscover as well as the connections point to *.net. What looks fine in the first moment.
Bit if I llok into your IIS logs, I see abc.gov.uk. So the question here is, against which DC / domain your outlook client tries to authenticate.
But it also looks like that the traffic fails on the authentication site.
But the proxy has also to pass the right autentication to exchange, it is not just to proxy https traffic.
Or in other words, the proxy setting for Exchange are a little bit more complex than just to route a web site.
You may have a look on the outlook anywhere settings in exchange (if enabled or not), as this would give the client the option to encapsulate RPC into HTTP, but the client also uses the network settings to decide, if the traffic is internal or external.
ASKER
Hi Bembi,
That is correct the users have a "default" emails address of user@abc.gov.uk which is an accepted domain in the exchange within the abc.sub.net domain/forest.
The test ranon a machine that i disabled the proxy > created the profile > opened outlook>disabled proxy > ran test gave me :
Sorry for the constant sanitising but its a government client and i will get the sack if i didnt :)
External clients isnt an issue as they use OWA. This is internal clients only.
Ive been googling for days and have seen a few people refer to RPC. Can you give me any light here. What changes would be made and where.
The two urls
https://autodiscover.abc.sub.net/autodiscover/autodiscover.xml - works
https://autodiscover.abc.gov.uk/autodiscover/autodiscover.html - just get a white screen - but hosted elsewhere so cannot check on this.
That is correct the users have a "default" emails address of user@abc.gov.uk which is an accepted domain in the exchange within the abc.sub.net domain/forest.
The test ranon a machine that i disabled the proxy > created the profile > opened outlook>disabled proxy > ran test gave me :
Sorry for the constant sanitising but its a government client and i will get the sack if i didnt :)External clients isnt an issue as they use OWA. This is internal clients only.
Ive been googling for days and have seen a few people refer to RPC. Can you give me any light here. What changes would be made and where.
The two urls
https://autodiscover.abc.sub.net/autodiscover/autodiscover.xml - works
https://autodiscover.abc.gov.uk/autodiscover/autodiscover.html - just get a white screen - but hosted elsewhere so cannot check on this.
Have a look at the log tab.
There you find the used autodiscovery URL including the status code. (200 = success)
This autodiscovery URL should deliver something, like all other URLs you see als well. Alt least an Access Denied what gives us a proof, that it comes from exchange.
The XML tab show you the result im XML form even with some additianl information from the AD. In this XLM you will find also authentication information, used ad controller, available authentication methods etc.
What I see here is:
A.) External URL is not set. Nevertheless not needed as far as the client recognizes the connection as internal.
This can be tested with any working link pointing to a abc.sub.net URL.
At least you can check https://mail.abc.sub.net [/owa]
If the browser regognizes this URL as external URL, authentication is not send, therefore the authentication fails.
At least an External URL in combination with Oulook anywhere may be something like a fallback for this case.
B.) Protocoll: Exchnage-HTTP
This points into the same direction, as for an internal connection you shoud see a complete block starting with Exchnage-RPC ...
This block is completely missing.
C.) Auth package NTLM:
Even this should be set to Standard...
But this is usually set in the Outlook profile. It may also point to Outllok anywhere as kerberos related login doesn't (usually) work from external.
What I follow out of what I see...
Your configuration looks like that the client interprets the connectiona as external.
On external connections the browser (better the WIN-HTTP) doesn't send credentials in the request which has usually the effect, that you get a login dialog, as far as basic authentiation is allowed.
The available authentication method can be seen in the XML tab under<OWAURL Authentication Method = ... >
The used authentication is visible in the same page under <AuthPackage ... >
You may compare all this results to a connection without proxy.
At the end, there are possibly several configuration issues which are not quite correct.
But you may have success (as a workaround) to enter an external URL (same as internal) and to allow Outlook anywhere as well as basic authentication. Maybe the proxy can handle this.
But the major issue is, that it looks like your browser is recognizing the URLs as external, what is more a network configuration issue. This can possibly be the case, if the proxy is outside your local network area or even if client and exchange are in different subnets.
D:) Last but not least you can also inspect your mail account settings...
And on the connection tab...
Where Exchange Proxy Settings are used for Outlook Anywhere.
There you find the used autodiscovery URL including the status code. (200 = success)
This autodiscovery URL should deliver something, like all other URLs you see als well. Alt least an Access Denied what gives us a proof, that it comes from exchange.
The XML tab show you the result im XML form even with some additianl information from the AD. In this XLM you will find also authentication information, used ad controller, available authentication methods etc.
What I see here is:
A.) External URL is not set. Nevertheless not needed as far as the client recognizes the connection as internal.
This can be tested with any working link pointing to a abc.sub.net URL.
At least you can check https://mail.abc.sub.net [/owa]
If the browser regognizes this URL as external URL, authentication is not send, therefore the authentication fails.
At least an External URL in combination with Oulook anywhere may be something like a fallback for this case.
B.) Protocoll: Exchnage-HTTP
This points into the same direction, as for an internal connection you shoud see a complete block starting with Exchnage-RPC ...
This block is completely missing.
C.) Auth package NTLM:
Even this should be set to Standard...
But this is usually set in the Outlook profile. It may also point to Outllok anywhere as kerberos related login doesn't (usually) work from external.
What I follow out of what I see...
Your configuration looks like that the client interprets the connectiona as external.
On external connections the browser (better the WIN-HTTP) doesn't send credentials in the request which has usually the effect, that you get a login dialog, as far as basic authentiation is allowed.
The available authentication method can be seen in the XML tab under<OWAURL Authentication Method = ... >
The used authentication is visible in the same page under <AuthPackage ... >
You may compare all this results to a connection without proxy.
At the end, there are possibly several configuration issues which are not quite correct.
But you may have success (as a workaround) to enter an external URL (same as internal) and to allow Outlook anywhere as well as basic authentication. Maybe the proxy can handle this.
But the major issue is, that it looks like your browser is recognizing the URLs as external, what is more a network configuration issue. This can possibly be the case, if the proxy is outside your local network area or even if client and exchange are in different subnets.
D:) Last but not least you can also inspect your mail account settings...
And on the connection tab...
Where Exchange Proxy Settings are used for Outlook Anywhere.
ASKER
I have set those settings as shown in your screen shots but still the exact same results of the exchange being offline. Can i just say your rely obviously took some of your time up and i appreciate the time you took to reply.
Hi Lee, dont worry...
but you should read, what I write...
The outlook settings are a result of your infrastucture.
I just try to explain so that you can have an idea, what is the reason.
So say it in short words: You client tries outlook anywhere, but your exchange is not configured for a outlook anywhere.
What can you do to make outlook anywhere work:
Exchange:
Set an external owa url (same URL internal)
Allow Windows authentication and basic authentication
Enable Outlook anywhere (here you use only the servername, i.e. mail, yourdomain.tld).
You can enable NTLM or Basic and you can enable SSL, if you have a certificate for the name.
but you should read, what I write...
The outlook settings are a result of your infrastucture.
I just try to explain so that you can have an idea, what is the reason.
So say it in short words: You client tries outlook anywhere, but your exchange is not configured for a outlook anywhere.
What can you do to make outlook anywhere work:
Exchange:
Set an external owa url (same URL internal)
Allow Windows authentication and basic authentication
Enable Outlook anywhere (here you use only the servername, i.e. mail, yourdomain.tld).
You can enable NTLM or Basic and you can enable SSL, if you have a certificate for the name.
Set this first and report, if something changed...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hello,
15.0.4569.1503 is 7 years old, right?
A good advise is usually to keep client and server version on the same patch level. Any security update may influence the communication and possibly need changes on both sites.
Nevertheless, check the autodiscover, if you see now Echange-RPC to be sure, it passes your proxy and even RPC is used for the connection.
If the question is solved in your opinion, its woth to close the question.
15.0.4569.1503 is 7 years old, right?
A good advise is usually to keep client and server version on the same patch level. Any security update may influence the communication and possibly need changes on both sites.
Nevertheless, check the autodiscover, if you see now Echange-RPC to be sure, it passes your proxy and even RPC is used for the connection.
If the question is solved in your opinion, its woth to close the question.
No comment has been added to this question in more than 21 days, so it is now classified as abandoned.
I have recommended this question be closed as follows:
Accept: 'Lee Fowler' (https:#a43297665)
If you feel this question should be closed differently, post an objection and the moderators will review all objections and close it as they feel fit. If no one objects, this question will be closed automatically the way described above.
seth2740
Experts-Exchange Cleanup Volunteer
I have recommended this question be closed as follows:
Accept: 'Lee Fowler' (https:#a43297665)
If you feel this question should be closed differently, post an objection and the moderators will review all objections and close it as they feel fit. If no one objects, this question will be closed automatically the way described above.
seth2740
Experts-Exchange Cleanup Volunteer
Does the email address fit to your domain? so user@yourdomain.tld ?
The client uses autodiscover to find the server details. To prove that autodiscover works, you may check the ISS logs of exchange, it you see the request.
My imagination is, that something with your autodiscover doesn't work as expected.
You may alkso check on a working client, which is connected via Proxy, what you get if you CTRL-RightClick on the outlook tray icon, there you can select an option to check autodiscover.