My experiences as an IT professional - Anything that I write here is my personal opinion and should not be officially associated with any other entity

Monday, March 21, 2005

Well, I've been on the line with Microsoft on the issue for over 3 hours now and we are still troubleshooting the issue.

Had to be persistent on not rebooting the server though. People are working on it and I can't reboot during business hours unless absolutely necessary.

Anyhow, first they turned off the antivirus apps to see if that was causing problems. No effect. Then they got someone on from the connector group and he did a bunch of baseline troubleshooting to make sure that it wasn't caused by a mail loop and of course everything "looks" normal. Now I'm on hold while they get a different group on the line.

I would think that there would be some way to look at the transaction logs to see what transactions are running that are causing the logs to be filled out at such a rapid pace.

Oh well...these things run at their own pace. I'm just glad that I was able to get things running after moving the log files.

So much for reaching a goal of 99.9% uptime though. Server was down for something like 32 hours. That hit alone puts down that metric to something like 99.85%.

One of the storage groups filled the system array with log files this weekend and basically killed the mail server.

I ended up moving the log files for that storage group to the main mailbox array, but it's still creating logs at a very fast rate (4 log files of about 5MB each a minute or more than a gig an hour). So now I have to figure out why that specific storage group is churning so much and so far I haven't found any answers.

Unfortunately, this shows weaknesses in my monitoring systems as I have nothing watching disk space at the moment. Then again, you don't exactly expect 21GB of disk space to be gobbled up by log files in less than a day.

Thursday, February 24, 2005

