The Exchange team has released an updated version of update rollup 4 for Exchange 2010 SP1 to the Download Center. This updated release is being made available after a complete review and revalidation of the list of fixes included in the previously released version of Rollup 4 dated June 22, 2011.

• Customers who have installed KB 2509910 (Rollup 4, dated June 22, 2011) and KB2581545 (fix for Rollup 4 regression) do not need to install KB 2579150 (re-released Rollup 4) but may do so if they choose to.
• Customers who have already installed KB 2581545 and want to update their systems to the updated Rollup 4 should first uninstall KB 2581545 (or any interim updates) prior to installing the new rollup.
• You do not need to uninstall original RU4 (KB 2509910) to install the re-released RU4 package (KB2579150).
• The re-release of Rollup 4 does not change the release plans for Update Rollup 5 for Exchange Server 2010 Service Pack 1. Rollup 5 is currently scheduled to release in August 2011.

The installation wizard clearly says that it is Update Rollup 4-v2

Download the v2 Update Rollup 4 for 2010 SP1 here

More info @ source

Exchange 2010 ships with a number of test cmdlets to test the CAS functionality, like testing Outlook, OWA, ActiveSync, POP, IMAP etc. But whenever you try and run a test cmdlet like Test-OutlookConnectivity, it will complain that it can’t find a test mailbox.

Exchange 2010 ships with a script to create a test mailbox to run these test cmdlets. It’s named “New-TestCASConnectivityUser.ps1” and is stored in the Scripts directory. I ran this script in my lab only to be greeted with an error!

CreateTestUser : Mailbox could not be created. Verify that OU (Users) exists and that password meets complexity requirements.

I am sure that the password I entered was a complex one. That left me with the second half of the error message. I do have a “Users” OU and hence I took a look at the script only to find that the OU name is coded as “Users”. As I have (and many other companies have) more than one OU named “Users”, the script throws the error message.

There are number of solutions for this issue.

• Edit your OU structure so that there is only one OU named “Users”.
• Edit the script with the distinguished name of the OU named “Users”.

• If you have a specific OU for test/service accounts, specify the DN of that OU in the script.

Once I made the changes, I was able to create the test account successfully using the script.

Every exchange admin would have come across a user complaining that the new staff is not present in the address book and hence he/she can’t email the new member of staff. There are number of ways of solving this and I am sure you are all aware of it. Few solutions are to flip Outlook to online mode, download the new set of OAB files after getting the server to update it, getting the user to use OWA as a work around etc.

One solution which is of particular interest is to get Outlook to use the online Global address list while working in cached mode itself. This does mean that the network traffic between the client and server will be more and there will be much more frequent lookup request against global catalog servers. For smaller companies, they can easily turn this feature on, whereas larger companies will need to analyze the impact it has on the network, especially if they have remote locations connecting to the backend infrastructure.

All it takes is a registry edit on the client machines to configure Outlook to use the global address list. Depending on the Outlook version, edit the registry as stated below. It should be noted that mobile users should be avoided from this registry edit as they won’t have an address book otherwise (while working offline)!

Outlook 2010

HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0OutlookCached Mode

Parameter: DownloadOAB
Type: REG_DWORD
Value: 0

Outlook 2007

HKEY_CURRENT_USERSoftwareMicrosoftOffice12.0OutlookCached Mode

Parameter: DownloadOAB
Type: REG_DWORD
Value: 0

Outlook 2003

HKEY_CURRENT_USERSoftwareMicrosoftOffice11.0OutlookCached Mode

Parameter: DownloadOAB
Type: REG_DWORD
Value: 0

Setting the value to zero prevents OAB download and forces Outlook to use the global address list. If the “Cached Mode” key doesn’t exist, create it.

Note If .oab files were previously downloaded and associated with an Outlook profile, this setting will not have the correct effect. To use this setting, you must set the registry value, remove any .oab files from the local computer and then synchronize.

Check the KB article for more info.

The title may seem confusing and it is intended. While going through the Exchange 2010 Technet, I came across a statement which will confuse any Exchange admin. The article says that it has been updated for Exchange 2010 SP1, but the last updated date is 2009-12-10. It says,

****To benefit most from Web-based distribution, client computers must be running Outlook 2010 or Outlook 2007. Organizations that also have client computers running Outlook 2003 or earlier can use both public folder distribution and Web-based distribution. The Outlook 2003 Service Pack 1 (SP1) and earlier clients will still access their OABs by using public folders, while Outlook 2010 or Outlook 2007 clients will take advantage of the new Web-based distribution method****

The full article is here. It gives a feeling that Outlook 2003 SP1 and prior uses public folders for accessing offline address book, while 2003 SP2 can use both web-based and public folder OAB and 2007 & 2010 uses only web-based distribution. Seriously???

