HP Launches New, Smaller-Size ProLiant 'Scale-Out' Servers

The ProLiant SL6000 product line includes a smaller, physically lightweight, power-draw-efficient modular systems architecture -- the first major rebuild of the ProLiant server since 2001. They can be deployed with up to 672 processor cores and 10 terabytes of storage capacity per standard 42U rack.

Hewlett-Packard on June 10 launched a new line of ProLiant servers, called the ProLiant SL Extreme Scale-Out portfolio, engineered specifically for the growing Web 2.0, financial services and high-performance computing markets.

"Scale-out" is a relatively recent data center industry buzzword referring to architectures for systems running thousands of servers that are required to scale nearly ad infinitum in order to comfortably handle a massive number of online users. Amazon, Facebook, eBay and Google are Web 2.0 companies specializing in both the deployment and the optimization of scale-out architecture.

The ProLiant SL6000 product line -- which HP is also calling ExSO -- includes a smaller, physically lightweight, power-draw-efficient modular systems architecture -- the first major rebuild of the ProLiant server since 2001, John Gromala, director of product marketing for HP's industry-standard server group, told eWEEK.

They are also powerful. These new servers can be deployed with up to 672 processor cores and 10 terabytes of storage capacity per standard 42U rack, HP said. Like all HP data center products, the ProLiant SLs are built on industry standards, so they are designed to work in a mix-and-match, storage-and-computing data center environment.

Read more!

HP Launches Carrier-Grade ProLiant Servers, StorageWorks Arrays

HP is offering upgraded carrier-grade servers and storage arrays designed to help telecommunications companies and service providers more easily manage the convergence of telephony and IT. The upgraded ProLiant systems are based on Intel’s “Nehalem EP” processors, and can support a variety of OSes, including Windows, Linux, HP-UX and Solaris. Another Integrity blade system is run on Intel’s Itanium chip. The two arrays come out of HP’s StorageWorks group.
Hewlett-Packard is looking to help telecommunications companies and service providers manage the ongoing convergence of IT and telephony.



HP June 24 rolled out several new versions of its carrier-grade hardware products that offer NEBS (Network Equipment-Building System) compliance in a flexible, cost-effective package, according to Chuck Smith, vice president of BladeSystem business development at HP.

The enhanced products including the BladeSystem Carrier-Grade platform, a ProLiant carrier-grade rack-mount server and a carrier-grade storage array, and can run in both telephony and IT networks, according to HP.

HP is offering carrier-grade versions of two of its ProLiant servers running on Intel’s quad-core Xeon 5500 Series “Nehalem EP” processors. The rack-mount ProLiant DL380 G6 server offers twice the performance of previous versions and improves energy efficiency. The carrier-grade version includes two 2.53-GHz Xeons.

The ProLiant BL460c G6 carrier-grade server blade also offers twice the performance of previous systems and enhanced energy efficiency. With two 2.53-GHz Intel quad-core processors, the blade system enables a single HP BladeSystem c7000-cg enclosure to support up to 16 blades—or 32 Intel quad-core processors—in a 10U (17.5-inch) enclosure.

The Integrity BL860c carrier-grade server blade, powered by Intel’s Itanium processor, is designed to offer high scalability and performance for such applications as text messaging. The server blade is designed for the HP c7000-cg enclosure.

The platforms support a number of operating environments, including Microsoft Windows, Linux, HP’s Unix variant, HP-UX, OpenVMS and Sun Microsystems’ Solaris. In addition, HP will distribute and support Sun’s Solaris 10 on the ProLiant and BladeSystem platforms.

HP’s StorageWorks MSA2000fc G2 and MSA2000sa G2 carrier-grade storage arrays support high availability and data protection through such features as snapshots for point-in-time copies of data. They also support up to 24 146 gigabyte SAS disks (3.5 terabytes) in a 2U (3.5-inch) enclosure. They also offer businesses a choice of Fibre Channel or SAS connectivity.



“With expertise in both telecom and IT, HP provides a family of servers that combines the best of both worlds,” Smith said in a statement.
Read more!

Microsoft Exchange hosting (Solution for small business)

Intermedia provides hosted Exchange email for over 300,000 small business customers. We give you the power of Microsoft Exchange 2007 as an affordable monthly service.

Intermedia offers a range of plans to fit our customers’ needs. Just choose the package that best suits your company:

visit the web for details:
http://www.intermedia.co.uk/exchange-hosting/small-business-exchange-hosting/small-business-exchange-hosting.asp

Read more!

Microsoft Exchange hosting (Enterprise Solotion)

Intermedia gives enterprises a Fortune 500-class Exchange 2007 infrastructure, instantly, at a reasonable price. It is the sensible alternative to deploying Exchange 2007 in-house: fully-featured, secure and managed 24x7.

For thousands of companies worldwide, Intermedia provides reliable, secure Microsoft Exchange email with advanced features such as hosted BlackBerry® and SharePoint.

By outsourcing the everyday management of Exchange 2007, your company can focus IT resources on strategic projects, rather than tedious maintenance.

And because Intermedia runs an enterprise-grade infrastructure by Dell, EMC and Cisco, housed in tier-4 datacenters, your email will be more reliable as well. Intermedia guarantees an SLA of 99.999% or above, with meaningful financial penalties if we fail to meet it.

To learn why more enterprises outsource Exchange 2007 to Intermedia than to any other provider, please see why choose Intermedia.

visit the web:
http://www.intermedia.co.uk/exchange-hosting/enterprise-exchange-hosting/overview.asp

Read more!

Introduction to Hosting Exchange 2000 Enterprise Server

This session will introduce the new features and technologies in Microsoft Exchange 2000 Enterprise Server that are targeted at the application service provider business. In this high-level overview, we will discuss design, implementation, as well as management options and considerations to be taken into account when deploying Exchange 2000 as a hosted service.

This is a session that was recorded November 30, 2000 and presented by Jeff Strasser. Jeff Strasser is a Support Professional in the Microsoft Business Applications - Server group. He has focused his support efforts towards application service providers (informally known as ASPs) and Exchange 2000 issues specific to their needs. Currently, Jeff is working on the Microsoft Mobile Information Server Beta program which will allow wireless access to retrieve Exchange data.

Viewing the Presentation

Collapse this imageExpand this image

To view, please click on the link: View this Support Webcast (Length: 1 hour 16 minutes)

This Windows Streaming Media archive requires an Internet connection of 28.8 Kbps or faster, and is best viewed with a minimum screen resolution of 800 X 600.

Additional Resources

Collapse this imageExpand this image

