Upgrading Exchange EAP and Address Lists (Opath Format) for Exchange 2007\2010

December 19, 2011 1 comment

For administrators that have supported Exchange since Exchange 5.5 or 2003 days, you know that if you have a large organization with multiple domains, you likely have several Address Lists and Email Address Policies that need to be upgraded to Exchange 2007\2010 format.  The problem is when you migrate to Exchange 2007 or 2010, the syntax or Opath format is no longer supported in the old version.   Essentially the Opath format is a LDAP filter, where the syntax between the different types of Exchange versions is drastically different.   This causes old address list queries to not produce any user while searching.  (Typically from the Outlook address book or GAL)

This TechNet Article goes into more detail on the subject.
http://gallery.technet.microsoft.com/scriptcenter/7c04b866-f83d-4b34-98ec-f944811dd48d

“After installing Exchange 2007 into your existing Exchange organization, the address lists and recipient policies must have OPATH filters specified in order to administer them from the Exchange 2007 tools. OPATH is the basis for the filtering syntax used by PowerShell, and is therefore the filtering syntax used by Exchange Server 2007.”

The script in the article does not change invalid or poorly written syntax that is already in place; it merely updates the syntax to Opath Format and gets them up to Exchange 2007\2010 standards.  If your LDAP filter is searching for mailboxes, DLs, and everyone named “BOB” in their Display Name at the global level, then you need to rethink what you want your filters to look for.  (We’ll get into that later)

Let’s Convert your EAP and Address Lists to Opath Format
To convert all legacy address lists, GALs, and email address policies, without prompting, run three commands:

Update any Address Lists in Legacy Format
Get-AddressList | WHERE { $_.RecipientFilterType -eq ‘Legacy’ } | foreach { Set-AddressList $_.Name -RecipientFilter (.\ConvertFrom-LdapFilter $_.LdapRecipientFilter) -ForceUpgrade }

Update any Global Address Lists in Legacy Format
Get-GlobalAddressList | WHERE { $_.RecipientFilterType -eq ‘Legacy’ } | foreach { Set-GlobalAddressList $_.Name -RecipientFilter (.\ConvertFrom-LdapFilter $_.LdapRecipientFilter) -ForceUpgrade }

Update any Email Address Policy in Legacy Format
Get-EmailAddressPolicy | WHERE { $_.RecipientFilterType -eq ‘Legacy’ } | foreach { Set-EmailAddressPolicy $_.Name -RecipientFilter (.\ConvertFrom-LdapFilter $_.LdapRecipientFilter) -ForceUpgrade }

Once these have been ran, we can now look at what a converted legacy address list versus a new 2007\2010 address list looks like.

From a 2007\2010 Exchange Management Console, the converted 2003 address list would look similar to this:

image
If you notice, you cannot edit the syntax, but you can old “Preview”.    In order to update this syntax, you must use Exchange PowerShell.

Conversely, an Exchange 2007\2010 Address List would look similar to:

image image
The one caveat is you lose the ability to edit any conditions like Display Name Filtering, which you previously could do in Exchange 2003 using the GUI.   This is quite the inconvenience and requires an additional step.

If you need to change the filtering rules or syntax, you can following this TechNet article: http://technet.microsoft.com/en-us/library/dd335105.aspx.

In my example from above, you could use:

image

Set-AddressList “Alaska” -RecipientFilter {((((((Alias -ne $null) -and (((((((((((ObjectClass -eq ‘user’) -or (ObjectClass -eq ‘contact’))) -or (ObjectClass -eq ‘msExchSystemMailbox’))) -or (ObjectClass -eq ‘msExchDynamicDistributionList’))) -or (ObjectClass -eq ‘group’))) -or (ObjectClass -eq ‘publicFolder’))))) -and (ObjectCategory -like ‘user’))) -and (DisplayName -like ‘Alaska*’))}

The highlighted portion in Red is where you would change the syntax or search criteria for your filter.  Note that, depending on your filtering rules, you may get different results depending if the mailbox is on Exchange 2003, 2007\2010.   Without knowing your environment, you may have to perform a trial and error setup.

Worse case, if you want to simplify your filter by using a specific attribute such as the DisplayName use this:
Set-AddressList “Alaska” -RecipientFilter {Displayname –Like ‘*Alaska*’}

You can use just about any other type of attribute such as mail, X400 or userPrincipleName, depending on the complexity of your environment.

Best of Luck.

Ed McKinzie

How to speed up a large Exchange 2010 Migration

December 12, 2011 6 comments

