Exchange 2010
With de following PowerShell command you create automatically archive mailbox for a user in a specified mailbox database
Get-Mailbox -Database MB1 | Enable-Mailbox -Archive -ArchiveDatabase MB3
This is very when you want to create a lot of archive mailboxes in one time
In Exchange Server 2010 the Exchange Management Console doesn’t provide a way to visually locate mailboxes that have no storage quota, or mailboxes that have a non-standard storage quota configured. However you can find mailbox storage quota settings quickly using the Exchange Management Shell.
To list all Exchange Server 2010 mailboxes that are exempt from the mailbox database storage quota settings use this command in the Exchange Management Shell.
get-mailbox | where {$_.UseDatabaseQuotaDefaults -eq $False}
To Set al mailbox to Mailbox Database Default:
get-mailbox | where {$_.UseDatabaseQuotaDefaults -eq $False} | set-mailbox -UseDatabaseQuotaDefaults $true
Today Microsoft released a fix (KB2677598) for a small cosmetic imperfection which shows up when using Outlook Web Access in Dutch, after installing Service Pack 2 on Exchange 2010.
Instead of showing up “Mail”, OWA displayed “Globale Adreslijst” (Global Addresslist) which might be confusing to end users.
To need to download the Microsoft Exchange Server 2010 SP2 Language Pack Bundle which released on 20 Feb 2012 and install on your Exchange 2010 SP2 Client Access Servers.
You can download the Microsoft Exchange Server 2010 SP2 Language Pack Bundle (219 MB) here.
Special thanks for Jetze for notice the update
The Exchange Team did a change in CAS to CAS proxy behavior between servers running Exchange 2010 SP2 RU1 and servers running older versions of Exchange.
The SP2 RU1 package introduced a change to the user context cookie which is used in CAS-to-CAS proxying. An unfortunate side-effect is a temporary incompatibility between SP2 RU1 servers and servers running earlier versions of Exchange. The change is such that earlier versions of Exchange do not understand the newer cookie used by the SP2 RU1 server. As a result, proxying from SP2 RU1 to an earlier version of Exchange will fail with the following error:
Invalid user context cookie found in proxy response
The server might show exceptions in the event log, such as the following:
Event ID: 4999
Log Name: Application
Source: MSExchange Common
Task Category: General
Level: Error
Description: Watson report about to be sent for process id: 744, with parameters: E12, c-RTL-AMD64, 14.02.0283.003, OWA, M.E.Clients.Owa, M.E.C.O.C.ProxyUtilities.UpdateProxyUserContextIdFromResponse, M.E.C.O.Core.OwaAsyncOperationException, 413, 14.02.0283.003.
Not all customers are affected by this. But since we received a few questions about this, we wanted to let you know about the change. Many Exchange customers do not use proxying between Exchange 2010 and Exchange 2007 but rather use redirection, which is not affected by the change. However, if you are using CAS-to-CAS proxying, where an Exchange 2010 SP2 RU1 Client Access server is proxying to an earlier version of Exchange 2010 or Exchange 2007 Client Access server, then you are affected by the change.
If you are affected, it is important to note that this issue is temporary and will exist only until all of the CAS involved in the CAS-to-CAS proxy process are updated to Exchange 2010 SP2 RU1. Thus, if you are affected by this problem, simply deploy SP2 RU1 on the relevant Exchange 2010 servers and the issue no longer exists.
If you use CAS-to-CAS proxy between Exchange 2010 and Exchange 2007, we will have an interim update (IU) for Exchange 2007. Availability of the IU will be announced on this blog.
Server proxy version
Server being proxied to
Action to take
Exchange 2010 SP2 RU1 –> Any version of Exchange 2010 older than SP2 RU1
Apply Exchange 2010 SP2 RU1 to all servers involved in proxy process
Exchange 2010 SP2 –-> RU1 Exchange 2007
Hold off deployment of Exchange 2010 SP2 RU1 until you deploy the Exchange 2007 interim update (IU)
SOURCE: Exchange 2010 sp2 ru1 and cas to cas proxy incompatibility
The Exchange Team released Update Rollup 1 for Exchange Server 2010 SP2.
It’s a long list with issues that are fixed in this rollup:
Download the rollup at HERE
When you use a Kemp LoadMaster for Loadbalacing Exchange 2010 you need to set static RPC ports.
By default Windows Server 2008 and 2008 R2 are configured with a dynamic RPC range of 49152-65535 for outbound connections. When the Exchange 2010 Client Access server role is installed on Windows Server 2008 or 2008 R2, the dynamic RPC port range is changed to 6005-59530 and the highest usable port number is set to 60554.
By default the RPC Client Access service on an Exchange 2010 Client Access server uses the TCP End Point Mapper port (TCP/135) and the dynamic RPC port range (6005-59530) for outgoing connections, every time an Outlook clients establish a connection to Exchange.
To set a static port for the RPC Client Access service on an Exchange 2010 Client Access server, you need to open the registry on the respective server and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC
Here, you need to create a new key named ParametersSystem, and under this key create a REG_DWORD named TCP/IP Port. The Value for the DWORD should be the port number you want to use. 
Configuring static ports for the RPC Client Access service
RPC.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC\ParametersSystem]
"TCP/IP Port"=dword:0000e88c
Note
Microsoft recommends you set this to a unique value between 59531 and 60554 and use the same value on all CAS in any one AD site.
When you’ve configured the port, it’s required to restart the Microsoft Exchange RPC Client Access service in order for the changes to be applied.
To set a static RPC port for the Exchange Address Book Service, create a new REG_SZ registry key named “RpcTcpPort” under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters
RPCAB.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters]
"RpcTcpPort"="59533"
Microsoft recommends you set this to a unique value between 59531 and 60554 and use the same value on all Exchange 2010 Client Access servers in any one AD site.
When you’ve configured the port, it’s required to restart the Microsoft Exchange Address Book service in order for the changes to be applied.
By default public folder connections uses the TCP End Point Mapper (TCP/135) and the dynamic RPC port range (49152-65535) for outgoing connections, every time an Outlook client establish a connection to Exchange.
To set a static port for public folder connections, follow the same steps as those required for configuring static ports for the RPC CA service. Just bear in mind you need to perform them on the Exchange 2010 servers that stores public folder databases. This is because public folder connections from an Outlook client occur against the RPC Client Access service on the Mailbox server role.
In order to verify that the static ports configured are used, the netstat.exe tool can be used:
Netstat -an -p tcp
Verifying the configured static ports are used on the Client Access and Mailbox servers
In my next blog post I will show how to config a Kemp Loadmaster.
Reference:
Link: Configure Static RPC Ports on an Exchange 2010 Client Access Server
When you need to performing maintenance on DAG nodes here is the process you want to go through In my environment I have two nodes in a dag. For more nodes the same process
All the commands below are run in an administrative exchange powershell prompt.
Type add first: cd $exscripts and press enter.
Now you are in the Exchange Scripts folder.
Exchange Node 1:
Process for running maintenance on exchange database servers
.\StartDagServerMaintenance.ps1 -ServerName <Dag Node 1>
Run maintenance on <Dag Node 1>
When you are finished on Node 1
.\StopDagServerMaintenance.ps1 -ServerName <Dag Node 1>
Exchange Node 2:
.\StartDagServerMaintenance.ps1 -ServerName <Dag Node 2>
run maintenance on <Dag Node 2>
When you are finished on Node 2
.\StopDagServerMaintenance.ps1 -ServerName <Dag Node 2>
When done performing maintenance on one or multiple servers (hopefully one at a time to maintain full database availability for end users!) you can end up with a sub-optimal active database layout, especially if you have a cross-site DAG. To resolve this you have to rebalance the databases based on the priorities set for them upon creation.
Rebalance databases across dag
.\RedistributeActiveDatabases.ps1 -DagName <Your DAG Name> -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution -Confirm:$false
If you get any errors you may have to re-index the search catalog for the passive database. Rather than hunting down which ones need to be fixed you can just fix them all with the custom script I wrote below (or for only the mail servers with issues). When finished running these commands then try to run the maintenance or rebalance scripts again.
Fix/Rebuild Search Catalogs
Get-MailboxDatabaseCopyStatus -Server <Dag Node 1> | where {$_.Status -like "Healthy"} | Update-MailboxDatabaseCopy –catalogonly
Get-MailboxDatabaseCopyStatus -Server <Dag Node 2> | where {$_.Status -like "Healthy"} | Update-MailboxDatabaseCopy -catalogonly
Add PF replica’s to an Exchange 2010 Server:
.\AddReplicaToPFRecursive.ps1 -server "Exchange 2003/2007 Server" -TopPublicFolder "\" -ServerToAdd "Exchange 2010 Server"
Replicate the System Folders to an Exchange 2010 Server:
.\AddReplicaToPFRecursive.ps1 -TopPublicFolder "\NON_IPM_Subtree" -ServerToAdd "exchange2010 server”
If you are planning to have multiple Exchange 2010 PF servers, you can repeat the Cmdlet
From the Exchange 2010 server: Update-PublicFolderHierarchy -Server "Exchange 2010 Server"
As a last step, after you confirmed that all the PF have been replicated to the Exchange 2010, you can move all replicas from Exchange 2003/2007 to Exchange 2010. The "move all replicas" will actually remove the Exchange 2003/2007 replicas.
To move all Exchange 2003/2007 replicas to Exchange 2010, which will actually remove the Exchange 2003/2007 replicas:
.\MoveAllReplicas.ps1 -Server "Exchange 2003 Server" -NewServer "Exchange 2010 Server"
To view a list of the replicas in the public folder hierarchy: Get-PublicFolder -recurse |fl name,replicas
For System Folders: Get-PublicFolder -recurse \non_ipm_subtree |fl name, replicas
To compare content replicated between the source and destination servers: Get-PublicFolderStatistics
Move Public Folder Content from One Public Folder Database to Another Public Folder Database – http://technet.microsoft.com/en-us/library/bb331970.aspx
This guide was created to help you deploy the new Outlook Mobile update for the Windows Mobile 6.1 devices that connect to your Exchange 2010 servers. This guide focuses on Microsoft Exchange Server 2010 RTM & SP1 & SP2 and Windows Mobile 6.1, and covers the following topics:
· Overview
· How to configure your Exchange 2010 for the Outlook Mobile update
· Details about the Outlook Mobile update
· How to get support for Outlook Mobile updates
· How to subscribe for future updates
First, we’ll review the overall update experience that’s built into Exchange 2010.
As part of the Outlook Mobile update, users will receive an update notification in an e-mail message in their Inbox. The purpose of this message is to inform them that there’s an Outlook Mobile update for their phone.
The message will instruct the user to click an inline link. This prompts the phone to download the Initial Setup CAB. After the Initial Setup CAB is installed, it will check for available updates specific to the user’s device type.
Next, if an Outlook Mobile update is available, it will be downloaded and installed. The user will receive a notification message that tells them they need to restart their device. After the device is restarted, it will resynchronize the data (e-mail, calendar, contacts, and tasks) with the Exchange server so it will be compatible with the new format of Exchange Server 2010. After that synchronization is complete, the user will be ready to experience the new features in the Outlook Mobile update.
Now that you understand the tasks that the Outlook Mobile update performs, we’ll cover how to configure your Exchange server so that your users who have Windows Mobile 6.1 devices will receive the update notification e-mail message.
The update notification e-mail message will be sent to the user’s device if the following conditions are true:
· The user’s mailbox is on a server running Exchange Server 2010.
· The Exchange ActiveSync mailbox policy parameter AllowMobileOTAUpdate is set to $True.
· The Windows Mobile OS version is 6.1. To check which version the device is running, from the Help About screen, look for the OS and Windows Mobile 6.1 build number (Start > Settings > System > About). You should see Windows OS = “Windows CE 5.2”, and the Windows mobile build should be between 19202 and 21142.
The AllowMobileOTAUpdate setting is one of the standard Exchange ActiveSync mailbox policy settings. This is the main setting that determines whether the update notification e-mail message is sent to the device.
The default value for the AllowMobileOTAUpdate parameter is enabled ($True). To confirm that your Exchange ActiveSync mailbox policy has this setting enabled, follow these steps:
1. Check which policy the user is assigned to by running the following command.
Get-CasMailbox <user> | fl ActiveSyncMailboxPolicy
In the preceding example, the result is the following.
ActiveSyncMailboxPolicy : Default
2. Check that the policy returned in the preceding step has the AllowMobileOTAUpdate setting enabled by running the following command.
Get-ActiveSyncMailboxPolicy Default | fl AllowMobileOTAUpdate
If the AllowMobileOTAUpdate setting is set to $True, the following will be returned.
AllowMobileOTAUpdate : True
The following section covers the end user experience for the Outlook Mobile update. The update notification e-mail message the user receives will look like this.
The user can click the first link in the message to start the download. This downloads the initial setup CAB, which is necessary to find the appropriate Outlook Mobile update for that user’s device.
Next, the user will see a URL Confirmation page that informs them that they’re being taken to a Web site. The user should click Yes to continue. Clicking No will cancel the update process.
After the file begins downloading, the user will be asked if they want to open the file, save it to a location, or click Cancel. The user should click Yes to continue opening the file, making sure that the open file after download box is selected.
The next screen they’ll see is the progress bar that shows that the initial setup CAB is being downloaded and installed.
The initial setup CAB finds the appropriate Outlook Mobile update for the user’s specific device. After the initial setup CAB is installed, it connects to the Outlook Mobile Update Service to find the update. If an update is found, the user will be asked if they want to download the Outlook Mobile update. The user should select Yes to download and install the update.
After the Outlook Mobile update has been installed, the user needs to restart their device to ensure that all new Outlook Mobile files loaded correctly.
After the user restarts their device, they’re presented with a warning message that informs them that they need to resynchronize their data with Exchange. This is necessary because the existing format of the synchronized data isn’t compatible with the new features built into Exchange Server 2010. The user should click Yes in this warning message box.
Occasionally, a user may see the following error, which can appear when the resynchronization hasn’t yet occurred. The user will need to manually resync their data with Exchange.
There may be updates available for your users’ Windows Mobile 6.1 phones in the future. The Outlook Mobile update package will ask users if they would like Outlook Mobile to automatically check for updates on a regular schedule. Users should click Yes to automatically check for updates and receive notification when new updates are available.
I recently came across the following issue while performing an Exchange 2007 to Exchange 2010 migration for a company that still heavily utilised mail-enabled public folders. The client’s Exchange environment was quite old and had been previously migrated from Exchange 5.5 to 2003 and hadn’t been properly decommissioned with the original move to 2007, but that’s another story!
The issue I had was that once I moved all receive connectors to the new Exchange 2010 server, emails sent to any of the mail-enabled public folders (which were still being replicated between the 2 servers) was being rejected with the following NDR:
#< #5.2.0 smtp;554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn’t found. ObjectNotFoundException: The Active Directory user wasn’t found.> #SMTP#
The following error was found in Event Viewer:
Log Name: Application
Source: MSExchange Store Driver
Date: 7/09/2010 2:00:02 AM
Event ID: 1020
Task Category: MSExchangeStoreDriver
Level: Error
Keywords: Classic
User: N/A
Computer: server@domain
Description:
The store driver couldn’t deliver the public folder replication message “Folder Content (PublicFolderDatabase@domain)” because the following error occurred: The Active Directory user wasn’t found.
Given this Exchange environment was originally running versions prior to Exchange 2007, the legacy Administrative Group and all its empty subcontainers still existed. An explanation from the Microsoft Exchange Team of why this issue occurs can be found here: http://msexchangeteam.com/archive/2010/05/05/454821.aspx
The solution to this issue was to delete the empty Servers container from the legacy Administrative Group.
Using ADSIEdit.msc, connect to a domain controller and navigate to:
CN=Configuration , CN=Services, CN=Microsoft Exchange, CN=[ExchangeOrganisationName], CN=Administrative Groups, CN=[LegacyAdministrativeGroupName], CN=Servers.
Right click the Servers container and select Delete
Click Yes
Restart the Microsoft Exchange Active Directory Topology Service and the Microsoft Exchange Information Store on both the Exchange 2007 & Exchange 2010 Servers