Today I had a interesting case with a customer! a user tries to log on to Outlook Web App, after a successful authentication the “loading page” just sits on the screen and nothing happens, see screenshot.
The user in question had been using OWA earlier without issues! But now it did not matter how long I waited, what browser I used or from what type of computer I tried the user was always “stuck” on the loading page and nothing happened. The strange thing was that if I changed the URL from /OWA to /ECP I was able to access the ECP part as the user. That ruled out authentication issues. So I started investigate the mailbox with PowerShell, nothing strange there, the user had OWA enabled and so on. After a while I thought that some settings must be wrong within OWA itself so I decided to click through ECP as the user and suddenly I realized the issue. Time and date format!
As soon as I went to Settings, Regional in ECP I got this warning (the user has Swedish settings so part of the message is in Swedish but see translation below)
Date format M/d/yyy isn’t valid for current language settings sv-SE. Valid formats include: yyyy-MM-dd, yy-MM-dd
The Timeformat h:mm tt isn’t valid for current language settings sv-SE. Valid formats include: HH:mm, H:mm, kl H:mm
After I changed the time and date format the user could successfully log on again!
So I tried to replicate this in PowerShell and it turn’s out that it’s being validated before it’s set so I have no idea how the user ended up in a corrupted state but he mentioned to me that he had changed the language before.
Hope this can help someone, please respond if you come across this and have and idea about how it can happen.
Update: This issue have been fixed in CU2
As part of an Exchange 2013 deployment I used the Exchange Admin Center, EAC, to create a request a new certificate today. The whole process of doing that is described in numerous places on the web (like here) so I wont go into details about that but I will mention a fact that came as a bit of a surprise to me….
After all the “hard work” with getting all namespaces correct the only part left was to enter the details of the customer. In this part you type in information about Organization name, Department, where you are located and so on. Normally this doesn’t present a huge challenge for me but when I for the second time got the request file back from the certificate provider telling me to enter the organization name correct I asked my self if I had gone totally bananas… But as I soon discovered the wizard in Exchange 2013 actually switches two fields… What you enter in “Organization name” will in the request file be presented in “Department name” and vice versa.
So in the example below (picture taken from Digicert link above), “Your Company Inc” would in the request end up in the department feels and “IT” where your organization name should have been.
This error is present in Exchange 2013 RTM and CU1 but the team over in Redmond know about the issue so I expect this to be fixed in future releases.
So what is the real impact of this problem? I would say very little besides the fact that some certificate provider, like my customers today, maybe won’t issue a certificate if the check all the details carefully. Once you have your cert, even if it has the two fields mixed up, it will work just as expected so no huge issue but something to be aware about.
Update: I forgot to mention that this issue won’t happen if you generate your request from Exchange Management Shell! Thanks for the reminder Dave! And while I’m thanking I should say a thank you to TRUSTZONE as well who twice rejected our requests, wouldn’t have seen this other ways.
A great friend and fellow MVP, Anders Olsson, wrote a blog about how users in Outlook Web App get’s logged out after 5 minutes. Since Anders writes in Swedish we thought it would be a good idea to publish it in English as well so here it is.
More and more organizations are upgrading their Exchange solutions to Exchange 2013. Many of these organizations uses a Forefront Threat Management Gateway, TMG, to secure the messaging solution. In most cases this works perfectly well but some have ran into issues with dropped sessions after 5 minutes. This is a known problem when TMG and Exchange 2013 are communicating but it only affects a few customers and we have not yet found the common ground for these issues. Microsoft has not yet released a official fix for this but TMG has a feature that can be used to solve the problem.
Session timeout is normally based on a user choice when logging on. In the Forms based authentication form a user can choose between Public or private computer witch results in 10 or 360 minutes session timeout.
These timeout values can be set via “Advanced Form Options from Forms on each listener in TMG.
Changing the value of these settings has proven not to work for customers with these issues.
The solution to this problem is a feature in TMG called Credential Caching. From Advanced (Authentication Options) on the listener you will find Client Credentials Caching. The feature has a self explanatory name, it caches the credentials for a certain time and the default value is 300 seconds, witch of course is out 5 minutes. By changing this value we can raise the time clients stays logged on.
You should NOT change the timeout value if you don’t experience this specific issue!
More information about how to publish Exchange 2013 with TMG can be found on the Exchange Team blog.
On site with a customer today I was asked to provide all bookings of room mailboxes with a note about who was the organizer. No big deal, there’s a feature for that called “Add the organizer’s name to subject” on room mailboxes, se below.
Said and done it was set on all room mailboxes and I tested to book a meeting. To my surprise the subject was not changed and no organizer was added as seen below.
After a session with Bing I found a note about this on Technet Forum and tested to add a distribution group to who was allowed to book the room. In my case I ran:
Get-Mailbox –Recipienttypedetails roommailbox | Set-CalanderProcessing –AllBookInPolicy $false –BookInPolicy mailmasterlab_all
And as soon as the command was finished I ran:
Get-Mailbox –Recipienttypedetails roommailbox | Set-CalanderProcessing –AllBookInPolicy $true
After this the organizers name is added to the subject.
My Exchange 2010 Server was a fresh install of Exchange 2010 Service Pack 3.
I know this post is really late, two weeks to be precise, but I just had two customers who told me they had no idea that this RU was out due to the lack of information about it on my blog. Sorry about that, it’s been hectic for some time.
This time I have no personal “favorite” issues solved so I suggest you read what the Exchange team wrote.
UPDATE 2: The fix for this is now in http://support.microsoft.com/kb/2618444 so no need to call support
UPDATE! A fix for this issue is now available, have a look at http://blogs.technet.com/b/exchange/archive/2011/10/17/a-fix-for-the-interoperability-issues-between-exchange-2007-and-2010-emc-and-ie9-is-now-available.aspx
I have seen some issues with Exchange Management Console after Internet Explorer 9 is installed on the server. You get a dialog box like the one below:
Event though there are now dialog box open you get “You must close all dialog boxes before you can close Exchange Management Console”
After I uninstalled IE9 everything worked fine again but I guess the will be a fix for this issue soon but for now you can uninstall IE9
Do you get a “550 Client host rejected: [not accepting mail from this ip]” when you send mail today?
It’s a Mxtreme issue when you have Reputation Authority enabled.
Two solutions are available to fix this:
a. Remove a DNS entry’s for borderware.com in DNS servers Boderware uses.(You find them under Configuration -> Network or Interfaces).
b. Empty DNS cache in Mxtreme/XCS under Status & Utility -> Flush DNS Cache.
If above doesn’t work you can disable the Reputation Authority:
Intercept – connection control
-Clear all checkboxes under BSN
-Clear Reject on DNSBL under DNSBL Reject Intercept – Anti-spam
-Clear DNS Block list
-Clear URL Block list
Security – ReputationAuthority
-Clear all checkboxes on that page
Security – Connection control
-Clear Reject on DNSBL
Security – anti-spam
-Clear DNS Block list
-Clear URL Block list
I know this was not at all related to Exchange but I had this problem first hand today…
Update: I think someone at Borderware forgot to register… A whois on borderware.com gave me the following result:
Update 2: Try do the following as well:
Go to Activity – Threat Prevention Status and press “Reset Threat Prevention History”