By default, Exchange 2010 Client Access Servers throttle how many mailbox moves can concurrently migrate to Exchange 2010.  This throttling is controlled by the Exchange 2010 CAS Mailbox Replication Service (MRS) and limits both the target and source Exchange servers performing the moves.  In my example, I migrated 45,000 mailboxes from Exchange 2003 and 2007 to Exchange 2010 SP1.   When I first began the migration we moved only 35 per hour @500 MB mailbox averages.  For an organization this large, the migration would have taken months.

 
In order to override the default migraiton throughput, you can follow this article:
http://technet.microsoft.com/en-us/library/ff963524.aspx.
 

“The Mailbox Replication Service (MRS), which resides on all Microsoft Exchange Server 2010 Client Access servers, is the service responsible for moving mailboxes, importing and exporting .pst files, and restoring disabled and soft-deleted mailboxes.”

If you go to your CAS server and navigate to the c:\Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config file using a text editor such as Notepad, you will see the following settings at the bottom of the config file.

 By default, the CAS servers are set to:
MaxActiveMovesPerSourceMDB = “5”    
MaxActiveMovesPerTargetMDB = “2”    
MaxActiveMovesPerSourceServer = “50”    
MaxActiveMovesPerTargetServer = “5”    
MaxTotalMovesPerMRS = “100”
 

Essentially, these settings only allow 5 concurrent moves from the source database, 2 concurrent moves for the target database, 50 per sources server, and 5 per target server, and 100 moves per CAS server.  If you are running high-end disk or have plenty of IOPS to spare, you can change the settings to:

 
MaxActiveMovesPerSourceMDB = “15”    
MaxActiveMovesPerTargetMDB = “15”    
MaxActiveMovesPerSourceServer = “50”    
MaxActiveMovesPerTargetServer = “40”    
MaxTotalMovesPerMRS = “250”

Once changed you must restart the MRS services on the CAS server.  After changing these settings, we began to see mailboxes moves jump from 35\hour to 200-250\hour.   I do want to note that the migration process is very disk I\O intensive so you should adjust these settings gradually and account for any specific hardware limitations in your environment.  

Best of Luck!

Ed McKinzie

Categories: Exchange 2010

Full-Mailbox Permission Script: Exchange 2010

December 12, 2011 Leave a comment

If you need a quick script to add the “FullAccess” permission for an account on behalf of another Exchange 2010 mailbox, here is your script:

#Save this file as Add-Full-Mailbox-Permission.ps1
#Add-Full-Mailbox-Permission.ps1
$user=Read-Host “Enter a user name”
$mailbox=Read-Host “Enter a mailbox you want to add the user to”
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
Set-ADServerSettings -ViewEntireForest:$True
Set-ADServerSettings -PreferredServer MyDomainConroller.vlab.com
Remove-MailboxPermission $mailbox -Accessrights “FullAccess” -User $user | FL    # I added this to remove the account first, just in case the ACL is hosed in some way.
Add-MailboxPermission $mailbox -Accessrights “FullAccess” -User $user | FL
#End of Script

Now we can make it easier by creating a batch script that we can use to invoke the Exchange command at will.

##Save this file as Call-Add-Full-Mailbox-Permission.bat
Powershell.exe -noexit c:\scripts\Add-Full-Mailbox-Permission.ps1

Once you have both files created, you can now click on the batch file and use the script at your leisure.  This is much easier than trying to remember syntax…..

image

Best of Luck!

Ed McKinzie

Categories: Exchange 2010

Configure RRAS on Windows 2008 R2 to route 4 Private Networks within VMware

June 8, 2011 3 comments

Within my VMware test lab, I wanted to be able to route three private networks in order to test Exchange 2010 (DAG and CAS), TMG 2010 (Reverse Proxy) and a Windows XP\7 client using Outlook Anywhere and OWA.   The problem is, I wanted to truly test the NAT routing as simulated in our production environment using VMware and virtual networks.  The networks look like this:

  • 192.168.0.X  (Internal LAN Network)
  • 10.0.0.X        (DMZ – or Internet Facing Network)
  • 100.0.0.X      (Exchange DAG Replication Network)
  • 100.0.20.X (Exchange DAG Replication Network – Second Site)

So how do I get these networks to route between one another?

THE FIX:  RRAS (Routing and Remote Access Server in Windows 2008 R2).   I was actually surprised on how easy this was to setup and will work on Hyper-V as well.

Step 1:  Add the NICS to your RRAS server.  Each NIC will have the IP address that you will use for the Default Gateway for each of the Networks in your environment.  If this is in VMWare or Hyper-V, no Default Gateway is required.   If you are using publicly routable IPs, you will need to designate static routes within the RRAS setup.  Note: Each of these NICs are on the same “VMWare” Virtual Network, so you will not have to create VM networks, this work will be handled by RRAS.

NIC Configuration on RRAS server:

  1. NIC1:  100.0.20.1 -MASK 255.255.255.0 -NO Gateway
  2. NIC2: 100.0.0.1 -MASK 255.255.255.0 -NO Gateway
  3. NIC1: 10.0.0.1 -MASK 255.255.255.0 -NO Gateway
  4. NIC1: 192.168.0.1 -MASK 255.255.255.0 -NO Gateway

