832 Chapter 16 • Administration of an IIS 7.0 Web Server This command, though, isn’t as useful on busy servers since it will return large amounts of data in which it is diffi cult to fi nd what you are looking for. AppCmd.exe will make this easier by allowing you to narrow down the scope of your search by providing a site name or application pool. To see all currently executing requests in the DefaultAppPool, enter the following: Appcmd list requests /apppool.name:DefaultAppPool To further narrow your search, you can use a parameter that allows you to ask only for show requests that match the following criteria (such as to request executing elapsed time) and AppCmd. exe will return this information to you. In the following example, we will attempt to locate requests that are currently executing in the DefaultAppPool, but that are still executing after 10 milliseconds. To see all requests executing in DefaultAppPool that have elapsed for greater than 10 milliseconds, enter: AppCmd list requests /apppool.name:DefaultAppPool /elapsed:10 As you have hopefully seen, AppCmd.exe provides you with some powerful command-line capabilities and insight into the Web server runtime. If you use this wisely, you will be well ahead in the troubleshooting and diagnostics in IIS 7.0. Confi guring and Using Trace Log Data with AppCmd IIS 7.0 introduces Failed Request Tracing to help administrators and developers locate failures. As we mentioned earlier, setting up tracing requires you to enable this for the server, site, or application and then defi ne a tracing rule. You can use AppCmd’s Trace object to help you enable log fi les, set up rules, and even inspect your trace log fi les. Enabling or Disabling Failed Request Tracing Compared to IIS Manager, AppCmd is unique in allowing you to either enable or disable tracing with or without defi ning a tracing rule. This is nice because you can predefi ne rules and have them ready should they be needed. In this case, you would simply enable tracing and the existing rules will be used. However, you might need to enable tracing for the URL but also defi ne new rules at the same time. In IIS Manager, you had to take two separate actions, but with AppCmd.exe you can defi ne all within a single command. To enable tracing and defi ne a rule, enter the following: appcmd confi gure trace “Default Web Site/” /enable /path:*.aspx To disable tracing for a URL, type: appcmd confi gure trace “Default Web Site/” /disable /path:*.aspx Viewing Trace Log Files Using AppCmd As we mentioned earlier, you can also use AppCmd.exe to inspect previously created trace log fi les. This is a nice, handy feature but requires some insight into how tracing is designed and works. You will learn more about how tracing works in the next chapter, but for our purposes here let’s Administration of an IIS 7.0 Web Server • Chapter 16 833 defi ne how you would view a trace log fi le. It is important to note that it is much easier to use Internet Explorer to view trace log fi les since it assists you in viewing the various errors, warnings, or informational data stored in the log fi les. To view a trace log fi le using AppCmd, use the following syntax: appcmd inspect trace “Default Web Site/fr000001.xml” Writing Scripts Using the New WMI Provider The fi rst question asked by many when they hear there is a completely rewritten WMI provider in IIS 7.0 is why. You are surely asking the same if you are familiar with IIS 6.0’s WMI provider. The reason is fundamental and centered on the IIS 6.0 provider more than anything else. The resources and work it would take to rewrite the IIS 6.0 provider to understand the brand-new confi guration in IIS 7.0 was terribly expensive and potentially risky. Beyond that, the WMI provider in IIS 6.0 wasn’t built with extensibility in mind, and building in extensibility after the fact is diffi cult. The current provider in IIS 6.0 as well would be diffi cult to keep it compatible if you embarked on re-architecting it to support IIS 7.0. Instead, Microsoft built a new WMI provider from the ground up that supported the new confi guration as well as extensibility. Let’s learn more about this new WMI provider. Getting Started with WMI Let’s get started by familiarizing you with the objects available in the WMI provider, and then apply that learning to accomplish common tasks using that provider. WMI scripts start with a specifi c creation process where objects, methods, and wisdom come together. The power of WMI is the fact that it has remoting built in to allow you to connect directly to a remote computer and manipulate its confi guration. This is the downside to AppCmd.exe because it can’t work remotely. Starting Fresh with WMI in IIS 7.0 IIS 6.0 shipped with a WMI provider, and in fact, most of the command-line scripts were built using this provider. We mentioned though that the new provider in IIS 7.0 is completely new and provides a new object model to simplify the usage of WMI. To learn WMI, you should start with simple, straightforward tasks and build upon them until you have a fully functional script to accomplish your Web deployment. In our example, we will use similar heuristics as we did for IIS Manager and AppCmd.exe, where we do the following: 1. Create Web sites. 2. Add Virtual Directories to our Web sites. 3. Create an application pool. 4. Enable an authentication type for our Web site. 5. Set up tracing for our new Web site. 834 Chapter 16 • Administration of an IIS 7.0 Web Server Creating Web Sites Using WMI You might typically not work with single Web sites and need to manage or create multiple sites on your IIS 7.0 server. This administration task can be accomplished using IIS Manager, or AppCmd.exe, yet they require a little more work than one might want. Beyond that, they aren’t reusable in the future. This is possible using WMI. In this case, you can easily adapt using WMI, and with simple steps can start building your deployment automation. To create a Web site using WMI, type this code and save it as CreateWebsite.vbs: Set oIIS = GetObject(“winmgmts:rootWebAdministration”) ‘ Create a binding for the site Set oBinding = oIIS.Get(“BindingElement”).SpawnInstance_ oBinding.BindingInformation = “ * :80:www.myFirstWMISite.com” oBinding.Protocol = “http” ‘ These are the parameters we will pass to the Create method name = “My First WMI Site” physicalPath = “C:\inetpub\wwwroot” arrBindings = array(oBinding) ‘ Get the Site object defi nition Set oSiteDefn = oIIS.Get(“Site”) ‘ Create site!! oSiteDefn.Create name, arrBindings, physicalPath Creating Virtual Directories Using WMI To take the next step, you should now defi ne your fi rst virtual directory using WMI to allow you to further expand your arsenal of tools. In this example, you will add to your script the ability to create a virtual directory and defi ne your fi rst root application using WMI. Add the following WMI script to your CreateWebsite.vbs to add a virtual directory: Set oIIS = GetObject(“winmgmts:rootWebAdministration”) ‘ Defi ne the Path, SiteName, and PhysicalPath for the new application. strApplicationPath = “/NewApp” strSiteName = “My First WMI Site” strPhysicalPath = “D:\inetpub\NewApp” ‘ Create the new application oIIS.Get(“Application”).Create strApplicationPath, strSiteName,_ strPhysicalPath Using WMI to Create Application Pools The goal is to step up your script to allow it to isolate your Web applications in IIS 7.0. In this next step, we will add script to allow you to create a new application pool and assign your root application for your new site to this application pool. Administration of an IIS 7.0 Web Server • Chapter 16 835 To create your application pool and assign an application to it, copy the following and save it as CreateAppPool.vbs: Set oIIS = GetObject(“winmgmts:root\WebAdministration”) oIIS.Get(“ApplicationPool”).Create(“MyAppPool”) To assign your application, /NewApp, to your application pool, add this to CreateAppPool.vbs: ‘ Retrieve the NewApp application. Set oApp = oWebAdmin.Get(“Application.SiteName=‘My First WMI Site’, Path=‘/NewApp’ ”) ‘ Specify the new application pool name. oApp.ApplicationPool = “MyAppPool” ‘ Save the change. oApp.Put_ ‘ Display the new application pool name. WScript.Echo WScript.Echo “New application pool: ” & oApp.ApplicationPool Setting Authentication Using WMI After you have created your Web site, root application, and virtual directory, the next major step is to modify the default confi guration settings for your Web site. This sample could reach very, very far and is usable for many different properties or attributes in your Web site. In your case, you will start by modifying the default settings of your new Web site’s authentication to support Windows authentication. To change “My First WMI Site” authentication using WMI, copy the following and save it as SetWindowsAuthentication.vbs: siteName = “Default Web Site” Set oWmiProvider = GetObject(“winmgmts:root\WebAdministration”) Set oAnonAuth = oWmiProvider.Get(“AnonymousAuthenticationSection.Path=‘MACHINE/ WEBROOT/APPHOST’,Location= ’” + siteName + “‘”) Set oWinAuth = oWmiProvider.Get(“WindowsAuthenticationSection.Path=‘MACHINE/ WEBROOT/APPHOST’,Location= ’” + siteName + “‘”) oAnonAuth.Enabled = false oAnonAuth.Put_ oAnonAuth.Refresh_ oWinAuth.Enabled = true oWinAuth.Put_ oAnonAuth.Refresh_ Enabling Failed Request Tracing Using WMI Last, it is important to prepare yourself for any potential diagnostics you might need to do for your new Web site and application. The last step to perform will set up Failed Request Tracing for your new Web site. 836 Chapter 16 • Administration of an IIS 7.0 Web Server To enable Failed Request Tracing using WMI, copy the following and save it as EnableFREB.vbs: siteName = “Default Web Site” myFrebDirectory = “%SystemDrive%\MyFrebDir” Set oWmiProvider = GetObject(“winmgmts:root\WebAdministration”) Set oSite = oWmiProvider.Get(“Site.Name=’” + siteName + “‘”) oSite.TraceFailedRequestsLogging.Enabled = true oSite.TraceFailedRequestsLogging.Directory = myFrebDirectory oSite.Put_ oSite.Refresh_ Managed Code Administration: Inside Microsoft.Web.Administration Microsoft’s .NET Framework and its supporting development platforms offered yet another opportunity to manage your IIS Web servers. IIS 7.0 offers a new, robust, managed-code API aimed at empowering the manage code community of developers with the ability to not only build Web applications but also confi gure their IIS 7.0 servers. Using your language of choice, you can quickly add the Microsoft.Web.Administration (MWA) binary to your Visual Studio project and modify your IIS 7.0 confi guration. In this section, we will help you understand how MWA interacts with IIS 7.0 and give you a starter course on using it. The Microsoft.Web.Administration Object Model In this section, we will familiarize users with the object model that is available using MWA. It is also important to understand how to build scripts using MWA and we will help you get started with the most common tasks highlighted thus far in this chapter. The beauty of this administration stack is its powerful capabilities supporting all the .NET Framework languages. If you prefer VB.NET over C# then just set up the project and off you go using MWA—with your favorite development language. In our examples, we will use C# to manipulate the IIS 7.0 confi guration and also access runtime information all from within a console application. This makes the code reusable since it will be compiled to an EXE that can be reused on all your IIS 7.0 Web servers. . powerful command-line capabilities and insight into the Web server runtime. If you use this wisely, you will be well ahead in the troubleshooting and diagnostics in IIS 7.0. Confi guring and Using. reason is fundamental and centered on the IIS 6.0 provider more than anything else. The resources and work it would take to rewrite the IIS 6.0 provider to understand the brand-new confi guration. guration in IIS 7.0 was terribly expensive and potentially risky. Beyond that, the WMI provider in IIS 6.0 wasn’t built with extensibility in mind, and building in extensibility after the fact