Turning on the "larger than 16GB" feature of Exchange 2003 SP2

I learned an interesting tidbit of information from John Savill's Windows Tips & Tricks FAQ (www.windowsitpro.com). The feature of Exchange 2003 Service Pack 2 that allows a database to be larger than 16GB is NOT enabled by default. There is a Registry value that you need to create to define the maximum database size. In my example, the server name is HNLEX01. Locate the following registry key in HKLM\SYSTEM\CurrentControlSet\Services

\MSExchangeIS\HNLEX01\Private-GUID

The value of GUID is a unique identifier for that particular database and will be different for each installation. For Exchange 2003 Standard Edition, there will only "Private" GUID, though.

Create a REG_DWORD value called Database Size Limit in GB. Set the new value to a value between 1 and 75GB. Remember that the default entry field for REG_DWORD values is hexadecimal, so remember to click the Decimal radio button. If this key does not exist, then the default database size will remain at 16GB.

There is another registry value that you can create that defines a warning level above which the an event will be logged if the database exceeds a remaining percentage of its maximum size. In the same registry key as above, create a REG_DWORD value called Database Size Buffer in Percentage and set it to between 1 and 100 percent. (Once again, remember the default for this interface is hexadecimal, so remember to click the Decimal radio button.) The default is 10, which means when the database has only 10% of its available size left, you will start seeing warnings in the event viewer. These warnings are generated at 5:00AM, by defaut, but you can define a registry value (in the same key as the two above values) that defines an offset from midnight at which a warning limit is generated. Create a REG_DWORD value called Database Size Check Start Time In Hours From Midnight and set it to a value from 1 to 23 (in decimal). While John Savill's FAQ did not say whether or not the store needs to be dismounted and remounted for this to take effect, I'm betting it does.

Remember that Exchange 2003 Service Pack 2 is still in beta and should NOT be installed in production. I am not sure in the final release of Exchange 2003 SP2, if the database size will automatically be extended to 75GB of if you will have to do this via registry.

If your Exchange 2003 Standard Edition database has exceeded 16GB and Service Pack 2 is not yet available, you can temporarily extend the size of the database by 1GB. See Microsoft KG article 813051: How to temporarily increase the Exchange 2000 16-gigabyte database size limit.

Firefly - The Series

I'm hooked! A few days ago, a friend lent me the first DVD from Joss Whedon's Firefly - The Complete Series. Wow! What a great TV series! And what a shame that Fox cancelled it after only showing 11 episodes. Another example of the TV networks assuming that the viewing public has the attention span for nothing more than reality (hack, hack, cough, cough) TV series. I just ordered the entire set for myself after watching the pilot twice and the first two regular episodes. The cast forms a perfect ensemble, the characters are well developed and likeable, the technology is interesting, and the view of humankind 500-years in the future is fascinating. I never thought I would see people riding up to a spacecraft on horseback or a spacecraft flying over a train.

Error in Active Directory Users and Computers when updating e-mail addresses

In the environment in which I'm currently working, the OU admins in Active Directory have "Exchange View Only Admins" permissions to their respective Exchange admin groups. We have started seeing a problem when modifying e-mail addresses. When an OU-level admin modifies an e-mail address such as an SMTP on the user's E-Mail Addresses property page (using Active Directory Users and Computers), they get the following error message:

Microsoft Active Directory - Exchange Extension
An Exchange Server could not be found in the domain.

Check if the Microsoft Exchange System Attendant service is running on the Exchange Server.

ID no: c10308a2

Microsoft Exchange Directory - Exchange Extension

OR

There is no such object on the server
Facility: Win32
ID no: c0072030
Microsoft Active Directory – Exchange Extension

OR (updated on 10 Sept 2006)

There are no bindings.
Facility: Win32
ID no: c00706b6
Microsoft Active Directory - Exchange Extension

I'm not sure why the difference in errors occured, as I have had both reported to me for the same problem, but I suspect it is the difference between the E2K3 and E2K3 SP1 ADUC extension.

I did not not realize this, but the ADUC Exchange extension contacts an Exchange server via RPC when you modify an e-mail address. It does this to verify the validity of formatting on the particular type of address you are creating.

These problems started once the Exchange 2003 servers were updated to Windows 2003 SP1. Apparently, this has something to do with the services control manager and the DCOM/RPC security hardening that was done in Windows 2003 SP1. Here is a blog entry I read about this: Fun with changing E-Mail Addresses

I found very little data on the Internet about this, but I did find one thread that seemed to be relevant: Could NOT change mail address after windows server 2003 sp1

This article suggested running a program against the Windows 2003 server that would adjust the necessary permissions for the Distributed COM Users group. However, being a little uncomfortable with this solution, I wanted the "official" Microsoft, supported solution. Here is what PSS recommended.

