Friday, May 28, 2004

IMF and Exchange SP1 got me

I eagerly installed the IMF into my production Exchange environment on the day it was released and unfortunately tripped over my own eagerness. I have 2 servers in a front/back-end setup and I applied SP1 to my front-end and installed IMF there and everything was okay and both installs went smoothly. My backend Server because I had clients connecting to it I wanted to wait until I could schedule an outage to apply SP1 so I didn't upgrade this straight away. Since the IMF installed okay and I couldn't find anything that told me I needed SP1 on all my Exchange servers I decided to turned it on and test it out. Well it worked "sort of" the SCL was being set fine on all the messages going though and my Back-End server was responding to this but instead of just junking all mail with the default SCL of 8 it was junking every email. Going back over all the doco I couldn't see any problems with my install so I put it down to not having SP1 on my Back-end Server. Last night I managed to get SP1 on my Back-End Server and this morning re-enabled the IMF and everything is now fine. The anti-spam Infrastructure has been around since the release of 2003 so I still find it a little weird that I had this problem but so far I like the IMF.

Thursday, May 27, 2004

Using the IMF Spam Confidence Level in ADO

With the release of the IMF (Intelligent Message Filter) for Exchange 2003 it got me thinking about how I could use the SCL (Spam Confidence Level) that the IMF stamps on messages in my Exoledb and CDO apps. Running Outlook Spy against a message that went though the IMF yielded the answer which is to use MAPI property PR_CONTENT_FILTER_SCL . To use this is in a script is would look like.

set rec = createobject("ADODB.Record") "file://./backofficestorage/"
wscript.echo rec.fields("")

To view the SCL setting in Outlook have a look at the Exchange Team Blog which has a method on how to do this

One more thing that broke as a result of a Windows 2000 to 2003 Inplace Upgrade

Several weeks ago I did an in-place upgrade of my current employers Internal Network this involved upgrading all DC’s to W2k3 and Exchange from 2000 to 2003. Most things went okay with a few odd problems mainly revolving around some Internal Apps that we have written and some other problems with MSDE (JET) and FBA on Exchange. Another one of these little problems popped up today we have an Internal Access ADP application that accessed Active directory though a a SQL view that does an OpenQuery using a Linked server in SQL. In Windows 2000 this code used to work fine from any workstation but after the upgrade to 2003 these queries would fail with ICommandPrepare::Prepare returned 0x80040e14 error. After some investigations I found the problem was being caused because of the Linked Server security settings. I had set the Linked server to use the current users credentials which when your using a Access linked table somewhere on the line gets dropped out and I believe it ends up making a anonymous query. This lead me to further investigate why this worked on 2000 and stopped working on 2003. I found that in Windows 2000 the everyone group had read access to LDAP, in Windows 2003 anonymous operations on Active Directory are now disabled see Q326690 .Well the way I ended up fixing my problem was to assign an account that my linked server queries could run under and everything was okay.

Starting to Blog

Well i thought i'd have a go at a blog so here it is i guess well to set the tone of what this blog will be I spend a lot of my time proto-typing scripts and small apps that run on Microsoft Exchange and Office Live Communication Server. So this blog is a list of my experieces in doing so which may be assistance to those trying to do the same types of things.

Like most things I hope it will get better as it goes along