Archive | Exchange Server RSS feed for this section

How to Migrate Receive Connector’s from Exchange 2003 to Exchange 2007/2010 (Multiple IP Address Restrictions)

Setting up a new receive connector in Exchange 2007/2010 is pretty straightforward stuff and would hardly be worth writing a whole article about.

However, in a migration scenario where you need to migrate a specific receive connector from Exchange 2003 to multiple Exchange 2007/2010 servers and it has LOTS of IPs listed under Relay Restrictions the process can be a little more daunting.

Further, if you want to allow that list of IPs to relay to external domains without restriction, there is an additional step you must take under Exchange 2007/2010. Simply allowing those IPs to relay is insufficient.

Get the Massive List of IPs from Exchange 2003
The first thing you need to do is get the list of IPs under Relay Restrictions. If you have just a few IPs, this is no big deal and you’ll probably just write them down. If you’re in a situation like I was this past week though, you may have dozens and dozens or even hundreds of IPs, and writing them down is simply out of the question.

Fortunately, Microsoft makes it semi-easy with the SMTP Internet Protocol Restriction and Accept/Deny List Configuration (IPSec.vbs) script, which you can download here:

How to use the IPsec.vbs program to export an SMTP relay list from a computer that is running Exchange Server 2003
http://support.microsoft.com/kb/935635

Once you download and extract the contents to your C: drive, just run the following to export a list of Relay Restrictions.


cscript IPsec.vbs –s ExchangeServer –o e –r relay –d DomainController > C:\exipsecurity\exportconnectionlist.txt

NOTE: You must TYPE this command in the command window from the c:\ExIPSecurity directory. DO NOT COPY AND PASTE… it won’t work if you do that. No, it makes no sense, it’s just one of the mysteries of the Microsoft ‘verse. Now that you have your list of IPs, it’s time to create your receive connector. Create a New Receive Connector on an Exchange 2007/2010 Server As I said before, creating a new receive connector in Exchange 2007/2010 is relatively straightforward, and you can find full details from Microsoft here: New-ReceiveConnector http://technet.microsoft.com/en-us/library/bb125139.aspxI’ve taken the liberty of writing out the command below though to do what we want. This is the command we’ll run on the first Exchange Hub Transport server (technically you could run it against all of your hub transports, but I’ve also included another command to copy the Remote IP Ranges to another server).  Note that you must list out all of the IPs you wish to add to the RemoteIPRanges separated by a comma:


New-ReceiveConnector "ReceiveConnectorName" -Server Exchange2010Server -Bindings 0.0.0.0:25 -AuthMechanism None -PermissionGroups AnonymousUsers –RemoteIPRanges IPAddress1,IPAddress2,IPAddress3

Once you have the connector created on your first Hub Transport server, you can run this command to create an identical connector on the next Exchange Hub Transport server. Again, you could use the previous command. For the sake of argument though let’s say you’re adding a Hub Transport at a much later date and don’t have the original command or list of IPs handy. This command will create a new connector, and copy the Remote IP Ranges:


New-ReceiveConnector "ReceiveConnectorName" -Server Exchange2010Server -Bindings 0.0.0.0:25 -AuthMechanism None -PermissionGroups AnonymousUsers -RemoteIPRanges ( Get-ReceiveConnector "Exchange2010Server\ReceiveConnectorName" ).RemoteIPRanges

Now that you have your connectors on all of your Hub Transport servers, it’s time to allow them to relay to external recipients.

Assign Permissions to Receive Connector to Relay to External Recipients

In Exchange 2010, it’s not enough to allow a server to relay by listing its IP, you must further elevate permissions to give it this capability.

To do so, just use the following command on each of your Hub Transport servers with the relevant Receive Connector installed, replacing the bold parts with the appropriate names for your environment.


Get-ReceiveConnector "Exchange2010Server\RecieveConnectorName" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

