I've been chasing after an issue with a new Exchange deployment not sending any outbound mail. When you telnet to port 25 on any SMTP server it just fails straight away as if there's a firewall or something in between. I finally got a network trace and the very odd thing was that there was absolutely no network traffic at all. Usually you would see a bunch of TCP SYNs if there was a firewall in the mix.

I noticed that McAfee's little shield in the tray was bright red which it does when it as something to say. The log had these nice entries (well a lot of them) in it:

6/29/2009    11:39:13 AM    Blocked by port blocking rule     C:\Exchange\Bin\edgetransport.exe    Anti-virus Standard Protection:Prevent mass mailing worms from sending mail    10.100.10.16:25

6/29/2009    11:40:46 AM    Blocked by port blocking rule     C:\Windows\system32\telnet.exe    Anti-virus Standard Protection:Prevent mass mailing worms from sending mail    10.100.10.15:25

You can see Exchange trying to relay mail (the Edge Transport process) and me trying to test it by hand (telnet). Apparently McAfee has kindly inserted itself into the network stack somewhere and is intercepting these connections before they even leave the box.

In order to turn this off, you need to go in ePO and edit the Access Protection policy which applies to your servers. Inside the policy, go to Anti-virus Standard Protection and uncheck both boxes for Prevent mass mailing worms from sending mail:

Don't forget to do this for both the "Server" and "Workstation" policies (or just the server one).

If you're trying to import an LDIF file with some schema changes on a Windows Server 2008 (or Vista) machine and it bails with an access denied error and an INSUFF_ACCESS_RIGHTS messag, first make sure your account is in the Schema Admins group. Second, make sure User Account Control isn't adding to the mix. Right click the command prompt shortcut and Run as Administrator and then try the LDIF import.

I've had the pleasure of trying to reverse engineer the firewall requirements DPM has since they've declined to document any of this in a useful fashion. My experience so far is that this product does something very slick with Exchange and brings with it the baggage of awful documentation and a user interface which would earn an A for a high school computer science project.

