I'm using IIS 5.0 and occasionally want to stop the server immediately. The Iisreset command has a Timeout argument that should shut down IIS right away if I set the timeout to 0. However, when I set the timeout to 0, a permissions error occurs. Why am I receiving this error?
Iisreset.exe is one of the big improvements in IIS 5.0 over IIS 4.0. Stopping and starting IIS 4.0 servers can be problematic. If you're lucky, all the services initialize correctly and in sequence. All too often, however, you must use the kill.exe command in the Microsoft Windows NT Server 4.0 Resource Kit to shut down and reboot a hung IIS 4.0 server.
Iisreset.exe is an IIS 5.0 utility that lets you stop, start, reboot, query, and otherwise manage the Internet Services utilities. In IIS 5.0, you don't stop and start a Web server through Control Panel--you use Iisreset. In fact, Microsoft specifically advises against using Control Panel to manage the Internet Services.
When you issue the Iisreset command alone (i.e., without arguments or optional command-line switches), it stops and restarts the Internet Services. If an error occurs and IIS doesn't respond to the command, you can use other switches to force the server to reboot. For example, the command
"C:\>iisreset /RESTART /REBOOTONERROR /TIMEOUT:100"
causes IIS to stop and start; if the server doesn't respond within 100 seconds, the command reboots the server. You can use the Reboot switch to reboot the server:
C:\>iisreset /REBOOT
This command invokes a countdown window advising you that you have 20 seconds to save everything. If you want to reboot immediately, use the command
C:\>iisreset /REBOOT /TIMEOUT:0
The effect of this command is the same as using kill.exe. The command requires not only Administrative privileges but the Advanced Debug user right on the local IIS server. Administrators have this right by default, so make sure local or group policy, a template, or other action hasn't removed this right.
You can find the complete list of Iisreset switches in the IIS 5.0 online documentation. This list is also available when you type
iisreset /?
at a command prompt.
I'm running IIS 4.0 with Service Pack 6a (SP6a) on a member server that is part of a domain. When I attempt to log on to my FTP server, it will authenticate only against the member server's local user database. How can I use the accounts on my domain controller to log on to the FTP server?
By default, Microsoft's FTP server authenticates to the local user database. You can specify a domain logon by entering your domain and username in the FTP client. The FTP server will then authenticate to a domain controller.
You can also log on to an FTP server from Microsoft Internet Explorer (IE) directly without the use of specialized FTP software. Simply use the URL form ftp://username@password:servername. In your case, the URL would be ftp://domain\username@password:servername.
Although being able to specify the domain against which you want to authenticate is useful, it's also a hassle to tell all your users that such a specification is necessary. Undoubtedly, you'll receive a lot of Help desk calls, despite clear instructions to your users. Fortunately, you can use an Adsutil command to modify the metabase to force FTP to log on to a specified domain controller. To set the DefaultLogonDomain for all FTP sites, use the syntax
adsutil set msftpsvc/Default LogonDomain "DomainName"
To set the DefaultLogonDomain for the default FTP site only, use the syntax
adsutil set msftpsvc/1/Default LogonDomain "DomainName"
To set the DefaultLogonDomain for any other FTP site, use the same command as for the default FTP site, but change the 1 to the appropriate number. To find the number of an FTP site, use MetaEdit to browse the FTP sites for the correct name.
Adsutil.vbs usually resides in the \systemroot\system32\inetsrv\adminsamples folder. (The utility can be in another location if you specify a location other than the default folder during IIS installation.) To use adsutil.vbs, you first need to install Windows Script Host (WSH).
My system has a new Windows 2000 server with SP1 and IIS 5.0 installed. I would like users to be able to send email messages to my domain (e.g., [email protected]), but I don't want the expense (and hassles) of Microsoft Exchange Server. How can I use SMTP to forward email messages that come in to the domain and redirect them to my "regular" account (e.g., [email protected])?
The short answer is that SMTP doesn't have this ability. The SMTP service will happily deliver mail to [email protected], if that is the message destination. The service won't, however, readdress mail from one user to another. You're most likely thinking of SMTP's ability to use a smart host. When you specify a smart host for SMTP, SMTP forwards all nonlocal mail to the designated host, the notion being that the smart host has better Internet or intranet connections, hosts the corporate mail server, or has some other reason to be the nexus for mail.
An excellent online document (http://www.microsoft.com/technet/iis/mail.asp) explains how to set up the SMTP server. This document is the SMTP chapter from Leonid Braginski and Matthew Powell, Running Microsoft Internet Information Server (Microsoft Press, 1998). In my opinion, this book is essential for any IIS administrator.
I installed IIS 4.0 without the SMTP service. I now need to send email from the IIS server, and the SMTP service is perfect for what I need. However, after I installed the SMTP service, it won't start. When I try to start the service from Control Panel, error 0002 The specified file not found appears. Also, event ID 7000 Source: Service Control manager. "Microsoft SMTP service. Service failed to start due to the following error: the system cannot find the file specified" appears in the event viewer. How can I get SMTP to run?
This error occurs when you do two things: first, install IIS without SMTP to a path other than the default folder C:\winnt\system32\inetsrv; and second, add SMTP after you've already installed IIS. The SMTP service installation process doesn't check to see where you've installed IIS; it simply loads itself into the C:\winnt\system32\inetsrv folder. Consequently, when you start the service, the SMTP files aren't where they're supposed to be. The Microsoft article "Added SMTP Service Fails After IIS 4.0 Is Installed on Non-Default Path" (http://support.microsoft.com/support/ kb/articles/q245/2/08.asp) tells you which files to move and includes a registry edit that will get you running. I must also mention that after you install SMTP or any network service on a running NT server, you must reapply the service pack you're using. Failure to do so will result in an unstable installation.
I want to place my log files on a server other than the IIS server. To accomplish this task, I created a shared folder on server B, mapped it to IIS server A, then told IIS to log the files on that share. When I completed this process, event error 3 Cannot create directory on w3svcXX, the data is the error occurred. The shared directory has Everyone, Full Control permissions. Why am I receiving this error message?
IIS stores log information in memory in a batch until the log buffer is full. By default, this buffer is 64KB. Note that you can change the size of this buffer by making this registry change (be sure to back up the Registry before making any changes):
LogFileBatchSize : REG_DWORD Range: 0 - 0xFFFFFFFF Default: 64*1024 (64KB)
When the log buffer is full and IIS writes the logs to disk, IIS does so by using the authority of the System account. The System account doesn't have access to the network because the account isn't a user with authenticated credentials. The reasoning behind this security is sound, although it can result in some odd permission scenarios, such as the one you're talking about. The System account has virtually unlimited permissions on the server, but it doesn't have the traditional username and password. This distinction is a required characteristic because during server startup, no one is logged on, yet you must start services for the server to operate. Consequently, services running under the System (sometimes called the Local System) account typically can't access network shares because the network requires a username and password to connect to network resources. IIS (as inetinfo.dll) is one service that runs under the authority of the System account. As a result, when IIS writes its logs, it can't write to shares on remote servers.
The UI accepts a Uniform Naming Convention (UNC) pathname for the logs. However, Microsoft expressly doesn't support using UNC pathnames or mapped network drives with log files.
I have a machine running Win2K Server and IIS 5.0. This machine has one NIC with two IP addresses. When I set up IIS to use port 80 on one of the addresses, IIS captures the other port as well. Aside from IIS, I have another application that needs to use port 80 on the second IP address. With IIS 4.0 on NT 4.0, everything worked fine. Why is IIS 5.0 behaving this way?
In IIS 4.0, when you create a Web site, TCP sockets are allocated specifically for that Web site. This allocation affects scalability and performance because sockets that sit idle are unavailable for other sites' use. In contrast, IIS 5.0 uses a technique called socket pooling, which IIS enables by default for all sites that use the same port but have different IP addresses. Regardless of the number of Web sites using port 80, the sites all share the same set of TCP sockets, which is an improvement over IIS 4.0 because this method distributes server resources better. Adding a large number of Web sites that are all listening to port 80 doesn't significantly increase nonpaged memory.
Because all the sites are sharing the same set of sockets, adjustments you make on the Performance tab of a Web site's Properties dialog box affect not only the Web site you're tuning but all Web sites that use the same port. Put another way, by default, if you make a performance-tuning adjustment to any Web site in IIS 5.0, that change affects all Web sites that use that port.
In addition—and this directly addresses the question—IIS listens to port 80 on all IP addresses, not just on the assigned addresses. The good news is that you can disable socket pooling for an individual site or for the entire server, which effectively returns the system's behavior to IIS 4.0 style (i.e., dedicated socket behavior). To make this change, type
C:\inetpub\adminscripts\cscript adsutil.vbs set w3svc/ disablesocketpooling true
at a command prompt, then stop and restart your server. This command turns off socket pooling for the entire server. For an individual Web site, the command is the same except that
w3svc/disablesocketpooling true
becomes
w3svc/X/disablesocketpooling true
where X is the number of the Web site. (For an explanation of Web site numbering, see the sidebar "Distinguishing Web Sites in IIS.")
