TECHPRO.MS

Many people use rules to automatically sort messages from various distribution lists into folders in order to keep the volume of email traffic in their inbox to a manageable level. This work for the most part - until someone decides to BCC a list. Since the distribution list isn't visible in the list of recipients, it bypasses all rules and gets dropped in their inbox. This can cause quite a distraction for everyone on that DL because something appeared in their inbox, and it's not quite apparent why they received that message.

Mailman and Majordomo have had this problem solved for a while now. It's actually a very simple solution: make sure the name of the mailing list is included in the subject of the email. Then users can set up filters based on words in the subject and they never encounter the problem when someone BCC's the list.

Exchange 2007 can do the same thing; it just needs a little help from a custom transport agent. I have written a very basic agent to add the name of the DL into the subject. You can use it as a starting point and add your own features.

To install this agent, follow these instructions:

1. Copy ShowDLInSubjectAgent.dll to your transport server. In this example, I place it in C:\MyAgents
2. Open the Exchange Management Shell
3. Type Install-TransportAgent -Name ShowDLInSubjectAgent -TransportAgentFactory ShowDLInSubjectAgent.ShowDLInSubjectFactory -AssemblyPath C:\MyAgents\ShowDLInSubjectAgent.dll
4. Close and restart the Exchange Management Shell.
5. Type Enable-TransportAgent -Identity ShowDLInSubjectAgent
6. Restart the transport service by typing Restart-Service MSExchangeTransport

If all goes well, all emails to a distribution list will now include the name of the DL in the subject of the email.

Note: This is a sample transport agent and it is not officially supported by Microsoft. Please see the readme.txt file included in the package for more information.

The ZIP file with the binary and the entire source for you to play with is here:

ShowDLInSubjectAgent.zip

- Jesse Weigert

Share this post :

Recently I came across a situation where it was reported that Connection Filtering stopped working (IPs on the Blocklist and RBLs were no longer being blocked). The solution led me to write this blog to clarify some confusion about "when" connection filtering is applied and how configuration settings are applied when the agents are installed on a Hub server.

Let's begin by looking at the online documentation regarding Connection Filtering:

"By default, connection filtering is enabled on the Edge Transport server for inbound messages that come from the Internet but are not authenticated. These messages are handled as external messages. You can disable the filter in individual computer configurations by using the Exchange Management Console or the Exchange Management Shell.

When connection filtering is enabled on a computer, the Connection Filter agent filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources. These are considered anonymous Internet sources."

http://technet.microsoft.com/en-us/library/bb123943(EXCHG.80).aspxv-61marf

From this explanation we see 4 things:

1. That Connection Filtering is installed on Edge by default (as are all the other AS agents)
2. Enabled for inbound (ExternalMail) by default
3. For connections that have not authenticated
4. Connection Filtering (and all AS agents) can be disabled/enabled on individual computers

So in the scenario (where connection filtering was no longer blocking) we checked:

1. Get-Transportagent which showed the Connection Filtering agent enabled
2. Get-IPBlocklistconfig which showed True for both Enabled and ExternalMailEnabled (False for InternalMailEnabled - default setting)
3. Get-IpBlocklistentry which contained IPs that should be blocked
4. Confirmed that ActiveDirectory correctly reflected that the agent and config were enabled
5. Agent Logs did not show activity related to the IPs that should be blocked

The missing piece was in understanding that connection filtering is a combination of how the Agents are enabled (noted above) and what rights the connecting SMTP session is granted. Examining the SMTP receive log files indicated that the session was granted all the rights possible (including ByPassAntiSpam) which only occurs with "Externally Secured" Authentication.

So here's the way it works:

When the AS Filter components "Enabled" and "ExternalMailEnabled" parameters are set to true, any mail that comes in from an SMTP Session anonymously or via a Partner may be scanned. If the AS Filter components "Enabled" and "InternalMailEnabled" parameters are set to true, any mail from an authenticated session may be scanned. Note: Authenticated partner sessions are not considered Internal.

So to recap: The following 5 points should be considered when determining whether an AS agent executes against a particular SMTP session.

1) The agent itself must be enabled. i.e. The Connection Filtering agent. Use Get-TransportAgent to determine which agents are installed and enabled/disabled.

2) The Anti-Spam config must be enabled. i.e. Get-IPBlockListconfig | fl enabled

3) Consider whether the Anti-spam component is set for ExternalMailEnabled and/or InternalMailEnabled

Default settings IPAllowListConfig:

4) Anonymous and Partner SMTP Sessions are governed by the ExternalMailEnabled parameter. Authenticated sessions (including connectors that are configured for External Authoritative) are governed by the InternalMailEnabled parameter.

5) What permissions does the submitting client have? i.e. All Exchange Servers and Externally Secured sessions get the Bypass Anti-spam privilege (this cannot be removed). Even when ExternalMailEnabled is true and the SMTP session is anonymous, if NT Authority\Anonymous Logon has the Bypass Anti-Spam associated with the receive connector, mail will not be checked.

Now to dispel some other misunderstandings with regard to Configuration controls

IPAllowlistconfig or IPBlocklistconfig command default settings are below. However, if InternalMailEnabled is set to True...

...no action is taken on trusted servers in the Exchange Organization. For grins, I decided to test this in my lab sending mail from one Hub to another. The sending server passed the X-EXPS Auth command which would be the auth used for "Exchange Servers". In the debug tracing you could see that the IP was checked against the IPBlocklist, but not rejected because the Exchange Servers group is granted ByPassAntispam permissions on the connector.

Configuration Misunderstandings when Anti-Spam Agents are installed on Hub servers

Anti-spam Agents are installed per server by running install-antispamagents.ps1 script.

After running the script you will have Organization level and Server level controls. There are two Anti-Spam Tabs added to the Exchange Management Console, one at the Org level and another at the Server\Hub level.

Organization level settings in the Exchange Management Console:

Server level setting in the Exchange Management Console:

Get-TransportAgent cmdlet is a per Transport server configuration setting. This example has 3 of the agents disabled. So this will only affect the Hub this is configured on:

The cmdlet, Set- Transport server, -AntispamAgentsEnabled, is a bit confusing at first. The default value is True when you run the script to install the agents on a Hub. When set to False, it does not disable the AS agents. It simply hides the Anti-Spam tab at the Server level for that particular Hub server in the Exchange Management Console (may require restart of the msExchangeTransport and close / reopen the console).

The overlooked 'internalSmtpServers' list

Imagine this scenario:

Mail with valid SPF records is rejected by your SenderID Agent. The SPF shows these IP addresses:

contoso.com text =
"v=spf1 ip4:192.168.50.2 ip4:192.168.50.3 ip4:192.168.50.4 -all"

The rejected Message headers are:

Received: From senderserver.contoso.com (192.168.50.3) by hosting1.company.com (192.168.2.3)
Received: From hosting1.company.com (192.168.51.3) by mail02.yourcompany.com (192.168.75.6)
From: sender@contoso.com

