General IIS 7.0 Questions

This must be done manually.

The impact will depend on the server load. If you are doing 10,000 requests/second, you will sorely miss kernel caching; however, if you are doing 100 requests/second you probably will not notice. It depends heavily on the content being served, IIS 5.0 did not have a kernel mode component and it worked well for most customers.

There is basic ruby support. See following link for more information:

http://mvolo.com/10-steps-to-get-ruby-on-rails-running-on-windows-with-iis-fastcgi/

If you are installing via the Server Manager GUI ("Add Features"), order of installation does not matter. The Add Features wizard checks all dependencies and will alert you if you are missing any required modules. In addition, Add Features wizard knows the correct ordering of modules.

If you are installing from a command line or using an unattended installation, the order of modules doesn't matter (again, Setup knows the correct ordering of modules), but you are responsible for identifying all dependencies. If you fail to include a required dependency, unattended/ command-line setup will fail.

An Application Pool that only serves static files with all features installed will have a footprint of 3 MB private bytes, 5 MB page file. (This is larger than IIS 6.0). Windows Server 2008 handles multiple application pools better than WS03. When ASP.NET requests are made we pre-load a small amount of the CLR during startup (~100kb) . The preload is configurable by a property on the ApplicationPool. It is called managedRuntimeVersion. The rest of the CLR (~8mb) will be loaded on the first ASPX request.

Access only works in 32-Bit application pools. Loading the user profile (loadUserProfile property on the AppPool) is an issue when Classic ASP is used because Access is using the temp directory which doesn't allow access to the anonymous user when the user profile is loaded.

Windows Server 2008 web edition is much improved, and we have focused hard on removing the artificial limits. The final licensing is not yet complete, but we are planning to remove all hardware restrictions, allow 4x processors and 32GB RAM (on x64). SQL is allowed, and SharePoint will be installable on the SKU.

FPSE is no longer a part of Windows Server. We are working with a third party to create a download package for FPSE to run on Windows Server 2008/IIS 7.0. It does not have any new features or enhancements, only fixes to make it compatible.

We recommend that Windows Server 2008 be installed fresh and migrated to; or, just put new customers on new servers. We suggest that a well managed list of third party components and configurations is documented for each server, so that the current environment can be replicated on the new server. See the recommendations in the shared hosting paper for site and application pool configuration. A tool to assist in the migration will be released in the near future.

In-place upgrades are supported for the following scenarios:

• Windows Server 2003 can be upgraded to WS2K8 Beta3, WS2K8 RC0, WS2K8 RC1, and WS2K8 RT
• Windows Server 2008 Beta3 can be upgraded to WS2K8 Beta3, and WS2K8 RC0
• Windows Server 2008 RC0 can be upgraded to WS2K8 RC0, WS2K8 RC1, and WS2K8 RTM
• Windows Server 2008 RC1 can be upgraded to WS2K8 RC1, and WS2K8 RTM

If the server is in Shared Configuration mode, it must be reverted to standalone configuration before the upgrade is run. To do so, disable shared config, copy down the applicationhost.config and encrypted keys to the local machine, run the upgrade on each server, then re-enable shared config.

Both the log files that setup is writing and the iis7.log are always on. It is not granular about what gets logged.

We do not provide any way to configure modules other than Windows modules during setup. There may be a way through generic unattend setup to run something after setup is done, and in that a user could do some coding.

Tracing ALL requests at <1000 requests/second should be <5% CPU. It is possible to configure a global tracing rule for all sites. Tracing can be enabled for all sites by changing the <siteDefaults> section.

No, but there is memory-based recycling, which will recycle AppPools that exceed configured memory limits.

Encryptions made before sysprep are lost after sysprep. There is no workaround.

You can export the machine keys and import them into all the servers so that decryption works. The UI for Server Beta 3 includes a feature called Shared Configuration which will allow you to do that. Click Export... and it will encrypt the machine keys, copy them along with applicationHost.config and administration.config to a path. After that, from all the other machines you can select "Import..." and it will import the machine keys and point the config to the shared configuration.

Different AppPools can have different values for this setting. Applications can be assigned to different AppPools

The default file for handling this error is contained in \inetpub\custerr\en-us. The footer of the error contains "Server Version Information: Internet Information Services 7.0.", which of course can be removed or edited directly from the .htm file.

The managed API (Microsoft.Web.Administration) has access to all of the settings that the native API does and has DCOM remoting support by using ServerManager.OpenRemote static method. You can set any configuration settings but for Beta 3 there is no support for runtime information such as the State of an AppPool or the list of requests or workerprocess.

In previous IIS versions you had to control access via file system ACLs. This is tedious and there is no web interface to do it. With URL authorization, you can control access to URLs using the IIS User Interface or using web.config directly. Additionally, you can use non-windows identities, e.g. Membership users and roles provided by forms authentication.

Any data in the applicationPool section relevant to that app-pool (so either in applicationPoolDefaults or specific to that app-pool) will cause WAS to recycle the app-pool. Worker process can ask WAS to recycle app-pools based on certain config changes, currently the only one we do it for is globalModules, but this is not a closed list (as modules can ask for recycle based on config change).

