Praveen

Praveen

Start-DatabaseAvailabilitygroup is one of the cmdlets used when we do a datacenter switchover of Exchange DAG, especially during a disaster recovery situation. We might end up unsuccessful in executing the Start-DatabaseAvailabilitygroup and will fail with below error.

WARNING: Server 'EX2010-DR' failed to be started as a member of database
availability group 'DAG-01'. Error: A server-side database availability group
administrative operation failed. Error: The operation failed. CreateCluster
errors may result from incorrectly configured static addresses. Error: An error
 occurred while attempting a cluster operation. Error: Node ex2010-dr is
already joined to a cluster. [Server: EX2010-02.fabrikam.com]
WARNING: The operation wasn't successful because an error was encountered. You
may find more details in log file
"C:\ExchangeSetupLogs\DagTasks\dagtask_2013-11-26_06-39-40.462_start-databaseav
ailabilitygroup.log".
Start-DatabaseAvailabilityGroup failed to start server(s) 'EX2010-DR' in databa
se availability group 'DAG-01'.
    + CategoryInfo          : InvalidArgument: (:) [Start-DatabaseAvailability
   Group], FailedToStartNodeException
    + FullyQualifiedErrorId : 8D6C2942,Microsoft.Exchange.Management.SystemCon
   figurationTasks.StartDatabaseAvailabilityGroup

One of the reasons why this error is generated could be because of the previous un-successful execution of the command. During the previous attempt the Start-DatabaseAvailabilitygroup will change the start-up type of the Cluster Service to automatic and will fail to complete the process due to various other issues. So when executing the command again, it will assume that the node is already part of the cluster and will fail with the above error.

So Open the Services window and ensure that the cluster service is in Stopped and Disabled Status.

Cluster_Service_Status

Re-run the command again once you ensure that the start-up type disabled and service is not running, the execution should finish successfully.

Start-DatabaseAvailabilitygroup Success

Share your comments.

-Praveen

As you aware, the receive connectors are created on server identity, and we might end up in creating similar receive connector in multiple servers for redundancy/disaster recovery purposes. You can easily export and import the RemoteIPRages from one connector to other by just following the following simple steps,

First of all, create the receive connector on the server where you want to import the RemoteIPRanges (relay IPs). Ensure you do the necessary settings for the receive connector properties, as we only import the remoteIPRanges not all configurations’.

new-ReceiveConnector -Name 'connector_name' -Usage 'Custom' -Bindings '0.0.0.0:25' -RemoteIPRanges 'x.x.x.x' -Server 'new_server_name'

Now, we have to export the RemoteIPRanges values from the other server that we need to import to this newly created receive connector.

Get-ReceiveConnector "EXH2\ connector_name" | fl remote*

RemoteIPRange_Truncated-M

If the result is truncated as seen in the above figure, you can set the value $FormatEnumerationLimit to display the complete list. The default value for this variable is 16. Set the value to a higher limit, or as shown below to get the complete list.

$FormatEnumerationLimit =-1

FormatEnumerationLimit

Now execute the Get-ReceiveConnector "EXH2\ connector_name" | fl remote* cmdlet to get the complete the list of IP addresses allowed for realy.

Get_RemoteIPRange_Full

Copy the details into a notepad and format it by removing any additional space between the coma and the next IP address. This will look like below,

10.10.10.1,10.10.10.3,10.10.10.101-10.10.10.125

The input value also can contain the ranges as you may noticed, not only single IP addresses. Now you all set to import the data to the newly created Receive Connector, execute the below command (in the snapshot, I used separated IP ranges).

Set-ReceiveConnector -Identity "EXHDR1\ connector_name" –RemoteIPRanges 10.10.10.1,10.10.10.3,10.10.10.101-10.10.10.125

Set_RemoteIPRange_Full

That’s it, you have now imported the complete list of relay IPs to the newly created receive connector. This way is really useful when you have more number of IPs individually allowed to relay emails through a receive connector.

-Praveen

 

Many of us have started upgrading the work station to Windows 8, and the Exchange 2010 Management Tools installation prior to Exchange Server 2010 SP3 cannot be installed on a Windows 8 64 bit machine. Here I have shared the work around for installing the Exchange 2010 SP2 Management tool on a Windows 8 64 bit machine (I used Windows 8 pro).

Step1: Ensure that you have installed all the pre-requisites for management tools,

Step 2: Modify the value of registry key CurrentVersion from 6.2 to 6.1.

Location of the Key:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

Step3: Prepare for the Exchange 2010 Server Management Tool Installation (readiness will show you green signal)

 Exchange2010_Mgmt_Tool_on_Win_8

