Windows Vista Kind of "Documents and Settings" Is Gone

I liked Windows 2000's improvements over NT 4.0, but I really found one thing annoying about it: the Documents and Settings folder. I do a lot of command-line work, you see, and folder names with spaces are a pain in the neck. You've got to put quotes around them, and even if you do, some programs get a bit stupid when handed a folder name with spaces in it.

NT originally stored user profiles in winnt\profiles, but Microsoft decided to move the profiles out of the OS's directory (which probably made sense) into a separate location. That, again, was a good idea; calling it “Document and Settings”, in contrast, was a bad one. (Not as dumb as making people learn goofy phrases like HKEY_LOCAL_MACHINE to understand the Registry, but dumb enough.) Vista changes that, creating a folder to store local profiles called \Users. You've just gotta love it: no spaces, short and sweet.

But we've been living with Documents and Settings for six and some years, so Microsoft knows that there will be some application out there that doesn't follow the rules, and decides to write some data to c:\documents and settings\ some-users-name \ some-folder-name instead of just asking the operating system where that user's profile folder is. To combat that, Microsoft creates a Documents and Settings folder on the drive, but hides it. Then they take things a step further and set its NTFS permissions to-you'll love this-deny the Everyone group read access to Documents and Settings. The result? Any application that tries to create data in Documents and Settings, rather than just asking the OS where to put the profile information, will fail.

Vista, however, does make working with folders and file names with spaces in them easier. Whenever you're using a command-line tool that requires a file or folder name, you can just type as much or as little as you like of the folder or file name that you want to specify, then press the Tab key. It auto-completes the file or folder name. Thus, to change my directory to C:\Documents and Settings, I just type cd d and then press Tab, and instantly the command becomes cd ‘c:\documents and settings.’ If there is more than one directory starting with a "D" and it chose the wrong one, I'd just press Tab again and it'll cycle through the possibilities. It even puts the quotes around the name if there's a space in the name. (This feature existed in 2000, XP, and 2003 but was not enabled by default.)

Source of Information : Sybex Administering Windows Vista Security: The Big Surprises

Windows Vista Start Menu "Run…" Is Off

I'm not sure who makes the call on the user interface stuff at Microsoft, but I get the impression that he thinks we user types are pretty dumb. It seems like every version of Windows changes the default behaviors of the Start menu in ever-increasing levels of annoyance. XP hid Administrative Tools, Server 2003 made getting to the actual Control Panel more work, and now Vista has taken away the Run… item from the Start menu. Personally, I use Run… a lot of the time, if for no other reason than to quickly get to Regedit and the local Group Policy Editor. Losing Run… on the Start menu makes me less productive on Vista.

So let's fix that, shall we?

1. Right-click the Start menu, and in the resulting context menu choose "Properties." As with earlier versions of Windows, that brings up the Taskbar and Start Menu Properties page with the "Start Menu" tab highlighted. Choose the "Customize…" button in the upper right-hand corner to bring up the Customize Start Menu dialog.

2. In the Customize Start Menu dialog, you'll see a number of radio buttons in a window with a scroll bar down its side. Scroll down almost to the bottom, and you'll see the option "Run command" with an unchecked check box next to it. Check the box.

3. Still in that window, scroll all the way down and you'll see a section called "System administrative tools." In that section, choose the radio button labeled "Display on the All Programs menu."

4. Click OK to dismiss the Customize Start Menu dialog, and again to dismiss the Taskbar and Start Menu Properties page.

The Run… command and the Administrative Tools group are now back, after a few clicks. (And they call Vista a productivity tool!)

Source of Information : Sybex Administering Windows Vista Security: The Big Surprises

Windows Server 2008 Domain Group Policy - Scripts

Using GP, you can assign scripts to entire domains, organizational units, sites, and groups instead of repeatedly entering the same login script into multiple users' profiles. You can launch four types of scripts using a GPO: logon and logoff scripts, which apply to users, and startup and shutdown scripts, which apply to computers. Startup scripts are executed before logon scripts, and logoff scripts are executed before shutdown scripts.

You can write scripts in any number of languages. Windows Server 2008 is prepared to accept Jscript (.JS) and Visual Basic Scripting Edition (.VBS) files in addition to batch (.BAT), compiled command scripts (.COM), and application executables (.EXE). Scripts to be run through GP are stored on domain controllers in %SystemRoot%\SYSVOL\yourdomain.com\Policies\scripts, with yourdomain.com replaced with your fully qualified domain name.

You can assign startup and shutdown scripts in GP using the following procedure:

1. In the Group Policy Object Editor, navigate in the lefthand pane through Computer Configuration, Policies, Windows Settings, and Scripts (Startup/Shutdown).

2. In the righthand pane, click Startup and Shutdown to modify the scripts assigned to each.

You can assign logon and logoff scripts in GP using the following procedure:

1. In the Group Policy Object Editor, navigate in the lefthand pane through User Configuration, Policies, Windows Settings, and Scripts (Logon/Logoff).

2. In the righthand pane, click Logon and Logoff to modify the scripts assigned to each.

You can further define properties for these scripts under the Computer Configuration/Policies/Administrative Templates/System/Scripts and User Configuration/Administrative Templates/System/Scripts nodes in the Group Policy Object Editor. For users running scripts, you have the following options :

"Run legacy logon scripts hidden" tells Windows not to display the DOS window when using a .COM or .BAT logon or logoff script.

"Run logoff scripts visible" indicates whether the actions and results of the logoff script's execution should be displayed to the user.

"Run logon scripts synchronously" allows you to specify multiple scripts and have them run at the same time rather than in sequence as the default dictates.

"Run logon scripts visible" indicates whether the actions and results of the logon script's execution should be displayed to the user.

For computers running scripts, you can configure the following options:

"Allow logon scripts when NetBIOS or WINS is disabled" instructs Windows to either run or ignore logon scripts depending on where you have enabled the old legacy-compatible NetBIOS and WINS naming schemes.

"Maximum wait time for Group Policy scripts" sets a cutoff time for the execution of scripts specified in GP before Windows simply cuts them off and continues with the process at hand.

"Run logon scripts synchronously" allows you to specify multiple scripts and have them run at the same time, rather than in sequence as the default dictates, on a per-computer rather than a per-user basis.

"Run shutdown scripts visible" indicates whether the actions and results of the shutdown script's execution should be displayed to the user.

"Run startup scripts asynchronously" allows to you to specify multiple scripts and have them run in sequence, rather than at the same time, as the default dictates.

"Run startup scripts visible" indicates whether the actions and results of the startup script's execution should be displayed to the user.

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide

Windows Server 2008 Software Restriction Policies