If you remember my problems of a week ago with a "zero hour virus" (virus that is so new that it hasn't been added to Dat files) version of Mydoom, you will recall my lament that neither McAfee's engine that Postini uses nor our own Symantec caught the new Mydoom.AZ variant.

Well Postini just announced today that they are adding a new layer of virus protection in addition to their existing McAfee protection:

"Virus Blocking: Authentium Antivirus Added as Second Virus
Engine

Enterprise Edition now provides better virus protection with the
addition of the Authentium Antivirus engine. For an added level of inspection,
Authentium scans all inbound emails which are determined to be clean by the
current McAfee Antivirus engine. The strengths of Authentium Antivirus are its
heuristic virus scanning engine, and ability to detect viruses in files that are
compressed and encrypted. Authentium provides both weekly antivirus definition
file updates and urgent updates. Perimeter Manager polls Authentium for
antivirus definition file updates every minute to ensure timely protection.

The addition of Authentium Antivirus gives Enterprise Edition two sources for
antivirus definition file updates and two heuristic techniques for catching
viruses. This augments Postini's ability to protect you from known viruses as
well as zero-hour threats (new viruses that have not yet been included in
antivirus definition files).

Authentium Antivirus protection will be rolled out to groups of customers
over the month of March. We will send a notification when the deployment to all
customers is completed. At this time, we cannot notify you individually when you
have been upgraded to Release 5.4. However, you do not need to make any changes
or configuration settings to enable Authentium Antivirus. We thank you for your
patience throughout this process."

That should take care of the issue of new viruses getting through at least from the email vector standpoint.

If spam and virus laden emails are a problem for your organization, why aren't you using Postini or some other web based solution? I don't quite understand why anyone would use Barracuda (a hardware spam filter that sits inside your network, allowing spam traffic to use up your bandwidth) as their first line of spam defense.

How do you prevent an Exchange 2003 user from sending and receiving SMTP traffic through the internet, while still allowing them to receive emails from within the Exchange organization?

In the Exchange System Management tool, you have to add the account in question deny lists in two separate places.

The first place is Message Delivery in Global Settings of your organization. Here you go to Properties and select Recipient Filtering tab, add all SMTP addresses for accounts that you want to deny receipt of internet email.

Second place is in any Internet Mail SMTP Connectors you have for your organization. Go into the Properties for each connector and select the Delivery Restriction tab. Add the accounts in question to the Reject Messages From list.

Saturday, January 22, 2005

So last week I finally got the Blackberry Enterprise Server (BES) software from Research in Motion (RIM). The install went OK. They have a pretty nice checklist of things that need to be done before BES is installed on the designated server.

Things like IIS has to be installed, you have to have an account in Exchange for the BES services to use that has specific rights and that account has to have a mailbox that works, server has to be able to resolve DNS names and the server has to be able to initiate contact to the relay servers on the web over a specific port. I'm sure there's more that you need to do, but you get the gist.

Some issues that I've run into so far: In order for over the air synching of contacts to work, the desktop software has to be running for the user of the Blackberry and the BB Handheld software must be version 4 or higher. T-Mobile is currently shipping the 7730s with version 3.7. BES has to be version 4 as well, but that is now available.

Over the air synching of calendaring can only be done while the user has a system connected to the Exchange server running the BB Desktop software.

Over the air reconcilliation of email can only be done if the Handheld software is version 4 as well.

I'm not sure how Goodlink handles synching and reconcilliation of these types of info, but if it's done over the air without the user having to run software on a PC separate from the server, I'd say that they have a big leg up even after BES 4 was released.

The 7730s themselves work fine, although if you have a lot of contacts it can take a while for the BB to sort them if you want to say change the sort method from First name to Last name. Whereas a newer Palm device seems to do this much more quickly.

The keypad on the 7730 is pretty easy to use once your brain gets used to the fact that it's a "qwerty" and not a phone keypad. The 7100Ts look like they will have a much steeper learning curve before you are able to type decent emails quickly.

The backlight, while not as strong as on the 7100T, works pretty good, especially at night. It's pretty much not needed when you are outside during the daytime.

Overall, I'd say that the interface on the 7730 is pretty easy to use, but I can see that a new user will take a bit of time getting used to using the scroll wheel and its integrated button. Of course, it's a bit different from using a Palm or Pocket PC as you can't touch the screen to navigate.

The integrated phone works good, especially with a headset. The ubergeeks out there will be missing Bluetooth support, but I personally don't care if I have a wire going up to my ear.

So, so far it's still a neat technology that enables you to keep in contact with your "customers", but it's still not perfect. I'd prefer if the email functionality actually "looked" like your mailbox on the Exchange server with all of the folders, but I'm sure that would require much more memory than the 16MB that seems to be on most of these devices.

Although it does look like you can use the BB browser to access OWA in a pinch, but it ain't pretty. :)

Friday, December 17, 2004

I've been asked recently if it's possible to prevent an Exchange user from deleting their email while still having access to it, being able to send, etc.

From what I've found and through some experimentation of Mailbox Rights it doesn't look like it can be done. In order to prevent a user from deleting emails, you basically have to take the rights to the mailbox away.

Friday, December 03, 2004

Or at least it's employees are. Got an email from one of the Exchange support people today regarding an issue that I had blogged about a while back. The issue was that Exchange 2000/2003 handle incoming SMTP emails a bit differently than what I was used to in 5.5. No longer could you set up a global domain alias (IE translate all emails coming to apples.com to oranges.com instead). In 2000/2003 you have to set up aliases in each account.

As one person mentioned there are tools to do this to existing accounts, but the Microsoft Support person gave me this link to a knowledge base article on Microsoft's website that details the strings that can be used to set up recipient policies and how to use them. Oh, this will actually change all existing accounts by adding the proper email addresses as well, but don't worry, it's not destructive for any other addresses you have entered into accounts manually.

The strings to do 1st initial last name are %1g%[email protected]<domain Name>. The strings to do first initial of all three names would be %1g%i%[email protected]<domain name>, but in our case we don't need this, all we need is @<domain name> as this gives you <username>@<domain name> and since we use a user's initals for their username, this renders out as [email protected] for instance.

Anyhow, thanks to the support person at Microsoft who sent me that article link.

Thursday, November 11, 2004

This is another example of how different Exchange 2003 is to set up versus 5.5.

As I have written before, I have two Exchange 2003 servers, one back-end server, where all the mailboxes and public folders are primarily stored and one front-end server that handles SMTP traffic, bridgehead and routing functions, OWA, replication with the 5.5 server and a few other things. The front-end server has the default SMTP virtual server and the Internet Mail SMTP Connector (Exchange 2003 version of the 5.5 IMS or Internet Mail Service). All outgoing mail from our organization goes through the Internet Mail Connector to our ISP's email relay, which is usually done to hide the internal server, but since our ISP's gateway doesn't strip off the header information of relayed SMTP emails, it's just there to offload some work from the front-end I suppose.

The problem that I ran into was that replication and other traffic going from the front-end to the back-end was getting stuck in a queue on the front-end. Everything seemed to be working OK, so I put the problem on the backburner after poking around initially.

Then I had a problem with one of the Public folders that receives email from the internet. It wasn't getting mail that it should have gotten. I finally noticed that the mail was stuck in the aforementioned queue. So I had to resolve the problem right away.

As I was poking around, I noticed that I had set the SMTP virtual server to also forward all email to our ISP's gateway. So the mail was getting stuck in the SMTP virtual server's queue because it was attempting to send to the ISP's SMTP server and that server did not recognize the domain name at all and was basically rejecting the mail. So I set the SMTP virtual server so that it would route emails as necessary instead of forwarding everything to the "smart host" and that resolved the issue.

So at least anyone who cares to search for a similar problem can come here and make sure they haven't made the same mistake. I know I won't be making that one again. :)

I currently have a mixed mode Exchange site with 1 x 5.5 server and 2 x 2003 servers. All mail boxes are on the 2003 backend server now and the 5.5 server is up and running for SMTP traffic (I was having some issues with 2003 as an SMTP server - more on that later) and is also the PDC for the old NT4 domain.

Since all mailboxes were moved, I had anyone who used OWA to change their password to meet the stricter requirements of "strong" passwords that AD has (must have 3 of the 4 requirements: upper case, lower case, numbers and symbols) and activated the accounts that had their passwords changed in AD.

Some time later, I noticed that I could no longer administer Public Folders from within Outlook when logged in as my NT4 account. If I logged in as my AD account, I could administer them, but couldn't access user mailboxes.

Today, a secretary called to let me know that she couldn't access her attorney's contact folder, which got me looking at permissions again, although her issue ended up being much simpler (was in Mail folders view in Outlook instead of Contacts or Folder List view). I happened across a KB article on Microsoft's support site that had as part of the instructions for giving an NT4 account access to a mailbox on Exchange 2003, the curious step of disabling the AD account for the mailbox in question.

So I disabled my AD account and Voila! I was able to administer the Public folders again after I went back in with Exchange System Manager and readded myself in as Owner of the folders since my mailbox had been replaced with my AD account as owner.