Step 4: Click on Installation and wait for the successful completion.

Step 5: You will be able to open the Exchange Management Console without any errors, however it might not expand from the root navigation (‘Microsoft Exchange On-Premises”)

Create a batch file with the following entries,

set __COMPAT_LAYER=RUNASINVOKER
set COMPLUS_Version=v2.0.50727
START "C:\Windows\System32\mmc.exe" "C:\Program Files\Microsoft\Exchange Server\V14\Bin\Exchange Management Console.msc"
Exit

Save it anywhere (preferably in desktop) as “ExchangeMMC.bat’.

Open the newly created batch file, done! You are now able to open the Exchange Management Console from a Windows 8 machine.

Step 6: Revert the changes done on registry entry “CurrentVersion” back to previous value (i.e. from 6.1 to 6.2).

Key Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

 That’s it, you have finished installing and configuring for Exchange 2010 Management Console on Windows 8 Pro machine.

Courtesy: Multiple blogs and forums.

-Praveen

 

 

 

Recently I was testing the Datacenter failover of Database Availability Group (DR), and observed few things/errors when adding back the DAG members after the successful failover. During the failback, I could add one of the 2 servers in primary datacenter but failed to add another server. The Start-Databaseavailabilitygroup failed to complete with error as pasted below,

WARNING: Server 'EX-01' failed to be started as a member of database availability group 'DAG-01'. Error: A

server-side database availability group administrative operation failed. Error: The operation failed. CreateCluster

errors may result from incorrectly configured static addresses. Error: An error occurred while attempting a cluster

operation. Error: Node ex2010-01 is already joined to a cluster. [Server: Ex-DR.fabrikam.com]

WARNING: The operation wasn't successful because an error was encountered. You may find more details in log file

"C:\ExchangeSetupLogs\DagTasks\dagtask_2013-07-30_06-10-35.992_start-databaseavailabilitygroup.log".

Start-DatabaseAvailabilityGroup failed to start server(s) 'EX-01' in database availability group 'DAG-01'.

   + CategoryInfo         : InvalidArgument: (:) [Start-DatabaseAvailabilityGroup], FailedToStartNodeException

   + FullyQualifiedErrorId : 811A6BB8,Microsoft.Exchange.Management.SystemConfigurationTasks.StartDatabaseAvailabilit

   yGroup