Software Restriction Policies allow you to control the execution of certain programs. It's an excellent feature to use on terminal servers or machines serving as a public kiosk, so users are locked into one specific function and can't mess with administrative tools or Internet applications and utilities.

Windows can identify software to either restrict or allow in several different ways. For one, it can use hash rules, which are made by identifying characteristics of files and executables that come with a program and generating an algorithmic hash from them. Hashes are great for identifying specific versions of programs because the hash value would change when different files are used to compute the hash (which is a near certainty with newer version of a program). Certificate rules can identify software via a digital signature, which is a useful method to secure authorized scripts. Windows also can identify software via its path and the Internet zone (inside Internet Explorer) from which a particular piece of software is downloaded. Finally, Windows can create a rule that catches any software not explicitly identified either in a list or by any other rule. (Control for programs executed within a browser is lacking from the GP standpoint, but improvements to Internet Explorer in Windows XP Service Pack 2 pick up a bit of this slack.) Windows matches programs to rules in the order in which they're listed in the software restriction GPO, and if more than one rule identifies the same program, the rule that catches the program most specifically will trump any other rule.

You might be tempted to create a rule that disallows programs from running by default aside from those explicitly placed in an exception list. This seems like an easy way out, but it really can lobotomize a system unless you take great care to create an exception for every Windows executable a user might need, including his application programs. It can also step on the toes of any user logon scripts that might be necessary to create a secure environment. If you decide to go this route, it's imperative that you extensively test any restriction policies and exception lists in a lab. Also, when you do create the actual software restriction GPO, make sure to add the Domain Administrators group to the GPO's ACL and explicitly deny the Apply Group Policy permission to the GPO—this will enable an administrator to reverse the policy and not lock himself out.

Once you're ready to create the policy, follow this procedure:

1. Create a new GPO for each restriction policy. This makes it easier to disable a policy that might be overly restrictive.

2. Choose Computer Configuration or User Configuration to apply the restrictions to machines or users, and then navigate through Policies à Windows Settings à Security Settings à Software Restriction Policies.

3. Right-click Software Restriction Policies and choose New Software Restriction Policy from the context menu.

4. Set a default identifier rule: in the left pane, click Security Levels, and then right-click a specific security level and choose Set as Default from the pop-up context menu.

5. Now, create the actual rules that will catch software on which to enforce a restriction. Right-click Additional Rules in the lefthand pane. Choose New Certificate Rule and select the certificate to require or block, New Hash Rule and the file to allow or block, New Internet Zone Rule and the zone from which to allow or block programs, or New Path Rule and the file or Registry key to allow or restrict.

6. In the righthand pane, double-click Enforcement. Here, indicate how these restrictions should be enforced. Use of the following options is recommended:

"All software files except libraries" will help you avoid blocking critical system and application function files.

"All users except local administrators" indicates that Windows should enforce the policy for everyone except those in the local administrator group.

7. Next, in the righthand pane, double-click Designated File Types. On this sheet, review and add file extensions associated with applications included in the software restriction policies. The list should be fairly complete, but ensure that any scripting languages you use in your organization have their associated file extensions included.

8. Finally, in the righthand pane, double-click Trusted Publishers. Here you can specify whether normal users, local administrators, or enterprise administrators are allowed to decide what certificates to trust when opening digitally signed programs and controls.

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide

Windows Server 2008 IntelliMirror: Folder Redirection

You can use the folder redirection functionality of GP to change the target location of many folders within a particular user's Windows interface. For example, you can specify custom locations for the Application Data, Desktop, Documents (including the Pictures, Music, and Videos subfolders), Favorites, Contacts, Downloads, Links, Searches, Saved Games, and Start Menu folders. Using folder redirection circumvents the nasty problem of roaming profiles: severe network traffic hikes caused by copying large My Documents and Desktop folders to workstations around the network when users log on. You also can back up the share where the folders are redirected using a normal network backup procedure, automatically protecting the contents.

To access the folder redirection functionality, launch the Group Policy Object Editor for a particular GPO and navigate through User Configuration, Policies, Windows Settings, and Folder Redirection. In the righthand pane, you'll see the folders you can redirect. Right-click each folder to bring up the Properties window.

On the Target tab, you can choose the type of redirection for this policy. For this example, choose the basic method, which simply redirects all users' folders to the same location. Next, enter the target folder at the bottom of the screen under Root Path, and select the option to create a new folder for each user underneath the root path. Then, move to the Settings tab, and choose the following settings:

Grant the user exclusive rights to My Documents

If this setting is enabled, the user to whom the folder belongs and the local computer have administrative and exclusive rights to the folder, to the exclusion of all other objects. If this setting is disabled, the current permissions on the folder are kept.

Move the contents of My Documents to the new location

If this setting is enabled, everything in the current My Documents folder will be moved to the new, redirected location. If this option is disabled, nothing will be moved and the new My Documents folder will be empty.

Policy removal

You can adjust the Windows default setting, which is to leave the folder in the redirected location if the redirection policy itself is removed. You also can choose to move the folder back to its initial location.

My Pictures preferences

The default action for the My Pictures subfolder is to follow the My Documents folder to wherever it resides.

Redirecting folders based on group membership

If you want to redirect some profile folders to different locations based on the different groups to which a user belongs, you can use the Advanced method of redirection inside the redirect policy properties page, on the Target tab. When you select Advanced from the drop-down setting box indicating the type of redirection, click the Add button. The Specify Group and Location box will appear.

Enter the name of a security group, and then enter the network path to the folders. Always use a UNC path, even if the folders are local to your machine, so that users taking advantage of roaming profiles will see the correct folders in an absolute path and not wrongly translate a local, relative path. Click OK when you're done, and then repeat the process for as many groups as you need.

If your users are creatures of habit, you can even turn on the Offline Files and Folders feature on the share where you've stored the redirected folders. This way, Windows will continue to display and use a customized environment even when the network is down and the share can't be reached.

Removing a redirection policy

It can be a bit difficult to track what happens to redirected folders if you decide to remove a redirection policy. It really depends on the appropriate setting on the Settings tab of the redirected folder's policy properties sheet.

If you've elected to redirect the folder back to the local user profile when the policy is removed, and the option to move the contents of the local folder to a new location is enabled, the folder will return to its original location and the contents of the folder will be copied back to the original location but not deleted from the redirected location. If the option to move the contents of the folder to a new location is disabled, the folder will revert to its original location, but the contents of the folder will not be copied or moved to the original location. This means the user is unable to access the contents of the redirected folder from the special folder's UI within the shell, but using a UNC path, she still can access the redirected folder and retrieve its contents manually. If you've selected to leave the folder in the new location when the policy is removed, the folder and its contents will remain at the redirected location, and the user will have access to it, regardless of whether the option to move the contents of the folder to the new location is enabled or disabled.

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide

Windows Server 2008 IntelliMirror: Software Installation

In my opinion, software installation is one of the coolest and most useful features of GP, and I know many administrators who agree with me. Using Microsoft's IntelliMirror technology introduced in Windows 2000, administrators using GP can distribute software applications initially, using a push or pull method, and then upgrade, redeploy, or remove that software either wholesale or when certain conditions apply. IntelliMirror also offers intelligent application repair features so that when critical files for an application deployed through IntelliMirror are corrupted or deleted, Windows takes over and fixes the problem so that the application will still start and function correctly. This is a big timesaver.

You can distribute and install applications in your organization in two ways. You can assign a software package, which places a shortcut on the user's Start menu and loads the advertisement for the package into the computer's Registry. Or you can publish an application, which simply places the program with the Add/Remove Programs applet in the Control Panel. The user can elect to install the software at his discretion and at a convenient time.

You also can distribute applications via the assign and publish functionality to a computer or a user. If you assign a package to a user, the application is installed on the local system the first time the user runs the software. Incidentally, you can also elect to install such an application when the user logs on, although this can make for long boot times and calls to the help desk. These user-assigned applications follow a user around the network to each computer to ensure that she has all the applications she should on each computer. If you assign a package to a computer, the application is installed on that system when booted up, and the software is installed only on the computer defined in the policy. Applications don't necessarily follow a user around. If you use the publish functionality of IntelliMirror, you can publish to only a specific user because computers can't choose how and where to install software. Published applications also are not quite as robust as assigned applications, and the repair functionality of published applications is limited.

Packaging software

The easiest way to publish and assign software is with Microsoft Installer packages, or MSI files. Applications packaged in Installer format include a database of changes to make to files and Registry keys, instructions on removing previous or outdated version of software, and strategies to install on multiple versions of Windows within one file. MSI files also allow intelligent repair functionality for use if installations become corrupted on individual computers, and their rollback function for removing or redeploying an application is useful as well. IntelliMirror and GP-based software distribution are designed to work with applications that install using an MSI package.

But all is not lost if your software isn't offered in MSI format. First, you can use the ZAP file method. You can use a ZAP file when software isn't available with an MSI package to publish (but not assign) the application. A ZAP file is nothing more than a description of an application, its setup program, and any associated file extensions. A sample ZAP file for Adobe's Acrobat Reader 5.0 is shown here:

Line 1: [Application]

Line 2: FriendlyName = Adobe Acrobat Reader 5.0

Line 3: SetupCommand = \\deploy\adobe\rp505enu.exe

Line 4: DisplayVersion = 5.0

Line 5: Publisher = Adobe Corporation

Line 6: URL = http://www.adobe.com

Line 7:

Line 8: [Ext]

Line 9: PDF=

A few notes about this ZAP file: the FriendlyName section shows the application name, which will appear in the Add/Remove Programs applet within the Control Panel on the computers to which the package is published. It also contains the Setup directive, which tells Windows the network path of the file to install the package. The other tags, although offering more information on the version, manufacturer, and Internet address of the manufacturer, are optional. The Ext section lists file extensions to be associated with the program, each followed by an equals sign.

The ZAP file method has a few caveats. First and foremost, because ZAP file installations can only be published, you lose the robustness and intelligent repair features of software applications assigned to computers and users. You also can't set an application deployed via a ZAP file to install automatically on first use, and you can't upgrade or remove an application deployed via a ZAP file using a GPO. In addition, a specific user must have appropriate permissions to run the package's installer executable and to access the source files for the installation. And, the installation probably is not very automated, so the process likely would require user intervention to answer prompts such as the destination directory, installation options, and so forth, which is something we all try to avoid when possible. Finally, because the installer isn't granted sweeping administrative privileges during the setup process like an MSI installer is, you might have conflicts and problems to troubleshoot with a mass package deployment.

If the ZAP file method doesn't appeal to you, you can use a repacking tool, such as Veritas WinInstall LE or the InstallShield deployment tools. These tools will take a snapshot of your current system configuration and prompt you to install the software you want to package. Once the installation is complete, these tools will take another snapshot, record what changed on the filesystem and Registry, and prompt you with a list of what it detected. You go through the list, make sure the changes listed were due to installing the software and not to errant behavior on the part of Windows, and then confirm the list. The software will create an MSI with the program's installer and a database of filesystem and Registry changes.

Using this method, you gain the robustness and rollback features of using an MSI installer as opposed to ZAP files. However, the repackaging tools can tend to be a bit flaky, and sometimes you'll have difficulty installing them on multiple platforms. There's not a good way around that, other than obtaining an MSI directly from the software vendor, but it's somewhat of a middle ground between the inflexible ZAP files and a true MSI from the manufacturer.

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide

Windows Server 2008 Domain Group Policy

Domain-based GPs offer a much more flexible and configurable set of standards and settings for your organization than local GPs. In this section, I'll discuss the four most common methods of managing your IT assets centrally using domain GP: configuring a security standard, installing software using the IntelliMirror technology found in Windows Server 2008, redirecting folders present in the user interface to network locations, and writing and launching scripts triggered by events such as logons and logoffs.

Security Settings

As discussed earlier, one of the most useful aspects of GP is its ability to control security settings and configuration from a central location within the organization. Security policy comprises three key components: restricted groups, Registry settings, and filesystem settings. In this section, I'll take a look at each of them.

Restricted groups

The restricted groups option allows you to modify the current group configuration and membership on your client computers. When this policy is applied to workstations and servers, their individual group configurations are modified to match that configured inside the policy. The policy contains members and members of lists that overwrite any configuration on the target computers. For example, if you were to add the Administrator group to the policy but not add any users to the members of this group list, and then you applied the policy, Windows would remove any users currently in those groups on the client computers. However, the other facet of the policy, groups of which the added group is currently a member, is only additive: if the list is empty, no modifications are made to the client computers. Only additions are processed and changed.

Only the groups listed inside the Details window of the Restricted Groups policy branch can be modified using the policy, but it's a great way to keep individual users from modifying powerful groups on their own systems.

To modify the restricted groups policy, do the following:

1. Launch the GPMC, and then right-click on your target GPO in the left pane and select Edit.

2. Inside the Group Policy Object Editor, navigate through Computer Configuration, Policies, Windows Settings, and Security Settings.

3. Right-click the Restricted Group branch and select Add Group from the context menu.

4. Click the Browse button, and select any group currently inside your directory. Click OK.

5. Now, right-click the newly added group, and select Properties from the context menu.

6. Add the users that belong to this group to the "Members of this group" list, and add the groups within which this group is nested to the "This group is a member of" list. Use the Add button in both cases.

7. When you're finished, click OK to close out the boxes.

Filesystem and Registry policy

