Hello!

One more strange issue: in all my deployments of Exchange Server 2013SP1 I always start from removing a default mb database and I never had any problems with it. The procedure is ~ as follows:

1) I create a new mailbox db.
2) Get-Mailbox Arbitration | New-MoveRequest -TargetDatabase NewDB
3) Get-Mailbox Monitoring| New-MoveRequest -TargetDatabase NewDB
4) Get-Mailbox | New-MoveRequest -TargetDatabase NewDB

5) Make sure Administrator account has been moved to the new db.

6) Delete the default db.
7) Restart
8) Log on to ECP as Administrator.

Today the two new installations end up  with the following error on 8)  "Log on to ECP as Administrator":

The IIS log shows this:

"2015-04-17 13:56:17 fe80::191b:2b21:3254:ddd%12 POST /owa/auth.owa &CorrelationID=<empty>;&cafeReqId=8bb165df-6c57-49f0-9ee9-9590c6f981db; 443 TestCompany\Administrator fe80::191b:2b21:3254:ddd%12 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko https://exch1.testcompany.com/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fexch1.testcompany.com%2fowa 500 0 0 15"

Looks like the Administrator's mailbox has not been moved into the new database, but Get-MoveRequest and Get-Mailbox... showed that Administrator's mailbox was really in the new db.

Moreover, right after deletion of the default db (after item 6) I signed out from ECP and logged back to it - the logon was successfull (at this moment the default database had been already deleted!). And only after restarting the server it started showing this error.

While logged on as Administrator I created one more exchange administrative user account in the new db - it doesn't experience any issues with logging on to ECP.

No errors show in any Windows logs.

What should I check in this situation?

Thank you in advance,

Michael

"What exactly was the validation process as described in step #5?"

For example:

RunspaceId                             : 6036c666-da17-4c1a-8465-76e5cb4aa5c7
Database                               : TestCompany
Location                               :
UseDatabaseRetentionDefaults           : True
RetainDeletedItemsUntilBackup          : False
DeliverToMailboxAndForward             : False
IsExcludedFromServingHierarchy         : False
LitigationHoldEnabled                  : False
SingleItemRecoveryEnabled              : False
RetentionHoldEnabled                   : False
EndDateForRetentionHold                :
StartDateForRetentionHold              :
RetentionComment                       :
RetentionUrl                           :
LitigationHoldDate                     :
LitigationHoldOwner                    :
LitigationHoldDuration                 : Unlimited
ManagedFolderMailboxPolicy             :
RetentionPolicy                        :
AddressBookPolicy                      :
CalendarRepairDisabled                 : False
ExchangeGuid                           : da0cb195-14d4-4755-b661-a689dc5abae6
MailboxContainerGuid                   :
AggregatedMailboxGuids                 : {}
ExchangeSecurityDescriptor             : System.Security.AccessControl.RawSecurityDescriptor
ExchangeUserAccountControl             : None
AdminDisplayVersion                    : Version 15.0 (Build 847.32)
MessageTrackingReadStatusEnabled       : True
ExternalOofOptions                     : External
ForwardingAddress                      :
ForwardingSmtpAddress                  :
RetainDeletedItemsFor                  : 14.00:00:00
IsMailboxEnabled                       : True
Languages                              : {en-US}
OfflineAddressBook                     :
ProhibitSendQuota                      : Unlimited
ProhibitSendReceiveQuota               : Unlimited
RecoverableItemsQuota                  : 30 GB (32,212,254,720 bytes)
RecoverableItemsWarningQuota           : 20 GB (21,474,836,480 bytes)
CalendarLoggingQuota                   : 6 GB (6,442,450,944 bytes)
DowngradeHighPriorityMessagesEnabled   : False
ProtocolSettings                       : {RemotePowerShell1}
RecipientLimits                        : Unlimited
ImListMigrationCompleted               : False
IsResource                             : False
IsLinked                               : False
IsShared                               : False
IsRootPublicFolderMailbox              : False
LinkedMasterAccount                    :
ResetPasswordOnNextLogon               : False
ResourceCapacity                       :
ResourceCustom                         : {}
ResourceType                           :
RoomMailboxAccountEnabled              :
SamAccountName                         : Administrator
SCLDeleteThreshold                     :
SCLDeleteEnabled                       :
SCLRejectThreshold                     :
SCLRejectEnabled                   

