|
|
|
date: Fri, 19 Sep 2008 14:40:44 -0400,
group: microsoft.public.exchange.admin
back
issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Good afternoon!
Okay, this can possibly be one of the longest posts in the history of news
groups (some of you know my 'style'). I will try to keep it short and sweet
(which means 20 pages instead of 60!).
Exchange Server 2007 SP1
MS Outlook 2003 SP3 / MS Outlook 2007 SP1
WIN2003 SP2 AD
Four AD Sites (EXCH2007 - on box, in the HQ site)
Issue is that when a user (MS Outlook 2007 SP1) tries to use Out of Office
he/she gets the error message "blah! blah! Server not available". Yes, OWA
works just fine. Yes, MS Outlook 2003 SP3 works just fine.
This affects users in all four Sites. Yes, there are users in the Site in
which the EXCH2007 box is located.
The DigiCert Cert appears to be fine. I did not do it (probably why it is
fine!). Using OWA internally or externally does not present us with the
Cert error. We have about 65 users making use of Outlook Anywhere without
any issues. They are all MS Outlook 2003, so no OoO issues with them
(Thank, God! These 65 users are the Police Department!).
I tested MS Outlook with two users (in different Sites...same results) by
holding down the Ctrl key and right-clicking the MS Outlook icon in the
system tray and then selecting 'Test E-Mail Configuration". We receive -
everytime - the "Can not determine your settings" error message. Looking in
the Logs tab gives us lots of info. None of it seems to point me in the
direction of a solution, though.
I have looked at all of the get-xxxxVirtualDirectory | fl
[get-ClientAccessServer | fl
get-OABVirtualDirectory | fl
get-WebServicesVirtualDirectory | fl
get-UMVirtualDirectory | fl]
used the test-outlookwebservices | fl. There were several errors in the
test-outlookwebservices that I was able to resolve (see next paragraph for
more on that).
The internal domain name (mydomain.org) is the same as the external domian
name (mydomain.org) so there was an issue resolving 'mail.mydomain.org'. I
created - in the internal FLZ for 'mydomain.org' - a Host record 'mail' and
pointed it to the WAN IP Address and those issues went away.
I have checked IIS and ensured that what is supposed to be is and what is
not supposed to be is not (how is that for 'vague'). For example, anonymous
access is not checked for the Autodiscover Virtual Directory. Basic and
Integrated Authentication are enabled for the AutoDiscover Virtual
Directory.
I have ensured that the SCP is indeed there and correct. It is.
I can access the https://server.mydomain.org/autodiscover/autodiscover.xml
and all the other URLs (https://server.mydomain.org/EWS/Exchange.asmx, for
example).
I have created a Host record in the Public DNS of 'autodiscover' and pointed
it to the WAN IP Address. This does not seem to have helped. I am not able
to create an SRV Record as the company that our client is using does not
allow for SRV Records (or SPF records...).
About the only thing that I have not done is unchecked the "Require SSL" on
the VDs.
I have checked the NTFS permissions. I think that everything is good
there.....
Obviously, something is not clicking! Probably with me!
Any ideas?
Thanks,
Cary
date: Fri, 19 Sep 2008 14:40:44 -0400
author: Cary W. Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
What was the output of Get-WebServicesVirtualDirectory and your errors from
Test-OutlookWebServices? Did you resolve all of them?
"Cary W. Shultz" wrote in message
news:#gu6xdoGJHA.1308@TK2MSFTNGP02.phx.gbl...
> Good afternoon!
>
> Okay, this can possibly be one of the longest posts in the history of news
> groups (some of you know my 'style'). I will try to keep it short and
> sweet (which means 20 pages instead of 60!).
>
> Exchange Server 2007 SP1
> MS Outlook 2003 SP3 / MS Outlook 2007 SP1
> WIN2003 SP2 AD
> Four AD Sites (EXCH2007 - on box, in the HQ site)
>
> Issue is that when a user (MS Outlook 2007 SP1) tries to use Out of Office
> he/she gets the error message "blah! blah! Server not available". Yes,
> OWA works just fine. Yes, MS Outlook 2003 SP3 works just fine.
>
> This affects users in all four Sites. Yes, there are users in the Site in
> which the EXCH2007 box is located.
>
> The DigiCert Cert appears to be fine. I did not do it (probably why it is
> fine!). Using OWA internally or externally does not present us with the
> Cert error. We have about 65 users making use of Outlook Anywhere without
> any issues. They are all MS Outlook 2003, so no OoO issues with them
> (Thank, God! These 65 users are the Police Department!).
>
> I tested MS Outlook with two users (in different Sites...same results) by
> holding down the Ctrl key and right-clicking the MS Outlook icon in the
> system tray and then selecting 'Test E-Mail Configuration". We receive -
> everytime - the "Can not determine your settings" error message. Looking
> in the Logs tab gives us lots of info. None of it seems to point me in
> the direction of a solution, though.
>
> I have looked at all of the get-xxxxVirtualDirectory | fl
>
> [get-ClientAccessServer | fl
> get-OABVirtualDirectory | fl
> get-WebServicesVirtualDirectory | fl
> get-UMVirtualDirectory | fl]
>
> used the test-outlookwebservices | fl. There were several errors in the
> test-outlookwebservices that I was able to resolve (see next paragraph for
> more on that).
>
> The internal domain name (mydomain.org) is the same as the external domian
> name (mydomain.org) so there was an issue resolving 'mail.mydomain.org'.
> I created - in the internal FLZ for 'mydomain.org' - a Host record 'mail'
> and pointed it to the WAN IP Address and those issues went away.
>
> I have checked IIS and ensured that what is supposed to be is and what is
> not supposed to be is not (how is that for 'vague'). For example,
> anonymous access is not checked for the Autodiscover Virtual Directory.
> Basic and Integrated Authentication are enabled for the AutoDiscover
> Virtual Directory.
>
> I have ensured that the SCP is indeed there and correct. It is.
>
> I can access the https://server.mydomain.org/autodiscover/autodiscover.xml
> and all the other URLs (https://server.mydomain.org/EWS/Exchange.asmx, for
> example).
>
> I have created a Host record in the Public DNS of 'autodiscover' and
> pointed it to the WAN IP Address. This does not seem to have helped. I
> am not able to create an SRV Record as the company that our client is
> using does not allow for SRV Records (or SPF records...).
>
> About the only thing that I have not done is unchecked the "Require SSL"
> on the VDs.
>
> I have checked the NTFS permissions. I think that everything is good
> there.....
>
> Obviously, something is not clicking! Probably with me!
>
> Any ideas?
>
> Thanks,
>
> Cary
date: Fri, 19 Sep 2008 14:53:39 -0400
author: Michael Dragone
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Mike,
I thought about putting this info in the original post but figured not...
Anyway, here it is....
=============================================================================================================
get-WebServicesVirtualDirectory | FL
InternalNLBBypassUrl :
https://server.mydomain.org/ews/exchange.asmx
Name : EWS (Default Web Site)
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
BasicAuthentication : False
DigestAuthentication : False
WindowsAuthentication : True
MetabasePath : IIS://server.mydomain.org/W3SVC/1/ROOT/EWS
Path : C:\Program Files\Microsoft\Exchange
Server\ClientAccess\exchweb\EWS
Server : server
InternalUrl :
https://server.mydomain.org/EWS/Exchange.asmx
ExternalUrl : https://mail.mydomain.org/EWS/Exchange.asmx
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=EWS (Default Web
Site),CN=HTTP,CN=Protocols,CN=SERVER,CN=Servers,CN=Exchange Administ
rative Group
(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=NICE,CN=Microsoft Exchange,CN
=Services,CN=Configuration,DC=mydomain,DC=org
Identity : SERVER\EWS (Default Web Site)
Guid : 6e18e2ab-256b-424e-ac5f-b4ea89f64c1f
ObjectCategory :
mydomain.org/Configuration/Schema/ms-Exch-Web-Services-Virtual-Directory
ObjectClass : {top, msExchVirtualDirectory,
msExchWebServicesVirtualDirectory}
WhenChanged : 3/30/2008 12:37:52 AM
WhenCreated : 8/7/2007 1:58:41 PM
OriginatingServer : anotherserver.child.mydomain.org
IsValid : True
The thing here is that the OriginatingServer is the sole Domain Controller
for a child domain (soon to be demoted) that is located in the same Site as
the Exchange 2007 box. Not sure what the OriginatingServer does....
=============================================================================================================
test-outlookwebservices
Id : 1003
Type : Information
Message : About to test AutoDiscover with the e-mail address
Administrator@mydomain.org.
Id : 1007
Type : Information
Message : Testing server server.mydomain.org with the published name
https://server.mydomain.org/EWS/Exchange
.asmx & https://mail.mydomain.org/EWS/Exchange.asmx.
Id : 1019
Type : Information
Message : Found a valid AutoDiscover service connection point. The
AutoDiscover URL on this object is
https://server.mydomain.org/autodiscover/autodiscover.xml.
Id : 1006
Type : Information
Message : The Autodiscover service was contacted at
https://server.mydomain.org/autodiscover/autodiscover.xml.
Id : 1016
Type : Success
Message : [EXCH]-Successfully contacted the AS service at
https://server.mydomain.org/EWS/Exchange.asmx. The elaps
ed time was 609 milliseconds.
Id : 1015
Type : Success
Message : [EXCH]-Successfully contacted the OAB service at
https://server.mydomain.org/EWS/Exchange.asmx. The elap
sed time was 0 milliseconds.
Id : 1014
Type : Success
Message : [EXCH]-Successfully contacted the UM service at
https://server.mydomain.org/UnifiedMessaging/Service.asm
x. The elapsed time was 796 milliseconds.
Id : 1013
Type : Error
Message : When contacting https://mail.mydomain.org/EWS/Exchange.asmx
received the error The request failed with
HTTP status 401: Unauthorized.
Id : 1016
Type : Error
Message : [EXPR]-Error when contacting the AS service at
https://mail.mydomain.org/EWS/Exchange.asmx. The elapsed
time was 93 milliseconds.
Id : 1015
Type : Success
Message : [EXPR]-Successfully contacted the OAB service at
https://mail.mydomain.org/EWS/Exchange.asmx. The elaps
ed time was 0 milliseconds.
Id : 1014
Type : Information
Message : [EXPR]-The UM is not configured for this user.
Id : 1017
Type : Success
Message : [EXPR]-Successfully contacted the RPC/HTTP service at
https://mail.mydomain.org/Rpc. The elapsed time w
as 93 milliseconds.
Id : 1006
Type : Success
Message : The Autodiscover service was tested successfully.
Id : 1021
Type : Information
Message : The following web services generated errors.
As in EXPR
Please use the prior output to diagnose and correct the errors.
So, just the one set of errors....
=============================================================================================================
Michael, if you can see something that I am not I would greatly appreciate
your assitance....
Thanks,
Cary
"Michael Dragone" wrote in message
news:%23qA9KkoGJHA.2408@TK2MSFTNGP04.phx.gbl...
> What was the output of Get-WebServicesVirtualDirectory and your errors
> from Test-OutlookWebServices? Did you resolve all of them?
>
> "Cary W. Shultz" wrote in message
> news:#gu6xdoGJHA.1308@TK2MSFTNGP02.phx.gbl...
>> Good afternoon!
>>
>> Okay, this can possibly be one of the longest posts in the history of
>> news groups (some of you know my 'style'). I will try to keep it short
>> and sweet (which means 20 pages instead of 60!).
>>
>> Exchange Server 2007 SP1
>> MS Outlook 2003 SP3 / MS Outlook 2007 SP1
>> WIN2003 SP2 AD
>> Four AD Sites (EXCH2007 - on box, in the HQ site)
>>
>> Issue is that when a user (MS Outlook 2007 SP1) tries to use Out of
>> Office he/she gets the error message "blah! blah! Server not available".
>> Yes, OWA works just fine. Yes, MS Outlook 2003 SP3 works just fine.
>>
>> This affects users in all four Sites. Yes, there are users in the Site
>> in which the EXCH2007 box is located.
>>
>> The DigiCert Cert appears to be fine. I did not do it (probably why it
>> is fine!). Using OWA internally or externally does not present us with
>> the Cert error. We have about 65 users making use of Outlook Anywhere
>> without any issues. They are all MS Outlook 2003, so no OoO issues with
>> them (Thank, God! These 65 users are the Police Department!).
>>
>> I tested MS Outlook with two users (in different Sites...same results) by
>> holding down the Ctrl key and right-clicking the MS Outlook icon in the
>> system tray and then selecting 'Test E-Mail Configuration". We receive -
>> everytime - the "Can not determine your settings" error message. Looking
>> in the Logs tab gives us lots of info. None of it seems to point me in
>> the direction of a solution, though.
>>
>> I have looked at all of the get-xxxxVirtualDirectory | fl
>>
>> [get-ClientAccessServer | fl
>> get-OABVirtualDirectory | fl
>> get-WebServicesVirtualDirectory | fl
>> get-UMVirtualDirectory | fl]
>>
>> used the test-outlookwebservices | fl. There were several errors in the
>> test-outlookwebservices that I was able to resolve (see next paragraph
>> for more on that).
>>
>> The internal domain name (mydomain.org) is the same as the external
>> domian name (mydomain.org) so there was an issue resolving
>> 'mail.mydomain.org'. I created - in the internal FLZ for 'mydomain.org' -
>> a Host record 'mail' and pointed it to the WAN IP Address and those
>> issues went away.
>>
>> I have checked IIS and ensured that what is supposed to be is and what is
>> not supposed to be is not (how is that for 'vague'). For example,
>> anonymous access is not checked for the Autodiscover Virtual Directory.
>> Basic and Integrated Authentication are enabled for the AutoDiscover
>> Virtual Directory.
>>
>> I have ensured that the SCP is indeed there and correct. It is.
>>
>> I can access the
>> https://server.mydomain.org/autodiscover/autodiscover.xml and all the
>> other URLs (https://server.mydomain.org/EWS/Exchange.asmx, for example).
>>
>> I have created a Host record in the Public DNS of 'autodiscover' and
>> pointed it to the WAN IP Address. This does not seem to have helped. I
>> am not able to create an SRV Record as the company that our client is
>> using does not allow for SRV Records (or SPF records...).
>>
>> About the only thing that I have not done is unchecked the "Require SSL"
>> on the VDs.
>>
>> I have checked the NTFS permissions. I think that everything is good
>> there.....
>>
>> Obviously, something is not clicking! Probably with me!
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Cary
>
date: Fri, 19 Sep 2008 15:13:05 -0400
author: Cary W. Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
The OriginatingServer field states which DC was used to retrieve the data
we're looking at.
Is it possible that some of the computers your users are receive the OOF
error on are not joined to the domain?
I would try adding basic authentication to the allowed authentication
methods, especially externally.
I'm also a little confused by the following in your original post.
"The internal domain name (mydomain.org) is the same as the external domian
name (mydomain.org) so there was an issue resolving 'mail.mydomain.org'. I
created - in the internal FLZ for 'mydomain.org' - a Host record 'mail' and
pointed it to the WAN IP Address and those issues went away."
You added a host (A) record for mail in the internal FLZ? What is the
internal FLZ?
"Cary W. Shultz" wrote in message
news:eOi22voGJHA.3928@TK2MSFTNGP03.phx.gbl...
> Mike,
>
> I thought about putting this info in the original post but figured not...
>
> Anyway, here it is....
>
> =============================================================================================================
>
> get-WebServicesVirtualDirectory | FL
>
> InternalNLBBypassUrl :
> https://server.mydomain.org/ews/exchange.asmx
> Name : EWS (Default Web Site)
> InternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
> ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
> BasicAuthentication : False
> DigestAuthentication : False
> WindowsAuthentication : True
> MetabasePath : IIS://server.mydomain.org/W3SVC/1/ROOT/EWS
> Path : C:\Program Files\Microsoft\Exchange
> Server\ClientAccess\exchweb\EWS
> Server : server
> InternalUrl :
> https://server.mydomain.org/EWS/Exchange.asmx
> ExternalUrl :
> https://mail.mydomain.org/EWS/Exchange.asmx
> AdminDisplayName :
> ExchangeVersion : 0.1 (8.0.535.0)
> DistinguishedName : CN=EWS (Default Web
> Site),CN=HTTP,CN=Protocols,CN=SERVER,CN=Servers,CN=Exchange Administ
> rative Group
> (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=NICE,CN=Microsoft
> Exchange,CN
>
> =Services,CN=Configuration,DC=mydomain,DC=org
> Identity : SERVER\EWS (Default Web Site)
> Guid : 6e18e2ab-256b-424e-ac5f-b4ea89f64c1f
> ObjectCategory :
> mydomain.org/Configuration/Schema/ms-Exch-Web-Services-Virtual-Directory
> ObjectClass : {top, msExchVirtualDirectory,
> msExchWebServicesVirtualDirectory}
> WhenChanged : 3/30/2008 12:37:52 AM
> WhenCreated : 8/7/2007 1:58:41 PM
> OriginatingServer : anotherserver.child.mydomain.org
> IsValid : True
>
>
> The thing here is that the OriginatingServer is the sole Domain Controller
> for a child domain (soon to be demoted) that is located in the same Site
> as the Exchange 2007 box. Not sure what the OriginatingServer does....
>
>
> =============================================================================================================
>
> test-outlookwebservices
>
>
> Id : 1003
> Type : Information
> Message : About to test AutoDiscover with the e-mail address
> Administrator@mydomain.org.
>
> Id : 1007
> Type : Information
> Message : Testing server server.mydomain.org with the published name
> https://server.mydomain.org/EWS/Exchange
> .asmx & https://mail.mydomain.org/EWS/Exchange.asmx.
>
> Id : 1019
> Type : Information
> Message : Found a valid AutoDiscover service connection point. The
> AutoDiscover URL on this object is
> https://server.mydomain.org/autodiscover/autodiscover.xml.
>
> Id : 1006
> Type : Information
> Message : The Autodiscover service was contacted at
> https://server.mydomain.org/autodiscover/autodiscover.xml.
>
> Id : 1016
> Type : Success
> Message : [EXCH]-Successfully contacted the AS service at
> https://server.mydomain.org/EWS/Exchange.asmx. The elaps
> ed time was 609 milliseconds.
>
> Id : 1015
> Type : Success
> Message : [EXCH]-Successfully contacted the OAB service at
> https://server.mydomain.org/EWS/Exchange.asmx. The elap
> sed time was 0 milliseconds.
>
> Id : 1014
> Type : Success
> Message : [EXCH]-Successfully contacted the UM service at
> https://server.mydomain.org/UnifiedMessaging/Service.asm
> x. The elapsed time was 796 milliseconds.
>
> Id : 1013
> Type : Error
> Message : When contacting https://mail.mydomain.org/EWS/Exchange.asmx
> received the error The request failed with
> HTTP status 401: Unauthorized.
>
> Id : 1016
> Type : Error
> Message : [EXPR]-Error when contacting the AS service at
> https://mail.mydomain.org/EWS/Exchange.asmx. The elapsed
> time was 93 milliseconds.
>
> Id : 1015
> Type : Success
> Message : [EXPR]-Successfully contacted the OAB service at
> https://mail.mydomain.org/EWS/Exchange.asmx. The elaps
> ed time was 0 milliseconds.
>
> Id : 1014
> Type : Information
> Message : [EXPR]-The UM is not configured for this user.
>
> Id : 1017
> Type : Success
> Message : [EXPR]-Successfully contacted the RPC/HTTP service at
> https://mail.mydomain.org/Rpc. The elapsed time w
> as 93 milliseconds.
>
> Id : 1006
> Type : Success
> Message : The Autodiscover service was tested successfully.
>
> Id : 1021
> Type : Information
> Message : The following web services generated errors.
> As in EXPR
> Please use the prior output to diagnose and correct the errors.
>
> So, just the one set of errors....
>
> =============================================================================================================
>
> Michael, if you can see something that I am not I would greatly appreciate
> your assitance....
date: Fri, 19 Sep 2008 16:06:21 -0400
author: Michael Dragone
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Michael,
That is what I thought.....I wonder why the Domain Controller from a child
domain is the one being used to do this? Anyway, I will look into this.
And, that is the point that I forgot to add in the original post....no, all
machines are joined to the domain. Well, except for the 65 computers that
the Police Department use. That is a long story. I will save it for later.
But, all the other machines are indeed joined to the domain....being
authenticated by the local Domain Controller (which is also a GC).
Regarding Basic Authentication - everything that I have seen suggests to not
allow this. I will try it, however, just for troubleshooting purposes.
Last point....."mail" host record.
When I looked at the results of the test-outlookwebservices initially I saw
that all of the "trying to access https://mail.mydomain.org/" failed. All
of them. So, I thought for a second and it hit me that the in the internal
DNS the AD-Integrated zone is "mydomain.org". So, there are all the sub
folders (_msdcs, _tcp, _sites, _udp) and what not. However, the public DNS
is also "mydomain.org" (or, better stated, the name that they have
registered with the Registrar). So, if you open up IE and enter
http://www.mydomain.org you will be taken to their web site. Obviously, the
internal users - given this - would not be able to access their web
site -UNLESS- I created a host record "www" and point it to the Public IP
Address provided to us by the Web Hosting company. The same is true, in
this case, for "mail". The internal users will never be able to resolve
"mail.mydomain.org" because there is no A Recond in the internal DNS of
"mail". So, I created "mail" and gave it the Public IP Address of the WAN
Connection (Verizon, in this case). Once I did this all of the "remote name
could not be resolved: 'mail.mydomain.org'" issues went away....except for
the AS Service shown below...
Thanks,
Cary
"Michael Dragone" wrote in message
news:e8D2yMpGJHA.3576@TK2MSFTNGP05.phx.gbl...
> The OriginatingServer field states which DC was used to retrieve the data
> we're looking at.
>
> Is it possible that some of the computers your users are receive the OOF
> error on are not joined to the domain?
>
> I would try adding basic authentication to the allowed authentication
> methods, especially externally.
>
> I'm also a little confused by the following in your original post.
>
> "The internal domain name (mydomain.org) is the same as the external
> domian
> name (mydomain.org) so there was an issue resolving 'mail.mydomain.org'.
> I
> created - in the internal FLZ for 'mydomain.org' - a Host record 'mail'
> and
> pointed it to the WAN IP Address and those issues went away."
>
> You added a host (A) record for mail in the internal FLZ? What is the
> internal FLZ?
>
> "Cary W. Shultz" wrote in message
> news:eOi22voGJHA.3928@TK2MSFTNGP03.phx.gbl...
>> Mike,
>>
>> I thought about putting this info in the original post but figured not...
>>
>> Anyway, here it is....
>>
>> =============================================================================================================
>>
>> get-WebServicesVirtualDirectory | FL
>>
>> InternalNLBBypassUrl :
>> https://server.mydomain.org/ews/exchange.asmx
>> Name : EWS (Default Web Site)
>> InternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
>> ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
>> BasicAuthentication : False
>> DigestAuthentication : False
>> WindowsAuthentication : True
>> MetabasePath :
>> IIS://server.mydomain.org/W3SVC/1/ROOT/EWS
>> Path : C:\Program Files\Microsoft\Exchange
>> Server\ClientAccess\exchweb\EWS
>> Server : server
>> InternalUrl :
>> https://server.mydomain.org/EWS/Exchange.asmx
>> ExternalUrl :
>> https://mail.mydomain.org/EWS/Exchange.asmx
>> AdminDisplayName :
>> ExchangeVersion : 0.1 (8.0.535.0)
>> DistinguishedName : CN=EWS (Default Web
>> Site),CN=HTTP,CN=Protocols,CN=SERVER,CN=Servers,CN=Exchange Administ
>> rative Group
>> (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=NICE,CN=Microsoft
>> Exchange,CN
>>
>> =Services,CN=Configuration,DC=mydomain,DC=org
>> Identity : SERVER\EWS (Default Web Site)
>> Guid : 6e18e2ab-256b-424e-ac5f-b4ea89f64c1f
>> ObjectCategory :
>> mydomain.org/Configuration/Schema/ms-Exch-Web-Services-Virtual-Directory
>> ObjectClass : {top, msExchVirtualDirectory,
>> msExchWebServicesVirtualDirectory}
>> WhenChanged : 3/30/2008 12:37:52 AM
>> WhenCreated : 8/7/2007 1:58:41 PM
>> OriginatingServer : anotherserver.child.mydomain.org
>> IsValid : True
>>
>>
>> The thing here is that the OriginatingServer is the sole Domain
>> Controller for a child domain (soon to be demoted) that is located in the
>> same Site as the Exchange 2007 box. Not sure what the OriginatingServer
>> does....
>>
>>
>> =============================================================================================================
>>
>> test-outlookwebservices
>>
>>
>> Id : 1003
>> Type : Information
>> Message : About to test AutoDiscover with the e-mail address
>> Administrator@mydomain.org.
>>
>> Id : 1007
>> Type : Information
>> Message : Testing server server.mydomain.org with the published name
>> https://server.mydomain.org/EWS/Exchange
>> .asmx & https://mail.mydomain.org/EWS/Exchange.asmx.
>>
>> Id : 1019
>> Type : Information
>> Message : Found a valid AutoDiscover service connection point. The
>> AutoDiscover URL on this object is
>> https://server.mydomain.org/autodiscover/autodiscover.xml.
>>
>> Id : 1006
>> Type : Information
>> Message : The Autodiscover service was contacted at
>> https://server.mydomain.org/autodiscover/autodiscover.xml.
>>
>> Id : 1016
>> Type : Success
>> Message : [EXCH]-Successfully contacted the AS service at
>> https://server.mydomain.org/EWS/Exchange.asmx. The elaps
>> ed time was 609 milliseconds.
>>
>> Id : 1015
>> Type : Success
>> Message : [EXCH]-Successfully contacted the OAB service at
>> https://server.mydomain.org/EWS/Exchange.asmx. The elap
>> sed time was 0 milliseconds.
>>
>> Id : 1014
>> Type : Success
>> Message : [EXCH]-Successfully contacted the UM service at
>> https://server.mydomain.org/UnifiedMessaging/Service.asm
>> x. The elapsed time was 796 milliseconds.
>>
>> Id : 1013
>> Type : Error
>> Message : When contacting https://mail.mydomain.org/EWS/Exchange.asmx
>> received the error The request failed with
>> HTTP status 401: Unauthorized.
>>
>> Id : 1016
>> Type : Error
>> Message : [EXPR]-Error when contacting the AS service at
>> https://mail.mydomain.org/EWS/Exchange.asmx. The elapsed
>> time was 93 milliseconds.
>>
>> Id : 1015
>> Type : Success
>> Message : [EXPR]-Successfully contacted the OAB service at
>> https://mail.mydomain.org/EWS/Exchange.asmx. The elaps
>> ed time was 0 milliseconds.
>>
>> Id : 1014
>> Type : Information
>> Message : [EXPR]-The UM is not configured for this user.
>>
>> Id : 1017
>> Type : Success
>> Message : [EXPR]-Successfully contacted the RPC/HTTP service at
>> https://mail.mydomain.org/Rpc. The elapsed time w
>> as 93 milliseconds.
>>
>> Id : 1006
>> Type : Success
>> Message : The Autodiscover service was tested successfully.
>>
>> Id : 1021
>> Type : Information
>> Message : The following web services generated errors.
>> As in EXPR
>> Please use the prior output to diagnose and correct the errors.
>>
>> So, just the one set of errors....
>>
>> =============================================================================================================
>>
>> Michael, if you can see something that I am not I would greatly
>> appreciate your assitance....
>
date: Fri, 19 Sep 2008 16:40:52 -0400
author: Cary W. Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Okay. I'm sure this is fixable.
The OOF errors are received by different sets of users, right? Not just
everyone in the police department?
Why not assign the A record for mail to be the internal IP address of the
server? Can you browse to https://mail.mydomain.org/owa and log in to OWA?
"Cary W. Shultz" wrote in message
news:eORW6gpGJHA.4408@TK2MSFTNGP04.phx.gbl...
> Michael,
>
> That is what I thought.....I wonder why the Domain Controller from a child
> domain is the one being used to do this? Anyway, I will look into this.
>
> And, that is the point that I forgot to add in the original post....no,
> all machines are joined to the domain. Well, except for the 65 computers
> that the Police Department use. That is a long story. I will save it for
> later. But, all the other machines are indeed joined to the
> domain....being authenticated by the local Domain Controller (which is
> also a GC).
>
> Regarding Basic Authentication - everything that I have seen suggests to
> not allow this. I will try it, however, just for troubleshooting
> purposes.
>
> Last point....."mail" host record.
>
> When I looked at the results of the test-outlookwebservices initially I
> saw that all of the "trying to access https://mail.mydomain.org/" failed.
> All of them. So, I thought for a second and it hit me that the in the
> internal DNS the AD-Integrated zone is "mydomain.org". So, there are all
> the sub folders (_msdcs, _tcp, _sites, _udp) and what not. However, the
> public DNS is also "mydomain.org" (or, better stated, the name that they
> have registered with the Registrar). So, if you open up IE and enter
> http://www.mydomain.org you will be taken to their web site. Obviously,
> the internal users - given this - would not be able to access their web
> site -UNLESS- I created a host record "www" and point it to the Public IP
> Address provided to us by the Web Hosting company. The same is true, in
> this case, for "mail". The internal users will never be able to resolve
> "mail.mydomain.org" because there is no A Recond in the internal DNS of
> "mail". So, I created "mail" and gave it the Public IP Address of the WAN
> Connection (Verizon, in this case). Once I did this all of the "remote
> name could not be resolved: 'mail.mydomain.org'" issues went
> away....except for the AS Service shown below...
>
> Thanks,
>
> Cary
date: Fri, 19 Sep 2008 16:51:15 -0400
author: Michael Dragone
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Mike,
No one in the Police Department is receiving an OOF error. They are all
using MS Outlook 2003 SP3. It is only the users with MS Outlook 2007 SP1.
All of the MS Outlook 2003 users are fine with OoO....I have personally
tested this with several users.
And, that is another idea! The 'mail' pointing to the internal IP Address
of the Exchange Server. I have always tried to stay away from doing this
(assuming that 'mail' points to the MX record. I will try this as well.
Will post back in a bit. Internally they have used https://server/OWA to
get to OWA (not many do that...they all have Outlook but a couple of them
use it to quickly check other mailboxes). From the outside world this is
the URL used to access OWA...without issue.
Thanks,
Cary
"Michael Dragone" wrote in message
news:egw64lpGJHA.4956@TK2MSFTNGP06.phx.gbl...
> Okay. I'm sure this is fixable.
>
> The OOF errors are received by different sets of users, right? Not just
> everyone in the police department?
>
> Why not assign the A record for mail to be the internal IP address of the
> server? Can you browse to https://mail.mydomain.org/owa and log in to OWA?
>
> "Cary W. Shultz" wrote in message
> news:eORW6gpGJHA.4408@TK2MSFTNGP04.phx.gbl...
>> Michael,
>>
>> That is what I thought.....I wonder why the Domain Controller from a
>> child domain is the one being used to do this? Anyway, I will look into
>> this.
>>
>> And, that is the point that I forgot to add in the original post....no,
>> all machines are joined to the domain. Well, except for the 65 computers
>> that the Police Department use. That is a long story. I will save it
>> for later. But, all the other machines are indeed joined to the
>> domain....being authenticated by the local Domain Controller (which is
>> also a GC).
>>
>> Regarding Basic Authentication - everything that I have seen suggests to
>> not allow this. I will try it, however, just for troubleshooting
>> purposes.
>>
>> Last point....."mail" host record.
>>
>> When I looked at the results of the test-outlookwebservices initially I
>> saw that all of the "trying to access https://mail.mydomain.org/" failed.
>> All of them. So, I thought for a second and it hit me that the in the
>> internal DNS the AD-Integrated zone is "mydomain.org". So, there are all
>> the sub folders (_msdcs, _tcp, _sites, _udp) and what not. However, the
>> public DNS is also "mydomain.org" (or, better stated, the name that they
>> have registered with the Registrar). So, if you open up IE and enter
>> http://www.mydomain.org you will be taken to their web site. Obviously,
>> the internal users - given this - would not be able to access their web
>> site -UNLESS- I created a host record "www" and point it to the Public IP
>> Address provided to us by the Web Hosting company. The same is true, in
>> this case, for "mail". The internal users will never be able to resolve
>> "mail.mydomain.org" because there is no A Recond in the internal DNS of
>> "mail". So, I created "mail" and gave it the Public IP Address of the
>> WAN Connection (Verizon, in this case). Once I did this all of the
>> "remote name could not be resolved: 'mail.mydomain.org'" issues went
>> away....except for the AS Service shown below...
>>
>> Thanks,
>>
>> Cary
>
date: Fri, 19 Sep 2008 16:58:36 -0400
author: Cary W. Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
I'm sorry, you said that in your initial post. I should've reread it. Your
Outlook 2003 users are fine because they're not using the Availability Web
service to modify their OOF settings; the Outlook 2007 users (since they're
running against Exchange 2007) are though.
There's one case that I know of where even if everything is set up correctly
you'll receive the "Server not available." error with Outlook 2007/Exchange
2007. It occurs if you log in as UserA who has full mailbox access to
UserB's mailbox, open UserB's entire mailbox and then try to set their OOF.
An MX record would point to mail, not the other way around. You likely don't
need an MX record in the zone on your internal DNS servers (it would likely
not cause a problem, but it's also likely not necessary), only on your
external ones.
"Cary W. Shultz" wrote in message
news:#MyI0qpGJHA.468@TK2MSFTNGP06.phx.gbl...
> Mike,
>
> No one in the Police Department is receiving an OOF error. They are all
> using MS Outlook 2003 SP3. It is only the users with MS Outlook 2007 SP1.
> All of the MS Outlook 2003 users are fine with OoO....I have personally
> tested this with several users.
>
> And, that is another idea! The 'mail' pointing to the internal IP Address
> of the Exchange Server. I have always tried to stay away from doing this
> (assuming that 'mail' points to the MX record. I will try this as well.
> Will post back in a bit. Internally they have used https://server/OWA to
> get to OWA (not many do that...they all have Outlook but a couple of them
> use it to quickly check other mailboxes). From the outside world this is
> the URL used to access OWA...without issue.
>
> Thanks,
>
> Cary
> "Michael Dragone" wrote in message
> news:egw64lpGJHA.4956@TK2MSFTNGP06.phx.gbl...
>> Okay. I'm sure this is fixable.
>>
>> The OOF errors are received by different sets of users, right? Not just
>> everyone in the police department?
>>
>> Why not assign the A record for mail to be the internal IP address of the
>> server? Can you browse to https://mail.mydomain.org/owa and log in to
>> OWA?
>>
>> "Cary W. Shultz" wrote in message
>> news:eORW6gpGJHA.4408@TK2MSFTNGP04.phx.gbl...
>>> Michael,
>>>
>>> That is what I thought.....I wonder why the Domain Controller from a
>>> child domain is the one being used to do this? Anyway, I will look into
>>> this.
>>>
>>> And, that is the point that I forgot to add in the original post....no,
>>> all machines are joined to the domain. Well, except for the 65
>>> computers that the Police Department use. That is a long story. I will
>>> save it for later. But, all the other machines are indeed joined to the
>>> domain....being authenticated by the local Domain Controller (which is
>>> also a GC).
>>>
>>> Regarding Basic Authentication - everything that I have seen suggests to
>>> not allow this. I will try it, however, just for troubleshooting
>>> purposes.
>>>
>>> Last point....."mail" host record.
>>>
>>> When I looked at the results of the test-outlookwebservices initially I
>>> saw that all of the "trying to access https://mail.mydomain.org/"
>>> failed. All of them. So, I thought for a second and it hit me that the
>>> in the internal DNS the AD-Integrated zone is "mydomain.org". So, there
>>> are all the sub folders (_msdcs, _tcp, _sites, _udp) and what not.
>>> However, the public DNS is also "mydomain.org" (or, better stated, the
>>> name that they have registered with the Registrar). So, if you open up
>>> IE and enter http://www.mydomain.org you will be taken to their web
>>> site. Obviously, the internal users - given this - would not be able to
>>> access their web site -UNLESS- I created a host record "www" and point
>>> it to the Public IP Address provided to us by the Web Hosting company.
>>> The same is true, in this case, for "mail". The internal users will
>>> never be able to resolve "mail.mydomain.org" because there is no A
>>> Recond in the internal DNS of "mail". So, I created "mail" and gave it
>>> the Public IP Address of the WAN Connection (Verizon, in this case).
>>> Once I did this all of the "remote name could not be resolved:
>>> 'mail.mydomain.org'" issues went away....except for the AS Service shown
>>> below...
>>>
>>> Thanks,
>>>
>>> Cary
>>
>
>
date: Fri, 19 Sep 2008 20:18:30 -0400
author: Michael Dragone
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Michael,
No worries. I used to be an MVP for AD and would answer a ton of
questions....
Getting the facts turned around happens sometimes, especially in a post with
as much verbiage as mine!
Anyway, I thought of that situation as well. Not the case, unfortunately.
Pretty much no one in this environment has access to anyone's mailbox
[neither to the full mailbox nor to part of the mailbox (read: Calendar or
Contact, for example)]. So, Joe logs on to the WINXP SP3 box as Joe and
opens up Joe's Mailbox. Sally logs on to the WINXP SP3 box as Sally and
open's up Sally' mailbox. Everyone has his/her own computer and their is no
'roaming'....in either sense of that word. And, on top of that, no one has
access to anyone else's mailbox.
And, the MX Record is indeed only in the Public DNS (IX WebHosting - would
not suggest that anyone use them...can not do .txt records (read: SPF) and
can not do SRV records). That Public MX record - which points to the Public
WAN IP Address - is indeed 'mail'. That has worked just swell since I set
it up last year. I simply set up - in the Internal Forward Lookup Zone -
that Host record 'mail' and then pointed it - initiall - to that same Public
IP Address as the MX Record. Simply because the internal domain domain
(mydomain.org) is the same as the public domain name (mydomain.org) and the
internal users could not resolve 'mail.mydomain.org'. This did not resolve
the issues. So, at your suggestion, I changed the internal Host 'mail' to
point to the internal IP Address of the Exchange 2007 Server (just one box).
Still, no love!
Also, Internet Explorer is not misconfigured (Proxy Settings) and there is
no ISA or anything like this involved. Funny thing is...when these machines
were put in place (read: the new Dell workstations running MS Office 2007)
the MS Outlook configured the profile automagically. It pulled the user's
name and the mailbox and there it was! Hey, about the only thing that I
have not done is look at the local machine and check out to log file...see
what is *not* going on there! I may just do that still....
Anyway, I am pretty much throwing in the towel on this one and going to call
MS-PSS because I have spent a ton of time on this. Way more time than I
should have (but I love a good challenge!).
I will let you know what the problem was once we figure it out.
I wonder if we have this issue at any other clients. Several of our clients
have EXCH2007 (I set up all bt two of them) and are not starting to move to
MS Office 2007.
Mike, Thanks for your persistence on this. It is starting to get a little
frustrating. But, like I said, I like a good challenge. I am just running
out of time (from a buiness perspective...not from a technical perspective).
Thanks,
Cary
"Michael Dragone" wrote in message
news:ukmqsZrGJHA.3640@TK2MSFTNGP04.phx.gbl...
> I'm sorry, you said that in your initial post. I should've reread it. Your
> Outlook 2003 users are fine because they're not using the Availability Web
> service to modify their OOF settings; the Outlook 2007 users (since
> they're running against Exchange 2007) are though.
>
> There's one case that I know of where even if everything is set up
> correctly you'll receive the "Server not available." error with Outlook
> 2007/Exchange 2007. It occurs if you log in as UserA who has full mailbox
> access to UserB's mailbox, open UserB's entire mailbox and then try to set
> their OOF.
>
> An MX record would point to mail, not the other way around. You likely
> don't need an MX record in the zone on your internal DNS servers (it would
> likely not cause a problem, but it's also likely not necessary), only on
> your external ones.
>
> "Cary W. Shultz" wrote in message
> news:#MyI0qpGJHA.468@TK2MSFTNGP06.phx.gbl...
>> Mike,
>>
>> No one in the Police Department is receiving an OOF error. They are all
>> using MS Outlook 2003 SP3. It is only the users with MS Outlook 2007
>> SP1. All of the MS Outlook 2003 users are fine with OoO....I have
>> personally tested this with several users.
>>
>> And, that is another idea! The 'mail' pointing to the internal IP
>> Address of the Exchange Server. I have always tried to stay away from
>> doing this (assuming that 'mail' points to the MX record. I will try
>> this as well. Will post back in a bit. Internally they have used
>> https://server/OWA to get to OWA (not many do that...they all have
>> Outlook but a couple of them use it to quickly check other mailboxes).
>> From the outside world this is the URL used to access OWA...without
>> issue.
>>
>> Thanks,
>>
>> Cary
>> "Michael Dragone" wrote in message
>> news:egw64lpGJHA.4956@TK2MSFTNGP06.phx.gbl...
>>> Okay. I'm sure this is fixable.
>>>
>>> The OOF errors are received by different sets of users, right? Not just
>>> everyone in the police department?
>>>
>>> Why not assign the A record for mail to be the internal IP address of
>>> the server? Can you browse to https://mail.mydomain.org/owa and log in
>>> to OWA?
>>>
>>> "Cary W. Shultz" wrote in message
>>> news:eORW6gpGJHA.4408@TK2MSFTNGP04.phx.gbl...
>>>> Michael,
>>>>
>>>> That is what I thought.....I wonder why the Domain Controller from a
>>>> child domain is the one being used to do this? Anyway, I will look
>>>> into this.
>>>>
>>>> And, that is the point that I forgot to add in the original post....no,
>>>> all machines are joined to the domain. Well, except for the 65
>>>> computers that the Police Department use. That is a long story. I
>>>> will save it for later. But, all the other machines are indeed joined
>>>> to the domain....being authenticated by the local Domain Controller
>>>> (which is also a GC).
>>>>
>>>> Regarding Basic Authentication - everything that I have seen suggests
>>>> to not allow this. I will try it, however, just for troubleshooting
>>>> purposes.
>>>>
>>>> Last point....."mail" host record.
>>>>
>>>> When I looked at the results of the test-outlookwebservices initially I
>>>> saw that all of the "trying to access https://mail.mydomain.org/"
>>>> failed. All of them. So, I thought for a second and it hit me that the
>>>> in the internal DNS the AD-Integrated zone is "mydomain.org". So,
>>>> there are all the sub folders (_msdcs, _tcp, _sites, _udp) and what
>>>> not. However, the public DNS is also "mydomain.org" (or, better stated,
>>>> the name that they have registered with the Registrar). So, if you
>>>> open up IE and enter http://www.mydomain.org you will be taken to their
>>>> web site. Obviously, the internal users - given this - would not be
>>>> able to access their web site -UNLESS- I created a host record "www"
>>>> and point it to the Public IP Address provided to us by the Web Hosting
>>>> company. The same is true, in this case, for "mail". The internal
>>>> users will never be able to resolve "mail.mydomain.org" because there
>>>> is no A Recond in the internal DNS of "mail". So, I created "mail" and
>>>> gave it the Public IP Address of the WAN Connection (Verizon, in this
>>>> case). Once I did this all of the "remote name could not be resolved:
>>>> 'mail.mydomain.org'" issues went away....except for the AS Service
>>>> shown below...
>>>>
>>>> Thanks,
>>>>
>>>> Cary
>>>
>>
>>
date: Sat, 20 Sep 2008 08:11:50 -0400
author: Cary Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
On Fri, 19 Sep 2008 14:40:44 -0400, "Cary W. Shultz"
wrote:
[ snip ]
>Issue is that when a user (MS Outlook 2007 SP1) tries to use Out of Office
>he/she gets the error message "blah! blah! Server not available". Yes, OWA
>works just fine. Yes, MS Outlook 2003 SP3 works just fine.
>
>This affects users in all four Sites. Yes, there are users in the Site in
>which the EXCH2007 box is located.
Sounds like the Outlook 2007 clients are having a problem connecting
to the CAS server. That's where OL2K is setting the OOO messages.
>The DigiCert Cert appears to be fine. I did not do it (probably why it is
>fine!). Using OWA internally or externally does not present us with the
>Cert error. We have about 65 users making use of Outlook Anywhere without
>any issues. They are all MS Outlook 2003, so no OoO issues with them
>(Thank, God! These 65 users are the Police Department!).
Well, techically, they're using RPC-Over-HTTPS, not Outlook Anywhere.
They're also setting the OOO status directly in their mailbox, not
through the CAS.
>I tested MS Outlook with two users (in different Sites...same results) by
>holding down the Ctrl key and right-clicking the MS Outlook icon in the
>system tray and then selecting 'Test E-Mail Configuration". We receive -
>everytime - the "Can not determine your settings" error message.
Well, so far you're headed down the same path -- a problem connecting
to the CAS.
BTW, unchecking the "Use Guessmart" and "Secure Guessmart
Authentication" boxes will give you results that are less cluttered.
>Looking in
>the Logs tab gives us lots of info. None of it seems to point me in the
>direction of a solution, though.
When it works you'll probably only see three lines in that tab. :-)
>I have looked at all of the get-xxxxVirtualDirectory | fl
>
>[get-ClientAccessServer | fl
>get-OABVirtualDirectory | fl
>get-WebServicesVirtualDirectory | fl
>get-UMVirtualDirectory | fl]
What about the get-autodiscovervirtualdirectory?
>used the test-outlookwebservices | fl. There were several errors in the
>test-outlookwebservices that I was able to resolve (see next paragraph for
>more on that).
>
>The internal domain name (mydomain.org) is the same as the external domian
>name (mydomain.org) so there was an issue resolving 'mail.mydomain.org'. I
>created - in the internal FLZ
FLZ? Wazzat, a dyslexic DNS? :-)
>for 'mydomain.org' - a Host record 'mail' and
>pointed it to the WAN IP Address and those issues went away.
I'm gonna guess that if you create a way to resolve the
autodiscover.mydomain.org name from inside your organization that
you'd fix the OOO problem, too.
>I have checked IIS and ensured that what is supposed to be is and what is
>not supposed to be is not (how is that for 'vague'). For example, anonymous
>access is not checked for the Autodiscover Virtual Directory. Basic and
>Integrated Authentication are enabled for the AutoDiscover Virtual
>Directory.
Sounds good.
>I have ensured that the SCP is indeed there and correct. It is.
>
>I can access the https://server.mydomain.org/autodiscover/autodiscover.xml
>and all the other URLs (https://server.mydomain.org/EWS/Exchange.asmx, for
>example).
>
>I have created a Host record in the Public DNS of 'autodiscover' and pointed
>it to the WAN IP Address. This does not seem to have helped.
Why not the IP address of the internal NIC? The folks having a problem
are inside the network, aren't they?
>I am not able
>to create an SRV Record as the company that our client is using does not
>allow for SRV Records (or SPF records...).
How's the AD dealing with that? Or are you referring to some external
DNS and not to your internal DNS?
---
Rich Matheisen
MCSE+I, Exchange MVP
date: Sat, 20 Sep 2008 14:16:38 -0400
author: Rich Matheisen [MVP]
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Rich, greetings from Salem, VA (well, we moved from Roanoke to Salem a year
ago)...
In-line...
"Rich Matheisen [MVP]" wrote in message
news:83ead4hc7vbcrf9bc6bjq0r3ooq4qbutac@4ax.com...
> On Fri, 19 Sep 2008 14:40:44 -0400, "Cary W. Shultz"
> wrote:
>
> [ snip ]
>
>>Issue is that when a user (MS Outlook 2007 SP1) tries to use Out of Office
>>he/she gets the error message "blah! blah! Server not available". Yes,
>>OWA
>>works just fine. Yes, MS Outlook 2003 SP3 works just fine.
>>
>>This affects users in all four Sites. Yes, there are users in the Site in
>>which the EXCH2007 box is located.
>
> Sounds like the Outlook 2007 clients are having a problem connecting
> to the CAS server. That's where OL2K is setting the OOO messages.
Pinging the sole EXCH2007 box via IP Address and via NetBIOS name and via
FQDN has never been a problem....so, not sure what other way there is. But,
I believe that you are correct....somewhere there is a problem. Could it
possibly be the "OriginatingServer" used? More on this later.
>>The DigiCert Cert appears to be fine. I did not do it (probably why it is
>>fine!). Using OWA internally or externally does not present us with the
>>Cert error. We have about 65 users making use of Outlook Anywhere without
>>any issues. They are all MS Outlook 2003, so no OoO issues with them
>>(Thank, God! These 65 users are the Police Department!).
>
> Well, techically, they're using RPC-Over-HTTPS, not Outlook Anywhere.
> They're also setting the OOO status directly in their mailbox, not
> through the CAS.
Well, technically you are correct! ;-) Outlook 2003 would be using RPC
over HTTPS. Outlook 2007 would be using Outlook Anywhere. I wondered if
anyone would correct that....thanks for correcting this, Rich. Someone else
reading this would make the same *mistake* that I did....looking soley at
the back-end without taking the front-end into consideration.
>>I tested MS Outlook with two users (in different Sites...same results) by
>>holding down the Ctrl key and right-clicking the MS Outlook icon in the
>>system tray and then selecting 'Test E-Mail Configuration". We receive -
>>everytime - the "Can not determine your settings" error message.
>
> Well, so far you're headed down the same path -- a problem connecting
> to the CAS.
Yeppers. Still wondering how, though. Obviously I am missing something.
> BTW, unchecking the "Use Guessmart" and "Secure Guessmart
> Authentication" boxes will give you results that are less cluttered.
Rich, great tip. I did not uncheck those two the first 100 times I ran it
(a bit of an exxageration, but not much!) and then finally unchecked them.
Lo and behold...much more manageable! So, anyone reading this post please
take this advice seriously. It really makes things much more manageable.
>
>>Looking in
>>the Logs tab gives us lots of info. None of it seems to point me in the
>>direction of a solution, though.
>
> When it works you'll probably only see three lines in that tab. :-)
"when"......looking forward to that!
>>I have looked at all of the get-xxxxVirtualDirectory | fl
>>
>>[get-ClientAccessServer | fl
>>get-OABVirtualDirectory | fl
>>get-WebServicesVirtualDirectory | fl
>>get-UMVirtualDirectory | fl]
>
> What about the get-autodiscovervirtualdirectory?
Rich - Man, can not gete anything passed you today! I realized that also
yesterday and ran that. Guess what?
InternalURL and ExternalURL were both blank. Son of a bugger! I used the
Set-AutodiscoverVirtualDirectory -externalUrl
https://mail.mydomain.org/autodiscover/autodiscover.xml and then
Set-AutodiscoverVirtualDirectory -internalUrl
https://server.mydomain.org/autodiscover/autodiscover.xml and set the
Identity to "Autodiscover (Default Web Site)" at the prompt after each
entry. I had a problem specifying the identity within the command so I
specified it after.
Also, the authentication was 'basic, ntlm and windows integrated" - if I
remember correctly.
>>used the test-outlookwebservices | fl. There were several errors in the
>>test-outlookwebservices that I was able to resolve (see next paragraph for
>>more on that).
>>
>>The internal domain name (mydomain.org) is the same as the external domian
>>name (mydomain.org) so there was an issue resolving 'mail.mydomain.org'.
>>I
>>created - in the internal FLZ
>
> FLZ? Wazzat, a dyslexic DNS? :-)
(F)orward (L)ookup (Z)one.........Sorry. I almost always use FLZ and RLZ
(Reverse Lookup Zone).
>>for 'mydomain.org' - a Host record 'mail' and
>>pointed it to the WAN IP Address and those issues went away.
>
> I'm gonna guess that if you create a way to resolve the
> autodiscover.mydomain.org name from inside your organization that
> you'd fix the OOO problem, too.
Rich, I wish that were the case. When I installed Exchange 2007 (no SP1 at
that time...have since *upgraded* to SP1) a good long time ago one of the
first things that I did was create a Host record 'autodiscover' and pointed
it to the IP Address of the CAS Server (well, Exchange 2007 Server since
there is only one EXCH2007 box....). So, there is indeed a Host record of
autodiscover that points to 192.168.0.46 (internal IP Address, obviously) in
the [here we go] internal FLZ. Additionally, the creation of the host
record in the FLZ also created a record in the RLZ (see above). So,
autodiscover.mydomain.org (internal name) is indeed 'findable'. And, I have
tested this - pinged 'autodiscover' and 'autodiscover.mydomain.org' and
'192.168.0.46' and there are no issues. The first two resolved to
192.168.0.46 and the other one...well, no issues there.
Here is the results of the Get-AutodiscoverVirtualDirectory | FL
==============================================================================================================
Name : Autodiscover (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication : True
DigestAuthentication : False
WindowsAuthentication : True
MetabasePath :
IIS://server.mydomain.org/W3SVC/1/ROOT/Autodiscover
Path : C:\Program Files\Microsoft\Exchange
Server\ClientAccess\Autodiscover
Server : server
InternalUrl :
https://server.mydomain.org/autodiscover/autodiscover.xml
ExternalUrl :
https://mail.mydomain.org/autodiscover/autodiscover.xml
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=Autodiscover (Default Web
Site),CN=HTTP,CN=Protocols,CN=server,CN=Servers,CN=Exchange
Administrative Group
(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=SWEET,CN=Microsoft Ex
change,CN=Services,CN=Configuration,DC=mydomain,DC=org
Identity : server\Autodiscover (Default Web Site)
Guid : 12c10160-8d74-41e6-abc5-efd00a5c11a8
ObjectCategory :
mydomain.org/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
ObjectClass : {top, msExchVirtualDirectory,
msExchAutoDiscoverVirtualDirectory}
WhenChanged : 9/19/2008 7:48:22 PM
WhenCreated : 8/7/2007 1:58:29 PM
OriginatingServer : dc01.mydomain.org
IsValid : True
==============================================================================================================
Here is the thing that I find interesting......The 'OriginatingServer' in
this case is one of the two Domain Controllers in the 'mydomain.org' Parent
Domain. In the other tests the OriginatingServer was *always* the Domain
Controller from the child domain (located in the same AD Site as the ECH2007
box...). I am thinking that this is playing a role in this problem...but
not sure.
>>I have checked IIS and ensured that what is supposed to be is and what is
>>not supposed to be is not (how is that for 'vague'). For example,
>>anonymous
>>access is not checked for the Autodiscover Virtual Directory. Basic and
>>Integrated Authentication are enabled for the AutoDiscover Virtual
>>Directory.
>
> Sounds good.
>
>>I have ensured that the SCP is indeed there and correct. It is.
>>
>>I can access the https://server.mydomain.org/autodiscover/autodiscover.xml
>>and all the other URLs (https://server.mydomain.org/EWS/Exchange.asmx, for
>>example).
>>
>>I have created a Host record in the Public DNS of 'autodiscover' and
>>pointed
>>it to the WAN IP Address. This does not seem to have helped.
>
> Why not the IP address of the internal NIC? The folks having a problem
> are inside the network, aren't they?
Rich, as mentioned, the internal 'autodiscover' already exists. I have done
a ton of reading and I am seeing everywhere that we need an SRV record in
the Public DNS that points to the WAN IP Address (so, the IP Address that
resolves mail.mydomain.org...) for the people using RPC over HTTPS / Outlook
Anywhere. But, yes - the users having this issue are all inside the
network. Now, the Police Department is outside the network (the guys/gals
using "RPC over HTTPS"...but, they are using MS Outlook 2003 so no issues.
I sure want to resolve this before they move to MS Outlook 2007).
>
>>I am not able
>>to create an SRV Record as the company that our client is using does not
>>allow for SRV Records (or SPF records...).
>
> How's the AD dealing with that? Or are you referring to some external
> DNS and not to your internal DNS?
Rich....the internal HOST record for 'autodiscover'
(autodiscover.mydomain.org = 192.168.0.46) has always been there. So, in
this case I am refering to an SRV Record in the Public DNS Zone....Just
thinking ahead for when the Police Department moves from MS Outlook 2003 to
MS Outlook 2007 (or whatever it might be at the time they do this)......
As always I appreciate your help.
> ---
> Rich Matheisen
> MCSE+I, Exchange MVP
date: Sat, 20 Sep 2008 16:06:58 -0400
author: Cary Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Rich, one more thing...
I checked the Get-OutlookProvider for the three providers (EXCH, EXPR and
WEB) and the values were missing.
So, I used Set-OutlookProvider -Id EXPR -Server SERVER (and likewise for -ID
EXPR and ID WEB). This did not help.
BTW - I have seen in several places on the Internet that the name of
the -SERVER entry needs to be entered in all Caps! Is this true?
So, set-OutlookProvider -ID EXCH -Server server would be a problem while
set-OutlookProvider -ID EXCH -Server SERVER would be fine.
Thanks,
Cary
"Rich Matheisen [MVP]" wrote in message
news:83ead4hc7vbcrf9bc6bjq0r3ooq4qbutac@4ax.com...
> On Fri, 19 Sep 2008 14:40:44 -0400, "Cary W. Shultz"
> wrote:
>
> [ snip ]
>
>>Issue is that when a user (MS Outlook 2007 SP1) tries to use Out of Office
>>he/she gets the error message "blah! blah! Server not available". Yes,
>>OWA
>>works just fine. Yes, MS Outlook 2003 SP3 works just fine.
>>
>>This affects users in all four Sites. Yes, there are users in the Site in
>>which the EXCH2007 box is located.
>
> Sounds like the Outlook 2007 clients are having a problem connecting
> to the CAS server. That's where OL2K is setting the OOO messages.
>
>>The DigiCert Cert appears to be fine. I did not do it (probably why it is
>>fine!). Using OWA internally or externally does not present us with the
>>Cert error. We have about 65 users making use of Outlook Anywhere without
>>any issues. They are all MS Outlook 2003, so no OoO issues with them
>>(Thank, God! These 65 users are the Police Department!).
>
> Well, techically, they're using RPC-Over-HTTPS, not Outlook Anywhere.
> They're also setting the OOO status directly in their mailbox, not
> through the CAS.
>
>>I tested MS Outlook with two users (in different Sites...same results) by
>>holding down the Ctrl key and right-clicking the MS Outlook icon in the
>>system tray and then selecting 'Test E-Mail Configuration". We receive -
>>everytime - the "Can not determine your settings" error message.
>
> Well, so far you're headed down the same path -- a problem connecting
> to the CAS.
>
> BTW, unchecking the "Use Guessmart" and "Secure Guessmart
> Authentication" boxes will give you results that are less cluttered.
>
>>Looking in
>>the Logs tab gives us lots of info. None of it seems to point me in the
>>direction of a solution, though.
>
> When it works you'll probably only see three lines in that tab. :-)
>
>>I have looked at all of the get-xxxxVirtualDirectory | fl
>>
>>[get-ClientAccessServer | fl
>>get-OABVirtualDirectory | fl
>>get-WebServicesVirtualDirectory | fl
>>get-UMVirtualDirectory | fl]
>
> What about the get-autodiscovervirtualdirectory?
>
>>used the test-outlookwebservices | fl. There were several errors in the
>>test-outlookwebservices that I was able to resolve (see next paragraph for
>>more on that).
>>
>>The internal domain name (mydomain.org) is the same as the external domian
>>name (mydomain.org) so there was an issue resolving 'mail.mydomain.org'.
>>I
>>created - in the internal FLZ
>
> FLZ? Wazzat, a dyslexic DNS? :-)
>
>>for 'mydomain.org' - a Host record 'mail' and
>>pointed it to the WAN IP Address and those issues went away.
>
> I'm gonna guess that if you create a way to resolve the
> autodiscover.mydomain.org name from inside your organization that
> you'd fix the OOO problem, too.
>
>>I have checked IIS and ensured that what is supposed to be is and what is
>>not supposed to be is not (how is that for 'vague'). For example,
>>anonymous
>>access is not checked for the Autodiscover Virtual Directory. Basic and
>>Integrated Authentication are enabled for the AutoDiscover Virtual
>>Directory.
>
> Sounds good.
>
>>I have ensured that the SCP is indeed there and correct. It is.
>>
>>I can access the https://server.mydomain.org/autodiscover/autodiscover.xml
>>and all the other URLs (https://server.mydomain.org/EWS/Exchange.asmx, for
>>example).
>>
>>I have created a Host record in the Public DNS of 'autodiscover' and
>>pointed
>>it to the WAN IP Address. This does not seem to have helped.
>
> Why not the IP address of the internal NIC? The folks having a problem
> are inside the network, aren't they?
>
>>I am not able
>>to create an SRV Record as the company that our client is using does not
>>allow for SRV Records (or SPF records...).
>
> How's the AD dealing with that? Or are you referring to some external
> DNS and not to your internal DNS?
> ---
> Rich Matheisen
> MCSE+I, Exchange MVP
date: Sat, 20 Sep 2008 16:12:32 -0400
author: Cary Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Hmm. This IS interesting!
Have you already tried hitting up
https://server.mydomain.org/EWS/Exchange.asmx and
https://mail.mydomain.org/EWS/Exchange.asmx from Internet Explorer?
"Cary Shultz" wrote in message
news:efcQJpxGJHA.4296@TK2MSFTNGP02.phx.gbl...
> Michael,
>
> No worries. I used to be an MVP for AD and would answer a ton of
> questions....
>
> Getting the facts turned around happens sometimes, especially in a post
> with as much verbiage as mine!
>
> Anyway, I thought of that situation as well. Not the case, unfortunately.
> Pretty much no one in this environment has access to anyone's mailbox
> [neither to the full mailbox nor to part of the mailbox (read: Calendar or
> Contact, for example)]. So, Joe logs on to the WINXP SP3 box as Joe and
> opens up Joe's Mailbox. Sally logs on to the WINXP SP3 box as Sally and
> open's up Sally' mailbox. Everyone has his/her own computer and their is
> no 'roaming'....in either sense of that word. And, on top of that, no one
> has access to anyone else's mailbox.
>
> And, the MX Record is indeed only in the Public DNS (IX WebHosting - would
> not suggest that anyone use them...can not do .txt records (read: SPF) and
> can not do SRV records). That Public MX record - which points to the
> Public WAN IP Address - is indeed 'mail'. That has worked just swell
> since I set it up last year. I simply set up - in the Internal Forward
> Lookup Zone - that Host record 'mail' and then pointed it - initiall - to
> that same Public IP Address as the MX Record. Simply because the internal
> domain domain (mydomain.org) is the same as the public domain name
> (mydomain.org) and the internal users could not resolve
> 'mail.mydomain.org'. This did not resolve the issues. So, at your
> suggestion, I changed the internal Host 'mail' to point to the internal IP
> Address of the Exchange 2007 Server (just one box). Still, no love!
>
> Also, Internet Explorer is not misconfigured (Proxy Settings) and there is
> no ISA or anything like this involved. Funny thing is...when these
> machines were put in place (read: the new Dell workstations running MS
> Office 2007) the MS Outlook configured the profile automagically. It
> pulled the user's name and the mailbox and there it was! Hey, about the
> only thing that I have not done is look at the local machine and check out
> to log file...see what is *not* going on there! I may just do that
> still....
>
> Anyway, I am pretty much throwing in the towel on this one and going to
> call MS-PSS because I have spent a ton of time on this. Way more time
> than I should have (but I love a good challenge!).
>
> I will let you know what the problem was once we figure it out.
>
> I wonder if we have this issue at any other clients. Several of our
> clients have EXCH2007 (I set up all bt two of them) and are not starting
> to move to MS Office 2007.
>
> Mike, Thanks for your persistence on this. It is starting to get a little
> frustrating. But, like I said, I like a good challenge. I am just
> running out of time (from a buiness perspective...not from a technical
> perspective).
>
> Thanks,
>
> Cary
date: Sat, 20 Sep 2008 16:57:19 -0400
author: Michael Dragone
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Michael,
Absolutely....it works. But, it redirects to another file....forget to what
right now. Will remote in and report...hold on!
Cary
"Michael Dragone" wrote in message
news:eOw47N2GJHA.1304@TK2MSFTNGP02.phx.gbl...
> Hmm. This IS interesting!
>
> Have you already tried hitting up
> https://server.mydomain.org/EWS/Exchange.asmx and
> https://mail.mydomain.org/EWS/Exchange.asmx from Internet Explorer?
>
> "Cary Shultz" wrote in message
> news:efcQJpxGJHA.4296@TK2MSFTNGP02.phx.gbl...
>> Michael,
>>
>> No worries. I used to be an MVP for AD and would answer a ton of
>> questions....
>>
>> Getting the facts turned around happens sometimes, especially in a post
>> with as much verbiage as mine!
>>
>> Anyway, I thought of that situation as well. Not the case,
>> unfortunately. Pretty much no one in this environment has access to
>> anyone's mailbox [neither to the full mailbox nor to part of the mailbox
>> (read: Calendar or Contact, for example)]. So, Joe logs on to the WINXP
>> SP3 box as Joe and opens up Joe's Mailbox. Sally logs on to the WINXP
>> SP3 box as Sally and open's up Sally' mailbox. Everyone has his/her own
>> computer and their is no 'roaming'....in either sense of that word. And,
>> on top of that, no one has access to anyone else's mailbox.
>>
>> And, the MX Record is indeed only in the Public DNS (IX WebHosting -
>> would not suggest that anyone use them...can not do .txt records (read:
>> SPF) and can not do SRV records). That Public MX record - which points
>> to the Public WAN IP Address - is indeed 'mail'. That has worked just
>> swell since I set it up last year. I simply set up - in the Internal
>> Forward Lookup Zone - that Host record 'mail' and then pointed it -
>> initiall - to that same Public IP Address as the MX Record. Simply
>> because the internal domain domain (mydomain.org) is the same as the
>> public domain name (mydomain.org) and the internal users could not
>> resolve 'mail.mydomain.org'. This did not resolve the issues. So, at
>> your suggestion, I changed the internal Host 'mail' to point to the
>> internal IP Address of the Exchange 2007 Server (just one box). Still, no
>> love!
>>
>> Also, Internet Explorer is not misconfigured (Proxy Settings) and there
>> is no ISA or anything like this involved. Funny thing is...when these
>> machines were put in place (read: the new Dell workstations running MS
>> Office 2007) the MS Outlook configured the profile automagically. It
>> pulled the user's name and the mailbox and there it was! Hey, about the
>> only thing that I have not done is look at the local machine and check
>> out to log file...see what is *not* going on there! I may just do that
>> still....
>>
>> Anyway, I am pretty much throwing in the towel on this one and going to
>> call MS-PSS because I have spent a ton of time on this. Way more time
>> than I should have (but I love a good challenge!).
>>
>> I will let you know what the problem was once we figure it out.
>>
>> I wonder if we have this issue at any other clients. Several of our
>> clients have EXCH2007 (I set up all bt two of them) and are not starting
>> to move to MS Office 2007.
>>
>> Mike, Thanks for your persistence on this. It is starting to get a
>> little frustrating. But, like I said, I like a good challenge. I am
>> just running out of time (from a buiness perspective...not from a
>> technical perspective).
>>
>> Thanks,
>>
>> Cary
>
date: Sat, 20 Sep 2008 18:25:25 -0400
author: Cary Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Michael,
Here are the results of the internal URL:
I enter the following in IE: https://server.mydomain.org/ewa/exchange.asmx
I am prompted for credentials (with the standard Basic Authentication popup)
and upon entering credentials I am redirected to:
https://server.mydomain.org/ews/Services.wsdl
I have done this on the Exchange Server and on a workstation (all
workstations are joined to the domain) and on a server in the domain - using
different credentials (administrator and other 'normal' user accounts). All
results are the same.
Here are the results from the External URL:
Upon entering the external URL in IE:
https://mail.mydomain.org/ews/exchanges.asmx I am, again, prompted for
credentials with the standard Basic Authentication popup. I enter
credentials in the format Domain\username with password. I am then
redirected to:
https://mail.mydomain.org/ews/Services.wsdl
Again, this is entered into IE while outside the network (sitting at home on
my laptop....not joined to the domain). Additionally, I did this several
times, using different sets of credentials (administrator and 'normal' user
accounts).
Now, sitting on the EXCH2007 box itself results in an error (the http error
401.1). This is with the host record 'mail' pointing to the internal IP
Address. I am going to change it to the Public IP Address and see what
happens! Hold on....
Okay...with the host record 'mail' pointing to the internal IP Address of
the Exchange Server I understand why I am getting theI am getting the HTTP
error. I enter the credentials and am prompted again and then again and
then I get the error message (HTTP 401.1). So, I changed it the Public IP
Address and get the same thing. But, only when running this test on the
EXCH2007 box. From other machines (all joined to the domain) I am prompted
for credentials and then am redirected to the /Services.wsdl page.
So, when I run the test-outlookwebservices | fl on the EXCH2007 box it is
exactly this test that is failing with:
ID: 1013
Type: Error
Message: when contacting https://mail.mydomain.org/ewa/exchange.asmx
received the error The Request failed with HTTP Status 401: Unathorized
ID: 1016
Trpe: Error
Message: [EXPR]-Error when contacting the AS Service at
https://mail.mydomain.org/ews/exchange.asmx. The elapsed time was 108
milliseconds.
All other tests complete successfully.
Does this make any sense?
I am scratching my head on this......obviously I am missing something....but
where?!?!?!?
Thanks,
Cary
"Michael Dragone" wrote in message
news:eOw47N2GJHA.1304@TK2MSFTNGP02.phx.gbl...
> Hmm. This IS interesting!
>
> Have you already tried hitting up
> https://server.mydomain.org/EWS/Exchange.asmx and
> https://mail.mydomain.org/EWS/Exchange.asmx from Internet Explorer?
>
> "Cary Shultz" wrote in message
> news:efcQJpxGJHA.4296@TK2MSFTNGP02.phx.gbl...
>> Michael,
>>
>> No worries. I used to be an MVP for AD and would answer a ton of
>> questions....
>>
>> Getting the facts turned around happens sometimes, especially in a post
>> with as much verbiage as mine!
>>
>> Anyway, I thought of that situation as well. Not the case,
>> unfortunately. Pretty much no one in this environment has access to
>> anyone's mailbox [neither to the full mailbox nor to part of the mailbox
>> (read: Calendar or Contact, for example)]. So, Joe logs on to the WINXP
>> SP3 box as Joe and opens up Joe's Mailbox. Sally logs on to the WINXP
>> SP3 box as Sally and open's up Sally' mailbox. Everyone has his/her own
>> computer and their is no 'roaming'....in either sense of that word. And,
>> on top of that, no one has access to anyone else's mailbox.
>>
>> And, the MX Record is indeed only in the Public DNS (IX WebHosting -
>> would not suggest that anyone use them...can not do .txt records (read:
>> SPF) and can not do SRV records). That Public MX record - which points
>> to the Public WAN IP Address - is indeed 'mail'. That has worked just
>> swell since I set it up last year. I simply set up - in the Internal
>> Forward Lookup Zone - that Host record 'mail' and then pointed it -
>> initiall - to that same Public IP Address as the MX Record. Simply
>> because the internal domain domain (mydomain.org) is the same as the
>> public domain name (mydomain.org) and the internal users could not
>> resolve 'mail.mydomain.org'. This did not resolve the issues. So, at
>> your suggestion, I changed the internal Host 'mail' to point to the
>> internal IP Address of the Exchange 2007 Server (just one box). Still, no
>> love!
>>
>> Also, Internet Explorer is not misconfigured (Proxy Settings) and there
>> is no ISA or anything like this involved. Funny thing is...when these
>> machines were put in place (read: the new Dell workstations running MS
>> Office 2007) the MS Outlook configured the profile automagically. It
>> pulled the user's name and the mailbox and there it was! Hey, about the
>> only thing that I have not done is look at the local machine and check
>> out to log file...see what is *not* going on there! I may just do that
>> still....
>>
>> Anyway, I am pretty much throwing in the towel on this one and going to
>> call MS-PSS because I have spent a ton of time on this. Way more time
>> than I should have (but I love a good challenge!).
>>
>> I will let you know what the problem was once we figure it out.
>>
>> I wonder if we have this issue at any other clients. Several of our
>> clients have EXCH2007 (I set up all bt two of them) and are not starting
>> to move to MS Office 2007.
>>
>> Mike, Thanks for your persistence on this. It is starting to get a
>> little frustrating. But, like I said, I like a good challenge. I am
>> just running out of time (from a buiness perspective...not from a
>> technical perspective).
>>
>> Thanks,
>>
>> Cary
>
date: Sat, 20 Sep 2008 19:09:15 -0400
author: Cary Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
On Sat, 20 Sep 2008 16:06:58 -0400, "Cary Shultz"
wrote:
[ snip ]
>> Sounds like the Outlook 2007 clients are having a problem connecting
>> to the CAS server. That's where OL2K is setting the OOO messages.
>
>Pinging the sole EXCH2007 box via IP Address and via NetBIOS name and via
>FQDN has never been a problem....so, not sure what other way there is. But,
>I believe that you are correct....somewhere there is a problem. Could it
>possibly be the "OriginatingServer" used? More on this later.
Sorry. Didn't mean to imply that this was a connectivity problem. I
meant that the name they were looking for wasn't there. But this does
bring up an interesting question -- have you had a look at one of
these clients with, say, WireShark while they try to set the OOO
status? I've had a *lot* of "AHA!" moments using a network monitor in
cases like this. Just seeing the name in the DNS query or the HTTP
"GET" or "POST" can sometimes be enlightening, if ya know what I mean.
[ snip ]
>> FLZ? Wazzat, a dyslexic DNS? :-)
>
>(F)orward (L)ookup (Z)one.........Sorry. I almost always use FLZ and RLZ
>(Reverse Lookup Zone).
Thanks. More acronyms! My old brain is filling up. :-(
[ snip ]
>Here is the results of the Get-AutodiscoverVirtualDirectory | FL
>
>==============================================================================================================
>
>
>Name : Autodiscover (Default Web Site)
>InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
>ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
>BasicAuthentication : True
>DigestAuthentication : False
>WindowsAuthentication : True
>MetabasePath :
>IIS://server.mydomain.org/W3SVC/1/ROOT/Autodiscover
>Path : C:\Program Files\Microsoft\Exchange
>Server\ClientAccess\Autodiscover
>Server : server
>InternalUrl :
>https://server.mydomain.org/autodiscover/autodiscover.xml
>ExternalUrl :
>https://mail.mydomain.org/autodiscover/autodiscover.xml
>AdminDisplayName :
>ExchangeVersion : 0.1 (8.0.535.0)
>DistinguishedName : CN=Autodiscover (Default Web
>Site),CN=HTTP,CN=Protocols,CN=server,CN=Servers,CN=Exchange
> Administrative Group
>(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=SWEET,CN=Microsoft Ex
> change,CN=Services,CN=Configuration,DC=mydomain,DC=org
>Identity : server\Autodiscover (Default Web Site)
>Guid : 12c10160-8d74-41e6-abc5-efd00a5c11a8
>ObjectCategory :
>mydomain.org/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
>ObjectClass : {top, msExchVirtualDirectory,
>msExchAutoDiscoverVirtualDirectory}
>WhenChanged : 9/19/2008 7:48:22 PM
>WhenCreated : 8/7/2007 1:58:29 PM
>OriginatingServer : dc01.mydomain.org
>IsValid : True
>
>==============================================================================================================
Well, I'm going to suggest you change a URL. :-)
The InternalURL looks okay, assuming that server.mydomain.org is the
real FQDN of the machine, but I'd change the ExternalURL to
"https://autodiscover.mydomain.org/autodiscover.autodiscover.xml",
Outlook doesn't know to look for "https://mail.......". If it doesn't
find the autodiscover.<domain> it'll go after "<domain>".
That'll probably screw up your cert unless you had the
autodiscover.mydomain.org in the SAN set.
>Here is the thing that I find interesting......The 'OriginatingServer' in
>this case is one of the two Domain Controllers in the 'mydomain.org' Parent
>Domain. In the other tests the OriginatingServer was *always* the Domain
>Controller from the child domain (located in the same AD Site as the ECH2007
>box...). I am thinking that this is playing a role in this problem...but
>not sure.
>
>>>I have checked IIS and ensured that what is supposed to be is and what is
>>>not supposed to be is not (how is that for 'vague'). For example,
>>>anonymous
>>>access is not checked for the Autodiscover Virtual Directory. Basic and
>>>Integrated Authentication are enabled for the AutoDiscover Virtual
>>>Directory.
>>
>> Sounds good.
>>
>>>I have ensured that the SCP is indeed there and correct. It is.
>>>
>>>I can access the https://server.mydomain.org/autodiscover/autodiscover.xml
>>>and all the other URLs (https://server.mydomain.org/EWS/Exchange.asmx, for
>>>example).
>>>
>>>I have created a Host record in the Public DNS of 'autodiscover' and
>>>pointed
>>>it to the WAN IP Address. This does not seem to have helped.
>>
>> Why not the IP address of the internal NIC? The folks having a problem
>> are inside the network, aren't they?
>
>Rich, as mentioned, the internal 'autodiscover' already exists.
Sorry. I must have missed that.
>I have done
>a ton of reading and I am seeing everywhere that we need an SRV record in
>the Public DNS that points to the WAN IP Address (so, the IP Address that
>resolves mail.mydomain.org...) for the people using RPC over HTTPS / Outlook
>Anywhere
The SRV record is only necessary if you don't use a SAN/UC cert and
you have only one IP address available. If you use two IP addresses
and a single-name cert on both of them you don't need the SRV record,
either. But if you want to use the autodiscover stuff from outside
your LAN you have to have a name that Outlook knows to look for, and
mail.mydomain.org isn't one of those names.
http://msexchangeteam.com/archive/2007/04/30/438249.aspx
Inside your network the SCP record should direct the Outlook client to
the CAS. I don't recall seeing you mention if the SCPs are correct but
it would be a good idea to check that.
>But, yes - the users having this issue are all inside the
>network.
And the machines are all domain members? If not they'll need the same
autodiscover.mydomain.org DNS stuff on your internal DNS.
[ snip ]
>> How's the AD dealing with that? Or are you referring to some external
>> DNS and not to your internal DNS?
>
>Rich....the internal HOST record for 'autodiscover'
>(autodiscover.mydomain.org = 192.168.0.46) has always been there.
Okay, so skip my talk about needing one -- but /do/ check the SCP AD
object because the domain-joined clients are going to use that to find
the CAS.
---
Rich Matheisen
MCSE+I, Exchange MVP
date: Sat, 20 Sep 2008 22:30:19 -0400
author: Rich Matheisen [MVP]
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
Rich,
Thanks a ton....in-line...
"Rich Matheisen [MVP]" wrote in message
news:q2rad419abldjub7i9aqj02dprs1qeoqtj@4ax.com...
> On Sat, 20 Sep 2008 16:06:58 -0400, "Cary Shultz"
> wrote:
>
> [ snip ]
>
>>> Sounds like the Outlook 2007 clients are having a problem connecting
>>> to the CAS server. That's where OL2K is setting the OOO messages.
>>
>>Pinging the sole EXCH2007 box via IP Address and via NetBIOS name and via
>>FQDN has never been a problem....so, not sure what other way there is.
>>But,
>>I believe that you are correct....somewhere there is a problem. Could it
>>possibly be the "OriginatingServer" used? More on this later.
>
> Sorry. Didn't mean to imply that this was a connectivity problem. I
> meant that the name they were looking for wasn't there. But this does
> bring up an interesting question -- have you had a look at one of
> these clients with, say, WireShark while they try to set the OOO
> status? I've had a *lot* of "AHA!" moments using a network monitor in
> cases like this. Just seeing the name in the DNS query or the HTTP
> "GET" or "POST" can sometimes be enlightening, if ya know what I mean.
>
Rich, good call. It would be really nice to see what is going on...or not
going on!
> [ snip ]
>
>>> FLZ? Wazzat, a dyslexic DNS? :-)
>>
>>(F)orward (L)ookup (Z)one.........Sorry. I almost always use FLZ and RLZ
>>(Reverse Lookup Zone).
>
> Thanks. More acronyms! My old brain is filling up. :-(
Right, your's and mine! This alphabet soup that we continue to put upon
ourselves.....one day we will just go back to saying 'Forward Lookup
Zone'...
>
> [ snip ]
>
>>Here is the results of the Get-AutodiscoverVirtualDirectory | FL
>>
>>==============================================================================================================
>>
>>
>>Name : Autodiscover (Default Web Site)
>>InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
>>ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
>>BasicAuthentication : True
>>DigestAuthentication : False
>>WindowsAuthentication : True
>>MetabasePath :
>>IIS://server.mydomain.org/W3SVC/1/ROOT/Autodiscover
>>Path : C:\Program Files\Microsoft\Exchange
>>Server\ClientAccess\Autodiscover
>>Server : server
>>InternalUrl :
>>https://server.mydomain.org/autodiscover/autodiscover.xml
>>ExternalUrl :
>>https://mail.mydomain.org/autodiscover/autodiscover.xml
>>AdminDisplayName :
>>ExchangeVersion : 0.1 (8.0.535.0)
>>DistinguishedName : CN=Autodiscover (Default Web
>>Site),CN=HTTP,CN=Protocols,CN=server,CN=Servers,CN=Exchange
>> Administrative Group
>>(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=SWEET,CN=Microsoft Ex
>>
>> change,CN=Services,CN=Configuration,DC=mydomain,DC=org
>>Identity : server\Autodiscover (Default Web Site)
>>Guid : 12c10160-8d74-41e6-abc5-efd00a5c11a8
>>ObjectCategory :
>>mydomain.org/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
>>ObjectClass : {top, msExchVirtualDirectory,
>>msExchAutoDiscoverVirtualDirectory}
>>WhenChanged : 9/19/2008 7:48:22 PM
>>WhenCreated : 8/7/2007 1:58:29 PM
>>OriginatingServer : dc01.mydomain.org
>>IsValid : True
>>
>>==============================================================================================================
>
> Well, I'm going to suggest you change a URL. :-)
>
> The InternalURL looks okay, assuming that server.mydomain.org is the
> real FQDN of the machine, but I'd change the ExternalURL to
> "https://autodiscover.mydomain.org/autodiscover.autodiscover.xml",
> Outlook doesn't know to look for "https://mail.......". If it doesn't
> find the autodiscover.<domain> it'll go after "<domain>".
>
> That'll probably screw up your cert unless you had the
> autodiscover.mydomain.org in the SAN set.
Gonna try this. I actually had the foresight to put this in the SAN.
Probably more out of ignorance than anything else (well, maybe not exactly
ignorance....). I will try this and see what happens...
>
>>Here is the thing that I find interesting......The 'OriginatingServer' in
>>this case is one of the two Domain Controllers in the 'mydomain.org'
>>Parent
>>Domain. In the other tests the OriginatingServer was *always* the Domain
>>Controller from the child domain (located in the same AD Site as the
>>ECH2007
>>box...). I am thinking that this is playing a role in this problem...but
>>not sure.
>>
>>>>I have checked IIS and ensured that what is supposed to be is and what
>>>>is
>>>>not supposed to be is not (how is that for 'vague'). For example,
>>>>anonymous
>>>>access is not checked for the Autodiscover Virtual Directory. Basic and
>>>>Integrated Authentication are enabled for the AutoDiscover Virtual
>>>>Directory.
>>>
>>> Sounds good.
>>>
>>>>I have ensured that the SCP is indeed there and correct. It is.
>>>>
>>>>I can access the
>>>>https://server.mydomain.org/autodiscover/autodiscover.xml
>>>>and all the other URLs (https://server.mydomain.org/EWS/Exchange.asmx,
>>>>for
>>>>example).
>>>>
>>>>I have created a Host record in the Public DNS of 'autodiscover' and
>>>>pointed
>>>>it to the WAN IP Address. This does not seem to have helped.
>>>
>>> Why not the IP address of the internal NIC? The folks having a problem
>>> are inside the network, aren't they?
>>
>>Rich, as mentioned, the internal 'autodiscover' already exists.
>
> Sorry. I must have missed that.
Rich, no worries. This post is typical of my posts (as you well
know...)....tons and tons and tons of verbiage. Easy to miss something.
>
>>I have done
>>a ton of reading and I am seeing everywhere that we need an SRV record in
>>the Public DNS that points to the WAN IP Address (so, the IP Address that
>>resolves mail.mydomain.org...) for the people using RPC over HTTPS /
>>Outlook
>>Anywhere
>
> The SRV record is only necessary if you don't use a SAN/UC cert and
> you have only one IP address available. If you use two IP addresses
> and a single-name cert on both of them you don't need the SRV record,
> either. But if you want to use the autodiscover stuff from outside
> your LAN you have to have a name that Outlook knows to look for, and
> mail.mydomain.org isn't one of those names.
> http://msexchangeteam.com/archive/2007/04/30/438249.aspx
Okay, now it is my turn to say, "I must have missed that"! ;-)
> Inside your network the SCP record should direct the Outlook client to
> the CAS. I don't recall seeing you mention if the SCPs are correct but
> it would be a good idea to check that.
Rich, the SCP is indeed correct. Well, as best I can tell. I will use my
good friend ADSIEdit to verify. I should also be able to use the Exchange
Server and look at get-clientAccessServer | FL, correct?
>
>>But, yes - the users having this issue are all inside the
>>network.
>
> And the machines are all domain members? If not they'll need the same
> autodiscover.mydomain.org DNS stuff on your internal DNS.
Yeppers! All Domain members (again, except for the Police
Department...using MS Outlook 2003 SP3 / RPC over HTTPS). And, just for
Poops and Grins I configured my laptop (running MS Office 2007) to connect
to the EXCH2007 box via Outlook Anywhere.....same issue! Can not use
OoO...same error message. Just to be clear...my laptop is not part of this
client's domain...
>
> [ snip ]
>
>>> How's the AD dealing with that? Or are you referring to some external
>>> DNS and not to your internal DNS?
>>
>>Rich....the internal HOST record for 'autodiscover'
>>(autodiscover.mydomain.org = 192.168.0.46) has always been there.
>
> Okay, so skip my talk about needing one -- but /do/ check the SCP AD
> object because the domain-joined clients are going to use that to find
> the CAS.
> ---
> Rich Matheisen
> MCSE+I, Exchange MVP
date: Sun, 21 Sep 2008 03:48:18 -0400
author: Cary Shultz
Re: issues with Out of Office (Exchange Server 2007 SP1....Outlook 2007 SP1)
On Sun, 21 Sep 2008 03:48:18 -0400, "Cary Shultz"
wrote:
>Rich,
>
>Thanks a ton....in-line...
Hi Cary, sounds like every question and test has been covered, but
have you verified there is no duplicate ip for autodiscover in your
DNS? Tried with an entry for autodiscover in your hosts file?
If you cant get those autodiscover settings, then not only will OOF be
affected, then no free/busy or OAB either!
>
>
>"Rich Matheisen [MVP]" wrote in message
>news:q2rad419abldjub7i9aqj02dprs1qeoqtj@4ax.com...
>> On Sat, 20 Sep 2008 16:06:58 -0400, "Cary Shultz"
>> wrote:
>>
>> [ snip ]
>>
>>>> Sounds like the Outlook 2007 clients are having a problem connecting
>>>> to the CAS server. That's where OL2K is setting the OOO messages.
>>>
>>>Pinging the sole EXCH2007 box via IP Address and via NetBIOS name and via
>>>FQDN has never been a problem....so, not sure what other way there is.
>>>But,
>>>I believe that you are correct....somewhere there is a problem. Could it
>>>possibly be the "OriginatingServer" used? More on this later.
>>
>> Sorry. Didn't mean to imply that this was a connectivity problem. I
>> meant that the name they were looking for wasn't there. But this does
>> bring up an interesting question -- have you had a look at one of
>> these clients with, say, WireShark while they try to set the OOO
>> status? I've had a *lot* of "AHA!" moments using a network monitor in
>> cases like this. Just seeing the name in the DNS query or the HTTP
>> "GET" or "POST" can sometimes be enlightening, if ya know what I mean.
>>
>
>
>Rich, good call. It would be really nice to see what is going on...or not
>going on!
>
>
>
>> [ snip ]
>>
>>>> FLZ? Wazzat, a dyslexic DNS? :-)
>>>
>>>(F)orward (L)ookup (Z)one.........Sorry. I almost always use FLZ and RLZ
>>>(Reverse Lookup Zone).
>>
>> Thanks. More acronyms! My old brain is filling up. :-(
>
>
>
>Right, your's and mine! This alphabet soup that we continue to put upon
>ourselves.....one day we will just go back to saying 'Forward Lookup
>Zone'...
>
>
>
>>
>> [ snip ]
>>
>>>Here is the results of the Get-AutodiscoverVirtualDirectory | FL
>>>
>>>==============================================================================================================
>>>
>>>
>>>Name : Autodiscover (Default Web Site)
>>>InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
>>>ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
>>>BasicAuthentication : True
>>>DigestAuthentication : False
>>>WindowsAuthentication : True
>>>MetabasePath :
>>>IIS://server.mydomain.org/W3SVC/1/ROOT/Autodiscover
>>>Path : C:\Program Files\Microsoft\Exchange
>>>Server\ClientAccess\Autodiscover
>>>Server : server
>>>InternalUrl :
>>>https://server.mydomain.org/autodiscover/autodiscover.xml
>>>ExternalUrl :
>>>https://mail.mydomain.org/autodiscover/autodiscover.xml
>>>AdminDisplayName :
>>>ExchangeVersion : 0.1 (8.0.535.0)
>>>DistinguishedName : CN=Autodiscover (Default Web
>>>Site),CN=HTTP,CN=Protocols,CN=server,CN=Servers,CN=Exchange
>>> Administrative Group
>>>(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=SWEET,CN=Microsoft Ex
>>>
>>> change,CN=Services,CN=Configuration,DC=mydomain,DC=org
>>>Identity : server\Autodiscover (Default Web Site)
>>>Guid : 12c10160-8d74-41e6-abc5-efd00a5c11a8
>>>ObjectCategory :
>>>mydomain.org/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
>>>ObjectClass : {top, msExchVirtualDirectory,
>>>msExchAutoDiscoverVirtualDirectory}
>>>WhenChanged : 9/19/2008 7:48:22 PM
>>>WhenCreated : 8/7/2007 1:58:29 PM
>>>OriginatingServer : dc01.mydomain.org
>>>IsValid : True
>>>
>>>==============================================================================================================
>>
>> Well, I'm going to suggest you change a URL. :-)
>& |
