Wednesday, April 27, 2005

ISA 2004 & Exchange Server 2003

Thank you to my colleague Mike Baalman for posting this link to good information on using ISA 2004 and Exchange Server 2003 together. 

http://www.microsoft.com/isaserver/solutions/exchange.mspx

 

Tuesday, April 26, 2005

RUS Error

We ran into an issue today at a customer site as described below.  Come to find out that the Display Specifier lost much of it's objects and running forestprep again will resolve this.  The issue is listed below as well as the KB875300 that describes the fix.

Issue:

Yesterday, during an install of the first E2K3 server in an existing E5.5 site, we ran into an issue.  Another E55 site showed no display name in E55.  Although this display name had been updated almost 2 years earlier.  We manually pulled E55 replication around the Org and the issue appeared to resolve itself.  The install yesterday completed without errors.  No RUS was needed and none were created.
    Today, we worked on another install of the first E2K3 server in another E55 site, which completed without error as well. However, this time when he went to create a new Recipient Update Service (RUS), the error "Invalid Argument - ID 80070057 was displayed.  We have since tried to create a RUS on two other E2K3 servers using different permissions, always with the same error.  
 

Solution:

According to KB875300, re-running ForestPrep will replace the missing Display Identifiers.

Monday, April 25, 2005

Recipient Policies and pure Exchange 2000/2003 sites

Bill Long has posted another good article on Recipient Policies in a Pure AG over at EHLO.  Take a look...

Once a site has no Exchange 5.5 servers in it, that old "Highest Priority" policy based on legacyExchangeDN isn't needed anymore. As people decommission their 5.5 servers and move to pure Exchange 2000 and 2003 sites, the question on how to get rid of the old site recipient policies often arises. This is not as complicated as people often think, but it does require some thought, depending on what exactly you want to achieve.

The logic of the RUS is fairly simple, but often misunderstood. The details of the decision-making process are documented in article 328738, and all you really need to know about throwing out your old policies is contained in that article. The basic idea is this:

- In the Recipient Policies container, you have a set of recipient policies.
- Each policy has a priority and a filter.
- The policy for each user is the policy with the highest priority (the lower the number, the higher the priority) with a filter that matches the user.
- The recipient policy only really matters in two situations. 1) The user is new and has no proxy addresses. 2) The policy has been "applied", as described in article 328738. In these two cases, the RUS stamps addresses on people. The RUS does not normally generate new address for recipients that already have them.

Preparation

Let me restate - the normal behavior of the RUS is to leave a user's email addresses alone, regardless of whether those addresses match the policy. It is not the normal behavior for the RUS to regenerate recipient addresses to force them to match the policy. The regeneration of proxy addresses only occurs when the policy is in an "applied" state. Update Now doesn't do it, nor does a Rebuild. These two options only control the scope of users that the RUS looks at - they do not affect the decision-making process that occurs for each user. You can Update Now and Rebuild all day long, and the RUS will never change anyone's address unless you have a policy in the "applied" state. This is why article 328738 is divided into two sections - one on the type of query, and another on the decision-making process.

This means that as long as none of your policies are currently applied, reconfiguring your recipient policies has no impact. Before you start making changes that will cause users to fall under different policies, though, it's a good idea to be 100% sure that no policies are applied. To do this, use ADSI Edit or LDP.EXE to go to your Recipient Update Services container and view the properties on each Recipient Update Service. Make sure that the gatewayProxy attribute on these objects is clear. This process is described in article 821743. Also, don't confuse gatewayProxy on the RUS objects with gatewayProxy on the Recipient Policies themselves. They serve two different purposes.

GatewayProxy on the RUS should only be populated for a limited amount of time. It is populated when the policy is applied, and the RUS begins processing all the users who match the filter on the applied policy. If the RUS finishes processing these users successfully, it will clear the corresponding entries from gatewayProxy to take the policy back out of the applied state. However, for the reasons described in article 821743, this doesn't always happen, and a policy may be left in the applied state indefinitely. There was also a bug in Exchange 2000, described in article 835156, where the policy would continue applying even after gatewayProxy was cleared, until the System Attendant service was restarted. This fix was included in the latest rollup for Exchange 2000.

