In a previous post I explained how you can use a SRV record to resolve certificates issues with Autodiscover when your Internal domain isn’t an analogous as your Email domain. This time, I’m going to clarify how to fix things by making adjustments to Exchange and Active Directory that may allow things to function continually while not having to use a SRV record or any DNS records at all, for that matter. But provided that the computer systems that access Exchange are participants of your Domain. The Active Directory SCP is how Exchange hands out Autodiscover configuration URLs by default with none DNS or SRV history.
However, when you have an Private Domain Name in your AD environment, which you should definitely try to avoid when you’re constructing new environments now, you will always get a Certificate Error when you use Outlook on account that SSL certificates from third party CA suppliers won’t do inner most domains on SAN certificates anymore. To fix this little problem, I will first come up with a bit information on a lesser known characteristic in Active Directory called the Service Connection Point SCP. SCPs play an Important role in Active Directory. They are essentially entries in the Active Directory Configuration Partition that outline how domain based users and computer systems can connect with a variety of amenities on the domain. Hence the name Service Connection Point.
These will customarily happen in one of the vital Active Directory tools that a large number of people overlook, but is really important in Exchange since 2007 was released, Active Directory Sites and Services ADSS. ADSS is usually used to define replication boundaries and paths for Active Directory Domain Controllers, and Exchange uses the information in ADSS to direct users to the appropriate Exchange server in large environments with numerous AD Sites. But what you also can do is view and make adjustments to the SCPs which are set up in your AD environment. You try this with a function it truly is overpassed even greater than ADSS itself, the Services node in ADSS. This can be exposed by right clicking the Active Directory Sites and Services object in case you have ADSS open, choosing view, then clicking “Show Services Node” like this:Once you open the services node, that you may see numerous the stuff that AD uses in the back end to make things work in the domain. Our focus here, even though, is Exchange, so go into the Microsoft Exchange node.
You’ll see your Exchange Organization’s name there, and you’ll then expand it to view all the Service Connection Points which are related to Exchange. I wouldn’t recommend making any changes in here unless you actually know what you’re doing, since this view is very akin to ADSIEdit in that it lets you examine stuff that may very abruptly break things in Active Directory. If we inspect the Microsoft Exchange facilities tree, you first see the Organization Name. Expand this, then navigate to the Administrative Group section. In any Exchange edition that helps Autodiscover, this may happen as First Administrative Group FYDIBOHF23SPDLT. If the long string of letters confuses you, don’t worry about it.
That’s just a joke the developers of Exchange 2007 put into the system. It’s a +1 Caesar Cipher meaning EXCHANGE12ROCKS when decoded. Programmers don’t get much humor in life, so we’ll just ought to forgive them for that and move on. Once you expand the executive group node, you’ll be capable of see many of the configuration alternatives for Exchange that are stored in AD. Most of these shouldn’t be touched. For now, expand the Servers node.
This is the area that defines all your Exchange servers and the way client programs can hook up with them. If you dig around in here. Mostly you just see folders, but if you right click on any of them and click on Properties, you will be capable of view an Attributes tab in Windows 2008+, a minimum of, ahead of that you simply need to use ADSIEdit to expose the attributes focused on the Services for ADSS. There are a lot of cool things that you may do in here, like change the greatest size of your Transaction Log files, implement strict limits on variety of databases per server, change how much the database grows when there isn’t enough space in the database to commit a transaction, and other fun things. What we’re focusing on here is Autodiscover, though, so expand the Protocols tree, then go to Autodiscover, as seen below. Now that we’re here, we see every one of the Exchange CAS servers in our environment.
Mine is named Exchange2013 when you consider that I am an incredibly artistic individual Except when naming servers. Again, that you may right click the server name after which select Properties, then go to the Attribute Editor tab to view all the stuff that you can control about Autodiscover here. It looks like a large number of stuff, right?Well, you’ll really only want to worry about two attributes here. The rest are described and utilized by Exchange to do…Exchangey stuff Technical term. And you’ll really only ever are looking to change one of them.
The two attributes you’ll want to know the goal of are “keywords” and “serviceBindingInformation”. For data, modern Active Directory Best Practices may help you avoid having problem with certificates errors in Exchange. Go here to see some information about modern AD Domain Naming best practices. If you follow that best follow when developing your AD surroundings, you won’t ought to worry loads about certificate errors in Exchange, so long as the Certificate you utilize has the Exchange Servers name listed. However, if you can’t build a new surroundings or aren’t already making plans emigrate to a new AD environment in the near future, it isn’t worth the trouble to do so when small configuration adjustments like placing the SCPAt this point, most groups are moving to or have moved to Office 365 for email.
However, in this system, you will find out some issues when you shut down your on prem endpoint for Exchange after migration is finished. Specifically, the SCP value remains to be picked up by Outlook in the course of the autodiscover manner, leading to slow or failed makes an attempt to connect. This can be fixed by editing the SCP to indicate to Office 365. Particularly, reconfigure the SCP so it points to Autodiscover s. outlook.
com or autodiscover. domain. com when you have pointed that value up. Make sure that any on prem DNS history for autodiscover. domain. com and autodiscover.
domain. local also are redirecting to autodiscover s. outlook. com for the domain’s autodiscover records, no matter if using CNAME, A, or SRV records. I’m so uninterested in looking for examples of how to set up a site where you truly have multiple alternate server. Apparently every site that runs Exchange as an email provider has only one server, one autodiscover inner DNS entry with one IP, and it all works.
Unfortunately, I’m an idiot, I have a couple of server for redundancy and such, and I’m looking to decide if I should have an autodiscover record in my internal DNS for only one server, or for all of them. I mean, we are talking about redundancy in spite of everything, right. So if you have an internal namespace of vfr. dataways. com and an exterior namespace/SMTP name as dataways. com with 2 CA servers and 4 DAG Exchange servers, just what should your autodiscover carrier be configured as on the inside?Should every server have the inner URL’s listed as the servername.
vfr. dataways. com which sort of negates any redundancy you might need decided to engineer into the system or should all of the URL’s be an analogous?I know I’m bucking the trend here with a couple of Exchange server, but does anyone have any suggestions as to how to set this up accurately, since right now, all my Exchange connections appear to go to the public web site URL’s instead on the inner ones, which is really pissing me off since every person loses their Outlook connection if the ISP drops. The best follow for Exchange High Availability is to use a hardware load balancer to handle client access and configure DNS with an A record for autodiscover and whatever else you are looking to use as the server name that points to the Virtual IP of the weight balanced application OWA/EWS/Etc. From there, all URLs for Exchange should use the DNS history for Autodiscover or mail. domain.
com or whatever else you want to have. The crucial part is that the Exchange CAS servers/URLs are looking to be load balanced for true redundancy. If you don’t have a load balancer, you will are looking to pick a single server as the “Primary” mail server and configure all URLs to point to that. If the primary server fails, you are going to want to manually change DNS to point to the “Secondary” server. Exchange will will let you access mailboxes that sit on the secondary server via the primary, so you simply ever have to have DNS records for client access pointing to one of them at a time, but a load balancer is needed if you want to avoid manual intervention in a failure.
You also can use Round Robin DNS to do things, but that doesn’t work very well in observe and causes random slowness and connectivity issues when one server fails. The SCP lookup in your situation would connect to the domain the computer is linked to to match the SCP before moving on with the method. Since both domain names have SCPs configured in them, doing a cross domain Autodiscover check will eventually fail since the autodiscover request that gets done uses an invalid email address, username, and password. The way to address this would be to disable the SCP lookup step on domain joined desktops in both domains in the event that they want to have cross domain money owed set up. You can try this in a pair ways, one is to push out a GPO that forces Outlook to skip the SCP lookup step This is more labor in depth, because it requires downloading, setting up, and configuring the GPO templates for Office for every version your agency uses. If the SCPs are Null, shoppers will fail on that step and move on to the non joined lookup steps.
You mention that SCP helps purchasers find a CAS in their site to avoid them from “crossing a replication boundary. ” If all CAS servers in a site are down, will the customer attempt to hook up with a CAS in a distinct site or just fail the SCP autodiscovery and fall through to the DNS autodiscover methods?I ask due to the fact that we suffered a server outage which took the local servers offline. The databases in a stretched DAG correctly failed over to an alternate site but the customers were unable to connect. Just thinking about if that is by design or if we now have something configured less robustly that it can be. Thanks.
Thank you loads. I though I had checked every little thing but if I used “Test Email Auto Configuration” by clicking outlook icon at bottom right of screen it showed me that my mapi virtual directory was set to inner address. I changed this mapi listing using here commandSet MapiVirtualDirectory Identity “machinename. domain. localmapi Default Web Site” InternalUrl IISAuthenticationMethods NTLM,NegotiateThis worked but outlook cache was still looking to inner tackle. I adjusted account to not use cache, all started outlook and then closed outlook.
Then enabled cache again and it linked fine. Thanks again.