Reset the Trend Micro OfficeScan Unload/Uninstall Password

If your IT department has set a password that prevents you from removing or just unloading Trend Micro Office Scan from your computer, you can often make a small change to the INI file that will reset the password to "1"

Instructions

Navigate to the installed directory, like C:\Program Files\Trend Micro\OfficeScan Client. Once there, look for a file named ofcscan.ini and open it up in notepad.
Note: Sometimes the ofcscan.ini file can be found in the Windows directory instead.
Search through the file using Ctrl+F to find "Unload_Pwd", and then you should see a section that looks like this:

Change these two lines to a value of "70" (without the quotes):
Uninstall_Pwd=70 Unload_Pwd=70
When you are done the file should look like this:

Now you should be able to unload Office Scan by right-clicking on the icon and choosing Unload, or you can uninstall the software from the control panel.

When you are prompted for the password, enter "1" (without the quotes)

Note that you probably shouldn't do this as it might violate the policies and procedures set by the pointy-haired bosses at work. If you do remove Trend Micro, make sure you have some type of alternate anti-virus solution installed.

How Email Works

To help you understand how spam is sent and how SpamStopsHere blocks it, let us explain the basics of how email is sent on the Internet.

Let us assume that your email address is john@example.com and that someone sends you an email message.

The sender's server will query the public DNS (Domain Name Service) system for the DNS "MX" records for the domain example.com.

The answer to the query will typically consist of a single "MX" record, such as:

example.com.   MX   priority=10   mail1.bighost.net.

In this example, the domain example.com is probably being hosted by the company Bighost.net and mail1.bighost.net is the hosting company's mail server. Basically, this record is telling the public that all email for the domain of example.com should be delivered to the mail server mail.bighost.net, which has been assigned to handle email for the domain.

The sender's mail server then connects to mail1.bighost.net and sends it the message. The Bighost.net mail server then delivers the message locally to your john@example.com inbox and holds the message until you log in and check your email.

Going into a bit more detail, mail servers do not connect using names such as mail1.bighost.net, but rather using IP addresses (such as 64.123.38.149). So the sending mail server actually first does an "A" record DNS look up for mail1.bighost.net. This "A" record will contain the IP address of the mail1.bighost.net server. Internet traffic can only be routed by IP address, the names are just for us humans.

The receiving mail server records in the header of your email message the IP address of the sending mail server. It also records the sender's supposed email address.

Spammers often use a fake reply email address and even a fake name for their mail server. However, they cannot fake the IP address of their mail server.

More about DNS "MX" records

If your domain's web and email is hosted by a third party company, then more than likely that hosting company has set up your MX records for you. If your domain's web or email is hosted on your own servers, then the person (probably you) in charge of them or the IT department, set up the MX records.

While most domains have just one "MX" record, your domain can have multiple MX records. After you sign up for our service and receive our confirmation, you activate the service by adding three more MX records to your domain. The MX records might then be:

example.com.   MX   priority=5    example-com.relay1a.spamh.com.
example.com.   MX   priority=6    example-com.relay1b.spamh.com.
example.com.   MX   priority=10   mail1.bighost.net.
example.com.   MX   priority=20   example-com.relay1c.spamh.com.

When a mail server sends email to your domain, it first attempts to send it according to the MX record with the highest (lowest numerically) priority. If the two servers fail to establish a connection, the sending mail server tries the next highest priority MX record, until it goes through all of the MX records.

In the example above, "example-com.relay1a.spamh.com" has the highest priority and will therefore receive all mail (unless there is a connection failure). As described later, this is our mail "relay" which filters your email for spam. After we filter your email, it is then relayed back to your actual mail server, "mail1.bighost.net" in this example, set in the Control Panel. Because your actual mail server is a private configuration setting, it doesn't even need to be in the MX records, as you will read later.

A nice feature of MX records is built-in "auto-failover". If the highest priority mail server goes off-line, mail is automatically sent to the next highest priority mail server.

