Mailbox Stats Mailed Exchange 2010

The goal of this article is to create a mailbox.txt file that contains mailbox statistics about your exchange users AND to have it mailed to you everyday at say, 5:00pm.

This article is specific for Exchange 2010, but it can be used on 2007, just modify the path to Exchange installation folder by removing the “v14” folder.

You will be creating two files, both reside in the “bin” folder of exchange, by that I mean for a standard installation of Exchange 2010, it would be the following folder:
C:\Program Files\Microsoft\Exchange Server\v14\bin

First, create a file called SendStats.ps1 that has the following two lines of code and three comment lines (which begin with ###)


###Send mailbox statistics script###
###Get the stats and store in a text file called mailboxes.txt###
Get-MailboxStatistics -database "Exchange Mailbox Database"| Sort-Object DisplayName | ft DisplayName,@{label="TotalItemSize(KB)";expression={$_.TotalItemSize.Value.ToKB()}},ItemCount > mailboxes.txt

###Create the mail message and add the mailboxes.txt text file as an attachment###
Send-MailMessage –From help@madtownengineer.com –To help@madtownengineer.com –Subject "Mailbox Size Report" –Body "Attached is the current list of mailbox sizes." -Attachment "Mailboxes.txt" –SmtpServer localhost

You will need to modify the -database “Exchange Mailbox Database” to the actual name of your database and you will need to modify the from and to addresses to a valid email address for your system.
I found that exchange 2010 likes ‘localhost’, but exchange 2007 likes the dns name of the server itself, as in ‘server1.addomain.local’

Then, create another file called MBStats.bat which contains two lines of code:

cd "C:\Program Files\Microsoft\Exchange Server\v14\Bin"
C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -PSConsoleFile "C:\Program Files\Microsoft\Exchange Server\v14\Bin\ExShell.psc1" -Command "sendstats.ps1"

The nice thing about this batch file is that it easily allows you to make the scheduled task without a lot of command line arguments  (and testing the script from a cmd prompt is easy too)

Like I said above, both of these files are stored in the “bin” folder of exchange.

Finally, go into the Scheduled Tasks of Windows 2008 R2 and create a scheduled task to run every day at 5pm, whether user is logged on or not.

You can just type in the batch file name, you won’t need to point to the entire path location because the Exchange “bin” folder is already in the PATH variable.

Advertisements

2008 R2 Domain Controllers unable to communicate to root DNS servers

I upgraded a domain with two local domain controllers from 2003 to 2008 R2.
I installed two new dcs, then moved the fsmo roles over and flipped ip addresses.
That way i did not have to deal with issues of dns resolution for workstations (modify dhcp scope for DNS) or member servers.
When I did that, the new dcs had the old dcs ip address, and the old dcs had some other previously unused ip addresses.
At that point, the new dcs were being queried for names of external websites. The dcs were unable to resolve anything external.
For a quick fix, I configured one of the dcs to enable forwarding (rather than root hints servers) and all requests were forwarded to the ISP’s DNS servers.
That worked, but why could 2003 perform root hints communication, but 2008 could not I thought?
The answer turned out to be this technet article. It affects 2003 R2, 2008, and 2008R2

http://support.microsoft.com/kb/832223

Basically type this from an elevated cmd prompt
 dnscmd /config /enableednsprobes 0

No need to restart services or reboot anything.

Two issues: difference in implementation of dns server between windows version and some cisco firewall setting.
The cisco engineer enabled large packet size or something like that, but that still did not fix the issue.
So i ran the commands described in the above article, and all is good. I was able to turn off forwarders and use root hints as necessary.

Some strange setting on the cisco firewall that did not like the way 2008 operated dns.

“Some firewalls contain features to check certain parameters of the DNS packet. These firewall features may make sure that the DNS response is smaller than 512 bytes.”
Click on the image below to see it larger.
Note: You have to run the cmd prompt elevated (Runas Administrator)

NDR Spam and POSTINI how to

First of all, what is a NDR?

http://www.postini.com/webdocs/rel_notes/announce/bulletin_ndr.pdf

A non-delivery report or NDR is a message sent by the email server that informs the sender that the delivery of the email message failed.

While there are various events that can trigger an NDR, the most common cases are when the

recipient of the message does not exist or when the destination mailbox is full.

So if I sent a message to mikkkkkke@madtownengineer.com, from an external account, I get back a NDR.

In plain English, No user by that name, sorry, message returned.

Typically, the message is sent with the original message just below it, as if you were replying to a message….

What spammers do is this:
They spoof the FROM:, send a bunch of messages to your server to users that may or may not exist.

So what happens is, your server sees all these messages addressed to users that don’t exist.

Your server sends NDRs in response. The FROM: that was spoofed are valid email addresses.

Your server is sending “NDR spam”.

Spammers do this on purpose…. Your server sends these NDRs with the ORIGINAL message just below it.

It’s a cheap shot, I agree, but it’s a way to send spam.

Throw a thousand messages at youdonotexist@madtownengineer.com, each with a different FROM: addresss, and your server is sending tons of NDR spam.

Ohhh noooo….

What if the FROM: address is totally bogus, like ramdomly generated domains.

Your server will try to send NDRs to domains that have no MX (receiving mail servers) records.

This screenshot of the outbound queue viewer below is what you will see.

The FROM address of <> is the server way of saying it’s a NDR.

And you will see your server making some communication with odd domains

What can you do?

If your anti-spam device is an appliance, you can, if the appliance supports it, perform an LDAP lookup of the user.

So the appliance does an ldap lookup, if the user exists, then send it, if not, send an NDR or drop the message completely.

Microsoft says that you can install the Anti-spam agents on the exchange server.

This is normally found on the edge server, but can be installed on any HUB transport server.

Then enable the Recipient Filtering.

But I found that this still creates NDRs…. Not a bounce.

So that installation work was kinda worthless, but what the heck, now you know how to install the antispam piece on exchange.

And the verification comes when postini is done, and tries to deliver it to the exchange server.

Some NDRs are good, say you send accidently type the address incorrectly when you send a message, you want the server to notify you that “there’s no user here”.

In this case, the exchange server sends it from postmaster@, and it’s a 5.1.1, and the erros is Recipient not found.

So, it looks like this, and is generated at the Exchange server

If you have all your users setup in Postini, the aliases, and the groups that are allowed incoming from the internet, you can turn this setting on

“Non-Account Bouncing”

I like this better because it tells the sending server “no user found” and doesn’t even accept the message.

The details are seen here when you click on the “General Settings” icon

Then the bounce message looks like this, and is generated from the sending server, ours.

This prevents NDR spam.

This error occurs when PDS’s sending side tries to send mail to Postini (masters’s mx record).

During the smtp communication, the “no such user” occurs and the bounce occurs.

Notice that the response here is 5.0.0, not 5.1.1 as seen above

So to summarize, to reduce/eliminate NDR spam, have the first receiving device (the anti-spam appliance / service) verify the user exists before sending it onward.

That way, the receiving server can tell the sending server “no such user” and reject it at that point. The NDR is generated at the sending side.