Most operations on Metabase keys and properties work seamlessly and the user is presented with these legacy concepts and names and not the new IIS concepts like configuration sections and named properties (ABO continues to work with property IDs ADSI continues to work with the legacy property names). The configuration settings for those can still be managed via legacy programmatic interfaces and direct editing of the metabase.xml file. Note that FTP, SMTP and NNTP configuration is still persisted in the Metabase system and was not ported over to the new IIS configuration systems. Obviously, this is very different from the recommended way to extend the IIS configuration system, hence another reason to consider porting such applications, over time, to use new interfaces and new features offered by the IIS 7.0 and above configuration system. They can be retrieved via the legacy interface just like in IIS 6.0, so the system is fully compatible. From the legacy script perspective, the system is fully compatible here with IIS 6.0.Ĭustom web server properties that are set via legacy scripts and applications are always persisted into the section. If such a subsequent call is not made, then the server runtime will never see this invalid site, but legacy scripts will have it in the ABO view, just like they did in IIS 6.0. Temporary data will be removed from at that point, so the user will not need to cleanup leftovers from the system. If a subsequent call is made to set the site bindings, then the site object is considered complete, and persisted in its entirety to the section, where it will be picked up by the server runtime. In IIS 7.0 and above, it is kept in the section, which is not consumed by the server. In IIS 6.0, such a call would have created an invalid site object in configuration. An example of incomplete data is when the legacy script set the site id but not the site bindings. This section is used as a persistent store for the Metabase Compatibility feature, and customers should never modify its content. Incomplete data that is not ready for consumption by the server runtime is persisted into a special section in nfig, called customMetadata. This is referred to as "read-through", because the information is again not fetched from memory. When calling ABO to read web server configuration, the Metabase Compatibility component will read it from nfig. This is referred to as "write-through", because the information is not kept in-memory. When calling ABO to write web server configuration, the Metabase Compatibility component will persist the data in nfig. The legacy system handles applications differently: they are simply virtual directories with a special property to mark them as applications (AppIsolated, or AppRoot). For example, the new system has a concept of applications, under each site and above all virtual directories. Mapping is done to translate back and forth between the ABO view back and the new system view. Web server configuration is typically under LM/W3SVC, including custom properties, with some few additions like Mime Maps. The mapping decision is based on the Metabase node in question. Note that even custom properties that are under the web server configuration are mapped to (and persisted in) the new system. If it is related to FTP, or SMTP, or NNTP configuration, then it follows the regular logic of the Metabase system and ends up in the Metabase file. If the information in the method call is related to the web server configuration, it is mapped to the new system. The Metabase Compatibility feature runs inside the Metabase service (IISADMIN). When all of the legacy scripts and applications are ported to the new interfaces, it is recommended to uninstall the Metabase Compatibility feature. It is also recommended that new scripts and applications be developed using the new interfaces, so they work ideally with the new system, and can have access to the new properties, concepts and structure of the configuration system. more and more web.config files with IIS settings in them are present on the system), customers will consider porting legacy scripts and applications over to the new system and its interfaces. The legacy interfaces have some limitations and are not ideal for working with distributed configuration files (see Limitations section below) therefore it is recommended that over time, and especially when opening up the configuration system for more and more delegation (i.e. This component is not installed by default because IIS is not initially set up to use it. You can find this component in setup under Internet Information Services->Web Management Tools -> IIS 6.0 Management Capability Feature. Installing Metabase Compatibility Support By default, this component is not installed.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |