Good morning. It is another fine day in support. I wanted to share an issue that I have seen a couple of times and want to have it handy for future reference. I had a customer with an SBS (Small Business Server) 2011 install. He was adding in Outlook 2016 clients, but could not get any of them to connect with autodiscover. One key piece of information in this case is that Outlook 2010 and 2013 clients work fine. With this in mind I checked Google. I found quite a few articles pointing to disabling MAPI/HTTP. This should not keep Outlook 2016 from connecting as it will drop down to RPC/HTTP.
In the end I setup an Outlook profile with IMAP. I was then able to get into Outlook and run an autodiscover test. When I ran the test I was able to get the error code from the server. Here is what I saw:
Autodiscover then proceeded to try the default path and failed. I did a search on this error code and found the following Microsoft article. My customer was running the latest version of Outlook though. I ended up doing the workaround at the bottom. Here it is.
- Open Registry Editor.
- Locate and then click the following registry subkey:
- On the Edit menu, point to New, and then click DWORD Value.
- Type ExcludeHttpsRootDomain, and then press Enter.
- On the Edit menu, click Modify, type 1 in the Value data box, and then click OK.
- Exit Registry Editor.
Outlook immediately worked after this, and much faster.
I hope this article has been informative. If you have anything to add or just want to comment, please do so below.
Good morning. Today I wanted to post a couple of quick one line PowerShell commands for Exchange 2010. I used both of these today and they are invaluable in certain situations.
The first command is used to load local Exchange Shell. Normally you don’t want to do this, but I had issues with RBAC (Role Based Access Control) that prevented doing anything in Exchange Shell or Exchange Management Console.
- Run a PowerShell command as Administrator
- Run: Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
The second command is very useful in multi-domain exchange forests. For instance if multiple user accounts are in a child domain, but Exchange is in the parent domain, and you need to move the mailboxes.
Here is the command without setting the AD server setting parameter:
Get-Mailbox -Database “Mailbox Database” -Domaincontroller DC.child.domain.com | New-MoveRequest -TargetDatabase “New Database” -Domaincontroller DC.child.domain.com
Here is the command to change the behavior of Exchange Shell to mimic Exchange Management Console:
Set-AdServerSettings -ViewEntireForest $True
And the resulting command to move mailboxes as above:
Get-Mailbox -Database “Mailbox Database” | New-MoveRequest -TargetDatabase “New Database”
I hope you have found this article informative. If you have any comments or suggestions, please leave them below.
This will be the first in a short series of articles I will be writing on mail flow troubleshooting. I wanted to start with a general article on how to narrow the scope of the mail flow issue. Mail flow issues typically fall into one of three categories.
- External mail is not coming in for all or some email.
- Internal mail is not going out to the Internet for all or some email.
- Internal mail flow is not working.
So before we start troubleshooting we need to determine which category to focus on. Occasionally you may see an issue that encompasses more than one of the categories above. If that is the case then it is best to start on internal mail flow.
When I start looking at a mail flow issue I like to start with a few questions.
- Are you having any issues sending or receiving emails to other users in your organization?
If the answer is yes, then this narrows down the scope of the issue tremendously. If the answer is no, then we know we need to start on internal mail flow troubleshooting.
- Are you having a problem with receiving emails from users outside your organization?
If the answer is yes, then you can focus on troubleshooting mail coming in from the Internet. If the answer is no, then the issue is likely mail going out to Internet is having issues.
- Are you having problems with users outside your organization receiving the emails your users are sending?
If the answer is yes, then you can focus on mail going out to other mail servers on the Internet.
So now that we have an understanding of how to narrow the scope of the issue, the next parts of this series will focus on troubleshooting each of the different categories.
This is one of those errors that is a real pain because there are so many issues that can cause it. In this article I wanted to touch on a fairly new issue that causes this issue; MAPI over HTTP.
If you have not heard of MAPI over HTTP, it is the replacement for RPC over HTTP as the default connection method for Exchange 2016. It is also available in 2013 SP1 and later, but not turned on by default. So if you are installing the first Exchange server in an organization and it is Exchange 2016, then MAPI over HTTP is enabled as the default protocol. If the MAPI URL is not configured then Outlook 2013+ clients will see the error above when trying to setup the mailbox.
The fix is pretty easy though. The MAPI virtual directory must be configured to match the certificate name. The below command should do the trick. Just make sure and change the name to the correct one for your environment.
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl https://hostname.domainname.com/mapi -ExternalUrl https://hostname.domainname.com/mapi
So there you have it. Hopefully this did the trick for you. If you have any questions or suggestions, please leave a comment below.
Here is an issue I see just infrequently enough to forget it. When accessing OWA (Outlook Web Access), the following interaction takes place.
- The user accesses OWA via a web browser and receives the logon page.
- The user enters his/her credentials and presses the Sign in button.
- The user is presented with a 500 Internal Server Error screen. The address indicated is https://myexchangeserver.mydomain.com/owa/auth.owa. The title bar typically indicates HTTP 500 Internal Server Error.
The most common cause for the above behavior is the “Microsoft Exchange Forms-Based Authentication service” is not started. Sometimes this service does not automatically start at boot. Simply starting the service will correct the issue.
In case the above is not causing the issue, there is another easy step to correct the issue. Reset the OWA virtual directory. Below are the PowerShell commands.
- Get-OwaVirtualDirectory ‘SERVER\owa (Default Web Site)’ | fl
- Remove-OwaVirtualDirectory ‘SERVER\owa (Default Web Site)’
- New-OwaVirtualDirectory -WebSiteName ‘Default Web Site’
In all of the above commands, replace SERVER with the actual server name.
The first command is to get all settings for OWA. This can be useful if it is later determined there were custom settings that need to be restored. The second command removes the existing virtual directory. The last command creates a new OWA virtual directory will all default settings.
If after doing all of the above, and the issue remains, it is time to start going through the IIS (Internet Information Server) logs and the event viewer to determine the cause of the problem.
If you have another scenario where OWA is generating a 500 Internal Server Error I want to hear about in the comments section.