[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2846
  • Last Modified:

Outlook 2007 msstd value keeps changing

I have a situation where a client has two sites.

Site1 houses the SBS2008 server and all clients here use the domain-a.com email address.

Site2 its own SBS2008 server but we're now configuring all of it's clients to access their mail through site1's server. These clients use domain-b.com for their email addresses. We've added an accepted domain in Exchange and configured an email policy that assigns the correct email address to these domian-b clients. This part works fine and mail is accessible via OWA, Blackberry and I've configured my own PC with mail profiles to connect to these domain-b mailboxes. I'm running Win7 and Outlook 2010 and it works just fine.

The problem I'm having is the domain-b client machines run Win7 and Outlook 2007 and this appears to keep changing the proxy server and MSSTD value when Outlook is closed. This is the process:

1. Configure exchange profile via control panel setting as follows:
Proxy server: https://office.domain-a.com
Connect only to: msstd:office.domain-a.com
Un-tick the 'on fast networks...' box
Tick the 'on slow networks...' box
Proxy authentication set to Basic (although I've also tried this set to NTLM).

2. Open Outlook - Everything works just fine.

3. Close Outlook

4. Check the mail settings and find that the proxy is now set to https:office.domain-b.com and msstd:office.domain-b.com

Obviously, now the DNS won't resolve and the certificate won't match. If you change the values back again, you can open Outlook and it will work fine. However, closing outlook rewrites these incorrect values back to the Outlook settings.

I should be clear and say that the domain-a.com people are having no issues and my Outlook 2010 works fine on both domains and my settings don't get re-written.

I'm having to assume at this stage that there is a bug with Outlook 2007 which looks at the domain name of the email address and re-writes this into the proxy settings.

I'm running Microsoft updates on one of the domain-b machines at the moment but there doesn't seem to be anything Outlook or Office based in the list of available updates.

Any ideas?
0
edz_pgt
Asked:
edz_pgt
  • 17
  • 9
  • 5
  • +2
2 Solutions
 
Sanjay SantokiCommented:
Hello,

By design it will be changed as from outlook 2007 onward, it support autodiscover (autoconfigure). As per my knowledge there is not way to get rid of it except disabling autodiscovery from Exchange server.

Thanks,
Sanjay Santoki
0
 
edz_pgtAuthor Commented:
OK - thanks for the hints but why is my Outlook 2010 working without these issues?
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
5g6tdcv4Commented:
Which exchange server and which GC is your 2010 outlook connected to?
1.      On the client computer, move the mouse pointer over the Microsoft Office
Outlook icon in the notification area that is located at the lower right of
the desktop.
2.      Press the CTRL key, and then right-click this icon.
3.      Click Connection Status.
4.      Please check if the Mail server(your Exchange server) and Directory
server(your Global Catalog server) are connected with status "Established".
Then check on the machines that are not working
0
 
edz_pgtAuthor Commented:
I'm not getting a specific menu pop up when I do as you've described. All I'm getting is the 'Customize Status Bar' menu.

My machine is not connected to any domain at all. It's simply configured for RPC over HTTP connection to these mailboxes on the client's server at site-a.
0
 
5g6tdcv4Commented:
So the machines that are getting their outlook settings "overwritten" are domain members?
0
 
edz_pgtAuthor Commented:
Yes, they are domain machines but attached to the local SBS2008 server at site2. This server was used for domain-b.com emails until a few days ago.

I've been reading up on this. I now get the impression that the autodiscover at site1 may not be working properly. When this happens, the Outlook may then try to guess the settings based on the email address.

This is really annoying. I really don't need autodiscover making my life difficult. Nobody uses autodiscover since every workstation is manually configured by IT staff. Is there a way to disable it so that I don't have to fix it?

I have read that you must purchase a 3rd party certificate to make autodiscover work properly. We've never had to purchase a certificate for anybody so I assume that this is only a problem in this case because of this odd email configuration.

So, what do you think? Is it likely to be an easy fix? or is it easier to disable autodiscover?
0
 
edz_pgtAuthor Commented:
...or will this never work if autodiscover is disabled?
0
 
5g6tdcv4Commented:
you only need the 3rd party cert if you are going to be accessing the email from outside the domains i.e. outlook anywhere. You can use a wildcart cert or a unified messaging cert with subject alternative names if you want.
use the Set-ClientAccessServer command to set the SCP (service connection points) in active directory to tell your clients which CAS server they need to use.
here is a technet on it http://technet.microsoft.com/en-us/library/bb124251.aspx


The following is copied from technet:
When the client connects to Active Directory, the client looks for the SCP object created during Setup. In deployments that include multiple Client Access servers, an Autodiscover SCP object is created for each Client Access server. The SCP object contains the ServiceBindingInfo attribute with the fully qualified domain name (FQDN) of the Client Access server in the form https://CAS01/autodiscover/autodiscover.xml, where CAS01 is the FQDN for the Client Access server. Using the user credentials, the Outlook 2007 or Outlook 2010 client authenticates to Active Directory and searches for the Autodiscover SCP objects. After the client obtains and enumerates the instances of the Autodiscover service, the client connects to the first Client Access server in the enumerated list and obtains the profile information in the form of XML data that's needed to connect to the user's mailbox and available Exchange features.
0
 
MegaNuk3Commented:
Try changing the autodiscoverUrl as per the post above or just edit site2's outlook anywhere settings (URL) to point to site1's server.
The msstd value can be changed with
Set-OutlookProvider EXPR -certPrincipalName "msstd:CAS.site1.com"

Changing the proxy name is
Set-outlookanywhere -externalhostname "CAS.site1.com"
0
 
edz_pgtAuthor Commented:
@MegaNuk3

Thanks - I'd like to be certain of what the settings are before I try that but whatever I type I can't get the shell to recognise the command like get-outlookanywhere -externalhostname

It says that a parameter cannot be found that matches 'externalhostname'

I've actually tried the first set command you quoted with the same result, too.
0
 
edz_pgtAuthor Commented:
@5g6tdcv4

hmm... I've seen that technet article before. However, it's difficult for me to establish which bits are relevant or how to interpret it in a SBS environment. Perhaps you could help me interpret this into this real-world scenario please?

With regards to the 3rd party cert - obviously we are trying to access site1 from a different domain on site2. However, I think I've identified another complication here...

Site1 is domain-a.local and hosts domain-a.com and now also hosts domain-b.com
Site2 is domain-b.local and hosts no email (although Exchange is still running as a host for domain-b.com)

The issue I'm seeing is that a domain-based workstation on site2 is probably going to assume that its own server is the host for several services associated with domain-b.com

Does what MegaNuk3 suggest get around this issue?
0
 
5g6tdcv4Commented:
You can just go into the exchange management console on site 2 go to server configuration, client access, properties of outlook anywhere and put in site 1's mail server.
This is changing the Connect only to: msstd:mail.yoursite.com, and end the end will do what you want to do.
Real works calls will be in meetings for next 2 hours good luck
0
 
MegaNuk3Commented:
It's "set" not "get", but you could pipe get to set
E.g.
Get-outlookanywhere | set-outlookanywhere -externalhostname "CAS.site1.com"
Or just do it in the EMC as suggested above
0
 
edz_pgtAuthor Commented:
Thanks for your help everyone.

I tried setting the server in outlook anywhere's properties at site2 but that didn't seem to do anything. However, I then disabled outlook anywhere at site2 (exchange management console, go to server configuration, client access, right-hand panel) and all of my problems drifted away. :)

I suppose that the machines joined to the domain at site2 were being affected by the presence of Outlook Anywhere on their local server that still thought it was in control of email on the domain-b.com domain.

Just a point to note, there is one other machine on site2 today that belongs to site1's domain and another that doesn't belong to any domain. Both of these machines worked fine using email on the domain-a.com domain accessed remotely on site1.
0
 
edz_pgtAuthor Commented:
I may have spoken too soon!

I only have access to one machine at the moment. It is on site2, configured for Outlook connection to site1 to receive email from domain-b.com

It's not synchronising properly and occasionally gets an autodiscover certificate warning pop up which quotes domain-b.com at the top. Since all mail now goes in and out of site1's server and it's primary domain is domain-a.com, it seems that this autodiscover warning could be coming from the SBS server on site2.

Is there a way to get around this?
0
 
praveenkumare_spCommented:
please check ,but this might be repeate , but this behavior looks like caused of outlook provider


just type get-outlookprovider and let me know what u see there
0
 
MegaNuk3Commented:
Are you getting rid of Site2's SBS2008 server?
You can either kill AutoDiscover on this server or set the SCP to point to site1's server

On site1's SBS server do:
Get-clieantaccessserver | fl identity, autodiscoverserviceinternaluri
Note the autodiscoverserviceinternaluri value

Go to site2's SBS server and do:
Get-clientaccessServer | set-clientaccessServer -autodiscoverserviceinternaluri "<value noted from site1>"
0
 
MegaNuk3Commented:
Ideally as you move users to site1's SBS server you should be moving their computer account to the site1 domain too, then you would not be in this mess.
0
 
edz_pgtAuthor Commented:
Thanks.

I can understand why you might say that we should migrate the machines across to site1's domain. However, there is still a domain with file sharing and permissions set up on site2 which we need to keep in place. These two sites really need to remain separate at this stage if possible.

Should the identity parameter also be changed to match that of site1? At the moment, the autodiscoverserviceinternaluri value is set to the Site1 address but the identity is still stating site2's name.
0
 
MegaNuk3Commented:
You won't be able to change the Identity...

Any joy with outlook after changing the autodiscoverserviceinternaluri ? Do an outlook autoconfig test to confirm the correct URL is being picked up.
0
 
edz_pgtAuthor Commented:
I haven't had chance to get on to any of the affected PCs yet - Hopefully in the next couple of hours.
0
 
edz_pgtAuthor Commented:
OK - we're part way there I think. I've managed to get the Site2 PCs to connect to site1 for their email. However, they are getting a warning about an autodiscover certificate mismatch. The error is regarding autodiscover.domainb.com

Since this is likely to be produced by the server at site2, I'm wondering if it's best to disassociate domainb.com from the site2 server. I mean, if a machine on the site2 LAN tries to access an email account that the site2 server is associated with, then I'm likely to get conflicts. However, if we change the domainb.com configuration on site2's server to be something else then will that stop it trying to interfere?

If I'm thinking straight on this, what's the best way to disassociate the domain? Just the email recipient policy? or should we run the internet connection wizard and change the domain in there?
0
 
MegaNuk3Commented:
Or just kill the autodiscover SCP in Site2 and setup a DNS SRV record pointing autodiscover at the Site1 URL.
0
 
edz_pgtAuthor Commented:
How do you disable the autodiscover?
0
 
MegaNuk3Commented:
Quick question, if you create a new account in site1 on a site1 PC and logon and open outlook with that account does it give you a cert error?
0
 
edz_pgtAuthor Commented:
I don't really know for certain but I wouldn't have thought so since they would be using a Site1 domain PC, a site1 user account and a domainA email address that's associated with site1. All the DNS for site1 and domainA seems to be kind ok I think. The only thing that's happened here is that domainB has been added as an accepted domain and a recipient policy to set domainB if the company field matches a certain string on the user's account.
0
 
MegaNuk3Commented:
Can you test my previous comment please?
0
 
edz_pgtAuthor Commented:
It's not something I can easily do without knowing why I'm doing it. This is a client's network and they'll be asking me questions about what I'm doing and why I'm doing it.

Perhaps you could explain a bit more to give me some background theory please?
0
 
edz_pgtAuthor Commented:
Since we've been making changes, it now seems that the SQL Server on Site2's server isn't allowing logins. Seems like a coincidence to me but I can't help wondering if I've messed something up by altering things related to certificates or autodiscover etc.

Any ideas?

0
 
MegaNuk3Commented:
AutoDiscover has nothing to do with SQL, check your DNS and DC event logs for trust issues.
0
 
edz_pgtAuthor Commented:
Glad to hear that! - The finger is being pointed towards me since I've been the one messing with the server!
0
 
edz_pgtAuthor Commented:
In the end, the SQL issue was nothing but a coincidence and the supply of the wrong login credentials from the client.

Also, the mail functionality was migrated to Google Apps and everyone is a lot happier now (including me!).

Even though we didn't nail the issues in the end, thanks for all your help.
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

  • 17
  • 9
  • 5
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now