Hope you all would have planned to upgrade your Exchange 2007 to Exchange 2007 SP3. In this post I would like to inform you one of the issues reported.
In Exchange 2007 SP3, there is a mismatch between OWA (Outlook Web Access) S/MIME control. An active X component provides the S/MIME support in OWA. So, after you upgrade the exchange 2007 with SP3, the user will be prompted to install the upgraded version of the control into their client computers. The mechanism works in this way, the code checks the ‘Version’ of the client S/MIME control (MIMECTL.DLL) in end user’s computer with the ProductVersion of MSI file (OWASMIME.MSI) on the CAS server. During the SP3 release, the version of the MSI has incremented to 184.108.40.206. However, the DLL in MSI retained to the old one (220.127.116.11). So even though the client has updated the S/MIME version it will still prompt them to install the latest version (in IE browser).
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
Start-DatabaseAvailabilityGroup failed to start server(s) 'EX2010-DR' in databa
se availability group 'DAG-01'.
+ CategoryInfo : InvalidArgument: (:) [Start-DatabaseAvailability
+ FullyQualifiedErrorId : 8D6C2942,Microsoft.Exchange.Management.SystemCon
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.
Re-run the command again once you ensure that the start-up type disabled and service is not running, the execution should finish successfully.
Share your comments.
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*
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.
Now execute the Get-ReceiveConnector "EXH2\ connector_name" | fl remote* cmdlet to get the complete the list of IP addresses allowed for realy.
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,
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
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.
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)
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,
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.
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
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
Other symptoms are,
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,
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*
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.
You will be able to execute the Start-Databaseavailabilitygroup cmdlet successfully after these checks, see below,
Share your comments, and errors if any.
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,
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,
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.
Hope this helps.
Update: (19 - Feb - 2013)
Fixes an Exchange calendar bug that could result in increased network activity
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.
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.
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:
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
Please see this post from Apple for more details - iOS 6.0.1 Software Update
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,
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,
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
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.
Share your feedback.