As long as gatewayProxy is empty on all your RUS objects, and you have the article 835156 or a later fix, the RUS will not be making changes to any addresses just because a user's addresses don't match his current policy.

If you're still nervous about making these changes, consider getting an export of everyone's email addresses before you start. This is easy to do with ldifde, using syntax like:

Ldifde -d "DC=domain,DC=com" -r "(&(mailnickname=*))" -l proxyAddresses -f proxies.txt

This command line will export the proxyAddresses attribute for every mail-enabled object in the specified domain, and you can also add any other attributes you like to the -l parameter. You can use a simple script to reformat this file as an import and put all the proxy addresses back in their previous state if something goes wrong.

Creating the new policies

This is the part that takes some thought, and the solution will vary from one organization to another. If all your users should have a single addressing scheme, just configure the Default Recipient Policy accordingly and you're done. If you need several different addressing schemes, determining the appropriate filters for your new policies may take some planning. You'll need to identify an attribute on the users that distinguishes one group of people from another. Are your email addresses based on location? How about a filter based on city (the "l" attribute), or state (the "st" attribute). Are your email addresses based on department? Then maybe a filter based on that (the "department" attribute) would work. If none of the existing attributes on the users will work for you, you can always use one of the extension attributes, such as extensionAttribute1. The ADModify tool can be handy when you need to populate an arbitrary attribute on a large number of users. Once you know what attribute you want, building a basic filter using that attribute is easy:

(&(mailnickname=*)(myAttribute=myValue))

This filter matches any mail-enabled object which has the corresponding attribute value you've specified. For simple filters like this, you may find it easier to just choose Custom Search, click the Advanced tab, and type the filter in manually, instead of trying to choose all the appropriate checkboxes to do what you want.

Once you have configured your new policy, click OK, but beware! At this point, if you have changed the e-mail addresses that were specified on the policy by default, ESM will prompt you asking if you want to apply the policy. Clicking Yes will populate gatewayProxy and could cause the regeneration of email addresses on anyone who falls under this policy. It is best to choose No unless you want the RUS to go around changing addresses on people.

Deleting the mixed-site policies

Once you have your new policies done, simply use Exchange System Manager to delete the unwanted 5.5 site policies. Of course, you can do this step first if you like. Unless you've already created other policies that will match the users in those sites, they will now fall under the Default Policy. But this doesn't matter - since the Default Policy is not in the applied state (you know this because you checked gatewayProxy), their addresses will not be regenerated to match it.

Verification

After your old legacyExchangeDN-based policy is deleted and your new policies are configured, you're done. If you want to verify your policy configuration, you can run a Rebuild. As the RUS processes each user, it will update their msExchPoliciesIncluded to reflect the objectGUID of the policy they fall under (though, again, it will not update their proxyAddresses to match this policy as long as you have not applied the policy). You can look at the GUIDs stamped in msExchPoliciesIncluded to verify that the users are getting the policies you intended. However, keep in mind that a Rebuild can take hours or even days in the largest environments, so carefully consider this before running a Rebuild. Another option is to just make changes to a few select users. Change their Description, Zip, or anything you like. The RUS will evaluate them and stamp the new msExchPoliciesIncluded value.

As a general rule, it is not a good idea to have users fall under a policy that their addresses don't match. Someday, someone is going to apply your policies if only by accident or as a troubleshooting measure. If you want to manually configure email addresses on users and never have them be affected by applying a policy, it's best to go to the Email Addresses tab and clear the "Automatically update e-mail addresses based on recipient policy" checkbox. Once you do this, the RUS won't touch that user's email addresses even if you apply the policy. This is another operation that can be automated for a large number of users by using ADModify.

Enable Remote Desktop Remotely!

Have you ever needed to connect to a Windows Server 2003 machine only to find out that Remote Desktop or TS is not configured or enabled?  Mitch Tulloch has a solution that is shown in detail at Windows Server Hacks: Remotely Enable Remote Desktop.

