Disabling WSUS Logging (or any website on Windows Server 2008)

SBS 2008 has IIS logging enabled by default. For most websites on an SBS server, this probably isn’t an issue.

However, the WSUS Administration website can generate very high traffic. On my client’s servers, I’ve seen 5 GB generated in just a couple of months. One person reported as much as 7.5 GB generated within a month.

Unless you need this logging for some debugging purpose, you can easily disable the logging. Sure, there are command line ways to do it, but in this case, using the GUI is pretty easy.

Open the IIS Manager and expand both the server and the Sites nodes in the Connections pane. See the figure below.

Next, click on the WSUS Administration website, then locate the IIS feature named Logging in the main pane. Double-click on it (or single click and select “Open Feature” from the Action pane).

Finally, click Disable, red-circled in the figure below. That’s all it takes!

If you should ever need to re-enable logging, you can return to this same window. Once disabled, the “Disable” action changes to “Enable”.

Disabling WSUS Logging

Until next time…

If there are things you would like to see written about, please let me know


Follow me on twitter: @EssentialExch

Monitoring Exchange Server 2007 with System Center Operations Manager 2007

Just a few days ago, my new book (of the subject title!) started shipping from Amazon. If it hasn’t already, it should start appearing in your local bookstores this week.

If you want to order from Amazon, you can get it here.

Eight months in the making, this book was a labor of love. Including information on installing and configuring OpsMgr 2007, it also includes much information about operating a reliable Exchange environment. Even if you don’t have OpsMgr in your organization, you can learn from this book the key areas of Exchange that need monitoring and how to do so.

A strong PowerShell component is provided in several chapters to assist you in the generation of synthetic transactions for testing your Exchange environment.

While the book is written toward a key audience of Exchange Server 2007 administrators, much material is also provided for the Exchange Server 2003 administrator. The book uses a virtualized environment to describe a test roll-out of an OpsMgr 2007 and Exchange 2003/2007 mixed environment.

Since Exchange Server depends on the health of Windows Server, Active Directory, DNS, and IIS; tracking the health and well-being of these key services is also covered.

Go buy it. You’ll like it. 🙂

The chapter titles are:

  1. An Evolution of Server Management
  2. Monitoring Exchange Server 2007
  3. Installing and Configuring OpsMgr 2007
  4. Deplying OpsMgr 2007
  5. The First Management Pack: WIndows Server
  6. The Active Directory Management Pack
  7. The Domain Name System (DNS) Management Pack
  8. The Internet Information Services Management Pack
  9. SQL Server: An Ancillary Management Pack
  10. Exchange Server 2003
  11. Exchange Server 2007
  12. Exchange Server 2007 Redundancy
  13. Exchange Server Operations
  14. Tracking Mail Flow

Until next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!


Follow me on twitter: @EssentialExch

Monitoring Exchange Server 2007 with System Center Operations Manager 2007

Just a few days ago, my new book (of the subject title!) started shipping from Amazon. If it hasn’t already, it should start appearing in your local bookstores this week.

If you want to order from Amazon, you can get it here.

Eight months in the making, this book was a labor of love. Including information on installing and configuring OpsMgr 2007, it also includes much information about operating a reliable Exchange environment. Even if you don’t have OpsMgr in your organization, you can learn from this book the key areas of Exchange that need monitoring and how to do so.

A strong PowerShell component is provided in several chapters to assist you in the generation of synthetic transactions for testing your Exchange environment.

While the book is written toward a key audience of Exchange Server 2007 administrators, much material is also provided for the Exchange Server 2003 administrator. The book uses a virtualized environment to describe a test roll-out of an OpsMgr 2007 and Exchange 2003/2007 mixed environment.

Since Exchange Server depends on the health of Windows Server, Active Directory, DNS, and IIS; tracking the health and well-being of these key services is also covered.

Go buy it. You’ll like it. 🙂