Since Exchange has to pick an IP to compare to the SPF records, which one does it pick?

To determine this, Exchange starts with the last "received: From" header in the mail message and looks for a match in the internalSmtpServers list moving up the received: From headers until a match is NOT found. In the example above, "Received: From hosting1.company.com (192.168.51.3) will be the first IP match attempted. The reason the mail was rejected above was that IP was not in the internalSmtpServers list. Adding it then returns a match so the next Recevied:From header is now examined and that IP is not only the last external IP (not in the list of internalSmtpServers) but also on the Sender's SPF records (192.168.50.3) and the mail passes SenderID Agent.

In some scenarios mail is filtered through a hosted service provider that provides services such as Anti-Spam, Anti-Virus. By failing to add the hosted service provider IP addresses to the internalSmtpServers list, it's possible that all inbound mail will cease. Upon investigation you find the following in your Agent Log:

Agent : Connection Filtering Agent
Event : OnEndOfHeaders
Action : RejectMessage
SmtpResponse : 550 5.7.1 External client does not have permissions to submit to this server
Reason : LocalBlockList
ReasonData : machine-generated entry

Machine generated entries are those added by the Sender Reputation Agent. You can get a quick look with the following cmdlet:

PS> get-IPBlockListEntry | {where $_.IsMachineGenerated}

Remember, the internalSmtpServers determines what the 'last external IP' to be used by the AS agents. If incoming mail is filtered through an appliance or hosted service it's imperative that the ip address(s) of those servers be listed here.

When the AS agents are installed but the InternalSmtpServers is not populated, Event 1022 is logged:

Anti-spam agents are enabled and the list of internal SMTP servers is empty. Please use the set-TransportConfig task to populate this list.

Troubleshooting connection filtering

1. Determine if the connecting server authenticated by examining the SMTP protocol receive logs
2. What permissions were ultimately granted to the session (get-adpermission for the receive connector Exchange Extended rights on the user)
3. Check the IPAllowlistconfig or IPBlocklistconfig for how they are enabled
4. Check the IPAllowlistentry and / or IPBlocklistentry
5. Check the individual server settings with Get-Transportagent

- Dave Forrest

Share this post :

It's been a while since I've been thinking of writing a blog post about various aspects of Outlook Anywhere that people have been asking questions about. Somehow, I keep getting myself caught up in one thing or another, and have consequently delayed writing this blog post by almost 4 months. Ugh. Better late than never I figure.

Given how long this blog post is overdue, I plan to cover a lot of topics, from frequently asked questions to common misconceptions to problems with Outlook Anywhere to suggested solutions for different problems.

How does Outlook Anywhere work?

I won't cover details on the cmdlets that enable and change settings for Outlook Anywhere. There is already a bunch of documentation on it. Instead, let's do a slightly deeper dive than the cmdlet documentation provides.

The values that you provide to Outlook Anywhere settings can be classified into 2 types of properties - client facing and server facing. Examples of client facing properties are ClientAuthenticationMethod, External Host Name. Examples of Server facing properties are IISAuthenticationMethods, SSLOffloading. Client facing properties are picked up by Autodiscover and supplied to Outlook to configure client access to the Outlook Anywhere service. Server facing properties are picked up by a servicelet called RpcHttpConfigurator which runs as part of the Microsoft Exchange Service Host service. This servicelet runs every 15 mins by default, but the interval can be adjusted by changing the value of the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\PeriodicPollingMinutes regkey. Note that setting this value to 0 turns off the RpcHttpConfigurator.

When the RpcHttpConfigurator runs, it picks up the IISAuthenticationMethods and SSLOffloading values from the AD and stamps it on the \rpc vdir settings in the IIS metabase - overwriting any previously set value. This means that if you manually change the settings on this vdir, you should expect to be run over pretty shortly by the RpcHttpConfigurator (unless you have set the reg key to 0).

Ok, so that's just part of what the servicelet does.

Outlook Anywhere depends on the RPC/HTTP Windows component to do the marshalling and unmarshalling of the RPC packets from the client to the CAS server. A client side RPC component is responsible for marshalling every RPC packet into an HTTP tunnel and sending it over to the \rpc vdir on the CAS server. RPCProxy is an ISAPI extension that unmarshals the RPC packet, retrieves the RPC endpoint that the client wants to talk to and forwards the packet to the endpoint. But imagine if you were able to connect to any server in the organization if you were able to auth against an IIS box running RPCProxy. By the weakest link theory, all you'd need to do would be hack into a single IIS server and you'd have free access to all servers in the org. Ouch ! To alleviate this problem, RPCProxy only allows connections to be made to servers and ports that are in a trusted list. This list is maintained through the HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy\ValidPorts regkey and contains all the servers/ports that RPCProxy is allowed to talk to. So, the other part of what the RpcHttpConfigurator servicelet does it that is queries the AD for all mailbox servers and stamps them in the ValidPorts regkey allowing access to ports 6001, 6002, 6004 for both FQDN and Netbios access. So, you will typically see something like mbx1:6001-6002;mbx1:6004;mbx1.contoso.com:6001-6002;mbx1.contoso.com:6004 as the value for the key. As new mailbox servers are added to the org, they will be picked up when the servicelet runs and be added to the key. Again, if you manually change this regkey, you should expect to be bulldozed by the servicelet.

Note that the ValidPorts key is only used by RPCProxy as a filter to disallow communication with unlisted server ports. It is not used to determine which server to send requests to. For the same reason, the order in which servers are listed in this key does not matter. I just thought I'd clarify this since I was recently told that there was confusion on what this key accomplished.

Ok, simple enough, now that all the configuration is done, how does Outlook Anywhere actually establish its connections. The following diagram may help:

As you see above, the client specifies the VIP of the Load balancer (or direct CAS FQDN if the CAS is exposed to the Internet) as the HTTP endpoint and the mailbox server as the RPC endpoint. The query string is somewhat like this:

http://nlb.contoso.com/rpc/rpcproxy.dll?mbx1.contoso.com:6001

This tells the RPCProxy on CAS1 that the client is trying to connect to server mbx1.contoso.com on port 6001. RPCProxy looks up the ValidPorts key and if mbx1.contoso.com:6001 is listed there, it allows the connection to go through.

The blue and red arrows above represent the 2 different connections spawned by the RPC/HTTP client component to represent a single RPC connection. This is done because HTTP connections are half duplex (i.e. they either allow you to send information or receive information, not both at the same time). In the case of RPC, connections need to be long lived and full duplex, so the RPC_IN_DATA connection acts as the sending half duplex connection, while the RPC_OUT_DATA connection acts as the receiving half duplex connection. Since HTTP requires that each connection be given a max length, each of these connections are 1GB "long" and are terminated when this limit is reached. Each of these connections is tagged with a client session id. When the RPC server component receives the RPC_IN_DATA and RPC_OUT_DATA with the same client session id, it knows that for any request received on the RPC_IN_DATA connection, it must reply back on the RPC_OUT_DATA connection. That's magic.

