Glen's Exchange and Office 365 Dev Blog

Apart from message tracking logs one of the most useful things you can have when trying to track down message transfer problems are SMTP protocol logs. This is one thing I usually always enable on any Exchange server I’m managing. One of the things that is missing is a way in which you can manage these files over a long period of time if you leave logging enabled (something like the badmail detection and archiving would be nice actually most of the work is already done its just a matter of adaptation). So what I’ve decided to do was put together a script that would first enumerate all the SMTP virtual servers on all Exchange servers within a domain and then report on if logging was enabled, what type of logging is being used, how many logfiles are in the logging directory, how much space the log files are taking up and what the oldest log file in the directory is. Because the log settings for a SMTP VS are stored in the metabase the next part of the script uses the ADSI IIS provider ...

Now that SP2 is out in the wild and I’m starting to look more at what’s happening with SenderID (by the way if you haven't seen this already there is a great post on SenderID on the Exchange Team Blog). I wanted a way I could aggregate the information that is stored in the SMTP protocol logs so I could see for each domain that is sending me email what are the IP address’s of the mail servers and how many emails do have i recieved from each IP (and do this for a time period say the last 1-2 hours). I’ve had the beta of Monad which is the next version of the Windows Shell that will be in Vista (maybe) and E12 (downloadable for here ) installed on my machine for a while and this seemed like a good task to take it out for a test drive. The main advantage of Monad from my point of view is being able to get access to all the objects in the .NET framework so this means you can finally get access to hashtables in your scripts (Perl users have had this for years). Hashtables are very versa...

I’ve had a few questions from people recently asking about the different methods you can mail enable a folder when your running Exchange 2003 in Native Mode. The standard method for mail enabling objects programmatically is to use CDOEXM and the IRecipient Interface . To mail enable a public folder you need to combine this with a little CDOEX like this FolderURL = "http://server/public/folder/" set objFolder1 = createobject("CDO.Folder") objFolder1.DataSource.Open FolderURL, , 3,-1 Set objRecip1 = objFolder1.Getinterface("IMailRecipient") objRecip1.MailEnable objFolder1.DataSource.Save Now because this uses CDOEX which runs over Exoledb it will only work locally on an Exchange server. To do this remotely you can use the Exchange_PublicFolder WMI class I posted a sample of doing the here previously. I was curious at the way Exchange System Manger went about mail enabling folders when you where using this on a remote machine as this obviously wasn’t using ...

Reporting on rules in mailboxes and public folders can get a little challenging for the humble sysadmin. Because most the time the setting of these rules is out of your control knowing where some rules are forwarding can be a little scary (and in some cases can be against company policy or breach privacy laws). There are a few ways to manipulate rules one of the most often used is the rule.dll which can be used to create and enumerate rules while this is useful it still only offers you the hex value of the binary action property which contains the list of the recipient addresses for a forwarding rule. An active rule in a mailbox or public folders is a special message in a mailbox of type IPM.Rule.Message. In CDO 1.2 you can access these messages by using the hidden messages collection on a folder. If a rule is a forwarding rule then the email address’s the rule is forwarding to gets stored in the PR_RuleMsgActions (0x65EF0102) Mapi Property on that IPM.Rule.Message. Unfortunately this ...

Someone asked me about a script that would display details about the log files for each storage group on all the Exchange servers in their domain. While initially puzzled as to why this might be useful after a little thought the idea does bare a little fruit. Note the idea behind this is to look at the file details eg filename, date and size not the content of the file or to in anyway open or lock the files (which would be a bad thing). The general gist of the script is to enumerate the log file directory for each storage group and then count how many log files there are currently for that SG. While your counting them you can also add there sizes together to give you a figure of how much space you log files are taking up and you can also look at what the age of the oldest log file is this can let you know if your backups are working correctly and log files are being purged at the end of the backup cycle. If you start to think a little more laterally on this if where to snapshot this in...