IIS5, IIS6, IIS7, Apache web servers

Security, news, configuration information about most popular web servers on WEB.

Click here to play!
Best Online Casino

Wednesday, May 24, 2006

Windows Vista Beta 2 & IIS7 beta 2

Windows Vista Beta 2 and 2007 Office System Beta 2 are now available for immediate download from MSDN Subscriber Downloads.
Also IIS7 beta 2 included.



Be among the first to download Vista and Office by signing in above. Once authenticated, you can begin the download.



Note that this build of Windows Vista Beta 2 contains functionality to unlock several different versions of the software, including Windows Vista Ultimate Beta 2, Windows Vista Business Beta 2, Windows Vista Home Premium Beta 2, and Windows Vista Home Basic Beta 2. Please visit the Product Keys page within MSDN Subscriber Downloads to obtain the Windows Vista Beta 2 key(s) for the product(s) you prefer.



For more information on Windows Vista or 2007 Office System, please visit the MSDN Developer Centers for Windows Vista and 2007 Office System.



Get It First! from MSDN Subscriber Downloads.

Tuesday, May 16, 2006

IIS7 first impression

Couple IIS7 gotchas running ASP.NET Apps
I've had a little time today playing around with IIS 7 on Vista, and there are a couple of problems that took some time to get around to get an application to run. If you're trying out IIS with your ASP.NET applications this might help you.



#1

The default installation sets up AppPools under NETWORK SERVICE, but NETWORK SERVICE is not added the Temporary ASP.NET directory in the .NET framework path. This causes ASP.NET to fail out right complaining that an invalid directory name is used.



Actually this may not be the whole of it as I tried adding NETWORK SERVICE to the permission set and adding it file full access rights. Still doesn't work. Ultimately I had to change the AppPool to run under Local System and then the app started running.



I'm not sure what else could be the problem with NETWORK SERVICE, but it works with SYSTEM. Obviously this is not a secure solution but it works for now. In any case the default installation apparently doesn't have enough permissions to run ASP.NET apps (much like .NET 1.0 did).



#2

It looks like the ASP.NET State Service is nowhere to be found. I installed IIS using default options, but no state service. I went back to Windows Component to install under IIS but I see nothing that explicitly installs this service.



At this point I had to switch back to InProc, which is fine for testing.



It's taken a few false starts to get even this far. At this point I have several apps running both in ISAPI pipeline (IIS 6 mode) or in the integrated pipeline (IIS 7 mode) and the 3 apps I threw at it were running fine. In addition I also installed a Web Connection ISAPI application on the server and that ran fine as well at least in ISAPI mode. However, in either of these cases the configuration applications did not work as it looks like ADSI configuration is either not there at all or disabled in this build.



Now I can actually play around with the new features of the integrated pipeline. The most interesting thing to me at least is the low level HTTP Module integration that allows .NET components to handle all traffic directed at the server. There are a couple of interesting things I want to try including throwing Web Connection into this area and replacing the truly hideous ISAPI/COM code that drives that particular engine.



One of the more visual changes for IIS 7 is the new management tool which replaces the MMC interface. I was looking forward to this, because as far as I'm concerned the MMC has produced nothing but horrible interfaces. The new management tool looks a lot nicer and more importantly is a lot more snappy.







Unfortunately it's a mess to use at this point. The interface is horribly busy and there are way too many options the various pages with names that are not real clear. The console mixes both IIS and ASP.NET settings which I think is part of the reason for this confusing interface as there are terminology overlaps. While there are grouping options it seems that you end up hunting around a lot for finding the right options. As bad as the IIS 6/5 MMMC interfaces were, the way they grouped the various choices together seemed reasonably logical and well organized and you get to most places with a couple of clicks.



Here the choices seem scattered about in inconsistent ways in many places. One good example, is the basic properties dialog which is not accessible through the main list but sits of on the side and context menu only. But these options are accessible only in the top level view, not when you're furtherdown.



I'm sure it's not easy to build an interface for this many options, but I think what's really needed is much better grouping of options. Some high level overview that has a manageable number of options on it into which you can drill down later.

Wednesday, April 26, 2006

Internet Information Services

IIS, an acronym for Internet Information Services is a web application server program that handles HTTP requests, ranking second in popularity (after Apache). Its popularity is mainly due to the fact that IIS sites are so easy to implement - just a few mouse-clicks away - from a total disaster.
Easy to use, easy to hack. Indeed, the ease of installation can further tempt users to overlook careful planning, adequate fundamental security measures or patching holes when they emerge. Such a default installation is massively vulnerable and it is no wonder that attackers are finding IIS to be "the easiest pickings" of all Web servers. Something must be going on if one considers the outburst of CodeRed infection. If so, what can be done to prevent the problem? The most important aspect of any security countermeasure is, knowing what to look for and where to look for it.

The Internet Information Services is a suite of tools and services for creating, managing, and securing Web sites that is included with Windows NT operating systems (also Windows 2000, XP and .NET). The IIS services are tightly integrated with the operating system and therefore all IIS versions are Windows-dependent, namely:

IIS 5 - is associated with Windows 2000 (all versions) IIS 5.1 - is associated with Windows XP Professional IIS 6 - is associated with Windows .NET Server IIS versions 3 and 4 are designed for Windows NT 4.0, (technical support for this is expected to be terminated by the end of 2002)[1]. The IIS Versions designed for workstations (that is IIS5 in Windows 2000 Professional and IIS5.1 in Windows XP Professional) have limited functionality as compared with their server versions (IIS5 on Windows 2000 Server and IIS6 on Windows .NET Server). This limited functionality relates, for example, to a maximum of 10 concurrently handled HTTP requests, the possibility of running a single Web site only, lack of host IP-based access control list, no Connection Limit extension. Therefore, IIS workstations are not suitable for serving up fully functional web sites - this limitation continually triggers the irritating "403 Too many users" message, despite the fact that the logs show that there are fewer than 10.



(Fig.1 Whether our site is reaching its maximum popularity or our server is experiencing difficulties to handle requests?)

Since Windows .NET Server (together with IIS6) is at the moment undergoing finishing touches and unavailable for purchase as yet, we will focus below on Windows 2000 Server IIS Version 5. This is because this version is currently the most suitable to be a powerful server for a new generation of Web applications. Moreover, given the availability of downloadable patches being of vital importance for web server security, we will deal further with the English Version of Windows 2000 Server.

Getting installed with IISAll IIS services are installed in the same manner as any other Windows component - through the Control Panel: select "Add/Remove Programs", then click on "Add/Remove Windows Components". The screen will appear that allows you to install new Windows components - this requires caution, because an operating system connected to the Internet is particularly vulnerable to attacks. Therefore DO NOT install IIS together with services that are of key importance for LAN functionality or security. Locate the Internet Information Services (IIS) entry and then click on the Details button to select the necessary IIS pieces of functionality. They are:

