There are some exciting events coming up around the Charlotte area which I'll be speaking at. Next weekend is the Charlotte Code Camp Spring 2008. I'll be speaking on what is currently fresh on my mind, and what I believe is very applicable to developers today. The session is titled "What every developer needs to know about IIS 7".
Here's the Code Camp agenda: http://www.developersguild.org/Default.aspx?tabid=248 For anyone in the area, I encourage you to register before it fills.
IIS 7 has many new changes that affect the developer this time around. With IIS 6, mostly just the server administrator benefited. But, with IIS 7, there are many changes that apply to the developer. There are deployment changes, web.config configuration changes, the new system.webServer which applies to all types of files, distributed configuration, better debugging and troubleshooting tools, new remote management tools and those are just the most obvious. The list goes on when you talk about the modular framework, extensibility, shared configuration for webfarms, security and FTP changes just to name a few. I'll be speaking this very topic.
The other event in this area is July 8th in Ashville. There is a new user group starting up next week, May 13th. (http://wncdotnet.com/) Brian Hitney will be presenting on "Building Next Generation Web Applications with VS2008" for the opening night. Dave Kolb asked if I would speak at one of the following events. I can't in June because I'll be at TechEd 2008, but I will for July 8th. Ashville is a beautiful area about 2 hours North of where I live so I'll take my wife and kids and stay the night. We're all looking forward to the trip. I'll be covering a similar session as I will at Code Camp.
Searching for file content on your computer or server is a common task and one where you would expect accurate results. You, like so many of us, may have assumed that but found different results.
Within Windows 2000 Server, if you entered something in the windows search dialog and clicked "Find", it would find it. But, with Windows Server 2003 or Windows XP, there are a lot of searches that would come up empty, even if you were sure that you had files with the words in them that you were searching for.
The reason that the results are different in Windows Server 2003 and Windows XP is because Microsoft decided to only include certain types of files in the search to speed up the search. Even if you set the file type as "All Files and Folders", it ignores a large amount of files when doing a search. The reasoning is that it takes a long time to search every file on the server and binary type files like a jpg or gif or exe don't need to be searched for a plain text search term. Why include them if they aren’t going to turn up any results anyway.
While I agree with it in part, if I want to find a file based on a keyword, I want it to search every file so that I can be sure that my search is accurate.
The fix is fairly easy as long as you don't mind making a registry change. My preferred method is to set Windows to index every file, even if it's an unknown exception. This is done by adding or changing a DWORD called FilterFilesWithUnknownExtensions in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex. Set it to 1. (1 for on, 0 for off)
In fact I added it as part of the build process here at ORCS Web when Windows Server 2003 first came out a few years ago. The search on every server on our network will search every file type.
Here is how I prefer to do it. Create a file called AddIndexingToAllFiles.reg (Or, I just call it abc.reg since I delete the file immediately after using it). Then put the following in it:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex]
"FilterFilesWithUnknownExtensions"=dword:00000001
Save the file on your desktop and double click on it. After accepting the prompt and warning, the entry will be added to your registry. You can delete the registry file since you're done applying it.
Here's a good Microsoft KB article on this with further details: http://support.microsoft.com/default.aspx?scid=KB;EN-US;309173. It also explains how you can add specific extensions rather than just indexing all files if you prefer to do that.
Note: This is for Windows XP and Windows Server 2003. The rules change again in Vista with a whole new search engine and method. Here is a long discussion between Microsoft and some not-so-happy people discussing how Vista works: http://windowsvistablog.com/blogs/windowsvista/pages/advanced-search-techniques.aspx.
I use Remote Desktop all the time to manage servers remotely, and often I join other people's sessions to troubleshoot something with them, or walk through something or other.
In Windows Server 2003 (and Windows 2000 Server), the easy way to start up Terminal Services Manager is Start -> Run -> 'tsadmin' -> [Enter]. This calls us Terminal Services Manager where I can right-click on a user and click 'Remote Control', and if they approve, I can join their session.
This doesn't work in Windows Server 2008 anymore. The change is ever so slight. In Windows Server 2003 the tool was tsadmin.exe, so typing 'tsadmin' was all that was required to start the tool. Now, in Windows Server 2008, this has been moved to a MMC snap-in and is called tsadmin.msc (plus tsadmin.dll is used silently).
So, to spin up Terminal Services Manager in Windows Server 2003, you can click on Start and your cursor focus will already be in the search box. Type 'tsadmin.msc' and press [Enter] and you'll be in Terminal Services Manager.
If you really don't want to type the '.msc' each time, you could create a batch file to do it for you. Create a file in c:\windows\system32 (which is in the system path already), call it tsadmin.bat and type 'tsadmin.msc' (without the quotes) in the body of the file. Save it and you'll be set. The disadvantage of doing this though is that you won't be practiced up on typing tsadmin.msc on fresh servers, so personally I prefer to just remember the extra .msc now on Windows Server 2008.
Note: If you don't type this often enough to remember 'tsadmin.msc', this has always been available from the Administrative Tools folder. In Windows Server 2003/2000 it's directly under Administrative Tools. In Windows Server 2008 it's one folder deeper under 'Terminal Services'.
I was just asked to help someone troubleshoot a site that worked fine on Windows Server 2003 / IIS6 but didn't work on Windows Server 2008 / IIS7. A file was in a folder under the bin folder on the site and displayed an error when trying to view the page. The path looked something like this:
http://www.sitename.com/subfolder/bin/debug/file.xml
The subfolder wasn't marked as an application, although that doesn't really matter. The point is that since /bin/ was in the path somewhere, IIS7 wouldn't allow the file.xml to be displayed. It served up a 404.2 error saying file or directory not found.
404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
Since I knew that it worked in IIS6, I knew that it wasn't asp.net that was blocking it, so I looked in applicationHost.config and found the following under the <requestFiltering> section:
<hiddenSegments applyToWebDAV="true">
<add segment="web.config" />
<add segment="bin" />
<add segment="App_code" />
<add segment="App_GlobalResources" />
<add segment="App_LocalResources" />
<add segment="App_WebReferences" />
<add segment="App_Data" />
<add segment="App_Browsers" />
</hiddenSegments>
So, IIS7 now blocks those key folders and doesn't allow them to be seen. To the outside world, any page in any of these folders appears to not exist.
There may be times when you really do want to display the page, as in this particular case. Not to worry, it can be changed easily enough. This setting in on purpose though, so you usually shouldn't remove it for the whole site.
You can use AppCmd or do it manually from applicationHost.config or web.config. Since requestFiltering is allowed to be set at the site or folder level by default, it's probably best to set a web.config file in the folder that you want to allow.
To do this, create a web.config file in your folder and type or paste the following into it. I should look something like this:
<?xml version="1.0"?>
<configuration>
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>
If you want to make the change to your applicationHost.config file instead, you can do it by adding a location tag to the bottom of the file (well, almost the bottom - along with the other location tags) like this:
<location path="sitename.com/subfolder/bin/debug">
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</location>
You can do this using AppCmd instead. Just drop to the command prompt and type the following: (Be sure to change the paths to the correct page before running this.)
C:\Windows\System32\inetsrv\appcmd.exe set config "sitename.com/subfolder/bin/debug" -section:system.webServer/security/requestFiltering /-hiddenSegments.[segment='bin']
After making this change, you will be able to view pages normally, even if they have /bin in the site path.
The title is a bit biased since I co-authored the book, but Professional IIS 7 will be out in print within a couple weeks and I highly recommend picking up a copy!
I've had my head buried in this book for months—spending more time that I realized possible, but learning IIS 7 inside out and ultimately enjoying it. (Although I have to admit that sometimes at 4:00 in the morning, trying to hit deadlines, I'm not sure that I realized that I was enjoying it. :))
The book will be in bookstores and shipping online during the 2nd week of March 2008. You can order it directly from Wrox: http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470097825.html or from Amazon.com.
We had a great team of authors on this book, each writing in areas that they knew best, and all delivering excellent content that is both knowledgeable, but also practical, based on their experience. The author list is: Ken Schaefer, Jeff Cochran, Scott Forsyth, Rob Baugh, Mike Everest, Dennis Glendenning.
I wrote on application pool administration, remote delegation, webfarm management and configuration, programmatic configuration and administration and diagnostics and troubleshooting.
Be sure to pick up a copy and tell all of your IIS friends about it too!
A question was asked on a forum that I frequent which I thought was worth writting a blog about.
Q: What is the difference between an application and an Appdomain? I understand from my research so far that an Appdomain is a container within which ASPX runs and that Apppool is a process that starts the w3wp.exe worker process within which ASP applications run.
A: That's a good question. Here are some key differences:
-
An application is an IIS term, but it's one that ASP.NET utilizes. Essentially it creates a sandbox, or a set of boundaries to separate different sites, or parts of sites, from the others.
-
An AppDomain is a .NET term. (In IIS7, AppDomains play a larger role within IIS, but for the most part it's an ASP.NET term)
-
An AppDomain contains InProc session state (the default session state mode). So if an AppDomain is killed/recycled, all of your session state information will be lost. (if you are using the default InProc session state)
- Applications can have multiple AppDomains in them although often times there is a one-to-one relationship between them.
-
In IIS6 and greater, there is the option of creating groups, or "pools" of applications that can be bundled together or separated; however the server administer decides. These are called Application Pools. Each app pool runs under its own w3wp.exe worker process.
-
In IIS, it's easy to see an application. A new website is a separate application and any subfolder can be marked as an application. When they are, the icon beside the folder turnes into a picture of some gears. By right-clicking on the folder, you have the option of marking a folder as an application or removing it as an application, if it already is one. Also, in IIS6, in the Application Pools section, you can see all of the applications and which app pool they live under.
-
ASP.NET, on the other hand, doesn't give much visibility into AppDomains, at least not from any visual tools. This is done behind the scenes. Programmatically you can create them, tear them down or see a list of all running AppDomains.
-
You can recycle an application from IIS. In IIS5, you can't do it directly unless you recycle the entire web server, but in IIS6 and greater, you can recycle the application pool that the application lives under. It will gracefully die off and a new application will start up to replace it. Or, to word it another way, another w3wp.exe worker process will be started and then the old one will die off after it completes any currently running page requests.
-
You can recycle an AppDomain in ASP.NET through the 'touch trick'. There are a few ways to do it, but the most straight forward is to edit your web.config file in notepad and add a space to an insignificant place. Then save the file. This will cause the AppDomain to recycle. This *does not* touch the IIS application though.
-
Recycling an AppDomain will come pretty close to starting ASP.NET fresh again for that particular ASP.NET application, so although it doesn't recycle the apppool, it can give ASP.NET a fresh start in many situations.
Beta 2 of VS 2008 and .NET 3.5 which was just released a few minutes ago and is available for download. I know I've been really quiet on my blog for a while. I'm still around, just haven't freed up my time enough to do the blogging that I know I should. I figured I would break my silence and mention this release.
http://weblogs.asp.net/scottgu/archive/2007/07/26/vs-2008-and-net-3-5-beta-2-released.aspx
Scott Guthrie's blog post is a must read. Some key features in VS 2008 and .NET 3.5 are:
- LINQ
- JavaScript IntelliSense and Debugging
- AJAX integrated
- Great CSS support
- Development can target different versions of the framework
- much more
Perfmon is a great tool for mining performance data on a server and has a slew of objects and counters to expose most any type of data.
As nice as it is, there is one thing that can be difficult to do, and that is to view data for temporary objects. For example IIS worker processes only live until the next recycle or restart. If there are many worker processes on the server, the default view doesn't allow you to tell which is which.
Notice in the screenshot that there are three w3wp.exe worker processes on this server in the section on the right, but you can't tell from this view which belongs to which worker process.
A co-worker of mind pointed me to this great registry setting today that takes care of this. http://support.microsoft.com/kb/281884. Through a simple registry change, you can view the PID of each worker process within perfmon. It can be obtained without the registry change, but through extra effort.
As long as you know the PID, you can match it up to the app pool easily. In IIS6, you can use iisapp.vbs. In IIS7, you can use "appcmd list wp". Of course Task Manager is a key tool that is often used in parallel to show active PIDs, worker processes and various other real-time counters.
The registry change is quick and painless. In fact, after making the change, I closed the Add Counters windows in perfmon and opened it again and the PID was there immediately. No restart necessary.
If you want to save a click or two, you can follow the following steps instead of doing the change manually:
Take the following indented text and save to your desktop and call it showPID.reg.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance]
"ProcessNameFormat"=dword:00000002
Double click, acknowledge the prompt and you're done!
Disclaimer: Any changes to the registry needs to be done with an awareness of the impact. There is always the chance that some tool, or another administrator, needs this to be at the default setting. While it is safe in most environments, I can't be held liable for any negative impact that this change has.
I had an interesting situation come up yesterday that I thought would be worth writing about.
As a web host here at www.orcsweb.com, we offer disk space, but obviously need to set some type of limits. One of our clients had an allotment of 1,140 MB. (That is an odd number, but that's what it worked out to.) While working with him a couple of weeks ago, I checked his disk usage by right-clicking on the folder in windows explorer and clicking on properties. The space that it told me was 1.14GB, which I relayed on to the client. So far so good, it seemed that he was right at his limit.
Yesterday, an automated process checked the disk usage on his site, calculated his usage at 1,170MB and sent him an email asking for him to address the disk space or increase his allotment. He was confused, and rightfully so, because I had just told him that he was at 1.14GB, and he was confident that nothing was added since our conversation.
So, I started digging. I checked the database information which is what the script utilized and say that it has been at 1,170MB every day for a while. So, I pulled apart our automated script to see why it said 1,170MB but windows explorer/properties said 1.14GB. I even created a 5 line VBScript script using FileSystemObject to see what it returned, and sure enough, it returned 1,170MB. I was confused and looked at the numbers for a bit, then realized that I had overlooked the obvious. It's something I know well, but it didn't click at first.
1GB is actually 1024MB. It's not an even 1000. People will often say that it's 1000, but that's just a rounded number. In day to day situations, it may not even matter too much, people are often wondering about their usage in general terms, not something so precise. But, in this case, one number was under his limit and one was over his limit so it was important to figure out the issue.
Check it out: The size is actually 1,227,418,765bytes, so we'll take that divided by 1024 (for KB) divided by 1024 (for MB) and divided by 1024 (for GB). We get: 1.1431228. That matches the size of 1.14GB shown. Now, multiple that by 1024 and we get 1,170MB. The 24MB that was lost in rounding made a big different in this case!
So, nothing was wrong in the script, it calculated the information correctly, but from the windows explorer/properties view, the 1024 instead of 1000 made enough of a difference that it threw us off at first.
I was able to work out something on the disk space that worked for both of us and everyone is happy, plus this serves as a good reminder about the real difference between 1GB and 1000MB.
Here's a must-have cheat sheet for PowerShell. Jeffrey Snover has put together an excellent doc that is well worth printing off and keeping handy for anyone working with PowerShell:
http://blogs.msdn.com/powershell/archive/2007/01/24/powershell-cheat-sheet.aspx
More Posts
Next page »