What does all this mean? Nothing but shelling out extra $$$ to invest in a backup solution unless you are interested in a very simple backup solution to assure that the logs get truncated and you have backup copies which you can restore. Here is a basic hack which can help one save a couple of $$$.

Step #1

Get access to a Windows 2003 R2 Server which is running a 64-bit OS. Assuming that you are not running your production Exchange Server 2007 in 32-bit environment, we require the 64-bit version library files. If you do not have a one handy, you can get the source files and then expand the DLL’s or install one in a virtual environment.

Step #2

Copy the ntbackup.exe, ntmsapi.dll, and vssapi.dll files from C:\windows\system32 into a new folder on your Exchange Server 2007 running on Windows 2008. I created a folder called NTBackup under Program Files and placed them there.

NT Backup Exchange 2007

Step # 3

Right click Ntbackup.exe and choose “Run as administrator”.

Your should see the Exchange Server Information Store as part of your backup wizard.

Select the Information Stores that you want to backup. Choose the Backup media or filename and the path where you want to store your backups. Once you have finished the configuration, click on Start Backup and the exchange store backups should start.

Once the backup is complete, you should see all the transaction logs getting truncated (hope circular logging is not enabled) and also the mail store would be stamped with the Last Full Backup date and time stamp.

One thing to note though: you cannot back up a storage group in a Standby Continuous Replication (SCR) environment. Backups of storage group copies are available for Local Continuous Replication (LCR) or Cluster Continuous Replication only.

Communication: If possible and if budget permits, do not expose the SQL Server directly to the Internet. Allow the communication from a web server to the SQL database server over an internal IP address.

Strong Passwords: Ensure that the server uses a strong password for the “sa” account. Use a combination of letters, numbers and symbols. This make it difficult for Brute Force hacks to guess the password.

Authentication: Keep this to Windows Authentication if possible and avoid setting SQL to run under Mixed Mode. Windows Authentication will require SQL server to check the Active Directory and moreover the logins will not be stored in the SQL server.

Service Packs and Updates: Make sure that the SQL Server is always patched with the latest Service Pack and Security Updates. This ensures that the latest security vulnerabilities are addressed and blocked.

Service Accounts: Run both MSSQLSERVER and SQLSERVERAGENT under the Domain User permissions. Do not run them under any Administrator account. This ensures very less damage in case the user account or the server is compromised.

Block Ports: If there is no need to expose the MS SQL Server to the Internet, block port 1433 and 1434 at the firewall. This means that the SQL Server will not be accessible from the Internet, thus making it hard for outside attackers to reach to the server. It also prevents worms and viruses.

Backups: Encrypt and compress the backup files. Put a password on the backups and store them to a safe location. Do not keep them on the server.

So why do we need a centralized patch management policy? Well, the answer is simple – the systems are prone to risks and threats when exposed to the Internet or medias like USB pen drives, wireless networks and devices, etc. We all, at some point, might have experienced or read about the havoc caused by Blaster or the Sasser worms. Today software vendors have stepped up the releases of emergency and critical updates in a formalized manner to encounter these threats. Microsoft’s Patch Tuesday is a good example that highlights that. To learn more about this program, click here.

WSUS from Microsoft is a boon to Network and System Administrators in this scenario. WSUS (Windows Server Update Services) is basically designed to run on a company’s network and automate the process of patching. This free product from Microsoft does a fair job of streamlining the overall patch management process of an organization with centralized reporting. For a Network or System Administrator it is just a simple task of installing the WSUS server on a system and then configures all Desktops to use the WSUS server for software updates. This can be easily achieved by creating a group policy and linking the policy to the correct OU using Group Policy Editor. The Desktops would automatically announce their current status to the WSUS server with details like which patches are needed to be installed, which patches have failed to install, which patches have been successfully installed, etc.

In a nutshell, WSUS seems to be a good product especially when there is no price tag attached to it and starting with WSUS 3.0 the reports have also improved over its predecessor.