P.S. "What exactly was the validation process as described in step #5?"

And I suppose this "right after deletion of the default db (after item 6) I signed out from ECP and logged back to it - the logon was successfull (at this moment the default database had been already deleted!)" can  validate the moving as well.

Since only the database was change the only thing that comes to mind is to make sure RpcClientAccessServer on database was set to the CAS or CASArray.

Get-MailboxDatabase "<database name>" | fl *rpc*

Hi MF47,

Have you tried the above suggestions ? How about the result ?

Best regards,

"Get-Mailbox Administrator | FL Database"

"What if you try the IP of the CAS server instead of the FQDN, does it work?  Can you access OWA as administrator or do you get the same HTTP 500 error?" - the same error.

"Get-MailboxDatabase "<database name>" | fl *rpc*"

- that's the correct output...

Now I can successfully log on to Administrator's mailbox using OWA

...but trying to open ECP leads to the same error (after typing Administrator / Password):

So the question is: what's the difference between logging into OWA and ECP?

Regards,

Michael

• Edited by MF47 16 hours 29 minutes ago

When you log into ECP, you are using the OWA login ressources.

Authentication settings should be the same on OWA and ECP Vdir (Forms for both, or WI for both, etc.). What are your current auth mecanism for both OWA and ECP?

Now I can successfully log on to Administrator's mailbox using OWA

...but trying to open ECP leads to the same error (after typing Administrator / Password):

So the question is: what's the difference between logging into OWA and ECP?

Regards,

Michael

• Edited by MF47 Monday, April 20, 2015 2:56 PM

Now I can successfully log on to Administrator's mailbox using OWA

...but trying to open ECP leads to the same error (after typing Administrator / Password):

So the question is: what's the difference between logging into OWA and ECP?

Regards,

Michael

• Edited by MF47 Monday, April 20, 2015 2:56 PM

Now I can successfully log on to Administrator's mailbox using OWA

...but trying to open ECP leads to the same error (after typing Administrator / Password):

So the question is: what's the difference between logging into OWA and ECP?

Regards,

Michael

• Edited by MF47 Monday, April 20, 2015 2:56 PM

ECP:

Name                            : ecp (Default Web Site)
InternalAuthenticationMethods   : {Basic, Fba}
MetabasePath                    : IIS://EXCH1.TestCompany.com/W3SVC/1/ROOT/ecp
BasicAuthentication             : True
WindowsAuthentication           : False
DigestAuthentication            : False
FormsAuthentication             : True
LiveIdAuthentication            : False
AdfsAuthentication              : False
OAuthAuthentication             : False

OWA:

Name                                                : owa (Default Web Site)
InternalAuthenticationMethods                       : {Basic, Fba}
MetabasePath                                        : IIS://EXCH1.TestCompany.com/W3SVC/1/ROOT/owa
BasicAuthentication                                 : True
WindowsAuthentication                               : False
DigestAuthentication                                : False
FormsAuthentication                                 : True
LiveIdAuthentication                                : False
AdfsAuthentication                                  : False
OAuthAuthentication                                 : False

Regards,

Michael

• Edited by MF47 21 hours 58 minutes ago

P.S. By the way, according to this article
"https://technet.microsoft.com/en-us/library/gg247612%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396"

OWA vd should have the following permissions in IIS: BASIC.

But my IIS shows this:

Enabling Basic authentication changes nothing.

Regards,

Michael

Hello, in the future use this to deploy your exchange with correct database name, location, etc:

./Setup.exe /m:Install /Roles:ca,mb,mt /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents /DBFilePath:"E:\Folder\DB.edb" /LogFolderPath:"E:\Folder" /MdbName:"DB"

ECP:

Name                            : ecp (Default Web Site)
InternalAuthenticationMethods   : {Basic, Fba}
MetabasePath                    : IIS://EXCH1.TestCompany.com/W3SVC/1/ROOT/ecp
BasicAuthentication             : True
WindowsAuthentication           : False
DigestAuthentication            : False
FormsAuthentication             : True
LiveIdAuthentication            : False
AdfsAuthentication              : False
OAuthAuthentication             : False

OWA:

Name                                                : owa (Default Web Site)
InternalAuthenticationMethods                       : {Basic, Fba}
MetabasePath                                        : IIS://EXCH1.TestCompany.com/W3SVC/1/ROOT/owa
BasicAuthentication                                 : True
WindowsAuthentication                               : False
DigestAuthentication                                : False
FormsAuthentication                                 : True
LiveIdAuthentication                                : False
AdfsAuthentication                                  : False
OAuthAuthentication                                 : False

Regards,

Michael

• Edited by MF47 Tuesday, April 21, 2015 9:29 AM

ECP:

Name                            : ecp (Default Web Site)
InternalAuthenticationMethods   : {Basic, Fba}
MetabasePath                    : IIS://EXCH1.TestCompany.com/W3SVC/1/ROOT/ecp
BasicAuthentication             : True
WindowsAuthentication           : False
DigestAuthentication            : False
FormsAuthentication             : True
LiveIdAuthentication            : False
AdfsAuthentication              : False
OAuthAuthentication             : False

OWA:

Name                                                : owa (Default Web Site)
InternalAuthenticationMethods                       : {Basic, Fba}
MetabasePath                                        : IIS://EXCH1.TestCompany.com/W3SVC/1/ROOT/owa
BasicAuthentication                                 : True
WindowsAuthentication                               : False
DigestAuthentication                                : False
FormsAuthentication                                 : True
LiveIdAuthentication                                : False
AdfsAuthentication                                  : False
OAuthAuthentication                                 : False

Regards,

Michael

• Edited by MF47 Tuesday, April 21, 2015 9:29 AM

ECP:

Name                            : ecp (Default Web Site)
InternalAuthenticationMethods   : {Basic, Fba}
MetabasePath                    : IIS://EXCH1.TestCompany.com/W3SVC/1/ROOT/ecp
BasicAuthentication             : True
WindowsAuthentication           : False
DigestAuthentication            : False
FormsAuthentication             : True
LiveIdAuthentication            : False
AdfsAuthentication              : False
OAuthAuthentication             : False

OWA:

Name                                                : owa (Default Web Site)
InternalAuthenticationMethods                       : {Basic, Fba}
MetabasePath                                        : IIS://EXCH1.TestCompany.com/W3SVC/1/ROOT/owa
BasicAuthentication                                 : True
WindowsAuthentication                               : False
DigestAuthentication                                : False
FormsAuthentication                                 : True
LiveIdAuthentication                                : False
AdfsAuthentication                                  : False
OAuthAuthentication                                 : False

Regards,

Michael

• Edited by MF47 Tuesday, April 21, 2015 9:29 AM

Because when you deploy with standard method Exchange setup will create a default database with a name you don't want. With this method, you create the correct database name, location, etc.

Is it more clear for you ?

Hi MF47,

Let me know the result of below URL: Customize the domain name as per your environment.

https://exch1.testcompany.com/ecp?ExchClientVer=15 

Hu Satyajit321,

I'll do it a bit later - need to rebuild the lab.

Hello all,

"Let me know the result of below URL: Customize the domain name as per your environment.

https://exch1.testcompany.com/ecp?ExchClientVer=15 

"

- the same error:

Regards,

Michael

Hi MF47,

Is this issue with only the account which is moved to new DB or to other Admins created on the new DB as well.

Hi Satyajit321,

"Is this issue with only the account which is moved to new DB" - yes, it's only Administrator account wich can't log on to ECP. The other one (ExAdmin) that has been created in the new DB does not suffer from it.

Regards,

Michael

I've already tried various authentication options with no luck... I can successfully log on to Administrator's mailbox (via OWA) but not to ECP.

• Edited by MF47 16 hours 27 minutes ago typo

I've already tried various authentication options with no luck... I can successfully log on to Administrator's mailbox (via OWA) but not to ECP.

• Edited by MF47 Thursday, May 28, 2015 3:01 PM typo

I've already tried various authentication options with no luck... I can successfully log on to Administrator's mailbox (via OWA) but not to ECP.

• Edited by MF47 Thursday, May 28, 2015 3:01 PM typo

I've already tried various authentication options with no luck... I can successfully log on to Administrator's mailbox (via OWA) but not to ECP.

• Edited by MF47 Thursday, May 28, 2015 3:01 PM typo

Hi MF47,

