March 2008 - Posts

As anticipated, Microsoft today released confirmation that E14 would completely support public folders (that being at the current level of implementation - no new features are expected/anticipated). Along with this, they also gave their guidance as to how companies should investigate using PFs vs. SharePoint.

No major disagreement with their guidance - except I believe that PFs provide a significantly better experience for discussion forums than SharePoint does.

See Updated Exchange Public Folder Guidance on the MS-Exchangeteam blog.

Posted by michael | with no comments
Filed under: ,

Over three years ago, I wrote my most popular (in terms of number of times it has been read) blog post ever: "Exchange Server 2003 and Domain Controllers - A Summary." Since it was written in January of 2005, Exchange Server 2003 service pack 2 has been released, Windows Server 2003 service pack 2 has been released, Exchange Server 2007 RTM'ed, and Exchange Server 2007 service pack 1 has been released.

Recently, I also blogged about a key point missed in that original article; the fact that Local\Administrators on a member server is a far different animal than Builtin\Administrators on a domain controller (this leads to the fact that you can't restrict permissions for an Exchange Server Admin when Exchange is installed on a DC). That was in this post.

The basic recommendation and supportability statement has not changed: Microsoft does not support the execution of DCPROMO on a server after Exchange Server has been installed. This includes either the demotion of a domain controller to a member server OR the promotion of a member server to a domain controller.

Also, while running Exchange Server on a domain controller is supported by Microsoft, it is not recommended.

So...why not?

From a technical perspective, Exchange Server is "nothing more" than a large application that uses lots of the capabilities of Windows Server. It uses IIS, ESE, NTFS, ACLs, Active Directory, ASP.NET, the .NET Framework, etc. etc. However, unlike many applications that use only a small part of the capabilities available from a given technology, Exchange Server uses some of the technologies to the utmost - ESE, for example, was initially developed for the use of Exchange Server.

What this tends to mean is that changes in the underlying operating system can have a large impact on how Exchange Server works.

Take, for example, the fact that a domain controller has no local account database. None. So, when IIS is installed on a domain controller, the IIS user that is created for application pools is a domain user, instead of a local user. Any application that "knows" what the IIS user is will have issues with a change from a member server to a domain controller, and vice versa.

Note also that different security policies are applied to domain controllers vs. member servers. This affects the rights available to any service or process running on the subject server. It also affects the rights assigned to the various built-in accounts attached to that server. Any single domain controller has identical rights (via the Domain Controller Security Policy) as every other domain controller in a domain. However, a member server is subject to both Local Security Policy and to the Domain Security Policy. Not to mention that different Group Policies may be attached to the Domain Controllers OU versus the Computers container.

Therefore, from a security perspective, it begins to become obvious that making a change from member server to domain controller is a very significant change and it should be no surprise that this change can significantly effect some applications. It actually becomes surprising that more applications are not effected by this change.


Except in fairly rare cases, making all DCs into GCs (domain controllers into group catalog servers) is a good idea. The exceptions tend to revolve around bandwidth-constrained environments where there are large numbers of domains and high-churn (that is, lots of changes).

In fact, if you install Exchange Server on a domain controller, that DC must be a GC. Installing Exchange Server on a DC removes any redundancy from Active Directory for that particular Exchange server. Exchange will always refer to the server on which it is installed for LDAP and GC queries.

This also means that any Exchange Server installed on a Windows Server 2008 DC cannot use the Windows Server 2008 functionality that allows Active Directory to be stopped and restarted on that server. If Active Directory is stopped on that server, Exchange Server will stop working.

When you make a DC into a GC, it does not immediately become available for use by Exchange Server. The GC replication process has to complete before the DC will begin advertising itself for use as a GC. If you are needing to create a new GC and then eliminate an old GC, you will need to monitor the event log in order to know when the new GC is ready.

On a similar note, when you remove the GC attribute from an existing GC, it will not stop being a GC until the next reboot. This needs to be taken into account during your planning.

Exchange Server makes heavy use of Active Directory, and in medium-to-large environments, Microsoft makes specific recommendations about the number of GCs that should be available (see KB 875427). In general, you need to have a dedicated GC processor core for each four Exchange processor cores (assuming the cores are of a similar architecture and speed).

Prior to Exchange Server 2003 service pack 2, when installed on Windows Server service pack 1 (or earlier), there were long delays associated with restarting a DC where Exchange Server were installed. If you are in that case, please update to more recent version (Service pack) of both Exchange Server and Windows Server. This problem occurs because of dependencies between Exchange and Active Directory - a needed Active Directory service would terminate prior to Exchange being done with it, causing Exchange Server to appear to "hang" until it timed out.


If you install Exchange Server on a domain controller, the Exchange Server Administrator must be a member of Builtin\Administrators or of Domain Admins. Since both have privileges over every server in the domain, you have no restriction of responsibilities.


Both Active Directory and Exchange Server are memory and processor intensive applications. In 32-bit installations, it is commonly recommended to use the /3GB switch for Exchange Server, but this is NEVER recommended for a DC. On a DC, using that switch can cause Active Directory to be starved for memory.

Similarly, in a 64-bit installation, both Exchange Server and Active Directory will attempt to consume all available memory (as will SQL Server, should it happen to be installed). This can lead to memory-to-disk thrashing without careful tuning.


Finally, if you do choose to install Exchange Server on a domain controller, you should verify and test your backup and recovery plan thoroughly. Placing both Exchange Server and Active Directory on a single computer significant complicates the recovery process should a significant failure occur. Significantly.

If you want to review the Microsoft guidance on this topic, enter the following query into Google: "running exchange server on a domain controller site:*.microsoft.com".

Until next time...

As always, thanks for reading. If you have topics that you would like to see covered, please e-mail me or leave a message for me in the forums.

I just finished installing Exchange Server 2007 on Windows Server 2008 (single server install). It went smooth as silk and I'm as pleased as punch.

You have to install the "PowerShell" feature and the "IIS" role, and then start setup. And off she goes...

This is what it looks like (from the command line):

C:\Users\Administrator.ESSENTIAL\Desktop\E2K7SP1EN64>setup.com /mode:install /roles:h,c,t,m

Welcome to Microsoft Exchange Server 2007 Unattended Setup

Preparing Exchange Setup

The following server roles will be installed
    Management Tools
    Hub Transport Role
    Client Access Role
    Mailbox Role

Performing Microsoft Exchange Server Prerequisite Check

    Organization Checks              ......................... COMPLETED
 The Active Directory schema will be upgraded if you continue. Verify that the organization is ready for Exchange 2007 by running the Exchange 2007 Readiness Check, which is part of the Exchange Best Practices Analyzer.
    Hub Transport Role Checks        ......................... COMPLETED
 Setup cannot detect an SMTP or Send connector with an address space of '*'. Mail flow to the Internet may not work properly.
    Client Access Role Checks        ......................... COMPLETED
    Mailbox Role Checks              ......................... COMPLETED
 If Outlook Web Access is in use, you should replicate the free/busy folder on this server to every other free/busy server in the organization. This step should be performed once Setup completes.

Configuring Microsoft Exchange Server

    Organization Preparation         ......................... COMPLETED
    Copying Exchange files           ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Hub Transport Server Role        ......................... COMPLETED
    Client Access server role        ......................... COMPLETED
    Mailbox Server Role              ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully. Setup has made changes to operating system settings that require a reboot to take effect. Please reboot this server prior to placing it into production.

C:\Users\Administrator.ESSENTIAL\Desktop\E2K7SP1EN64>

Easy, huh?

I personally like using the command line - I think the errors are better (actually, they are exactly the same, I'm just a command-line junkie).

"Exchange Server 2007 and Windows Server 2008 - Better Together!"

Or so they say. :-)  I'll let you know after I've played with it some!

Until next time...

Thanks for reading, and if there are topics that you would like to see covered in this blog, please e-mail me or leave a message in the forums.

Posted by michael | with no comments
Filed under: ,

Just like a certain segment of the blogosphere is concerned about Windows versions and gets excited every time a notice about "Windows 7" (the succeeding product to Windows Vista and Windows Server 2008) comes out of Redmond, I follow, instead the segment that gets excited about E14 - the next release of Exchange Server.

At this point, I would say that we probably know less about E14 than we do about Windows 7! 

One of the MAJOR issues that came out of E12 (Exchange Server 2007) was that Microsoft chose to de-emphasize Public Folders. What this means is that they said they would support public folders for E12, but would not guarantee that they would be supported in releases after E12, nor would additional feature content be added to Public Folders.

Microsoft's stated direction for public folders is the SharePoint product suite. Which, while it does a GREAT job at some things (document libraries come to mind) does poorly at other things (threaded conversations) and does not do some things at all (replication of content to many sites).

Well, in a conversation today it came out that Microsoft will support public folders in E14. Many of us were shocked, surprised, and very happy! The Microsofties in the conversation were surprised that we were surprised - they said that they had told us this 'way back in 2006! They pointed to this blog post by Scott Schnoll from June of 2006.

Well, now we know! I'm sure we'll hear more about this Real Soon Now (tm).  :-)