Other symptoms are,

  1. The cluster service fails frequently on the ex-01 server
  2. Cmdlet Start-Databaseavailabilitygroup keeps failing
  3. No changes to the network settings since the stop- Databaseavailabilitygroup
  4. Verified the Get-clusternode cmdlet to verify the cluster ex-01 status, and did not find any state entry (up, joining etc.

 It means, the ex-01 is cleanly evicted from the cluster and does not have any stale entry in the cluster configuration.

How to Fix:

When I verified the DAG nodes Exchange version, I observed that the node which is failing to add is in a higher rollup version though at the same service pack level. I have raised the other nodes (ex-dr and ex-02) into the similar rollup level as ex-01 (server fail to add) and could able to execute the Start-Databaseavailabilitygroup cmdlet without any issues. That means, when you try to add a dag node using Start-Databaseavailabilitygroup, the PAM (Primary Active Manager) should be at the same or above rollup level.

So, please ensure the below if you are facing the similar error,

  1. Ensure all the DAG nodes are running at the same Service Pack and Rollup levels
  2. Ensure the OS patch level does not have much of a difference
  3. Ensure the NIC settings are matching with other nodes
  4. Ensure the DAG node you are trying to add is listing out in the Stopped mailbox servers list,
  5. Ensure that the cluster node is not in the status on “Joining” on cluster configuration (Use Get-ClusterNode cmdlet).

First 3 steps are easy to follow, step 4 and 5 are explained below.

How to verify the current started and stopped mailbox server in a DAG,

Execute the below cmdlet,

Get-DatabaseAvailabilityGroup -Status | fl st*,pr*,op*

DAG_Status_-_Started_Servers

Once you confirm that the server which are trying add back to DAG is listing in StoppedMailboxServers list, you can safely execute. If the server you are trying to add is already in the startedMailboxServers list then you might have to stop the server before you can add it back. The configuration might have updated due to multiple execution of Start-Databaseavailabilitygroup cmdlet in the past.

Do not forget to execute Set-DatabaseAvailabilityGroup cmdlet to properly set the cluster properties in case you run the Stop DAG command.

How to verify the node status in cluster configuration,

Execute Get-ClusterNode to list all the available nodes in the DAG. If the cluster node you are trying to add is listing out there other than status “up”, you might have to remove it forcefully before executing the Start-Databaseavailabilitygroup cmdlet.

Final Step:

You will be able to execute the Start-Databaseavailabilitygroup cmdlet successfully after these checks, see below,

DAG_Status_-_Start_and_Status_After

Share your comments, and errors if any.

-Praveen

 

 

 

As per the updates from various sources, the iOS 6.1 version creates issues with Exchange Server, as it overloads the Exchange Server 2010. According to the latest updates, apple and Microsoft are currently working towards an update to workaround this issue.

This issue looks to have some relation with earlier reported meeting hijacking, as it has turned out to be happening when Apple users process their calendar updates using their iPAD or iPhone.

Need to know more, read the following blogs,

Rapid growth in transaction logs, CPU use, and memory consumption in Exchange Server 2010 when a user syncs a mailbox by using an iOS 6.1-based device

Apple iOS 6.1 upgrades result in excessive transaction log growth

Request the users not to update the new version until Apple and MS are coming up with a fix.

Update: (14- Feb-2013)

Apple has acknowledge the bug, iOS 6.1: Excess Exchange activity after accepting an exception to recurring calendar event

When you respond to an exception to a recurring calendar event with a Microsoft Exchange account on a device running iOS 6.1, the device may begin to generate excessive communication with Microsoft Exchange Server, they also have suggested a workaround,

Resolution
Apple has identified a fix and will make it available in an upcoming software update. In the meantime, you can avoid this bug by not responding to an exception to a recurring event on your iOS device. If you do experience the symptoms described above, disable then reenable the Exchange calendar on your iOS device using the steps below.

  1. Go to Settings > Mail, Contacts, Calendars
  2. Select the Exchange account from your Accounts list.
  3. Turn the switch for Calendars to OFF.
  4. Wait ten seconds.
  5. Turn the switch for Calendars back to ON.

Hope this helps.

Update: (19 - Feb - 2013)

iOS 6.1.2 Software Update

Fixes an Exchange calendar bug that could result in increased network activity

-Praveen

You may have observed an unexpected growth in the database size and transaction log after a cross forest migration. It happened to me when I was doing a cross forest migration project from Exchange 2007 Server to Exchange 2010 server, so I thought of sharing it so that it may help you to plan the migration in a better manner.

The database size and transaction logs growth was unacceptably high due to few users’ outlook client. I observed ~30GB logs generated because of 2 users, and the database is also grown about 25 GB in a time span of 8 hours without any reason.

Cause:

When I identified the users and clients (used Exchange User Monitor), it is observed that all the client versions are outlook 2010 original version (without any service pack), have mentioned it below.

Microsoft Outlook 2010 OUTLOOK.exe   14.0.4760.1000; I also observed that most of them were in Online mode with exchange.

Workaround:

To quickly work around this issue, all you need to create a new outlook profile for the user.

To plan the migration better, you must install the latest service pack for outlook (at least SP1) as I have not seen this issue with the SP1 version. I also have observed many migration issues with cache mode profile are also fixed with SP1.

How do you Identify the users:

Simply use the Exchange User Monitor. Download it here, and configure it by following Microsoft Exchange Server User Monitor

-Praveen

We have discussed about a bug in Apple iOS 6 with the Exchange Active Sync(EAS) in one of the previous posts, you may read it here

Good news is that, Apple has come up with a software upadate that addresses the issue with EAS along with other few fixes, please find the details about new apple iOS software update below,
        • Fixes a bug that prevents iPhone 5 from installing software updates wirelessly over the air
        • Fixes a bug where horizontal lines may be displayed across the keyboard
        • Fixes an issue that could cause camera flash to not go off
        • Improves reliability of iPhone 5 and iPod touch (5th generation) when connected to encrypted WPA2 Wi-Fi networks
        • Resolves an issue that prevents iPhone from using the cellular network in some instances
        • Consolidated the Use Cellular Data switch for iTunes Match
        • Fixes a Passcode Lock bug which sometimes allowed access to Passbook pass details from lock screen
        • Fixes a bug affecting Exchange meeting
Inform the users to apply this software update (if they already installed the iOS 6) to overcome the issue mentioned above.

Please see this post from Apple for more details - iOS 6.0.1 Software Update

-Praveen

We have been hearing (at least for last couple of weeks) that the Apple IOS 6 which is released along with Apple iPhone 5 is creating some issues with Microsoft Exchange Server when using Active Sync feature. The actual issue is “the meeting request’s owner is changed (or meeting hijacked)", and according to MS almost every call raised on this issue was some or the other way related when the meeting request is acted on IOS 6 devices. MS has already contacted Apple and has officially written on their Exchange Blog.

As you know, the IOS 6 is now available to update of other compatible Apple devices, so it is recommended not to update the new version (if you are an Active Sync user) until Apple announces the fix. Few ways to work around (precautions / mitigations) the situation as mentioned in the Exchange Team Blog are,

    • Tell users not to take action on calendars on iOSWe're not seeing this particular issue if users don't take action on their calendar items (for example, accept, delete or change meetings).
    • Switch iOS users to POP3/IMAP4 Another option is to switch users over to POP/IMAP connections. This will remove calendar and contacts functionality while allowing users to still use email (though the email may shift to pull from push while using these protocols).
    • 3rd party clients/OWA Moving impacted users over to another email client that is not causing these issue for your organization may help alleviate the pain here. There are a number of other client options (OWA being one of them of course). Numerous clients are available in mobile application stores. We don’t recommend any particular client.
    • Block delegates Many of the issues we are seeing involve delegates. An admin can take the less drastic step of using the Allow/Block/Quarantine list to block only users who are delegates, or have a delegate, to minimize the impact here.
    • Block iOS 6 devices Exchange server comes with the Allow/Block/Quarantine functionality that enables admins to block any device or user.
    • Tell users not to upgrade to iOS 6 or to downgrade their devices – This solution may work as a temporary fix until Apple provides a fix but many users may have already made the decision to update.

MS Exchange Team do not have any information on the timeline of a fix from Apple but if this timeline is short, this may be the easiest course of action. Please contact Apple about any potential fix or timeline for its delivery.

Look the below article from Exchange Team for more info,

iOS6 devices erroneously take ownership of meetings

Meeting in Attendee’s Calendar Loses Track of the Meeting Organizer

Update - Apple informs that this issue is addressed in the iOS 6.0.1 Software Update. See the post iOS 6.0.1 Software Update fixes Exchange Meeting Hijacking Issue for more details


-Praveen

You may see the databases dismounted after you restarted the member server of a DAG (mostly when you only have 2 copies of databases). And if you try to mount the database, it will through the below error.

--------------------------------------------------------
Microsoft Exchange Error
--------------------------------------------------------
Failed to mount database 'Mailbox Database 0834974974'.
Mailbox Database 0834974974
Failed
Error:
Database 'Mailbox Database 0834974974' can't be mounted on server 'EXH1.exchangedictionary.local' due to a previous error: Failed to determine the mount status of the active database copy. Verify that the underlying cause of the error has been corrected before attempting to mount the database. The error can be ignored and the mount allowed if Mount-Database is reissued with the -Force switch.

Resolution:

As mentioned in the error, it is better try to fix the underlying cause, before you forcefully mount the database.
      • Ensure that the cluster service is up and running
      • Ensure that the DAG members are able to communicate each other, using the replication network (incase if you have replication and MAPI network).
      • Ensure the File Witness is reachable to the server
Mostly, any failure on above checks can lead to this issue, fix the cause and try to mount the database.

Share your feedback.

-Praveen

You may recieve the below error when try to access the OWA (Outlook Web App) published through Microsoft TMG 2010. The Outlook Web App (OWA) login page will appear without an issue, but after providing the username and password you will recieve website can not be found error.

------
The website cannot be found

Technical Information (for support personal)

Error Code 11001: host not found

Background: This error indicates that the gateway or proxy server could not find the IP address of an upstream server.
---

TMG_Error_-_Accessing_OWA

How to Fix:

As the error indicates, this issues happens because the TMG server unable to reach the exchange server. It mostly related to the DNS resolution issue as you might have given the Exchange Server name in "this rule applies to this published site" section in "To" tab of the publishing policy.

To verify the error is due to it, try testing the publishing rule

  1. Logon to TMG Server and open the properties of the OWA publishing rule, and then click on Test Rule button on the botton left corner.
  2. If the test is failed for all, then try to ping the internal Exchange CAS server and see if the TMG can reach it. If the ping result did not resolve to the correct IP verify your DNS configuration and ensure that it is pointing to the correct internal DNS servers.
  3. Try to resolve the internal CAS server from TMG after correcting any DNS resolution issue, and test the rule. It should work fine now.

You may also create a host file entry to resolve the issue quickly, before you fix any major DNS issues resolution between TMG and internal DNS servers(due to any firewall/network configs).

Ensure that all the required ports are allowed and no network configurations are changes between TMG and Internal Exchange CAS as normally the TMG sits in the DMZ network.

-Praveen

Page 4 of 15
theme by reviewshub