Edit the Default Domain GPO, in the Services portion of the GPO, set theMicrosoft Exchange System Attendant service to start automatically and then set Security on this service so that your groups that have been delegated Exchange View Only Admins permission will also have the "Read" and the "Write" permissions on this service. (You will need to edit the GPO from an Exchange server in order for the Exchange services to show up properly in the Services section of the GPO. I was not crazy about this solution and I'm still now sure why it is necessary to put this in the Default Domain GPO rather than a GPO that just applies to the Exchange Servers OU. However, I tried this by editing ONLY the GPO that applied to the Exchange Servers and it did not fix the problem.

In the middle of all this troubleshooting, Microsoft released KB 905809: You receive an "ID no: c10308a2" error message when you use the Active Directory Users and Computers snap-in to remotely add or edit an e-mail address for a mail-enabled user in Exchange Server 2003.

The method that seems to have ended up fixing this is Method 1 in this KB article. Make sure that you have v5.2.3790.1830 of the SC.EXE utility. At the command prompt on each Exchange server, run:

sc sdset SCMANAGER D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

Make sure you type this command in exactly, as the Security Descriptor Definitation Language (SDDL) must be typed in exactly. You can also insert the name of the server into the SC command line and perform this task remotely.

Konfabulator makes your desktop fabulous!

If you read my blog much, you will know that I'm a gadget freak. My office at home is full of gadgets. This extends to my desktop, too. I recently installed the new Google Desktop v2 beta and thought it was the cat's meow. However, I just found a tool that Yahoo now owns called Konfabulator. Very spiffy. And lots of Konfabultor widgets that you can download and add to it. I have weather report, clock, stock ticker, picture viewer, and NY Times headline viewer widgets on my desktop. They look much more slick than the Google Desktop. For those of you that use the Mac, yes, I know, this looks a LOT like the Tiger desktop. I'm assuming this is where the concept came from.

Exchange clusters and the Microsoft Distributed Transaction Coordinator

This week there has been some discussions on one of the e-mail lists to which I describe about the proper placement of the MSDTC (Microsoft Distributed Transaction Coordinator) resource in an Exchange-only cluster. Over the past couple of years, I have seen recommendations that state that it should be in its own cluster resource group (with its own physical disk, IP address, and network name) versus putting the MSDTC resource in the Cluster group with the cluster quorum and the quorum drive. Even Microsoft's own guidance on this has been less than consistent.

First, a little background, while Exchange does not directly use the MSDTC in a cluster, it is required on a cluster during Exchange setup and service packs. Therefore, the MSDTC is really used less than 1% of the time in a cluster.

Thanks to this lively discussion, the Microsoft documentation (including the Exchange High Availability Guide and the Deployment Guide) as well as a few KB articles are going to be updated to reflect Microsoft's recommended Best Practices.

So, the best practice for the MSDTC is to put it in the default Cluster Group with the cluster name resource, cluster IP address, cluster quorum resource, and the cluster quorum drive. If you are concerned about a failure of the MSDTC causing a fail-over of the entire Cluster Group, on the Advanced property page of the MSDTC properties, clear the "Affect the Group" checkbox. I personally recommend this additional step.




Please note that this advice does not hold up in a cluster that supports SQL Server, as SQL Server makes more use of the MSDTC and thus it may be important that the MSDTC is in its own resource group and uses a dedicated disk drive.

Clusters, security templates, OUs, and GPOs

If you have been keeping up with some of my past posts, you have seen that I have been wrestling with clustering issues and also with security templates and GPOs. I came up with a list of things that has been helpful to us in deploying our clusters.

• Do not apply "high security" templates to the base operating system.
  
• Organize your clustered nodes in to OUs (a single OU for the physical nodes of the cluster if possible.)
• Put the clustered server OU as close to the root as possible.
• Create a GPO specifically for the clustered nodes; use that GPO to restrict settings that need to be locked down. This simplifies troubleshooting if you only have ONE GPO that affects your clustered nodes.
  
• Block inheritance of GPOs on the cluster OU.
• Watch out for wayward GPOs on parent OUs and especially GPOs that have the Enforced (or No Override) setting on them.
  
• Remember, GPOs apply the the physical nodes of the cluster, not the virtual servers.
  

A good reference for applying more restrictive settings to clustered nodes is: How to apply more restrictive security settings on a Windows Server 2003-based cluster server.

Exchange 12 will ship only on DVD

KC Lemson wrote on the Exchange Team blog that Exchange 12 would only ship on DVD. I think this is a good move. In most environments in which I have worked, we copy the entire Exchange CD-ROM on to a shared folder anyway.

Microsoft's easoning behind the DVD-only media is that the "text to speech" engines each take up a couple hundred megabytes of disk space. Exchange 12 will use these text-to-speech engines to allow users to dial-in via phone to their e-mail server and have their e-mail read to them. Exchange 12 will not be release for at least 12 to 18 months. For the full text, see Exchange 12 will ship on DVD.

Problems with Windows Time service after upgrading to W2K3 SP1

As many people that have applied Windows 2003 SP1 have found, there have been a number of different things done to "harden" the operating system. These include changing some of the rights that the built-in services accounts (i.e. SERVICE, Local Service, Network Service) have to services.

Well, in some cases this has broken things. Most of the work I do is in much more security conscious environments than the average corporate environment. Generally, when we build servers, we secure the server "out of the box" with some type of improved security template. The most notorious of these (and a template to be avoided unless you are ready to some troubleshooting) is the NSA Windows security templates. After working with a number of different template configurations, I recommend just sticking with the built-in Windows security templates such as hisecdc.inf or securews.inf.

At any rate, Windows 2003 SP1 "broke" the Windows Time service on our domain controllers. This is because the Network Service account no longer had permissions to change the time on a domain controller. (This can happen on member servers and workstations, too.) Some of the errors we saw in the event log included:

Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7023
Description:
The Windows Time service terminated with the following error:
Not all privileges referenced are assigned to the caller.

and

Event Type: Error
Event Source: W32Time
Event Category: None
Event ID: 46
Description:
The time service encountered an error and was forced to shut down. The error was: 0x80070700: An attempt was made to logon, but the network logon service was not started.

Microsoft has a couple of fixes for this as documented in KB 892501. The approach I have taken is to add to the GPO that affects the domain controllers a new user right. In whichever GPO will affect the machines on which you are having problems, grant the SERVICE account (this is the Local Service) the right to "Change The System Time". Then give the GPO time to replicate and be applied to your machines.

There is some good information at the bottom of KB 892501 on checking and doing this for other services.

If you are messing with custom security templates in your environment, I recommend reading: Security Configuration Guidance Support.