You also can use GPs to configure permissions on filesystem objects and Registry keys. You can set entries on the ACLs of individual files, folders, and Registry keys from a central location. If you make this change at the domain-wide level—one of the few changes I recommend and endorse at that level—registries are protected against meddling users all over the enterprise, which is definitely a benefit.

To add a Registry key to be protected to a GPO, follow these steps:

1. Launch the GPMC, and then right-click on your target GPO in the left pane and select Edit.

2. Inside the Group Policy Object Editor, navigate through the Computer Configuration, Policies, Windows Settings, Security Settings, and Registry. Right-click Registry and select Add Key from the context menu.

3. You can add one Registry key at a time, and you can selectively apply permissions to each key.

To add a file or folder to be protected to a GPO, follow these steps:

1. Launch the GPMC, and then right-click on your target GPO in the left pane and select Edit.

2. Inside the Group Policy Object Editor, navigate through the Computer Configuration, Policies, Windows Settings, Security Settings, and File System. Right-click File System and select Add File from the context menu.

3. You can explore the entire directory structure, select a file, and then selectively assign permissions to files and folders.

If you select the configure option, you also will need to select how permissions are applied. If you choose to apply inheritable security to this file or folder and to its subfolders, the new permissions are applied to all child objects that do not have a permission or ACL entry explicitly set. This preserves your custom permissions on a tree but also automatically overwrites permissions simply inherited by default. If you choose to replace existing security for this file or folder and its subfolders, you overwrite all permissions on any child folders, including those permissions explicitly set.

If you'd rather not have any of these methods used to apply permissions, simply choose the following option: "Prevent the application of security policies to this file or folder and its subfolders." Doing so will make child files and folders immune to the permissions assigned by this new policy.

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide

Windows Server 2008 Local Group Policy

Now let's examine the two different types of GP, starting with local GP and moving to domain-based GP. Although local policies don't have the flexibility of domain-based GPs, as you will see, they are still a valuable tool for creating a deployable set of standards for computers in your organization. Local policies are most useful for creating a security configuration for either clients or servers that is appropriate for your company. With the Security Templates snap-in, you can create role-based templates that configure most security-related settings on your machines. And with the Security Configuration and Analysis Tool snap-in, you can create a database of roles and policies for your organization's machines.

Security Templates

Microsoft wisely decided to ship Windows with a few predefined security settings files, hereafter referred to as "security templates." These files contain what are essentially recipes for configuring a machine's security policy based on its daily role. These templates, designed to be applied to new Windows installations that already have had a basic template applied, must be used on systems formatted with NTFS, at least on the boot partition (the one containing the operating system files). The incremental security templates are as follows:

For workstations or servers in which users ought to be prevented from being in the Power Users group, apply the compatws.inf template. This template compensates for the lack of additional privileges afforded to members of the Power Users group by relaxing the rights restrictions on the normal Users group. But be careful: you should only use this template if you're dealing with noncertified software (programs that don't have the Windows logo affixed to them) that won't otherwise run.

To further secure workstations or servers, the securews.inf template increases the overall security level of a machine by tightening areas of the OS not under the purvey of rights and restrictions. Areas that are more secure using this template include account policy settings, auditing controls, and Registry keys that are prominent in security policy. The appropriate version of this template for Windows domain controllers is securedc.inf.

For the ultra-paranoid and for those with the most stringent security requirements, the hisecws.inf (and for domain controllers, the hisecdc.inf file) can be used; however, because all network transmissions must be signed and encrypted by Windows machines, this template is appropriate only in pure Windows 2000 or greater environments.

Setup security.inf restores the security settings of a machine to their default, out-of-the-box configuration. Use this if you have made modifications and want to completely reverse them and "wipe the slate clean," as it were.

Rootsec.inf specifies the newer, more secure permissions for the root of the system drive. Most significantly, this removes the full control permissions from Everyone on the system drive. You also can use this template to reapply the more stringent root directory security on systems where the baseline security settings have been modified.

DC security.inf refers to the default security template for domain controllers, which imposes more stringent requirements on network transmissions and secures more portions of the filesystem and Registry. This template is created when a server is promoted to domain controller status.

Iesacls.inf provides a tighter security configuration for Internet Explorer, restricting scripting activity in certain untrusted zones and providing a more stringent, but secure, web browsing atmosphere.

These convenient templates are designed to be used with the Security Templates snap-in. Using the snap-in, you can apply the basic and incremental security templates included with the product, or you can modify the templates to create your own easily distributable templates.

To begin using the Security Templates snap-in, follow this procedure:

1. Run mmc /s from a command line. This loads the MMC in author mode, allowing you to add a snap-in.

2. From the Console menu, select Add/Remove Snap-in. Then select Add. This raises a dialog box entitled Add Standalone Snap-in.

3. From the list, select Security Templates, click Add, and then click Close.

4. Click OK in the next box to confirm the addition of the snap-in.

Now you have the Security Templates snap-in added to a console. From this snap-in, you can expand the Security Templates section in the console tree on the left, and then expand the C:\Windows\security\templates folder to view the predefined security templates discussed earlier.

Creating a Custom Security Template

You might want to make your own customized policy modifications that go above and beyond those made in the templates shipped with Windows. Creating a custom security template affords you an easy way to package, deploy, and apply these modifications with a minimum of administrative headache. Best of all, you can use these templates in conjunction with a utility called the Security Configuration and Analysis Tool to assess the overall "hardness," or state of security, of your machines.

To create your own security template, follow these steps:

1. In the Security Templates console, expand Security Templates in the tree pane on the left, and right-click C:\Windows\security\templates (this is the default templates folder in the system).

2. Select New Template from the context menu that appears.

Now you can make any policy modifications you want in any one of the policy areas supported by the tool: account policies, local policies, the event log, restricted groups, system services, the Registry, and the filesystem. Your additions, deletions, and other changes are saved directly into the template as they are made.

To take this one step further, you might decide to build on the basic policy settings provided by the basic and incremental templates shipped with Windows. In that case, it's quite simple to open the basic or incremental templates, resave to a different name, and make further modifications to create your own custom template. To do so, follow these steps:

1. Select an existing template inside the Security Templates console. In this example, I'll use the securews.inf file.

2. Right-click the existing template, and click Save as ... from the context menu.

3. Give the new template a name.

4. Click OK. The new template is created with the settings from the old basic template.

Compiling the Security Database

The next step is to compile your templates into a security database using the Security Configuration and Analysis (SCA) tool. From within the MMC, add the SCA tool to the console. Then do the following:

1. Right-click Security Configuration and Analysis and select Open Database.

2. From the Open Database dialog, type the name of a new database.

3. Because no database exists with that name, you'll be prompted for the specific security template from which the database should be built. The choices in this box come from the C:\Windows\Security\Templates folder. Choose the template and click OK.