Posted by michael | 2 comment(s)
Filed under: ,

I had a poster on a mailing list ask a question recently, and while researching the answer I came across KB 948716. Now, that particular KB article is of great interest because it includes all the patches in KB 941275.

KB 941275 is basically a mini-service pack. It's got a number of fixes for issues that I have experienced, and you may have as well.

Check'em out.

Until next time...

If there are things which you would like to see covered in this blog, please send me an e-mail or leave a message in the forums.

Posted by michael | with no comments
Filed under:

If you are a regular reader, then you know I've been working on a major SharePoint/MOSS upgrade the last couple of months. It's finally winding down to a close and should finish up this week.

One of my duties as part of this process has been to produce a series of scripts that automate the upgrade, as much as possible. Unfortunately, PowerShell wasn't an option here, as the client couldn't deploy PowerShell in a timely manner given the constraints under which they operate.

So...out come the batch files!

It's worthwhile noting that if you are deploying RODCs (Read-Only Domain Controllers) in Windows Server 2008 - you will still need to know how to write these! PowerShell can't be installed on RODCs due to its dependence on the .NET Framework.

There are a couple of things about batch files that are really cool - but those things are few and far between! When you start to take advantage of the cool features, your batch files start to look like spaghetti code (because they are) and they become quite difficult to read.