Ok, so you already know this, but I'll reiterate - the mailbox server has 3 ports that are used for RPC/HTTP: port 6001 is used for Mail connections, port 6002 is used for directory referral, port 6004 is used for proxying directory connections to AD. The Referral Service running on port 6002 and DSProxy running on port 6004 are part of the same mad.exe process, and the Referral Service just refers clients back to DSProxy to establish their Directory connections. If you Ctrl+Right Click the Outlook icon and click on Connection Status, it will tell you what connections exist (Mail vs. Directory), what server they are going to and what protocol they are using (HTTPS vs. TCP(direct Exchange RPC connection)).

I have conveniently omitted any discussion around certificates, since that can take up another few blog posts. As some would say, that is beyond the scope of this article and is left as an exercise to the reader.

How do I know Outlook Anywhere is working?

Simple... when no one is complaining! Seriously though, it is preferable is to run diagnostics on Outlook Anywhere before subjecting it to thousands of users. The one tool that works pretty well in most cases is rpcping. Yes, it has a lot of parameters and is confusing, but it does provide pretty good diagnostic information and as long as you have the KB open, you can figure out where problems lie. Start by pinging just the RPCProxy by using the -E option. Once that works, move onto testing the mailbox server endpoints by removing the -E and adding -e 6001 instead. Similarly for 6002, 6004.

A typical command line would be something like this. Refer to http://support.microsoft.com/kb/831051 for usage details

rpcping -t ncacn_http -o RpcProxy=cas1.contoso.com -P "user,domain,password" -H 1 -F 3 -a connect -u 9 -v 3 -s mailbox.contoso.com -I " user,domain,password " -e 6004

How does Outlook Anywhere not work?

Unfortunately, there are some cases where Outlook Anywhere does not work without requiring manual tweaks. This is the part I wish I had blogged about earlier. I'm sure there are poor folks out there that have hit these issues and wasted their time figuring out what I had already learned...

DSProxy and IPv6

As of E12 SP1, Outlook Anywhere on Windows 2008 requires that IPv6 be manually turned off on the CAS server. This is because the DSProxy component that listens on port 6004 (mad.exe) for directory connections does not listen on the IPv6 stack. If you do a netstat -ano | findstr 6004, you will see only 1 LISTENING entry - the one that corresponds to the IPv4 stack. Contrast this with ports 6001 and 6002 that have 2 entries.

(As most of you already know, if you are running your Mailbox role on the same machine as a DC, lsass.exe not mad.exe listens on port 6004, so this problem will not surface since lsass.exe listens on both protocol stacks.)

How do you turn off IPv6 ? It depends on whether you are running CAS and Mailbox on the same server or different ones.

If you're in a multi-server scenario where the RPCProxy is not on the same server as the Mailbox, then you need to do the following:

1. Unselect IPv6 from the properties of your NIC (on the RPC-over-HTTP Proxy machine); that will force the RPC-over-HTTP Proxy to use IPv4 to talk to Exchange and everything will be fine. In most cases, this step suffices. If it does not, continue with steps 2 and 3.
2. Under the regkey HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters, add a 32 bit DWORD with the name Disabled Components and value 0xFF
3. Reboot the machine

If you're in a single-server scenario where the RPCProxy and Mailbox are on the same machine, then the above does not work since the loopback interface still uses IPv6. In this case, you need to make the following changes in the system32\drivers\etc\hosts file:

1. Comment out the line ":::1    localhost"
2. Add the following two lines:
      <IPv4 address>    <hostname of the computer>
      <IPv4 address>    <FQDN of the computer>

Thanks to Kevin Reeuwijk and others for finding and reporting the issue and solution. A fix (make DSProxy listen on the IPv6 stack) is on the way and is expected to be available in Exchange 2007 SP1 RU4 in Q3 2008.

DSProxy and Split RPC_IN_DATA, RPC_OUT_DATA connections

In the diagram above, you will notice that I have used a Source IP Loadbalancing layer. This ensures that the RPC_IN_DATA and RPC_OUT_DATA connections coming from a single Outlook instance are always affinitized to the same CAS server. However, there are some legitimate scenarios where Source IP affinity is not viable for customers. A typical example is when a large number of end users are behind NAT devices causing all connections to end up with the same IP and hence the same CAS server... yay load balancing! Outlook Anywhere does not support cookies, so cookie based Load balancing cannot be used either. The only way of spreading load across the server farm is to use with no affinity or SSL-ID based affinity. However, this has the problem that the RPC_IN_DATA and RPC_OUT_DATA connections could (and most likely would) end up on different CAS servers as shown in the diagram below:

If you've been reading closely, you'll remember my earlier mention that the RPC server component is well aware of client session IDs and can reply on RPC_OUT_DATA for any requests on RPC_IN_DATA. And if that's the case, we should still be fine since Outlook always specifies the mailbox server as it's RPC endpoint. Well, almost. We are fine for ports 6001 and 6002 which are real RPC end points. The issue is with port 6004 where DSProxy pretends to be an RPC endpoint, but is just a proxy as the name implies. DSProxy only proxies client connections through to the DC. In the example above, RPC_IN_DATA is proxied to DC1 while RPC_OUT_DATA is proxied to DC2. The DCs are the real RPC endpoints. However, now that the 2 connections have been split, neither of the DCs is aware of the other connection and requests sent on RPC_IN_DATA are lost in oblivion. We call this split connectivity and it is a problem surfaced by SSL-ID or no affinity load balancing. While I would recommend not using these configurations if avoidable, it is clear as described earlier that these may be the only alternatives. Think hard if this is the case since the workaround that I am describing below will be tedious to maintain.

The goal of these steps is to eliminate the possibility of split connectivity by (1) having clients bypass DSProxy wherever possible and (2) constrain DSProxy to talking to a single DC for any requests to DSProxy.

First off, you need to avoid using DSProxy wherever possible. Normally, the Referral Service running on port 6002 refers clients to DSProxy on port 6004. By setting the following regkey, you instruct Referral Service to not send clients to DSProxy, but instead give them a referral to a DC for directory connections. So, instead of client connections going from Client to RPCProxy to DSProxy to DC, the path would be from Client to RPCProxy to DC. Note that the client is not directly connecting to the DC, so it is not required to publish the DCs to the internet or open any new firewall ports. See KB http://support.microsoft.com/kb/872897 for details:

On the Mailbox servers: a DWORD  entry needs to be created on each Mailbox server named "Do Not Refer HTTP to DSProxy" at HKLM\System\CCS\Services\MSExchangeSA\Parameters\ and the value set to 1