Remote Desktop is a cool feature of Windows Server 2003 that lets you remotely log on to and work at a machine as if you were seated at the local console (in Windows 2000 Advanced Server, this feature was called Terminal Services in Remote Administration Mode). Remote Desktop can be a lifesaver for fixing problems on servers at remote sites, but what if you forgot to enable the feature before you shipped the server out to Kalamazoo? Enabling Remote Desktop is easy if the server is in front of you: just log on as an administrator, open System in Control Panel, select the Remote tab, and under Remote Desktop select the checkbox labeled "Allow users to connect remotely to this computer." Unfortunately, you can't use the System utility to enable Remote Desktop on a remote machine, though you can access some properties pages of System using Computer Management by first connecting the console to a remote computer, then right-clicking on the root node and selecting Properties. Unfortunately...

Tuesday, April 19, 2005

Scripting Exchange Part Two

MSExchange.org - Scripting Exchange Using VBScript and ADSI (Part 2)

"The first part of my scripting series discussed ways of accessing and searching for Exchange objects such as users and contacts in Active Directory. This second part of the series will go over creation of a new object, and over the most important attribute of an Exchange recipient, the e-mail address."

 

Exchange 2003 Utilities Updated

A few of the Exchange Server 2003 utilities that Microsoft provides have been updated and published to the downloads area of their site.

Exchange Server 2003 Jetstress Tool

Exchange Server AUTD Binding Cleanup

Exchange Server Load Simulator 2003 (LoadSim)

Exchange Server MSSearch Administration Tool

Update: The reference to NAS support on the Jetstress download page has been removed.  Thanks to Matt Lathrum.

 

Exchange Server User Monitor Tool

Microsoft has released another utility for our toolbox: the Exchange Server User Monitor Tool

It must be installed on the Exchange Server you want to monitor users for and requires Exchange 2000 sp2 (or later) or Exchange 2003 sp1 (or later).

You can read more about ExMon at the Exchange Team blog and of course in the documentation.  Even though it has been released as an installer package, it is really just a self extracting file.

William Lefkovics

Updated Exchange MP Configuration Wizard

For those using MOM 2005 to manage Exchange, note that Chris Harris of Microsoft advises that a new version of the Exchange Management Pack Configuration Wizard has been released.

The update fix list includes:

1.  Crash due incorrect resource string when there is an error setting the messageTrackingEnabled property on the AD (Error msg: Index (zero based) must be greater than or equal to zero and less than the size of the argument list.)  This update means you no longer have to apply the .NET update for the Wizard to properly enable Message Tracking.

2.  A valid domain is reported as not valid for the Mailbox Access Account if domain uses DNS in other forest (Error msg: "Invalid domain for the mailbox access account")

3.  DCR: Wizard does not support NetBIOS domain names containing a period (.)

4.  Wizard incorrectly matches a valid list of services to monitor if more than one service is inside double-quotes

5.  Wizard incorrectly assumes that the AD schema has been extended for Exchange 2003 when configuring Exchange 2000 servers

 

IBM In Denial Over Lotus Notes

The marketing folks in IBM's Lotus division are starting to sound like the Black Knight in Monty Python and the Holy Grail, who insists he's winning a fight even as he loses both arms and legs: "'Tis but a scratch," the Black Knight declares after one arm is lopped off. "Just a flesh wound," he says after losing the other. "I'm invincible!"

The same goes for IBM's Lotus, which keeps declaring victory even as Microsoft carves it up. First Microsoft consumed Lotus's 1-2-3 spreadsheet business. Lotus spinmeisters insisted Microsoft wasn't really winning because Lotus 1-2-3 still had a larger installed base. Eventually that wasn't true either. Now Microsoft's Exchange has clawed its way to the top of the corporate e-mail market, displacing Notes/Domino, which once dominated e-mail and was the main reason IBM paid $3.2 billion to acquire Lotus in 1995.

Exchange, first released in 1996, now outsells Notes/Domino and has a larger installed base and more momentum, many analysts say.
Yet IBM still claims Notes is the "best-selling" e-mail product on the market. And the rah-rah Lotus faithful--consultants who make a living by maintaining Notes and writing specialized Notes applications--promote this version of reality to their customers. (IBM declined to comment for this article.)

Conceived in 1984 and introduced in 1989, Notes has a user interface that some consider dated and overly complex. The product is also costly to operate, some say. Even IBM seems to think something new is needed. It has developed an e-mail program called Workplace Messaging, which is part of a new family of software products. IBM says Workplace Messaging won't replace Notes. Instead, IBM says Notes will, ahem, evolve and become part of the Workplace family. The truth is that the spin is aimed at keeping Notes customers from dropping Notes and switching to something else.