Although you won't get any confirmation from the user interface, the template has been added to the database. Now you can right-click the SCA tool in the left pane and choose either Analyze Computer Now or Configure Computer Now. When you select Analyze Computer Now, the SCA tool looks at the new security configuration within the database, compares it with the current state of the computer, and reports on the differences; the report also is saved to a logfile in \My Documents\Security\Logs. Alternatively, when you select Configure Computer Now, the changes will actually be committed to your system. You want to avoid using that option unless you're absolutely sure you want the results in production without seeing them first.

You also can script the application of templates across multiple computers, using a login script, Telnet server, or some other means, by taking advantage of the SECEDIT utility. SECEDIT takes a template file, adds it to the SCA database, and then applies the security settings to the machine on which SECEDIT is being run. To import a template named Hassell-secure.inf, compile it into SCA into a database called securepcs and overwrite any data already in the database, apply it to the current computer, and create a log for all of these actions named apply.log, for example, issue the following command:

secedit /configure /cfg Hassell-secure.inf /db securepcs /overwrite

/log apply.log

If you've already imported the template into SCA manually, and you just need to apply the settings to a computer, issue the following command:

secedit /configure /db securepcs /overwrite /log apply.log

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide

What is New in IIS 7.0

IIS 7.0 has been re-engineered at its core to deliver a modular and extensible Web server platform, forming the foundation for lean, low-footprint Web servers that power customized workloads and Web applications. The new extensible architecture enables the Web server to be completely customized; you can select only the required IIS features and add or replace them with new Web server features that leverage the new rich extensibility application programming interfaces (APIs). In addition, the Web server enables the use of a new distributed configuration system and management tools that simplify Web server deployment and management. The core feature set of IIS 7.0 continues to leverage the reliability and security-focused architecture established by its predecessor, IIS 6.0, and it adds additional improvements to enhance the reliability and security of the Web server platform. IIS 7.0 also includes extended support for application frameworks, including better integration with ASP.NET and built-in support for FastCGI-compliant application frameworks.

Among its many improvements, IIS 7.0 delivers the following:

Modular Web server architecture. Unlike its monolithic predecessors, IIS 7.0 is a completely modular Web server, containing more than 40 components that the administrator can individually install to create low-footprint, reduced surface-area Web server deployments that play a specific role in the application topology. Furthermore, the new extensibility architecture enables any of the built-in modular features to be replaced with customized implementations that Microsoft and third parties provide.

.NET Extensibility through ASP.NET integration. The new ASP.NET integration capabilities enable you to develop IIS 7.0 features with the power of ASP.NET and the .NET Framework, reducing development and maintenance costs for custom Web server solutions. You can use existing ASP.NET services in this mode to enhance any application technologies, even those that were not developed with ASP.NET in mind. These abilities enable Web applications using IIS 7.0 to further customize the Web server to their needs without incurring the higher development costs associated with the previously used Internet Server Application Programming Interface (ISAPI).

Enhanced application framework support. In addition to improved ASP.NET integration for extending the Web server, IIS 7.0 provides more options for hosting other application frameworks. This includes the built-in support for the FastCGI protocol, a protocol used by many open source application frameworks such as PHP Hypertext Preprocessor (PHP) so that they can be reliably hosted in a Windows environment.

Distributed configuration system with delegation support. IIS 7.0 replaces the centralized metabase configuration store with a new configuration system based on a distributed hierarchy of XML files, which enables applications to control their own configuration. The new configuration system enables simplified application deployment without the overhead of required administrative involvement and provides the foundation for more flexible Web server configuration management.

Improved management tools. IIS 7.0 offers a host of management tools that leverage the new configuration system to provide more flexible and simpler configuration management for the Web server. This includes a brand new task-based IIS Manager tool, which offers remote delegated management; a new tool for command line management (Appcmd); and several APIs for managing Web server configuration from scripts, Windows Management Instrumentation (WMI), and .NET Framework programs.

Enhanced diagnostics and troubleshooting. IIS 7.0 provides diagnostic features to help diagnose Web server errors and troubleshoot hard-to-reproduce conditions with a Failed Request Tracing infrastructure. The diagnostic tracing features are integrated with ASP.NET applications to facilitate end-to-end diagnostics of Web applications.

Windows Server 2008 Refreshing computer policies

Changes to policies can take some time for modifications to propagate across domain controllers within a domain and finally to the objects for which they're destined. Policies are refreshed on a client when the computer is turned on, a user logs on, an application requests a policy refresh, a user requests a policy refresh, or the interval between refreshes has elapsed. The latter part of that sentence is key: there's a GPO you can enable that will allow you to customize the interval at which computer and domain controller policies refresh. It's best to make this change at either a domain or OU level for consistency.

To enable the policy refresh interval, follow these steps (I'll assume you're changing this on a domain-wide basis):

1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane.

2. Right-click on Default Domain Policy, and choose Edit.

3. The Group Policy Object Editor window appears. In the Computer Configuration tree, navigate through Policies, Administrative Templates, and System.

4. Click Group Policy.

5. In the right pane, double-click the setting Group Policy refresh interval for computers, or Group Policy refresh interval for domain controllers, whichever is applicable.

6. Select Enabled, and then enter an interval for the refresh. Be sure to make this a healthy interval; otherwise, you will degrade your network's performance with constant traffic updating policies across the domain. For smaller networks, 15 minutes should be an acceptable timeframe. Allow 30 to 45 minutes for larger networks.

7. Click OK.

You also can also manually force a policy refresh from the command line on client computers with the gpupdate command. To refresh all parts of a policy, issue this command:

gpupdate /force

To refresh just the Computer Configuration node of the policy:

gpupdate /target:computer /force

To refresh just the User Configuration node of the policy:

gpupdate /target:user /force

To manually refresh GPOs on Windows 2000, the syntax is a little different. To refresh only the computer policy:

secedit /refreshpolicy machine_policy

To refresh only the user policy:

secedit /refreshpolicy user_policy

You can force updates of objects, even if they haven't been modified since the last update, by adding the /enforce switch at the end of the command. Then Windows will enforce all policies, regardless of whether the actual policy objects have changed. This is useful if you are having network difficulties and want to ensure that every computer has a fresh application of policy, or if you have a large contingent of mobile users that connect to the network briefly and unpredictably.

For either clients or domain controllers, exercise extreme caution when modifying the default refresh interval. On large networks, altering the refresh interval can cause hellish amounts of traffic to be unleashed over your network—a costly move that's unnecessary for 95% of sites with domains installed. Although clients will pull down new policies only if those policies have changed, the increased traffic results from clients just contacting a domain controller every x minutes to get new policies and updates. There's very little reason to alter this value. Here's a good rule of thumb: if you don't know of a good justification to increase the refresh interval, it isn't necessary for your site.