Next, as indicated earlier, the RPCProxy will block access to the DC servers unless there servers are included in the ValidPorts regkey. So, set the following on the Client Access Servers

1. The ValidPorts setting at HKLM\Software\Microsoft\RPC\RPCProxy needs setting so that the entries referring to 6004 point to DC servers in addition to the mailbox server.
2. The PeriodicPollingMinutes key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\ needs setting to zero to prevent RpcHttpConfigurator from updating the Valid Ports key automatically.

Finally, you need to make sure that the DCs are listening on port 6004:

On the Global Catalog servers: a REG_MULTI_SZ  entry needs to be created on each GC named NSPI interface protocol sequences at HKLM\System\CCS\Services\NTDS\Parameters\ and the value set to ncacn_http:6004

These fixes will make sure that all directory connections bypass DSProxy and terminate at the DCs, thereby allowing the DC RPC server side component to receive both the RPC_IN_DATA and RPC_OUT_DATA connections.

There is 1 last thing to deal with in this SSL-ID load balanced configuration. Outlook profile creation hard codes a call to DSProxy on 6004. Which means that we can get split connectivity during profile creation. To deal with this minimal volume of traffic, there is 1 final regkey that should be set on the mailbox servers:

On the Mailbox Servers - set the HKLM\System\CCS\Services\MSExchangeSA \Parameters key "NSPI Target Server" to the FQDN of the DC that profile creation should use.

By using only 1 DC for profile creation, all DSProxy calls will be proxied into that single DC, once again avoiding split connectivity.

That's it folks!

Of course, subsequent releases will provide cleaner solutions for such topologies, but for now, rest assured that having gone through the above steps multiple times, I feel your pain.

That's pretty much it. I hope that adds some clarity to how Outlook Anywhere works and hasn't succeeded in confusing everyone even more.

Until the next post - Hasta Luego!

- Sid

Share this post :

There has been a lot of discussions in the Exchange ecosystem (see comments on this post and other posts on our blog for example) about the fact that Windows Server 2008 built-in backup application (Windows Server Backup) is not Exchange-aware. Even though we have also clarified that the limitation does not apply to Windows Small Business Server 2008, we still kept getting a lot of open and honest feedback on the subject, which we greatly appreciate.

Background

About 2 years ago, when the Exchange team started testing Exchange 2007 on Windows 2008, we found that the built-in backup application had changed dramatically. Decisions that drove that change by the Windows team are not the subject of this post, but it is fair to say that the Windows team did not make the decision lightly.

When we evaluated the features of Windows Server Backup, it was clear that the backup and restore experience on Windows 2008 would not be the experience that existing Exchange customers have been used to for so long. Because we had feedback from several customers who told us they would rather get a more full-featured backup solution for their Exchange servers, a decision was made not to provide an Exchange-aware backup solution for Windows 2008 in Exchange 2007 Service Pack 1.

Exchange 2007 Service Pack 1 Ships...

Right after we shipped Service Pack 1, we started hearing from customers who were upset with the fact that they cannot take Exchange-aware online backups with Windows Server Backup. These customers had enjoyed the integration of Exchange and Windows Backup (NTBackup) for many years, and for many versions of Exchange and Windows. We also saw quite a but of discussion activity on this issue in various Exchange communities (this blog, internal discussion groups, MVP and MCT communities, etc.).

We then published a blog post on this issue, which prompted more comments from customers who told us that they were unhappy about this and why.

Now - the next question you have must be:

What are we doing about this?

Although we can't share all of the details now, we thought that this issue was important enough to announce a decision we recently made. We have decided to develop and release a VSS-based plug-in for Windows Server Backup that will enable you to properly backup and restore Exchange 2007 with a built-in Windows 2008 backup application.

While you will be able to backup and restore Exchange 2007 on Windows 2008, you should not expect feature parity with the Windows 2003 NTBackup experience. There will not be the same level granularity and control that NTBackup provides and backups will be limited to the local server only. However, you will be able to perform a VSS backup of Exchange to a separate disc or a network share. If the backup completes successfully, it will (depending on options chosen) truncate Exchange transaction log files, and you'll be able to restore Exchange data when needed.

We will cover all of the details in updated documentation when the time comes. We realize that this may not be an ideal solution for all organizations, but we are quite confident that this is a good solution for many, especially our smaller customer segment.

When can you expect this?

We do not have a release date to announce yet. Our Customer Experience team is working out the details, and because we are still relatively early in this process, we cannot commit to a specific date yet. Rest assured - we'll announce it when it becomes available!

Finally, I think it is in order to thank all of you for all the feedback that you have provided us. As we mentioned before, we want your feedback. We are lucky to have people passionate enough to let us know and explain why what we did was not ideal.

- Nino Bilic

Share this post :

Recently we have published the updated Exchange Developer Roadmap over on Exchangedev blog. This covers Exchange Server beyond Exchange Server 2007. You can read about multiple things there, including:

• APIs that Will Be Removed
• APIs Moving To Extended Support

If you are developing for Exchange Server, please make sure to check it out.

- The Exchange Team

Share this post :

Please go to our Mailbox Server Role Storage Requirements Calculator updates tracking page to see what is in this new version! There are a lot of usability improvements as well as a whole new section on Storage Design.

A blog post explaining the calculator (updated for this new version) is here and the calculator can be downloaded from here.

Comments welcome!

- Ross Smith IV

Share this post :

Every so often, a question comes up for us that are running this blog: how do you do it? What is the process that you follow for your blog posts? Where do you get ideas from?

Recently - as part of the INTERACT2008 conference, I had a chance to present on this subject to Exchange/UC bloggers. I then made a mental note that we should talk about this on the blog too. After all - there is nothing top secret here and I believe you (our readers) might enjoy it. So let's get started:

Where do we get ideas from?

Ideas for blog posts fall into several categories (listed below). The subjects that we post about are also quite influenced by our release cycles. For example - just before we have a major release (like Exchange 2007 or SP1) you can fully expect that we'll be talking about that major release a lot. We do this because we are trying to make you comfortable with the technology and also to provide the information you need so that when the product is released, you have extra resources that are easy to find.

I have tried to put the overall idea sources categories in the order of "how many" we get from which source. As explained above, that can vary heavily:

• Blog audience - this is stuff you submit to us using this page. We love those. Keep it up!
• Support organization - we work closely with support folks to get clarifications, alerts, solutions of current issues etc.
• Individual employees - those are "one-off posts" where any internal Exchange-related individual can write something up and submit it for posting on the blog. A lot of "pre-release" posts fall into this category, where various Devs, PMs or Beta engineers might want to write about their components.
• Product group announcements.
• Browsing internal discussion groups and following up with authors that are specialists and are answering technical questions that we find interesting.

What process do the posts go through?

I am proud to introduce you to our Simplified Blogging Process v 11.7 Rev. IV:

Simple, huh? OK so that was a joke... now seriously, this is what we actually do:

To go a little more into those steps:

• Idea - we get the ideas as described above.
• Finding the author - Once we have identified the suggestion as a good blog post, we figure who would be the best person to write about it. Depending on what it is - this might fall anywhere from Dev to Support or Marketing. Or anywhere else in between. I don't think there is a group in our internal Exchange world that we did not tap into for content.
• Getting it written - Here's the tricky part - this consists of work on the part of the writer and sometimes the work on the part of the Blog team, as there are times when people might need a reminder or three <g>.
• Technical review - Since the Exchange team blog is a technical blog - this is super important. Every blog post gets a technical review (some get a few). Depending on the subject who the writer is as well as the release state of the product - reviewers come from specialists anywhere from Dev, PM, Support Services or - anyone else within Microsoft that is really good in the component being talked about.
• Marketing review - this is something that we usually do when we are talking about pre-release products only. For example, when we RTMed Exchange 2007, our SP1 posts went through Marketing review. But once SP1 RTMed, they did not have to anymore. The idea here is that we have to try strike the balance between what we as technical geeks want to write about and what we as a company are ready to announce or discuss at pre-release time (the decision around this usually depends on "is this feature set in stone already?"). This has been a very painless process for everyone involved.
• Posting - self explanatory... once the post is ready, it gets put into a posting queue and then it goes out when it's time comes. Rarely do we have posts that we want to hold until specific date/time but it has happened. Oh yeah, we use Windows Live Writer to post.
• Follow-up, Updates - this is what happens to the post once it has been posted. We get notifications if there are comments, and someone reads them all. Writers are engaged if clarifications or answers are needed. We might update the post at the later time based on feedback or some later change that impacts the post subject.

Note that some of the arrows in this chart go both directions. That is because posts can go both ways - if for example technical review sends the post back with a lot of changes - it goes back to the writer who makes the corrections and then it is off to technical review again.

How long does all this take? It might take anywhere from 45 minutes to few months.

That's it? Where is the red tape?

Seriously - that is it. We do not do any other stuff with posts really. There is no mandate around post subjects and we are really trying to let our readers (you!) drive that as much as possible by listening what you are asking for. There is also no editing by professional editors of everything that we post - although a couple of us that have been doing this for a while do read through all posts before posting and do go after obvious language issues or typos of course.

Hopefully this answers some of your questions you might have had on how we run this place. It has been a great ride for us and hopefully for you too. Thanks for coming! Now send us a blog post suggestion!

- Nino Bilic

Share this post :

This week, TechED 2008 IT Professionals is going on in Orlando, Florida. If you did not make it there, you can still keep up with latest and greatest news announced there by going to TechED Online site:

http://www.microsoft.com/techedonline/default.aspx

There are keynote clips, links to various feeds (News, Videos, Podcasts) - in other words, you can still learn quite a bit without traveling too.

Also, check out these blogs for information about what is going on each day at TechED:

 

Bharat Suneja's blog 
Scott Schnoll's blog

 

Scott and Bharat, along with a couple of other folks from the Exchange team, will be working hard to put up some blog posts of what is going on throughout the day, along with some interesting events they may have seen or heard about. We will also try to put up a couple of summary reports of the day's events from the perspective of these folks... stay tuned!

- Nino Bilic

Share this post :

The Exchange Server documentation team is pleased to announce updates to the Exchange Server content.

To see what content has changed for Exchange Server 2007 with Service Pack 1, take a look at Exchange Server 2007 Documentation Updates.

To see what content has changed for Exchange Server Analyzer, take a look at Exchange Server Analyzer Topic Updates.

In particular, we would like to highlight the following new or updated topics:

• Overview of Namespace Planning: Planning your namespaces involves examining your physical and logical network structure and choosing an organizational topology. This article presents several different topologies and provides information about how using the different topologies would affect your Exchange organization.
• How to Move a Client Access or Hub Transport Server to a Different Site: Added a step to set the Client Access server Autodiscover site scope due to Active Directory Site change.
• How to Perform a Dial Tone Recovery Using and Staying on an Alternate Server for the Dial Tone Database: Fixed incorrect example code by using Get-Mailbox instead of Get-MailboxStatistics.
• How to Seed a Standby Continuous Replication Target: Updated topic to specify that seeding with Update-StorageGroupCopy should be done on SCR target computer. Also, corrected permissions section that incorrectly referenced CCR.
• How to Upgrade a Single Copy Cluster to Exchange 2007 SP1: Removed step for starting Windows Firewall service, because that step is not needed.
• Planning for Cluster Continuous Replication: Removed old guidance to use DNS CNAME record for file share witness alias in UNC path.
• How to Configure the Node and File Share Majority Quorum: Removed old guidance to use DNS CNAME record for file share witness alias in UNC path.
• How to Configure Network Connections for Cluster Continuous Replication: Fixed incorrect configuration steps for the private network by specifying that Client for Microsoft Networks and File and Print Sharing need to be cleared.
• Applying Exchange 2007 Update Rollups to Clustered Mailbox Servers: Fixed incorrect statement, "The amount of downtime varies based on how long it takes each organization to perform the installation procedure for the entire cluster," by stating that the true downtime is only for as long as it takes to move the CMS between nodes and have it brought online.
• How to Configure Deleted Item Retention for a Mailbox Database: Fixed incorrect example code by using -DeletedItemRetention instead of -ItemRetention.
• Understanding How Transport Rules Are Applied in an Exchange 2007 Organization: Text added to clarify rules only have access to envelope headers in encrypted messages. "Transport rules can access envelope headers contained in encrypted messages, and process messages based on predicates that inspect them. Rules with predicates that require inspection of message content, or actions that may modify content, cannot be processed."
• Help Reference - Recipient Properties > Mailbox Settings Tab > Messaging Records Management (RTM): Removed incorrect information about pre-Outlook 2003 SP2 clients not being able to access a mailbox if Managed Folder Mailbox Policy is applied to the mailbox. Modified to state that older clients do not support Managed Custom Folders (similar text as seen in dialog box when a policy is being applied).

You can see these articles and other Exchange Server documentation content in the Microsoft Exchange Server TechCenter.

The following downloads are also available for SP1 content:

• Microsoft Exchange Server 2007 Service Pack 1 Help
• Microsoft Exchange Server 2007 Service Pack 1 Shell Help

BTW, if you haven't noticed, all our topics in the Exchange Library now have a "Topic Last Modified" date at the top of the topic. And, if you wonder which topics apply to Exchange Server 2007 with Service Pack 1, we now have an "Applies to" tag for Exchange 2007 content.

You can now annotate topics in the Exchange Server 2003 and Exchange Server 2007 documentation. Scroll to the Community Content section at the end of any topic in the Exchange Server Library, and click Add Community Comment. You'll be asked to sign in with your Windows Live ID and to register as a participant. Then, share your insights with the Exchange community.