Meanwhile, Notes consultants have resorted to bashing market researchers who say Notes is slipping, suggesting on blogs that these analysts are extreme outliers who lack credibility and/or are shills who were paid off by Microsoft. But the fact is that all but one of the top market research firms say Microsoft Exchange is now the leading e-mail product. Even Gartner Group, the lone holdout, says IBM maintained a mere 1.8% market share lead--but that was in 2003.

Nevertheless Notes zealots cling to this Gartner statistic, touting it to support their "We're number one" rhetoric.

For the record, here is a rundown of analyst opinions:

  • Gartner: In 2003 Gartner estimates IBM had a 46% share of e-mail sales vs. 44.2% for Microsoft. The firm won't comment on 2004 sales yet.
  • IDC: In 2003 Microsoft outsold IBM $770 million v. $709 million. The final 2004 figures have not been tallied but the preliminary estimate is that "Microsoft will go up and IBM will go down. The delta is growing," analyst Mark Levitt says.
  • Ferris Research: Microsoft has a 60% share of the business e-mail market vs. 25% for Lotus. Microsoft has a larger installed base and generates greater license fees than IBM.
  • Meta Group: "Exchange is picking up share, and Notes/Domino is losing share. I'm seeing more defections from Domino. There is migration from Domino to Exchange," says analyst Matt Cain.
  • Radicati Group: In 2004, Microsoft had 115 million seats installed worldwide vs. 83 million for IBM. By 2009, Microsoft will have 200 million seats installed vs. 103 million seats for IBM's Notes and Workplace products combined.
  • Info-Tech Research Group. Among midsize companies ($1 billion or less in annual sales) in 2004, Microsoft had a 33% market share and IBM had 25%. By end of 2005, Microsoft will reach 35% with IBM dropping to 18%. "A lot of Notes shops are looking elsewhere," analyst Carmi Levy says.

Despite all this research, IBM and its head-in-the-sand Lotus "community" insist they're still number one. Which, paradoxically, helps explain why they're not.

Future version of LCS2005 client for MS mobile platform

Looks like Microsoft is creating an IM client for a future version of Windows Mobile that will work with LCS 2005, according to Ed Simnett, group product manager at MS.  However, RIM is working on the same type of client and may beat Microsoft to the punch.

Full story here: http://news.zdnet.com/2100-3513_22-5675587.html?tag=nl.e539

Friday, April 15, 2005

How Mailbox Manager processes recipients

Here is a good post from Mike Lagase on Mailbox Manager details...

This is a part 2 of my 3 part series on Mailbox Manager, please go here to read the part 1!

There is a task (CMBCleanTask) within MAD.EXE that runs every 15 minutes and figures out if the schedule information says it is now time to run. The schedule is controlled by the attributes msExchMailboxManagerActivationStyle and msExchMailboxManagerActivationSchedule on the server object in the DS.

The values for 'style' are:

         0 = Never
         1 = Schedule
         2 = Always
         3 = Custom

If we determine that we need to run, MAD starts the Clean Mailbox function to do the actual work. When this function is called, we first look in each of the databases on the server for mailboxes.  Based on the mailboxes this process found, it then queries Active Directory to see what user has a Mailbox Manager Policy applied to them. Once the user's policies have been identified, we then, based on how that policy is configured, go in to each mailbox and clean them accordingly. Once a mailbox is processed, an email notification is sent to the end user, if configured. At the end of the process, we send the administrator report, whether it is a detailed or a summary report. This report beginning with Exchange 2000 SP3 and later is sent via an authenticated MAPI logon using LocalSystem. Versions prior to Exchange 2000 SP3 used CDO for sending this report and needed anonymous authentication on the SMTP Virtual Server to relay properly.

How do we calculate if we process a message?

This calculation is determined by the following three MAPI properties on a message. If any one of these properties is less than the limit set by the Mailbox Manager rules, then we will skip that message.

- PR_MESSAGE_DELIVERY_TIME
- PR_CLIENT_SUBMIT_TIME
- PR_LAST_MODIFICATION_TIME

