Implementing Outlook Web Access with Exchange Server 2003

Following the implementation of Exchange Server in a company it is often desirable connect to users mailboxes using Web Access. Especially with the new release of Exchange Server it is quite interesting to use OWA because you have nearly all the functionality as Microsoft Office Outlook 2003. Within this article we provide a detailed step-by-step guide for implementing Outlook Web Access. Priority will be given to security issues at every stage of the implementation.

 

General Information

With Exchange Server 2003 you can use Standard Edition or Enterprise Edition of Exchange Server to provide Web Access with a Frontend Server. That is quite different in comparison to Exchange 2000 Server where you had to use Enterprise Edition to provide it. But before thinking of implementing a Frontend Server you should first consider your network infrastructure. Do you have a DMZ (also known as perimeter network)? What kind of firewall(s) do you have? Are you using an ISA Server 2000 or any other application layer firewall? Especially using ISA Server 2000 you have some tricky functions providing a good way to securely configure OWA Access over the ISA Server.

Preparing Exchange Server 2003 for OWA
Your Exchange Server 2003 generally behaves as Backend Server and every user has HTTP as an allowed protocol. So you do not have to configure anything on your Backend Servers unless you want to prevent some of your users from accessing their mailbox using OWA. This can be done quite easily via Active Directory Users and Computers in the user properties.

Figure 1:  Enabling OWA for a user

The next step is installing and configuring your Frontend Server. The easiest way to do this is to install it as a second Exchange Server in your organization. After that we should enable it to act as a Frontend Server. This can be generally done in the properties of your Exchange Server in Exchange System Manager.

Figure 2: Configuring a Frontend Server

If we choose this configuration the server changes from using the DAVEx process (to act as Backend Server) to the ExProx process (acting as Frontend Server). The next step is to reboot the server to make the changes take effect.
Then we should go through the following steps to make the Frontend Server a genuine Frontend by disabling all unnessecary services. On your Frontend Server you must have the following services running, every other service may be stopped without any trouble.

• HTTP-Service
• SMTP-Service
• Exchange System Attendant
• Exchange Routing Engine

You really do not need to run the Exchange Information Store, because there should not be any public folders or mailboxes on your Frontend Server. The best practice is to dismount and delete all databases on your server and then disable the Exchange Information Store Service.
After you have successfully placed this server in the perimeter network (also known as DMZ) we now have to configure the appropriate ports on the firewall(s) to make our server run.
On the intranet firewall (which connects the DMZ and the internal network) we have to open the following ports:

• For Exchange Communication:
  • Port 80 for HTTP
  • Port 691 for Link State Algorithm routing protocol
• For Active Directory communication:
  • Port 389 for LDAP (TCP and UDP)
  • Port 3268 for Global Catalog Server LDAP (TCP)
  • Port 88 for Kerberos Authentication (TCP and UDP)

Note: You should now configure the DSAccess service for perimeter networks on your Frontend Server. At first you should disable the check for available disk space at netlogon by using RPC. This can be done by changing the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
Registry Value: DisableNetlogonCheck
Value Type: REG_DWORD
Value Data: 1

In addition to this you should prevent DSAccess from pinging domain controllers. This can be done by creating the following key on your Frontend Server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
Registry Value: LdapKeepAliveSecs
Value Type: REG_DWORD
Value Data: 0

Then you should configure your Exchange Frontend Server to connect to the DC and GC you want by editing the server properties in Exchange System Manager.

• For DNS communication:
  • Port 53 for DNS (TCP and UDP)
• For RPC communication:
  • Port 135 – RPC endpoint mapper (TCP)
  • Ports 1024 and higher for RPC services

Note: You can limit RPCs across the firewall by editing the registry of all your DCs. You should now change the registry setting of the following key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters Registry Value: TCP/IP PortValue Type: REG_DWORDValue Data: (available port)

If you are using IPSec between Frontend- and Backend Servers you have to open:

• Port 500 for IKE (UDP)
• Port 51 for Authentication Header (AH)
• Port 50 for Encapsulation Protocol (ESP)

If you want to provide high availability for your Frontend Server you could do this by configuring the Network Load Balancing Service (NBL) to act as a virtual cluster. NLB will then make sure that users connect to a running Frontend Server. Then every user connecting to OWA will connect to the virtual cluster and will then be redirected to one of your Frontend Server nodes.

Implementing Security for Outlook Web Access

If you have successfully implemented your Exchange Front-End Server constellation for providing Outlook Web Access for your users, you may be concerned about security matters. HTTP connectivity is not very secure and authentication information is always on the net as clear text. In addition to this, Outlook Web Access authentication is generally session based. This means if you do not logoff and close your browser you remain logged in. Especially in public web access areas where users are unable to close the browser window it becomes quite easy for other users to read and send emails in the name of a company user.
Providing a secure HTTPS connection with an SSL server certificate is quite easy to implement. The most interesting decision is whether to use a web server certificate from an internal certificate authority or to buy one from a well-known trust center like Verisign or anyone else. This certificate must then be installed on your OWA server.

Figure 3: Installing a Web Server Certificate on an OWA Box

Now you can choose between a secure channel and a non-secure one. If you would like to require 128-bit encryption, just check the appropriate box and it runs. But do not forget that some countries have laws that only allow 40-bit encryption (e.g. France).
With a new feature in Exchange Server 2003 you can make your OWA connections more secure. This feature is called “Form-based Authentication” which means you can configure a cookie timed-out session connection. This can be quite easily implemented as shown in the following picture below.