If you want, you can also elect to disable background policy refreshing completely. You might do this if you're having trouble tracking down an intermittent GPO problem, or if you don't want to have a GP applied during the middle of a client session because it might disrupt an application. Again, it's best to do this on a domain-wide or OU-wide basis for consistency and best performance.

To disable background processing, follow these steps:

1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane.

2. Right-click on Default Domain Policy, and choose Edit.

3. The Group Policy Object Editor screen appears. In the Computer Configuration tree, navigate through Policies, Administrative Templates, and System.

4. Click Group Policy.

5. In the right pane, double-click the setting "Turn off background refresh of Group Policy."

6. Select Enabled.

7. Click OK.

In some situations, you might want a policy setting to be applied, even if no setting has changed. This goes against default GPO behavior because usually, only changes trigger a policy refresh and reapplication. For example, a user might change some Internet Explorer settings within his session. You might want that change to be reversed, but Windows won't trigger a refresh because the policy itself hasn't changed. To prevent this, you can use the configuration option called "Process even if the Group Policy Object has not changed." (This is like the /enforce switch described a bit earlier.) You've probably caught on by now that it's best to do this on a domain-wide or OU-wide basis for consistency and best performance.

To do so, follow these steps:

1. Within the Group Policy Management Console, find the Default Domain Policy in the left pane.

2. Right-click on the Default Domain Policy GPO and choose Edit.

3. In the Computer Configuration tree, navigate through Policies, Administrative Templates, System, and Group Policy.

4. You'll see a list of options ending in "policy processing," such as "Scripts policy processing" and "Wireless policy processing." These GPOs exist to allow you to tweak the functionality of these types of policies. Open the appropriate policy up (which one is best for you depends on the type of policy that you're trying to trigger to change) to view its Properties.

5. Click the Enabled button.

6. Finally, check the "Process even if the Group Policy Object has not changed" checkbox.

Policy settings related to computer security follow a refresh policy that is a bit different from normal GPOs. The client computer still refreshes security policy settings even if the GPO has not been changed or modified. There are Registry settings whose values indicate the maximum acceptable time a user or client computer can wait before reapplying GPOs, regardless of whether they are changed. They are as follows:

To change the refresh interval for computers, set HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTime. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 64,800.

To change the offset interval for computers, set HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeOffset. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 1,440.

To change the domain controller refresh interval, set HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeDC. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 64,800.

To change the domain controller offset interval, set HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTimeOffsetDC. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 1,440.

To change the refresh interval for users, set HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTime. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 64,800.

To change the offset interval for users, set HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\GroupPolicyRefreshTime. The type is REG_DWORD and the valid range for data (in minutes) is 0 to 1,440.

Windows Server 2008 Group Policy Preferences

Windows Server 2008 incorporates a feature called Group Policy Preferences, which is essentially the old products PolicyMaker Standard Edition and Policy Share Manager in new form, directly into the Group Policy Management Console (GPMC). In a nutshell, preferences allow you to "suggest" an initial configuration to your users while still giving them the ability to change them. Let's delve a little deeper into this.

Group Policy itself was designed so that an administrator determines and sets up his mandatory environment, configures it appropriately for the organization's needs, and then leaves it up to Windows to strictly enforce those settings. GP generally overrides any user-provided settings in the event of a conflict, and it typically disables any user interface functions that could be used to change those settings. And while one can limit or otherwise affect the scope of a GPO, it essentially can touch every machine that is a member of any given Windows domain. Machines and settings controlled by Group Policy are termed "managed" machines and settings.

Group Policy preferences take a lighter approach. While GP preferences still are set up by an administrator and filter down to managed clients, GP writes preferences to the same places in the Registry where applications store their data about that specific setting. This lets GP address settings and switches in applications that don't by default know about Group Policy. In addition, there isn't a restriction on the user interface of the software, so if the administrator-defined preferences don't meet a user's working style or in some other way aren't what a user wishes, she is free to change them. You can also define the schedule at which Group Policy refreshes preference information—it can either be done at the same interval that GP refreshes policy (the mandatory settings), or you can set it once and then prohibit Windows from refreshing that preference again.

Supporting Group Policy preferences is also lightweight. You can create GPOs that contain preference information right out of the box. On the client, you'll need to install—via a separate download—a client-side extension; this will need to be deployed to any computer that is a target of your preference settings. The client-side extension will support Windows XP Service Pack 2 and later, Windows Vista, and Windows Server 2003 with Service Pack 1 and later. (If you install Windows Server 2008, you already get the CSE.)

You can create preference entries by right-clicking on the appropriate preference item in the left pane of the Group Policy Management Editor and selecting New from the context menu. The same breakdown for regular GPOs applies for GP preferences: Computer Configuration is used to customize machine-specific settings, which become effective when a computer first boots, and User Configuration is used to configure settings that apply only to that user regardless of where she is on the network.

Windows Server 2008 Group Policy Management Console

You'll find that GPOs themselves are much easier to create and edit using Microsoft's Group Policy Management Console (GPMC), a drop-in replacement for the more limited Group Policy Object Editor that you might know from previous versions of Windows Server. Native Group Policy Object Editor, the tool has limitations: the biggest by far being the lack of ability to see the exact scope of a GPO's application, making troubleshooting very difficult. The GPMC fixes this and also offers a cleaner interface, scripting functionality, and enhancements to troubleshooting and modeling features.

To navigate around in the GPMC, you need to expand the forest you want to manage in the left pane. Then you can select specific domains and sites within that forest, and OUs within individual domains. When you expand, for example, a particular domain, links to the GPOs that exist are listed within their respective OUs. They also are listed under the Group Policy Objects folder. Clicking on a GPO brings up a four-tabbed screen in the right pane.

The first tab is the Scope tab, which examines how far-reaching the effects of this GPO are. Sites, domains, and OUs that are linked to the GPO you've selected are listed at the top of the window. You can change the listing of pertinent links using the drop-down box, where you can choose to list links at the current domain, the entire forest, or all sites. At the bottom of the window, any security filtering done by ACLs is listed. Clicking the Add button brings up the standard permissions window, as you would expect from the Group Policy Object Editor.

At the very bottom, you can see any WMI filters to which this GPO is linked. You can choose to open the WMI filter for editing by clicking the Open button. You can associate only one WMI filter with any particular GPO, and WMI filters work only with Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008. We'll get to these in a bit—for now, let's move on.

The next tab, Details, simply shows the domain in which the current GPO is located, the owner of the GPO, when the GPO was created and modified, the version numbers for the user and computer portions, the GUID of the object, and whether the GPO is fully enabled or fully disabled or whether just the computer or user configuration portions are enabled.