Here is a feature I've used extensively recently:

                set PRESCAN=%PRESCAN:"=%

How obvious is that, eh? What this does is set an environment variable named PRESCAN to itself - after all quotations marks have been stripped out. This is something you need to be able to do when an executable file name is passed in as a variable to a batch file. If the file name has spaces in it, then the user of the batch file will have to quote the file name. And one of the, uh, odd things that the batch file processor does not do for you is strip those off. So if the user enters:

                 somefile.cmd "C:\Program Files\A Utility\util.exe"

Then the string received by the batch files for parameter 1 is "C:\Program Files\A Utility\util.exe" - quotes and all. If the user enters:

                somefile.cmd C:\Program Files\A Utility\util.exe

Then the string received by the batch file for parameter 1 is C:\Program - with no quotes.

Ouch.

Now, if you try to use the filename with quotes in it - many features of batch files don't work. You can't execute the program, you can't use "IF EXIST", etc. So, you have to strip them off.

You also need some way to determine the user specified a value for a parameter. If they didn't, you may want to substitute a reasonable default (or generate an error message if the value should be requried). "IF DEFINED" is to the rescue, but it has quirks too.

Using these pieces of information, we've got two possibilities now. Let me show you a couple of examples:

SET PRESCAN=%7
If DEFINED PRESCAN goto :cleanPRESCAN

Set PRESCAN=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\prescan.exe
echo PRESCAN (parameter 7) not defined. Trying %PRESCAN%

:cleanPRESCAN
REM strip any quotation marks off
set PRESCAN=%PRESCAN:"=%

IF EXIST %PRESCAN% GOTO :gotPRESCAN

echo Specified PRESCAN file does not exist. Aborting.
goto :EOF

:gotPRESCAN

echo.
echo Will use PRESCAN file: %PRESCAN%
echo.

Note that in this example, the user may or may not specify a value for the parameter. If they don't, a reasonable default is applied. If they do, quotes are stripped out of the file name. The the existence of the file is checked and if it is present, processing continues.

REM
REM Process parameter 5 (name of the database server and instance)
REM

if "x%5" == "x" GOTO :noDBSERVER

