This list is of course incomplete, but should help you to avoid common problems as well as a few of those that are uncommon but difficult to troubleshoot. In particular, this is designed to troubleshoot/avoid issues of the sort "it used to work on IIS 5 but fails on IIS 6"
1. Use the Log Parser Tool to scan your IIS 5 log files and identify all executables. These must be defined in Web Service Extensions or you have to disable Web Service Extensions by allowing all executables.
2. Use the Log Parser Tool to scan your IIS 5 log files and identify all extensions that in use. You will need to define MIME maps for those that are not defined in IIS 6 and it points the way to identifying script engines that need to be installed.
3. Reset Application Pool recycling to something other than every 29 hours, the absurd default. DO recycle, however, if you can.
4. Consider disabling automatic shutdown of Application Pools after 20 minutes of inactivity. You may not need too and it takes a while for the first request to launch when the pool doesn't exist.
5. Enable logging of Protocol Substatus in the IIS log Files (IIS W3C format).
6. Use Metabase Explorer or other means to set the LogEventOnRecycle Metabase property in the Application Pools key to 255. This will cause all recycle events to be recorded in the event logs.
7. Identify any IIS 5 filters that use Read_Raw_Data before you migrate. Here's the syntax to use MDUTIL to query the settings for the ISAPI filter sspiflit:
Mdutil get w3svc/filters/sspifilt/filterflags
If the result shows ReadRawData you have to run in IIS 5 mode or rewrite the filter.
8. If using custom identities for application pools, make SURE they are members of the IIS_WPG. Not optional.
9. For asp.net content, assign the IIS_WPG read permissions to web content unless running with unique identities for security isolation between websites. In that case, place the unique identity in the IIS_WPG but use the unique identity for ACLS, not the IIS_WPG. See http://www.microsoft.com/technet/prodtechnol/windowsserver2003
/technologies/webapp/iis/appisoa.mspx for details.
11. Identify HTTP.sys default values that may interfere with your application. There are limits on the url content, url segment length, client submission size, etc. Also HTTP.sys strictly enforces http 1.1 and 1.0 standards. If you have a monitoring system delivering sloppy requests to IIS 6, those may get rejected and there is no "AcceptSloppyHTTP" registry settings.
12. Determine if overlapping recycling causers problems for your applications. If so, disable it. See the IIS 6 Resource Kit for details.
13. Identify if your applications have any dependencies on the IIS 5 architecture such as running as the IWAM or System account.
14. Be aware that when creating new virtual directories on UNC paths, the default is to "pass through" the user's credentials. This will probably fail unless your using Basic or Kerberos with delegation enabled.
15. If your applications use Parent Paths (dotted notation), you will need to enabled that in IIS 6.
16. Determine if your applications are stable when you enable AspExecuteinMTA for multi-threaded ASP. Can get a good performance boost here as long as COM in your applications gets along in the MTA.
17. Identify an services using mapped drives on Windows 2000. You will likely need to find another way to do this on Windows 2003.
18. Consider enabling compression
19. Install CDONTS if you require it. Tip: Don't install SMTP just to deliver email from your application. Instead use one of the many SMTP objects you can invoke in your script. This way, you don't have 24/7 server online that you have to configure, administer, hotfix, secure, etc. The SMTP object delivers mail just fine and is non-existent when the page that creates it goes out of scope.
20. Identify ASP.net process elements that need to be configured in the IIS 6 user interface.
21. Be aware that you may need to increase the number of connections permitted to an application pool on a high volume server.
ليست هناك تعليقات:
إرسال تعليق