Figure 4: Enabling Form-based Authentication

After enabling this feature you have a default setting of 10 minutes as the timeout value for a client session. Then you must re-logon to get a new cookie and new OWA access.
Note:  You can change the default timeout by changing the following registry setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA
Registry Value: PublicClientTimeout
Value Type: REG_DWORD
Value Data: (possible setting decimal)
and
Registry Value: TrustedClientTimeout
Value Type: REG_DWORD
Value Data: (possible setting decimal)

On both registry values the possible settings will vary from 1 – 4320 (minutes). After changing these settings you have to restart your W3SVC service.
With the setting of compression you have the possibility of speeding up your connections, if you can make sure that your OWA clients are aware of the following requirements:

• Windows 2000 or later
• Internet Explorer 6.0 with the cumulative of November 2002 or Netscape Navigator 6.0 or higher

Understanding the Exchange Information Store

We would like to welcome Rodney Buike to our team of authors as he presents his first article to MSExchange.org readers. The Information Store is the heart and soul of Exchange Server 2000 and 2003. Understanding the fundamentals of the Information Store is important for anyone managing an Exchange server.

If you don’t believe me, stop the Microsoft Exchange Information Store service and count the seconds before your phone starts ringing!
The Information Store is made up of a number of components. Figure 1 shows a graphical layout of a typical Exchange server.

Figure 1

Exchange 2000 and 2003 use the same Information Store but there are some differences depending on the version. Table 1 describes these differences.

Store Features	Exchange 2000* or Exchange 2003 Standard Pre-SP2	Exchange 2003 Standard /w SP2	Exchange 2000 or 2003 Enterprise
# of Storage Groups	1 + 1 RSG**	1 + 1 RSG**	4 + 1 RSG**
# of Stores	1 Mailbox store and 1 Public Folder Store per Storage Group	1 Mailbox store and 1 Public Folder Store per Storage Group	5 per Storage Group
Store Size Limit	16GB per Store	75GB per Store	16TB per Store

Table 1

* Any Exchange 2000 service pack level
**RSG = Recovery Storage Group

Storage Groups and Databases

A Storage Group will contain one or more Mailbox and Public Folder stores, depending on the version and the needs of the organization. Mailbox stores contain the user and system mailboxes and the Public Folder Store contains the Public Folders and their contents. For most organizations, a single Storage Group, with one Mailbox Store and one Public Folder Store is more than enough, however as the database grows in size, splitting one large database into multiple smaller databases can ease the management of backups.
A default Exchange installation will create a Storage Group that contains a Mailbox Store and a Public Folder Store.  Each Mailbox Store is made up of a database set that contains two files:

• Priv1.edb is a rich-text database file that contains the email messages, text attachments and headers for the users e-mail messages
• Priv1.stm is a streaming file that contains multi-media data that is formatted as MIME data.

Similarly, each Public Folder Store is made up of a database set that also contains two files:

• Pub1.edb is a rich-text database file that contains the messages, text attachments and headers for files stored in the Public Folder tree.
• Pub1.stm is a streaming file that contains multi-media data that is formatted as MIME data

For every EDB file there will be an associated STM file.
Exchange utilizes what Microsoft terms a single-instance message store. This single-instance message store works on a per database basis. What does this mean? If an e-mail message is sent to multiple mailboxes that are all in the same database, the message is stored once and each mailbox has a pointer to the message. The transaction is also logged in the transaction logs for the Storage Group that contains the database. However, if the e-mail message is sent to multiple mailboxes that are located in different databases, the message is copied to each database and written to the transaction logs for each Storage Group that contains the database with a copy of the message. 
For example, if I send 10 users a 1MB email message and all the mailboxes are located in the same database, one copy of the message is written to the database and each mailbox points to this message which will consume 1MB of disk space in total. If the 10 recipients are located in two different databases, each database will get a copy of this message which will consume 2MB of disk space. As you can see this is a much more efficient use of space as opposed to the alternative of 10 1MB messages using up 10 MB of disk space.
Aside from the database files, Storage Groups also contain system files and transaction logs. There are two system files, Tmp.edb which is a temporary database where transactions are processed, and E##.chk. The E##.chk file maintains the checkpoint for the Storage Group. The ## represents the Storage Group number with the First Storage Group file called E00.chk. This checkpoint file keeps track of the last committed transaction. If you are ever forced to perform a recovery, this file contains the point at which the replaying of transaction logs starts.

Transaction Logs

The transaction logs are some of the most crucial files when it comes to a working Exchange server. Microsoft Exchange Server uses transaction logs as a disaster recovery method that can bring a Exchange database back to a consistent state after a crash. Before anything is written to the EDB file, it is first written to a transaction log. Once the transaction has been logged, the data is written to the database when convenient.
Until a transaction is committed to the database, it is available from memory and recorded in the transaction logs. This is why you will see store.exe use up to 1GB of memory after the Exchange server has been in use for a while. After an Exchange server is brought back up after a crash, the checkpoint file points to the last committed transaction in the transaction logs which are then replayed from that point on. This form of write-ahead logging is important for you to know. 
There are four types of transaction logs:

• E##.log is the current transaction log for the database.  Once the log file reaches 5MB in size it is renamed E#######.log and a new E##.log is created.  As with the checkpoint file the ## represents the Storage Group identifier.  While the new E##.log file is being created you will see a file called Edbtmp.log which is a template for Exchange server log files.
• E#######.log are the secondary transaction logs.  They are numbered sequentially starting with E0000001.log using the hexadecimal numbering format and are 5MB in size.
• Res1.log is a reserved log file that is limited to 5MB in size.  When the disk has run out of space, transactions are written to this log file while you work on clearing up space on the disk.
• Res2.log is another reserved log with the same function as Res1.log.

