Archive | Exchange Server RSS feed for this section

Download Links for Microsoft Exchange Server 2010 SP1 Pre-Requisites

In order to install Microsoft Exchange 2010 Service Pack 1 (SP1) you must first download and install a number of hotfixes that are not available via Microsoft update.  Unfortunately, Microsoft was not so kind as to give you a clickable or copyable link in the installer in order make installing them efficient.

So, I prepared the list below with all relevant links.  Note that on many of the links downloads are available for a number of different platforms.  If, like me, you are running Windows Server 2008 R2, you’ll be looking for the Windows 6.1 x64 version.

KB979099 (Update – No Longer Required if SP1 for Windows Server 2008 R2 is installed)


KB982867 (Update – No Longer Required if SP1 for Windows Server 2008 R2 is installed)

KB979744 (Update – No Longer Required if SP1 for Windows Server 2008 R2 is installed)

KB983440 (Update – No Longer Required if SP1 for Windows Server 2008 R2 is installed)

KB977020 (Update – No Longer Required if SP1 for Windows Server 2008 R2 is installed)

Additionally, the PowerShell commands to install the Windows OS prerequisites can be found at:

Have fun!

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= "*"

For 2008 R2, use this command:

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

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:


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! : )

Language Pack Error when Attempting to Install Exchange 2010 Service Pack 1 Upgrade

While attempting to install Service Pack 1 for Microsoft Exchange Server 2010, I kept getting this during the Readiness Checks:

Language Prerequisites
Language packs are installed on this server and must be upgraded with the Exchange binaries. Please specify a language bundle with the upgrade operation.

I was unable to proceed with the install, and clicking on the link led me nowhere.  I finally discovered that the language packs can be downloaded separately from Microsoft here:

After downloading them, I re-ran setup, and this time chose to install not only languages from the DVD, but to install all languages from the language bundle.  That led me to a screen where I was able to point to the Language Pack Bundle .exe I had downloaded.

The installation then proceeded normally with no interruption.

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 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.

Outlook 2010: How to Automatically Add Locale-based Holiday’s to Your Calendar

Today I was nosing around my Outlook 2010 settings and happened upon a neat little feature to automatically add in all of the holidays for a given country/region.

While I’m familiar with my own country’s holidays, due to a lack of interest I’m not familiar at all with the rest of the world and I’m even less interested in adding them to my calendar by hand. I deal with peers in many different countries around the world, and in attempting to schedule joint projects it’s very helpful to know in advance if they’re celebrating a holiday.

Outlook makes no assumptions when you begin using it as to what holiday’s you would like on your calendar, so by default none are added. Fortunately, Microsoft has made it very easy in Outlook 2010 to add those holidays automatically. Just do the following:

  1. On the File menu, click Options, and then click Calendar.
  2. Under Calendar options, click Add Holidays.
  3. Select the check box next to each country/region whose holidays you want to add to your Calendar, and then click OK. Your own country/region is automatically selected.

Removing holidays is not quite as slick though. Whereas you might think (logically) that you would just uncheck the holiday’s in the same box, Microsoft has a more convoluted way of doing it:

  1. In Calendar, on the View tab, click Change View, then select List.
  2. Select the holidays you want to remove. To quickly remove all of the holidays for a country/region, click the Location column heading to sort by country. To select multiple rows, press the CTRL key and click subsequent rows.
  3. Change to the Home tab and click Delete on the Standard toolbar (or simply right-click on the highlighted items and select delete).

A bit of a short post and probably obvious to a lot of people, but it was something that I hadn’t run across before and thought was pretty useful.

Exchange Architecture: Hosted vs. Non-Hosted in the Enterprise Environment

I was recently privy to a discussion about the benefits of migrating to a hosted Microsoft Exchange 2010 architecture as opposed to upgrading the internal architecture from Microsoft Exchange 2003.

This particular organization was a publicly traded company with nearly 2500 users, and had another 500 users coming online from a recent acquisition (a whole other discussion that I am sure will be the subject of many blog entries). The parent organization was utilizing Exchange Server 2003 with about four back-end and six front end servers utilizing roughly 1.5 TB of mailbox space (not to mention a full disaster recovery infrastructure in place at a hot site). The acquired company was already running Exchange 2007 with a much smaller footprint. The goal was to upgrade the Exchange 2003 architecture to Exchange 2010 and move the 2007 users in the acquired company to the new Exchange 2010 setup.

I should point out that this is a global organization with a substantial presence in multiple countries… any Exchange architecture that was deployed needed to take into account multiple languages, time zones, varying degrees of connectivity (in the United States we had near infinite bandwidth, in India we had a 2 Mbps DSL). The 2010 architecture was to be as fault tolerant as possible, utilizing a minimum of three database replicas spread across three continents.

To fully disclose my personal feelings, I wholeheartedly believe that a hosted Microsoft Exchange solution is ideal for any Small-to-Medium sized business. Microsoft Exchange is quite simply a complicated beast. While it may be easy to deploy utilizing Microsoft’s Small Business Server, it is quite difficult to troubleshoot for the vast majority of SMB computer consultants. It is for that reason that I believe a hosted solution is critical to the success of an SMB network and probably much more cost effective when you take all of the factors into account.

However, when it comes to the Enterprise sector, we are presented with quite a few additional challenges. For starters, migrating users to a traditional shared hosting platform is ridiculous. The effort that would need to be put forth and the risks involved with migrating thousands of users to a new, shared Exchange architecture is quite simply madness.

Most Exchange Hosting companies though offer a “managed” solution where the Exchange architecture is deployed much as it would be if it were a 100% internal deployment, but the hosting company then manages that solution using their substantial on-staff talent.

The use of external staff to manage a (probably) publicly traded company is where I have a real problem.

As any Exchange admin knows, it is exceedingly easy for an Exchange admin with privileged access to anyone’s mailbox, including senior management, with little or no trace of that access having ever taken place.

Consider for a moment all of the information you could glean about a publicly traded company if you had access to the CEO, Chairman’s, President’s, COO, and CFO mailboxes. Assume for a moment that they encrypt every single email they send (they likely do not)… imagine what you could find out just by having access to their calendar and contacts. A person could discover information related to an impending bankruptcy, internal strife, recalls, or mergers… information that is exceedingly valuable.

Now imagine that you see a press release from a major Exchange hosting company bragging that they host such and such Fortune 500 company. If you really wanted some info, it would be an easy task to identify their senior engineers and find one that needed some extra money. It’s just too easy to see the potential for abuse and the reward for encouraging that abuse is substantial.

Honestly, I really don’t care how many non-disclosure documents are signed or any number of insurance policies that are in place… a third party having that degree of access is spooky, there is no way they can control all of their employees and they likely are not vetting their employees as thoroughly as they say they are.

Internal admins certainly have the same access… but at least they are on the corporate network, and can be snooped upon themselves. It would be far more likely to catch an internal snoop than an external snoop, and an internal snoop would probably have a real fear of losing their job. InfoSec departments deal with internal snoops every day, external snoops are much harder to catch, especially when they’ve been given the keys to the castle.

I will say I am a big proponent of domain-integrated encryption, such as the products available from CryptZone. I strongly believe every email should be encrypted, it’s the only way to provide reasonable certainty that information is being kept confidential.

Nevertheless, I believe it is critical for the enterprise, especially the publicly traded varieties, to maintain operational control of any messaging system. The risks far outweigh the rewards of outsourcing any piece of it.