Begin thinking now about Exchange’s future

by  Scott Lowe
Takeaway:
The changes due in Exchange 12 may affect the way you plan on doing business.
 
While Microsoft’s development cycles have increased in recent years, one thing is certain: Microsoft will eventually release Exchange 12, and there will certainly be some things that you need to consider before rolling out an upgrade. Yes, it’s early to be thinking about Exchange 12, but a little forethought now may help you a whole lot when the time comes when you organization needs a whiz-bang new feature found only in Exchange 12.
First, if your server’s processors are of the 32-bit-only variety, you’re going to be out of luck when Exchange 12 rolls off the production line. Microsoft recently announced that Exchange 12 will be supported only on 64-bit platforms, along with an eventual release of Longhorn Server R2. If you’re currently making plans to replace or add hardware to support your Exchange infrastructure, make sure whatever you buy is capable of handling a 64-bit operating system. Any currently shipping x86-64 (or a 32-bit processor with 64-bit extensions) will do.
When it comes to public folders, there have been rumors that public folders as you know them will be phased out in Exchange 12, with SharePoint picking up the pieces in some form. However, I doubt that this will be the case in Exchange 12. That said, Microsoft will likely soon to begin to push SharePoint for tasks currently handled by public folders. From everything I have read thus far, you can expect Exchange 12 to be the last version that supports public folders. Do bear in mind that everything is subject to change! Why do I mention this? If you’re considering planning a significant business process around the use of Exchange public folders, consider using one of the various versions of SharePoint instead. By doing so, it’s less likely that you’ll need to undertake a project to revamp the process in the next few years.
Microsoft has big plans for Exchange. With a little foreknowledge and planning, you can make decisions that will save you a little pain in the future.
 
 
 
摘要:
Microsoft’s new command line shell, known as Monad, will make its first appearance in Exchange 12. The scriptable shell can be used for automating tasks, essentially providing command line control of Exchange that goes beyond the standard Exchange System Manager.
Microsoft hasn’t yet set a final release date for Exchange 12, giving itself a window of late 2006 and early 2007. Because the new Exchange will be 64-bit online, it will require Windows Server 2003 R2 x64 Edition or the 64-bit version of Windows Server "Longhorn," which is due out in late 2007.

Network configuration: IIS SMTP mail relay service and Microsoft Exchange Server

You can use the IIS SMTP mail relay service to prevent spammers from directly interacting with your Microsoft Exchange Server!

Your Exchange Server is probably set up on your internal network to receive all mail for users in your domain for onward delivery. If you publish your Exchange Server’s SMTP service, Internet users can send messages directly to your Exchange Server. Allowing the Internet to have direct contact with your Exchange Server is never a good idea. To stop this direct contact, set up an IIS SMTP relay, and instead of publishing the Exchange Server’s SMTP service, publish the IIS SMTP Service. Now when mail destined for yourdomain.com hits the external interface of your firewall, it will be forwarded to the SMTP relay. The SMTP relay in turn forwards it to your Exchange Server. Now set your Exchange Server to send outgoing SMTP mail messages to the IIS SMTP relay server so it forwards them on to the Internet.

To secure this set up, for incoming mail, allow the IIS SMTP server to relay only to your own domains. For outgoing mail, allow the IIS SMTP server to relay to all domains. If you allow incoming mail to be relayed to all domains, spammers will take advantage of your open mail relay and you’ll process thousands of spam e-mails within a few days. A default configuration allows all computers that can authenticate to relay through the server; however, authentication requires more overhead, so it’s better to allow relay based on IP address. Since you only want to allow your Exchange Server to use the IIS SMTP Server as an open relay, add the IP address of your Exchange Server to Allow "Only the list below." You need to allow the IIS SMTP Service to act as an open relay for your Exchange Server because the Exchange Server needs to send SMTP mail to all Internet mail domains. The open relay for outbound mail is required. You also need to prevent relay for incoming messages. Do this by configuring the server to relay only messages destined to your own domain:

  1. In the Internet Services Manager console, expand the Default SMTP Virtual Server node.
  2. Right-click on the Domains node, point to New and click Domain.
  3. Select the Remote option and click Next.
  4. Type in your mail domain name and click Finish.
  5. Double-click on your new Remote Domain name.
  6. Check the option to Allow incoming mail to be relayed to this domain so that inbound mail destined for other domains is dropped by the SMTP relay.
  7. In the Route domain frame, select Forward all mail to smart host.
  8. Enter the IP address of your Exchange Server in the text box under this selection in brackets, like [192.168.1.254].

Another advantage of this set up is that you can take down the Exchange Server for maintenance without losing any incoming mail. You can also improve fault tolerance by setting up multiple IIS SMTP Servers. Another possibility would be to add an additional mail relay server to filter e-mail for spam or viruses before relaying it on to the Exchange Server.

by Michael Cobb

01 Jun 2005 | SearchSecurity.com

使用 NSlookup.exe

nslookup [-option] [hostname] [server]

Commands:   (identifiers are shown in uppercase, [ ] means optional)

 NAME            – print info about the host/domain NAME using default server
 NAME1 NAME2     – as above, but use NAME2 as server
 help or ?       – print info on common commands
 set OPTION      – set an option

    all                 – print options, current server and host
    [no]debug           – print debugging information
    [no]d2              – print exhaustive debugging information
    [no]defname         – append domain name to each query
    [no]recurse         – ask for recursive answer to query
    [no]search          – use domain search list
    [no]vc              – always use a virtual circuit
    domain=NAME         – set default domain name to NAME
    srchlist=N1[/N2/…/N6] – set domain to N1 and search list to N1, N2, and so on
    root=NAME           – set root server to NAME
    retry=X             – set number of retries to X
    timeout=X           – set initial time-out interval to X seconds
    type=X              – set query type (for example, A, ANY, CNAME, MX, NS, PTR, SOA, SRV)
    querytype=X         – same as type
    class=X             – set query class (for example, IN (Internet), ANY)
    [no]msxfr           – use MS fast zone transfer
    ixfrver=X           – current version to use in IXFR transfer request

 server NAME     – set default server to NAME, using current default server
 lserver NAME    – set default server to NAME, using initial server
 finger [USER]   – finger the optional NAME at the current default host
 root            – set current default server to the root
 ls [opt] DOMAIN [> FILE] – list addresses in DOMAIN (optional: output to FILE)

    -a          –  list canonical names and aliases
    -d          –  list all records
    -t TYPE     –  list records of the given type (for example, A, CNAME, MX, NS, PTR, and so on)

 view FILE       – sort an ‘ls’ output file and view it with pg
 exit            – exit the program

通过在命令提示符下运行 set 命令,可以在 Nslookup.exe

参考MS/KB: 200525