set DBSERVER=%5
goto :gotDBSERVER

:noDBSERVER

SET /p DBSERVER="Enter the name of the database server (and instance if applicable): "

if NOT DEFINED DBSERVER (
	echo You entered an empty database server name. Aborting.
	goto :EOF
)

:gotDBSERVER

Now, in this case, a different technique is used to determine whether or not a value has been provided by the user (as the desired outcome is different). If the user hasn't entered a value as a parameter, then the user is prompted to enter a value. If they do not, the program aborts.

Using protected input like this is a key difference between an "enterprise quality script" and something you just "see on the Internet". One is suitable for production use. The other is suitable for hacking around. Which kind are YOUR scripts?

Until next time...

Thanks for reading! If there are topics you would like to see covered in this blog, please send me an e-mail or leave a note in one of the forums.

Posted by michael | 2 comment(s)
Filed under: ,

Sorry for the quiet time, it's been a busy week here at the homebase of TheEssentialExchange...

When I think of everything that's been going on the last couple of weeks, I'm actually surprised I'm still standing:

  1. Finishing the development of some major tools for a huge WSS 2.0 to MOSS 2007 migration
  2. My 45th birthday!
  3. Signing of a new book contract and writing 18 pages of chapter 1
  4. Studying for, taking, and passing 70-292 and 70-296
  5. Studying for 70-236 (taking that next Thursday)
  6. Reviewing an article for Penton Media (to be published in May)
  7. Writing two articles for EMO
  8. Other revenue generating consulting (something has to pay the bills....)
  9. Playing with the kids!

While I was "in management" for another company, I had let my certifications slide; and now it is time to get them back up to speed. The new adaptive testing, with the simulations and drag-n-drop steps take a little getting used to (now, I realize to most of you these things aren't new - but it's been quite a while since I took a MSFT certification test!), but the testing material is the same as always - a few questions that are ridiculously easy, a few that are impossible, and most that are reasonable.

Next week I plan on being back to my normal two-or-three post a week habit.

Thanks for reading!

Posted by michael | with no comments
Filed under:

Well, it appears that Microsoft has given in.

In today's patches, we see KB 948496, "An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers".

As I've reported previously, here, here, and here; there have been many issues with the Scalable Networking Pack since its release in Windows Server 2003 service pack 2. Many people have made disabling it part of their standard server build. Now, Microsoft is disabling it for you.

About time.

I wonder how many developer and test hours were spent on this feature versus the agony it has caused in the field?

 

I also wonder if anyone is actually using the feature - successfully!

 

If you read KB 948496, you see a wider description of problem areas than I was previously aware of: including issues with copying files from Vista computers, issues with Exchange ActiveSync, issues with both NAT and NLB.

 

Ouch. So...get this one in, or turn off the feature!

 

Until next time...

 

As always, I hope you've enjoyed this article. If there are topics you are interested in and would like for me to cover, please send me an e-mail or post in the local forums.

Posted by michael | 2 comment(s)
Filed under:

Once the spammers find your domain, which usually only takes a few weeks after it has come online, you'll start seeing lots of error messages being returned to your Exchange Server - for email that was never sent from your server! This is commonly called back scatter, and can be worse than spam itself. Viruses, worms, adware and other types of malicious software can all cause your Exchange Server to generate NDRs - Non-Delivery Reports. NDRs traditionally meant that a mailbox was full or that a particular user is no longer at a particular company.

Unfortunately, with the explosion of spam and malware over the last few years, their usefulness is at an all-time minimum. Today, many Exchange Administrators choose to turn them off. This is done in the window displayed below (on Exchange Server 2003 - a similar setting exists in Exchange Server 2007).

 

 

You access this window by opening ESM. Expand Global Settings, click on Internet Message Formats in the left pane, then right-click on the Default label in the right pane. Finally, select Properties, and then click on the tab named Advanced. The six check-boxes at the bottom of this page control a number of interesting behaviors. It is worthwhile to click on the Help button, and explore what each of them does. For right now you are only interested in the fifth box and except for this particular box, "Allow non-delivery reports", the default settings for these items are normally just fine.