Transaction logs can grow at a fast pace as each and every transaction is recorded to the log files. There are two ways to manage this growth with the recommended method being a regular full backup of the Information Store. Upon successful backup, the transactions are committed to the database and then purged. 
The other method is to enable circular logging. Circular logging is disabled by default as it only allows you to recover Exchange data since the last full backup. With circular logging enabled the transaction logs are purged as the transactions are committed to the database. If you have to restore from backup, the transaction logs will not be replayed and all transactions since that backup will be lost.
The two reserved log files, Res1.log and Res2.log, are used to “save” 10MB of space on the disk in case there is no more free space. When the disk runs out of free space, the transactions are logged to the reserve logs as the Information Store shuts down gracefully. You will not be able to restart the Information Store service until you clear up some disk space.

Best Practices

As with anything there are some best practices you can follow in order to maintain a healthy Information Store.

• Locating the Exchange program files, SMTP queues, transaction logs and database files on separate disk arrays is ideal. If budget constraints will not allow for this, locating the program files, transaction logs and SMTP queues on separate partitions on one disk array and the database files on a separate disk array will still offer some performance increases at a reduced cost.
• All files should be located on redundant disk arrays. RAID 1 is the minimum recommended level, with RAID 5 offering an increase in performance and RAID 10 offering the best performance but at an increased cost.
• Perform regular, full backups of the Information Store to commit the transactions and flush the log files. This can be done with the native Windows backup tool, NTBackup, or a third party solution. Even if you live on the wild side and do not keep backups of your data, it is important to do this to prevent the disk from filling up with log files and running out of space.
• Do not use circular logging. As mentioned circular logging will not allow you to replay the transaction logs limiting you to recovering only the data from the latest full backup set.

The Information Store is the most critical component of Exchange Server 2000/2003 and a proper understanding of its structure is important to know for anyone tasked with managing and maintaining an Exchange server. 

How to increase the Exchange Server 2003 Service Pack 2 18-gigabyte database size limit

To increase the Exchange Server 2003 SP2 database size, follow these steps:

Important Before you increase the maximum size of an Exchange database, verify that sufficient hard disk space is available for the larger database.

1. On the computer that is running Exchange 2003 SP2, click Start, click Run, type regedit, and then click OK.
2. Click one of the following registry subkeys, as appropriate for the store that you want to increase:
   • For a mailbox store, click the following registry subkey:
     HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Server name\Private-Mailbox Store GUID
   • For a public folder store, click the following registry subkey:
     HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Server name\Public-Public Store GUID
3. On the Edit menu, point to New, and then click DWORD Value.
4. In the New Value #1 box, type Database Size Limit in Gb, and then press ENTER.
5. Right-click Database Size Limit in Gb, and then click Modify.
6. Click Decimal, and then type an integer from 1 to 75 in the Value data box.
   
   Note These integer values represent the maximum size of the database in gigabytes (GB). For example, a value of 75 represents a database that has a maximum size of 75 GB.
7. Click OK, and then exit Registry Editor.
8. Restart the Microsoft Exchange Information Store service. To do this, follow these steps:
   1. Click Start, click Run, type cmd, and then click OK.
   2. At the command prompt, type the following command, and then press ENTER:
      net stop msexchangeis
   3. After the Microsoft Exchange Information Store service has stopped successfully, type the following command, and then press ENTER:
      net start msexchangeis
9. Examine the Application log to verify that the database size has been set successfully. To do this, follow these steps:
   1. Click Start, click Run, type eventvwr, and then click OK.
   2. In the Event Viewer tool, click Application.
   3. Double-click event ID 1216 to verify that the database size has been set successfully

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.

Excel 2003 Slow Opening From Network Share

Recently a user was having issues opening excel files , were by a 600kb file could take around 20 seconds to open. When you copied this file locally to the computer it opened it straight away , and other computers accessing the file had no problem. What I did notice was when you opened the file , the network usage would spike to 7mb/s for the entire time while only retrieving a 600kb file. Opening .pdf / .doc files around double or triple the size would open instantly A bit of research online only proved the fault/fix with a Windows 7 setup accessing office 2003 documents http://support.microsoft.com/kb/982860 I tried the “Under the registry entry, disable these two registry keys: Right-click Enablesecuritysignature, and then click Modify. Type 0 in the Value data box and then click OK. Right-click Requiresecuritysignature, and then click Modify. Type 0 in the Value data box and then click OK.” However no success , my setup however was Windows XP and Office 2003. After much searching the fix was actually pretty recent from microsft http://support.microsoft.com/kb/2570623 “reduces performance due to the network traffic when reading in the parts of the workbook” So upgrade to 2007/2010 or disable OFV!

You can perform the below fix manually , or I have create a .re file which does it http://www.pariswells.com/upload/fix.zip

You can use the EnableOnLoad registry entry to configure how you want Excel to handle opening workbooks for the OFV. By default, the EnableOnLoad entry is not present in the Windows registry. To add the EnableOnLoadentry to the Windows registry, follow these steps:

1. Exit Excel.
2. Click Start, click Run, type regedit, and then click OK.
3. Locate and then click to select the following registry key: **EDIT** Thanks to Frank in the comments , the proper key is ” HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\11.0″ Old key “HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\”
4. After you select the key that is specified in step 3, point to New on the Edit menu, and then click Key.
5. Type Excel, and then press ENTER.
6. Select Excel, point to New on the Edit menu, and then click Key.
7. Type Security, and then press ENTER.
8. Select Security, point to New on the Edit menu, and then click Key.
9. Type FileValidation, and then press ENTER.
10. Select FileValidation, point to New on the Edit menu, and then click DWORD Value.
11. Type EnableOnLoad, and then press ENTER. Note: The default value is 0 which disables the validation.
12. On the File menu, click Exit to quit Registry Editor.

How MX Records Work

What is an MX record?

An MX record tells senders how to send email for your domain.

When your domain is registered, it’s assigned several DNS records, which enable it to be located on the Internet. These include MX records, which direct the domain’s mail flow. Each MX record points to an email server that’s configured to process mail for that domain. There’s typically one record that points to a primary server, then additional records that point to one or more backup servers. For users to send and receive email, their domain's MX records must point to a server that can process their mail.

To filter email through the message security service, you must insert new records that point to the message security service's servers.

 

Where are my MX records?

Your authoritative MX records are on your DNS provider's server. When you change the MX record on your DNS provider, other servers will make copies of these updated MX records over time.

 

How can I see my MX records?

 To check your current MX records, follow these steps:

1. Search for "MX lookup" on Google.com.

2. Select a search result from the list.

3. Type your domain name in to the field.

4. Select MX records if it's not the default search query.

5. Click Lookup.

 

How do I update my MX records?

If your company has its own DNS servers, talk to your DNS administrator. Otherwise, contact your domain name provider.

For detailed instructions on how to update your MX records, see Change Your MX Records

 

Why should I update MX records?

For the message security service to work, we need you to route your mail to us. When you update your MX records, we accept your mail, filter out the bad mail, and pass the good mail on to your server.

 

When should I update my MX records?

During activation, you'll receive a message telling you it's time to update your MX records.

If you're adding more domains later on, update your MX records after you've added the domain in the Administration Console. Until your domain is set up in the Administration Console, mail will bounce if you update your MX records.

 

What's the format of an MX record?

An MX record includes the following fields:

Name: The name of your domain.

Class: This is always set to IN, which stands for Internet.

Type: For MX records, this is always set to MX.

TTL: "Time to Live." How long it will take to update the record. This is measured in seconds. A TTL of 3600 seconds means records will take an hour to update. A TTL of 86400 means records will take a day to update. A higher TTL value means less traffic load for the DNS server, but it also means that changing the MX records will take longer.

Preference or Priority: The order of preference for mail delivery. Sending servers should try the lowest preference number first, then the next lowest, and so on.

Data: The host name of the mail server that handles mail for that domain.

For instance, if your domain is jumboinc.com, your MX records might look like this:

jumboinc.com. IN MX 86400 1 jumboinc.com.s7a1.psmtp.com.

jumboinc.com. IN MX 86400 2 jumboinc.com.s7a2.psmtp.com.

jumboinc.com. IN MX 86400 3 jumboinc.com.s7b1.psmtp.com.

jumboinc.com. IN MX 86400 4 jumboinc.com.s7b2.psmtp.com.

Every DNS host has a different user interface for MX records. Some use a trailing period and some don't. Some allow you to set your TTL and some won't. Our instructions include information for most common MX hosts, but yours may be different. If you're not sure what to enter, use the same format as your existing MX records. Be sure that the message security service MX records have the first priority; the exact numbers don't matter as long as the message security service MX records are the first. If your DNS server allows fewer than 4 records, enter as many as you can.

For detailed instructions on how to update your MX records, see Change Your MX Records.

 

Why do I need four separate MX records?

We use redundant MX records as a backup in case any problem occurs. They give our network more flexibility if any changes to architecture are necessary.

 

Should I update A records when routing mail to the message security service?

Do not update your A records. Since your MX records point to psmtp.com, you do not need to change any A records.

 

Can I keep MX records pointed directly to my mail server as a backup?

Yes. If you want to keep a direct MX record for your mail server as a backup, you can, but be sure to leave it at the lowest priority, after all four psmtp.com records. Leaving your own mail server in the MX records should be a temporary backup measure, because spammers sometimes try to bypass the service and connect directly to your mail server using your backup MX records. Once your mail is flowing through the message security service successfully, consider changing your MX records to remove this backup.

 

How long do MX record updates take?

MX record updates are not immediate. After you've updated your MX records, it will take a while for every sender to use the new MX records. Your original TTL setting determines how long (in seconds) this will take. Changing the TTL setting won't speed this up.

 

Will I lose mail after changing MX records?

No. As long as you enter the MX records correctly, you won't lose any MX records. While your MX records are changing over, some mail will be delivered using your old MX information, and some mail will be delivered using your new MX information, but all of it will be delivered.

 

What happens if I type the wrong information into the MX record?

If you type the incorrect delivery information in the MX record, some mail will bounce. The sender will receive a notice that the mail wasn't delivered. If this happens, correct the MX records as soon as possible. Some mail may still bounce for a period of time (up to the length of the new TTL setting), but the sooner you update the MX records to the correct setting, the fewer messages will bounce.

 

What happens when I update my MX records?

