When not caused by a version conflict between IIS and IIS Management Tools, these symptoms are often caused by some corruptions in configuration files under %WinDir%\System32\Inetsrv\Config. What's in your administration.config and applicationHost.config? IIS Configuration Reference:
ApplicationHost.config - This configuration file stores the settings
for all your Web sites and applications.
Administration.config - This configuration file stores the settings
for IIS management. These settings include the list of management
modules that are installed for the IIS Manager tool, as well as
configuration settings for management modules.
Redirection.config - IIS 7 and later support the management of several
IIS servers from a single, centralized configuration file. This
configuration file contains the settings that indicate the location
where the centralized configuration files are stored.
Is your Windows Server 2016 installation a completely fresh installation or is it upgraded from a former version? It's unlikely that the configuration files would be corrupted after a clean install. Is it possible in any way that there was old versions from some previous IIS installation? Does the Date modified of these configuration files correspond your installation date?
As your installation is new, there shouldn't be anything you need to recover. After uninstalling IIS, you could check whether these files still exists and manually remove whole System32\Inetsrv\Config, if necessary. Then, reinstalling IIS should re-create the files with default settings.
You won't believe it, but the problem got solved in the meantime, I don't really understand, why the following change in RouterOS ensures that the ACK is not lost anymore, and the application gets loaded in a hurry, but I am really relieved about it: Inside the RouterOS Route lists, the Gateway IP was entered as an IP address instead of an interface name / DNS name.
Do you have any explanation for this issue? Does the translation/lookup take so many seconds, and the ACK is ignored in the meantime? I always had a feeling, that it has to be an issue in the RouterOS, but I had no idea how to track it down. What a lucky coincidence that our admin was playing with the router tables, and asked me to check the loadup time again. Can this really be the only change? I was able to confirm in wireshark, that the ACK is not lost any longer.
EDIT:
I exported the ip route settings below to see the differences in the route:
- Working: add distance=1 dst-address=33.2.1.0/24 gateway=33.2.4.1 pref-src=33.2.4.211
- Old state: add distance=1 dst-address=33.2.1.0/24 gateway=ETH2 pref-src=33.2.4.211
The gateway is not explicitly defined in the address list, only the router:
- Address: 33.2.4.211/24 | Network:33.2.4.0 | Interface: ETH2
So, what happens technically, and where does the delay and missing ACK come from?
Best Answer
%windir%\System32is a 64 bit system folder on Windows 64 bit (32 bit on Windows 32 bit), while%windir%\WOW64is the 32 bit system folder on Windows 64 bit. Memorize that if you haven't yet.On Windows 32 bit, IIS is purely 32 bit.
On Windows 64 bit, IIS contains both 64 bit and 32 bit components, so that it can run both 64 bit and 32 bit web apps.
Microsoft ships 32 bit and 64 bit MSI packages, which is for 32 bit and 64 bit Windows releases.
InetMgr6.exeis the legacy tool for only SMTP service. It has nothing to do with IIS any more so you can neglect it. It was there for compatibility purposes. If you do want to learn, Google "IIS SMTP". As it is a legacy tool, if it tells you something like IIS 7.5, don't believe in it either.Lastly, you are using Windows Server 2016, so you are using IIS 10, not IIS 7.5. Each IIS releases bind to a Windows release, and IIS 7.5 is only on Windows 7 and Windows Server 2008 R2.