image

image

STEP 2:

Install the RRAS service on your Windows 2008 R2 Server.  This can be done by going to the Add Server Roles Wizard.   You will need to add the Network Policy and Access Services.

image

STEP 3:  We will now Enable the RRAS configuration. Navigate to the Server Manager and drill into the the roles. The Routing and Remote Access should have a red indicator. Follow the illustrations below to complete the configuration.

image

Select Secure Connection between two private Networks.

image

Select NO to create Demand-Dial Connections

image

If you see an error stating “An error occurred while trying to start Routing and Remote Access Service….” This is normal.  Click OK on the error.

image

You should now see your RRAS server with a red error or indicator.   Right click on the RRAS Server (Local) and select properties.  Change the IP4V router setting from LAN and Demand-Dial routing to Local Area network (LAN) routing only.  Click Apply and OK.   Right Click on the RRAS server again, Select All Tasks and select Start to start the services.

image

You should now be all set.

image

Have fun testing!

Ed McKinzie

LYNC 2010 Design Draft

March 8, 2011 2 comments

In an effort to upgrade our existing OCS 2007 R2 environment, I wanted to come up with a new design I could build up in parallel.  This draft design includes:

  • 4 Front-End Pool Lync 2010 Servers, collocating the A\V Lync Role.
  • 2 Node – Active\Passive SQL 2008 Cluster (Note: the Passive node with server as the archive and monitoring server)
  • 2 Edge Lync 2010 Servers
  • 2 Lync 2010 Mediation Servers
  • 2 ISA\TMG Servers for Address Book Reverse Proxy
  • Pair of Hardware Load Balancers and use of a DNS round robin.

The impetus for this design was High Availability and Redundancy at every layer. We anticipate 50,000 users enabled, with a 30% utilization or concurrent connection rate. Depending on load, we can add additional front-end and edge servers to scale.

Once I get a proof of concept deployed in the lab, I will share my experiences with the build and deployment.

 

LYNC 2010 Draft Design

 

image

 

Categories: Lync 2010

EdExchange 2007: Find the Path to a Mail Enabled Public Folder

February 24, 2011 1 comment

As many Exchange administrators know when dealing with large companies, trying to track down the path of a mail enabled public folder can be a challenge.  This is especially true if you have large Public Folder implementations.  Active Directory UAC or Exchange System Objects does not show the path, but on the CN and other AD attributes.   Using the Exchange 2007 Public Folder tools is also a slow and painful process.  In order to over come this, I have written a small script to dump the Public Folder name and path or each object and child object in the hierarchy.

Get-PublicFolder -Recurse | Format-Table -AutoSize -Property Name,ParentPath| out-string -width 4096 | out-file c:\PF-Path.txt

Arts & Science \Contoso\Departments\Accounting Services\Divisions
Activity Codes \Fabrika\Departments\Accounts Payable
Arts and Sciences \Fabrika\Departments
FASAP Quarantine \Contoso\Departments\IT\Email\SBP3
FASC Announcements \Contoso\Departments\Support Center
FASC Staff \Contoso\Departments\Support Center Calls
ASIA Market Info \Fabrika\Departments\Language Services

Note: The out-string –width 4096 variable allows for the entire path to be listed and not just the truncated output.   (For example: \Contoso\Departments\Accou……………….)

Best of Luck,

Ed McKinzie

Categories: Exchange 2007

Outlook clients using Delegates break when WINS is disabled and DNS Suffixes are not configured properly on the NICs.

January 5, 2011 Leave a comment

Background:

When Outlook connects to a user’s mail profile, the FQDN of the email server the mailbox is hosted is used.  When the same user is a delegate or has access to another mailbox, the client does a port 135 referral request using the NetBIOS name of the secondary mailbox server.  MSX-Mail2 for example.  The same is true for Public Folder referral requests.  If the client fails this lookup using the NetBIOS or WINS lookup, the proxy\referral request is then made by the backend mail server on the users’ behalf.

Issue:

In this example, the DHCP clients are configured to use WINS; however, they do not have the DNS Domain Suffixes defined on the TCP\IP NIC settings, which is causing the NetBIOS lookup failures.  They need to include domain.com, user.domain.com, accounting.domain.com and so forth.  Many users are attempting to access another mailbox or calendar and upon the WINS Lookup are failing.  If you notice in the Outlook Client Configuration settings, the referral is using the NetBIOS and failing……eventually causing the Outlook client to fail.  The other compounding issue is the backend mail server also had missing DNS suffixes, which was causing the mail server referrals to fail.

Outlook

The Fix is to add the Domain suffixes to your desktop machines and backend Mail Servers.