Therefore, if the primary anti-spam relay for your domain should go off-line due to a system failure, maintenance, or any other reason, the backups automatically take over. In the unlikely event the primary two relays for your domain went off-line, email would be sent directly to your "real" mail server. So you wouldn't lose any email, it just wouldn't be filtered for spam.

When our service is activated, you will have to change, or authorize the change of your MX records. We cannot do that for you; only you and possibly your hosting company have (legal) access to your MX records.

When changing MX records, keep in mind that the changes do not take place instantly because many DNS servers will have cached the old entry. Therefore, the changes must "propagate" through out the Internet's many DNS caches. The suggested time to cache a record "look up" is set by the "TTL" (Time-To-Live) value for your MX records but some senders' DNS caches will take a bit longer to update. A typical TTL value is 43200 seconds (12 hours) or 86400 seconds (24 hours). After the MX record changes are complete, some email will start being filtered immediately. Even more will be filtered after the TTL is past but the majority might not be filtered for up to 72 hours. This is because some DNS caching servers don't honor TTL values, but cache records for up to 72 hours.

If you don't know how to change your MX records, that is no problem. This probably just means that someone else takes care of that for your domain. We will email you the necessary information and you can simply forward the request to them (probably your email hosting company or IT department).

More about the anti-spam relays

The page SpamStopsHere Technical Details describes how our service blocks spam based on URLs, content, countries and black-lists. This is an explanation of how the relays work.

When your service is activated, you will be assigned three "relays" (servers) which must be added to your MX records. One is the "primary" relay and the others are the "backup" relays.

Since spam filtering is certainly desirable, but not mission critical, you might think that having a backup relay is overkill. There are several reasons why every customer gets backup relays:

• It allows us to perform maintenance work on one relay without disrupting your service.
• As described later, for maximum spam blocking, you can remove your "real" mail server from the MX records. In that case, a backup relay is needed for maximum reliability.
• For your peace of mind and ours. We recognize that email is now critical to any business.
• To allow us to do some load balancing.

Each relay is actually a cluster of dedicated servers that we rent from large data centers with redundant fiberoptic internet connections, 24/7 monitoring, UPS and generator backup and physical security. For maximum reliability, the primary and backup relays assigned to each customer will reside in different data centers, owned by different companies, in different regions of the United States.

When using our service, the weakest link in your email reliability is probably the reliability of the DNS servers that hold your MX records. Domains are supposed to have two DNS servers, but unfortunately both servers are often in the same room on the same Internet connection.

The SpamStopsHere.com website is database driven and resides on another dedicated server, separate from the relays. This server handles all account information, including any changes you make via the "Members" control panel. Every few minutes, this server automatically updates the databases on the relay(s) with any changes that you make in your SpamStopsHere control panel.

Options to stop even more spam (Optimal MX Records)

Adding our anti-spam relays to your MX records will typically stop 95% of all spam. By implementing the options described here, you can typically stop 98% - 99% of all spam.

