SBS 2008, Exchange 2007 & Outlook 2007...

M

Mikey

                                       [ snip ]
Installed certificate & still having problems...
I am once again getting warnings when using OWA, too.
. . .  and that warning is?
You'll want the names in the certificate that you'll use to access the
resources you're offering:

You may want to add to that list:
mail-server.externaldomainname.com
mail-server.internaldomainname.local
GoDaddy might be lenient enough to all you to use names without them
being fully qualified. but other CAs probably won't. It'd be a good
idea to have the name by which you access the resources from inside
you LAN be the same as the names you use from outside. Publish the
names and the LAN IP addresses you internal DNS and the names and
external IP address in your external DNS. There's no confusion among
the users as to what name should be used because they're the same
everywhere.
If you're having a problem getting the CSR generated for submission to
the CA, try using DigiCert's tool for that:

I tried & am getting a message that either I can't over write the file
(there's nothing there with that currect name!) or I don't have
sufficient privelages!
Is an administrator acount not what it used to be?- Hide quoted text -

- Show quoted text -

D'OH!
Forgot 'run as administrator'!
 
R

Rich Matheisen [MVP]

[ snip ]
I tried & am getting a message that either I can't over write the file
(there's nothing there with that currect name!) or I don't have
sufficient privelages!
Is an administrator acount not what it used to be?

I guess that depends on what you mean.

1. Did you have a problem renaming the CSR file that already exists?
2. Did you have a problem deleting the CSR file that already exists?
3. Did you add "-force:$true" to the cmdlet to overwrite the existing
CSR file?

-Force <SwitchParameter>
Use this parameter switch to overwrite an existing certificate
request file that matches the same file path as specified in
this cmdlet.
By default, this cmdlet will not overwrite existing files.


4. Did you tell the cmdlet to write the CSR file to a different path?
 
M

Mikey

Alright, just to get everybody back on the same page, I received a private
email from "Mikey"with the results of his log. HE was concerned about
publishing the information publicly, so it isn't my place to supercede that
decision.

With that said, what I *can* share is that there AutoDiscover is configured
to work using the SRV record method and the domain name the SRV record
returns does not match the domain name on the certificate.

So the fix here is to update DNS and have the SRV record point to
remote.<domain-name>

That should resolve the issue.

--
Cliff Galiher
Microsoft has opened the Small Business Server forum on Technet!  Checkit
out!http://social.technet.microsoft.com/Forums/en-us/smallbusinessserver/....
Addicted to newsgroups?  Read about the NNTP Bridge for MS Forums.

Changed the SRV record & still no help!
Still getting all kinds of errors in the exchange connectivity tests.
Alot of it looks like it's trying to go to the address of our website,
which is hosted else where!
I deleted the * (all Others) in my public DNS settings - why is it
still looking there?
 
M

Mikey

                                        [ snip ]
I tried & am getting a message that either I can't over write the file
(there's nothing there with that currect name!) or I don't have
sufficient privelages!
Is an administrator acount not what it used to be?

I guess that depends on what you mean.

1. Did you have a problem renaming the CSR file that already exists?
2. Did you have a problem deleting the CSR file that already exists?
3. Did you add "-force:$true" to the cmdlet to overwrite the existing
CSR file?

   -Force <SwitchParameter>
       Use this parameter switch to overwrite an existing certificate
       request file that matches the same file path as specified in
       this cmdlet.
       By default, this cmdlet will not overwrite existing files.

4. Did you tell the cmdlet to write the CSR file to a different path?

See post above yours.
 
R

Rich Matheisen [MVP]

                                        [ snip ]
If you're having a problem getting the CSR generated for submission to
the CA, try using DigiCert's tool for that:
I tried & am getting a message that either I can't over write the file
(there's nothing there with that currect name!) or I don't have
sufficient privelages!
Is an administrator acount not what it used to be?

I guess that depends on what you mean.

1. Did you have a problem renaming the CSR file that already exists?
2. Did you have a problem deleting the CSR file that already exists?
3. Did you add "-force:$true" to the cmdlet to overwrite the existing
CSR file?

   -Force <SwitchParameter>
       Use this parameter switch to overwrite an existing certificate
       request file that matches the same file path as specified in
       this cmdlet.
       By default, this cmdlet will not overwrite existing files.

4. Did you tell the cmdlet to write the CSR file to a different path?

See post above yours.

If I was looking at this in a web browser that might make sense. But
if you're refering to your other posting at 3:59AM it doesn't answer
any of the questions I asked.
 
C

Cliff Galiher - MVP

The connectivity test is exactly that: a test. It will test *all* methods
and most of them are supposed to fail. The idea here is to pay attention to
the one you expect to succeed and keep plugging at it until it does.

If you post the results of your latest test (privately if you so choose
again) then I can tell you what is still breaking.

--
Cliff Galiher
Microsoft has opened the Small Business Server forum on Technet! Check it
out!
http://social.technet.microsoft.com/Forums/en-us/smallbusinessserver/threads
Addicted to newsgroups? Read about the NNTP Bridge for MS Forums.
 
M

Mikey

[ snip ]
If you're having a problem getting the CSR generated for submissionto
the CA, try using DigiCert's tool for that:
https://www.digicert.com/easy-csr/exchange2007.htm
---
Rich Matheisen
MCSE+I, Exchange MVP
I tried & am getting a message that either I can't over write the file
(there's nothing there with that currect name!) or I don't have
sufficient privelages!
Is an administrator acount not what it used to be?
I guess that depends on what you mean.
1. Did you have a problem renaming the CSR file that already exists?
2. Did you have a problem deleting the CSR file that already exists?
3. Did you add "-force:$true" to the cmdlet to overwrite the existing
CSR file?
-Force <SwitchParameter>
Use this parameter switch to overwrite an existing certificate
request file that matches the same file path as specified in
this cmdlet.
By default, this cmdlet will not overwrite existing files.
4. Did you tell the cmdlet to write the CSR file to a different path?
See post above yours.

If I was looking at this in a web browser that might make sense. But
if you're refering to your other posting at 3:59AM it doesn't answer
any of the questions I asked.

I didn't have a CSR there to overwrite. What kept me from writing the
request was that even though I am logged in as the administrator, I
haven't got in the habit of using the 'run as administrator' option.
Once I did that, it created the request, I re-keyed my certificate,
but when I tried to install it, it wouldn't, saying it didn't match
the name of the server, or something along those lines, probably
because the original request was for remote.mydomain.com & I tried to
create it for exchange.mydomain.com.
As Cliff suggested, I changed my SRV record to point to
remote.mydomain.com. so now any knid of smart phone connects with no
problem, I am not getting warnings when using OWA, but I still cannot
connect remote clients using Outlook Anywhere! The test exchange
website still throws up a bunch of error, as well, so I am open for
any suggestions, including jumping off of a very tall building at this
point!
Seriously, I appreciate all the help you guys are offering, it's been
a loooong day....
 
R

Rich Matheisen [MVP]

[ snip ]
I didn't have a CSR there to overwrite. What kept me from writing the
request was that even though I am logged in as the administrator, I
haven't got in the habit of using the 'run as administrator' option.
Once I did that, it created the request, I re-keyed my certificate,
but when I tried to install it, it wouldn't, saying it didn't match
the name of the server, or something along those lines, probably
because the original request was for remote.mydomain.com & I tried to
create it for exchange.mydomain.com.
As Cliff suggested, I changed my SRV record to point to
remote.mydomain.com. so now any knid of smart phone connects with no
problem, I am not getting warnings when using OWA, but I still cannot
connect remote clients using Outlook Anywhere!

And Outlook's "Exchange Proxy Settings" use what server name?
The test exchange
website still throws up a bunch of error, as well, so I am open for
any suggestions,

You've already been offered suggestions. One of them was to reveal the
names you're using in the certificate and in Outlook. You can't expect
to get meaningful help for an identity problem if you remain
anonymous.
 
C

Cliff Galiher - MVP

Okay, once again getting everyone up to speed. The SRV record has been
created and I got an updated Autodiscover log, info filtered and two
important "errors" posted below:
------------------------
Certificate trust is being validated.
The test passed with some warnings encountered. Please expand the
additional details.
Additional Details
Only able to build certificate chain when using the Root Certificate Update
functionality from Windows Update. Your server may not be properly
configured to send down the required intermediate certificates to complete
the chain. Consult the certificate installation instructions or FAQ's from
your Certificate Authority for more information.
--------------------------------
Fore issue #1, I viewed the certificate and it is issued by GoDaddy.
GoDaddy uses "intermediate" certificates that must also be installed to
resolve this warning. Here is a blog post outlining the process. Perform
this process to resolve the warning.
http://sbs.seandaniel.com/2009/02/installing-godaddy-standard-ssl.html

--------------------------------
ExRCA is attempting to send an Autodiscover POST request to potential
Autodiscover URLs.
Autodiscover settings weren't obtained when the Autodiscover POST request
was sent.
Test Steps
Attempting to Retrieve XML AutoDiscover Response from url
https://xxxxxxxxxxxxxxxxxxxxxx/Autodiscover/Autodiscover.xml for user
(e-mail address removed)
Failed to obtain AutoDiscover XML response.
Additional Details
A Web Exception occurred because an HTTP 401 - Unauthorized response was
received from Unknown
-----------------------------------
Issue #2:
The URL is not returning any autodiscover info with a 401 error. This is
usually an authentication error, so what I'd recommend doing is opening IIS
via the snap-in located in Administrative tools.
Expand the sites and find the site called "SBS Web Apps"
Locate the "autodiscover" virtual directory and select it.
Click on "authentication" in the center pane under the IIS group.
There should be TWO authentication methods enabled.
Basic authentication is used for external clients. Since they operate over
SSL, the channel is still secure so the weakness of basic authentication is
mitigated and this is safe.
Windows Authentication is used by internal clients.
All other authentication methods should be DISABLED.

That should hopefully resolve the remaining issues.

--
Cliff Galiher
Microsoft has opened the Small Business Server forum on Technet! Check it
out!
http://social.technet.microsoft.com/Forums/en-us/smallbusinessserver/threads
Addicted to newsgroups? Read about the NNTP Bridge for MS Forums.
 
R

Rich Matheisen [MVP]

Okay, once again getting everyone up to speed. The SRV record has been
created and I got an updated Autodiscover log, info filtered and two
important "errors" posted below:
------------------------

Just trying to browse to his server gives me errors that the
certificate's revoked.

Maybe he has the cert installed on the CAS but not on ISA/TMG?
 
M

Mikey

                                        [ snip ]
I didn't have a CSR there to overwrite. What kept me from writing the
request was that even though I am logged in as the administrator, I
haven't got in the habit of using the 'run as administrator' option.
Once I did that, it created the request, I re-keyed my certificate,
but when I tried to install it, it wouldn't, saying it didn't match
the name of the server, or something along those lines, probably
because the original request was for remote.mydomain.com & I tried to
create it for exchange.mydomain.com.
As Cliff suggested, I changed my SRV record to point to
remote.mydomain.com. so now any knid of smart phone connects with no
problem, I am not getting warnings when using OWA, but I still cannot
connect remote clients using Outlook Anywhere!

And Outlook's "Exchange Proxy Settings" use what server name?
The test exchange
website still throws up a bunch of error, as well, so I am open for
any suggestions,

You've already been offered suggestions. One of them was to reveal the
names you're using in the certificate and in Outlook. You can't expect
to get meaningful help for an identity problem if you remain
anonymous.

The CN is remote.mydomain.com I tried to make this
exchange.mydomain.com, but SBS's certificate request thinks remote
would be a better name, even though the server is named exchange!
The other names on the certificate are;
autodiscover.mydomain.com
exchange.mydomain.com
exchange.mydomain.local
sites

In Outlook, I've tried to use remote.mydomain.com and
exchange.mydomain.com & it doesn't like either of them!
What's even stranger, is that if you try to use OWA from a Mac (&
probably same goes for iPhones), I get the warning that the cert is
invalid. If I ask to show the certificate, it lists the following;
remote.mydomain.com
wwww.remote.mydomain.com
autodiscover.mydomain.com
exchange
exchange.mydomain.local
sites

Why isn't exchange.mydomain.com listed there? It's what the browser/
iphone is looking for, & it's also one of my SAN names!!!
 
C

Cliff Galiher - MVP

Mikey,

I've posted several steps for you to take and you haven't taken them. I know
that having a system not work the way you expect can be frustrating, but
randomly changing settings and poking at the system only makes things worse.
Here are my final words of advice, then I'll shut up. If you decide you want
to pick up the thread of troubleshooting we started, I'll leave it for you
to re-engage at that point:

1) This is SBS. Use the wizards. There are many blog posts and talented
people that give great advice about Exchange, Windows Server, and other
components, but they may not be experienced with SBS. The "thinkg" about SBS
is that it sometimes stores settings in odd places that the enterprise
versions don't. This is to to allow the wizards and SBS console to work
better with integrating the disparate pieces and it allows the wizards to
"fix" misconfigured settings. However, if you are making manual change, even
when you fix an issue, that means the wizard can actually re-break those
settings because he wizard wasn't aware of the manual changes you made. In
other words, be careful where you get advice. If the person giving advice
isn't aware of the "SBS" way, they may unintentionally be making your life
more difficult. This is not a reflection on the person, just a reflection on
their skillset with enterprise products. SBS is a unique beast and that
needs to be considered.

2) For he reasons above, use the wizards. If you aren't using a wizard to
make a change, think twice. Every so often a setting comes up that truly
*needs* manual tweaking. But that will come from a skilled SBSer that knows
when it is time to stray from wizard-land. If you are straying, be *DARNED*
sure you know why.

3) Be patient! Don't poke at things in hopes that a random button will fix
an issue. Revoking a self-signed certificate in hopes that it'll cause the
3rd-party cert to take precedence, for example, will not work AND it can
cause more problems because that self-signed cert may still be getting used
for internal functions. Disabling IPv6 without a clear reason why may seem
like a good idea too, but again, usually uases more harm thatn good because
the intent going in was unclear.

There ya go, and good luck.

--
Cliff Galiher
Microsoft has opened the Small Business Server forum on Technet! Check it
out!
http://social.technet.microsoft.com/Forums/en-us/smallbusinessserver/threads
Addicted to newsgroups? Read about the NNTP Bridge for MS Forums.
 
M

Mikey

Mikey,

I've posted several steps for you to take and you haven't taken them. I know
that having a system not work the way you expect can be frustrating, but
randomly changing settings and poking at the system only makes things worse.
Here are my final words of advice, then I'll shut up. If you decide you want
to pick up the thread of troubleshooting we started, I'll leave it for you
to re-engage at that point:

1) This is SBS. Use the wizards. There are many blog posts and talented
people that give great advice about Exchange, Windows Server, and other
components, but they may not be experienced with SBS. The "thinkg" about SBS
is that it sometimes stores settings in odd places that the enterprise
versions don't. This is to to allow the wizards and SBS console to work
better with integrating the disparate pieces and it allows the wizards to
"fix" misconfigured settings. However, if you are making manual change, even
when you fix an issue, that means the wizard can actually re-break those
settings because he wizard wasn't aware of the manual changes you made. In
other words, be careful where you get advice. If the person giving advice
isn't aware of the "SBS" way, they may unintentionally be making your life
more difficult. This is not a reflection on the person, just a reflectionon
their skillset with enterprise products. SBS is a unique beast and that
needs to be considered.

