One of the most important stage of a Cross forest exchange migration is to have the Global Address List (GAL) availability to the end users in target forest including the required LegacyExchangeDN as x500 address. If we don’t add the legacyExchangeDN as x500 to the target forest, there are many chances of generating NDRs from user who sends email using outlook clients. This is due to the cached address list contact with the old information. The below piece of script will help in creating Global Address List (GAL) in the target forest with the LegacyExchangeDN as x500 address thus avoiding/reducing chances for such NDRs.
Note - This is applicable only when your migration approach is different from the normal MS recommended approach (i.e. preparemoverequest -> ADMT-> Mailbox Move).
My scenario was,
Sometime we will have to migrate the user account first and followed to which the mailboxes. Or, when you are planning to migrate the Linked mailboxes (resource forest) to User mailboxes (account forest). In both the cases, you will be having linked mailboxes as an interim and the account forest will not have a complete GAL.
Once you have the data delete the first line “#TYPE System.Management.Automation.PSCustomObject” of the output CSV and then copy it to the C:\ drive of new exchange org server. Copy the below script and save it on new Exchange server as _MailEnableScript.ps1 file (preferably under C:\Scripts).
In case of a cross forest migration you will have intermediate routing between both the exchange organizations until the completion of migration. So, the mail enabled user in new exchange forest will have the target address as primary SMTP of existing source organization for the interim email flow.
The additional smtp address will be used for the target address calculation after the mailbox move. Because the old exchange organization need a target address once the mailbox is moved and the source account is converted as mail enabled user(read New-MoveRequest for more details about the cross forest move).
Please read cross forest migration articles(http://blogs.technet.com/b/exchange/archive/2010/08/10/3410619.aspx) to understand the scenario better, and make use of the above simple script to populate the GAL required.
Let me know your comments..
Mostly we create Exchange Transport Rules Condition using the criteria’s like “when FROM address ...”, When recipient ...” “When user from inside/outside organization” etc. Recently I have come across to create a rule for filtering the emails from internet groups, and the from address will always shown as the primary email address of the sender which could be always well known internet domains like gmail.com, yahoo.com etc, not the news group domain name. Most of the company wanted the email traffic from those public domains, by restricting the email traffic which are send to common groups (news group, community groups and other non-business groups).
To work with such request in transport rule, you can use the condition “When the message header matches text patterns”. Before we create any rule, let’s look at the header of one such email and decide on the parameter which can be used for filtering such emails (common criteria for all such emails).
Look at the part of a header; I have selected the “Reply-To” field to create the condition for the transport rule. You can see that the from address will be always(mostly) the sender address, hence the filteration is not that easy using the common conditions, as that can cause stopping the entire email from the common public email domain.
I hope every one of us was waiting for the Service Pack 2 for Exchange 2010 to be released, may be just for the ABP (Address Book Policies). This is one good feature I think will be greatly utilized by most of us, because even without the GAL segmentation or ABP we were doing it with permissions/ACLs.
In simple, GAL Segmentation/ABP means we are grouping few of the address lists to give a segmented or Customized GAL to the exchange users. When we create an Address Book Policy, we assign a GAL, an Offline Address List (OAL), room (conference) list and one or more address lists. This policy will then be assigned to the mailbox users to give them a customized GAL in OWA/Outlook.
Here I tried to show how you can create and assign your own customized address lists and Address Book Policies to the mailbox users.
Before you begin, decide on the way we are planning to filter the mailboxes/DLs/room mailboxes. Microsoft suggest using one of the CustomAttributes as a filtering criteria, however you may proceed with your own filtration.
I have updated the value “ED_GAL” to customattribute11 of all mailbox/DLs which are to be filtered for the new GAL.
The mini version of Outlook Web App is designed for using in simple HTML compactible browsers. This version will help mainly the users who were accessing the OWA using their mobile browsers. This feature was available in Exchange 2003 server, and it is good to see this again. The MINI OWA (OMA) gets enabled automatically once you install the Service Pack 2 on the CAS servers.
Append /OMA to the existing Outlook Web App URL,
Once logged in the OMA (mini Outlook Web App) will look like below,
The SP2 upgrade is almost straight forward from Exchange 2010 SP1; however it requires the IIS 6 WMI Compatibility component for CAS role upgrade. Normally this would be installed when initially you have added Web Server (IIS) role, if this component is not installed already then add it prior installing SP2.
Follow the simple steps below(I did upgrade from my Exchaneg 2010 SP1 installation).
The upgrade will almost take the same time as the installation, hence wait until the process completes. The installation did not give any other issues, and went just fine.
I am sure that everyone will be very confused when doing the capacity planning for the new Excchange 2010 infrastructure. It is very important to plan the transaction log space requirement along with the backup policy designing. Recentlyhas written an article in Exchange Official bog about planning the space requirement for your exchange implementation. He has clearly explained the parameters that has to taken into consideration, click the below link to read the article.
I already have shared a script for migrating user mailbox into linked mailbox during the cross forest migration scenario in one of my previous posts, see here. Sometime(I faced all the time) during this process you would have observed that after the creation of linked mailboxes all manually configured limit, mailbox features are set back to the default. I have created two small of power shell command combination to import the features and the limits from a csv file.
Set the limit, follow this
Mandatorily, we need to extract the each mailbox limit details from exchange data before the linked mailbox conversion. This step is to get the existing values into a csv file, you may use the simple power shell command pated below to export the current data,
The output file will be like,
Remove the file line starts with “#Type System…..” and save it in the drive C:\ with the same name.
Note - In my scenario total user is less than 3000, if you have more than 3000 users the -ResultSize can be mentioned accordigly.
I know we are all talking about the new features of Exchange 2010 for a while now. Recently Microsoft has given a quick view about the exchange 2010 feature comparison with Exchange Server 2007 and Exchange Server 2003.
The comparison have been split into three major feature categories, which are Protection and Compliance, Anywhere Access and Flexible and Reliable.
Hope you all would be interested to have a look, see here.
Comparing the features will really help us to take a decision on "whether to go for it or not"!
In case of cross forest migration, most of us will plan the mailbox and account migration together to avoid complexity. However, there are situations where we plan to go one by one (all the user account migration first and then the mailbox migration). In my case, I chose to do the user account migration due to some dependency to the new forest and keep the User Mailboxes still in the source forest (existing forest). As you all know, we have to create linked mailboxes in this scenario and the process would be,
Note – The source forest has Exchange 2007 Servers Org.
Imagine you have many users to be migrated, definitely the activity going to eat up a lot of your time. Use the simple piece of script to finish your linked mailbox creation in few minutes ….
Imp Note - Ensure that the AD user accounts corresponding to the user mailbox (source AD accounts) are disabled during the account migration using ADMT. If you did not choose to disable the source account during account migration, you need to disable those account before going for linked mailbox creation.