For a message to be moved or deleted by Mailbox Manager, all three of the above properties need to exceed the limit that has been set on the policy. So if you have a policy that states that any message in your Inbox older than 30 days needs to get cleaned by the Mailbox Manager process, we check the above properties and if all are greater than 30 days, we go ahead and clean that message. For other message classes such as Appointments, Task, Journal items, etc., we perform additional checks and look at different MAPI properties during this cleaning process. More information regarding those other checks can be found at http://support.microsoft.com/?id=302804

When Mailbox Manager first came out back in Exchange 5.5, we based the above calculation different than what we do in Exchange 2000 or Exchange 2003. We used to base this on the PR_MESSAGE_DELIVERY_TIME of a message only. There are some instances where you would like to base the cleaning on this property alone. This can be modified by changing the value for msExchMailboxManagerAgeLimit on the Mailbox Manager policy to a value of 3. All possible modifications to this value can be found here.

Below is a listing of attributes associated with Mailbox Manager Policies:

Policy Attributes
msExchMailboxManagerAgeLimit
msExchMailboxManagerCustomMessage
msExchMailboxManagerFolderSettings
msExchMailboxManagerKeepMessageClasses
msExchMailboxManagerMode
msExchMailboxManagerSendUserNotificationMail
msExchMailboxManagerSizeLimit
msExchMailboxManagerSizeLimitEnabled
msExchMailboxManagerUserMessageBody
msExchMailboxManagerUserMessageFooter
msExchMailboxManagerUserMessageHeader

Server Attributes
msExchMailboxManagerActivationStyle
msExchMailboxManagerActivationSchedule
msExchMailboxManagerMode
msExchMailboxManagerReportRecipient

Wednesday, April 13, 2005

MS05-021: Vulnerability in Exchange Server Could Allow Remote Code Execution (894549)

This update resolves a newly-discovered, privately-reported vulnerability in Microsoft Exchange Server that could allow an attacker to run arbitrary code on the system. The vulnerability is documented in the "Vulnerability Details" section of this bulletin. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
[Microsoft Security Bulletins]

The new Windows Server 2003 TechCenter

The Windows Server 2003 TechCenter offers a key step toward improving the documentation experience by enabling authors to update content based on customer feedback. It presents views into documentation by language, technology, task (or documentation category), and documentation set. The TechCenter hosts Microsoft Windows Server 2003 technical documentation and updates (including the new Service Pack 1).


Thursday, April 07, 2005

Exchange User Monitor (Exmon) released

Introducing the Microsft Exchange User Monitor (Exmon) tool

Chris Mitchell has announced that this month's Exchange Web release contains a tool that the Exchange performance, development, and operations teams at Microsoft have used for quite some time called Exchange User Monitor (Exmon) and can be downloaded here.  Exmon for the first time allows an Exchange administrator the ability to see in amazing detail the performance of an Exchange server.  Shown on a user by user basis, Exmon allows you to see how much CPU, latency, network traffic, and disk each user on an Exchange server consumes.  It can be run in almost realtime (minute by minute analysis) or over longer (multiple-hour) capture periods.  Exmon also 'bubbles' up data sent back to the Exchange server from Outlook 2003 and higher about the user's actual experience, showing the actual RPC (network+server) latency and even the name of the process talking to the Exchange server (so you can see ActiveSync usage and other 3rd party MAPI applications).  The data Exmon exposes is the 'raw' data that many of the Exchange Performance counters use in calculating the running averages. 

Internally, this tool was used to help understand the performance of Outlook 2003 and other MAPI applications during the development of Exchange Server 2003.  We use it to understand the broad impact of performance across a server, but also to troubleshoot specific performance problems with individual users.  The impact to the server being 'traced' is minimal, allowing it to be run on very large servers. 

On a personal note, I recommend looking at a number of traces to 'aquaint' yourself with what's normal.  Exmon data can be highly dynamic in range.  It's best to use longer traces rather than smaller ones, because MAPI traffic can be very bursty, unless you're trying to look at a very microscopic level.

 

Monday, April 04, 2005

Network Monitor 3.0 beta soon