Once you update your MX records, mail will start flowing through the message security service. After your old previous TTL (in seconds) has expired, all your mail flows through the message security service. When your mail flows through the service, mail is bounced from IP addresses known to be a major source of spam attacks or viruses. Also, if you have Non-Account Virus Blocking, mail to users will be filtered for viruses as well. You'll get complete mail filtering after you've added your users.

 

How can I tell if the MX update worked?

Send a test message from an outside address, then view the full headers. The full headers are about 20-50 lines of text. If the headers include the word "psmtp.com" then the mail flowed through the message security service.

Record Monitor Screen in VLC

This tool will record each mouse-click and save it as an image, then compile everything into HTML (more specifically, a Microsoft MHT file). However this is not a video capture tool. As far as I know, there isn't one built-in to Windows.
You may look into downloading the free VLC player. With VLC, you can use your desktop as a capture device:

1. Click Media
2. Click Open Capture Device
3. Choose Capture Mode: Desktop (at this point, you may want to set a higher FPS)

..and then stream it to a file:

1. Click icon to the left of play
2. Stream
3. Hit next, then click Add next to the dropdown (make sure File is selected)
4. Choose a filename and click Stream

Hope this helps.

What Is Windows Server Update Services (WSUS)?

WSUS Overview

Windows Software Update Services (WSUS), is Microsoft's upcoming free patch management tool. WSUS is essentially the next version of Microsoft's free patch management tool, replacing Software Update Services or SUS. WSUS provides a number of new features including targeting of patches to specific groups of machines, support for more produts (e.g Office), and improved reporting.

In beta for over a year, RC of WSUS released on 22 March 2005. WSUS RTM is expected to be released during the first half of 2005 (e.g. by end June 2005).  Service Pack1 for WSUS, which provides support for Windows Vista, new versions of the database and performance increases was released at the beginning of June 2006. More details on this release are available here. For more information on the background to WSUS and Microsoft's approach to patch management see WSUS Background.

WSUS is a service you run inside your organisation - on one or more servers which you configure to serve software updates to one or more AU clients. You can configure a WSUS server to download updates either from Microsoft or from another WSUS server within your organisation. Once you approve an update for installation, WSUS downloads it from configured upstream partner, and can then issue these updates to clients that request it. You can approve any update for some, all, or none of your computers. Once an update is approved, the targeted WSUS clients download the update using the Windows AU client. WSUS also provides reports on which clients have, and have not, had which updates.