The chapter titles are:

  1. An Evolution of Server Management
  2. Monitoring Exchange Server 2007
  3. Installing and Configuring OpsMgr 2007
  4. Deplying OpsMgr 2007
  5. The First Management Pack: WIndows Server
  6. The Active Directory Management Pack
  7. The Domain Name System (DNS) Management Pack
  8. The Internet Information Services Management Pack
  9. SQL Server: An Ancillary Management Pack
  10. Exchange Server 2003
  11. Exchange Server 2007
  12. Exchange Server 2007 Redundancy
  13. Exchange Server Operations
  14. Tracking Mail Flow

Until next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!


Follow me on twitter: @EssentialExch

Exchange 2003 Default Recipient Policy Problems with OMA/EAS

So, yes, I spend most of my time writing about Exchange 2007, but most of my clients are still on Exchange 2003.

I ran into an interesting problem today. It took me about an hour to figure out what was going on, but then it was a “duh, of course” moment on my part.

The real issue? Too many cooks in the kitchen. This problem was caused by a client administrator making a change I wasn’t aware of, just because he thought it made things “cleaner”. If I had been aware of the change before it happened, I would’ve said “no, that’s gonna hurt, don’t do it!” After the case, I would’ve said “let’s change it back.”

Anyway, the problem started with a report of a user who just got a Treo and couldn’t sync with EAS and couldn’t log into OMA. This is why:

When Exchange is first installed on a server, either Exchange 2000 or Exchange 2003, it creates something called ExIFS – the Exchange Installable File System. The purpose behind ExIFS is to allow an application to access Exchange mailboxes as if they were a file system – each folder representing a directory, each mail message or calendar item being a file, etc.

In Exchange 2000, this was visible by default, as the “M: Drive”. That caused huge numbers of heartaches. Many anti-virus solutions would scan M: and end up corrupting items. (Note that this was not necessarily the fault of the anti-virus vendors, as Microsoft guidance was quite clear about configuring the a/v solutions to NOT do this.)

In Exchange 2003, the M: drive was still present – but hidden. To access it, you must use a special syntax of NTFS, often called “the volume syntax”, as it can also be used to see your normal disk drives and mount-points, if you know their system names (which contain a 128-bit value known as a GUID). You access it by using this syntax \\.\BackOfficeStorage\. If you do a “dir \\.\BackOfficeStorage\” from a command prompt on an Exchange Server, another directory will be visible. This directory will be the DEFAULT SMTP domain in the Default Recipient Policy.

Now, when you first install Exchange, the default SMTP domain is the same as your Active Directory domain. So, if your Active Directory is named test.local, then your default SMTP domain is also test.local. As you create users with mailboxes, that Default Recipient Policy will stamp your users with test.local as their primary SMTP domain.

That is generally not what they want. J Most people have a different Internet domain than their AD domain. To solve this, you have two options:

1] Change the default policy, or
2] Create a newer, higher priority policy.

Option [2] is the correct choice.

If you choose option [1], then you will change the default SMTP domain. OMA and EAS depend on the default SMTP domain, and they were setup when you installed Exchange. Now, if you change the default policy, and leave it so that the default policy still generates the original email address, just not as the primary, OMA and EAS will still work. If you change the default policy and eliminate the original email address, then users created without that original email address will not be able to use OMA and EAS.

This is especially critical in SBS 2003 servers and in servers where KB 817379 has been applied (which has automatically been done on all SBS 2003 servers).

This is because the directory gets updated in the Exchange virtual directory of the Default Web Site automatically by the DS2MB process of Exchange’s System Attendant. However, the Exchange-OMA directory is not updated.

If you run into this problem, you can update the Exchange-OMA virtual directory, you can update the Default Policy, or you can update individual users with the other email address; whichever works out best for your organization or your security standards.

This problem disappears on Exchange 2007, since it no longer has OMA or the ExIFS. EAS on Exchange 2007 uses Exchange Web Services (EWS).

Until next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!


Follow me on twitter: @EssentialExch