It can be working on Exch2 for two possible reasons that I can think up of:

1. Exch2 is proxying the connection to Exch1 (Unbound model does this by default)

2. When you are accessing ECP on EXCH2 it talks to the AD directly and there is no need to reach the mailbox (Exch1), any cmdlets will anyways proxied\remoted.

Anyways nothing explains what's up with Exch1 and the Administrator account. May be some sort of Deny permissions got set in Exch1 for that user or something is broken.

Nobody seem to have asked, but hope EMS on Exch1 with Administrator account is running fine.

Have you tried re-creating the ECP virtual directory on EXCH1:

Give it a shot and let me know.

Test and record current info:

Test-EcpConnectivity -ClientAccessServer Server01


Get-EcpVirtualDirectory -Server Server01

Reset ECP Virtual Directories:

Remove-EcpVirtualDirectory -Identity "Server01\ecp (default Web site)"

New-EcpVirtualDirectory -Server SERVER01 -ExternalURL https://mail.contoso.com/ecp -InternalURL https://mail.contoso.com/ecp 

After re-creation re-set the auth:

For the "ECP" virtual directory

1. Start Windows PowerShell.
2. Type the following commands, and then press Enter after each line:

Add-PSSnapin *exchange*

Set-EcpVirtualDirectory -Identity "E15MBX\ecp (Exchange Back End)" -WindowsAuthentication $true -FormsAuthentication $false

  3.  Run the following command on both the Client Access and Mailbox servers to restart Internet Information Services (IIS):

iisreset /noforce

References:

New-EcpVirtualDirectory

https://technet.microsoft.com/en-us/library/dd351218(v=exchg.150).aspx

Reset Client Access Virtual Directories

https://technet.microsoft.com/en-us/library/ff629372.aspx

Cannot access Outlook Web App or the EAC after you re-create the "owa" or "ECP" virtual directory on an Exchange Server 2013 Mailbox server

https://support.microsoft.com/en-us/kb/2778897

Hi Satyajit321,

Thank you very much for the detailed instructions - I'll try to follow them when I have time.

I think it's not ECP issue because my second administrative account (ExAdmin) can successfully log onto ECP (this account was created AFTER removing a default database).

"2. When you are accessing ECP on EXCH2 it talks to the AD directly and there is no need to reach the mailbox (Exch1)," - there really is the need to reach the Administrator's mailbox on Exch1, it's not possible to log onto Exch2\Ecp or Exch2\OWA when Exch1 is offline.

In any case it's not normal (mildly speaking) that almost every new Exchange installation should end up with ECP recreation. I'm going to open a case with MS regarding it.

Regards,

Michael

Hi Michael,

Why I suspected ECP of EXCH1, its because everything else works on EXCH1 and on EXCH2 even the ECP works.

"Adminsitrator's mailbox on Exch1, it's not possible to log onto Exch2\Ecp or Exch2\OWA when Exch1 is offline."

Shows that there is some issue with your installation or the adminstrator account itself.

During my test I was able to login to ECP using an AD Account which didn't had any mailbox, it was just a simple User Account with Organization management group membership.

OWA is used for authentication part when accessing the ECP directory, you don't have to reach the other server OWA to do that.

My test confirms that, user ECP access is not related to the mailbox location as actually its the connection with the current server and AD. But depending upon the requirement it might talk to the other server if OWA or someting related to mailbox is triggred.

Below happens when I try to access the OWA url for the AD admin.

--------------------------------------

https://EXCH2/OWA

:-(

something went wrong

A problem occurred while you were trying to use your mailbox.

X-OWA-Error: Microsoft.Exchange.Data.Storage.UserHasNoMailboxException
X-OWA-Version: 15.0.913.21
X-FEServer: EXCH-2
X-BEServer: EXCH-1
Date: 6/4/2015 9:27:00 AM

--------------------------------------

Basically ECP on EXCH2 should work even when EXCH1 is down. Mailboxes might not work ofcouse depending if you have DAG, witness etc or not.

Hey this gives me another IDEA :)

Why not Disable-Mailbox Administrator and then try.(This would be less impacting than re-creating the ECP)

If it works, Connect-Mailbox and try again. (Maybe the mailbox part of admin has some corruption\issues)