Common Files - that is, the main files and services included with IIS, Documentation - files of the Default Web Site, files containing IIS error messages and the basic HTML documentation (C:\WINNT\Help\iisHelp directory), Internet Information Services Snap-In - an application for managing IIS from the Microsoft Management Console (MMC), World Wide Web Server - which provides Hyper Text Transfer Protocol (HTTP) services compiled in a user-friendly manner.Other IIS components that may deserve further attention are as follows:

File Transfer Protocol (FTP) Server - included in the system provides support for an FTP account. Remember however, that the FTP service lets you force anonymous logons because it does not use encryption for authentication. You should also be very restrained when considering other options that require logons (web site update, sharing files). NNTP Service - to host newsgroups. It can be utilized, for example, for client-to-server and employee communications, but it is not recommended to use the USENET features (that is the commonly available newsgroup hierarchy) because of their limitations. SMTP Service - the email server. Being an SMPT server, it provides only mail delivery functionality. It is not intended to aid in receipt of emails, but with its Collaboration Data Objects (CDO) component it is able to forward messages from WWW sites. Remember, however, to ensure that your spam-borne mailing service will be appropriately secured to avoid this nuisance i.e. preventing your server from being used to relay spam! [2] There are also components that when installed, may be risky from the security point of view and are therefore not recommended, please consider:

FrontPage 2000 Server Extensions - this is a special communication protocol that supports authoring and administering Microsoft FrontPage webs, Internet Service Manager (HTML) - is designed to configure and monitor IIS using WWW pages, Visual InterDev RAD Remote Deployment Support -this is a sub-component that assists in the development of web applications via Visual InterDev. While installing IIS remember, that any subsequently added service will imply the need for proper configuration and maintenance of its security environment otherwise problems may occur and worse, persist. On poorly secured and/or configured servers everything may happen quickly: unauthorized third party relaying, illegal contents, mail viruses and hacking attempts, potentially involving "ritual" problems, with possible legal risks for you, as the owner of the server. Depending on the scale of your web site, installation of the previously mentioned IIS components, SMPT and anonymous FTP may be enough.



(Fig. 2 Installing IIS)

The general approach involves closing down the connections to the Internet while installing web services - once installed, IIS can potentially expose your server to unfriendly forces. Of course, a complete firewall solution or a NAT device may be enough to deny incoming traffic as appropriate. In fact, further sections of this article will be devoted to some security countermeasures allowing a safe installation of IIS components while still allowing Internet connectivity and access to your WWW pages.

Security considerationsThe first step in securing your server is to download the most updated Service Pack (currently Service Pack 3 [3]) and current IIS patches (MS02-062 is the recent patch concurrent with this article [4]). The system administrator, should also download other patches as required for Windows 2000 [5] (at least consider seriously their implementation) and Internet Information Services 5.0 [6]



(Fig. 3 Windows 2000 Patches & Updates).

In addition, don't forget to register so that you will automatically receive Microsoft security bulletins [7]. This is of fundamental importance because procurement and installation of any update patches is a must from time to time in order to keep the server operating securely (hackers and viruses like to find out where "lousy software" is!). Don't forget to confirm your subscription by replying to the email with the instructions included.