It is about time that the article is updated. I have seen a few questions in forums quoting the above statement. To be clear, Outlook 2007+ uses web-based distribution and 2003 & prior uses public folders for accessing OAB.

There are lot of companies still using Outlook 2003 with Exchange 2010, purely because the desktop refresh hasn’t happened yet. Hence, public folder distribution will be used to distribute OAB files to these clients. With public folder distribution, a request for a full OAB download is served immediately, which means that if there are many clients requesting a full download, the network bandwidth might be saturated. This doesn’t affect smaller companies or ones with small address books. But, for large organizations, this is a serious issue as the size of the address book might run into few hundred megabytes.

I came across this issue as I am working on an Exchange 2010 design for a large organization. Is it possible to throttle the OAB download when public folder distribution is used? You sure can. All you need is a registry edit specifying the limit in KBps (kilobytes per second). The registry has to be edited on all mailbox servers hosting the OAB folders. It should be noted that throttling is turned off by default.

Make the following registry edit to limit the network bandwidth used by OAB downloads.

• HKEY_LOCAL_MACHINESystemCurrentControlSetServicesMSExchangeISParameterSystem
• Create a DWORD named OAB Bandwidth Threshold (KBps)
• Set a decimal value between 0 and 4194304.

No server or service restart is necessary. Exchange will dynamically pick up the registry change.

It is known that the InternalURL for the OAB virtual directory is “http” by default in Exchange 2010. OAB is the only service which uses unencrypted traffic by default. If you check the properties of the OAB directory in Exchange Console, you will see that the url will be “http://cas fqdn/oab” by default. In my case, the CAS server fqdn is hewexch.hew.local.

Checking the properties in IIS shows that the “Require SSL” option for OAB is not checked by default.

Why is it that OAB accepts unencrypted traffic, when we say that Exchange 2010 is secure by design? The reason is that Outlook uses Background Intelligent Transfer Service (BITS) to download OAB and BITS doesn’t work with the self signed certificate that Exchange 2010 installs by default.

The next question will be whether it is possible to have encrypted OAB traffic at all. Yes, you can. It is recommended by Microsoft to turn on SSL for OAB virtual directory in IIS. You can do this as long as you are using a trusted certificate for Exchange 2010 and the OAB url is covered by the certificate.

In my lab, I have a SAN certificate that covers “mail.howexchangeworks.com” and “autodiscover.howexchangeworks.com” urls (Yes, I have split-DNS). Hence, I can turn on SSL in IIS for OAB (or using Shell), as long as my OAB url is “https://mail.howexchangeworks.com/oab”. I can use the autodiscover url, but that won’t be neat!

Now, all of you using trusted certificate, go ahead and turn on SSL for OAB

I have been to customer sites where exchange admin gets all confused about autodiscover and split-DNS. Is split-DNS necessary to run Exchange 2010? What are the advantages?

First of all, it is not mandatory to have split-DNS in your environment to have Exchange 2010 deployed. Is it good to have? Definitely, yes. Microsoft does recommend using split-DNS model where possible. It is understandable that not all companies will be in a position to have split-DNS.

Following are the advantages of having split-DNS

• Staff will be able to use a single url for Exchange services like OWA, irrespective of whether they are internal or external to the corporate network.
• When staff are internal and access OWA, traffic remains within the internal LAN.
• You can have Exchange 2010 running with a SAN/UCC certificate with just two urls, mail.domain.com and autodiscover.domain.com.
• You can have your AutodiscoverServiceInternalURI to be autodiscover.domain.com (a public url). This means that your SAN/UCC certificate will only have public urls. Some admins are concerned about exposing internal AD information in the certificate.
• You can have mail.domain.com for all your internal and external URLs for different Exchange virtual directories and autodiscover.domain.com for autodiscover service, both internally and externally.
• It will be easy to configure and manage your environment. Less urls/settings to remember as an admin.

It is worth noting that Exchange 2010 does work fine without a split-DNS model. It means more urls and having a clear understanding of how autodiscover works internally (explained here) and which all urls should be in the SAN/UCC certificate.

Do comment if you know any other advantages of having split-DNS.

I received an email few days back with a lot of questions around autodiscover. The sender was confused about a number of facts around autodiscover service. This has prompted me to write “to the point articles” about this wonderful service.

How does Outlook 2007+ clients connect using autodiscover service internally? What is needed and what should be configured? Do we need an “A” record for autodiscover.ADdomain.local? These were few of the questions I had received.

First of all, when an Outlook 2007+ client is fired up, it queries AD for SCP object (explained here). Every CAS server in the environment will have a corresponding SCP object. The SCP object has an attribute named “serviceBindingInformation” which is an https url, normally pointing to the CAS server itself.

We can configure this url using the Exchange Shell, by setting the “AutodiscoverServiceInternalURI” parameter of the CAS server. It is this url to which the Outlook clients connect to, for getting the urls for Exchange services (OAB, OOF, Availability Service etc) provided by the autodiscover service.