The Settings tab is one of the most useful tabs in the GPMC. The GPMC will generate HTML-based reports of all the settings in a particular GPO, and you can condense and expand portions of the report easily for uncluttered viewing. You can print the report for further reference, or save the report for posting to an internal web site for your IT administrators. It's a much, much easier way to discern which settings a GPO modifies than the Group Policy Object Editor. To edit the GPO that is displayed in the report, simply right-click it and select Edit. To print the HTML report, right-click it and select Print; to save the report, right-click it and select Save Report.

Finally, the Delegation tab lists in a tabular format the users and groups that have specific permissions for the selected GPO, what those permissions are, and whether they're inherited from a parent object. Clicking Add brings up the common Select User, Computer, or Group dialog box that you are familiar with from reading this chapter. You can remove a delegated permission by clicking the appropriate user or group in the list and then clicking the Remove button. The Properties button will bring up the standard Active Directory Users and Computers view of the selected user and group.

Windos Server 2008 Group Policy Implementation

Like NTFS permissions, GPs are cumulative and inherited—cumulative in that the settings modified by a policy can build upon other policies and "amass" configuration changes, and inherited in that objects below other objects in Active Directory can have any GPs that are applied to their parent object be applied to themselves automatically.

GPOs are associated with, or linked, to any number of objects, either within a directory or local to a specific machine. To implement a GP on a specific type of object, follow these guidelines.

Local computer

Use the Local Security Policy snap-in inside Control Panel à Administrative Tools. Or, for a more complete look, use Start à Run à gpedit.msc.

A specific computer

Load the MMC, and then select Add Snap-in from the File menu. Browse in the list and add the Group Policy Object Editor to the console. On the Select Group Policy Object screen, peruse the list to find the specific object you want.

Entire domain

Install and launch the Group Policy Management Console, and then right-click on the domain and create or edit a policy from there.

OU within Active Directory

Install and launch the Group Policy Management Console, right-click on the OU, and create or edit a policy from there.

Active Directory site

Launch Active Directory Sites and Services, right-click the site's name, and select Properties from the context menu. Navigate to the Group Policy tab, and create or edit a policy from there.

Windows applies GPs in the following order, which you can remember with the acronym of "LSDOU":

Local GPOs

Site-specific GPOs, in an order which the site administrator configures

Domain-specific GPOs, in an order which the domain administrator configures

OU-specific GPOs, from the parent OU down through the ranks to the child OU

The only exception to this rule occurs when you're using NT 4.0 system policies that are created and set with the NT System Policy Editor. Recall from NT administration days that the system policies are called NTCONFIG.POL, so if Windows finds that file present, it applies these policies before the local GPO. Of course, these policies can be overwritten by policies that come farther down in the application chain.

Windows Server 2008 Group Policy and IntelliMirror

Windows Server 2008 offers a marvelous command and control system for your organization's computers called Group Policy (GP). With GP, you can manage user- and computer-based configurations, which you can apply en masse to computers in a particular Active Directory site, OU, or domain.

An Introduction to Group Policy

Group policies consist of five distinct components:

Administrative templates

Configure Registry-based policies.

Folder redirection

Alters the target location of various elements in the UI, such as My Documents, to other places on the network.

Scripts

Execute when computers are first booted and shut down. They also can run during user logon and logoff.

Security settings

Configure permissions, rights, and restrictions for computers, domains, and users.

Software policies

Assign application packages to users and computers.

The data for each component is stored in a Group Policy Object (GPO). In domain-based GPs, GPOs are stored at various levels in Active Directory, but they're always associated with a domain. GPOs are affiliated with a variety of objects within Active Directory, including sites, domains, domain controllers, and OUs, and they can be linked to multiple sites, to the domains themselves, and to OUs. For non-domain-based (i.e., local) GPs, you simply configure those settings on individual servers.

Local computer policies are stored in the %SystemRoot%\System32\GroupPolicy directory because they apply only to the computer on which they're stored and they need not be replicated. Local policies are also more limited in scope and ability, as you'll see later in this chapter.

When you first set up an Active Directory domain, two default GPOs are created: one that is linked to the domain itself, and therefore affects all users and computers within the domain; and one that is linked to the Domain Controllers OU, which affects all domain controllers within a domain.

*.* Source of Information : O'Reilly Windows Server 2008: The Definitive Guide

Using ASP.NET Applications with IIS 7.0

When you are working with ASP.NET, it is important to consider the managed pipeline mode you will use. IIS 7.0 supports two modes for processing requests to ASP.NET applications:

Classic

Integrated

Classic pipeline mode, is the standard processing mode used with IIS 6.0. If a managed Web application runs in an application pool with classic mode, IIS processes the requests in an application pool by using separate processing pipelines for IIS and ISAPI. This means that requests for ASP.NET applications are processed in multiple stages like this:

The incoming HTTP request is received through the IIS core.

The request is processed through ISAPI.

The request is processed through ASP.NET.

The request passes back through ISAPI.

The request passes back through the IIS core where the HTTP response finally is delivered.

Integrated pipeline mode, is a dynamic processing mode that can be used with IIS 7.0. If a managed Web application runs in an application pool with integrated mode, IIS processes the requests in an application pool by using an integrated processing pipeline for IIS and ASP.NET. This means that requests for ASP.NET applications are processed directly like this:

The incoming HTTP request is received through the IIS core and ASP.NET.

The appropriate handler executes the request and delivers the HTTP response.

From an administrator perspective, applications running in classic pipeline mode can appear to be less responsive than their integrated counterparts. From an application developer perspective, classic pipeline mode has two key limitations. First, services provided by ASP.NET modules and applications are not available to non-ASP.NET requests. Second, ASP.NET modules are unable to affect certain parts of IIS request processing that occurred before and after the ASP.NET execution path.

With an integrated pipeline, all native IIS modules and managed modules can process incoming requests at any stage. This enables services provided by managed modules to be used for requests to pages created using static content, ASP.NET, PHP, and more. Direct integration makes it possible for developers to write custom authentication modules, to create modules that modify request headers before other components process the request, and more.

When working with the integrated pipeline mode, it is important to keep in mind that in this mode ASP.NET does not rely on the ISAPI or ISAPI Extension modules. Because of this, the running of an integrated ASP.NET application is not affected by the ISAPI CGI restriction list. The ISAPI CGI restriction list applies only to ISAPI and CGI applications (which includes ASP.NET classic applications). For integrated mode to work properly, you must specify handler mappings for all custom file types.

Further, many applications written for classic pipeline mode will need to be migrated to run properly in integrated pipeline mode. The good news is that the Configuration Validation module, included as a part of the server core, can automatically detect an application that requires migration and return an error message stating that the application must be migrated. You can migrate applications by using Appcmd.exe (general-purpose IIS command-line administration tool). Any migration error reported by IIS typically contains the necessary command for migrating the application. To use this command to migrate an application automatically, right-click the command-prompt icon and choose Run As Administrator. You then can migrate an application manually by running the following command at the elevated command prompt:

appcmd migrate config AppPath

where AppPath is the virtual path of the application. The virtual path contains the name of the associated Web site and application. For example, if an application named SalesApp was configured on the Default Web Site and needed to be migrated, you could do this by running the following command:

appcmd migrate config "Default Web Site/SalesApp"

When AppCmd finishes migrating the application, the application will run in both classic and integrated modes.

Real World

Although IIS notifies you initially about applications that you need to migrate, IIS will not notify you about migration problems if you subsequently change the application code so that it uses a configuration that is not compatible with integrated mode. In this case, you may find that the application doesn't run or doesn't work as expected, and you'll need to migrate the application manually from a command prompt. If you don't want to see migration error messages, modify the validation element in the application's Web.config file so that its validateIntegratedModeConfiguration attribute is set to false, such as:

*.* Source of Information : Microsoft Press Internet Information Services (IIS) 7.0 Administrator's Pocket Consultant

Using IIS 7.0 Applications

You can configure Web sites to run several different types of applications, including:

Common Gateway Interface (CGI) programs.

Internet Server Application Programming Interface (ISAPI) applications.

ASP.NET applications using managed code.

CGI describes how programs specified in Web addresses, also known as gateway scripts, pass information to Web servers. Gateway scripts pass information to servers through environment variables that capture user input in forms in addition to information about users submitting information. In IIS 7.0, standard CGI is implemented through the CgiModule and multi-threaded CGI is implemented through the FastCgiModule. The CgiModule has a managed handler that specifies that all files with the .exe extension are to be handled as CGI programs.

The way CGI programs are handled is determined by the way you've configured the CGI feature within IIS. By default, CGI is disabled. When you enable CGI, the CgiModule is the default handler for .exe programs. You can modify the handler configuration for .exe programs to use the FastCgiModule. This configuration is useful if you've installed the PHP Hypertext Preprocessor (PHP) on your IIS server and want to use it. Once you've configured the server to use FastCgi for .exe programs, you should add handler mappings for PHP-related file extensions and configure these mappings so that they use the PHP executable, such as Php-cgi.exe. For example, you could add mappings for *.php and *.php5. Your IIS server would then process files with the .PHP and .PHP5 extensions through Php-cgi.exe.

In IIS 7.0, ISAPI is implemented using two modules, IsapiModule and IsapiFilterModule. The IsapiModule makes it possible to use ISAPI applications and ISAPI extensions. In the IIS server core, several components rely on handlers that are based on ISAPI extensions, including ASP and ASP.NET. The IsapiModule has a managed handler that specifies that all files with the .dll extension are to be handled as ISAPI extensions. If you remove this module, ISAPI extensions mapped as handlers or explicitly called as ISAPI extensions won't work anymore.

IIS uses ISAPI filters to provide additional functionality. If you selected ASP.NET during initial configuration, an ASP.NET filter is configured to provide classic functionality through aspnet_filter.dll, an ISAPI filter. For classic ASP.NET functionality, each version of ASP.NET installed on a Web server must have a filter definition that identifies the version and path to the related filter. After you install new versions of ASP.NET, you can add definitions for the related filter.

ISAPI and CGI restrictions control the allowed ISAPI and CGI functionality on a server. When you want to use an ISAPI or CGI application, you must specifically allow the related DLL or EXE to run.

*.* Source of Information : Microsoft Press Internet Information Services (IIS) 7.0 Administrator's Pocket Consultant

IIS 7.0 Worker Process Isolation Mode

Worker Process isolation mode is the standard processing mode for Web sites and Web applications. This mode allows sites and applications to:

Recycle worker threads

Monitor process health

Use advanced application pooling configurations

Take advantage of other IIS 7.0 features

The World Wide Web Publishing Service and Windows Process Activation Service provide the essential services for IIS 7.0. Service Host processes control all Web resources running on a server. Starting, pausing, or stopping the World Wide Web Publishing Service affects all Web sites on the server. It doesn't directly affect the Service Host. Instead, Windows Server uses an intermediary to control the Service Host for you. For non-Web services, this intermediary is the Inetmgr.exe process. A single instance of Inetmgr.exe is used to manage Web sites and Web applications.

Management of the Web service and Web applications is internalized. The Web Administration Service component of the Web Service Host is used to manage the service itself. Worker processes are used to control applications, and no ISAPI applications run within the IIS process context.

Worker processes are used in several ways:

Single worker process—single application Here a single worker process running in its own context (isolated) handles requests for a single application as well as instances of any ISAPI extensions and filters the application's need. The application is the only one assigned to the related application pool.

Single worker process—multiple applications Here, a single worker process running in its own context (isolated) handles requests for multiple applications assigned to the same application pool as well as instances of any ISAPI extensions and filters the applications' needs.

Multiple worker processes—single application Here, multiple worker processes running in their own context (isolated) share responsibility for handling requests for a single application as well as instances of any ISAPI extensions and filters the application's needs. The application is the only one in the related application pool.

Multiple worker processes—multiple applications Here, multiple worker processes running in their own context (isolated) share responsibility for handling requests for multiple applications assigned to the same application pool as well as instances of any ISAPI extensions and filters the applications' needs.

The standard operating mode ensures that all sites run within an application context and have an associated application pool. The default application pool is DefaultAppPool. You can also assign sites and applications to custom application pools.

Each application or site in an application pool can have one or more worker processes associated with it. The worker processes handle requests for the site or application.

You can configure application pools to manage worker processes in many ways. You can configure automatic recycling of worker threads based on a set of criteria such as when the process has been running for a certain amount of time or uses a specific amount of memory. You can also have IIS monitor the health of worker threads and take actions to recover automatically from failure. These features might eliminate or reduce your dependence on third-party monitoring tools or services.

You can also create a Web garden in which you configure multiple worker processes to handle the workload. Applications configured using this technique are more responsive, more scalable, and less prone to failure. Why? A Hypertext Transfer Protocol (HTTP) listener, called Http.sys, listens for incoming requests and places them in the appropriate application pool request queue. When a request is placed in the queue, an available worker process assigned to the application can take the request and begin processing it. Idle worker processes handle requests in first-in, first-out (FIFO) order.

Worker processes can also be started on demand. If there are unallocated worker processes and no current idle worker processes, IIS can start a new worker process to handle the request. In this way, resources aren't allocated until they're needed, and IIS can handle many more sites than it could if all processes were allocated on startup.

*.* Source of Information : Microsoft Press Internet Information Services (IIS) 7.0 Administrator's Pocket Consultant