Those of you, who support IIS6, it might be obvious to notice the following line at the start of IIS6 log file:
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2009-01-30 02:05:59
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
It appeared to me that (because so far I never read exact configuration!!) when you perform following actions, HTTP.SYS will insert the extra header in log file:
1) Restart the Web Site
2) Restart the IIS Server.
3) When new log files get created.
4) Logging Configuration Changes
While troubleshooting IIS problem, I generally try to relate server event with one of those above but I caught multiple times when I could not. In addition to above list, HTTP.SYS has an idle time out for log file. To Preserve System Resources especially for server hosting large number of sites, HTTP.SYS will close the file handle after 15 minute of inactivity! So if you receive request at every 16th minute, you may notice that above header multiple times.
On a side note, IIS 6 logging is not synchronous hence you may need to wait for sometime before entries get flushed to disk and it is frustrating! I believed that restarting website or IIS server will force logbuffer to flush the entries but more often than not, it is not possible in live environment just to flush logbuffer. I also believed that changing Logging configuration forces IIS to write the log to disk but that is not the case either.
However in IIS7, we have a new option. Try following command by yourself to see the result, if you haven’t:
netsh http flush logbuffer
Hi,
I am playing with MSDeploy quite a lot these days and it is great. I just want to share information about how we can use it to install assembly in GAC.
I wrote a strongly typed assembly for a test and installed it on my Windows 7 laptop. Here is an information about that assembly:
Here is syntax to synchronize assembly from my machine to other machine:
msdeploy -verb:sync -source:gacAssembly="' AssemblyUday, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c7ae5fd536683962'" -dest:gacAssembly,computername=ARRMSD,username=administrator@contoso.com,password=Pa$$w0rd
Alternatively, if you do not want to synchronize between machines, you can archive the package and move the package files to production server and synchronize production machine with archivedir.
msdeploy -verb:sync -source:gacAssembly="' AssemblyUday, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c7ae5fd536683962'" -dest:archiveDir=c:\ToGoForProduction
Isn’t it great? I think it is awesome rather using GACUTIL.EXE or MSI installer.
Hi Friends!
Scenario:
Yesterday I was asked to help out IIS 6 to IIS 7 migration with close to 500 sites with 50 of them were SSL website. I thought it is good time to evaluate MSDeploy. It has a support to migrate SSL certificate between the servers and it has really appealed me to use that tool. I opened built in help and I found the following syntax:
msdeploy.exe -verb:sync -source:cert=(STORENAME\HASHOfCERTIFICATE) -dest:cert=(STORENAME\HASHOfCERTIFICATE),computername=DESTINATIONCOMPUTER
I thought that it is something to easy to do. In order to find the SSL certificate association with IIS, I used the following command:
HTTPCfg query ssl
And I saw the following o/p:
So I thought I got the HASH required and tried the following command to archive the SSL certificate to folder store:
msdeploy.exe -verb:sync -source:cert=MY\db1209c20e1be61a4d86644067604118ee7dfa -dest:archiveDir=c:\CertArchive
As you expected, (and reason behind this post) it failed. Have a look at following screenshot:
It failed the first time because I copied the HASH directly from the HTTPCFG output. It failed due to space in a hash. I removed the spaces and tried second time and it failed too very strange error. “Certificate not found in store”. I checked and double checked that certificate does exist, certificate is marked with private key exportable and IIS website with SSL certificate is working over SSL connection. Out of clue and permutations and combinations!!
Takeaway:
I forwarded the problem to internal discussion group and within minutes I got reply from Andreas Klein and that was amazing.
I executed the following command:
Do you notice the random spaces in Hash? They are actually not space. They are ‘0’ that human eye cannot see!!!!!!!!
E.g. A certificate Hash reported by HTTPCFG as “db12 09c20e1 be61a4d86644067604118ee7dfa” should actually be “db12009c20e10be61a4d86644067604118ee7dfa”. Instead of 0, HTTPCFG report it as ‘ ‘.
There is a problem in a way that HTTPCFG reports the certificate hash. I hope it will save some of your time while doing Migration with MSDeploy.
Hi Friends!!!
I am back in business and apologies for out of contact for a while. Lot of exciting thing happened over past few months. Finally I landed where I always wanted to be so thanks for your support so far and yes your guess is right from the blog addressJ.
I was waiting to right my first post with some exciting information. Exciting means hidden to the world and internet search engines could not find! In my usual style here it goes:
Scenario:
I was at customer site and my task was to monitor the IIS System health and that obliviously means monitoring the application health. I decided to setup performance counter for a start and I opened the Process counter as shown in following figure:
So server was hosting multiple web application and sever had multiple worker processes. In the Instance list all worker process was appearing as w3wp, w3wp#1, w3wp#2 and w3wp#n and so on. Problem was which one is associated with correct application pool?
Resolution:
I executed the following command to get a list of worker processes running on the server and associated process ID.
C:\windows\system32\cscript c:\windows\system32\iisapp.vbs
Output was something like below:
Then I remembered the one blog post from very dear friend of mine:
http://blogs.technet.com/marcelofartura/archive/2006/09/14/perfmon-s-counters-output-format-tip.aspx
I applied the registry changes as said and voila!!! I got the output as below:
Job done! Hum... I am sure you are wondering what is the point of having this blog entry? Such a waste of time isn’t it? If you are thinking this than wait...
I opened .Net CLR Counters and specifically .Net CLR Exceptions and .Net CLR Memory and I saw the following:
Hum!! Something didn’t work as expected. I verified the registry entries and appeared correct to me. I came to conclusion that this registry modifications are not working for .NET CLR counters. Question was how to monitor .Net CLR counters for specific application pool only?
I decided that it is time to call the internal help line and guess what within hours I got reply and reply was amazing that I decided to write this blog.
Guy told me to look for under “.Net CLR Memory” Performance object and asked me “what is the 4th last counter you see?” I was amazed what it has to do with 4th last counter? I looked the counter and it was full of surprise!!! It seemed that “Promoted Finalization Memory from Gen1" is the holly grail!!!! The last value of that counter was actually the worker process ID!! Now you got the relationship between .Net CLR performance counters and Worker process ID as well.
Takeaway:
When you have .Net 1.1 installed it loads the .Net 1.1 performance counters and there is no easy way to get this relationship established. However, in .Net 2.0 onwards you can unload the .Net 1.1 counters and reload the .Net 2.0 specific counters with following instructions:
1) Go to \Windows\Microsoft.NET\Framework\v2.0.50727
2) Run “unlodctr .NetFramework”
3) Run “lodctr corperfmonsymbols.ini”
This should load the .Net 2.0 counters from corperfmonsymbols.ini. So what is the difference? Well, see the screenshot below:
Now you have the real name of performance counter as well along with real value. Demystifying the secret! Though you have counter listed, it will not work with .Net 1.1.
Well this solution provided as it is and you are at your own risk! Please don’t take it as an official supported way to implement and it is kind of working solution. We should expect a lot of improvement on this side with .Net 4.0 so wait and watch!
PS: Special Thanks to Mr. A. Kamath who assisted me with this problem.