At this point, you’ll be able to change DNS records or otherwise redirect the relaying servers/devices to your Exchange 2010 environment, and all will work just as well as it did with Exchange 2003.

Advertisements

Microsoft Exchange Team re-releases Update Rollup 4 for Exchange Server 2010 SP1 (with a Quirk)

On Wednesday, July 27th, the Microsoft Exchange Team released Update Rollup 4 v2, the replacement for Update Rollup 4 released on June 20th that was pulled for various issues.

While patching my own servers, I ran in to a bit of an issue trying to get it to install. I kept getting error 1603 (see below for full error).

Upon further review it was stating that I had installed an interim patch for Exchange 2010. The error log also stated I needed to remove that interim patch before I could install Update Rollup 4, and that I needed to run the update as an administrator.

One problem, I hadn’t installed any interim patches and the account I was using has god rights on the domain.

It turns out the solution was simple, but undocumented. I simply ran the update from the command line with elevated administrative permissions (i.e. I right-clicked on Command Prompt and selected Run as Administrator), and it installed without incident.

Also, if you want to dramatically speed up the amount of time it takes to install Hotfixes in Exchange 2010, remember to do the following:

  1. Open Internet Explorer
  2. Go to Tools – Internet Options
  3. Click on the Advanced tab
  4. Scroll down to Security
  5. Uncheck “Check for publisher’s certificate revocation”
  6. Hit Apply, then OK and install the Hotfix according the procedure above.

You can read all about the patch here:

http://support.microsoft.com/kb/2579150

…and read the more candid release on the Microsoft Exchange Team blog here:

http://blogs.technet.com/b/exchange/archive/2011/07/27/announcing-the-re-release-of-exchange-2010-sp1-rollup-4.aspx

Here’s the full error I was getting:

MSI (c) (34:D8) [08:18:24:200]: Product: Microsoft Exchange Server – Update ‘Update Rollup 4-v2 for Exchange Server 2010 Service Pack 1 (KB2579150) 14.1.323.6’ could not be installed. Error code 1603. Additional information is available in the log file [redacted]. MSI (c) (34:D8) [08:18:24:200]: Windows Installer installed an update. Product Name: Microsoft Exchange Server. Product Version: 14.1.218.15. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: Update Rollup 4-v2 for Exchange Server 2010 Service Pack 1 (KB2579150) 14.1.323.6. Installation success or error status: 1603. MSI (c) (34:D8) [08:18:24:216]: Product: Microsoft Exchange Server — Configuration failed. MSI (c) (34:D8) [08:18:24:216]: Windows Installer reconfigured the product. Product Name: Microsoft Exchange Server. Product Version: 14.1.218.15. Product Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 1603.

How to Upgrade the Distribution Group version from Exchange 2003 to Exchange 2010 for All Objects

In my Exchange environment, I have thousands and thousands of distribution groups, all of which needed to be upgraded to the latest Exchange version so that they could be easily managed in the Exchange Management Console by our help desk.

Not wanting them to have to manually upgrade each one as they came across them, I looked for a way to upgrade all of them all at once. It’s actually quite simple, just run the command below… it simply retrieves each Distribution Group and then runs the “Set” command against it. It doesn’t actually make any modifications to the object though, it just upgrades it to the latest version.

get-DistributionGroup | set-DistributionGroup

How to Automatically Remove Spaces from Legacy Distribution Groups for Exchange 2007 & 2010

In Exchange 2003, it was possible to create a mailNickname (aka Exchange Alias) with special characters in it such as spaces. This poses a major problem in Exchange 2010, as it does a validation on that field and if it’s invalid in any way, it considers it a corrupt object. This prevents you from upgrading the object and will also prevent Distribution Group managers from modifying their lists.

Personally, I manage an Exchange environment with thousands and thousands of groups, hundreds of which included spaces. Modifying them one at a time wasn’t an option, so I found this PowerShell script to remove them programmatically.

