Note to self
The IIS 8 configuration file is located in %windir%\System32\inetsrv\config\applicationHost.config. It is just an XML file and the schema is well known. You can open it, edit it (if you are brave), and otherwise do configuration stuff with it. You can diff it from system to system to find inconsistencies or save it in a source code repository to standardize on a base configuration across web server nodes, if your project needs that kind of thing. Lastly, you can manage it with Powershell… you can manage it with Powershell… you can manage it with Powershell DSC!
The possibilities are endless so stop depending so much on the IIS Server Manager UI like you are in Dev preschool. You are a big boy now, remove the training wheels, but you might want to wear a helmet.
I don’t want to have this discussion again!
Here is another PowerShell command. This one is for installing IIS.
First I establish a session with the server I want to install to:
PS> enter-pssession -computername winbuildserver1
Next we just need to run a simple command:
winbuildserver1: PS> Install-WindowsFeature Web-Server -IncludeManagementTools -IncludeAllSubFeature -Source E:\sources\sxs
In the example I am installing the IIS web server, including the management tools and all sub-features, and I am installing from a specific source path, easy-peasy.
Of course you can achieve more fine grained control of the install and you can get more information on that at:
Today I received an error while trying to browse an ASP.NET website application locally, “HTTP Error 503. The service is unavailable.”
Fortunately, I found an excellent post on troubleshooting IIS issues, Troubleshooting IIS7 503 “Service unavailable” errors with startup debugging by Mike Volodarsky. I am just documenting some of the things that were a little different for me. I am running Windows 7 and IIS 7. I downloaded Windows Software Development Kit (SDK) for Windows 8 from http://msdn.microsoft.com/en-US/windows/hardware/hh852363 and only installed the debugger to the default location. This made the path to the debugger executable C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\ntsd.exe. I used regedit to add the w3wp.exe Registry Key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\w3wp.exe) with the Debugger string value of C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\ntsd.exe -server npipe:pipe=w3wp -g. I also added C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\windbg.exe to my Path to make it easy to start in command line.
Unfortunately, I didn’t need to go through all of that. I never got the debugger to attach because the Worker Process wouldn’t start. After some experimenting I decided to change the Application Pool for my web application and the app came up. I looked at the old Application Pool and noticed something that didn’t hit me before. I spent 2 hours researching and poking around and my real error in this instance was the Application Pool I created for my web application was assigned to my local Windows account. When I was forced to update my password the password did not update on the Application Pool. So, updating the password fixed my issue. I have since created a new Windows account specifically for this web app that doesn’t have a password that expires.
Anyway, it was a nice exercise getting windbg up and running. Maybe I will really need it one day.
*Safety Note: Use the Windows Debugger Install instructions above at your own risk. It may affect your Visual Studio Debugger.