In the next step, setting up the computer is important enough to not be ignored [8]. The simplest way is to get HiSecWeb.exe file from the Microsoft Web site [9], unpack it to the C:\WINNT\Security\Templates and follow the instructions given in [10]. Open it in mmc.exe (using the "Security Configuration and Analysis" application to be downloaded from the Console > Add/Remove Snap-In menu) and run (being prompted to import hisecweb.inf, select "Analyze Computer Now" from Action menu, and then "Configure Computer Now." Remember that HiSecWeb is designed for dedicated Web servers and it disables all services that are not associated with web access services. The HiSecWeb package does not alter the permissions within the file structure on the system partition [11], while the WWW files are to be installed on a non-system partition, the hardening of which will be discussed later.

Post installationOnce all necessary patches and updates have been applied and the system settings chosen, you must disable access to the default Web site that has been installed concurrently with the IIS documentation. To do this, run "Internet Services Manager" (within administrative tools, that is Programs > Administrative Tools). This program is an MMC application that was been previously installed under the name "Internet Information Services Snap-In". Once started, choose a name for the server, right mouse click on "Default Web Site", and then select "Properties" from the popup menu.

In order to disable the default web site, assign it to the localhost address (that is 127.0.0.1) - in the "IP Address" box (the "Web Site" tab) delete "(All Unassigned)" and insert 127.0.0.1, and then click "OK"



(Fig. 4 assigning the default web site to the localhost address).

This will cause the default web site to only be accessed from the web browser running on the server, not from the network. It is better to leave the default web site disabled rather than remove it, as it may come in handy later. Right mouse-click on the Default Web Site and select "Stop" in popup menu (instead using the right mouse button, you may use "Action" menu). Naturally, if you plan not to use the default web site anymore, for example to check location of IIS installed files or to read IIS documentation, you can remove it (from popup menu). So far, no other changes to the IIS configuration are necessary, but you can review all tab settings. As you can simply check, directories (and even individual files) can have their own settings within the IIS configuration.

In the next step related to the IIS hardening, you should set master properties for the WWW services. Contrary to the default web site configuration, the IIS configuration is a hierarchical one, that is, any changes to the IIS configuration associated with the WWW Service Master Properties (W3SVC for short) can be inherited through the hierarchy of the embedded system components (sites, applications, directories and files). When you configure properties at the level of the IIS server, certain security-related settings will become the default settings for all web sites (the existing ones and those which are to be created). Before attempting to change settings, ensure that you make a backup copy of the metabase (i.e. the IIS configuration). To do this, in the "Internet Services Manager" application, right mouse- click the server (not the web site!) and click on "Backup/Restore Configuration". The backup IIS copy management window will appear. Click on "Create backup " , and insert the backup copy name (for example "Manufacturer's Configuration") and click OK. The backup copy has been stored to the file in the C:\WINNT\system32\inetsrv\MetaBack directory.



(Fig. 5 the first IIS configuration backup copy).

After making the backup copy, close the "Configuration Backup / Restore" and configure the W3SVC services. Right mouse click on the computer name and select "Properties". Under "Master Properties", click "Edit " next to the "WWW Service" tab. The window similar to the web site configuration will appear - it has its "Service" tab. Pay attention, that certain components are disabled (because they are consistent with individual web sites only). On the "Web Site" tab, select the "Enable Logging" check box and then select the format (I recommend that you select "W3C Extended Log File Format"). Pressing the "Properties" button can modify both the file rollover period (preferably leave "Daily") and the location of the log directory. Because a typical server can have logs measuring dozens of MB daily, it is a good idea to choose a directory on a dedicated disk, for example E:\LogFiles (remember to establish an appropriate directory on the selected partition). You may also enable local time logging (I don't recommend this), and select the scope of the logged information. My advice is to select all boxes excluding "Process accounting" on the "Extended Properties" tab. These options are useful at troubleshooting, detecting intrusions, examining traffic etc. The "Process Accounting" boxes allow one to analyze the server load resulting from individual HTTP requests, but I do not recommend that one use them during a normal operation of the server.



(Fig. 6 Details of WWW Server logins).

After enabling the logging feature (in the master properties of the W3SVC), change the Home Directory settings. In the "WWW Service Master Properties" window, select the "Home Directory" tab and then click on "Configuration ". The "Application Configuration" window will appear, it allows you to set up dynamic WWW pages that are files with specific extensions. Whenever they are called from the Web, they will be passed through the W3SVC service for execution by ISAPI applications, that is additional programs (more specifically - DLLs) installed on the WWW server. These programs are, for example, C:\WINNT\System32\inetsrv\asp.dll, ism.dll, httpodbc.dll, ssinc.dll and C:\WINNT\System32\msw3prt.dll, idq.dll and webhits.dll (within the same directory). You must remove all said programs, leaving only those using asp.dll (and also ssinc.dll if it is considered useful) - all others were used in the past for breaking into the IIS servers and infecting them with viruses (for example CodeRed that uses a known buffer overflow vulnerability contained in the idq.dll). Of course, given all these patches and updates installed previously, it is quite impossible to feel unsecure even with the entire set of ISAPI programs enabled. However, an experienced system administrator would know the old German saying, "once lost, confidence does not easily return" - particularly when the ism.dll application had "lost confidence" with its record-breaking negative events. One is advised to only leave enabled for use the asp.dll and possibly ssinc.dll - since they both also had security-related problems, but of considerably less importance and which were far more difficult to be exploited by hackers.

Files with .inc extensions will not be compiled, executed, or served with the default installation of IIS. In order to have ASP pages served, you will need to give all include files a .ASP extension and add these extensions to the Web Service Extensions list. Otherwise whenever any request is made for an .inc suffixed page, its code will be revealed for public viewing instead of executing it (even with errors, it is far better than publicizing dynamic pages code). Of course, the same procedure should be followed for any other extension scripts. Those who save ASP customization in the .txt files deserve to be given special attention from the system administrator.

In order to setup the extension service via ISAPI applications, click on the "Add" button and then fill in the boxes:

Executable: C:\WINNT\System32\inetsrv\asp.dll Extension: .inc Limit to: POST, GET, and HEAD It is a good idea to provide each extension (those default included) with the "Check that file exists" option enabled - this setting implies that if the requested file doesn't exist, the usual error processing occurs ("404 Not Found") instead of producing the ISAPI application error.



(Fig. 7 Adding ISAPI scripting environment).

The ISAPI msw3prt.dll functionality is dependent both on the IIS and "Web-based printing" setup in the group policy (defined on a local computer and the relevant GPO). It also depends on Print Spooler functionality - which was disabled while launching hisecweb.inf. When you intend to upgrade a Service Pack (sooner or later), the installer activates the Print Spooler service if it's not already running. However, if you have disabled the start-up type for this service, the service will fail to start. This is a strange but consistent requirement associated with the installation of all existing Windows 2000 upgrade packages.

The next important applications to be set up are listed in the tabs of the "Application Configuration" window. On the "App Options" tab, clear the "Enable parent paths" setting to ensure that the FileSystemObject started by an ASP application is limited to that application's defined directory. Another possible service to disable is the "Enable session state" to avoid overloading the server's memory at any ASP request. (Encourage the Webmaster to accept this change). On a cluster of Web servers (where many Web servers share the responsibility for responding to user requests), a Web page will not always function properly. This is because a single user session cannot be created on one server and then read and modified on another. With the advent of IIS 6 and its user session synchronizing support, this limitation will not longer be maintained.

On the "Process Options" tab you can either modify or disable the ASP file cache size - I would discourage you from enabling "Cache all requested ASP files" as the usage of server RAM for ASP session variables could become quite significant.

Lastly, on the "App Debugging" tab, ensure that the debugging options are unchecked and change "Send detailed ASP error messages to client" to "Send text error message to client". This will prevent potential attackers from compromising your website and then provide a simple text for error of WWW services with a possible email address included for reporting problems. With all applications set up as desired, click OK.

If at anytime during these steps you see the "Inheritance Overrides" properties box, this means that certain W3SVC components (web site etc.) have their own settings that are different from the master properties being applied. As you may remember, settings are inheritable, therefore you must decide whether to delete or maintain invariant certain settings as replicated ones. As the default web site is of concern, I suggest not to change anything, whilst for your own web sites use the documentation you are maintaining as guidance. Just click the OK button - do not touch the list! - The master properties will be modified but those previously set will remain unchanged.



(Fig. 8 Changing Master Properties; the Default Web Site settings remain unchanged)

After defining the default application settings, go to change the default WWW site settings. Select the "Directory Security" tab in the "WWW Service Master Properties" window, click on the upper button marked "Edit". The "Authentication Methods" window will appear with their enabled "Anonymous access" and "Integrated Windows authentication" options. It is advisable to uncheck the latter option in respect to commonly accessible WWW pages - it may allow "brute force" attacks from the Internet, targeted at unscrambling server (or related network) user passwords in transit. Unfortunately, this option is to be recurrently disabled, since it is activated by default whenever any new domain is opened. Also remember to uncheck the authentication options after installing SMTP and/or FTP services - this issue will be discussed later. After pressing OK, and then "Apply" you will again see the "Inheritance Overrides" window - do not enable any component belonging to the default web site (for example the .in. file localstart.asp file) and click OK again. The "Edit" button underneath allows defining of appropriate IP and domain restrictions - you might use it for a server that by default is designed for access by a selected group of users only (for example Intranet users or your company partners connected via ISDN). Remember that IP restrictions do not ensure high security level - today's IP protocol does not provide fully secure authentication of the connection source. If you want to have your server accessible from trusted sites only, take advantage of a Virtual Private Network (VPN) solution. On the "Documents" tab you can define default documents. If a domain or directory contains a file with its filename not listed here, the user will see the "403 Forbidden" error message (or the content of the entire directory if the "Directory browsing" has been enabled in the Home Directory option). It is good practice to consult the Webmaster about filenames to be placed on the list - for example, it may be required to add a name index.html.

Generally speaking, your IIS server is now fully set up. However don't forget to look at other tabs to ensure that the "Home Directory" tab has unchecked the "Read", "Write" or "Directory browsing" options, that the "Execute Permissions" (related to dynamic pages) are set to "None", and that "Log visits" is ON. As for the "Home Directory" settings, they will be re-visited after a new WWW site has been established.

Creating Web pagesWhen creating web pages, it is important to be aware of a problem when starting the work: you should provide a separate partition for WWW pages. Create separate partitions for your NT and Internet data. This suggestion is subtle but important. If you place each logical group of files or each independent directory structure on a separate partition (separate logical disk drives); you reduce the risk of contamination. For example, if you store your Web pages and your Web scripts in the same directory, hackers can break into your Web page area and easily contaminate your scripts.

This can be the same partition you use to store logs - pay attention not to store operating system programs on it (preferably no other programs if possible). Why this requirement? Unfortunately, IIS has a history of problems regarding improper access to programs outside the directory of WWW pages; and still there are many strange entries like "/scripts/../../winnt/system32/cmd.exe+/c+dir+\" found in server logs worldwide. Bugs in ".."path handling that were allowed to pass from the site directory to the operating system directories and run the programs residing under these directories were responsible for this. These bugs could be exploited to launch attacks from the sites hosted on the operating system partition. All other situations where relevant partition-related security recommendations were observed i.e. that used separate partitions for the operating system and WWW pages and with the "Default Web Site" disabled were immune to attacks despite the same IIS holes, because a potential attacker could not redirect his request between various disks. Due to a hard time learning slowly from our own mistakes - this costly experience can be avoided by following the said recommendation, (in addition to disabling the default web site, removing unnecessary ISAPI services and setting restrictive file access policies) that is one of the key IIS related security issues. It is an obvious choice, and is included as one of the options when you set up each IIS directory. Any directory you want to protect must be on a NTFS partition - for example E:\WebFiles and subdirectories of individual domains, for example E:\WebFiles\W3SVC2. Make sure you set out appropriate file access permissions: right click on the disk with your domain content and select the "Security" tab. Be aware, that IIS is particularly sensitive to the presence (or absence) of group "Everyone". Remove this hacker invitation from your server, then click "Add " and enable access for Administrators, SYSTEM and Authenticated Users. Then, still on the "Security" tab associated with Administrators and SYSTEM activate maximum permissions with "Full Control", whilst for Authenticated Users, uncheck all, leaving only "List Folder Contents". Confirm your disk security settings by pressing OK. Then mouse select the WebFiles directory, again open the "Properties" window with right mouse click and on the "Security" tab give the Authenticated Users permissions under "Read & Execute" (and also "Read" by default). It is suggested that such an entire set of file access permissions, simplified but conceptually sufficient, is as follows:

For Administrators: Full Control, For Authenticated Users: List Folder Contents, For SYSTEM: Full Control, For Authenticated Users: Read & Execute. Now, with such an "over-hardened" dedicated partition you have a certain margin for loosening restrictions on any other directory, that from time to time may share the disk with WWW sites content. If the log directory is placed on the same partition, you should add the users appropriate read access:

The log directory - Users: Read After setting the directory for all sites, you should set a subdirectory for your new site. Let's name it W3SVC2 - because it is a directory designed for the second site (W3SVC services). The same naming convention is used by the IIS service to name subdirectories containing the web site logs - of course, you may not use it if you don't wish to, but this solution can facilitate log interpreting when more web sites exist. The next thing to do is associated with the well-known "Internet Services Manager" program: run it and halt the default web site selecting the "Stop" option in the popup menu - if this has not been carried out before. Upon completion of these preparatory activities, create a new IIS web site. Right mouse click on the server name and from the popup menu, select New, and then select "Web Site" from the respective submenu. The "Web Site Creation Wizard" window will appear. Click "Next >" on the Welcome screen, then place a short description of your site (it may resemble the WWW address)



(Fig. 9 A short description of your site).

On the next screen, specify the IP address of your website (among those configured at the server - alternatively, you can use any of those available). Then the TCP port (it is recommended to use the 80 port only - using non-standard ports does not enhance security but rather makes more difficult to use web services) and, if you wish, the Web address of your site. This last box is to be filled in if you wish to have multiple sites running on a single IP address, differentiated only by their DNS names.



(Fig. 10 [...] Your Web site address).

Once again click "Next >" and locate your "elaborated" Home Directory - in this example E:\WebFiles\W3SVC2



(Fig. 11 [...] location of files).

Leave the "Allow anonymous access to this Web site" enabled and go to the last web site configuration screen to complete settings for the new web site. Here, leave the "Read" and "Run scripts" boxes enabled as they are. The first is designed to allow reading of static web site files- that is HTML, graphics, style spreadsheets, presentations, that is the files that are sent to Web users with no additional server operation required. Dynamic web pages (that is the scripts activated by ISAPI applications already set up under "Application Configuration") use the settings established in "Run scripts" - if using ASP pages is required, make sure that this box remains checked. Answering the question "Do I really need the "Execute" enabled? Is your next step. This option allows running of programs via the IIS server interface (including EXE files and DLLs, also called ISAPI applications) located in the web site - it is very likely to be exploited by enemies, because these powerful programs, if buggy, may be exploited by a hacker. Another threat but even more concerning is associated with the "Write" setting - all publicly available web sites should not be write-accessible and in this example this requirement has been fulfilled by appropriate file access restrictions settings. Enabling the Browse functionality will provide users with access to your web site as to a common FTP server. You can also enable it, if both names and contents of your files can be publicized (for example, if it is required to have an anonymous file server accessed via HTTP). Of course, you can apply such a setting for a chosen site subdirectory not to worsen aesthetic quality of your Home Page.



(Fig. 12 [...])

Finally, go to set up permissions for Internet users. After clicking on the "Next >" button, press "Finish" on the final screen - you will see the web site launched in the IIS server environment. Right click on it and select Properties tab followed by the "Home Directory" tab. The same tab is available at the settings of any web site subdirectory, so you will be able to individually set up access permissions in respect to specific directories depending on their content. The following options are seen while creating the web site:

"Script source access" allows access to dynamic pages source code via HTTP; it is better not to use this option. "Read" allows reading of web site files. If the web site or a subdirectory contain solely dynamic page scripts, you may disable this option; "Write" allows writing of files via HTTP. If your server is accessible on the Web, uncheck this option; "Directory browsing" enables a user to navigate through your WWW server directory structure (names of all files). It can be activated from a subdirectory performing the role of an anonymous file server. If you decide to enable this option, you will be likely to need to uncheck the "Enable Default Document" option on the "Documents" tab; Options "Log visits" and "Index this resource" - the first one should always be enabled, the second one not, unless the file indexing service has been installed on your server; "Execute Permissions"- when enabled, it is an equivalent to the "Run scripts" and "Execute" options together, being visible on the final screen while creating web sites. "None" corresponds to non-selecting any of the said options. "Scripts only," means the same as "Run scripts" enabled, whilst "Scripts and Executables" - corresponds to both options enabled. For directories containing static files only, (for example a directory with graphics or a file server) select "None", whilst for typical directories with ASP pages set "Scripts only"; May I suggest that you do not use the third alternative if possible "Application Protection" box - you can select a process that will be responsible for running ASP sites - preferably Medium or High to be checked. Do not enable "Low (IIS Process)", because you will be at heavy risk of possible running dynamic WWW under SYSTEM user privileges! Setting to "Medium" will place your ASP in a "pooled application" process. Selecting "High" will allow you to run an ASP "on its own" thereby enhancing security by separating web sites. Additionally; "Configuration" button allows one to modify ASP settings. If you have selected a high level of application separation (option "High" as described above), you will have access to an additional tab named "Process Options" in the "Application Configuration". This window has been already described when describing the server global configuration procedures. "Remove" (or "Create") - you can use it to create/delete ASP applications on the web site or its subdirectories. My advice is to not delete the application belonging to the web site! "Unload" button allows one to momentarily reduce server burden from ASP pages by removing ASP application from the memory The final setup component is associated with the location of web site files (it is provided in the upper portion of the window) - you can change the location of the Home Page directory or activate redirecting to another web site. Do not use the "A share located on another computer" option - this may imply a heavy overhead to the file server service and "unexplainable" lowering of your server performance. [12] [13] [14] [15] The above settings are documented in the IIS popup help facility (use Shift-F1 while previewing setup windows) and also in the Microsoft Knowledge Base [11] [16]. Moreover, the TechNet Whitepaper available at the Microsoft Web site may be helpful [17] [18].

Having completed the preview of the Home Page settings, go to enhance security parameters on the "Directory Security" tab - click on the upper button marked "Edit", then in the "Authentication Methods" window only leave enabled the "Anonymous access" option. You will need to remove the "Integrated Windows authentication" option that is unfortunately activated by default (you don't want to risk successful brute force attacks, do you?)



(Fig. 13 the final patch).

The same applies for other IIS server services - if you have installed the FTP service, enable the anonymous FTP user. In the "Internet Services Manager" application, click on "Default FTP Site" and select Properties from the popup menu. In the "Default FTP Site Properties" go to the "Security Accounts" tab and check the "Allow only anonymous connections" option. In this manner you will cause the FTP to be prevented from hacking away at usernames and passwords. If you have installed the SMTP service, also ensure that you disable this opportunity - click on "Default SMTP Virtual Server", and select Properties from the popup menu. In the "Default SMTP Virtual Server Properties" select the "Access" tab and click on "Authentication". You will see the user authentication access mode window - delete all options except for the highest one ("Anonymous access"). Of course, you can set up your services so that they will be accessible to trusted users of your network (offering them extra services, for example, accessing confidential files), but this is associated with some additional operations to enhance security of passwords involved.

What about the web sites?If you want to see your new site in the web browser, you have to add some files to it, at least a notepad-created default.html. You may manually copy the files from a CD-R, e-mail or a diskette, sent you by the Webmaster. This is an often-used solution allowing for documentation of the changes effected on the Web site. It is however possible that you would have to allow the Webmaster to save the files directly to the web site. Firstly you have to create an account for him. If the WWW server belongs to a Windows NT or an Active Directory domain, you may use a domain account. You should take note of the fact that the Ethernet card receiving HTTP tasks from the Internet must not be connected to the internal network - they have to be separate network interfaces. Then, you modify the authorizations in the file system, attributing the Webmaster the right of writing and modifying the files of the chosen web site (in our case of the E:/WebFiles/W3SVC2 directory). If you have a local area network and a WWW server belonging to the domain, you may define the access as a simple network share on the directory that contains the Web site's files (E:/Webfiles). Otherwise, you may define a new virtual FTP site (choose New -> FTP Site in the IIS server's popup menu). Your FTP 'site' has to be accessible from a trusted network only! To achieve this objective you should use the other Ethernet card installed in the server or the firmware VPN (or an IPsec tunnel) - it is important that the card's IP is not at all accessible from the Internet. While setting up a virtual FTP server you should choose this IP address. E:/WebFiles will be the home directory of the FTP 'site'. You should authorize the Webmaster to write in the directory, too, with the use of the 'Write' option on the last screen of the FTP site creation process. Additionally, the FTP server's setup should block any access coming from IP addresses not belonging to the VPN and/or the local area network. This is an extra means of security, which could save you from some consequences of the mistakes made in the process of connecting the server to the network. A more important way of securing yourself is a trusted network interface, accessible from the local area and/or VPN network, but inaccessible from the Internet. Its trust should not be based on the computer's configuration but on the topology and means of security of the network it is connected to. This is however a topic for another article. And now you can finally connect your new WWW server to the Internet!

Wednesday, February 15, 2006

Changes to Metabase Properties in IIS 6.0 (IIS 6.0)

Appendix B: Changes to Metabase Properties in IIS 6.0 (IIS 6.0)

There are IIS 5.0 metabase properties that are no longer supported in IIS 6.0. When upgrading or migrating from an earlier version of IIS, these properties are still in the metabase, but IIS 6.0 ignores the settings. On a new installation of IIS 6.0, these properties have been removed from the metabase, and they are not available even when IIS 6.0 is running in IIS 5.0 isolation mode.

There is one IIS 5.0 metabase property — CPUResetInterval — that still exists in the IIS 6.0 metabase, but it behaves differently in IIS 6.0.

Table 1.1 lists metabase properties that have changed in IIS 6.0. If your Web sites, applications, or setup programs reference any of these IIS metabase properties, follow the recommendations described in the table to accommodate these changes and ensure compatibility with IIS 6.0.

Table 1.1 IIS Metabase Properties That Have Changed Since IIS 5.0
IIS Metabase Properties Recommendation
• AspThreadGateEnabled

• AspThreadGateLoadHigh

• AspThreadGateLoadLow

• AspThreadGateSleepMax

• AspThreadGateTimeSlice

In IIS 5.0, these metabase properties are provided for the configuration of performance features.

In IIS 6.0, these performance features are provided by other means. As a result, IIS 6.0 no longer uses these metabase properties.

Remove any references to these metabase properties from Web sites, applications, or setup programs.

For more information about improving performance in IIS 6.0, see Web Server Scalability.

• CPUAppEnabled

• CPUCGIEnabled

• CPUCGILimit

• CPUEnableActiveProcs

• CPUEnableAllProcLogging

• CPUEnableAppLogging

• CPUEnableCGILogging

• CPUEnableEvent

• CPUEnableKernelTime

• CPUEnablePageFaults

• CPUEnableProcType

• CPUEnableTerminatedProcs

• CPUEnableTotalProcs

• CPUEnableUserTime

• CPULimitLogEvent

• CPULimitPause

• CPULimitPriority

• CPULimitProcStop

• CPULimitsEnabled

• CPULoggingInterval

• CPULoggingMask

• CPULoggingOptions

In IIS 5.0, these metabase properties are provided for the configuration of processor (CPU) management features.

In IIS 6.0, processor management (CPU throttling) is provided by other means. As a result, IIS 6.0 no longer uses these metabase properties.

Remove any references to these IIS metabase properties from Web sites, applications, or setup programs.

The following metabase properties reference and implement CPU throttling in IIS 6.0:

• CPULimit

• CPUResetInterval

• CPUAction


For more information about CPU throttling in IIS 6.0, see the CPULimit Metabase Property, CPUResetInterval Metabase Property, and CPUAction Metabase Property metabase properties.

CPUResetInterval
In IIS 5.0, this property enables the monitoring of processor utilization at the Web site level. IIS 5.0 was unable to monitor individual processes for a Web site, such as multiple processes in an ASP.NET Web garden.

In IIS 6.0, this property enables the monitoring of processor utilization at the worker process level. You cannot monitor the processor utilization for individual Web sites unless there is only one Web site in the application pool.

For more information about how to configure this value for worker processes in an application pool, see the CPUResetInterval Metabase Property metabase property.

DisableSocketPooling
In IIS 4.0 and IIS 5.0, Windows Sockets (WinSock) listens for HTTP requests that use Transmission Control Protocol (TCP). WinSock uses the concept of sockets to provide TCP connectivity. As a result, IIS 4.0 and IIS 5.0 are bound to the scalability constraints of using sockets through WinSock. In IIS 5.0, socket pooling addresses these scalability problems, in cases where a large number of Web sites were configured with individual IP addresses.

In IIS 5.0, socket pooling allows for socket resources to be shared between multiple Web sites and thus provides significant improvements — up to two to three times the scaling capacity of earlier versions of IIS.

In IIS 6.0, HTTP.sys is responsible for listening for HTTP requests and provides similar functionality to the DisableSocketPooling metabase property.

To configure HTTP.sys, use Httpcfg.exe.

Note

On new installations of Windows Server 2003 and IIS 6.0, the DisableSocketPooling metabase property still exists; however, IIS 6.0 ignores the property.ReplaceThisText

HcMimeType
In IIS 5.0, this metabase property indicates which Multipurpose Internet Mail Extensions (MIME) types are supported by the compression scheme.

IIS 6.0, HTTP compression is performed in a different way, and this metabase property is no longer used.

Remove any references to this metabase property from Web sites, applications, or setup programs.

PutReadSize
In IIS 5.0, this metabase property is provided to support the Web Distributed Authoring and Versioning (WebDAV) component, but is untested and unsupported.

In IIS 6.0, this functionality is integrated with the WebDAV component. As a result, IIS 6.0 no longer uses this metabase property.

Remove any references to this metabase property from Web sites, applications, or setup programs.

For more information about WebDAV in IIS 6.0, see About WebDAV.

UNCAuthenticationPassthrough
In IIS 5.0, this metabase property enables pass-through user authentication for Universal Naming Convention (UNC) virtual root access, which is for authentication schemes that support delegation.

In IIS 6.0, pass-through authentication occurs automatically when the UNCUserName and UNCPassword metabase properties are not specified. As a result, IIS 6.0 no longer uses this metabase property.

Remove any references to this metabase property from Web sites, applications, or setup programs.

For more information, see the UNCUserName Metabase Property and UNCPassword Metabase Property metabase properties.

Thursday, February 09, 2006

IIS and Built-in Accounts (IIS 6.0)

IIS and Built-in Accounts (IIS 6.0)

IIS uses a number of built-in Windows accounts, as well as accounts that are specific to IIS. For security reasons, you should be aware of the different accounts and their default user privileges. It can be a security risk to change the identity of a worker process so that it runs as an account with a high level of access, such as the LocalSystem user account.

LocalSystem
The built-in LocalSystem user account has a high level of access privileges; it is part of the Administrators group. If a worker process identity runs as the LocalSystem user account, that worker process has full access to the entire system. When IIS 6.0 is running in IIS 5.0 isolation mode, this is the default user account for worker process identities. LocalSystem has one default user right, Full access.

Top of page
Network Service
The built-in Network Service user account has fewer access privileges on the system than the LocalSystem user account, but the Network Service user account is still able to interact throughout the network with the credentials of the computer account. For IIS 6.0, it is recommended that the worker process identity that is defined for application pools run as the Network Service user account, which is the default setting. The following table shows the default user privileges for the Network Service account, along with how each privilege is derived.


Privilege Source
Replace a process-level token (SeAssignPrimaryTokenPrivilege)
Explicit assignment

Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
Explicit assignment

Generate security audits (SeAuditPrivilege)
Explicit assignment

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

• Access this computer from the network (SeNetworkLogonRight)

Through membership in the Everyone group

• Log on as a batch job (SeBatchLogonRight)

Through membership in the IIS_WPG group

• Log on as a service (SeInteractiveLogonRight)

Explicit assignment

• Impersonate a client after authentication

Through membership in the IIS_WPG group


Top of page
Local Service
The built-in Local Service user account has fewer access privileges on the computer than the Network Service user account, and those user privileges are limited to the local computer. Use the Local Service user account if the worker process does not require access outside the server on which it is running. The following table shows the default user privileges for the Local Service account, along with how each privilege is derived.


Privilege Source
Replace a process-level token (SeAssignPrimaryTokenPrivilege)
Explicit assignment

Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
Explicit assignment

Generate security audits (SeAuditPrivilege)
Explicit assignment

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

• Access this computer from the network (SeNetworkLogonRight)

Through membership in the Everyone group

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment


Top of page
IIS_WPG
The IIS IIS_WPG group account has the minimum permissions and user privileges that are necessary to start and run a worker process on a Web server. Application pool identities must be members of this group so the application pool can register with Http.sys. The following table shows the default user privileges for the IIS_WPG account, along with how each privilege is derived.


Privilege Source
Access this computer from the network (SeNetworkLogonRight)
Through membership in the Everyone group

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

Impersonate a client after authentication (SeImpersonatePrivilege)
Explicit assignment

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment


Top of page
IUSR_ComputerName
The IIS IUSR_ComputerName user account is for anonymous access to IIS. By default, when a user accesses a Web site that uses Anonymous authentication, that user is mapped to the IUSR_ComputerName account. The following table shows the default user privileges for the IUSR_ComputerName account, along with how each privilege is derived.


Privilege Source
Access this computer from the network (SeNetworkLogonRight)
Explicit assignment

• Allow log on locally (SeInteractiveLogonRight)

Explicit assignment

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment


Top of page
IWAM_ComputerName
The IIS IWAM_ComputerName user account is for starting out-of-process applications in IIS 5.0 isolation mode. The following table shows the default user privileges for the IWAM_ComputerName account, along with how each privilege is derived.


Privilege Source
Access this computer from the network (SeNetworkLogonRight)
Explicit assignment

• Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

Explicit assignment

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment

• Replace a process-level token (SeAssignPrimaryTokenPrivilege)

Explicit assignment


Top of page
ASPNET
The built-in ASPNET user account is for running the ASP.NET worker process in IIS 5.0 isolation mode. The following table shows the default user privileges for the ASPNET account, along with how each privilege is derived.


Privilege Source
Access this computer from the network (SeNetworkLogonRight)
Explicit assignment

• Allow logon locally (SeInteractiveLogonRight)

Through membership in the Users group

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Users group

• Deny logon locally (SeDenyInteractiveLogonRight)

Explicit assignment

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment

• Log on as a service (SeInteractiveLogonRight)

Explicit assignment

Wednesday, February 01, 2006

Monitoring Network Activity (IIS 6.0)

Monitoring Network Activity (IIS 6.0)

The primary functions of IIS 6.0 are to establish connections for clients, to receive and interpret requests, and to deliver files — all as quickly as possible. The pace at which these vital functions are performed depends, in large part, on two factors: the effective bandwidth of the link between the server and the network, and the capacity of this link and the server to support network resources.

The speed of the network interfaces also affects the pace. Some servers have two or more network interfaces, which are frequently called front-end and back-end servers. Front-end servers are client-accessible Web servers that run application server software, such as IIS, to handle traffic coming from the Internet. Front-end servers can add a layer of protection for your back-end servers, which include database servers, file servers, domain controllers, and WINS servers. Different interfaces do not necessarily run at the same speed. This is the case, for example, if a Web server is connected to a database server by means of a private network.

If more bandwidth is needed, the network must be upgraded or — in the case of shared-resource networks such as Ethernet — the network must be broken into subnets.

Bandwidth and Capacity
The main purpose of most Web servers is to manage input/output (I/O): Requests come in, and pages go out. Handling I/O requires a certain amount of bandwidth and other server resources as well. In addition to IIS 6.0, network I/O involves TCP/IP, which is implemented by Windows Server 2003 TCP/IP.


Network capacity is measured, in part, by the number of connections that the server establishes and maintains. Bandwidth is measured in several ways:

• By the rate at which bytes are transferred to and from the server.

• By the rate at which the server sends data packages, which include frames, packets, segments, and datagrams.

• By the rate at which the server sends and receives files.



Effective bandwidth varies widely and depends upon the transmission capacity of the link, the server configuration, and the server workload. The values for a single server also change as it operates in response to demand and to competition for shared network resources.


To ensure that your network has sufficient bandwidth and capacity for the network activity it must support, monitor the following performance indicators:

• Data transmission rates at the different Open Systems Interconnection (OSI) layers, because the components that transmit data reside in different layers.

• File transfer rates, because a Web page often requires multiple file transfers.

• TCP connections, because a plateau in connections established, or increases in connection failures and connection resets, can indicate insufficient bandwidth.

Tuesday, January 31, 2006

Iisvdir.vbs: IIS virtual directory script

Product(s):
Windows Server 2003 R2
Windows Server 2003 with SP1
Updated: January 21, 2005


Iisvdir.vbs: IIS virtual directory script
Creates and deletes virtual directories of Web sites on servers running Windows Server 2003 with Internet Information Services (IIS) 6.0.

To view the command syntax, click a command:

• iisvdir /create[#BKMK_create]

• iisvdir /delete[#BKMK_delete]

• iisvdir /query[#BKMK_query]


iisvdir /create
Creates virtual directories on Web sites on servers running Windows Server 2003 with Internet Information Services (IIS) 6.0.

Syntax
iisvdir[.vbs] /create WebSite[/VirtualPath] Name PhysicalPath [/sComputer [/u [Domain\]User [/p Password]]]

Parameters
WebSite Required. Specifies the descriptive name or metabase path of the Web site.
VirtualPath Specifies a path to the virtual directory within the Web site. The virtual path does not include the name of the virtual directory.This parameter places the virtual directory in a subdirectory of the Web site. By default, the virtual directory is added to the root of the Web site. All directories in the virtual path must already exist on the Web site.
Name Required. Specifies a name for the virtual directory. You can select any name.
PhysicalPath Required. Specifies a physical directory for the virtual directory.You must specify a path on the local computer, such as C:\Project\HTML. If the specified path does not exist, then Iisvdir.vbs creates the path.
/sComputer Runs the script on the specified remote computer. Type the computer name or IP address without backslashes. By default, the script runs on the local computer.
/u [Domain\]User Runs the script with the permissions of the specified user account. This account must be a member of the Administrators group on the remote computer. By default, the script runs with the permissions of the current user of the local computer.
/pPassword Specifies the password of the user account specified in the /u parameter. If you omit this parameter, the script prompts you for the password and obscures the text you type.
/? Displays help at the command prompt.

Remarks
• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

• The WebSite (or WebSite/VirtualPath), Name, and PhysicalPath parameters must always appear in the specified order on the command line. Otherwise, Iisvdir.vbs does not interpret the information correctly.

• When you use Iisvdir.vbs to create a new virtual directory, you specify only the basic properties needed to create the site and identify its contents. Iisvdir.vbs uses the same default properties that IIS uses when establishing new virtual directories, and it adheres to the same rules for inheriting properties. To configure the more advanced properties of the site, use IIS Manager.

• Virtual directory names (Name) are not required to be unique. However, when a Web site includes a virtual directory and a physical directory with the same name, then the physical directory content cannot be viewed on the Internet.


Examples
The following examples show how to use iisvdir /create in specific situations.

Top of page
To create a virtual directory at the root of the Web site
The following command creates a virtual directory called Insurance at the root of the Finance Web site on the local computer. It associates the directory with content currently stored in the C:\Projects\Insurance\Html directory.

iisvdir /create Finance Insurance c:\projects\insurance\html

In response, Iisvdir.vbs displays the following message, which indicates that the command was successful, and it also displays the basic properties of the new virtual directory:

Connecting to server ...Done.
Virtual Path = Finance/Insurance
ROOT = c:\projects\insurance\html
Metabase Path = W3SVC/1509060625/ROOT/Insurance

The WebSite, Name, and PhysicalPath parameters must appear in the specified order in the command. The following command is the same as the previous command except that the parameters are out of order:

iisvdir /create c:\projects\insurance\html Finance Insurance

This command fails and, having misinterpreted the parameters, Iisvdir.vbs reports that it cannot find a Web site called "c:."

To create a virtual directory in a Web site path
The following command creates a virtual directory called Updates on the Finance Web site of a remote server, Svr01. It uses the /s command to identify the server computer, and the /u and /p commands to run Iisvdir.vbs with the permissions of the user's Administrator account.

The command creates the new virtual directory as a subdirectory of the Finance/Insurance directory. The command uses the metabase path of the Finance Web site, W3SVC/1509060625, to identify the Web site. It indicates the virtual path, Finance/Insurance, by appending it to the Web site name.

Finally, the command associates the Updates directory with content stored in C:\Newstuff\Web on the remote computer.

iisvdir /createW3SVC/1509060625/InsuranceUpdatesC:\Newstuff\Web/s svr01/u Admin01/p p@SSw#rD2

In response, Iisvdir.vbs displays the following message, which indicates that the command was successful, and it also displays the basic properties of the new virtual directory:

Connecting to server ... Done.
Virtual Path = Finance/Insurance/Updates
ROOT = C:\Newstuff\Web
Metabase Path = W3SVC/1509060625/ROOT/Insurance/Updates

In this example, the Finance Web site and its Insurance subdirectory existed on the Svr01 IIS server before the command was issued. If the Web site or the subdirectory did not exist, the command would have failed.

Also, the Insurance subdirectory is a virtual directory. You can use Iisvdir.vbs to create virtual paths within actual or virtual directories.

To create a virtual directory to hide a physical directory
This example uses an artifact of virtual directories to hide the contents of a physical directory so that it cannot be seen on the Internet or an intranet. The command creates a virtual directory with the same name as a physical directory in the same virtual path of a Web site. As a result, Web users cannot see the contents of the physical directory.

Although this method does not secure or protect the physical directory, it does provide a measure of privacy.

The following command creates a virtual directory named Personnel at the root of the Finance Web Site. The virtual directory is associated with a physical directory, D:\IIStest\Personnel, that contains public information about the Finance department team.

iisvdir /create Finance Personnel D:\IIStest\Personnel

In response, Iisvdir.vbs displays the following message, which indicates that the command was successful, and it also displays the basic properties of the new virtual directory:

Connecting to server ... Done.
Virtual Path = Finance/Personnel
ROOT = D:\IIStest\Personnel
Metabase Path = W3SVC/1509060625/ROOT/Personnel

As a result of this command, the site has a physical directory and a virtual directory named Personnel. Users who access the Finance Web site see the contents of the Personnel virtual directory. They do not see the contents of the Personnel physical directory.

iisvdir /delete
Deletes virtual directories from the Web sites on servers running Windows Server 2003 with Internet Information Services (IIS) 6.0.

Syntax
iisvdir[.vbs] /delete Website[/VirtualPath]/Name[/s Computer [/u [Domain\]User [/p Password]]]

Parameters
WebSite Required. Specifies the descriptive name or metabase path of the Web site.
VirtualPath Specifies the path to the virtual directory. This parameter is required when the virtual directory is not located at the root of the Web site.
Name Required. Specifies the name of the virtual directory.
/sComputer Runs the script on the specified remote computer. Type the computer name or IP address without backslashes. By default, the script runs on the local computer.
/u [Domain\]User Runs the script with the permissions of the specified user account. This account must be a member of the Administrators group on the remote computer. By default, the script runs with the permissions of the current user of the local computer.
/pPassword Specifies the password of the user account specified in the /u parameter. If you omit this parameter, the script prompts you for the password and obscures the text you type.
/? Displays help at the command prompt.

Remarks
• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

• Do not use Iisvdir.vbs to delete a Web site. If you do, the Web site is still listed, but it is partially removed and does not operate properly. To delete a Web site, or to correct the improper removal of an Web site by Iisvdir.vbs, use Iisweb.vbs: IIS Web site management script[/WindowsServer/en/Library/ba0e7001-3c41-40b9-b320-b6b6481c97251033.mspx].


Examples
The following examples show how to use iisvdir /delete in specific situations.

Top of page
To delete a virtual directory
The following command deletes the Insurance virtual directory from the Finance Web site on the local server. As a result, the Insurance directory and all actual and virtual subdirectories of the Insurance directory are deleted.

iisvdir /deleteFinance/Insurance

In response, Iisvdir.vbs displays the following message, indicating that the command was successful. Note that Iisvdir.vbs does not ask for confirmation before deleting the directory or its subdirectories.

Web directory Finance/ROOT/Insurance has been DELETED.

iisvdir /query
Displays the virtual directories of Web sites on servers running Windows Server 2003 with Internet Information Services (IIS) 6.0.

Syntax
iisvdir /queryWebSite[/VirtualPath] [/s Computer [/u [Domain\]User [/p Password]]]

Parameters
WebSite Required. Specifies the descriptive name or metabase path of the Web site.
VirtualPath Specifies the path to a directory within the Web site. The query lists all virtual directories under the specified directory. Without this parameter, Iisvdir.vbs lists the virtual directories at the root of the Web site.
/sComputer Runs the script on the specified remote computer. Type the computer name or IP address without backslashes. By default, the script runs on the local computer.
/u [Domain\]User Runs the script with the permissions of the specified user account. This account must be a member of the Administrators group on the remote computer. By default, the script runs with the permissions of the current user of the local computer.
/pPassword Specifies the password of the user account specified in the /u parameter. If you omit this parameter, the script prompts you for the password and obscures the text you type.
/? Displays help at the command prompt.

Remarks
• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

• The query operation displays only virtual directories. Physical directories in the Web site or path do not appear.

• The query operation displays only virtual directories at the root of the Web site or in the specified subdirectory. It does not search recursively.


Examples
The following examples show how to use iisvdir /query in specific situations.

Top of page
To display the virtual directories of a Web site
The following command displays the virtual directories at the root of the Finance Web site:

iisvdir /query Finance

In response, Iisvdir.vbs displays the two virtual directories at the root of Finance. Note that these directories appear at the Finance root even though their physical locations are unrelated.

This display does not include virtual directories that are subdirectories of the site. The procedure for finding subdirectories is demonstrated in the example below, "To display virtual subdirectories."

Alias Physical Root
========================
/Personnel D:\Corpdir\FinanceWeb\People
/Insurance C:\Marketing\Insurance\HTMFiles

To display virtual subdirectories
The following command displays the virtual directories that are subdirectories of the Insurance virtual directory on the Finance Web site. The command specifies the Insurance directory by using its virtual path.

iisvdir /query Finance\Insurance

This command reveals the Current subdirectory of the Insurance virtual directory.

Alias Physical Root
=======================
/Current C:\Insurance\Monthly\200204

Remarks
• Iisvdir.vbs performs the same operations that are available from IIS Manager. You can use either tool to view and manage virtual directories.

• The computer issuing the command must be running Windows XP or a Windows Server 2003 operating system. The user must be a member of the Administrators group on any computer that the command affects.

• The computer that the command affects must be a server running Windows Server 2003 with Internet Information Services (IIS) 6.0.

• Iisvdir.vbs displays a "Connecting to server" message while it connects to the IIS service on the specified computer. This message appears whenever you use Iisback.vbs, whether on a local or a remote computer.

• Use quotation marks to enclose path elements that include spaces. Enclose only the element with spaces, not the entire path. For example, type "Default Web Site"/IISAdmin, not "Default Web Site/IISAdmin".

Application Pools in IIS 7.0

IIS 7.0 Beta: Application Pools in IIS 7.0 (IIS 7.0 Beta 1)



Application pools separate applications by process boundaries to prevent an application from affecting another application on the server. In IIS 7.0, application pools continue to use IIS 6.0 worker process isolation mode. In addition, you can now specify a setting that determines how to process requests that involve managed resources: Integrated mode or ISAPI mode.

Note
In IIS 6.0, worker process isolation mode and IIS 5.0 isolation mode are set at the server level. This makes it impossible to run both isolation modes on the same server. However, in IIS 7.0, Integrated mode and ISAPI mode are set at the application pool level, which enables you to run applications simultaneously in application pools with different process modes on the same server.

Integrated application pool mode
When an application pool is in Integrated mode, you can take advantage of the integrated request-processing architecture of IIS and ASP.NET. When a worker process in an application pool receives a request, the request passes through an ordered list of events. Each event calls the necessary native and managed modules to process portions of the request and to generate the response.

There are several benefits to running application pools in Integrated mode. First the request-processing models of IIS and ASP.NET are integrated into a unified process model. This model eliminates steps that were previously duplicated in IIS and ASP.NET, such as authentication. Additionally, Integrated mode enables the availability of managed features to all content types.

Top of page
ISAPI application pool mode
When an application pool is in ISAPI mode, IIS 7.0 handles requests as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response.

This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Additionally, managed code features, such as forms authentication, are only available to ASP.NET applications or applications for which you have script mapped all requests to be handled by aspnet_isapi.dll.

Be sure to test your existing applications for compatibility in Integrated mode before upgrading a production environment to IIS 7.0 and assigning applications to application pools in Integrated mode. You should only add an application to an application pool in ISAPI mode if the application fails to work in Integrated mode. For example, your application might rely on an authentication token passed from IIS to the managed runtime, and, due to the new architecture in IIS 7.0, the process breaks your application