Simply copy this script into a text file and name the file “FixDistro.ps1.” Open up the Exchange Management Shell (make sure to Run As Administrator), navigate to the directory holding the script and type: “./FixDistro.ps1”


$DistributionGroups = Get-DistributionGroup -OrganizationalUnit "internal.domain.local/OU/SubOU" | Where {$_.Alias -like "* *"}

ForEach($DistributionGroup in $DistributionGroups) {Set-DistributionGroup $DistributionGroup.Name -Alias:($DistributionGroup.Alias -Replace " ", "")}

It should go through and change all of the Distribution Groups so that they will not have spaces in them. Please note however that if the script runs into a Distro with another special character, it will likely terminate. You can either fix that distro manually and then rerun this script or simply modify this script to replace those particular special characters.

You will get a prompt to upgrade the object to Exchange 2010. Instead of hitting a key each time, just hold down the Enter key and it will fly through them pretty quick.

How to configure Exchange 2010 & Threat Management Gateway for iMExchange 2 or Other EWS-based Apps

We recently began a whole migration of users over to our Exchange 2010 environment after a successful months-long pilot program. One of our users reported that they could no longer successfully sync iMExchange 2 on their Apple iPhone and iPad after they were migrated from Exchange 2003 to Exchange 2010.

iMExchange 2 is a great program you can use to synchronize your tasks & notes with your iPhonei/iPad/iPod as well as manage your Out-of-Office settings. I only downloaded it for troubleshooting purposes, but it’s an app I’ll keep and use.

In order to troubleshoot it, I installed iMExchange 2 on my own iPhone and began to troubleshoot it.  It was a little puzzling because we didn’t have anything restricted any more than we did in Exchange 2003.  We still had ActiveSync and Outlook Web Access enabled, so one would think everything should work just as well under Exchange 2010.

However, iMExchange 2 doesn’t appear to use Outlook Web Access or ActiveSync under Exchange 2010 (and I would suspect the same is true with Exchange 2007). It actually uses Exchange Web Services, which would normally be set up as a component of Outlook Anywhere. Unfortunately, we don’t use Outlook Anywhere in this environment due to erroneous InfoSec concerns, so I needed to enable some of the functions while still restricting Outlook Anywhere.

So, in order to support it or any apps like it, you need to configure your environment with some of the same things that are used for Outlook Anywhere, but you don’t have to go all the way with it.

On Forefront Threat Management Gateway, you’ll need to use the Exchange Publishing Wizard to publish Outlook Anywhere (note: enable the option for Outlook 2007 extra folders when you come to it) just as you would have for ActiveSync & Outlook Web Access. You can use the same Listener you set up for the other services as well… no need for a unique IP or certificate.

In addition, you’ll likely need to enable Basic Authentication for the /EWS and /OAB folders in IIS Manager on each of the Client Access Servers.

At this point, iMExchange 2 should work great and all you have changed is that you are now publishing the /EWS and /OAB folders. They still require authentication, they are still protected via SSL, and Outlook Anywhere still will not work… leaving your end users’ and InfoSec needs satisfied.

User with Exchange 2003 Mailbox Cannot Manage Membership of Exchange 2010 Distribution Group

Consider the following scenario:  You have added Exchange 2010 to your Exchange 2003 infrastructure and intend on running both simultaneously for a period of time.

You create a new Distribution Group in Exchange 2010, and use the Exchange Management Console/Shell to add multiple users as managers for the group, including one or more Exchange 2003-based users.  After doing so, the Exchange 2003 users cannot manage the membership of the distribution group through Outlook.

However, any Exchange 2010-based users can manage the membership of the group.

Root Cause
In Exchange 2003, you would specify a single manager for a Distribution Group by using Active Directory Users and Computers; specifically the Managed By tab in the properties of the group.

In Exchange 2010, you can set multiple managers for a Distribution Group by using the Exchange Management Console/Shell.  This is done by going to the properties of the specific Distribution Group, and then clicking on the Group Information tab.  The “Managed By” section will allow you to add as many members as you wish.