Another IMPORTANT point would be are you able to reproduce the issue.

Regarding your case you are correct, fresh install should not have issues like this. If you can get a MS case opened on this nothing like it, do update the status here, so that it benefits the community as well.

Hi Michael,

I have done some more tests and found that if mailboxes are in a DB not in DAG, there is some issue connecting to the ECP as well using the regular URL

https://exch2/ecp/

However the other one works fine, even when mailbox server hosting the single instance DB is down.

https://exch2/ecp/?ExchClientVer=15

There seems to be some mechanism that triggers for accounts having mailboxes to detect the version. Bypassing which we can bypass the account's mailbox server while accessing ECP.

Normal user:my account page of ECP:  https://exch-1/ecp/?rfr=owa

Admin user also hits this page, but if found that its an admin it redirects to the appropiate EAC page. This is where I think the mailbox role interacts.

If we want to force access 'my accounts' for a Exchange Admin.

Use https://exch-1/ecp/?rfr=owa

You scenario is somwhat different though, still thought of updating it

Hi Satyajit321,

The main problem is that nobody knows if this  - "Shows that there is some issue with your installation or the adminstrator account itself."  - is true or not because there's NO documentation on technet stating how log on to ECP in multi-server environment should work. I asked this question here:

https://social.technet.microsoft.com/Forums/sqlserver/en-US/925d1c57-eed7-427a-86d4-154cdd9c5b15/multiple-exchange-2013-servers-ecp-redirects-on-second-server?forum=exchangesvradmin

"the EAC/OWA will automatically redirect your connection to the server where the mailbox is currently active so in this case if the admin account mailbox is active on Server1 then I can only access the EAC on server 1."

"https://exch2/ecp/?ExchClientVer=15" - I've already tried it with no luck.

"Why not Disable-Mailbox Administrator and then try.(This would be less impacting than re-creating the ECP)" - befor disabling Administrator's mailbox I tried to log onto Exch1\ECP once again to make sure it does not work ... but it worked... I have no explanation to this... am lost for words... Will keep an eye on this issue for some time from now on.

"Another IMPORTANT point would be are you able to reproduce the issue." - it arises as soon as I delete the default DB.

Regards,

Michael

Hi Michael,

Good news that something out of all the troubleshooting you have done worked, now the problem being finding which one worked.

Regarding your other post:

I was also thinking of posting the same, but seems like you have already.
As you had mentioned on the post "all client access is now directed to whichever server the corresponding mailbox database is active on." this is my observation as well, but not documented anywhere.(Again appears to be insiders info)

If you can reproduce the issue, there is definately something more serious to look after, if not we can just ignore it being some random MailboxMove related issue.

If you still want to figure this out, let do this:

1. Share the exact steps required to reproduce the issue (I'll try this out to confirm if its a bug or something)

Does this occur if you move an admin from custom DB2 and delete DB2. If not then to reproduce the issue do we need to install the Exchange environment again from fresh.

2. Reproduce the issue for some other admin user, then Disable-Mailbox on it or access ExchClientVer=15 URL and then try. (This will give us lead on which section to concentrate upon)

References:

Exchange 2013 Default DB

http://blogs.technet.com/b/rischwen/archive/2012/12/17/exchange-2013-default-db.aspx

Hi Satyajit321,

"Good news that something out of all the troubleshooting you have done worked" - bad news that, strictly speaking, I've done nothing... I still don't know why ECP did NOT work and why it now works so I don't now how I can "Reproduce the issue for some other admin user".

The steps to reproduce the issue (or to not reproduce) as follows:

https://michaelfirsov.wordpress.com/deploying-exchange-2013-sp1-step-by-step-part1/

- when I was writing this article I had no issues with ECP (as far as I remember I did the test installation at least twice). Now when I follow these steps to install Exchange on the SAME machines I get the error in the 100% of installations.

Regarding "all client access is now directed to whichever server the corresponding mailbox database is active on." this is my observation as well, but not documented anywhere.(Again appears to be insiders info)" - if one the most important fact of Exchange's behaviour is just an "insiders info" than there can not be any real troubleshooting of any ECP issues because no grounds exists to have any surmises or conjectures. Lack of documentation on Exchange 2013 is one of the reason why I don't recommend Exchange 2013 for deploying.

Regards,

Michael