Download presentation (http://download.microsoft.com/download/7/6/3/76321006-30f1-46ed-bd33-20f530b3763f/wc113000.exe) wc113000. This is a 549-KB Microsoft PowerPoint (.ppt) file.
If you do not have PowerPoint and you want a copy of the slides, use the PowerPoint Viewer (http://office.microsoft.com/downloads/2000/Ppview97.aspx) (1,911 KB).

Collapse this imageExpand this image

Read the transcript from this Support WebCast (http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fservicedesks%2fwebcasts%2fen%2fwc113000%2fwct113000.asp)

Collapse this imageExpand this image

Tell a friend about this Support WebCast (mailto:?subject=Support WebCast: Introduction to Hosting Exchange 2000 Enterprise Server&body=Take a look at this Microsoft Support WebCast about Introduction to Hosting Exchange 2000 Enterprise Server (November 30, 2000). More information about this WebCast is available at http://support.microsoft.com/WebCasts.)

Collapse this imageExpand this image

Supplemental reading:

• Microsoft Exchange Server website (http://www.microsoft.com/exchange/)
• Microsoft Internet Services Network, "Exchange 2000 for Service Providers" website (http://support.microsoft.com/default.aspx?scid=http%3a%2f%2fwww.microsoft.com%2fserviceproviders%2fsolutions%2f)

Provide Feedback on this Broadcast (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1073&p0=wc&p1=en-us&p2=WC113000)
Read more!

what is DNS Server

WHAT IS A DNS SERVER ?
The Domain Name System (DNS) is a standard technology for managing the names of Web sites and other Internet domains. DNS technology allows you to type names into your Web browser like compnetworking.about.com and your computer to automatically find that address on the Internet. A key element of the DNS is a worldwide collection of DNS servers. What, then, is a DNS server?


Answer: A DNS server is any computer registered to join the Domain Name System. A DNS server runs special-purpose networking software, features a public address, and contains a database of network names and addresses for other Internet hosts.
DNS Root Servers
DNS servers communicate with each other using private network protocols. All DNS servers are organized in a hierarchy. At the top level of the hierarchy, so-called root servers store the complete database of Internet domain names and their corresponding IP addresses. The Internet employs 13 root servers that have become somewhat famous for their special role. Maintained by various independent agencies, the servers are aptly named A, B, C and so on up to M. Ten of these servers reside in the United States, one in Japan, one in London, UK and one in Stockholm, Sweden.
DNS Server Hierarchy
The DNS is a distributed system, meaning that only the 13 root servers contain the complete database of domain names and IP addresses. All other DNS servers are installed at lower levels of the hierarchy and maintain only certain pieces of the overall database.
Most lower level DNS servers are owned by businesses or Internet Service Providers (ISPs). For example, Google maintains various DNS servers around the world that manage the google.com, google.co.uk, and other domains. Your ISP also maintains DNS servers as part of your Internet connection setup.
DNS networking is based on the client / server architecture. Your Web browser functions as a DNS client (also called DNS resolver) and issues requests to your Internet provider's DNS servers when navigating between Web sites.
When a DNS server receives a request not in its database (such as a geographically far away or rarely visited Web site), it temporarily transforms from a server to a DNS client. The server automatically passes that request to another DNS server or up to the next higher level in the DNS hierarchy as needed. Eventually the request arrives at a server that has the matching name and IP address in its database (all the way to the root level if necessary), and the response flows back through the chain of DNS servers to your client.
DNS Servers and Home Networking
Computers on your home network locate a DNS server through the Internet connection setup properties. Providers give their customers the public IP address(es) of primary and backup DNS servers. You can find the current IP addresses of your DNS server configuration via several methods:
· on the configuration screens of a home network router
· on the TCP/IP connection properties screens in Windows Control Panel (if configured via that method)
· from ipconfig or similar command line utility


Read more!

Microsoft Small Business Server 2003 Spam Filtering

This article takes an in-depth look at the spam filtering features provided with Microsoft SBS 2003 and how to implement them.

Unsolicited commercial email (UCE), generally known as spam, is becoming a bigger and bigger problem for each company and even home users. A lot of time has to be spent on filtering which emails are spam and which are not. So an important task of each Server Administrator who has the responsibility of the Messaging and Collaboration Server System, is to implement a good SPAM Email Filtering System.

Microsoft provides lots of features with Exchange Server 2003 Service Pack 2 to filter Spam and provides a solution to reduce the amount of time spent on filtering SPAM.

These features are included within Exchange Server 2003 and, due to this, are part of each Small Business Server 2003 Implementation within this solution.

Within this article we will now take an in-depth look at the features themselves and how to implement them.

Connection Level Protection

Protecting against SPAM at the connection level has been the best defense for years, because this means that SPAM will never enter the company’s network. This feature does nothing more than evaluate incoming SMTP connections for potential SPAM. If the connection SMTP host is a well known Spammer, the connection can be dropped.

Exchange itself provides two ways for connection level SPAM protection.

IP Connection Filtering

IP Connection filtering is a configurable setting within Exchange Server 2003 that can totally block SMTP connections based on IP-Addresses. This is a rudimentary method of protection because the connection filtering lists need to be administered manually. In addition to this you can allow special explict SMTP connections.

Figure 1: IP-Address Filtering

Real-Time Block Lists

With Exchange Server 2003, you will have a new and more dynamic way of providing connection level protection. This feature is called Real-Time Block Lists. These lists are known as SPAM sources, open relays or part of an IP range. But these lists should not include STMP hosts which are the same as a provider’s dial-up connection. This would lead to thousands of emails sent by dial-up users being rejected.

Block List providers are 3rd party organizations that collect IP addresses of internet SMTP domains. When a host initiates an SMTP session with a subscriber of a block list service, the subscriber issues a DNS query to the block list provider’s DNS Server with the sender’s host IP address. The block list server then checks whether the connecting host is on the block list or not.

To enable this feature you have to install Exchange Server 2003 Service Pack 2 because, in earlier versions of Exchange Server 2003, only the connection host was relevant and not the sending host, which meant that firewalls or SMTP hosts in between could be Spammers. This has been achieved by providing perimeter IP lists and an internal IP range configuration in Exchange System Manager.

Figure 2: Block List Filtering (1)

Figure 3: Block List Filtering (2)

Figure 4: Block List Filtering (3)

Figure 5: Block List Filtering (4)

Protocol Level Protection

Protocol level protection against SPAM is another way of filtering spam in the next layer of defense at the SMTP protocol level. The SMTP traffic between sending and receiving hosts is analyzed to verify that the sender and the recipient are allowed hosts.

Recipient and Sender Blocking

The first way of providing protocol level protection is to define individual senders or domains from who you do not want to accept messages (also known as white and black lists). Exchange Server 2003 can be configured to block blank sender addresses and filter recipients who are not in the Active Directory too.

This blocking method prevents the directory harvesting attack (DHA). Within this attack, the Exchange Server itself responds to RFC2821 RCPT TO: commands are passed in search of valid IP addresses. When it detects an email that is sent to a non-existing recipient, Exchange returns an “Unknown user”. Spammers now have the chance to sell valid email addresses or use them as recipients for unsolicited mail. This threat can be mitigated by using the tarpitting method, which is provided by Windows Server 2003 Service Pack 1. This feature allows the administrator to insert a configurable delay before returning an SMTP protocol response.

Figure 6: Sender Filtering

Figure 7: Recipient Filtering

Sender ID

One of the newest additions to Exchange Server 2003 anti-spam features is Sender ID filtering which comes with Exchange Server 2003 Service Pack 2. Sender ID attempts to verify that the sending host is approved to send messages from the SMTP domain.

There are two parts that need to be available for Sender ID to work. The first is a well-known DNS record known as sender policy framework. It defines which servers are allowed to send SMTP from this domain. The other one is an SMTP host that supports Sender ID.

Sender ID filtering can greatly reduce UCEs if the sending domains have SPF records registered in DNS, but all domains which do not have SPF records might encounter problems.

Figure 8: Sender-ID Filtering

Content Level Protection

The next option for filtering emails for SPAM is by using content level protection. This means that we can now analyze the message content looking for common clues that may indicate unsolicited email.

Exchange Intelligent Message Filter

With Exchange Server 2003 Service Pack 2, Microsoft provided a content filter called Exchange Intelligent Message Filter. It is based on patented machine-learning technology from Microsoft Research. This Smart Screen technology is already in use by MSN, Microsoft Hotmail and Microsoft Office Outlook 2003, and is called Junk Email Filtering.

Intelligent Message Filter was designed to categorize between SPAM and non-SPAM based on the characteristics of each email message.

After IMF adds a Spam Confidence Level (SCL) to the message, it then evaluates two configured thresholds:

• Gateway blocking > messages can be archived, deleted, rejected or nothing can be done
• Store junk email configuration > move emails to junk mail folder

IMF can provide anti-phishing filtering, too. It can be configured in detail using the “Custom Weighting” feature which is implemented by an XML file called MSExchange.UceContentFilter.xml and has to be saved in the same directory as the .dll and .dat files of your Exchange Server. IMF can be updated using Windows Server Update Services (WSUS).

Figure 9: Intelligent Message Filtering

Outlook 2003 and Outlook Web Access Junk E-Mail

The last step to filter Spam is to clean your Outlook client itself by using an anti-SPAM feature called Junk-Email Filtering. At first it collects the SCL information from IMF. In addition it has its own filtering feature where each user can configure their own white and black lists for SPAM.

Read more!

Exchange Server 2007 SPAM filtering features without using Exchange Server 2007 Edge Server

Using Exchange Server 2007 SPAM filtering features without using Exchange Server 2007 Edge Server Role.
Exchange Server 2007 SPAM filtering features without using Exchange Server 2007 Edge Server

Introduction

Many Exchange Server administrators know how to use features from Exchange Server 2003 which will not be available by default, if they do not use Exchange Server 2007 Edge Server Role as message hygiene server in the DMZ. This feature is only available within that role by default but can be enabled on each Exchange Server 2007 running Hub Transport Role. In this article we will have a look how to enable and configure this feature.

Activating AntiSpamAgent Feature

Adding this functionality to your Hub Transport servers is a pretty simple process. First, launch the Exchange Management Shell. In the Scripts folder that was created, you will find a PowerShell script to install the Anti-spam agents. After you run this command, you will need to restart your transport service and restart the Exchange Management Console. The script we need to run is called install-AntiSpamAgents.ps1.

Figure 1: Activating AntiSpamAgent Feature

After restarting the Exchange Transport Service, we have a new tab in Exchange Management Console available which will look like this:

Figure 2: The Anti-Spam Tab of Exchange Management Console

Note:

We will now take a closer look into each feature of Anti-Spam:

• Content Filtering
• IP Allow List
• IP Allow List Providers
• IP Block List
• IP Block List Providers
• Recipient Filtering
• Sender Filtering
• Sender ID
• Sender Reputation

Content Filtering

The Content Filter agents works with spam confidence level rating. This rating is a number from 0-9 for each message; a high SCL will mean that it is most likely spam. You can configure the agent according to the message ratings to:

• Delete the message
• Reject the message
• Quarantine the message

You can also customize this filter using your own custom words and configure exceptions if you wish.

IP Allow List

With this feature you are able to configure which IP addresses are allowed to successfully connect to your Exchange Server. So, if you probably have a dedicated mail relay server in your DMZ, you can add its IP addresses so that your server will not accept connections from other servers anymore.

IP Allow List Providers

In general, you are unable to configure your own “IP Allow Lists” without making mistakes that will lead to problems receiving emails from your customers or any other business partners. Therefore, you should contact a public IP allow list provider which does the work for you. This would mean that you will have more quality in this service and a higher business value.

IP Block Lists

This feature gives you the possibility to configure IP addresses that are not allowed to connect to your server. Contrary to “IP Allow Lists”, this feature provides a black list and not a white one.

IP Block List Providers

“IP Block List Providers” have been known in the past as “Blacklist Providers” too. Their task is to publish lists from servers / IP addresses that are spamming. If you want to read more about this, click here.

Recipient Filtering

If you need to block emails to specific internal users or domains, this feature is the one you will need. You can configure this feature and then add the appropriate addresses or SMTP domains to your black list. Another interesting feature is that it allows you to set up the configuration so that only you will accept emails from recipients that are included in your global address lists.

Sender Filtering

If you need to block specific domains or external email addresses, you will have to use this feature. You can configure a black list of what sender addresses or domains you will accept or not.

Sender ID

The Sender ID agent relies on the RECEIVED Simple Mail Transfer Protocol (SMTP) header and a query to the sending system's domain name system (DNS) service to determine what action, if any, to take on an inbound message. This feature is relatively new and relies on the need of a specific DNS setting.

Sender ID is intended to combat the impersonation of sender and domain also called spoofing. A spoofed mail is an e-mail message that has a sending address that was modified to appear as if it originates from a sender other than the actual sender of the message. Spoofed mails typically contain a FROM in the header of a message that claims to originate from a dedicated organization.

The Sender ID evaluation process generates a Sender ID status for each message. The Sender ID status is used to evaluate the SCL rating for that message. This status can have one of the following settings:

• Pass - IP address is included the permitted set
• Neutral - Published Sender ID data is explicitly inconclusive.
• Soft fail - IP address may be in the not permitted set.
• Fail - IP address is in the not permitted set.
• None - No published data in DNS.
• TempError - transient error occurred, such as an unavailable DNS server
• PermError - unrecoverable error occured, such as the record format error

The Sender ID status is added to email metadata and is then converted to a MAPI property. The Junk E-mail filter in Microsoft Office Outlook uses the MAPI property during the generation of the spam confidence level (SCL) value.

You can configure this feature to act as the following:

• Stamp the status
• Reject
• Delete

Additional information on how to setup your Sender-ID setting in your public DNS can be found here.

Sender Reputation

Sender Reputation is a new Exchange Server 2007 anti-spam functionality that is intended to block messages based on many characteristics.

The calculation of the Sender Reputation Level is based on the following information:

• HELO/EHLO analysis
• Reverse DNS lookup
• Analysis of SCL
• Sender open proxy test

Sender reputation weighs each of these statistics and calculates an SRL for each sender. The SRL is a number between 0 and 9. You can then configure what to do with the message in one of the following ways:

• Reject
• Delete and archive
• Accept and mark as blocked sender

Conclusion

As you have seen in this article, Exchange Server 2007 provides a lot of features to increase anti-spam functionality on each Exchange Server box. If you do not use a dedicated Exchange Edge Server, you can add this functionality to Exchange Server 2007 Hub Transport as described above. If you define a configuration for your specific server design, you will not have to add third party software to meet your basic business needs.

If you decide to have more than the described functions above, you should think of implementing Microsoft ForeFront Security for Exchange Servers.

Read more!

AMD plans 16-core server chip

Advanced Micro Devices is designing a server chip with up to 16 cores, quadrupling the count of its current quad-core server chips, the company said Wednesday.

Code-named Interlagos, the chip will have between 12 and 16 cores, and will be released in 2011, the company said at a press conference that was webcast. Interlagos will be a follow-up offering to the 12-core chip code-named Magny-Cours that AMD plans to release in the first quarter of 2010.

Increasing chip core counts is a way for AMD to improve performance while trying to reduce the power drawn by the processors. Adding more cores also squeezes more performance out of servers, which can reduce the total server count in data centers. That helps cut hardware acquisition and energy costs, said Pat Patla, vice president of the server platform unit at AMD.

The 16-core chips could go into servers with between two to four sockets, which could mean a maximum of 64 cores per server. The chip will be part of the Opteron 6000 series of chips, which the company said will likely be used in data-center servers.

The chips will be more for servers that handle a variety of applications -- including simulations and databases -- that need plenty of processing power, said Dean McCarron, principal analyst at Mercury Research.

"Given the consumer environment and those workloads, it will be a while before 16 cores is mainstream," McCarron said.

AMD's Opteron chips compete with Intel's Xeon server chips, but Intel has only announced an 8-core version of its Xeon chips with a chip code-named Nehalem-EX, due for release in 2010. Intel has also announced a Larrabee chip that has "many cores," but it is more for a supercomputing environment with high-end applications like 3D graphics rendering.

But there is more to chip performance than just adding cores, AMD's Patla said. The value of chips revolves around delivering a balanced computing performance and cutting energy and hardware acquisition costs, he said.

AMD in its future chips will integrate advanced power management features and instruction sets at the chip level to better execute tasks in virtualized environments. Users will be able to better control power consumption by manually capping the power drawn by cores and shutting off idle cores. AMD is also making improvements at the hypervisor levels to double the number of virtual machines that can be built on current AMD-based server chips.

Read more!

Planning for Your First Exchange Server

Considerations for installing a single Exchange server for first time Exchange admins.
let I can solve ur basic problem in my article read step by step...

Introduction

Sometimes Microsoft products can be misleading. To install one, or so it seems, all you need to do is run the setup program and press "Next" until the whole thing is over. However, there are a few considerations that should be taken into account when setting up the first Exchange server. There are IP addresses, naming schemes; there is that Active directory part, hardware considerations, Anti-virus protection and more. With a few pointers you can install your own Exchange server and rely on phone support for special issues that should not occur if you plan and execute well.

Active Directory

As you might have heard by now, Exchange relies on Active Directory. This means that users, groups and even the Exchange configuration itself is stored in Active Directory.

The server holding Active Directory is appropriately called a Domain Controller. Exchange can be installed on a domain controller. However, for redundancy, you might consider installing two domain controllers, separate from Exchange. Domain controllers require a reboot from time to time, so when you have two of them, separate from Exchange, you can do so without interrupting service to clients.

So, what is a Active Directory? Basically it's a database, just like Exchange, actually built on the same technology. Some small businesses will start using Active Directory for the first time when they implement Exchange. Previously, they had been working in a "Workgroup" where each computer has it's own security mechanism. Once Active Directory is implemented in order to make way for Exchange, all computers start using a central authentication system. This means that when you login to your Windows, you enter a username and password that is stored on the Active Directory domain controller. Active Directory can also store all kinds of information about you, and you can setup groups to implement permissions on files, database and other objects.

Once Exchange is installed, more attributes are added to Active Directory. This is referred to as "Extending the schema". This means that Exchange attributes can now be assigned to a user such as e-mail addresses, location of a user's mailbox, etc.

As an Exchange admin you should always worry about Active Directory. A lot of Exchange problems are a direct result of domain controller errors. Exchange actually uses only domain controllers that are global catalog servers for some functions. You should make sure that all the domain controllers are global catalog servers. Otherwise you might find that a problem with your first domain controller which is a global catalog server by default will cause Exchange not to service users anymore.

Global Catalog Server

By default, the first domain controller becomes a global catalog server. To set more global catalog servers:

1. Click Start, click Administrative Tools, and then click Active Directory Sites and Services.
2. Double-click Sites, expand Servers, and then select your domain controller.
3. Double-click the domain controller to expand the server contents.
4. Below the server, an NTDS Settings object is displayed. Right-click the object, and then click Properties.
5. On the General tab, make sure that the Global Catalog check box is selected (this is the default setting).

Though a restart is not a requirement anymore with Windows 2003, it is my recommendation that you still perform a reboot of the domain controller.

Beware that sometimes Exchange information replicates slowly from one domain controller to another so when setting up a mailbox for a user or change a group member you need to wait for replication to occur or replicate it yourself.

DNS

Computers on the Internet (or hosts as they are called) use DNS servers to locate servers. If you, for example, want to locate www.msexchange.org because you want to browse it's web server, you will approach your Internet provider's DNS server and it will search for this server by either using its cache or by querying a root server for the "org" domains list and from there to the server responsible for the "msexchange.org" domain which hosts the "www" server, or several servers that answer collectively as "www".

Microsoft decided to use this technology with Active Directory. In an Active Directory domain clients will have to use local DNS servers instead of the ISP servers to resolve local server names. Active Directory also hosts special records called "SRV records" for finding various services such as Global Catalog servers.

The best configuration is that you setup an Active Directory-integrated DNS and have clients DNS list point to the first, then the second domain controller, and then perhaps as a last resort, the ISP DNS. This means that a failure of a single domain controller will still allow you to use Exchange services, and a failure of two domain controllers will allow you to browse the Internet.

A domain controller should have a DNS client list as follows: Itself, the other domain controller and the ISP DNS.

To complicate matters further, you can have a separate Internet domain (msexchage.org) and an internal one (msexchange.local). This is actually the recommended configuration as it simplifies name resolution issues when you have some servers, such as your web server hosted outside your internal network. Make sure that your internal domain name is not one that is used on the Internet. Every few years new domain suffixes are added (.biz, for example), so using "[domain name].local" is considered a safe bet for a local Active Directory domain name.

IP Addressing

At this point you should decide on an IP addressing scheme. Most businesses these days use a separate internal and external IP addressing. The Internet provider assigns you an external, public Internet IP address. Internally, however, you will use one the private IP schemes.

The most common internal IP range for small companies is 192.168.0.0/16. You can use subnet mask 255.255.255.0 if you require less than 254 IP addresses or 255.255.0.0 if you need more in a single network. All these IP addresses will be translated on the Internet to one IP address, the one assigned to you by your Internet provider.

You should assign a range for servers, for example, 192.168.0.0-192.168.0.10 that will not be used by DHCP (which automatically assigns IP Addresses) or by manually assigned workstations.

You might require one more public IP address to represent your Exchange server on the Internet. The router or Firewall (shown below) will translate your public IP address to the internal one and forward communications from the internet to your Exchange server.

Alternatively you can have your router or Firewall redirect all incoming mail traffic (port 25) and possibly Outlook Web Access traffic (port 443) to your internal Exchange server. This means that the Internet DNS servers will point you to the router IP address and it will forward all relevant queries to the internal Exchange server which will no longer require an external IP address.

A typical Exchange server with no port re-direction implemented will answer to an internal IP address (such as 192.168.0.2) and externally to a valid Internet IP address (such as 69.20.55.133).

Some organizations might choose to implement a "mail relay" which accepts incoming mail and scans it for viruses, spam, etc. This server will also face all kinds of Internet attacks. This is a very good option for medium to large organizations but for small offices I would recommend using a good Firewall to fend Internet attacks, perhaps even weed out viruses and spam and not install a separate server.

In case you do implement a mail relay, Exchange will still need a public IP address if you intend to publish Outlook Web Access on the Internet, unless you implement an Exchange front-end server which answers HTTPS calls and forwards them to your internal Exchange server.

Again, for small organizations, implementing a front-end server could be a waste of money and time that could otherwise be invested in other solutions that can improve your security such as a better Firewall.

Naming

Externally, you can call your mail server whatever you like, though "mail" is quite common. The internal name does not need to have any resemblance to the external one. The external name, after all is resolved by Internet DNS servers and the internal one is resolved by the internal DNS servers.

Some "security experts" recommend a vague name for your Exchange server such as a color ("Red"), a planet ("Venus") or a complex name ("b2xxxrl3"). This supposedly meant to disguise the true nature of your server so that attackers will not find right away that your server is a domain controller or an Exchange server. However, most hackers and even viruses or Trojan horses will typically scan your machine for ports rather than look at its name.

My recommendation is to keep names simple and obvious. Remember that that you will need to configure a few Outlook servers and enter you Exchange name a few hundred times during your Exchange admin career. Worse, sometimes users will need to enter their own configurations, so the simpler the better. Names like "Exchange", "Mail", "DC1" and "DC2" are preferred.

Hardware

Exchange 2003 basically requires a server with at least 512MB though 1GB or more is recommended.

CPU is always an issue, but most servers and even workstations have enough CPU horsepower for Exchange if you're not loading your server with anything else that is CPU intensive. Exchange supports hyperthreading feature available with Pentium 4 and other CPUs. If you need more CPU power you can use Intel Xeon which can offer you more cache and multiple CPU support.

Today, 64-Bit support is available in some CPUs but is Not supported by Exchange 2003 and will only be available with the next version of Exchange, E12.

Disk configuration is a complex issue and is covered in my article:

http://www.msexchange.org/tutorials/Choosing-Storage-Exchange-Server.html

To make a long story short, today, you can choose either SATA disks for lower end Exchange servers or SCSI disks if you can afford it. SATA disks can give you more disk space for less money but are generally slower though by far better than ATA (IDE) disks. You will need some form of disk redundancy (RAID) so disk failure will not bring you down. Hardware based RAID is recommended in most cases.

When planning for disk space it is best to leave room for a bit more than double the disk space expected for the Exchange databases. 32GB or more for the Exchange database partition is recommended for Exchange Standard edition.

Backup, Viruses, SPAM

You cannot have an Exchange server without some extra components that you might need to purchase separately. Windows 2003 has its own backup utility that can backup Exchange 2003 and IMF can be freely installed on Exchange 2003 to prevent junk e-mail (SPAM) but you will definitely need to purchase some sort of an Exchange-specific anti-virus even if you have some sort of perimeter level anti-virus protection, because some viruses might come from within.

Make sure that your Exchange server is backed up daily and that your backup tapes are placed in a fireproof safe. You should also buy new tapes on a regular basis so that your tapes are not worn to a degree that makes them unusable.

IMF is not the most advanced junk e-mail filter though it is going to be improved in upcoming service packs and Exchange versions. You can buy a commercial product but make sure that it lets users manage their own filtering options so users don't have to turn to you every time an e-mail is quarantined because your junk e-mail filter found it to be suspect.

A solid anti-virus package doesn't hog your CPU and allows you to filter file types by extension which is typically less CPU intensive than going over virus signatures for every attachment. It should be updated on a daily basis or more since virus outbreaks can sometimes be violent and quick. Some anti-virus packages now have a way to determine whether an e-mail item contains an unknown virus.

It is difficult to test an anti-virus package for Exchange in a lab, so your best bet is to ask around or search the Internet for recommendations before getting one.

Conclusion

The information presented in this article is just the tip of the iceberg when it comes to the different aspects of Exchange. It does give the big picture, and MSExchange.org is frequently updated with in-depth articles for every aspect of Exchange.

As the article shows, planning for an implementation of a single Exchange server is not that difficult once you separate fact from myth and understand the basic architecture.

Read more!

Troubleshooting Connectivity Problems on Windows Networks (Part 3)

In this article, I will continue my discussion by showing you how to verify that the local TCP/IP protocol stack is working correctly.

n the previous article in this series, I showed you how to determine which IP address your system is using as its primary address. The next step in the process is to verify that the IP address configuration is working correctly, and that there are no problems with the local TCP/IP protocol stack.

The first test that you need to perform is to ping the local host address. There are a couple of different ways of accomplishing this. One way is to enter the following command:

PING LOCALHOST

When you enter this command, Windows will ping the address 127.0.0.1. Regardless of your machine's IP address, Windows will always use 127.0.0.1 as the local host address. Therefore, an alternative to the command listed above is to simply enter the following command:

Ping 127.0.0.1

Upon entering this command, you should see a successful ping, just as you would with any other ping command. You can see an example of this, shown in Figure A.

Figure A: You should receive a successful ping when you attempt to ping the local host address

Pinging the local host address does nothing to diagnose communications problems with a remote host. It does however allow you to confirm that your local TCP/IP stack is functioning correctly. If you ping the local host address and receive a destination host unreachable error message, it is almost always an indication that TCP/IP is configured incorrectly, or that some part of the local TCP/IP stack is damaged. It has been my experience that you can usually get around this problem by removing the TCP/IP protocol from the computer, and then reintroducing it from scratch.

Ping the Default Gateway

In the previous part of this article series, I mentioned that there were several different aspects of the TCP/IP configuration that you needed to document, and have on hand for the troubleshooting process. Among these pieces of information or the IP addresses of the default Gateway, and of the primary DNS server.

Assuming that the hosts that you're trying to communicate with is on a remote network, or on a different segment of your corporate network, then the next thing that you need to attempt is to ping the default Gateway. You can accomplish this by simply appending the default gateway’s IP address to the ping command. For example, if you look at Figure B, you will notice that my TCP/IP configuration lists my default Gateway address as 147.100.100.100. I then simply pinged this address. This verifies that the local machine can communicate with the default Gateway. It also tells you that communications on the local network are working as intended, at least at the IP address level.

Figure B: Pinging the default gateway verifies that IP packets can reach your network’s default gateway

Ping the DNS Server

So far we have established that IP level communications are working between the local computer and the default Gateway. This does not however guarantee that host names are being resolved to IP addresses. In the first part of the article series, I showed you how you could use the destination host's fully qualified domain name in conjunction with the ping command as a way of verifying that the DNS server is doing its job. There are a couple of other ways that you can easily test DNS name resolution though.

One thing that you can do is to ping the DNS server's IP address, as shown in Figure C. This does not guarantee the name resolution is working correctly, but it does verify that the local machine is able to communicate with the DNS server.

Figure C: You should verify that the host can communicate with your DNS server

Another thing that you can do is to use the Nslookup command to verify that name resolution is working properly. To do so, simply enter the Nslookup command, followed by the remote host’s fully qualified domain name. The Nslookup command should be able to resolve the fully qualified domain name to an IP address, as shown in Figure D.

Figure D: The Nslookup command tells you whether or not your DNS server is able to resolve the host name

The image above can be a bit misleading at first, if you are not used to working with Nslookup. Initially, this screen appears to be reporting an error. If you take a closer look though, you can see that the first part of the information that has been returned refers to the local DNS server. You can tell this because the IP address that is referenced matches the DNS server’s IP address. However, the lower section of the returned information provides you with the IP address of the host that you have queried. As long as this IP address is listed, then the DNS query was successful.

If the name resolution process fails, then there is a DNS problem. The actual problem may be any one of a number of different problems with the DNS server. For example, the DNS servers forwarding address may not be correct, or the DNS server may not have access to the Internet, which it needs in order to contact higher level DNS servers. Likewise, the DNS server's DNS service may have stopped. Typically though, these types of problems will affect other clients as well since multiple clients usually rely on a single DNS server.

If DNS name resolution succeeds, that it is important that you've verified the IP address that was returned during the name resolution process. You can do this by comparing the IP address of the returned to the actual IP address that the remote host is using. These IP addresses should match, but there are conditions that could cause a mismatch, which would result of the communications failure.

If you do encounter a IP address mismatch, it could be the result of a malware infestation on the client, or it could be the result of DNS poisoning. DNS poisoning is a process in which the DNS cache is populated with invalid or incorrect IP addresses.

If you should encounter such a problem, then I would recommend scanning the client machine for a malware. It is important to scan for both spyware and viruses since both are known to cause this type of problem. Once the machine is free of malware, then try flushing the DNS cache. You can flush the DNS cache by entering the following command:

IPCONFIG /FLUSHDNS

You can see an example of this, shown in Figure E.

It is important to keep in mind that just because the DNS cache contains inaccurate IP addresses, it does not always mean that DNS poisoning has taken place. Sometimes hosts are assigned new IP addresses, and it takes the DNS cache a while to become aware of the changes.

Figure E: If you suspect that your DNS cache may contain inaccurate information, then you must flush it

Read more!

Troubleshooting Connectivity Problems on Windows Networks (Part 2)

This article continues the Troubleshooting Connectivity Problems series by showing you how to examine the machine’s IP configuration for clues to the cause of the problem.

Before I Begin

As I explained in the first part of this article series, my goal is to create a troubleshooting guide that anyone with basic skills can follow. That being the case, I am starting with basic troubleshooting techniques, and as the series progresses, I will gradually move into more advanced techniques.

Confirming Connectivity

In the previous article, I showed you the basics of using the PING command to test network connectivity. However, if you are having trouble communicating with other hosts on the network, or hosts on remote networks, then there are a few more PING tests that you can perform in order to get a better idea of what’s going on.

Before I show you those techniques though, it is important to understand how the host that is having communications problems is configured. The procedure for doing so varies from one version of Windows to the next, so I will show you how to check the network configuration on a machine that’s running Windows Server 2003

The first thing that you must do is to determine whether the machine in question is running a static or a dynamic IP address configuration. To do so, open the Control Panel, and choose the Network Connections option. Now, right click on the connection that you are trying to diagnose, and choose the Properties command from the resulting shortcut menu. Upon doing so, you will see the connection’s properties sheet, as shown in Figure A.

Figure A: This is the network connection’s properties sheet

Now, scroll through the list of items that the connection uses until you locate the TCP/IP protocol (selected in Figure A). Select this protocol, and click the Properties button to reveal the Internet Protocol (TCP/IP) Properties sheet, shown in Figure B.

Figure B: The Internet Protocol (TCP/IP) Properties sheet is used to configure the TCP{/IP protocol

Once you arrive at this screen, it is important to make note of the machine’s IP configuration. Specifically, you will want to make note of the following items:

• Is the machine using a static or a dynamic configuration?
• If a static configuration is being used, what is the IP address, subnet mask, and default gateway?
• Is the DNS server address being obtained automatically?
• If the DNS server address is being manually specified, what address is being used?

Before I move on, I also want to mention that if a computer has multiple network adapters installed, then there will be multiple connections that are listed in the Control Panel. It is very important that you know which connection corresponds to which network adapter, or else the techniques that I am about to show you will not work.

If you have any doubt as to which connection corresponds to which network adapter, then check the adapter type. If you look at Figure A, you will notice that the adapter type is listed at the top of the screen. If need be, you can open the case to see which network adapter the network cable is connected to, so that you can be absolutely sure that you are looking at the correct network connection.

Now that you know how TCP/IP is configured for the network adapter in question, we must determine whether or not Windows acknowledges the configuration. To do so, open a Command Prompt window, and enter the following command:

IPCONFIG /ALL

It might seem strange to have to make sure that Windows acknowledges your configuration, but IPCONFIG can really tell you a lot about what’s going on. For example, take a look at the screen that’s shown in Figure C. When you enter the IPCONFIG /ALL command, the first thing that you must do is to locate the correct network adapter. In this case, locating the correct adapter is easy, because only one adapter is listed. Notice though that IPCONFIG provides you with the connection number (in this case it’s Ethernet adapter Local Area Connection 2). If you look back at Figure A, you will notice that the title of the properties sheet shown in the figure bears the same name. That along with the description of the physical network adapter tells you exactly which network connection you are looking at.

Figure C: The IPCONFIG /ALL command shows you the machine’s IP configuration as Windows sees it

Of course the first thing that you will probably notice about Figure C is that it lists many different IP addresses for the connection. The reason for this is that I created the screenshot on a Web server. The Web server hosts multiple Web sites, each with its own IP address. I wanted to use this server to illustrate the point that the IP address configuration that you see when you glance at the TCP/IP properties sheet isn’t always what Windows is using. In this case, the IP configuration information shown in Figure B is still valid. It serves as the machine’s primary IP address. However, there are many other IP addresses that are also in use.

The next step in the troubleshooting process varies depending on whether the machine is using a static or a dynamic IP address configuration. If the machine is using a static configuration, then for right now, just check to make sure that the IP address, subnet mask, default gateway, and DNS server address that is listed matches those entered on the TCP/IP properties sheet.

If the machine is using a dynamic IP address, then you will want to look at the address and see if it falls within the expected address range. If you are troubleshooting a problem on an unfamiliar network, then you may not know what the address range should be. If that’s the case, there are a few values that you can look for that have special meanings.

The most obvious clue that something has gone wrong is an IP address of 0.0.0.0. This presence of this address usually indicates one of three things:

The network adapter is not connected to the network (possibly because of a cable problem or a bad switch port)

The IP address was released

An IP address conflict has occurred.

If you receive this address, then try entering the following three commands:

IPCONFIG /RELEASE
IPCONFIG /RENEW
IPCONFIG /ALL

These commands will essentially tell the computer to give up its current address, try to obtain a new address, and then show you the new configuration information. Sometimes this process will fix the problem, and sometimes it won’t. Often though, it will yield clues as to the cause of the problem.

Another tell tale clue that something has gone wrong is that the IP address falls into the 169.254.x.x range with a subnet mask of 255.255.0.0. Some versions of Windows will automatically use this address if an IP address cannot be acquired from a DHCP server.

Read more!

Troubleshooting Connectivity Problems on Windows Networks (Part 1)

This article series will explain various troubleshooting techniques that you can use when machines on a Windows network have difficulty communicating with each other.

Verify Network Connectivity

When one host has trouble communicating with another, the first thing that you must do is to gather some information about the problem. More specifically, you need to document the host’s configuration, find out if the host is having trouble communicating with any other machines on the network, and find out if the problem effects any other hosts.

For example, suppose that a workstation is having trouble communicating with a particular server. That in itself doesn’t really give you a lot to go on. However, if you were to dig a little bit deeper into the problem and found out that the workstation couldn’t communicate with any of the network servers, then you would know to check for a disconnected network cable, a bad switch port, or maybe a network configuration problem.

Likewise, if the workstation were able to communicate with some of the network servers, but not all of them, that too would give you a hint as to where to look for the problem. In that type of situation, you would probably want to check to see what the servers that could not be contacted had in common. Are they all on a common subnet? If so, then a routing problem is probably to blame.

If multiple workstations are having trouble communicating with a specific server, then the problem probably isn’t related to the workstations unless those workstations were recently reconfigured. More than likely, it is the server itself that is malfunctioning.

The point is that by starting out with a few basic tests, you can gain a lot of insight into the problem at hand. The tests that I am about to show you will rarely show you the cause of the problem, but they will help to narrow things down so that you will know where to begin the troubleshooting process.

PING

PING is probably the simplest TCP/IP diagnostic utility ever created, but the information that it can provide you with is invaluable. Simply put, PING tells you whether or not your workstation can communicate with another machine.

The first thing that I recommend doing is opening a Command Prompt window, and then entering the PING command, followed by the IP address of the machine that you are having trouble communicating with. When you do, the machine that you have specified should produce four replies, as shown in Figure A.

Figure A: The specified machine should generate four replies

The responses essentially tell you how long it took the specified machine to respond with thirty two bytes of data. For example, in Figure A, each of the four responses were received in less than four milliseconds.

Typically, when you issue the PING command, one of four things will happen, each of which has its own meaning.

The first thing that can happen is that the specified machine will produce four replies. This indicates that the workstation is able to communicate with the specified host at the TCP/IP level.

The second thing that can happen is that all four requests time out, as shown in Figure B. If you look at Figure A, you will notice that each response ends in TTL=128. TTL stands for Time To Live. What this means is that each of the four queries and responses must be completed within 128 milliseconds. The TTL is also decremented once for each hop on the way back. A hop occurs when a packet moves from one network to another. I will be talking a lot more about hops later on in this series.

Figure B: If all four requests time out, it could indicate a communications failure

At any rate, if all four requests have timed out, it means that the TTL expired before the reply was received. This can mean one of three things:

• Communications problems are preventing packets from flowing between the two machines. This could be caused by a disconnected cable, a bad routing table, or a number of other issues.
• Communications are occurring, but are too slow for PING to acknowledge. This can be caused by extreme network congestion, or by faulty network hardware or wiring.
• Communications are functional, but a firewall is blocking ICMP traffic. PING will not work unless the destination machine’s firewall (and any firewalls between the two machines) allow ICMP echos.

A third thing that can happen when you enter the PING command is that some replies are received, while others time out. This can point to bad network cabling, faulty hardware, or extreme network congestion.

The fourth thing that can occur when pinging a host is that you receive an error similar to the one that is shown in Figure C.

Figure C: This type of error indicates that TCP/IP is not configured correctly

The PING: Transmit Failed error indicates that TCP/IP is not configured correctly on the machine on which you are trying to enter the PING command. This particular error is specific to Vista though. Older versions of Windows produce an error when TCP/IP is configured incorrectly, but the error message is “Destination Host Unreachable”

What if the PING is Successful?

Believe it or not, it is not uncommon for a ping to succeed, even though two machines are having trouble communicating with each other. If this happens, it means that the underlying network infrastructure is good, and that the machines are able to communicate at the TCP/IP level. Typically, this is good news, because it means that the problem that is occurring is not very serious.

If normal communications between two machines are failing, but the two machines can PING each other successfully (be sure to run the PING command from both machines), then there is something else that you can try. Rather than pinging the network host by IP address, try replacing the IP address with the host’s fully qualified domain name, as shown in Figure D.

Figure D: Try pinging the network host by its fully qualified domain name

If you are able to ping the machine by its IP address, but not by its fully qualified domain name, then you most likely have a DNS issue. The workstation may be configured to use the wrong DNS server, or the DNS server may not contain a host record for the machine that you are trying to ping.

If you look at Figure D, you can see that the machine’s IP address is listed just to the right of its fully qualified domain name. This proves that the machine was able to resolve the fully qualified domain name. Make sure that the IP address that the name was resolved to is correct. If you see a different IP address than the one that you expected, then you may have an incorrect DNS host record.

Conclusion

In this article, I have shown you some steps for testing basic connectivity between two machines. In the next article in the series, I will show you some more techniques that you can use in the troubleshooting process.

Read more!

ISA SERVER QUICK GUIDE

Are you entirely new to ISA Server 2000? A lot of ISAServer.org visitors are! If you're like most of us, you probably aren't sure where to start. ISA Server 2000 is an extremely flexible and powerful firewall and a big part of that flexibility and power is the large number of options available to you. Right now you just want to get it installed with the least amount of hassle and then you can worry about making it do some neat firewall tricks later.


Its was with the new ISA Server 2000 firewall admin in mind that I've put together the ISA Server 2000 Quick Start Guide. This Quick Start Guide guides you through the steps of installing and configuring your ISA Server firewall so that you're protected from external intruders and still have access to the Internet from computers on your internal network. I've made all the decisions for you. Just go through the steps, follow up on the recommendations, and things will "just work". You can then get into the fancy stuff, like user/group based access control, Web and Server Publishing, VPNs and logging/reporting after you're confident that your ISA Server 2000 firewall actually works.

Download the ISA Server 2000 Quick Start Guide

Read more!

GETTING START WITH ISA SERVER

Because ISA Server is completely different from Proxy Server 2.0, Microsoft recommends that even experienced administrators become acquainted with the Wizard that will help in the initial steps of product configuration and customization.

The Getting Started Wizard works with a set of options that will aid
users through the process of customizing the product and will also clarify the effects of specific modifications when introduced to the ISA Server.

The Wizard is split into two sections (see Fig. 10):

* Configuring policies,
* Configuring arrays.

After you have finished the initial configuration of ISA Server with help from the Getting Started Wizard, you can fully adapt the product to the working environment by finally re-adjusting certain settings

Creating protocol rules

Administering an ISA Server means creation of suitable arrays, rules and policies. Arrays and policies have already been explained so let us examine the term “rules”.

ISA Server uses two types of rules:

• Site and content rule – determines if and when content from specific Internet destinations can be accessed by users,
• Protocol rule – determines which packets may or may not access the ISA server.

Apart from the above rules, the following rules can also be defined for ISA server:

• Bandwidth (Capacity) rule – this will prioritise different types of services using ISA server. This allows administrators to verify which specific www traffic or business-related traffic will be allocated to the available bandwidth.
• Web publishing rules– to “publish” incoming HTTP, HTTPS, FTP requests and map them as services on the ISA Server.
• Server publishing – with this feature, clients from the public Internet are directed to the ISA Server instead of to the web server. Moreover, the ISA Server may act as the proxy for inbound and outbound traffic between the public Internet clients and the internal web server.
  

Web Cache functions

ISA Server features high-performance Web Cache functions. With Cache Configuration tab the user is guided through Web service configuring. In addition to a variety of settings, the possibility exists to set up the size of the cache memory per hard disk and configure the schedule of caching tasks (TTL utility).

Fig. 11 Configuring caching services

When ISA Server is set up as a Web caching server, two situations are possible:

• Forward Web Caching Server – this is the most popular use of the Web caching server. Its function is as follows:

Fig. 12 Forward Web Caching Server

1. User No. 1 (Client 1) forwards a request to the Web server for an object;

2. The ISA Server approves the request and checks if the object already exists in the local cache. If the content does not already exist in the cache, the ISA Server contacts the Web server to fetch the requested object (on behalf of the user);

3. The Web server returns the object in question to the ISA Server;

4. ISA Server returns the Web object to the original client No. 1, and saves this object to cache it locally.

5. User No. 2 forwards the request for the same Web object;

6. ISA Server will send the object cached locally to user No. 2.

• Reverse Web Caching Server – Reverse Proxy by an ISA Server offers security for one or more Web servers located on the internal network. This ensures secure Web publishing, which is of particular concern if sensitive data is to be sent from the servers.
  

Fig. 13 Reverse Web Caching Server

In addition to the security offered by both forward and reverse caching, ISA Server could be configured to give administrators the possibility to manage various Web caching solutions such as:

• Scheduled Content Download – ISA Server can be configured to provide tools for downloading/refreshing web pages at appropriate intervals. In this way, the most popular web objects may be refreshed at night instead of during the day without risking overloaded connections.
• Active caching – when active caching is used, ISA Server itself will evaluate and rank the cache and refresh it as necessary. This is a particularly useful option in situations where employees must use specific url sites to fetch necessary information several times during the day, from sites that are frequently updated, and especially if it is risky to fetch non updated versions.
• On Demand – the most popular configuration of a caching server: upon an initial request for on-demand content, the server acquires requested Web files and stores them locally in its cache.
  

Secure Internet Access through ISA Server

Secure Internet Access is one of the fundamental features provided by ISA Server. It is increasingly necessary to improve security tools and check users that access the network from outside, especially in a situation where the Global Web is vulnerable to outside interference from viruses, trojan horses or hacker attacks. One may also wish to improve security to monitor network users and protect the network from potential Internet threats. To face this challenge and provide solutions for a broad landscape of users, Microsoft has implemented three types of clients in ISA Server:

• Firewall clients – all computers that have Firewall Client software installed and active,
• SecureNat clients – all computers that do not have Firewall Client software installed,
• Web Proxy clients – all Web browser clients are configured to use ISA Server.
  

Feature	SecureNat Client	Firewall Client	Web Proxy Client
Installation required?	No, but some network configuration changes required	Yes	No, requires Web browser configuration
Operating System support	Any OS that supports TCP/IP	Only Windows platforms	All platforms
Protocol support	Requires application filters for multi-connection protocols	All Winsock applications	HTTP,SHTTP,FTP, Gopher
User-level authentication	No	Yes	Yes
Server applications	No installation or configuration required	Requires configuration file	N/A

Table 3 Comparison of ISA Server Clients

Both Firewall and SecureNat clients include WebProxy client service, since all Web client requests are passed to WebProxy. All other requests sent by either Firewall or SecureNAT clients are redirected to other modules within ISA server.

Before selecting the client type to be used in a specific enterprise, it is necessary to recognize what particular applications and protocols are to be used in the network. A proper evaluation will help to have trouble-free use of Web services without continuous changes to the configuration. Choosing reliable clients is also the foundation for all network security since a more liberal access policy to Internet facilities may threaten not only e-privacy but also e-access. It is enough to realise that a few users who are downloading MP3 or AVI files from the Net and have a few Internet sessions open will be sufficient to occupy an enterprise connection at nearly 100 percent utilisation.

Network need	Recommended client type	Reason
To avoid deploying client software or configuring client computers.	SecureNAT	SecureNAT clients do not require any software or specific configuration on client machines.
To use ISA Server only for forward Web caching.	SecureNAT	If one uses ISA Server as a Web caching server, one will not have to deploy any special software.
One wants to create user-based access rules to control non-Web Internet access.	Firewall Client	If one uses Firewall clients, one may configure access rules for non-Web sessions. However, these rules will be effective only if one configures ISA Server to require authentication information with each session.
The network supports many roaming users and computers.	Firewall Client	SecureNat clients do not support automatic discovery of ISA server. When one configures automatic discovery, roaming users or computers cannot connect to the Internet server as appropriate.
The clients need access (outside of Web browsers) to protocols with secondary connections to the Internet via FTP.	Firewall Client	SecureNat clients do not support protocols with secondary connections.
To support dial-in-demand for non-Web sessions from the clients.	Firewall Client	Though SecureNat supports dial-out, only Firewall clients support dial-in-demand for non-Web sessions.

Table 4 Choosing an ISA Server Client Type

Table 4 represents the choice that may be useful to benefit from a proper selection of clients accessing the network in a specific enterprise. For more detailed specification of the particular types of clients see the files attached to the program.

Read more!

INSTALLING ISA SERVER 2000

A Windows 2000 Server with a full implementation of Active Directory is the minimum on which it is possible to install Microsoft ISA Server. Before installing ISA Server, one must configure Active Directory (adding required classes and selecting object properties).

Fig. 1 ISA Server setup screen with selected AD schema modification option

Before the system attempts to update the schema you will be warned that this action is not reversible.

Fig. 2 Active Directory’s modification-related warning

When modifying the schema, it is necessary to determine what the intended extent of modifications to the existing policies integrated in AD would be. In case of problems with the modification of Active Directory, one should consult the Ldif.log file.

Fig. 3 Modifying Active Directory

Once the Active Directory has been updated, you can attempt to install ISA Server. In the first step, you will be requested to supply the information about the installation mode (Typical, Full, Custom).

Fig. 4 ISA Server installation options

After this step, the set-up wizard checks whether Active Directory has already been installed or not and if any settings have been modified. Next, you will be prompted to determine if the server should be a part of a domain or be used as a standalone unit. In the next step, select the mode of operation from the following three options:

· Firewall – with this option, ISA Server will function as a very powerful firewall,

· Web Cache – will establish the ISA Server as a cache server and give access to ‘Net resources’

· Integrated Mode – when in integrated mode, all ISA Server implemented and initialized features will be available.

Fig. 5 selecting the functional mode

Once the required mode has been selected, the next dialog box stops the Internet Information Services (if any are already installed) and prompts you to either deinstall IIS or re-configure it not to listen in on ports 80 and 8080 that are required for ISA Server. Despite possible joint operation, Microsoft recommends relocating the IIS Server to another machine.

In the next step, you will be prompted to specify the cache size for the Web Cache service.

Fig. 6 Configuring the cache size for WWW caching

If it is a multiple-disk server, one may benefit by distributing caches onto a few disks. This would accelerate the process of accessing cacheable information.

Having configured appropriate cache sizes for WWW Web services one may attempt to configure LAT (Local Address Table).

Fig. 7 LAT setup utility

LAT (Local Address Table) – these are tables that define all internal IP address ranges. If one selects this Table (Fig. 7), either the private IP address ranges as defined in RFC 1918 (10.X.X.X, 172.16.X.X, 192.168.X.X) or the external Windows 2000 routing tables will be used.

Fig. 8 A default LAT

Once this step is successful, you will get a screen with the end of LAT configuration. Remember to ensure that all network cards are connected to the Internet while installing ISA Server. Should any network card be inactive, LAT tables will probably not be created.

Fig. 9 Completing the LAT setup procedures

After completing the setup procedures, you can attempt to replicate the content of all files to the ISA Server directory. After installation, the ISA Server Administration utility will start.

Fig. 10 Microsoft ISA Server Administrator utility and Getting Started Wizard

To manage this utility, use the Microsoft Management Console (MMC) feature. The left dialog box contains all options that are necessary for setup whilst the right box provides the settings available for such options.

Read more!