Tag Archives: Exchange 2007

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
Advertisements

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.

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 Use a Proxy Server with Microsoft Exchange 2007/2010

If you’re like me and managing an Exchange 2010 infrastructure in an environment that requires the use of a proxy server to access the Internet, you may experience various issues with Exchange.  One issue in particular is that SSL’s issued by an external certificate authority (CA) will not be able to be verified by Exchange.  You’ll get an error such as:

“The Certificate Status could not be determined because the revocation check failed”

The reason for this is that Exchange uses WinHTTP to determine the validity of the certificate.  WinHTTP uses the Web Proxy Auto-Discover Protocol (WPAD) in order to determine if a proxy server is utilized in the installed environment (if it’s specified in DHCP or DNS).

In order to determine what proxy server, if any, Exchange is using run the following command from the Exchange Management Shell (working in either Exchange 2007 or 2010):


netsh winhttp show proxy

If none is specified, or if you wish to change it, run the following command (2003/2008 only):


netsh winhttp set proxy-server="http=myproxy:8080;https=secureproxy:8080" bypass-list= "*.internal.com"

For 2008 R2, use this command:


netsh winhttp set proxy proxy-server="http=myproxy:8080;https=secureproxy:8080" bypass-list= "*.internal.com"

Just change the parts necessary to reflect the settings in your environment.  Note that “myproxy” and “secureproxy” may be the same thing.  Although techically optional, I would highly recommend setting the bypass-list to your local, internal domain name or you may have significant difficulty with the Exchange Management Console/Shell.

If you need to reset it back to direct access, just use this command:


netsh winhttp reset proxy

How to assign Full Access Permissions to Multiple Mailboxes in Exchange 2007/2010

Recently I was required to modify several dozen mailboxes in Exchange 2007 to give a user Full Access administrative rights on those mailboxes.

The Exchange Management Console limits you whereby you can only grant those permissions on one mailbox at a time.  I wanted to find a way to script it to speed the process along and make it more interesting.

The first thing I had to figure out was how to filter out just a certain set of users.  Adding them to a security group was easy enough using DSMOD (previous Blog post), but unfortunately the Exchange Shell doesn’t let you specify a security group when assigning permissions.  It does, however, allow you to specify a Custom Attribute.

In order to set one of the CustomAttribute settings in Active Directory to something unique, I used one of my favorite utilities… ADModify.Net.  Once ADModify.Net is launched, you’ll want to filter your users down by using the following LDAP Query:


(&(objectCategory=person)(memberOf=CN=Group,CN=OU,DC=domain,DC=local))

Once they are filtered out, you can the select all of the users that appear from the query and proceed to the next screen, and go to the Custom tab.  Under the attribute name field, type in extentionAttribute# substituting the “#” for any number between 1-15.  Make absolutely sure it is not currently in use.

Under the attribute value field, type in whatever you want in order to find your set of users easily.

Hit Go! and once everything is finished, proceed to the Exchange Management Shell.

Use the following command in the shell to add Full Access to a specific user for all of your users with the Custom Attribute set to the value you specified.  You’ll need to change the labels in bold to fit your environment.


Get-mailbox –filter {CustomAttribute1 –eq “VALUE”} | Add-MailboxPermission -User "TrustedUser" -AccessRights FullAccess

Use the following command in the shell to add only Receive As access rights to a specific user for all of your users with the Custom Attribute set to the value you specified.  You’ll need to change the labels in bold to fit your environment.


Get-mailbox –filter {CustomAttribute1 –eq “VALUE”} | Add-ADPermission -User "TrustedUser" -ExtendedRights Receive-As

That’s it.  Technically giving a user Full Access will also give the Receive As rights, but I like to be thorough.

Good luck! : )

Exchange Server: How to use the InterOrg Replication Tool to Replicate Free/Busy Between Exchange 2003 & 2007

Recently, the company I work for acquired another large enterprise. In order to facilitate the integration of the two companies, I was required to get the Free/Busy calendar information flowing between the two organizations Exchange Servers. In our situation we were running Exchange 2003 Front-End and Back End servers with Exchange 2007 Edge Transports. The acquired company was running Exchange 2007 with separate mailbox, client access, and hub transport servers.

For us, this was a short term thing as we were migrating to Exchange 2010 anyway. Nevertheless, it was exceedingly important we get this running quickly.

Microsoft actually has three excellent articles on deploying the InterOrg Replication Tool:

InterOrganization Replication Tool

Installing, configuring and using the InterOrganization Replication Tool

How to Use the Exchange 2003 Version of the Inter-Organizational Replication Tool with Exchange 2007

Between those three articles, you can easily get the InterOrganizational Replication Tool set up and configured… but not necessarily operational.
; )

There are three important bits of information those three articles neglect to mention.

In our situation, we purchased another company and needed to replicate Free/Busy information.

However, since the purchased company was in another country and hadn’t been secured to our standards yet, we had strict firewall policies in place between our organizations (even though we were connected via a private VPN at this point).

Obviously RPC (utilizing TCP port 135 and a random port between 1024 & 65535) had to be opened up between our two Exchange servers in order for the Replication Tool to do its magic. However, we also happened upon another interesting fact while watching the traffic flow through the firewall. We kept having issues with it working, and it turns out that RPC needs to be open to the relevant domain controllers in the sites for both sides of the connector.

Effectively, when trying to authenticate to Active Directory, the Replication Tool is trying to authenticate directly against the domain controller and not the Exchange server it is actually connecting to.

Seems obvious now, but there is nothing in the Microsoft documentation that discusses that… it just references the ports to the Exchange servers.

Additionally, we had another little hiccup. We had prepped our Exchange 2003 organization already for the Exchange 2010 migration. Even though we had no actual Exchange 2010 servers in the organization yet, the legacyExchangeDN attribute for all new contact records (utilized for the Replication Tool) was being set to the Exchange 2010 Organization (which was non-existent), not the Exchange 2003 Organization.

This prevented the InterOrg Replication Tool from functioning. We ended up using ADModify.net from Microsoft (an awesome tool) to bulk modify all of the contact records (hundreds) we had imported into Active Directory. We looked at an old account to get the proper format for the Exchange 2003 legacyExchangeDN setting and changed all of the new contact records.

Finally, it’s important to note that the Exchange servers you connect to from the InterOrg Replication Tool need to be the backend servers if you have a split role environment (which we did on both sides).

Once that was done, coupled with the Firewall rules and the legacyExchangeDN modification, we were up and running with the precious Free/Busy data being freely replicated between our organizations.