Showing posts with label General. Show all posts
Showing posts with label General. Show all posts

Tuesday, January 13, 2009

Exchange Server Remote Connectivity Analyzer

This looks pretty exciting... in beta though but worth keeping an eye on as it can be very useful for exchange admins... especially the amount of troubleshooting we need to do... :-)

https://www.testexchangeconnectivity.com/

Wednesday, March 19, 2008

Windows update available that will turn off the SNP

There is a new High Priority Windows update available that will turn off the Scalable Networking Pack features which are installed by default in Windows 2003 SP 2.
http://msexchangeteam.com/archive/2008/03/12/448421.aspx
You have to reboot the server after applying this update.

Tuesday, January 8, 2008

Stats Setup for monitoring the Website

Few days back, I needed to set up the monitoring for my front-end webmail server for bandwidth usage, number of hits, tracking of IP addresses, browsers etc... I looked into the number of options but inarguably found that Awstats is the best in this business.

AWStats is a free powerful and featureful tool that generates advanced web, streaming, ftp or mail server statistics, graphically. This log analyzer works as a CGI or from command line and shows you all possible information your log contains, in few graphical web pages.

The Setup consists of 5 major steps:

1. Installing Perl
2. The AWStats Setup
3. Setup IIS Logging
4. Setup AWStats Config File
5. Scheduling Log File Analysis

1. Installing Perl

Download the Perl binary for Windows. Grab the MSI version. GO ahead and run the install.
It will automatically create the Web Service Extension mapping in IIS. However you need to allow that from IIS manager.

2. The AWStats Setup

Now that Perl is installed, we can get AWStats all setup.

1. Run the Setup. Select all the defaults.
2. Copy the contents of its Bin directory to C:\Perl\Bin Folder.
3. Go into IIS Manager, create the virtual directory named stats under default Website for C:\Perl\Bin.
4. Give Execute Permissions, select Scripts and Executables from the dropdown.

3. Setup IIS Logging

Right click the website to be logged, go to properties, and then on the Configuration tab, check off
Enable Logging (if it isn’t already). Select W3C Extended Format from the dropdown, and then click Properties.
Proceed to the advanced tab and uncheck everything. There are certain items here that we’ll tick back off. Namely, the following items should be checked:

Date (date)
Time (time)
Client IP Address (c-ip)
Username (cs-username)
Method (cs-method)
URI Stem (cs-uri-stem)
Protocol Status (sc-status)
Bytes Sent (sc-bytes)
Protocol Version (cs-version)
User Agent (cs(User-Agent))
Referrer (cs(Referrer))

The IIS end is now done, the final step is to setup the AWStats.conf file.

4 . Setup AWStats Config file

It is already copied in the C:\Perl\Bin Folder directory. Copy the existing config file and save it as awstats.mywebsite.com.conf.
*mywebsite.com = name of the website you want to monitor.

The first parameter to setup is your log file item. The only important part is the final piece at the end with the date time codes. Here's the line from my config file below:

LogFile="C:\WINDOWS\system32\LogFiles\W3SVC1\ex%YY-0%MM-0%DD-0.log"

The config file and documentation say that one should specify LogFormat=2 for IIS. Unfortunately, IIS 6 does not follow this predefined format, so we’ll have to specify our own:

LogFormat="date time cs-method cs-uri-stem cs-username c-ip cs-version cs(User-Agent) cs(Referer) sc-status sc-bytes"

Then we have to specify the value of Site Domain. Site Domain must contain the main domain name, or the main intranet web server name, used to reach the web site.

SiteDomain="www.mywebsite.com"

5. Scheduling Log file Analysis

AWStats only analyzes log files when told to do so. It can easily be toggled from the command line, and running a scheduled task to do this is the best solution.

Here’s a command that look like:

c:\perl\bin\perl.exe awstats.pl -config=mywebsite.com –update


All set now, you can access the stats from http://mywebsite.com/stats



Thursday, August 30, 2007

Greylisting and Exchange

There is a potential issue between the Mail Servers that implement Greylisting and MS Exchange SMTP Servers.

Greylisting is used on some mail servers to tempfail first attempt of an email, asking the sending server to retry later. When Exchange tries to send mails to certain domains that implement ‘greylisting’, the mails fail to get delivered and an NDR is generated. Here is an example of what that NDR looks like:

"You do not have permission to send to this recipient. For assistance, contact your system administrator. server.domain.com #4.7.1 smtp;450 4.7.1 <recipient@greylistdomain.com>: Recipient address rejected: Greylisted"

The problem is that the sending Mail Servers are not delaying in response to a 450 "mailbox unavailable" response. The standard (RFC2821) specifies this as a transient condition and the sender should re-queue the message and resend it later. While it's reasonable to fail a message after receiving a number of these "transient failure" responses, the timeout before resending should be higher than 1 second - 10, 15 or 30 minutes are usual values.

By defaut, messages receiving a 4xx SMTP response are processed as a "glitch" 3 times before being put back into the queue for processing on the retry interval. So the problem is when the server resend the message 2 more times with a 1-second delay between attempts and then (presumably) fails delivery and notifies the sender that an error has occurred.

So as a workaround, we need to assertively set GlitchRetrySeconds to a value that allows the greylisting conditions to be satisfied, 120 seconds would do good in most of the cases.

How to Configure Glitch Retry Interval in Exchange Server 2003

Tuesday, July 10, 2007

Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. It is an attempt to control forged e-mail. SPF is not directly about stopping spam – junk email. It is about giving domain owners a way to say which mail sources are legitimate for their domain and which ones aren't.

The current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages.

Sender authentication protocols are designed to protect against forgery of e-mail sender identities, either in the envelope or in the header. In the envelope, first there is the "HELO" identity, which names the mail server (MTA) that is sending the message. The "MAIL FROM" identity is the e-mail address that is responsible for sending the message and where delivery errors (bounces) will eventually be reported. And the "RCPT TO" identity is the message's recipient address. The header contains another set of identities (besides other meta information about the message, such as the subject and the sending date).

SPF authenticates the envelope HELO and MAIL FROM identities by comparing the sending mail server's IP address to the list of authorized sending IP addresses published by the sender domain's owner in a "v=spf1" DNS record.

SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together:
(1) the domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then
(2) the receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.

Example of SPF Record

mydomain.com. TXT "v=spf1 mx a:machine1.mydomain.com include:gmail.com -all"

The parts of this SPF record mean the following:

v=spf1: SPF version 1
mx: the incoming mail servers (MX's) of the domain are authorized to also send mail for mydomain.com
a:machine1.mydomain.com: the machine machine1.mydomain.com is authorized, too
include:gmail.com: everything considered legitimate by gmail.com is legitimate for mydomain.com
-all: all other machines are not authorized

For detailed information on SPF records and their syntax, please refer www.openspf.org
The SPF Setup Wizard: http://old.openspf.org/wizard.html