- Cathy Anderson, Content Release Manager, Exchange User Documentation

Share this post :

If you've wanted to know more about why high item counts and restricted view requests can impact the performance of your Exchange environment, we've just released some detailed information about the behavior you may see as item counts in your critical path folders grow. Critical path folders include the Calendar, Contacts, Inbox, and Sent Item folders. Restricted views are data views that restrict information based on search criteria that result in views of only a subset of items in a folder. Performance issues related to these situations are frequently related and can become visible to end-users in the form of slow client access and the dreaded RPC dialog-box popping-up. It only takes a few users who have abnormally high item counts in their critical path folders to cause performance issues which are felt throughout your whole Exchange organization. Learn more about the issue in the topic Understanding the Performance Impact of High Item Counts and Restricted Views: http://technet.microsoft.com/en-us/library/cc535025(EXCHG.80).aspx

- Tom Di Nardo

Share this post :

...YOU.

We've just opened up the Exchange 2007 product library to community annotation.  That gives you the ability to add content to our topics that you think others might find helpful.  The basic idea here is allow members of the Exchange community to share their knowledge and experience by adding relevant information to specific topics.

The process is straightforward:   The first time you click on the "Add Community Content" link at bottom of a topic (shown in the screen shot below), you'll be asked to register as a participant (you sign in with your Microsoft Live ID).   From then on, you'll be able to add information about topics that you feel others would benefit from having.   Within moments of typing in an entry, you (and everyone else reading the topic) will be able to see your contribution as entered on the page.

Here is the page section you should use for this (click to see bigger version):

By the way, this new annotation option isn't intended to replace the existing content feedback process.   That process (see the five-star widget on every page that reads "Click to Rate and Give Feedback") is still the best way to let us know whether a particular topic has or hasn't been helpful, and why.  Our Exchange UE team reads and evaluates all the feedback it gets through that channel, and a lot of our content improvements originate that way.  Microsoft people will be reviewing the Community Content for appropriateness, but not to identify content bugs. 

Keep in mind, too, that when you have a specific Exchange question that you haven't found answered in the core content, you can log on to an Exchange forum and pose your question directly to others working with Exchange.

So-to summarize: Continue to use the feedback chrome to rate and critique our content.  When you can't find an answer to your question in the core content and you need the information quickly, go to an Exchange forum and ask your question directly.   And when you've got valuable information to share on a particular topic, consider adding it via the community annotation option. 

Thanks.

- Tim Lulofs

Share this post :

This has been discussed / asked about several times on this blog (namely in various posts comments) - so I wanted to make sure you knew that this was now released. You can find the download here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=94274318-27c4-4d8d-9bc5-3e6484286b1f&DisplayLang=en

This is of course an optional component, not everyone needs it. If you have been waiting for the package that installs on Windows 2008, the wait is over.

Thanks for the tip, Scott!

Update: I also just learned that Stephen Griffin has documented a lot of tips about this release on his blog. Check it out.

- Nino Bilic

Share this post :

This blog post discusses several top issues seen to date by the Microsoft Exchange Product Support Team regarding the Standby Continuous Replication (SCR) feature introduced in Exchange 2007 Service Pack 1. We wanted to share this information as it can be used as a preventative measure as well as for resolving issues you may have experienced. It is understood that this will not cover all that can possibly go wrong, but it should give you some good pointers in some situations that you might have seen.

For basic configuration information on SCR, please review the following article available on Microsoft TechNet: Standby Continuous Replication

Issues covered here include:

• Enable-StorageGroupCopyStatus -StandbyMachine reports error "Another standby continuous replication source is already configured..."
• SCR Target Log Files Fail to Truncate After the TruncationLagTime is Surpassed
• SCR does not replicate logs in a disjoint namespace scenario
• Database seeding error: Error returned from an ESE function call (0xc7ff1004), error code (0x0)
• SCR Hidden Network share not created in a Cluster with Event id 2074

Enable-StorageGroupCopyStatus -StandbyMachine reports error "Another standby continuous replication source is already configured at <path to Storage Group logs> for 'CopyLogFolderPath'."

Possible Causes 

The SCR target server may be using the same log file path as the SCR source server.  This can happen when attempting to enable SCR on the First Storage Group.

Resolution 

Change the log file, system file paths on the Storage Group and database path on the Mailbox database to another location on the SCR target server.  Note: In order for the file path change to take effect the databases in the Storage Group will be temporarily dismounted and then remounted.

Step-by-step instruction

This can be done from the Exchange Management Console or through the Exchange Management Shell.  For specific instructions, please click the following links:

How to Set or Change the Location of Storage Group Log Files
How to Set a Database File Location

SCR Target Log Files Fail to Truncate After the TruncationLagTime is Surpassed.

Possible Causes

The SCR log file truncation time is set to a value over 24 hours.

Resolution

Set TruncationLagTime to 0.0:00:00 minutes and then restart the Microsoft Exchange Information Store and Microsoft Exchange Replication services.  Next, take a backup of the Storage Group on the SCR Source server and then confirm that SCR Target log files get truncated after successful backup.  After SCR target files truncate properly, you may change the TruncationLagTime to your desired values.

Note: This issue will be addressed in a future rollup for Exchange 2007 Service Pack 1.

Step-by-step instruction

In order to change the TruncationLagTime, you must disable SCR and then enable SCR using the desired values.  For specific instructions, please click the following links:

How to Disable Standby Continuous Replication for a Storage Group
How to Enable Standby Continuous Replication for an Existing Storage Group
How to Enable Standby Continuous Replication for a New Storage Group

SCR does not Replicate Logs in a Disjoint Namespace Scenario

Possible Causes

The SCR source and the SCR target servers have FQDNs with disjointed domain names

Resolution

Issue will be fixed in a future rollup for Exchange 2007 Service Pack 1.  To resolve this issue, contact Microsoft Customer Support Services to obtain fix 951955.

More Information

Understanding Disjoint Namespace Scenarios with Exchange 2007

Database Seeding Error: Error returned from an ESE function call (0xc7ff1004), error code (0x0).

Possible Causes

Windows firewall settings are blocking the command

Resolution

Add the "Windows PowerShell" to the Exceptions list under Windows Firewall settings.

Step-by-step instruction

Add a Program to the Exceptions List

SCR Hidden Network Share is not created in a Cluster with Event id 2074

Possible Causes

Resources in the default Cluster group, such as Cluster IP Address, Cluster name and Quorum disk were moved to a different cluster group.

Resolution

Move the Cluster IP Address, Cluster name and Quorum disk to the default Cluster group.

Step-by-step instruction

Best practices for configuring and operating server clusters

If you experience failures other than those listed here, look at the event log on both nodes to determine the cause and use the information in the logs to determine what recovery steps need to be taken.  You can also review other events that occurred around the same time that the failure occurred to help assess if they could be attributed to the issue.