In order to disable the generation of non-delivery reports, simply uncheck the box, and click OK. The effect is immediate and no new NDRs will be generated. However, if there are NDRs already in your SMTP outgoing queues (very likely), they will take a couple of days for them to filter out.

Until next time...

As always, I hope you've enjoyed this article. If there are topics you are interested in and would like for me to cover, please send me an e-mail or post in the local forums.

Posted by michael | 1 comment(s)

I don't often just refer you to another blog, but this article on "How to Think" by Ed Boyden is one that I keep returning to. I think it has gret value. Check it out.

Posted by michael | with no comments
Filed under:

In a move that was likely a surprise to no-one, last week Microsoft announced its offering for hosted Exchange 2007, hosted SharePoint (MOSS 2007, not WSS 3.0), and hosted LiveMeeting.

This was the next logical progression from the Microsoft Office Live Small Business offering  (where Microsoft offers domain hosting, web hosting, and web e-mail).

As a sort-of large scale alpha, Microsoft started with Live@Edu last year, providing Exchange services for educational institutions. Right now, the Microsoft Online service is in a limited beta, with an expectation of being available "later this year".

Microsoft says that this will be offered through the partner channel and not through direct sales. Price points haven't been made public yet, but one has to wonder what this is going to do to the established hosted Exchange partners?

Regardless of which - you have to suspect that Microsoft is uniquely qualified to offer hosting with these more complicated products. Hosting of Exchange and MOSS is not simple (trust me - I've done it for years) and the infrastructure can be complicated to maintain and update. It will be interesting to see whether Microsoft can pull this off as well, or better (or worse!), than the existing partner ecosystem.

Stay tuned!

For more (much more) information, click Microsoft Online!

There is also a new MSOnline blog. They list a whole slew of resources here.

Until next time...

As always, I hope you've enjoyed this article. If there are topics you are interested in and would like for me to cover, please send me an e-mail or post in the local forums.

Obligatory Disclaimer: Over the last 25 years, I've done work for companies of all sizes, large and small; although most of my clientele for the last 10 years has been on the smaller side since, as I've gotten older, I don't tend to want to travel as much, and I live in a pretty small town.

I'm in the middle of a consulting engagement with SharePoint. That product isn't my sweetest spot, but I know a fair bit about it. I'm doing a migration for a very large company from WSS 2.0 to MOSS 2007. And I'm frustrated.

In this company, Internet access is prohibited; so I can't do research onsite. In this company, external personnel have to be signed in and out; so I can't come and go. In this company, I can't attach my laptop to their network; so every time I need a resource, I have to have one of their personnel download it. In this company, USB devices are disabled; so I can't transfer files from my laptop to their laptops/desktops. In this company; the database people do databases, the SharePoint people do SharePoint, the network people do networks, the A/D people do A/D, the DNS people do DNS - and never the twain shall meet.

So each time I need an account created, there is a form to fill out. Along with justification for administrative level permissions too. A DNS entry created, there is a form to fill out. A database to be moved, a form to fill out.

ARGH.

I KNOW I'm being unreasonable. But the effort is taking four or five times longer than it should because I just can't get work done efficiently. I have to get six or seven other teams to do the work for me. No wonder consultants get a bad name! I'm used to being able to go in and "be a star" because I can "do it all".

<sigh>

Posted by michael | with no comments
Filed under:

A perennial recommendation to squeeze the utmost in performance from your Exchange 2007 (and Exchange 2000 and Exchange 2003...) disk spindles has been to align the partition boundaries of the disks to a 8 KB boundary - since Exchange will always read in 8 KB at a time (or a multiple of that up to a megabyte). It means that, most often, a physical read and a logical read will map one-for-one - and your I/O will be the most efficient.

Well, in Windows Server 2008 you don't have to do this. Windows Server 2008 automatically aligns the beginning of a partition to a 1,024 KB boundary. Since Exchange 2007 service pack 1 is the first version of Exchange to run on Windows Server 2008, it means that you get this "for free" by installing your Exchange Server using Windows Server 2008. It's just lagniappe!

Note: this is also considered a best practice for SQL Server 200x.

References: Why should you use Diskpar (Diskpart in W2003 SP1),  Partition Design,  How to Align Exchange I/O with Storage Track Boundaries, and KB 929491.

P.S.: Vista also does this alignment.