Glen's Exchange and Office 365 Dev Blog

One of the new WMI classes that comes with Exchange 2003 is the Exchange_PublicFolder Class. This is actually pretty useful when it comes to managing public folders via Code. For instance being able to propagate the folder settings to all of child subjfolers http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_wmiref_me_exchange_publicfolderpropagatesettings.asp . The other cool thing with this particular class is that a lot of the WMI properties are Read-Write. This means you can actually change setting and manipulate different aspect of public folders which you would usually need to use CDOEXM for. One of these is being able to mail-enable/disable a public folder. An example of mail-enabling a public folder via WMI would look like this. First you need to query the instances of public folders to find the folder you want to modify. I’ve used the Path property to search for the folder which is the normal path to the public folder but without the root suffix so if ...

When using the IMF to do spam filtering you do get the occasional user where the SCL store threshold is set a little too high. Eg if you have the store threshold set to 6 and one user is getting a lot of SPAM that is getting a SCL of 5 having a one-off type trick to push these emails into the junk email folder can come in handy. One way to do this is using the old Rule.dll COM component to create a server side rule in the inbox. Rule.dll has been around since Exchange 5.5 and because its mapi based it still works as it did back Exchange 5.5. There’s a great reference page with a lot samples on MSDN here Some fast hard facts about using the rule.dll, Rules created using the rule.dll can’t be seen, deleted or modified using Outlook. And you still need to watch out for the 32 KB rules limit on a folder. There is a copy of the rule.dll included in one of the samples on CDOlive http://www.cdolive.net/download/ruleasp.zip or there should be a copy in the Platform SDK. So to create a Rule ba...

One of the new features (among others) in Exchange 2003 OWA is the ability for the user to now search their own contacts folder when using the address book find in OWA 2003. One other location that can be used to store contacts especially if you want to share contacts among users is in a contacts folder in a public folder tree. So I was asked to look at making this available to search in OWA like the contacts folders. This brings up the first question of how can I customize OWA I went digging though some old whitepapers and found this one about customizing OWA 2000 which is mostly still relevant to Exchange 2003. The low down from this whitepaper is the core HTML used to render OWA is stored in the wmtemplates.dll file which means that you can’t really mess with it. There are some other warnings in this whitepaper about any changes made to the .js, htc or xml files used by OWA are unsupported. But further on they give you an example of modifying one of the script files used by OWA to...

Somebody asked me this question this week and what I thought would be quite easy turned out to be a little hard. On a Exchange 2003 box there is a WMI class Exchange_Server that you can use to do this and there is a sample in the Exchange SDK here . But this WMI class isn’t available in Exchange 2000, The PSS knowledge base offers two solutions one is based on looking for event id 1217 or 1216 in the event log and the other one is to use the Guid from the Uninstall key in the registry and they supply all the Guid's for Exchange 2000 Q296587 . Unfortunately there didn’t seem to be the same information available for Exchange 2003. A check of the ExBPA which seems to be using the same method did yield all the GUID'S for Exchange 2003 as well as the SBS versions. The Exbpa actually makes quite a good scripting reference if you have a look at the “ExBPA.Config.xml” config file there’s quite a lot of good information about how they are going about retrieving various pieces of infor...

I found this one the other day while looking for something else but its something that pops up for me now and again. If you want to find out which Domain Controller your Exchange server is currently using you can use the DirectoryServer property from the IExchangeserver Interface with CDOEXM. To use it in a script its just 3 lines Set iExchSvr = CreateObject("CDOEXM.ExchangeServer") iExchSvr.datasource.open "Servername" wscript.echo iExchSvr.DirectoryServer

I've been thinking a lot about DL's over the last week or so and have been running a few idea's around about how to use them in different ways. One idea was to create a bunch of DL's by scanning though the sent items folder of a mailbox and looking at any mail that had more then a certain number of recipients. Although this sounded like a good idea when I looked into it further it seemed that these type of emails where never usually just sent to a large number of recipients but rather there was a bunch of people in the To line another bunch being CC and maybe a few BCC'd. So what I though about instead of creating DL's why not just create some template emails that where addressed with all the TO,CC and BCC address's of people you sent these type of emails to and then store all these templates in a folder within the drafts folder. Out of this idea the following script was born, It uses CDO 1.2 basically because access to the recipients collection of a messag...

In my previous post on " Listing the file sizes of all Exchange Stores on all Exchange Servers in a Domain" I used the FSO (file system object) to get the details about the size of exchange store files and drive freespace. Somebody asked a question if there was another way to do this because in their network (as in many others) for security reasons the default admin shares (eg c$ d$) have been disabled. One way you can go about this is to use WMI and the CIM_DataFile class, If you have Windows 2000 and your store files are above 2 GB you need to make sure you have applied the following hotfix http://support.microsoft.com/?id=820608 for this to work. But using the CIM_DataFile class is actually really easier it actually takes fewer lines of code then using FSO. For example to display the size of priv1.edb on a Exchange box once you know the location of the file its just two lines of code. Set edbfile = GetObject("winMgmts:!\\servername\root\cimv2:CIM_DataFile.Name='e...