Some "sneaky" spam is not sent to the highest priority MX records, but rather to the lowest priority MX records. This is an attempt to bypass spam filters, such as ours, since the "real" mail server is typically listed in the lowest priority MX record. (This probably can't happen with open relays, but only with spammers that have modified the mail server software just for this purpose.) This is often the most offensive, vulgar spam of all.

One method of reducing this sneaky spam is to "sandwich" your real mail server between our relays as in the following example MX records:

example.com.   MX   priority=5    example-com.relay1a.spamh.com.
example.com.   MX   priority=6    example-com.relay1b.spamh.com.
example.com.   MX   priority=10   mail1.bighost.net.
example.com.   MX   priority=20   example-com.relay1c.spamh.com.

Notice that both the lowest and highest priority MX records point to our service. This is the intial configuration that we recommend when signing up.

While this "sandwiching" helps, some sneaky spam will still bypass our service and hit the real mail server directly.

The solution to stopping this spam, is to remove your "real" mail server from the MX records, leaving only our relays, as in the following example MX records:

example.com.   MX   priority=5    example-com.relay1a.spamh.com.
example.com.   MX   priority=6    example-com.relay1b.spamh.com.
example.com.   MX   priority=20   example-com.relay1c.spamh.com.

Note: If your domain uses an ISP's mail server, the ISP may not allow you to remove their mail server from your MX records. Making these changes might interfere with the successful handling of your email by your ISP's mail server. You should check with them before attempting it.

Since your email then depends entirely on our servers, you will appreciate that we provide all customers with a redundant configuration on our end. While our service is designed to provide the highest reliability, we still ask that you follow these implementation guidelines:

Wait at least a few days after activating our service before removing your mail server from the MX records. Confirm that our service is working by examining the headers of typical email messages. You should see that your mail server received the message from our relay. While the change shouldn't cause even a single email to be lost, plan on making the MX change during a quiet period. Then make the change, wait for amount of time set by the TTL value (typically 12 hours), and test by sending email from another domain, e.g. Yahoo or Hotmail. If it doesn't seem to work, please call us for technical support and/or restore the original MX records. It is not necessary to contact us or even to make any changes to your SpamStopsHere control panel when removing your mail server from the MX records

To completely stop aggressive spammers from directly hitting the mail server, some of our customers have configured their firewall or email server to only accept mail (traffic to your email server's TCP port 25) from our servers. If you wish to do this, please use the Firewall Feature in the SpamStopsHere Control Panel, which when enabled will cause all of your filtered email to come from a specific list of IP addresses.

Explaining the Database size limit changes in Exchange 2003 Service Pack 2

Introduction

One of the really interesting changes that comes with Exchange 2003 SP2 is the new database size limit increase in the Exchange 2003 Standard Edition. As most of you know the Standard edition of previous Exchange versions has a hard-coded limit of 16GB, finally this has changed with Exchange 2003 SP2; the default limit per database is now 18GB but can be set as high as to 75GB! Yes you heard me right. Finally Microsoft reacts to years of yielding from frustrated Exchange Administrators (if you ask me this was something that should have been changed back when Exchange 5.5 SP4 was released). Come on, when you think about it 16GB is the limit on our MP3 player’s these days, and should definitely not be a limit to fight against on our Exchange Server(s).

So if Exchange 2003 Standard Edition with SP2 applied can be configured as high as to 75GB, why is the default limit 18GB? Well try to think about it! Most organizations running Exchange 2003 Standard Edition have provisioned their server’s current database partition(s) for 16GB databases, so configuring the database with, for example, a 50 GB limit could make a server run out of disk space.

Manipulating the Database Size Limit

Let me be honest and say it’s a bit cumbersome to manipulate the database size limit, as you’ll need to do so via registry keys (nope as some of you might have hoped for this cannot be done via the Exchange System Manager).

You can configure a logical database size (logical size means the physical size of the .EDB and .STM  files minus the logical free space aka white space in each) limit for each Exchange database by creating a DWORD registry key named “Database Size Limit in GB”. This key should be created under the following location for the mailbox database and public folder database respectively:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Private-GUID
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Public-GUID

GUID is short for Globally Unique Identifier which is a unique 128 bit number generated by Windows or a Windows application, in this case Exchange.

In Figure 1 below I’ve configured the “Database Size Limit in GB” for the Mailbox Store on an Exchange 2003 SP2 Standard Edition to a decimal value of 50, which means the database has a limit of 50GB.

Figure 1: “Database Size Limit in GB” registry key

If you wanted to set a limit of 40GB for the Public Folder Store, you would simply need to create the same key under the Public-GUID and configure it with a decimal value of 40.

Note:The new database limit increase also applies to SBS 2003 Servers with Exchange 2003 SP2 applied.

After the Mailbox/Public Folder Store has been configured with a new logical database limit, you will have to dismount/mount the given store (or simply restart the Information Store service) in order for the changes to take effect. When doing so Event ID 1216 will be logged in the Application log as shown in Figure 2 and 3 below.

Figure 2: Mailbox Store Limit set to 50GB

Figure 3: Public Folder Store Limit set to 40GB

Database Size Buffer in Percentage

Another improvement in Exchange 2003 SP2 is that when an Exchange server database has grown to within 10% of the configured database size limit a warning event is logged in the Application log. But you can change the threshold at which you want to be notified by creating a registry DWORD key called “Database Size Buffer in Percentage” under the following locations (depending on whether we're talking about mailbox or public folder stores):

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Private-GUID
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Public-GUID

You have to specify a value of 1–100 (where 1 equals 1% and so on) in the Value data field of the “Database Size Buffer in Percentage”. In Figure 4 below I’ve, for example, configured the database with a database size limit of 75GB and a warning buffer of 15%.

Figure 4: Database Size Buffer Warning threshold

If or when an Exchange server grows to within 15%, an event Warning (Event ID 9688) will be logged in the Application log.

The first time the size of a given database is above the configured limit an Error event (Event ID 9690) will be logged in the Application log, second time an additional Error event will be logged in the Application log and the database will be dismounted. When this happens you can still re-mount the database but it will be dismounted again during the next check (specified time value in the “Database Size Check Start Time in Hours From Midnight” registry key which I'll explain in the next section). So re-mounting the database should only be a temporary solution, and you should immediately take the appropriate actions necessary in order to resolve the issue.

Database Size Check Start Time

There’s also another registry key with which you can specify the time of the day that the Exchange server should check the logical database size limits based on the limits that have been configured. By default the Exchange server will check the size of each Exchange database 5 hours after midnight or more specifically at 05:00. In order to change this time you should create a DWORD registry key called “Database Size Check Start Time in Hours From Midnight” under the following location (depending on whether we're talking about mailbox or public folder stores::

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Private-GUID
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Public-GUID

Then you’ll need to specify a value of 1-24 in the Value data field, where 1 is equal to 01:00 or 1 AM and so on.

Exchange 2003 Enterprise Edition

Although the new database limit registry key’s primarily are intended for the Exchange 2003 Standard edition, they can be used with the Enterprise edition as well. As most of you know the limit of a database running on an Exchange 2003 enterprise edition is 8000 GB, but this is a theoretical limit, the actual limit is based on the hardware used for the Exchange server and any storage subsystem.

When installing Exchange 2003 SP2 on an Exchange 2003 Enterprise edition server, you can use these same registry keys as the ones mentioned in this article, the only difference is that you can configure the database limit to a value up to 8000 GB instead of 75 GB.

The Database Size Limit in GB key and DisasterRecovery switch

Should you for some reason need to restore your Exchange Server(s) using the /DisasterRecovery switch (which you can read more about in one of my previous articles), it’s important you bear in mind that you need to re-create the “Database Size Limit in GB” key’s manually after the server has been restored using this switch.

Conclusion

Finally we’re over that annoying 16GB database limit, but this doesn’t mean you simply should rush out and set the database size limit on your Exchange 2003 Standard edition server(s) to 75 GB just like that. There’s actually a reason why the Microsoft Exchange team configured it with a default limit of 18 GB, they did this because they know most organizations running the standard edition have provisioned their servers’ database partition(s) for 16GB databases. So be sure you properly plan any database size limit changes thoroughly, as failing to do so could end up in a very sad situation.

Where are My IIS Log Files Stored?

Applies to: SmarterStats 4.x

To determine where your IIS log files are stored, please perform the following steps on your server:

1. Go to Start -> Control Panel -> Administrative Tools
2. Run Internet Information Services (IIS).
3. Find your Web site under the tree on the left.
4. Right-click on it and choose Properties.
5. On the Web site tab, you will see an option near the bottom that says "Active Log Format." Click on the Properties button.
6. At the bottom of the General Properties tab, you will see a box that contains the log file directory and the log file name. The full log path is comprised of the log file directory plus the first part of the log file name.

For example, if the dialog box displayed the following values:

• Log file directory: C:\Windows\System32\LogFiles
• Log file name: W3SVC1\exyymmdd.log

Then your full log path to put into SmarterStats would be: 
C:\Windows\System32\LogFiles\W3SVC1

Make sense of your IIS logs by running them through SmarterStats IIS log analyzer. You can download the free edition of SmarterStats from the Free Web Analytics page.