According to Neil Leslie, general manager of Microsoft Corp.'s customer service and support group, the company within six months will release a beta version of Network Monitor 3.0, an upgrade of a tool that has shipped as part of its Systems Management Server (SMS) software. What will be different in the next SMS release, Leslie says, is that Netmon won't have a "90-day time bomb" that turns off the tool unless you buy it. In other words, if you get SMS, you'll get Netmon 3.0. Free. Netmon captures and stores network packets for analysis. It can filter packets by protocol type and let you find devices on your network and track their packet-broadcasting rates. The 3.0 release adds a Visual Basic-like scripting language so you can easily customize it, says Leslie. Today, he notes, you need C and assembler language skills to do so.

Leslie says Microsoft will also make available later this year D-Code, its database of the various service and support tools that the company uses internally. The database not only lists what's what, but it also rates the effectiveness of what's what. Leslie says he wants other companies to rate their troubleshooting and analysis tools inside D-Code so the info can be shared broadly.

Saturday, April 02, 2005

Exchange Server due out in 2006

"Andy Lees, corporate vice president of marketing for Microsoft's server and tools business, revealed the ship date Tuesday."

This suggests that Exchange 12 will arrive sooner versus later.  It was previous suggested the release date might not be until early 2007.

Lees also indicated that Exchange 12 will support "both the 64-bit extensions and the dual-core technology."  I don't think that includes Itanium.

Exchange 2003/Windows 2003 sp1 Cluster Patch

This update only applies to Exchange Server 2003 clusters running on Windows Server 2003 with the recently released Windows 2003 sp1.  MS KB 841561 fixes "'500 - Internal server error' error message when a user tries to access a clustered Exchange Server 2003 back-end server by using Outlook Web Access."

SYMPTOMS

You install Microsoft Windows Server 2003 Service Pack 1 (SP1) on a server cluster. The server cluster is running a clustered Microsoft Exchange Server 2003 back-end server. You experience the following symptoms:
If a user tries to access a mailbox by using Microsoft Outlook Web Access, that user receives the following error message:
500 - Internal server error
If you log on to a client computer by using administrator rights and then try to access a mailbox by using Outlook Web Access, you are successful.
 

CAUSE

This problem is caused by some of the security enhancements that are included with Windows Server 2003 SP1.

In this scenario, when a user tries to access a mailbox by using Outlook Web Access, HTTP requests into the clustering API by impersonating the logged-on user. However, there have been security changes in Windows Server 2003 SP1. The security restrictions for the APIs that perform remote registry access have been changed. Therefore, the logon attempt is not successful.

Windows 2003 SP1 Security Configuration Wizard and Exchange servers

Nino Bilic has posted this more detailed information on the SCW and E2K3... 

Now that Windows 2003 SP1 is out, I wanted to mention a tool that has shipped as part of Windows 2003 SP1. While the tool itself is not installed by SP1, the shortcut to the Help file is placed on the server desktop when SP1 is installed.

What does that have to do with Exchange? About the tool:

Security Configuration Wizard (SCW) is an attack surface reduction tool that is part of Windows Server 2003 SP1.  SCW uses a roles-based metaphor (e.g. "File Server", "Web Server", "Domain Controller", etc.) to determine the desired functionality of a particular type of server, then disables functionality that is not required for the role(s) the server needs to perform.  Specifically, SCW:

    - Disables unneeded services
    - Blocks unused ports
    - Allows further (address or security) restrictions for ports that are left open
    - Prohibits unnecessary web extensions (if running IIS)
    - Reduces Protocol Exposure (SMB, LanMan, LDAP)
    - Defines an Audit Policy

SCW guides you through the process of creating, editing, applying, or rolling back a security policy based on the selected roles of the server. The security policies that are created with SCW are XML files that, when applied, configure services, network security, specific registry values, audit policy, and if applicable, Internet Information Services (IIS).

So - really, what does all this have to do with Exchange, you ask?

There is a known issue with Exchange server installed into a non-default path (something other than %ProgramFiles%\Exchsrvr) where SCW is run and application of resultant policy might cause Exchange Server not to be accessible by clients anymore. The possible gotcha is in the "Network Security" portion of SCW which configures the Windows Firewall. This portion of SCW is used to turn on and add exceptions to the Windows Firewall. Exceptions are added by pointing the Windows Firewall to the EXE file to the application that is exempt from firewall blocking. SCW however expects those applications (in our case - services) to be in their default installation paths.

