The attempt to connect to http://yourserver/PowerShell using “Kerberos” authentication failed: Connecting to remote server failed with the following error message : WinRM cannot process the request.

The following error occurred while attempting to connect to the specified Exchange server ‘yourserver.domain.com’:The attempt to connect to http://yourserver.domain.com/PowerShell using “Kerberos” authentication failed: Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found.  Possible causes are:  -The user name or password specified are invalid.  -Kerberos is used when no authentication method and no user name are specified.  -Kerberos accepts domain user names, but not local user names.  -The Service Principal Name (SPN) for the remote computer name and port does not exist.  -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following:  -Check the Event Viewer for events related to authentication.  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated.   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

The solution is to first export and then delete

HKCUSoftwareMicrosoftExchangeServerv14AdminToolsNodeStructureSettings (REG_BINARY key) registry key.

How to Setup Auto Reply Message or OOO In Microsoft Exchange Server 2010 Using Powershell

User below command to setup OOO or Auto Reply Using Powershell in Microsoft Exchange server 2010

Set-MailboxAutoReplyConfiguration Domain]Alias -AutoReplyState enabled -ExternalAudience all -InternalMessage “OOO Message” -ExternalMessage “OOO Message”

What is Datacenter Activation Coordination Mode DAC in DAG in MS Exchange 2010, 2013

Datacenter Activation Coordination (DAC) mode is a property setting for a database availability group (DAG). DAC mode is disabled by default and should be enabled for all DAGs with two or more members that use continuous replication. DAC mode shouldn’t be enabled for DAGs in third-party replication mode unless specified by the third-party vendor.

If a catastrophic failure occurs that affects the DAG (for example, a complete failure of one of the datacenters), DAC mode is used to control the startup database mount behavior of a DAG. When DAC mode isn’t enabled, and a failure occurs that affects multiple servers in the DAG, when a majority of the DAG members are restored after the failure, the DAG will restart and attempt to mount databases. In a multi-datacenter configuration, this behavior could cause split brain syndrome, a condition that occurs when all networks fail, and DAG members can’t receive heartbeat signals from each other. Split brain syndrome can also occur when network connectivity is severed between the datacenters. Split brain syndrome is prevented by always requiring a majority of the DAG members (and in the case of DAGs with an even number of members, the DAG’s witness server) to be available and interacting for the DAG to be operational. When a majority of the members are communicating, the DAG is said to have quorum.

For example, consider a scenario where the first datacenter contains two DAG members and the witness server, and the second datacenter contains two other DAG members. If the first datacenter loses power and you activate the DAG in the second datacenter (for example, by activating the alternate witness server in the second datacenter), if the first datacenter is restored without network connectivity to the second datacenter, the active databases within the DAG may enter a split brain condition.

How DAC mode works

DAC mode is designed to prevent split brain from occurring by including a protocol called Datacenter Activation Coordination Protocol (DACP). After a catastrophic failure, when the DAG recovers, it won’t automatically mount databases even though the DAG has a quorum. Instead DACP is used to determine the current state of the DAG and whether Active Manager should attempt to mount the databases.

You might think of DAC mode as an application level of quorum for mounting databases. To understand the purpose of DACP and how it works, it’s important to understand the primary scenario it’s intended to deal with. Consider the two-datacenter scenario. Suppose there is a complete power failure in the primary datacenter. In this event, all of the servers and the WAN are down, so the organization makes the decision to activate the standby datacenter. In almost all such recovery scenarios, when power is restored to the primary datacenter, WAN connectivity is typically not immediately restored. This means that the DAG members in the primary datacenter will power up, but they won’t be able to communicate with the DAG members in the activated standby datacenter. The primary datacenter should always contain the majority of the DAG quorum voters, which means that when power is restored, even in the absence of WAN connectivity to the DAG members in the standby datacenter, the DAG members in the primary datacenter have a majority and therefore have quorum. This is a problem because with quorum, these servers may be able to mount their databases, which in turn would cause divergence from the actual active databases that are now mounted in the activated standby datacenter.

DACP was created to address this issue. Active Manager stores a bit in memory (either a 0 or a 1) that tells the DAG whether it’s allowed to mount local databases that are assigned as active on the server. When a DAG is running in DAC mode (which would be any DAG with three or more members), each time Active Manager starts up the bit is set to 0, meaning it isn’t allowed to mount databases. Because it’s in DAC mode, the server must try to communicate with all other members of the DAG that it knows to get another DAG member to give it an answer as to whether it can mount local databases that are assigned as active to it. The answer comes in the form of the bit setting for other Active Managers in the DAG. If another server responds that its bit is set to 1, it means servers are allowed to mount databases, so the server starting up sets its bit to 1 and mounts its databases.

But when you recover from a primary datacenter power outage where the servers are recovered but WAN connectivity has not been restored, all of the DAG members in the primary datacenter will have a DACP bit value of 0; and therefore none of the servers starting back up in the recovered primary datacenter will mount databases, because none of them can communicate with a DAG member that has a DACP bit value of 1.

Error: Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0)

CAUSE

Previewing an object experiencing the error message, we found that we were importing the msExchVersion Attribute.  This is a Direct flow, indicating that we are pulling the information directly from the Microsoft Exchange 2010 User Object.  Confirmed in the management agent that was exporting to Microsoft Exchange 2007, that we were exporting the msExchVersion value in Direct Flow.

Configure Attribute Flow – Management Agent exporting to Exchange 2007

Generating Preview of the User Object to seethe value

RESOLUTION

We were able to resolve this issue by removing the msExchVersion attribute from the Export Attribute Flow on the management agent exporting to Microsoft Exchange 2007.

If this attribute is important to you, you may consider using a management agent extension to control the version number that goes into the msExchVersion attribute.

How to Delete Mail Contact in MS Exchange 2010 Using Powershell

Remove-MailContact -Identity “Mail Contact Display Name”

If you Do not want to get the confirmation for deletion type below command:

Remove-MailContact -Identity “Mail Contact Display Name” -Confirm:$False

Service ‘MSExchangeTransport’ failed to reach status ‘Running’ on this server during installation of exchange server

This Error commom when you are installing multiple Roles on a single server at the same time.

Please try below sequence and install one role at a time.

1. Client Access Server

2. Hub Transport Server

3. Mailbox Server

This issue would not occur ever again.

Error 3221684229 when installing mailbox role of Exchange 2007 SP1 on Windows Server 2008 r2

Problem:-

Mailbox Role  Failed

Error:  An error occurred. The error code was 3221684229. The message was Access is denied..

Resolution:-

Run setup.exe in compatibilty mode. I chose Windows 2008 SP1 and then the installation went through normally.