2) For he reasons above, use the wizards. If you aren't using a wizard to
make a change, think twice. Every so often a setting comes up that truly
*needs* manual tweaking. But that will come from a skilled SBSer that knows
when it is time to stray from wizard-land. If you are straying, be *DARNED*
sure you know why.

3) Be patient!  Don't poke at things in hopes that a random button willfix
an issue. Revoking a self-signed certificate in hopes that it'll cause the
3rd-party cert to take precedence, for example, will not work AND it can
cause more problems because that self-signed cert may still be getting used
for internal functions.  Disabling IPv6 without a clear reason why may seem
like a good idea too, but again, usually uases more harm thatn good because
the intent going in was unclear.

There ya go, and good luck.

--
Cliff Galiher
Microsoft has opened the Small Business Server forum on Technet!  Checkit
out!http://social.technet.microsoft.com/Forums/en-us/smallbusinessserver/....
Addicted to newsgroups?  Read about the NNTP Bridge for MS Forums.

I thought I had replied, saying that the authentication settings you
had mentioned above were as you recommended.
I am currently waiting for my re-keyed certificate & will let you know
how that works.
And I will always use wizards, whenever possible!
 
R

Rich Matheisen [MVP]

[ snip ]
The CN is remote.mydomain.com I tried to make this
exchange.mydomain.com, but SBS's certificate request thinks remote
would be a better name, even though the server is named exchange!
The other names on the certificate are;
autodiscover.mydomain.com
exchange.mydomain.com
exchange.mydomain.local
sites