When a group is created in Exchange 2010 and multiple managers are specified, only one of those managers (the first one added), will appear on the “Managed By” tab if you look at the properties from within Active Directory Users & Computers on a computer with the Exchange System Manager installed.

Therefore, as far as Exchange 2003 is concerned, only one user actually has “manage” permissions for the Distribution Group.

Solution
If you only have one Exchange 2003 user that needs permissions to manage the Distribution Group, you can use Active Directory Users & Computers to set them as the manager of the group.

That action will not affect the other managers of the group specified in the Exchange 2010 Management Console as long as they are homed on an Exchange 2010 server.

If you have multiple Exchange 2003 users that need to manage the membership of a Distribution Group, you will have to migrate those users to Exchange 2010.

Additional Information
In addition, you will likely need to ensure that you follow the instructions in this blog from Microsoft:

http://blogs.technet.com/b/exchange/archive/2009/11/18/3408844.aspx

By default, users are prevented from managing the membership of a Distribution Group in Exchange 2010 even if they are specified under “Managed By:” on the Group Information tab.  The above blog outlines this behavior in Exchange 2010 and the steps/scripts necessary to remedy it.

How to Modify the Default OU for New Distribution Groups in Exchange 2010

When creating a new distribution group with the Exchange Management Shell or Console in Exchange 2010, it will by default attempt to place the group in the Domain\Users (CN=Users,DC=domain,DC=com) folder.

While it is simple enough to specify the organizational unit (OU) while creating the distribution list, it is sometimes difficult for delegates to remember to specify the OU.

The solution is to use the Set-OrganizationConfig in order to change the default OU to whatever you want it to be.  Just launch the Exchange Management Console and run the following command:


Set-OrganizationConfig –DistributionGroupDefaultOU “[distinguishedName of OU]”

If you’re unfamiliar with how to retrieve the distinguishedName of the OU, just go to Active Directory Users & Computers and select View – Advanced Features.

Now, find the OU and right-click on it to select Properties.  There should be an Attribute Editor tab displayed which will list out all of the attributes for the OU, including the distinguishedName (you can double-click on it in order to copy/paste it in to your command).

If you would like to do the same thing for new mailboxes that are created, you can’t (at least as of SP1). The only way to enable similar funcationality for mailboxes is to use mailbox templates, which then require that you create all new mailboxes from the Exchange Management Shell instead of the console.

How to Turn Off Attachment Filtering on Exchange 2010 Edge Transport

We had an interesting issue recently where our Exchange 2010 Edge Transport server was erroneously stripping out .zip files.  The funny thing was that we really didn’t intend for it to be doing attachment filtering in the first place as we have a variety of other tools in place to take care of that.  It’s enabled by default though, and I wanted it off, so we needed to add an exception for our receive connector.

It’s not as straightforward as you would expect though to turn off attachment filtering on an Exchange 2010 Edge Transport server.

The first step is to see if there are any connectors on the attachment filter exception list presently.  To do so, run this command:


Get-AttachmentFilterListConfig

About the fifth line down you should see “ExceptionConnectors” which probably has nothing next to it.  Even if it does, it really doesn’t matter, we’re just checking so that we know the current state of affairs (always best to know your starting point so that you can check again at the end and make sure you were successful with what you think you did).

You can only turn off attachment filtering by referencing the GUID, so now we need to get the GUID of the relevant receive connector.  In our situation, the connector’s name was “Inbound from Internet,” so we run this command:


Get-ReceiveConnector "Inbound from Internet" | Format-List

This will give us all the properties of our Receive Connector, including the GUID, which will be listed about 10 lines up from the bottom.

Now that we have the GUID, we can run the command to add the receive connector to the list of exceptions for attachment filtering by running this:


Set-AttachmentFilterListConfig –ExceptionConnectors [GUID]

