Tag Archives: Exchange 2010

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.

Advertisements

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!

Mail Enable All Existing Distribution Groups within an OU

Using the EMC to mail enable a distribution group is incredibly inefficient as you can only perform the action on one group at a time.  The EMS isn’t much better as there is not a native command to target every group within a specific OU.

Why would you need to mail enable a distribution group?  Well, remember with Exchange 2007/2010, you could create a new group in Active Directory Users & Computers, and even make it a Universal Distribution Group, but Exchange won’t see it until you mail enable it.  In my case, I had to import a LARGE number of groups from a recent aquisition, so I had them in AD but did not have them mail enabled yet.

In order to do this, we need to create a new PowerShell script with the following code:

Get-Group -OrganizationalUnit "OU=users,DC=domain,DC=com" | ?{ $_.GroupType  -Match "Universal" } | %{ 

# Check to see if the group is mail enabled or not.   

   If ($_.RecipientType -eq "Group") {
      Enable-DistributionGroup $_.DistinguishedName
   }
}

Just change the “OU=users,DC=domain,DC=com” to whichever OU you are targeting and you should be good to go.

How to create a report of all mailbox sizes in Exchange 2007/2010

It’s often a requirement to get a good report of mailbox sizes for all users.  This was pretty straightforward in earlier versions of Exchange, but in 2007 & 2010 it’s a little more complex… you need a good script to do it.

This can be very useful if you want to get an idea of your heavy users or if you need to plan a migration.  Whatever your reason, it’s a handy script that creates a nice text file in whatever directory you run it from.

Please make sure you edit this so that the command is all on one line, and then you should be good to go!


Get-MailboxStatistics | Sort-Object TotalItemSize -Descending | ft DisplayName,@{label="TotalSize(KB)";expression={$_.TotalItemSize.Value.ToKB()}},ItemCount > GetMailboxStats.txt

How to Add Your Exchange 2010 Server as a Replica for all Public Folders

If you’re in a position where you must continue to use Public Folders with Exchange 2010, and you need to add your new Exchange 2010 server as a replica on a plethora of Public Folders, it’s surprisingly easy to add it to the list of replicas for every Public Folder.

You probably already know that simply adding it as a replica to the parent folder doesn’t quite do it.  However, Microsoft has a script built for Exchange 2010 that will do all of the hard work for you.

Simply open the Exchange Management Shell and navigate to the \scripts folder in your Exchange installation directory.  Once there, do the following:

  1. Run .\AddReplicaToPFRecursive.ps1
  2. Type in “\” when it prompts for the TopPublicFolder
  3. When it prompts for Server To Add, just type in the name of your Exchange 2010 server that is hosting the public folder database.

That’s it, the script may take a while to run (it won’t give any indication that it is doing anything), but it will ultimately complete.  When it does, you should see your 2010 server as a replication partner on every single public folder, which you can validate by running this command:


Get-PublicFolder –Recurse | fl Name, Replicas

Note that it might take a few minutes for the added servers to show up if you have a large number of replicas.

More details from Microsoft are available here:

http://technet.microsoft.com/en-us/library/aa997966.aspx