Using your real domain name, and checking the certificate on
remote.mydomain.com, those aren't the set of names I see on the
certificate. What I see are these three names:

mydomain.com
remote.mydomain.com <= this is the "CN"
soonermail.mydomain.com

The certificate is one that you generated from your own CA. Is it safe
to assume that all your mobile devices have your domain's root
certificate installed as a trusted root certificate?

The certificate is good from April 16, 2010 12:20:52PM until April 15,
2012 12:20:52PM

The thumbprint of the cert is:
e8b02b5f79e896915816a8928b1b5cd8d7d1045a

Is this the certificate in which you see the names:
exchange.mydomain.com
exchange.mydomain.local
autodiscover.mydomain.com
sites

.. . . or are you looking at some other certificate?
In Outlook, I've tried to use remote.mydomain.com and
exchange.mydomain.com & it doesn't like either of them!

The "exchange.mydomain.com" isn't present in the cert, so its not
working isn't a surprise.
What's even stranger, is that if you try to use OWA from a Mac (&
probably same goes for iPhones), I get the warning that the cert is
invalid.

If the machine doesn't trust the issuing CA that may be why.
If I ask to show the certificate, it lists the following;
remote.mydomain.com
wwww.remote.mydomain.com
autodiscover.mydomain.com
exchange
exchange.mydomain.local
sites