Replacing [GUID] with the GUID we retrieved in the previous step.

Finally, run Get-AttachmentFilterListConfig again and check the Exceptions line, you should now see your receive connector listed there.

How to Correct RBAC Permissions for Distribution List Membership Management in Exchange 2010

If you have just installed Exchange 2010 and are experiencing an issue with end users’ not being able use Outlook to add members to distribution groups they own, there is now a “fix” for it.  I say fix with air quotes because, according to Microsoft, nothing is really broken, it’s by design with the new RBAC permissions model.

Matt Byrd with The Exchange Team has an excellent blog article on this at:

http://blogs.technet.com/b/exchange/archive/2009/11/18/3408844.aspx

…with the actual script to fix it located at:

http://gallery.technet.microsoft.com/scriptcenter/8c22734a-b237-4bba-ada5-74a49321f159

After running the script, your end users should be able to manage the membership of any distribution groups they are listed as the manager of.

Critical Commands to get Autodiscover Working Properly in Exchange 2010

The AutoDiscover server in Exchange 2007/2010 can be particularly troublesome, and since it effects just about everything in Outlook 2007/2010 (such as the Out of Office Assistant and Free/Busy Status), it’s absolutely critical to get right.

When you break it all down though, there are really just three steps to ensuring your AutoDiscover service is configured correctly in Exchange.

Helpful Hint: I would highly suggest using separate SSL certificates on for your External servers (such as TMG) from your internal servers.  We used a public SSL certificate (GeoTrust) on our TMG servers for webmail (with a subject like mail.ExternalDomain.com).

However, on our internal Exchange servers, we used an internally signed cert that not only contained mail.ExternalDomain.com, but also contain alternative names with all server names in the Exchange organization… short names and FQDN’s.  This allowed everything to work together happily.

Contrary to popular belief, even if you are using multi-role 2010 servers, there is absolutely no requirement that the mail.ExternalDomain.com certificate be the same as the one installed on TMG.

Back to the subject at hand.  First, check the settings for the AutoDiscoverServiceInternalUri by running this command:


Get-clientAccessServer | fl Name,AutoDiscoverServiceInternalUri

Everything look right for how you think Outlook should see the server?  If not, then use this command to set it right:


Set-ClientAccessServer -Identity ClientAccessServerName -AutodiscoverServiceInternalUri https://ClientAccessServerName.InternalDomain.local/autodiscover/autodiscover.xml

Now, let’s look at the Offline Address Book.  This is actually available in the Exchange Management Console, so it’s easier to see the current settings or adjust it there.  However, if you want to be doubly sure, you can set it from the Exchange Management Shell with these commands:

Internally…


Set-OABVirtualDirectory -Identity " ClientAccessServerName\oab (Default Web Site)" -InternalUrl https://ClientAccessServerName.InternalDomain.local/oab

…and Externally


Set-OABVirtualDirectory -Identity " ClientAccessServerName\oab (Default Web Site)" -ExternalUrl https://mail.ExternalDomain.com/oab

Finally, the one that is most vexing and poorly documented, the Exchange Web Services themselves.  First, check the settings for the WebServicesVirtual Directory by running this command:


Get-WebServicesVirtualDirectory | Select name, *url* | fl

Everything look right?  Probably not… this one is a mess out of the box, and while you would think the settings would be copied from the EMC settings, but they are not.  To correct them, use these commands:

Internally…


Set-WebServicesVirtualDirectory -Identity "ClientAccessServerName\EWS (Default Web Site)" -InternalUrl https://ClientAccessServerName.internaldomain.local/ews/exchange.asmx

And Externally…


Set-WebServicesVirtualDirectory -Identity "ClientAccessServerName\EWS (Default Web Site)" -externalUrl https://mail.ExternalDomain.com/ews/exchange.asmx

Hopefully I’ve saved you some hours of beating your head against the wall like I did!