There is no in-place upgrade supported with Exchange 2007 and so the only option is to upgrade to Exchange Server 2007 by adding it to the current Exchange 2003 organization and then moving all the resources from Exchange 2003 to Exchange 2007 and thereafter removing the Exchange 2003 Server. This means that we have no option but to perform a migration. So let’s get on with it.

Prerequisites

The first step is to prepare our new Windows 2008 server so that it is ready for Exchange Server 2007 installation. Please note that we are talking about the 64-bit version of Exchange Server 2007 SP1 as the 32-bit version is not supported in production environment.

We will need the following components installed before we proceed:

• .Net Framework version 2.0 and 3.0
• .Net Framework version 2.0 update or Service Pack 1
• IIS 7 (various components)

• Windows PowerShell
•  
• MMC -Microsoft Management Console 3.0 (installed by default so can be skipped)

The following components should not be installed (were required in Exchange 2003):

• Network News Transfer Protocol (NNTP)
• Simple Mail Transfer Protocol (SMTP)

Once we have installed the prerequisites, let’s proceed towards the installation.

Installation Process

We are going to install all Exchange Server Roles (HUB, CAS and MAILBOX) on one single box except for the Edge Transport Role. Let’s start by first preparing the Active Directory for Exchange 2007. Actually, the installer would do this automatically, but I like to perform this manually so that we can see what’s happening and understand it better. Here is what we will do before we run the installer of Exchange 2007:

• Prepare the schema for legacy Exchange permissions. This is because we are migrating from Exchange 2003 in the current organization.
• Prepare Schema
• Prepare Active Directory
• Prepare the Domain

The first thing that we do is to update the schema for legacy permissions. In order to do this we must login to the Domain Controller which is the Schema Master at the forest root and run the command from there.

Type Setup /PrepareLegacyExchangePermissions and press Enter.

This must be run as an Exchange Admin account and also ensure that you are in the local server’s Administrator group. The safest thing to do is to add the user account you are logged in with to the Enterprise Administrators Group, Schema Administrator Group and Domain Administrators Group. Also, the domain should be able to communicate with all other domains in the forest and we should all ample time for the replication to finish once this command is run.

Next, we will proceed towards updating the Schema from the Windows 2008 Server.  Type Setup /PrepareSchema and press Enter.

We can see that the task failed with an error on the server. This is because the Remote Server Administration Tools were not installed. We can do this using the GUI but I’ve used the command line. Type ServerManagerCmd -I RSAT-ADDS and press Enter.

Here we go, the Remote Server Administration Tools have been installed and we need to reboot our Windows 2008 server before proceeding further.

Once the server has rebooted, let’s try preparing the Schema once again. Type the command that we used earlier – Setup /PrepareSchema and press Enter.

This time the task completed without error. Let’s move on.

Type Setup /PrepareAD to proceed with the Active Directory preparation.

Once this is completed, move on with preparing the domain.

Type Setup /PrepareDomain and press Enter.
Note: this setup can be skipped if you do not have multiple domains within the forest.

Great, we are done with preparing our Active Directory for Exchange Server 2007 SP1 installation and now we can run the installer. If you have geographically dispersed domains, please allow enough time for replication to happen over the WAN links.

So, with the Active Directory now ready, we are ready to complete the installation. Start the setup. The first screen that we see is as under:

Since we have already taken care of the prerequisites, we can directly proceed to Step-4 i.e. Install Microsoft Exchange Server 2007 SP1. Click on it and we will be presented with the standard EULA.

Accept the License Agreement and click Next.

We now have a choice of a Typical Installation or a Custom Installation. Since I like to see what configuration options are available, I always tend to choose the Custom option. Also, for this example, we are going to install the Exchange server in the D: drive instead of the C: drive. You can change the path to your liking here. Once the selections are done, click Next.

The next screen allows us to choose which roles we want to install.

We will choose all the three main roles i.e. Mailbox Role, Client Access Role (CAS) and Hub Transport Role (HUB). I’m not choosing the Unified Messaging Role (UM) as I intend to do a separate article on this in the near future.

Once the selections have been done, click Next.

Here we go. The installer now prompts for the Mail Flow setting. Since we have an Exchange 2003 server we will need to browse and select the same so as to enable it as a Bridgehead server in the routing group. Once selected, click Next.