Now, before we start to get nervous, we should understand that the SCW will indicate to the Administrator if it runs into this problem. In other words - the UI will indicate there are issues with services that were "not found", and the Admin will have a chance to correct this before any changes are made to server configuration.

Once you get to the SCW part that configures Network Security, and if you are running SCW on the server that is not installed into the default installation path, you will see this:


 
In above example - the MTA Stacks, System Attendant and Store are the services that SCW expects to find in one location, but the actual EXE files are not physically there. If we continued to run SCW here and said YES to the popup that will warn you that some services were not found - after the server reboot, those services would not be accessible by their clients, as Windows Firewall would block their ports.

Please see the following article for information how to configure SCW to point to valid file locations, as well as how to recover if the server is already in the situation where services are blocked by Windows Firewall after SCW policy was applied:

896742 After you run the Security Configuration Wizard in Windows Server 2003
http://support.microsoft.com/?id=896742

There are few extra things I wanted to mention on this:

At the end of the SCW run, you will save the policy under a name you can choose. SCW lets you then take this policy and apply it to other servers in your Organization.

The possible problem here is - if the policy was created on the "default installation path" Exchange server, it will cause problems after import on the "non-default installation path" Exchange server, and vice versa. The above warnings (and a chance to correct them before policy application) are seen only during the policy creation not during the policy import.

Additionally - assuming that Windows Firewall was activated on the server and exceptions were added to the firewall policy, if administrator then adds a component or a service to the server (for example, POP3, IMAP4 or SRS are enabled) - the service will effectively be blocked from it's clients until the SCW is re-run, the added service is approved through it and policy is reapplied. Alternatively, you can manually add the service into exceptions of Windows Firewall.

I personally love the tool, but - we just have to be careful when using it!

- Nino Bilic

[You Had Me At EHLO...]

Friday, April 01, 2005

E2K3 and the Security Configuration Wizard in Windows Server 2003 SP1

A new KB article has been published for Exchange 2003 when applying Windows Server 2003 Service Pack 1.  It involves servers that the install path for the Excahnge bits were changed from the default.
 
896742 After you run the Security Configuration Wizard in Windows Server 2003 SP1, Outlook users may not be able to connect to their accounts

Interesting Exchange KB articles

Here are a couple of interesting KBs that have come out or been updated recently:

KB.884863 (http://support.microsoft.com/kb/884863) – “Update to Exchange 2000 Server adds application event logging for deletion of public folders”

An additional feature that is related to public folder diagnostics logging is now available for Microsoft Exchange 2000 Server. When you use this new functionality, an event is generated in the Event Viewer Application log when a user deletes an Exchange 2000 public folder. If the Public Folders General category is set to Medium logging or higher, an event that similar to the following will be logged when a user deletes a public folder in Microsoft Exchange 2000 Server:

Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category: General
Event ID: 9682
Description: Folder /Name_of_Public_Folder with folder ID 9-9999B was deleted by /o=Exchange_Organization_Name/ou=Exchange_Site_Name/cn=Recipients_Container/cn=User, user account Domain\NTAccount_Name.
 
Note, you can also get this hotfix for Exchange 2003 Post-SP1 by referencing KB.891968 with PSS.
 
 
KB.895847 (http://support.microsoft.com/kb/895847) – “Multi-site data replication support for Exchange 2003 and Exchange 2000”
 
You can use replication technology to help provide high availability for Microsoft Exchange Server 2003 or Microsoft Exchange 2000 Server data. Exchange 2003 and Exchange 2000 replication solutions are provided by third-party program vendors. This article describes our support policies for Exchange when Exchange is used together with a third-party replication solution.
 
(Translation: this is the definitive “Exchange on replicated storage” KB article. It covers synchronous replication, asynchronous replication, software replication, Geo-clusters, you name it!)
 
 
KB.175481 (http://support.microsoft.com/kb/175481) – “Exchange single-instance storage and its effect on stores when moving mailboxes”
 
This KB article about single-instance storage behavior during mailbox moves (ie – that we keep it if you use the built-in move process) has been updated to include the cross-site mixed-mode Exchange 2003 SP1 feature. The article clarifies that these cross-site moves also retain SIS, unlike the old “Exmerge” method of moving mailboxes cross-site.