SMTP Testing

Troubleshooting SMTP Connectivity

On a few occasions, I've encountered application developers having difficulty with their application when it tries to send an email via an internal Exchange (or other SMTP) server.  This email might be part of a workflow or notification of a job completing, for example.

If you want to see what's happening, outside of the developer environment, running a few SMTP commands from the developer's computer can help.

First, you need to telnet to port 25 on your Exchange or SMTP server.  Then, send an email to a sample recipient and see how you get on.  Hopefully, if there is a problem with authentication or anti-virus or something similar, you will get stopped along the way and you'll be able to troubleshoot the cause.

The commands in yellow, above, are my user input.  The rest of the text is messages that SMTP responds with.  Note that it is sensitive to spaces in the correct places and I've found that using backspace to correct typos from a Windows command prompt does not go down well.  Type carefully!

1. ehlo domain.local - here, I am announcing where I am coming from
2. mail from: sender@domain.local - this is the sender address
3. rcpt to: recipient@domain.local - this is the recipient of the email
4. data - announcing that I have finished the addressing and am about to start with the data
5. subject: Test Message - the subject line of the email
6. . - I have finished my input and the email may be sent

Getting stopped or getting different messages at different stages along this path will mean different things, but this will hopefully put you in the right direction.

Group Policy Troubleshooting

Group Policy Troubleshooting

From time to time you may find yourself trying to identify what group policy (GPO) settings have been applied to a particular user or computer and what policy they have been applied from.  The Old Faithful of group policy troubleshooting is running gpresult from a command line.  While this is the tool that has been recommended on courses for years (even up to a Windows 2008 R2 course I attended a couple of years ago), I've always found the results from this lacking in detail.

RSOP.MSC

What I find most useful is to run rsop.msc from your Start...Run box.  RSOP is Resultant Set Of Policy and it loads as a MMC snap-in.  This snap-in will let you browse through the GPO objects and it will let you see the configured settings and, crucially, the name of the policy that it has applied from.  This will help you through difficulties that you might have with understanding the hierarchy of policies from Site, Domain, OU and Local.

In this next image, you can see the names of the policies that have applied to the computer (or User Configuration, if you select the properties on that).

rsop.msc will also let you see errors that caused particular policies not to load and security settings that may also be preventing a policy from loading.

Group Policy Modeling

One failing of running rsop.msc on your local system is that Group Policy Preference settings are not visible.  These preferences were introduced to Group Policy in Windows Server 2008 and provide GUI based configuration settings.  For example, you can get very specific with local user account settings or Internet Explorer settings using Group Policy Preferences.  Unfortunately, rsop.msc hasn't caught up with this yet.

However, using the Group Policy Modeling wizard in your Group Policy Management tool on a domain controller, or through your local administrative tools, you can see what Group Policy Preferences will be applied.  You can also go through a lot of 'what if' scenarios to see what would happen if, for example, group memberships are changed.

Troubleshooting Windows Domain Account Lockouts

Troubleshooting Windows Domain Account Lockouts

Finding out why a user is continually being locked out on a particular day can be a challenge.  A person may have logged onto a computer a few weeks ago but has forgotten about it.  Identifying where rogue session is can be difficult.  On a more sinister note, a user might be locked out from time to time and know that they didn't type a password incorrectly and pinpointing the source of these lockouts is important.  The built-in filtering on the Windows Event Logs, while useful in some circumstances, isn't always the most useful at helping out with this.

Worry not!  Microsoft provide a number of tools to assist with this.  You can download them from here and the two that I'm going to talk about are Eventcomb and LockoutStatus. These two tools do two different jobs and can be very useful individually or together.

http://www.microsoft.com/en-us/download/details.aspx?id=18465

Eventcomb

Eventcomb is a event log interrogation tool that will look for events that match your criteria and output them to a file.
To search for account lockouts, use settings similar to below.  You can fill in most of these details by going to Searches, Built In Searches and selecting Account Lockouts.  Note that if you are searching on DCs that are newer that Windows Server 2008, you will need to add event IDs 4740 and 4625 to the built in list of Event IDs.
If you right-click in the window "Select to search/right click to add", you can choose all DCs in your domain.

Lockout Status

Lockout status is a handy tool for seeing when an account was locked out, what domain controller it was locked out on and when passwords are due to expire.  OK, the password expiry might need a bit of mental arithmetic by adding number of days in your maximum password age policy to the 'Password Last Set' field, but it's a great help.

These are two great utilities that Microsoft provide for free that will help you troubleshoot lockouts and identify where problems are coming from.