Я не могу комментировать тему из-за отсутствия репутации. Другой комментатор заявил, что они не могут перейти с более ранней версии IIS на более высокую. Это верно, если вы не объединяете некоторые файлы, но если вы это сделаете, вы можете, поскольку я только что перенес свой сайт IIS 7.5 в IIS 8.0, используя ответ, опубликованный chews.
Когда экспорт создан (II7.5), есть два ключевых файла (administrator.config и applicationHost.config), которые имеют ссылки на ресурсы на сервере IIS7.5. Например, DLL будет ссылаться на открытый ключ и версию, специфичную для 7.5. Это НЕ то же самое на сервере IIS8. Конфигурация функций также может отличаться (я убедился, что мои были идентичны). В версии 8 есть несколько новых функций, которых никогда не будет в версии 7.5.
Если у вас хватит смелости объединить два файла - это сработает. Один раз мне пришлось удалить IIS, потому что я все испортил, но получил второй раз.
Я использовал инструмент слияния (Beyond Compare), и без чего-то эквивалентного это был бы огромный PITA, но это было довольно легко с хорошим инструментом сравнения (пять минут).
Чтобы выполнить слияние, файлы 8.0 необходимо сравнить с экспортированными файлами 7.5 ПЕРЕД попыткой импорта. По большей части файлы 8.0 должны перезаписывать специфический для сервера материал в экспортированных файлах 7.5, оставляя при этом специфический для сайта / пула приложений материал.
Я обнаружил, что administrator.config почти идентичен, без информации о версии многих записей. Это было легко.
ApplicationHost.config имеет намного больше различий. Некоторые записи упорядочены по-разному, но в остальном идентичны, поэтому вам нужно будет просмотреть каждое отличие и выяснить это.
Я поместил свои экспортные файлы 7.5 в папку System32 \ inetsrv \ config \ Export перед объединением.
Я объединил ИЗ папки System32 \ inetsrv \ config в папку System32 \ inetsrv \ config \ Export для обоих файлов, упомянутых выше. Я протолкнул все в файлах FROM, кроме тегов / элементов, специфичных для сайта (например, applicationPools, customMetadata, sites, authentication). Особо следует отметить, что было также много блоков тегов "местоположения", специфичных для сайта, которые мне пришлось сохранить, но у нового сервера был свой собственный блок тегов "местоположения" с определенными для сервера значениями по умолчанию, которые необходимо сохранить.
Наконец, обратите внимание, что если вы используете учетные записи служб, эти кешированные пароли являются ненужными, и их придется повторно вводить для ваших пулов приложений. Изначально ни один из моих сайтов не работал, но все, что требовалось, - это повторно ввести пароли для всех моих пулов приложений, и я начал работать.
Если кто-то, кто может прокомментировать, упомянет этот пост в ветке - это, вероятно, поможет кому-то вроде меня, у которого много сайтов на одном сервере со сложными конфигурациями.
С Уважением,
Стюарт