Where did "www.remote.mydomain.com" come from? You didn't mention that
before.
Why isn't exchange.mydomain.com listed there? It's what the browser/
iphone is looking for, & it's also one of my SAN names!!!

Please verify that the certificate you're looking at and the one
that's installed on remote.mydomain.com are the same. Use the
thumbprints to tell them apart.
 
R

Rich Matheisen [MVP]

Just trying to browse to his server gives me errors that the
certificate's revoked.

Which is no longer the case.
Maybe he has the cert installed on the CAS but not on ISA/TMG?

Not sure what's changed, but it seems thaere's an awful lot of
confusion about what names are on the certificate!
 
M

Mikey

Which is no longer the case.


Not sure what's changed, but it seems thaere's an awful lot of
confusion about what names are on the certificate!

Ok, got my new re-keyed certificate, installed per the settings in
sean daniel's site & names are correct in it.
I have logged onto remote computers, checked the outlook settings &
all looks good, but I am still continuously prompted for a pass word.
I have used the repair settings & it tells me I'm configured to use
exchange, at one point, it asked if I'd like to let exchange settings
be configured for me.
Authentication settings are as Cliff mentioned earlier.
What could it be now?
 
C

Cliff Galiher - MVP

Could be a couple of things. So now we are back on track with the
certificate (I think, I haven't checked.)

So lets make sure Outlook Anywhere works. www.testexchangeconnectivity.com

As far as the repeated credentials, have you patched up Exchange on your SBS
server? Repeated credentials could be a symptom of a conflict between an
outlook security update without the matching Exchange security update. Have
*at least* Exchange SP1 UR9 installed on the SBS server. SP2 is preferrable.
As always, have a backup.


--
Cliff Galiher
Microsoft has opened the Small Business Server forum on Technet! Check it
out!
http://social.technet.microsoft.com/Forums/en-us/smallbusinessserver/threads
Addicted to newsgroups? Read about the NNTP Bridge for MS Forums.
 
M

Mikey

Could be a couple of things.  So now we are back on track with the
certificate (I think, I haven't checked.)

So lets make sure Outlook Anywhere works.  www.testexchangeconnectivity..com

As far as the repeated credentials, have you patched up Exchange on your SBS
server?  Repeated credentials could be a symptom of a conflict between an
outlook security update without the matching Exchange security update.  Have
*at least* Exchange SP1 UR9 installed on the SBS server. SP2 is preferrable.
As always, have a backup.

--
Cliff Galiher
Microsoft has opened the Small Business Server forum on Technet!  Checkit
out!http://social.technet.microsoft.com/Forums/en-us/smallbusinessserver/....
Addicted to newsgroups?  Read about the NNTP Bridge for MS Forums.

I tried the rollup 9 back in the begining. I didn't want to apply SP2
until the weekend, in the event there were any problems.
You had said earlier that it didn't matter if some parts of the test
fail, find one area, pick that & work it out (or something along those
lines!).
I tried the test, manually entering the info & the message that I got
regarding the failure was:

SSL mutual authentication with the RPC proxy server is being tested.
Verification of mutual authentication failed.
Tell me more about this issue and how to resolve it
Additional Details
The certificate common name remote.domain.com, doesn't validate
against Mutual Authentication string provided
msstd:exchange.domain.com

Is this basically saying that it's not finding the name
msstd:exchange.domain.com on my certificate? I that's the case, do I
need to add that name, or is this an indicator of a mismatched
authentication setting? ON the 'tell me how to fix it' link, it talks
about a resolution that changes the name on the cert, but I'm assuming
it changes it on the self generated one, right? So I'm thinking that
probably won't help me. Or, do I need to do that, request a new
certificate, rinse lather & repeat?
 
M

Mikey

I tried the rollup 9 back in the begining. I didn't want to apply SP2
until the weekend, in the event there were any problems.
You had said earlier that it didn't matter if some parts of the test
fail, find one area, pick that & work it out (or something along those
lines!).
I tried the test, manually entering the info & the message that I got
regarding the failure was:

SSL mutual authentication with the RPC proxy server is being tested.
  Verification of mutual authentication failed.
   Tell me more about this issue and how to resolve it
   Additional Details
  The certificate common name remote.domain.com, doesn't validate
against Mutual Authentication string provided
msstd:exchange.domain.com

Is this basically saying that it's not finding the name
msstd:exchange.domain.com on my certificate? I that's the case, do I
need to add that name, or is this an indicator of a mismatched
authentication setting? ON the 'tell me how to fix it' link, it talks
about a resolution that changes the name on the cert, but I'm assuming
it changes it on the self generated one, right? So I'm thinking that
probably won't help me. Or, do I need to do that, request a new
certificate, rinse lather & repeat?- Hide quoted text -

- Show quoted text -

I did change the name to msstd:remote.domain.com on the client & it
worked, but it prompts you for a password everytime you open outlook.
The 'Always prompt for log on credentials' is NOT checked - is there a
way to 'fix' this?
Now, if I apply SP2 this weekend, can if mess up anything we've done
so far?
 
R

Rich Matheisen [MVP]

[ snip ]
SSL mutual authentication with the RPC proxy server is being tested.
Verification of mutual authentication failed.
Tell me more about this issue and how to resolve it
Additional Details
The certificate common name remote.domain.com, doesn't validate
against Mutual Authentication string provided
msstd:exchange.domain.com

Is this basically saying that it's not finding the name
msstd:exchange.domain.com on my certificate?

No, it's not finding "exchange.domain.com" as the certificate's CN. As
I've said before, Outlook wants you to use the CN of the certificate
in the Exchange Proxy Settings. You need to put
"msstd:remote.domain.com" into the 2nd edit box (and remote.domain.com
into the 1st edit box).
I that's the case, do I
need to add that name, or is this an indicator of a mismatched
authentication setting? ON the 'tell me how to fix it' link, it talks
about a resolution that changes the name on the cert, but I'm assuming
it changes it on the self generated one, right? So I'm thinking that
probably won't help me. Or, do I need to do that, request a new
certificate, rinse lather & repeat?

Just change the server name in Outlook's "Exchange Proxy Settings"
dialog box.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top