In the Readiness Check page, wait for all the readiness checks to complete and then click Install.

The installation process takes some time so it would be a good idea to sit back and relax over a cup of coffee. During the installation process, if we open up the System Manager on Exchange Server 2003, we will notice a new routing group.

Once the installation process completes, we now have a working environment of the new Exchange Server 2007 SP1. The process of installing Exchange 2007 on a Windows 2008 server is fairly simple.

To verify the installation, open the new Exchange Management Shell and type Get-ExchangeServer. A list of all Exchange 2007 server roles that we installed would be displayed. It is a good idea now to open up the Management Console of Exchange and run the Exchange Best Practices Analyzer. It will give a good idea about the deployment and would help in determining if the configuration has been done in accordance to the Microsoft best practices.

It is recommended to have 90MB hard disk space for a typical install. To get started, download the latest version of Perl from ActiveState (http://www.activestate.com)

Once the download process has completed, double click on the program to begin the installation process.

Choose Next to continue. You will be presented with the standard license agreement.

Accept the End-User License Agreement and choose Next to continue.

You can change the installation path to match your setup from here. For this example, we have used F:\Perl. You can even choose not to install the Examples files if you want. Once the selections have been done, click Next to continue.

On the next screen in the setup wizard, verify that the following choices are selected:

·  Add Perl to the PATH environment variable

·  Create Perl file extension association

·  Create IIS script mapping for Perl

Click Next to continue to the review screen in the setup wizard.

Click Install to begin the installation process. The installation will take a few minutes and once the installation is done click Finish to complete the installation process. That’s it, Perl has been installed and integrated with IIS.

To verify that the Perl path is set correctly and available to IIS, Right Click on My Computer and select Properties.

Select the Environment Variables from the Advanced tab and verify the path listed under System Variables.

Choose OK to close the current window. We have successfully installed Perl.

To start with, create a folder on the machine that you want to automate this on. I named my folder as “MaintenanceScripts”. The next step was to write the batch file with the content given below and save it as “ChecknDefrag.bat”.

@Echo Off
REM ***************************************************************************
REM *                                                                         *
REM *      AUTOMATED DISK CHECK AND DEFRAGMENTATION SCRIPT                    *
REM *                                                                         *
REM ***************************************************************************

REM chkdsk and defrag automation
REM Read the Drive Letter from the file
for /F "eol= tokens=1 delims=( " %%i in (DriveLetter.txt) do set DrvLtr=%%i& call :dsKchk

:dsKchk
If %DrvLtr% == end goto :eof
echo. >> diskcheck.rtf
echo. >> diskcheck.rtf
echo ******************************************************** >> diskcheck.rtf
echo CHECK DATE and TIME for %DrvLtr% >> diskcheck.rtf
date /t >> diskcheck.rtf
time /t >> diskcheck.rtf
echo ******************************************************** >> diskcheck.rtf
echo. >> diskcheck.rtf
echo. >> diskcheck.rtf
echo RUNNING DISK CHECK ON %DrvLtr% ....
chkdsk %DrvLtr% >> diskcheck.rtf
goto :defrag

:defrag
echo. >> defrag.rtf
echo. >> defrag.rtf
echo ******************************************************** >> defrag.rtf
echo CHECK DATE and TIME for %DrvLtr% >> defrag.rtf
date /t >> defrag.rtf
time /t >> defrag.rtf
echo ******************************************************** >> defrag.rtf
echo. >> defrag.rtf
echo. >> defrag.rtf
echo RUNNING DISK DEFRAGMENTATION ON %DrvLtr% ....
defrag %DrvLtr% -b >> defrag.rtf
defrag %DrvLtr% -f >> defrag.rtf

:EOF

The above batch file checks for a file called “DriveLetter.txt” in the same folder from where the script it going to run from. You can change it to your liking. It also saves the report of the disk check to a file called “diskcheck.rtf” and for defrag to a file called “defrag.rtf”. I choose RTF so that I can open it in MS Word or any other application to see a nice formatted output.

Next, we create a file called “DriveLetter.txt” in the same folder where we saved the Batch File and add all the drive letters that we want the script to check:

C:
end

You can add more disks to the above file by writing the drive letters to the text file – one drive per line.

Run the batch file once and wait for it to finish. Once it finishes its run, you can open the RTF files and see the results. If you are satisfied that everything is working fine with the batch files, you can now move towards scheduling the batch file to run at off-peak hours.

Basically, DDOS means a Distributed Denial of Service attack which are targeted towards a computer, server or a device to make it unavailable on the network. Lot of malicious traffic is directed towards a server or a service which blocks the bandwidth/network. Here are some steps Windows administrators can go through to prevent or fight against it:

- Keep your servers/computers updated with the latest patches, service packs and updates.
- Harden the TCP/IP stack. Here is an article from Microsoft which talk about it: http://support.microsoft.com/default.aspx/kb/324270
- Check with your Data Center to find out what infrastructure security is in place. They may be having a system in place where the DDoS traffic can be routed through a DDoS Mitigation Service. This filters out the attack traffic and allows the legitimate traffic to continue to its original destination.
- If the budget permits, get a good hardware firewall installed in your infrastructure network. If not, then you can also go in for some software based firewall which can filter packets. In the worst case, at least have your Windows Basic Firewall configured.

If you need to use the additional PECL modules then extract the files from the PECL Zip into the C:\PHP\ext directory.

Next locate the file ‘php.ini-recommended’ in C:\PHP and rename it to ‘php.ini’ (without the quotes of course)
 
Open the ‘php.ini’ file and find the line which reads extension_dir = “./” and change it to extension_dir = “C:\PHP\ext”. This tells PHP where the various extensions are located. If you open the default PHP.INI file which ships with the ZIP file you can see that the default path in the ‘php.ini-recommended’ file points to the wrong location, so you need to change it.

You also need to add the location of your PHP directory to the server’s PATH environment variable so that Windows knows where to look for any PHP related executables (such as the PHP extension DLL‘s). To do this Right-click on My Computer, click Properties and on the Advanced tab click Environment Variables. In the Environment Variables dialog box, under System Variables highlight the Path variable and click Edit.

Add ‘;C:\PHP’ (be sure to include the semi-colon separator) as shown here and click OK. You will need to re-boot the server for this change to take effect as system variables are loaded when the server starts up.

If you browse through the ‘php.ini’ file you will see an entry describing the ‘cgi.force_redirect’ property. You will also see a statement telling you that if you are using IIS you ‘MUST’ turn this off. However, this only applies if you are using the CGI version of PHP (i.e. php-cgi.exe) Since we are using the ISAPI version of PHP we can safely ignore this.

Configuring IIS (Only if required)

There are a few simple steps you need to take in order to get PHP working under IIS 6.0

First we need to create and then enable an appropriate Web Service Extension so that IIS will both recognize and allow PHP files to be processed by the appropriate script engine.

You can use the Internet Information Services (IIS) Manager GUI method to perform this task but there is a much quicker way of doing this; namely using the ‘iisext.vbs’ Command-Line Administration Script, which you will find in C:\Windows\system32 by default.

Assuming you are using the same directory structure as I am in this walkthrough you can simply copy and paste the following line of text and execute it at a command prompt from C:\Windows\system32 :

cscript iisext.vbs /AddFile c:\PHP\php5isapi.dll 1 PHPISAPI 1 “PHP ISAPI”

As you can see, this script creates a new Web Service Extension named “PHP ISAPI” with a status of Allowed.
 

The IIS 6.0 Command-Line Administration Scripts are very powerful and flexible tools and I would recommend using them wherever possible.

OK, now we are ready to test our PHP installation. Start by creating a simple PHP test file. Open Notepad on the server and copy the following line into a new text file: <?php phpinfo(); ?>

Save the file as index.php in the root of the test web site. Next create a new default document type of index.php on the test web site (this step is optional but it just makes browsing a bit easier)

Browse the site and you should see the standard PHP configuration details page

However, if you look carefully at the above page you will notice it is indicating that my ‘php.ini’ file is actually located in ‘C:\WINDOWS’ even though there is no such file in my C:\WINDOWS directory. This is because the ‘php5isapi.dll’ file is actually compiled with this location as its default value. A number of existing PHP and IIS tutorials suggest that you should copy the ‘php.ini’ file to the C:\WINDOWS directory – but what if you don’t want to do that?

Well, you don’t have to because PHP allows you to actually configure a custom value for the ‘php.ini’ file location. There are a number of ways to do this but perhaps the simplest is to configure the PHPRC environment variable.

To demonstrate how this works I am going to create a new folder called ‘C:\inifile’ and instruct PHP to read its configuration data from the ‘php.ini’ file in this location (in practice you may prefer to leave your ‘php.ini’ file in the C:\PHP directory)

In order to do this I need to create a new System environment variable named ‘PHPRC’ and provide the appropriate values. Right-click on My Computer, click Properties and on the Advanced tab click Environment Variables.

In the Environment Variables dialog box, under System Variables click New. In the New System Variable dialog box type PHPRC for the variable name and then enter the desired path to your ‘php.ini’ file’s location.

Then click OK and you will see that a new System environment variable has been created. In order for this to take effect you need to re-boot the server at this stage.

#Note
As an alternative, you can edit the registry and specify the location of your configuration file. The main benefit of the registry edit method is that it doesn’t require a re-boot – in testing this method I found that any changes made would take effect once the application pool serving the web site was recycled. However, choose whichever method you feel most comfortable with and which fits your requirements.

Now if we browse the site we can see that PHP is indeed looking for its ‘php.ini’ file in the ‘C:\inifile’ location which I specified previously.

And that’s it. You should now have a working installation of PHP running on IIS 6.0.

Hacking a Web Server
With the advent of Windows 2003 and IIS 6.0 there was a sharp turn in the way hosting services were being provided on Windows platform few years back. Today, web servers running on Internet Information Services 6.0 (IIS 6.0) are highly popular worldwide – thanks to the .NET and AJAX revolution for designing web applications. Unfortunately, this also makes IIS web servers a popular target amongst hacking groups and almost every day we read about the new exploits being traced out and patched. That does not mean that Windows is not as secured as Linux. In fact, it’s good that we see so many patches being released for Windows platform as it clearly shows that the vulnerabilities have been identified and blocked.

Many server administrators have a hard time coping up with patch management on multiple servers thus making it easy for hackers to find a vulnerable web server on the Internet. One good way I have found to ensure servers are patched is to use Nagios to run an external script on a remote host, in turn alerting on the big screen which servers need patches and a reboot after the patch has been applied. In other words, it is not a difficult task for an intruder to gain access to a vulnerable server if the web server is not secured and then compromise it further to an extent that there is no option left for the administrator but to do a fresh OS install and restore from backups.
Many tools are available on the Internet which allows an experienced or a beginner hacker to identify an exploit and gain access to a web server. The most common of them are:

IPP (Internet Printing Protocol) – which makes use of the IPP buffer overflow. The hacking application sends out an actual string that overflows the stack and opens up a window to execute custom shell code. It connects the CMD.EXE file to a specified port on the attacker’s side and the hacker is provided with a command shell and system access.

UNICODE and CGI-Decode – where the hacker uses the browser on his or her computer to run malicious scripts on the targeted server. The script is executed using the IUSR_<computername> account also called the “anonymous account” in IIS. Using this type of scripts a directory transversal attack can be performed to gain further access to the system.

Over these years, I’ve seen that most of the time, attacks on a IIS web server result due to poor administration, lack of patch management, bad configuration of security, etc. It is not the OS or the application to blame but the basic configuration of the server is the main culprit. I’ve outlined below a checklist with an explanation to each item. These if followed correctly would help prevent lot of web attacks on an IIS web server.

Secure the Operating System
The first step is to secure the operating system which runs the web server. Ensure that the Windows 2003 Server is running the latest service pack which includes a number of key security enhancements.

Always use NTFS File System
NTFS file system provides granular control over user permissions and lets you give users only access to what they absolutely need on a file or inside a folder.

Remove Unwanted Applications and Services
The more applications and services that you run on a server, the larger the attack surface for a potential intruder. For example, if you do not need File and Printer sharing capabilities on your shared hosting platform, disable that service.

Use Least Privileged Accounts for Service
Always use the local system account for starting services. By default Windows Server 2003 has reduced the need for service accounts in many instances, but they are still necessary for some third-party applications. Use local system accounts in this case rather than using a domain account. Using a local system account means you are containing a breach to a single server.

Rename Administrator and Disable Guest
Ensure that the default account called Guest is disabled even though this is a less privileged account. Moreover, the Administrator account is the favorite targets for hackers and most of the malicious scripts out there use this to exploit and vulnerable server. Rename the administrator account to something else so that the scripts or programs that have a check for these accounts hard-coded fail.

Disable NetBIOS over TCP/IP and SMB
NetBIOS is a broadcast-based, non-routable and insecure protocol, and it scales poorly mostly because it was designed with a flat namespace.  Web servers and Domain Name System (DNS) servers do not require NetBIOS and Server Message Block (SMB). This protocol should be disabled to reduce the threat of user enumeration.
To disable NetBIOS over TCP/IP, right click the network connection facing the Internet and select Properties. Open the Advanced TCP/IP settings and go to the WINS tab. The option for disabling NetBIOS TCP/IP should be visible now. To disable SMB, simply uncheck the File and Print Sharing for Microsoft Networks and Client for Microsoft Networks. A word of caution though – if you are using network shares to store content skip this. Only perform this if you are sure that your Web Server is a stand-alone server.

Schedule Patch Management
Make a plan for patch management and stick to it. Subscribe to Microsoft Security Notification Service (http://www.microsoft.com/technet/security/bulletin/notify.asp)  to stay updated on the latest release of patches and updates from Microsoft. Configure your server’s Automatic Update to notify you on availability of new patches if you would like to review them before installation.

Run MBSA Scan
This is one of the best way to identify security issues on your servers. Download the Microsoft Base Line Security tool and run it on the server. It will give you details of security issues with user accounts, permissions, missing patches and updates and much more.

That’s it to the basic of securing the operating system. There are more fixes which can be performed for further securing the server but they are beyond the scope of this article. Let’s now move on to securing the IIS web server.
IIS 6.0 when setup is secured by default. When we say this, it means that when a fresh installation of IIS is done, it prevents scripts from running on the web server unless specified. When IIS is first installed, it serves only HTML pages and all dynamic content is blocked by default. This means that the web server will not serve or parse dynamic pages like ASP, ASP.NET, etc. Since that is not what a web server is meant to do, the default configuration is changed to allow these extensions.

Listed below are some basic points that guide you to securing the web server further:

• Latest Patches and Updates
  Ensure that the latest patches, updates and service packs have been installed for .NET Framework. These patches and updates fix lot of issues which enhances the security of the web server.
• Isolate Operating System
  Do not run your web server from the default InetPub folder. If you have the option to partition your hard disks then use the C: drive for Operating System files and store all your client web sites on another partition. Relocate web root directories and virtual directories to a non-system partition to help protect against directory traversal attacks.
• IISLockDown Tool
  There are some benefits to this tool and there are some drawbacks, however, so use it cautiously. If your web server interacts with other servers, test the lockdown tool to make sure it is configured so that connectivity to backend services is not lost.
• Permissions for Web Content
  Ensure that Script Source Access is never enabled under a web site’s property. If this option is enabled, users can access source files. If Read is selected, source can be read; if Write is selected, source can be written to. To ensure that it is disabled, open IIS, right click the Websites folder and select Properties. Clear the check box if it is enabled and propagate it to all child websites.
• Enable Only Required Web Server Extensions
  IIS 6.0 by default does not allow any dynamic content to be parsed. To allow a dynamic page to be executed, you need to enable the relevant extension from the Web Service Extensions property page. Always ensure that “All Unknown CGI Extensions” and “All Unknown ISAPI Extensions” are disabled all the time. If WebDAV and Internet Data Connector are not required, disable that too.
• Disable Parent Paths
  This is the worst of all and thanks to Microsoft, it is disabled in IIS 6.0 by default. The Parent Paths option permits programmers to use “..” in calls to functions by allowing paths that are relative to the current directory using the ..\notation. Setting this property to True may constitute a security risk because an include path can access critical or confidential files outside the root directory of the application. Since most of the programmers and third-party readymade applications use this notation, I leave it up to you to decide if this needs to be enabled or disabled. The workaround to Parent Paths is to use the Server.MapPath option in your dynamic scripts.
• Disable Default Web Site
  If not required, stop the Default Web Site which is created when IIS 6.0 is installed or change the property of Default Web Site to run on a specific IP address along with a Host Header. Never keep it running on All Unassigned as most of the ready-made hacking packages identify a vulnerable web server from IP address rather than a domain name. If your Default Web Site is running on All Unassigned, it means that it can serve content over an IP address in the URL rather than the domain name.
• Use Application Isolation
  I like this feature in IIS 6.0 which allows you to isolate applications in application pools. By creating new application pools and assigning web sites and applications to them, you can make your server more efficient and reliable as it ensures that other applications or sites do not get affected due to a faulty application running under that pool.

Summary
All of the aforementioned IIS tips and tools are natively available in Windows. Don’t forget to try just one at a time before you test your Web accessibility. It could be disastrous if all of these were implemented at the same time making you wonder what is causing a problem in case you start having issues.

One final tip: Go to your Web server and Run “netstat –an” (without quotes) at the command line. Observe how many different IP addresses are trying to gain connectivity to your machine, mostly via port 80. If you see that you have IP addresses established at a number of higher ports, then you’ve already got a bit of investigating to do.

Click Next and let the server detect your settings, then choose Custom Configuration and click Next. Choose the Application Server Role from the list and click Next.

Since many applications require ASP.NET today, we’re going to choose to Enable ASP.NET. In addition, we will not choose to enable FrontPage Extensions at this time though.

Note: In order to publish .NET applications from VisualStudio, you may want to enable FrontPage Extensions to start with.

Moving ahead, once we’ve selected what we want, we click Next to set up the role. Just let the wizard run until you see the finish button, then click Finish.

Once you’ve installed the Application Server role to your server, you’ll naturally want to check and see if it works. The Manage Your Server wizard should now show the Application Server role installed, so click on Manage This Application Server.

This brings up the Application Server Management Console (MMC). Expand the Internet Information Services (IIS) Manager, then expand your server (local computer), and then the Web Sites folder. You should see the Default Web Site listed as shown below, and it shouldn’t say “Stopped”. If it does, you need to troubleshoot using the Event Viewer.

For now, ignore the files and folders listed in your default web site, we just want to run a test and ensure that IIS is running and serving a web page. On the server itself, launch Internet Explorer (IE) and browse to http://localhost/. You should see the “Under Construction” web page if the server is running correctly.

Okay, at this point you have a working IIS installation. Go back to the Application Server Management Console and right-click on the Default Web Site. Choose Properties to bring up the web site properties dialog. Then click on the Home Directory tab and ensure that the Default Site is set to the path shown below.

Because of the security enhancements in Windows Server 2003 and IIS 6, ASP pages are not enabled by default. Yes, we did install the server for ASP.NET, but ASP and ASP.NET isn’t the same thing.

In IIS 6, technologies like ASP, ASP.NET and so on are called Web Service Extensions. The same is true of Server Side Includes, PERL/CGI scripting, PHP and a host of other add-ons to web servers. Since many web sites run ASP (Active Server Pages), let’s activate ASP.

In the Application Server Management Console, click on the Web Service Extensions folder underneath the server name. You should see that Active Server Pages are Prohibited, this is the default configuration of IIS.

Simply set the extension to Allowed and the web server will start serving ASP pages. Repeat this for Server Side Includes too. This is required so that client pages parse the <include> variable in a page.

Last but not the least – you may probably want to shift your default web site as well as other web sites that you are going to host on the server off the System Partition (the one where the OS is installed). It’s always a good idea to shift the web site content to a different drive.

That’s it for the basic clean IIS 6.0 installation.