Exchange Server Lost Trust to the Domain

A customer of mine running Exchange 2010 SP3 after a UPS had issues with Exchange loosing trust to the Active Directory domain.  This renders Microsoft Exchange unusable as all important Exchange configuration is stored within Active Directory.

Computer accounts like user accounts also have passwords.  These change every 30 days by default by Active Directory and member servers and workstations are automatically updated with the new password.  In the event the workstation or member server is not updated with the latest computer password; the trust fails and the machine displays the error “The trust relationship between the workstation and the primary domain failed” as shown in the screenshot below:

As a general fix for this issue, the PC is simply needs to be rejoined to the domain which works for most member servers and workstations.

Exchange however stores all its config in Active Directory and cannot be removed from a domain.

In the event you experience your Exchange Server loosing trust to Active Directory, you can re-establish trust using the following command on the Exchange Server after logging in with the local administrator account:

netdom resetpwd /server:AnyDomainController.yourdomain.local /userD:domain\administrator /PassworD:"youradminpassword"

Hope this post has been helpful.

Need IT Support with Microsoft Exchange in Perth?  Contact Avantgarde Technologies.

Direct Access Server not displaying Connection Statistics

A customer of mine had an issue with a Direct Access Server not displaying connection statistics.  My clients are connecting to the server without issues using IPHTTPS but we have no visibility to who is connected and for how long.

All connections and total bytes display 0 in both PowerShell and "Remote Access Management Console".

 

 

Also on the Remote Client Status page, no active clients are displayed.

This issue occurs when Windows Firewall is disabled on a Direct Access server.

Re-enable Windows Firewall and reboot the server.  After rebooting the server, wait 24 hours and you will notice statistics will start generating again.

Hope this post has been helpful.

Need IT Support or IT Services in Perth?  Contact Avantgarde Technologies.

EventID 1006 MSExchangeFastSearch

A customer had an issue with Microsoft Exchange 2013 search not working.  Users received an error "Your search didn't return any results" in Outlook Web App.

 

This following error was generated in the Application Logs on the server.

 

Log Name:      Application
Source:        MSExchangeFastSearch
Date:          14/10/2016 1:10:14 PM
Event ID:      1006
Task Category: General
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      Exchange.domain.local
Description:
The FastFeeder component received a connection exception from FAST. Error details: System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://localhost:3847/. The connection attempt lasted for a time span of 00:00:02.0469288. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:3847.  ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:3847
   at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
   at System.ServiceModel.Channels.SocketConnectionInitiator.ConnectAsyncResult.OnConnect(IAsyncResult result)
   --- End of inner exception stack trace ---

Server stack trace:
   at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at System.ServiceModel.Channels.CommunicationObject.EndOpen(IAsyncResult result)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at System.ServiceModel.ICommunicationObject.EndOpen(IAsyncResult result)
   at Microsoft.Exchange.Search.OperatorSchema.PagingImsFlowExecutor.CreateProxy()
   at Microsoft.Exchange.Search.OperatorSchema.PagingImsFlowExecutor.AcquireProxy()
   at Microsoft.Exchange.Search.OperatorSchema.PagingImsFlowExecutor.ExecuteServiceCall(IProcessingEngineChannel& serviceProxy, Action`1 call, Int32 retryCount)
   at Microsoft.Exchange.Search.OperatorSchema.PagingImsFlowExecutor.ExecuteAndReadPage(QueryParameters parameters, String outputName)
   at Microsoft.Exchange.Search.OperatorSchema.PagingImsFlowExecutor.GetHitCount(QueryParameters parameters)
   at Microsoft.Exchange.Search.Fast.ExchangeQueryExecutor.<>c__DisplayClass20.b__1f()
   at Microsoft.Exchange.Search.Fast.ExchangeQueryExecutor.RunUnderExceptionHandler[T](Func`1 call, IDiagnosticsSession session, String flowName)

 

This issue occurs when the "Microsoft Exchange Search Host Controller" service is in a stopped state.  My customer installed the latest Cumulative Update for Exchange 2013 and after the installation finished, the Search Host Controller was not set back to an Automatic.

Issues with Local Mailbox Moves on Exchange 2010 SP3

A customer running an Exchange 2010 SP3 UR15 multi-role server had issues moving mailboxes between databases.

 The error experienced was as follows:

Get-Mailbox "mailboxname" | New-MoveRequest -TargetDatabase "Mailbox Database Canada" -BadItemLimit 10

There are no available servers running the Microsoft Exchange Mailbox Replication service.
    + CategoryInfo          : NotSpecified: (0:Int32) [New-MoveRequest], NoMRSAvailableTransientException
    + FullyQualifiedErrorId : C7FE28BB,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest

Running Test-MRSHealth cmdlet to test the Mailbox Replication Service (responsible for processing mailbox moves) returns the following error on the environment.

RunspaceId : 4c95273c-3876-4369-86e3-1d9c90bc999e
Check      : ServiceCheck
Passed     : True
Message    : The Mailbox Replication Service is running.
Identity   : EXCHANGESERVER
IsValid    : True
 
RunspaceId : 4c95273c-3876-4369-86e3-1d9c90bc999e
Check      : RPCPingCheck
Passed     : False
Message    : The RPC endpoint for the Microsoft Exchange Mailbox Replication service couldn't respond: The call to 'net.tcp://exchangeserver/Microsoft.Exchange
             .MailboxReplicationService' failed. Error details: Access is denied.. --> Access is denied..
Identity   : EXCHANGESERVER
IsValid    : True

RunspaceId : 4c95273c-3876-4369-86e3-1d9c90bc999e
Check      : QueueScanCheck
Passed     : True
Message    : The Microsoft Exchange Mailbox Replication service is scanning mailbox database queues for jobs. Last scan age: 00:03:35.0822558.
Identity   : EXCHANGESERVER
IsValid    : True

Despite the error indicating Access is denied, all permissions were set correctly on the Mailbox Import Export role which was validated with:

Get-ManagementRoleAssignment -Role "Mailbox Import Export"

After further investigation, the following error was present:

 Log Name:      Application
Source:        MSExchangeIS Mailbox Store
Date:          13/10/2016 12:50:33 PM
Event ID:      7043
Task Category: IS/AD Interactions
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      Exchange.domain.local
Description:
The mailbox GUID of an external system mailbox ('Mailbox - SystemMailbox{1c3fa654-fe01-4041-a3a6-0444ca10f96c}') does not match the information in the Active Directory for the mailbox. The existing GUID ('8c0c971d-c5d7-495b-aff7-53356904789a: /o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=SystemMailbox{1c3fa654-fe01-4041-a3a6-0444ca10f96c}') has been replaced with the expected GUID ('ed55827e-7cdd-466e-9421-a0dbce5f6486: /o=Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=SystemMailbox{1c3fa654-fe01-4041-a3a6-0444ca10f96c}').

 

 The GUID of the SystemMailbox no longer matched the GUID of the Active Directory mailbox at the customer site.

To restore this, we ran "Setup /PrepareAD" from the Exchange 2010 SP3 setup media.  This restored the Exchange SystemMailbox association with Active Directory.

After running Setup /PrepareAD on the environment, we were able to move mailboxs again.