So, the first step in configuring autodiscover internally is to set “AutodiscoverServiceInternalURI” parameter of the CAS server. If you have more than one CAS, it has to be set on all servers. Normally, we point this url to the load balancer and cover it in the SAN/UCC certificate. This means that you can configure this parameter with the url you are using for OWA internally, as it will hit the load balancer. Whichever url you go for (a new one or use existing internal URLs), it has to be in the SAN/UCC certificate.

The url doesn’t have to have the format of autodiscover.ADdomain.local. There is no specific format for this url, it is just a url that can be routed internally. For example, I have hew.local domain in my lab and I have configured an “A” record called “mail” which points to my load balancer VIP. I use “https://mail.hew.local/autodiscover/autodiscover.xml” as my “AutodiscoverServiceInternalURI” and I have this url as part of my SAN/UCC certificate. I ran the command below to configure it.

If you have split-DNS (which means that your OWA urls are same internally and externally), you can configure “AutodiscoverServiceInternalURI” parameter to be your OWA url. If I had split-DNS, I would configure it to be “https://mail.howexchangeworks.com/autodiscover/autodiscover.xml”. The url “mail.howexchangeworks.com” will be in my SAN cert, as that is the same url for all my Exchange services like OWA, EAS, OA. I think you get the point.

In short, you can configure “AutodiscoverServiceInternalURI” parameter of the CAS server to be any url, as along as it reaches the CAS server (either directly or through load balancing) and is covered in the SAN certificate. You don’t need a split-dns model just to have autodiscover working internally. I think this is were most of the admins are getting confused. Split-DNS is something “nice to have”, so that users will use the same urls irrespective of whether they are internal or external for OWA, ECP, EAS, OA and the SAN cert will only have public urls.

Once the autodiscover url is set internally, you need to set the internal (and external for external access) urls for the different Exchange virtual directories, like ActiveSync, WebServices, OWA, OAB, UM etc. I hope this clear the doubts of many exchange admins.

Note: You can use an internal PKI certificate covering “AutodiscoverServiceInternalURI” url and a third party certificate in your reverse proxy like TMG.

Every Exchange administrator will have heard the term “Service Connection Point” or SCP when autodiscover is mentioned. What is SCP and where can I find it? What is it used for? These are some of the questions that need clarification.

Whenever a client access server is installed, a new service connection point (SCP) Active Directory object is created for that server. The SCP object is used by domain joined clients to locate the Autodiscover service. Where can I find SCP? You can view the SCP object using Active Directory Sites and Services, after you have enabled the “View Services Node” option from the “View” tab.

You will have a list of SCPs if you have more than one CAS server in your environment. If you right click and take the properties of the SCP object (Attribute Editor tab), it contains two two pieces of information which is of interest, the “serviceBindingInformation” attribute and the “keywords” attribute.

The “serviceBindingInformation” attribute has the Fully Qualified Domain Name (FQDN) of the Client Access server in the form of https://hewexch.hew.local/autodiscover/autodiscover.xml, where hewexch.hew.local is the FQDN of the CAS server. This url is mostly changed to one that is covered by the SAN/UCC certificate. It is this url which internal Outlook client uses to connect to the mailbox and other Exchange features published using autodiscover.

The “keywords” attribute specifies the Active Directory sites to which this SCP record is associated. By default, this attribute specifies the Active Directory site to which the Client Access server belongs.

When using a domain joined client, Outlook 2007+ client authenticates to Active Directory and tries to locate the SCP objects by using the user’s credentials. After the client obtains and enumerates the instances of the Autodiscover service, it connects to the first Client Access server in the enumerated list and obtains the profile information in the form of XML data that is needed to connect to the user’s mailbox and available Exchange features.

It’s been a while since Microsoft released Exchange Processor Query Tool to assist architects in designing enterprise Exchange 2010 deployments. This tool is used to calculate the planned processor’s SPECInt 2006 Rate Value. Internet connection is required to run this tool. The tool will take your planned processor model as input and execute a web query against the spec.org website returning all test result data for that particular processor model. The tool will also calculate an average SPECint 2006 Rate Value based on the number of processors planned to be used in each mailbox server.

For example, if you are using HP DL380 G7 (3.20 GHz, Intel Xeon X5672) for your mailbox server, you use the processor type X5672 as an input to the Processor Query Tool.

Clicking “Query” shows the server models including our HP DL380 G7.

We will be using 8 cores and selecting “8” in step 4 shows the average result of “307”.

This value is then input into Exchange 2010 Storage Calculator – on the Input tab under "Role Requirements Input Factors – Processor Configuration". Enter the SPECint2006 Rate Value for your planned mailbox server to determine the adjusted megacycle calculation.

Download the Exchange Processor Query Tool here