The manner in which DPM does its deployment and management of agents is through something called the Agent Coordinator service. The agent coordinator comes and goes on an as necessary basis (it's temporary) and for whatever reason is installed into the Windows folder. If you take a network trace you'll see all of the file copy and service control manager operations happening assuming you have those firewall rules in place (you'll need them). Now in order for the agent coordinator to work it needs to listen on TCP 5719 as well as accept RPCs. If you don't have the rules in place for this, you'll get a failure with an Error 313 0x80070643 which the documentation points out could be due to a firewall. Of course the documentation doesn't specify what firewall rules might be necessary (go figure).

What I've discovered is that you need the following rules for agent deployment and management as well as backup to work. You can just use the "Custom" option in the Windows Firewall New Rule wizard to specify all this.

Add those rules to a Group Policy object or your local Windows Firewall policy and you should be good to go.

Under Windows Server 2003 (and 2000), Active Directory Users and Computers was always available by just launching dsa.msc. From there you could use the legacy Group Policy management interface if you didn't have the GPMC loaded. Windows Server 2008 machines no longer have ADUC loaded by default unless you either are on a domain controller or install the management tools. This makes the scenario where you need to edit a Group Policy locally a bit more complicated.

The good news is that the Group Policy Editor itself is there on Windows Server 2008 machines, you just can't graphically browse to a GPO (so far as I know). If you launch gpedit.msc, the local machine policy is pulled up. Adding the snap-in manually to an MMC allows you to target another machine for editing its' local policy.

The gpedit.msc console will however accept an argument at startup pointing it to a GPO in the domain. To do this you'll need the GUID of the policy you're looking to edit. If you go to the Details tab after selecting the GPO in question from the GPMC on another machine, the GUID is adjacent to the Unique ID label, and you can select the GUID and copy it to the clipboard.

If for example you wanted to edit the GPO with GUID {0F0AB6A5-A700-4493-9D0E-DCCA40D2E27B} in domain briandesmond.net, you could run "gpedit.msc /gpobject:"LDAP://CN={0F0AB6A5-A700-4493-9D0E-DCCA40D2E27B},CN=Policies,CN=System,DC=briandesmond,DC=net".

KB article 822158 does a good job covering all of the antivirus exclusions for Windows machines as well as for domain controllers in particular. If you're upgrading domain controllers to Windows Server 2008 or better, be sure to update your anti-virus exclusion rules as a couple of the excluded files (res1.log and res2.log) have changed names to Edbres00001.jrs and Edbres00002.jrs, respectively.

If you're trying to install McAfee EPO (ePolicy Orchestrator) 4.0 and setup is failing when it tries to connect to your SQL Server with a variety of worthless errors, be sure that the server name you specify matches the result of this SQL query exactly: "SELECT ServerProperty('ServerName')". After hours of messing around, a network trace revealed that this was query the last thing setup issued before it failed. In general the query seems to return the SQL server's shortname, so, if you've done something smart like I did and provided the FQDN of your SQL Server to setup, setup will fail and tell you it can't connect or the port number is wrong or something else in that general vicinity.

Another thing I learned from my network trace – make sure the credentials you provide setup have sufficient SQL access to create AND drop databases. Setup tests its ability to do so by creating a database with a GUID for a name and then dropping it.

If you run into a scenario where your Exchange databases are failing to mount with either of these errors, first reference this Technet article. Assuming that doesn't apply then manually start the System Attendant (MSExchangeSA) service on the machine which is failing. After doing that try mounting the databases (or bringing your clustered mailbox server online with Start-ClusteredMailboxServer). Bottom line I spent hours trying to figure out why Exchange wasn't succeeding in creating the mailboxes it needs for each store before I decided to randomly try this.

Log Name: Application
Source: MSExchangeIS
Date: 6/6/2009 7:48:43 PM
Event ID: 9519
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: FooExchange.domain.com
Description: Error 0x97e starting database "SG01\MB10SG01MS01" on the Microsoft Exchange Information Store.

Log Name: Application
Source: MSExchangeIS
Date: 6/6/2009 7:48:43 PM
Event ID: 9546
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: FooExchange.domain.com
Description: Failed to create the Event Registration Mailbox for Database SG01\MB10SG01MS01. Error - 0x97e.

If you've ever had Exchange 2007 setup fail partially, you've probably noticed that some of the components (maybe even the one it failed during) show up as installed, but, if you run the ExBPA (Best Practices Analyzer), it will probably complain that setup failed. Most applications you just go to Add/Remove Programs (or Programs and Features in WS2008) and there's a repair option. Exchange of course has no such option.

The trick with Exchange is to fix it with the exsetup utility. If for example you needed to fix up a Mailbox server role installation, you'd go to C:\Exchange\Bin (or where ever you installed Exchange to) and run "exsetup /role:Mailbox". The utility will resume setup where it left off and clean things up.

I recently discovered that VMWare Workstation has a couple of options on the View menu which will dynamically adjust the screen resolution of a guest to match the window on the host. If you've ever had a window looking like this and have tried to tweak the guest resolution for it to fit just perfectly, you know how much pain that is:

The trick is to go to View>Fit Guest Now. VMWare will adjust the resolution of the guest and make it fit perfectly. There is another option you can check/uncheck called Autofit Guest which will do this dynamically for you. I've noticed similar options in the VMWare Virtual Center (ESX) console although I haven't had consistent luck with them.

Also note that if the option in Workstation isn't working, make sure you have the latest VMWare Tools installed (check for a yellow exclamation overlay on the icon in the tray).

Coming to TechEd in a couple weeks? Come say Hello! I'll be hanging out at the MS Active Directory booth in the Technical Learning Center all week answering questions and talking to customers. I'll be at the booth for sure in the afternoon every day, and I'll probably be around most mornings (but no promises there). If you're going to be at TechEd, come say hello.

As far as Active Directory, 4^th Ed goes, if you've got a copy and would like to get it signed, bring it with. If you don't have a copy, I understand they will be for sale at the TechEd book store. It's usually near the front door somewhere. You could also pick one up from Amazon (at a discount off list) and bring it along.