WSUS provides a capability that allows the Windows AU client to obtain and install updates. However, it does not provide an internal version of the Windows Update site, thus your users can not navigate to your WSUS server and obtain updates (as they can when they navigate to Microsoft's Windows Update site).

You administer WSUS from the WSUS administration console: http://<WSUSServerName>:<port number>/WsusAdmin/. On your WSUS server you can also click Start, point to All Programs, point to Administrative Tools, and then click Microsoft Windows Server Update Services. Note that if you do not add your WSUS administration Web site name to the list of sites in the Local Intranet zone in Internet Explorer, you might be prompted for credentials each time you open the WSUS administration console.

WSUS also supports the option to Allow local administrator to use the Automatic Updates control panel applet to select a configuration option of their choice. Note that Local Administrators are not allowed to disable Automatic Updates. The setting Allow local administrator to choose setting only appears if Automatic Updates has updated itself to the version compatible with WSUS.

Q: Where does this option appear?

 

WSUS Updates
As noted above, WSUS enables you to download updates from Microsoft and distribute these to your clients. There is no support in WSUS for adding additional updates, e.g. for updates to 3rd party or your own applications, etc.

For WSUS, Microsoft intent to provice several different levels of updates (from crticial security patches to updated drivers). Support is provided for some, but not all, Microsoft products. For details on what products and levels of update are supported see WSUS Supported Updates

WSUS Database

The WSUS service makes use use of an SQL database, which is either supported by SQL Server or by MSDE/WMSDE (see WSUS Database for more details on the WSUS Database). Each WSUS server requries a separate database, thus if you plan to suppor multiple WSUS servers in your environment, you need to support multiple WSUS databases. If you are installing WSUS on Windows Server 2003 operating system or later, you can install WMSDE included in WSUS Setup. If you are installing WSUS on Windows 2000 Server operating system, install the MSDE database software prior to installing WSUS. The WSUS database stores the following types of information:

• WSUS server configuration information
• Metadata that describes each update
• Detailed Information about clients, updates, and client interaction with updates

The metadata for an update describes the update, lists the files required to install the update, and contains the relevant end user license agreement (EULA) for that update. Metadata is small, typically much smaller than the update itself, and is downloaded when you synchronise a WSUS server. An update, however, is only downloaded when it has been approved for installation.

Client Targeting

A key feature in WSUS is the ability to target updates to specific computers. WSUS enables you to create one or more target groups, to populate the target group with appropriate computers, and then approve updates for each target group independently. There are two default target groups All Computers and Unassigned Computers but you can add as many target groups as needed to support your approach to client targeting.

Update Approval

WSUS offers a number of features associated with approving updates, including setting deadlines for updates to be completed and uninstalling updates. A WSUS server first downloads download metadata, which allows the administrator to choose which updates to approve either for detection or installation. Updates can also be declined. The actual update is only downloaded to the WSUS server when you approve the update for installation.

Once you have approved update to members of one more Target group, computers belonging to the groups check in with the WSUS server and either check or deploy the approved updates. You can subsequently use WSUS reporting to determine the status of those updates.

For more informaiton on Update Approval, see Approve Updates.

Bandwidth Conservation

Updates distributed via WSUS can be very large (Windows XP SP2 for example is over 200 MB). WSUS attempts to be as bandwidth friendly as possible. First WSUS downloads update metadata. This is done independently of the update itself, which is downloaded only after it has been approved for installation.

And WSUS also provides supports servers that are not directly connected to the Internet. In this scenario, you first download updates to an Upstream server, then hand-carry media to disconnected servers running WSUS, and using the export/import feature to import the updates into your disconnected WSUS server.

For more information on how WSUS conserves bandwidth, see Bandwidth Considerations.

Firewall Considerations

If there is a firewall between the network you are running WSUS on and the Internet, you need to allow both HTTP and HTTPS traffic (port 80 for the HTTP protocol and port 443 for HTTPS) from your WSUS server to a limited set of sites, as follows:

• http://windowsupdate.microsoft.com
• http://*.windowsupdate.microsoft.com
• https://*.windowsupdate.microsoft.com
• http://download.windowsupdate.com
• http://*.download.windowsupdate.com
• http://*.windowsupdate.com
• http://wustat.windows.com
• http://ntservicepack.microsoft.com

Q: Where does this list come from? Is there a web link to this list that can be placed here to provide more authority?
A: see page 13 of Step-by-step guide to getting started with Microsoft Windows Update Services document from http://go.microsoft.com/fwlink?LinkId=39496

IIS Considerations
By default, WSUS installs into the default Web site in IIS (i.e on port 80). WSUS Setup gives you the option of creating a Web site on a custom port, the default being 8530. This allows you to run all WSUS traffic on a separate port, which may be helpful for internal firewalls.

During installation, WSUS stops, then starts the relevant web site. This includes the default default Web site if that was used. If you already have a Web site on the computer where you intend to install WSUS, use the setup option for creating a custom Web site. Note that if you install WSUS to port 8530, you have to manually set up the folder structure like, selfupdate virtual directory on port 80 to enable client self update using InstallSelfupdateOnPort80.vbs from installation folder.

Finally, ensure that the IWAM_ account is added to the Domain Administrators account on the WSUS Server. The IWAM account contains the ASPNET account used to start the WSUS service.
Mobile Clients
You can deploy an "internet facting" WSUS server outside your corporate firewall in order to distribute updates to mobile clients which are licensed to the same party as the WSUS server.  See Implementing WSUS with ISA Server 2004 to manage remote clients white paper on Microsoft's WSUS TechNet site.

You can, of course, enable the clients to create a VPN into the corporate network, and once connected use your WSUS server to receive update approvals that are then downloaded either from your WSUS server for from Micrososft's servers.
Migration From SUS to WSUSIf you have already deployed SUS in your network, WSUS has a migration tool, Working with WSUSUTIL, that you can use to migrate approvals and updates from SUS to your WSUS server. This avoids re-downloading the patch content.

You cannot migrate any of the WSUS Service settings or IIS settings. Additionally, migration is a one-way process - you cannot migrate from WSUS to SUS. If you plan to install the WSUS server on a server already running SUS, then the WSUS installation process sets up WSUS to use an alternate port.>

what is patch management in windows?

Patch management is an area of systems management that involves acquiring, testing, and installing multiple patches (code changes) to an administered computer system. Patch management tasks include: maintaining current knowledge of available patches, deciding what patches are appropriate for particular systems, ensuring that patches are installed properly, testing systems after installation, and documenting all associated procedures, such as specific configurations required. A number of products are available to automate patch management tasks, including RingMaster's Automated Patch Management, PatchLink Update, and Gibraltar's Everguard.
Like its real world counterpart, a patch is a "make-do" fix rather than an elegant solution. Patches are sometimes ineffective, and can sometimes cause more problems than they fix. Patch management experts, such as Mark Allen, CTO of Gibraltar Software, suggest that system administrators take simple steps to avoid problems, such as performing backups and testing patches on non-critical systems prior to installations.

Summary: This How To explains patch management, including how to keep single or multiple servers up to date. Additional software is not required, except for the tools available for download from Microsoft.
Operations and security policy should adopt a patch management process. This How To defines the processes required to create a sound patch management system. The patch management process can be automated using the guidance in this How To.

Contents

This How To shows you how to implement each phase of the patch management process. These phases include:
What You Must Know Before You Begin Detecting Assessing Acquiring Testing Deploying Maintaining Additional Resources

What You Must Know

Before using this How To, you should be aware of the following issues and considerations.

The Patch Management Process

Patch management is a circular process and must be ongoing. The unfortunate reality about software vulnerabilities is that, after you apply a patch today, a new vulnerability must be addressed tomorrow.
Develop and automate a patch management process that includes each of the following:

• Detect. Use tools to scan your systems for missing security patches. The detection should be automated and will trigger the patch management process.
• Assess. If necessary updates are not installed, determine the severity of the issue(s) addressed by the patch and the mitigating factors that may influence your decision. By balancing the severity of the issue and mitigating factors, you can determine if the vulnerabilities are a threat to your current environment.
• Acquire. If the vulnerability is not addressed by the security measures already in place, download the patch for testing.
• Test. Install the patch on a test system to verify the ramifications of the update against your production configuration.
• Deploy. Deploy the patch to production computers. Make sure your applications are not affected. Employ your rollback or backup restore plan if needed.
• Maintain. Subscribe to notifications that alert you to vulnerabilities as they are reported. Begin the patch management process again.

The Role of MBSA in Patch Management

The Microsoft Baseline Security Analyzer (MBSA) is a tool that is designed for two purposes: first, to scan a computer against vulnerable configurations; and second, to detect the availability of security updates that are released by Microsoft.
In this How To, you use MBSA without scanning for vulnerable configurations. When using the graphical user interface (GUI), specify this by unchecking the options in Figure 1 and only choosing Check for security updates.

Figure 1

MBSA scan options
When using the command line interface (Mbsacli.exe), you can use the following command to scan only missing security updates.

Mbsacli.exe /n OS+IIS+SQL+PASSWORD

The option /n specifies the checks to skip. The selection (OS+IIS+SQL+PASSWORD) skips the checks for vulnerabilities and weak passwords.
For more details about using MBSA, including the security configuration scan, see "How To: Use MBSA" in the How To section of this guide.

Backups and Patch Management

You should perform backups prior to deploying an update on production servers. Regularly test backups as well as your backup process. Discovering that your backup process is broken during restoration can be devastating.

Before You Begin

This section provides information about downloads and documentation that are needed before you walk through the steps in this How To.

Tools You Will Need

You need the following tools in order to be able to perform the steps in this How To:

• Microsoft Baseline Security Analyzer (MBSA) Download MBSA from the MBSA Home Page: http://www.microsoft.com/technet/security/tools/Tools/mbsahome.asp
• Latest Mssecure.cab By default, MBSA downloads the latest update list (Mssecure.cab) from Microsoft.com. If you do not have Internet access from the computer running MBSA, you must download the file and copy it to the MBSA installation directory. You can download the update file from: http://technet.microsoft.com/en-us/security/cc184923.aspx
• Microsoft Software Update Service (SUS) Microsoft Software Update Services (SUS) Server 1.0 Service Pack 1 (SP1) enables administrators to deploy critical updates to Windows 2000-based, Windows XP, and Windows Server 2003 computers. You can download it from: [Content link no longer available, original URL:"http://www.microsoft.com/downloads/details.aspx?FamilyId=A7AA96E4-6E41-4F54-972C-AE66A4E4BF6C&displaylang=en"]

Detecting

Use MBSA to detect missing security patches for Windows 2000, Windows XP, and Windows Server 2003. You can use MBSA in two modes; GUI and command line. Both modes are used to scan single or multiple computers. The command line can be scripted to run on a schedule.

Note   The login used to run MBSA must be a member of the Administrators group on the target computer(s). To verify adequate access and privilege, use the command net use \\computername\c$ where computername is the network name of a machine which you are going to scan for missing patches. Resolve any issues accessing the administrative share before using MBSA to scan the remote computer.

To manually detect missing updates using the MBSA graphical interface

1. Run MBSA by double-clicking the desktop icon or by selecting it from the Programs menu.
2. Click Scan a computer. MBSA defaults to the local computer. To scan multiple computers, select Scan more than one computer and select either a range of computers to scan or an IP address range.
3. Clear all check boxes except Check for security updates. This option detects uninstalled patches and updates.
4. Click Start scan. Your server is now analyzed. When the scan is complete, MBSA displays a security report and also writes the report to the %userprofile%\SecurityScans directory.
5. Download and install the missing updates. Click the Result details link next to each failed check to view the list of uninstalled security updates. A dialog box displays the Microsoft security bulletin reference number. Click the reference to find out more about the bulletin and to download the update.

To detect missing updates using the MBSA command line interface

• From a command window, change directory to the MBSA installation directory, and type the following command:

  mbsacli /i 127.0.0.1 /n OS+IIS+SQL+PASSWORD
  

  You can also specify a computer name. For example:
  

  mbsacli /c domain\machinename /n OS+IIS+SQL+PASSWORD
  

  You can also specify a range of computers by using the /r option. For example:
  

  mbsacli /r 192.168.0.1-192.168.0.254 /n OS+IIS+SQL+PASSWORD
  

  Finally, you can scan a domain by using the /d option. For example:
  

  mbsacli /d NameOfMyDomain /n OS+IIS+SQL+PASSWORD
  

To analyze the generated report

1. Run MBSA by double-clicking the desktop icon or by selecting it from the Programs menu.
2. Click Pick a security report to view and open the report or reports, if you scanned multiple computers.
3. To view the results of a scan against the target machine, mouse over the computer name listed. Individual reports are sorted by the timestamp of the report.

As previously described, the advantage of the command line method is that it may be scripted and scheduled to execute. This schedule is determined by the exposure of your systems to hostile networks, and by your security policy.

MBSA Output Explained

The following example was taken using the MBSA version 1.1.

Figure 2

Screenshot of the report details for a scanned machine
The top portion of the MBSA screenshot shown in Figure 2 is self explanatory.
Red crosses indicate that a critical issue has been found. To view the list of missing patches, click the associated Result details link.
The results of a security update scan might show two types of issues:

• Missing patches
• Patch cannot be confirmed

Both types include links to the relevant Hotfix and security bulletin pages that provide details about the patch together with download instructions.
Missing patches are indicated by a red cross. An example is shown in Figure 3.

Figure 3

Missing patch indication
When a patch cannot be confirmed, it is indicated by a blue asterisk. This occurs when your system has a file that is newer than the file provided with a security bulletin. This might occur if you install a new version of a product that updates a common file.

Figure 4

Patch cannot be confirmed indication
For updates that cannot be confirmed, review the information in the bulletin and follow the instructions. This may include installing a patch or making configuration changes. For more information on patches that cannot be verified by MBSA, see Microsoft Knowledge Base article, 306460, "HFNetChk Returns Note Messages for Installed Patches."

Assessing

With the list of missing patches identified by MBSA, you must determine if the vulnerabilities pose a significant risk. Microsoft Security Bulletins provide technical details to help you determine the level of threat the vulnerability poses to your systems.
The details from security bulletins that help you assess the risk of attack are:

• Technical details of requirements an attacker needs to exploit the vulnerability addressed by the bulletin. For example, an attack may require physical access or the user must open a malicious email attachment.
• Mitigating factors that you need to compare against your security policy to determine your level of exposure to the vulnerability. It may be that your security policy mitigates the need to apply a patch. For example, if you do not have the Indexing Service running on your server, you do not need to install patches to address vulnerabilities in the service.
• Severity rating that assists in determining priority. The severity rating is based on multiple factors including the role of the machines that may be vulnerable, and the level of exposure to the vulnerability. For more information about the severity rating system used by the security bulletins, see the TechNet article, "Microsoft Security Response Center Security Bulletin Severity Rating System" at http://www.microsoft.com/technet/security/bulletin/rating.mspx
  

  Note   If you use an affected product, you should almost always apply patches that address vulnerabilities rated critical or important. Patches rated critical should be applied as soon as possible.

Acquiring

There are several ways you can obtain patches, including:

• Using MBSA report details. MBSA links to the security bulletin that contains the patch, or instructions about obtaining the patch. You can use the link to download the patch and save it on your local network. You can then apply the patch to multiple computers.
• Windows Update. With a list of the updates you want to install, use Internet Explorer on the server that requires the patch, and access http://windowsupdate.microsoft.com/. Then select the required updates for installation. The updates are installed from the site and cannot be downloaded for installation on another computer. Windows Update requires that an ActiveX control is installed on the server (you will be prompted when you visit the site if the control is not found.) This method works well for standalone workstations or where a small number of servers are involved.
• HotFix & Security Bulletin Search. MBSA includes the Microsoft Knowledge Base article ID of the corresponding article for a given security bulletin. You can use the article ID at the HotFix and Security Bulletin Search site to reach the matching security bulletin. The search page is located at http://www.microsoft.com/technet/security/current.aspx. The bulletin contains the details to acquire the patch.

Testing

If the results of your assessment determine that a patch must be installed, you should test that patch against your system to ensure that no breaking changes are introduced or, if a breaking change is expected, how to work around the change.

Methods for Testing Security Patches

Methods used to test the installation of security patches against your systems include:

• Testing security patches against a test mirror of your live server configuration and scenario. This method allows you to both test the installation offline, without disrupting service, and the freedom to test workarounds if a breaking change is introduced, again without disrupting service.
• Testing the patch on a few select production systems prior to fully deploying the update. If a test network that matches your live configuration is not available, this is the safest method to introduce the security patch. If this method is employed, you must perform a backup prior to installing the update.

Confirming the Installation of a Patch

Before deploying a patch to production servers, confirm that the tested patch has made the appropriate changes on the test servers. Each security bulletin includes the information you need to confirm that the patch has been installed. In each bulletin, the Additional information about this patch section contains the entry Verifying patch installation. It includes registry values, file versions, or similar configuration changes that you can use to verify that the patch is installed.

Uninstalling a Security Patch

If you need to uninstall a patch, use Add/Remove Programs in the Control Panel. If an uninstall routine is not an option for the patch and its installation introduces breaking changes, you must restore your system from backup. Make sure that your testing process also covers the patch uninstall routine.
The security bulletin lists the availability of an uninstall routine in the Additonal information about this patch section.

Deploying

If you decide that the patch is safe to install, you must deploy the update to your production servers in a reliable and efficient way. You have a number of options for deploying patches throughout the enterprise. These include:

• Using Windows Server Update Services (WSUS)
• Using Systems Management Server (SMS)

Using Windows Server Update Services (WSUS)

WSUS provides a way to automatically deploy crucial updates and security rollups to computers throughout a network, without requiring you to visit each computer or write script. For more information about WSUS, see "Windows Server Update Services Product Information" at http://technet.microsoft.com/en-us/wsus/bb466202.aspx.

Using Systems Management Server (SMS)

SMS is an enterprise management tool for delivering configuration and change management of Microsoft Windows server and workstation operating systems. For more information about using SMS to deploy updates, see TechNet article, "Patch Management Using Microsoft Systems Management Server" at http://technet.microsoft.com/en-us/solutionaccelerators/default.aspx.

Maintaining

Bringing your servers up to date with the latest patches is part of the patch management cycle. The patch management cycle begins again by knowing when new security vulnerabilities are found and missing security updates become available.
Keeping your servers up to date with the latest security patches involves this entire cycle. You start the cycle again by:

• Performing security assessments
• Using security notification services

Performing Security Assessments

Use MBSA to regularly check for security vulnerabilities and to identify missing patches and updates. Schedule MBSA to run daily and analyze the results to take action as needed. For more information about automating MBSA, see "How To: Use MBSA" in the How To section of this guide.

Using Security Notification Services

Register to receive notifications of security bulletins released by Microsoft. Use the following services:

• Microsoft Security Notification Service at http://technet.microsoft.com/en-us/security/dd252948.aspx.
• TechNet security Web site at http://technet.microsoft.com/en-us/security/default.aspx

Additional Considerations

When bringing a new service online on an existing server, run MBSA to verify the patches for the service have been applied prior to having the server and service listening on the network. For example, disconnect the network cable or apply network based rules that block the newly added service's ports.