Here are some How-to Webcasts on SCR configuration created by Scott Schnoll:

SCR in Exchange Server 2007 SP1 - Part 1
SCR in Exchange Server 2007 SP1 - Part 2
SCR in Exchange Server 2007 SP1 - Part 3
SCR in Exchange Server 2007 SP1 - Part 4
SCR in Exchange Server 2007 SP1 - Part 5

- Gurpreet Erickson

Share this post :

Recently we've seen some cases in Exchange Support where the error event 623 gets generated immediately at the start of the Information Store service.  So far we've only witnessed this on some Exchange 2003 Servers. Please note that this is specifically about this event being generated after the IS start. There were other causes of even 623 that we had fixes for already.

When this behavior occurs, you may see the Information Store appear to take upwards of 45 minutes to fully respond at service startup.  Monitoring "Version Buckets Allocated" (viewable with Show Advanced Counters - see Nageshs' excellent post here:  http://msexchangeteam.com/archive/2006/04/19/425722.aspx) will show the Store is immediately running high (over 70%) and until the number falls the Information Store will be unresponsive to clients and ESM.  After Version Buckets Allocated falls, the server responds fine and no other issues are observed.  623 errors go away.  Restarting a 3rd party server that ties into users' mailboxes (if present) or restarting the Information Store service may cause the issue to occur again.

This problem occurs because of a large amount of hidden search folders that have been created by applications (other than Microsoft Exchange) that have access to users' mailboxes. When the Information Store starts, it becomes available to the host of 3rd party applications which might reconnect and want to sync the contents of the search folders at the same time. These search folder updates can then result in the search folders for a user's mailbox to all be updated at the same time.  When a mailbox has a large item count in the Inbox folder (more than 5,000 items) you can experience higher than normal store CPU % utilization and Version Buckets Allocated spikes which can lead to version store out of memory problems. Depending on the type of search performed, the impact can be greater or smaller.  Once version store cache has been depleted, the offending transaction gets canceled or it times out and is rolled back and everything moves along as if nothing happened.  That's why the event 623 eventually corrects itself.

To avoid this scenario, there are a few things you can do to monitor this:

1. Keep your Inbox item count down to 5,000 or less.  In some cases with this problem we've seen 60,000 to 80,000 items per user Inbox. To find out if you have a problem like this, we suggest you use the Exchange Server Profile Analyzer tool which we blogged about here.
2. Keep an eye on the number of search folders querying against the Inbox folder. This will require you to run ISINTEG on your server (please see below for what exactly to look for). Most people don't realize is that some third party applications that plug into Exchange (for example Fax servers, Mobile device synch servers, Unified Messaging clients, desktop search clients) create hidden search folders and restricted views. Each time a change happens in the folder that is being monitored (an modification, deletion, addition) - backlinks to the search folders are looked at and we will evaluate each search folder to see if this new items meet that set view.
3. It is possible that when 3rd Party products are upgraded older versions of search folders are not cleaned up as well.  In some cases we've seen users with well over 150 hidden search folders.  Just a few users with high item counts in their Inbox and this many hidden search folders can cause some serious trouble for your environment.

So - how do you do #2 above?

You'll have to run: isinteg -s servername -dump -l logfilename

Then open up the "logfilename" file and look for the following:

[7412] Folder FID=0028-00000002451E
Parent FID=0028-00000002451B
Root FID=0028-00000002451A
Folder Type=1
 Msg Count=29232
Msgs Unread=112
Msgs Submitted=0
Rcv Count=4
Subfolders=0
Name=Inbox
Comment=
Restriction=
 Search FIDs=0028-000008859B57,0028-000008859B60,0028-000008859B67,0028-000008859B54,0028-000008859B5D,0028-000008859B59,0028-00000C8C48C3,0028-000008859B4E,0028-000008859B4C,0028-000008859B58,0028-00000C8C2DF3,0001-0000001995E3,0028-000008859B55,0028-000008859B5E,0028-000008859B53,0028-000008859B4D,0028-000008859B4B,0028-00000C649EB1,0028-00000C8C48E5,0028-000008859B66,0028-000008859B69,0028-000008859B56,0028-000008859B5F,0028-00000C64A1EA,0028-000008859B65,0028-000008859B50,0028-00000C8C48D6,0028-000008859B5A,0028-000008859B64,0028-00000C8C48CE,0028-000008859B52,0028-000008859B4A,0028-000008859B68,0028-000008726E8B,0001-000000197413,0001-000000197C59,0001-000000198A12,0001-0000001CF526,0001-0000001CF53B,0001-0000002284E0
Scope FIDs(search folder only)=
Recursive FIDs=
 Search Backlinks=0001-000000031BEA,0028-000006CD9DC2,0028-000007594A53,0028-0000075DEE07,0028-00000857AB81,0028-00000A027DBC,0028-000008726E8B,0001-000000198A12,0001-000000197C59,0001-000000197413,0028-00000C8C48D6,0028-000008859B59,0028-000008859B55,0001-0000001995E3,0028-000008859B69,0028-000008859B66,0028-00000C8C48C3,0028-000008859B67,0028-000008859B65,0028-000008859B64,0028-000008859B68,0028-000008859B57,0028-000008859B53,0028-000008859B50,0028-00000C8C48CE,0028-00000C8C48E5,0028-000008859B4B,0028-000008859B52,0028-000008859B4D,0028-000008859B58,0028-000008859B5E,0028-000008859B54,0028-000008859B5A,0028-000008859B56,0028-000008859B4E,0001-0000001CF526,0001-0000001CF53B,0028-000008859B4A,0001-0000002284E0,0028-00000C8C2DF3,0028-000008859B5D,0028-00000C64A1EA,0028-000008859B60,0028-000008859B5F,0028-000008859B4C

What we're looking at here is a high number of Search folders (Search FIDs above) and Search Backlinks that - when they have to generate or update - have to scan over 29000 items each (MsgCount above). This is the crux of the 623 version store problem at startup that you might be seeing.

At this time, we do not have a simple solution for this problem... If you have this problem and have identified it using the above step #2 (as situation described in step #1 can be solved by reorganizing the folders/number of items), please contact our Exchange support line. Once we have a better way of resolving this, we'll post about it here.

For more information on Search Folders, review:

KB260322 - How To Search Folders with the SetSearchCriteria Method http://support.microsoft.com/kb/260322/en-us

Best Practices for Exchange 2003 Search Folders (there are several subsections here to look at as well)
http://technet.microsoft.com/en-us/library/aa997533.aspx

Creating Search Folders:
http://msdn.microsoft.com/en-us/library/ms878645.aspx

Exchange Store Search Folders:
http://msdn.microsoft.com/en-us/library/aa123899.aspx

- Jeff Stokes, Dave Goldman, Michael Blanton

Share this post :

We've just redesigned the homepage of the Exchange TechCenter to give Exchange administrators a single place to start when they're looking for information about Exchange. We're pretty confident that you're going to find it easier to get where you want to go by beginning at this redesigned homepage.  That should be true whether you need a quick answer to a specific question; are doing heavy-duty planning and research for, say, a large deployment; want to read the feature articles for the current month; or just want to catch up with the Product team to see what's going on in the Exchange ecosystem.

In our redesign we placed the things we think you're most interested in front and center.  So, for instance, there's now a search box in the left pane where it's hard to miss; search queries entered here will scour the core product documentation in the Exchange TechCenter library, the events and errors database, KB articles, and other Microsoft collections for relevant content.  There's a link to "You had me at EHLO" (this blog) on the homepage now, and you can get to Exchange forums, downloads and webcasts with one click.   The Exchange MVPs also get some face time here, via a rotating display and a link to their dedicated page. 

More changes are on the way.  But for now take a look-and consider adding the homepage to your favorites list. We think you'll probably use it a lot.  And let us know what you think about the changes!

- Tim Lulofs

Share this post :

Finally, we have the results of our comics contest. We know that the suspense has been killing you.

Without further ado, here are our favorites. We got many great submissions, choosing was a bit tricky.

The overall winner is Danny Mills:

The following 4 winners will also be getting Exchange swag:

Petrenyi Jozsef... Petrenyi has chosen to go for full-drawing style rather than use our templates; please click on the thumbnails to see them in full resolution!

Tony Woodruff:

Jeremy Wood:

Kale Davis (click on it to see the whole thing):

Thank you for all your submissions! We will be contacting the winners for their snailmail address or the address confirmation before we send out the swag.

- The Exchange Team

Share this post :

Hi everyone,

I wanted to let EHLO readers know I'll be keynoting at INTERACT 2008 in San Diego on Wednesday, April 9. We're planning a good walk through Exchange history, and then a peek into the future with Exchange Labs.

Register here with code EXCHANGE08.

I hope to see you there!

Thx,

Terry

Share this post :

I am sure many of you might have seen the issues that can be caused by the Windows Scalable Networking pack and incompatibilities with certain NIC drivers, as previously mentioned in http://msexchangeteam.com/archive/2007/07/18/446400.aspx.

As of yesterday, there is a new High Priority Windows update available that will turn off of the Scalable Networking Pack features once it is installed. If you have Windows Update setup to receive updates automatically, this update will be downloaded and automatically installed.  If you need to manually apply the update, you can reference http://support.microsoft.com/?kbid=948496 for more information as well as a link to the download. Note: Once this update is installed, you must reboot your server for these changes to take effect.

I would highly recommend applying this update to all Windows 2003 SP2 servers to help alleviate some of the connectivity issues that  can occur as a direct result of having the Scalable Networking Pack features enabled, and some incompatibilities with NIC drivers that we have seen.

In Windows 2008, these features are disabled by default and can be enabled if desired.

Have a great day!!

- Mike Lagase

Share this post :

Before you can install Exchange Server 2007 SP1 on a Windows Server 2008 there are varying prerequisites that need to be installed, depending on the Exchange 2007 Server role you plan on installing. Details on how to install those prerequisites manually can be found in the Exchange 2007 SP1 documentation:

How to Install Exchange 2007 SP1 Prerequisites on Windows Server 2008 or Windows Vista

In this blog post, we wanted to share a set of XML files that you can use to simplify the process of installing those prerequisites. Please see the attached ZIP file near the end of this post.

The following XML files are available:

Exchange-Base.xml - this will install the prerequisites that are common for majority of Exchange server roles. Note: To complete the installation, a reboot will be necessary. The reboot must be done before proceeding with the remaining Operating System prerequisites that are detailed below. If the AD management tools are not installed prior to installation of IIS 7 components, there are potential issues with IIS 7 configuration that can crop up as a result, hence the recommendation for a reboot.

Exchange-MBX.xml - this will install the rest of prerequisites that the Mailbox Server role requires.

Exchange-CAS.xml - this will install the rest of prerequisites that the Client Access Server role requires

Exchange-Edge.xml - this will install the rest of prerequisites that the Edge role requires.

Exchange-UM.xml - this will install the rest of prerequisites that the Unified Messaging role requires.

Exchange-ClusMBX.xml - this will install the rest of prerequisites that a clustered Mailbox Server role requires. When compared to the previously mentioned Exchange-MBX.XML, this XML file also installs Failover Clustering.

The Hub Transport Server Role requires no further Operating System prerequisites, other than what is already specified in Exchange-Base.xml.

To run those XML files and install the OS prerequisites you need, you should run the following from the CMD line:

ServerManagerCmd -ip <path>\<Exchange-role>.XML

So to put this into real life - if you wanted to install let's say the Mailbox server role, you would first run the Exchange-Base.xml followed by Exchange-MBX.xml.

Using those XML you can also test if correct Operating System prerequisites have already been installed. For example, let say I thought I had installed the clustered Mailbox Server prerequisites. I could run the following to verify:

ServerManagerCmd -w -ip <path>\exchange-clusmbx.xml

Note: Running in 'WhatIf' Mode.
Skipping [Web Server (IIS)] Web Server (IIS) because it is already installed on this computer.
Skipping [Web Server (IIS)] Basic Authentication because it is already installed on this computer.
Skipping [Web Server (IIS)] Windows Authentication because it is already installed on this computer.
Skipping [Web Server (IIS)] ISAPI Extensions because it is already installed on this computer.
Skipping [Web Server (IIS)] IIS 6 Metabase Compatibility because it is already installed on this computer.
Skipping [Web Server (IIS)] IIS 6 Management Console because it is already installed on this computer.
Specified for installation: [Failover Clustering]

This server may need to be restarted after the installation completes.

The above tells us that all the Operating System prerequisites have been installed, except for Failover Clustering. The remaining will be skipped, since they were installed sometime in the past. It does no harm to re-run the <Exchange-Role>.xml file if some of the prerequisites have already been installed, they will simply be skipped.

You can also quickly verify the OS components that have been installed by running:

ServerManagerCmd -q

Finally, you can download the XML files from here.

- Matt Richoux, Roman Maddox

Share this post :

On March 3 at the SharePoint Conference in Seattle, Bill Gates announced that Microsoft will offer Microsoft Online Services to businesses of all sizes. Microsoft Online Services include Exchange Online, SharePoint Online, Office Live Meeting, and Exchange Hosted Filtering.  These are enterprise-class software delivered as a subscription service, hosted by Microsoft and sold with partners.

For more information about the announcement, click through to the Press Pass article on the Microsoft site: http://www.microsoft.com/presspass/press/2008/mar08/03-02AllSizeBusinessesPR.mspx

For more information on Microsoft Online Services, visit: http://www.microsoft.com/online. You can also start following the team blog: http://blogs.technet.com/msonline/.

- Paul Englis

Share this post :