NLB is part of Windows Server 2008. It is essentially the same as it was in Windows 2003. To install NLB, go to Server Manager > Features > "Add Features" and select "Network Load Balancing" from the list. To configure NLB, you need to open a command prompt and run nlbmgr. This is the UI that existed in Windows 2003.

If the system-wide CPU exceeds a threshold dynamic, compression will stop occurring, freeing up the CPU it was using. If the system-wide CPU drops below a different limit, dynamic compression will resume, saving bandwidth.

Different users have different opinions on optimal CPU utilization. Some think a 20% average is perfect, others think 75%. If you want X and you're consistently above X, you might as well completely remove dynamic compression, as it is never going to be used.

It factors in average usage over the 30 second window since the last sample - so, even with irregular spikes, you will have dynamic compression on for at most 30 seconds after the spike - and if your spikes are instantaneous (and so do not affect average CPU usage over 30 seconds much) - they will not affect dynamic compression.

Setting loadUserProfile=false in applicationPoolDefaults is a good idea for Shared Hosting scenarios. The startup time of an AppPool will be much faster and you avoid any temporary directory permission issues.

The 500.19 error is caused by the IIS 7.0 feature delegation mode. When a feature is delegated to site owners, and the site owners modify the feature, then their changes are persisted in web.config. If the server administration revokes the delegated management on that feature, then the web site owner has the responsibility of cleaning up the feature details from web.config. Otherwise, all sites that had modified that delegated feature will immediately give an "Http Error: 500.19 - Internal Server Error" message. In order to avoid this issue, we recommend that hosters do not revoke delegated features once they are published to end customers.

If the hosted site does not have a web.config, IIS 7.0 will create one. If the site has a web.config, IIS 7.0 modifies it. If the web.config is modified, then the site owners have the responsibility of merging the changes and ensuring that the changes are manually merged and maintained.

Installing Management Service does not modify AppHost.config or Administration.config at all. The only changes you should see are the new binaries (wmsvc.exe). A self-sign certificate will be created and a few registry keys will be added. This means that in theory nothing should break.

For the most part, it works out of the box since we use the redirection.config settings for reading apphost/admon.config. However, for a detailed answer, it really depends on what scenarios you will be using:

• Shared Config using Local Content: Regular Windows or IIS users connecting to modify their local content and their web.config's - there is nothing to do, everything should work out of the box.
• Shared Config using Remote Content using Windows Users: It should work, provided the Windows accounts have access to their content.
• Shared Config using Remote Content using IIS Users: For this scenario you must change the Identity of the service (WMSVC) to an account that has access to the remote content, since we use the process identity for accessing content. Note that apphost.config/admon.config will work, since we use redirection.config
• Windows Administrator managing a Server Connection: It should work, provided your Windows administrator has write access to the shared config.

See the following link for information about creating sites in IIS 7.0.

An Application Pool that only serves static files with all features installed occupies 3 MB private bytes, 5 MB page file. When ASP.NET requests are made we pre-load a small amount of the CLR during startup (~100kb) . The preload is configurable by a property on the ApplicationPool. It is called managedRuntimeVersion. The rest of the CLR (~8mb) will be loaded on the first ASPX request.

Http.sys creates these folders automatically if they do not exist. If you override the permissions with something else, it should preserve the new permissions.

We have tested it internally and it seems to work well if ISAPI and Metabase are installed. There are some blogs online as well that give instructions on how to make it work. For more information see the following link:

https://blogs.iis.net/bills/archive/2007/03/06/coldfusion-on-iis7.aspx.

The server is setup in AD Account Creation mode. AD Creation Mode is a deprecated feature that is still supported, but will be removed in V4. Instead of allowing WSS to automatically create users in AD, the recommendation is to do user provisioning outside of WSS.

More information on Centralized Global Configuration can be found at: The Configuration System in IIS 7.0

There are currently no FPSE for x64. Our shared hosting recommended architecture is 64bit OS with 32bit AppPools. Unfortunately there is currently a bug that prevents FPSE from installing on 64bit for this scenario.

You may re-arm your system three times by completing the following steps:

In order to run slmgr /rearm, open regedit.exe and navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL. Verify that value "skiprearm" is set to ‘0'. If this value is non-zero, the re-arm function will not reset the system activation timers.

After verifying that the "skiprearm" registry value equals zero (0), run slmgr /rearm from an elevated command prompt. Wait for the notice that the process has completed. This can take a minute or two. Once complete, follow the prompt to shutdown the computer. Upon restart, the computer will be running in OOB Grace and will have another 30 days in which to activate. No other changes will be made to the system by this process.

IIS.CertObj COM-object is still there in IIS 7.0 and we think it is still the best option for deploying certificates on multiple web servers. This component behavior remains the same, so all old script should work (if ABOMapper is enabled).

set iiscertobj = CreateObject("IIS.CertObj")

iiscertobj.InstanceName = "0.0.0.0:443"

iiscertobj.Import pfxfile, pfxfilepassword, true, true

And such a script won't be depending on ABOMapper.