Showing posts with label Microsoft Xp. Show all posts
Proxying requests to the published site using ISA Server or Threat Management Gateway
In ISA Server 2004\2006 or Forefront Threat Management Gateway 2010 the “Proxy requests to published site” setting is one of the most confusing yet simple configuration options when publishing a server.
When you publish a website using the website publishing rule feature the default setting is to select the “Requests appear to come from the Forefront TMG computer” radio button available in the To tab of the website publishing rule’s properties dialog box. This is what I would call the “safe” option but as we’ll find out not necessarily the correct option for your environment (see image below):
Note: The default setting for publishing non-web server publishing rules is set to “Requests appear to come from the original client.” More on this specific setting at the end of this article.
With the setting “Requests appear to come from the Forefront TMG computer,” the logic is as follows:
The request comes into TMG and TMG sends it back to the web server. When TMG does this it changes the “Source IP” address field in the IP Header to its Internal adapter IP address. When the web server sees this request (assume it’s on the same logical segment as TMG), it sees the source IP is TMG. The web server then checks its routing table and says “This address is directly accessible to me. All I have to do is ARP for this IP and if I get a ARP response, I’ll deliver it directly to that host.” The response is complete as far as the web server is concerned.
Now, with the setting “Requests appear to come from the original client,” the logic goes like this:
The request comes into TMG and TMG sends it back to the web server. When TMG does this it leaves the “Source IP” address field in the IP Header alone (i.e. the external client’s IP is maintained.) When the web server sees this request (assume it’s on the same logical segment as TMG) it sees the Source IP as someone on the Internet. The web server then checks it’s routing table and says “This address isn’t directly accessible to me. My routing table says that if I don’t have a more specific route I’ll just punt and send it to my default gateway. Let me ARP for the gateway and if I get a response, I’ll deliver it to that system”. The request is now done as far as the web server is concerned.
You can see this behavior by opening a command prompt and typing “netstat -ano” without the quotes. This command displays your current network connections. You will be able to see the internal TMG source IP address or the client source IP address depending on the setting you have in TMG.
With the setting for “Requests appear to come from original client” it is essential that the return path for the responses from the web server honor the incoming path of the request. In other words, if the request came in from TMG and this setting is enabled, then the response has to go out through TMG as well. In other words, if you select the option “Requests appear to come from the original client” you must have the web server’s default gateway set to the TMG’s internal IP address! This begs the question as to why can’t TMG’s response go out some other device for the response such as another internal router? There are two reasons for this:
1) If the other device is capable of stateful inspection, it will not have any state for the response from the web server since the original packet came in through TMG.
2) Even if that device doesn’t perform stateful inspection it most likley does NAT. As the response goes through that other device, the Source IP will get changed to the NAT device’s IP and by the time the original client gets the response, the Source IP is not who the client sent it’s request to and it will drop the response.
They say a picture is worth a thousand words and in this case a graphical representation of what is going on helps. Below are four graphs depicting the four possible scenarios.
Scenario 1: Requests appear to come from the TMG computer. Default Gateway is TMG :
The below graph shows a client request traversing through TMG with the default setting of “Requests appear to come from the Forefront TMG computer.” The default gateway of the web server is set to TMG. This configuration will work but the downside to this configuration is that the web log files will only contain the IP address of the TMG’s internal interface obfuscating the true source of the request. This is a surefire way to infuriate the marketing folks, which for some of you may actually be an enjoyable thing to do. This scenario is a safe option but totally unnecessary in my opinion. If the Web server’s default gateway is set to the TMG server then there is no reason to have the requests appear to come from the Forefront TMG computer unless you want to purposely obfuscate the IP addresses in the web log files.
Scenario 2: Requests appear to come from the TMG computer. Default Gateway is a router.
The below graph shows a client request traversing through TMG with the default setting of “Requests appear to come from the Forefront TMG computer.” The default gateway of the web server is set to another router. This configuration will work but you have the same downside to this configuration as scenario 1 in that the web log files will only contain the IP address of the TMG’s internal interface. You will typically encounter this scenario in larger enterprises where they likely have a more complex routing infrastructure and they want the TMG server’s default gateway set to a router for policy reasons.
Scenario 3: Requests appear to come from the original client. Default Gateway is TMG.
The below graph shows a client request traversing through TMG with the setting of “Requests appear to come from the original client.” The default gateway of the web server is set to TMG. This is the most common scenario and the one that I use almost exclusively. This configuration will work and the web log files will contain the client’s Source IP address. I can hear the marketing folks jumping for joy.
Scenario 4: Requests appear to come from the original client. Default Gateway is a router.
The below graph shows a client request traversing through TMG with the setting of “Requests appear to come from the original client.” The default gateway of the web server is set to a router. I’ve saved the worst scenario for last because this is the scenario where people get into trouble. This scenario will not work because the client’s source IP address is maintained all the way to the TMG server but the TMG server forwards its response out through its default gateway breaking the chain of communication.
The question then becomes how can you maintain the client’s Source IP address in the web logs in this scenario? The only solution that I found is by using Microsoft’s ARR (Application Request Routing) proxy-based routing module. This appears to only work with IIS 7 though.
At the beginning of this article I briefly mentioned that the default setting for publishing non-web server protocol publishing rules is for the request to appear from the original client. So, the question then becomes why is this default setting different from publishing standard website publishing rule? I came across a possible scenario which may explain the reason. When publishing the latest version of a Microsoft CRM website you must use HTTPS. Microsoft CRM uses forms-based (or claims-based) authentication so that you log in using a secure form to gain access to your CRM website. What if you want to securely publish CRM for multiple companies using a wildcard SSL certificate? You would purchase a wildcard SSL certificate (i.e. *.example.com) and then you would create a non-web server protocol publishing rule in TMG using the HTTPS protocol. This wildcard SSL certificate then allows you to host CRM for multiple companies such as company1.example.com, company2.example.com and so on using a single HTTPS web listener. Microsoft CRM has intelligence built into the form whereby it inspects the URL that you are sending it and then depending on the URL it will forward you to the proper CRM database on the back end. This behavior only appears to function properly when you have the HTTPS rule set to have requests appear to come from the original client. If you have the other setting applied where the TMG server replaces your source IP with its IP address you will no longer get a form to sign on with but instead you will be presented with a pop-up window to logon to the domain.
Tag :
Microsoft Xp
Diagnose boot problems in Windows XP using MSCONFIG
Diagnose boot problems in Windows XP using MSCONFIG
Among all the wizards and utilities in Microsoft Windows XP is one great utility that has its roots in the Windows 9.x product line: the System Configuration Utility, or MSCONFIG. This handy utility allows you to make changes to boot files and startup parameters when troubleshooting boot problems. I’ll teach you all about the features included with MSCONFIG so you can eradicate pesky boot problems from a Windows XP workstation.
Launching MSCONFIG
To use MSCONFIG, click the Start button and select Run. In the Open box, type MSCONFIG and click OK. The utility will open, as illustrated in image 1.
Image 1
You must be logged on to the computer using an Administrator account before you can run MSCONFIG.
The MSCONFIG window contains six tabs: General, SYSTEM.INI, WIN.INI, BOOT.INI, Services, and Startup. We’ll take a closer look at each of these tabs in the following sections.
The General tab
The MSCONFIG General tab gives you some basic options for starting a computer. As shown in Figure A, the default setting for the utility is Normal Startup. The other two options for starting the computer are Diagnostic Startup and Selective Startup.
Diagnostic Startup allows you to start the computer with only the most basic devices and services that are needed for the computer to run. This startup gives you a clean environment for troubleshooting.
Selective Startup provides a variety of startup options that you can use for troubleshooting. By default, all the options under Selective Startup are chosen. However, deselecting one of these preselected options allows you to prevent one or more of the Selective Startup options from running.
For instance, if you think one of the programs that launch on startup is causing a problem, you can deselect the Load Startup Items option to prevent any startup program from launching. While this won’t help you determine which program is causing the problem, it will help you isolate the problem to a certain area. Please note that you’re unable to select the Use Modified BOOT.INI file unless you make a change on the BOOT.INI tab, which I’ll discuss later.
Finally, the Launch System Restore button provides easy access to the System Restore function, and the Expand File button is a very useful feature if you encounter a corrupted file and want to restore it.
The SYSTEM.INI and WIN.INI tabs
The SYSTEM.INI and WIN.INI tabs are included for legacy compatibility, and you may not need to use them very often. These tabs give you the ability to modify the SYSTEM.INI and WIN.INI files or prevent lines of code from executing when the computer is started.
In Image 2, each line of the SYSTEM.INI file is displayed in the window. Sections of the file, such as drivers, are expandable to allow you to work with the lines of code in those sections. You can also deselect a section to prevent the entire section from being executed.
Image 2
Deselect a section to prevent the entire section from being executed.
The Move Up and Move Down buttons allow you to move lines or sections to other locations in the file. The Find button is used to search the file; the New button lets you add new lines; and Edit lets you change the value of a line. The Enable All and Disable All buttons at the bottom of the window will select or deselect all the lines of the program. Using these buttons to alter these files is much easier and safer than using a text editor to perform the same tasks.
As you can see in Image 3, the WIN.INI tab provides the same functionality as the SYSTEM.INI tab.
Image 3
Same as before, select and deselect.
Boot options using the BOOT.INI tab
The BOOT.INI tab, shown in Image 4, gives you many options for starting the computer. The top portion of the window contains the BOOT.INI file that the computer is currently using. You cannot edit this file using MSCONFIG. You can change the timeout value for the boot menu. Even if you can’t edit the file, it is easy to view the file when you use MSCONFIG.
Image 4
Microsoft recommends that you don’t attempt to use MSCONFIG to edit BOOT.INI unless you’re directed to do so by a Microsoft support professional.
Three of the four buttons provided in this window are for editing purposes and are grayed out by default. The Check All Boot Paths button is used to verify that the boot paths in the BOOT.INI file are correct. When you click this button, you’ll receive either an error message you can use for troubleshooting or a window alerting you that the boot paths have been verified.
Boot option pane
The most valuable functions on the BOOT.INI tab are the boot options, which are explained below. You can use these choices for a variety of troubleshooting techniques:
The BOOT.INI Advanced Options screen, shown in Image 5, offers you more options for starting your computer:
Image 5
These are the advanced options.
Working with the Services tab
The MSCONFIG Services tab, shown in Image 6, allows you to prevent specific services from starting when the computer is started. This is extremely useful when you’re troubleshooting service-related problems.
Image 6
Microsoft has designed the majority of services in Windows XP. To make it easier to find a non-Microsoft service, you can select the Hide All Microsoft Services option.
Troubleshooting using the Startup tab
The Startup tab lets you prevent items in your startup folder from starting when you log in. As you can see in Image 7, you can simply deselect the service to prevent it from starting. If you want to disable all the services, click the Disable All button. To enable all the services again, click the Enable All button.
Image 7
These are the startup choices.
My favorite feature
The System Configuration Utility is easy to use and will help you troubleshoot a wide variety of Windows XP boot problems. The ease with which you can temporarily modify the boot files, system services, and startup files makes MSCONFIG an extremely useful troubleshooting utility. The best troubleshooting features I have found are the boot options located within the BOOT.INI tab. Remember to use caution when manipulating boot option parameters and always write down any changes you make in case you get stuck.
Diagnose and Repair an Unbootable XP or Vista PC
Diagnose and Repair an Unbootable XP or Vista PC
How do I prepare an emergency boot disc so I'm ready in case Windows becomes unbootable?
Paul Lopez, Allentown, Pennsylvania
Alas, the days when Windows came with a program for creating a useful emergency boot floppy are long gone. And those old boot floppies wouldn't help with XP or Vista--even if you PC had a floppy drive.
Boot from one of the discs that came with your PC, and examine the menus (don't select anything that might wipe your drive). You're looking for emergency utilities.
You're in real luck if you have a full Windows XP CD or Vista DVD. These come with great tools for diagnosing and repairing an unbootable PC. In fact, if you don't have a real Windows disc, find one you can borrow in an emergency. Don't install Windows from a borrowed disc, but if it has the same version of Windows as your PC, use its repair tools.
Boot from an XP CD, and press
R at the 'Welcome to Setup' screen to see the Recovery Console, a DOS-like command-line environment with a number of useful utilities. Consult "What to Do When XP or 2000 Won't Boot" for additional details.If you boot from a Vista DVD, click Repair your computer to open the System Recover program. There you'll find options to automatically fix boot problems, restore your hard drive from an image backup, diagnose memory, or perform a system restore.
If you're ready for a Windows alternative, try Puppy Linux, which you can download as a ready-to-burn .iso file from the Puppy Linux Web site. Boot from the CD, and you'll have a nongeek's version of Linux running on your PC. Puppy Linux is the best tool I've found for one extremely important job: copying important files off an unbootable hard drive. Unlike UBCD4Win, Puppy recognizes USB drives, making it extremely easy to put these files where you can readily access them.
The XP CD's Boot Tool Kit
Enter these commands in Windows XP's Recovery Console to perform CPR on your disks and files.
| Command | Action |
| Attrib | Changes the attributes of a file or directory. |
| Batch | Executes the commands specified in the text file. |
| Bootcfg | Boot file (boot.ini) configuration and recovery. |
| ChDir (Cd) | Displays the name of the current directory or changes the current directory. |
| Chkdsk | Checks a disk and displays a status report. |
| Cls | Clears the screen. |
| Copy | Copies a single file to another location. |
| Delete (Del) | Deletes one or more files. |
| Dir | Displays a list of files and subdirectories in a directory. |
| Disable | Disables a system service or a device driver. |
| Diskpart | Manages partitions on your hard drives. |
| Enable | Starts or enables a system service or a device driver. |
| Exit | Exits the Recovery Console and restarts your computer. |
| Expand | Extracts a file from a compressed file. |
| Extract | Extracts files from compressed .cab archives. |
| Fixboot | Writes a new partition boot sector onto the specified partition. |
| Fixmbr | Repairs the master boot record of the specified disk. |
| Format | Formats a disk. |
| Help | Displays a list of commands you can use in the Recovery Console. |
| Listsvc | Lists the services and drivers available on the computer. |
| Logon | Logs on to a Windows installation. |
| Map | Displays the drive letter mappings. |
| Mkdir (Md) | Creates a directory. |
| More | Displays a text file. |
| Net Use | Connects a network share to a drive letter. |
| Rename (Ren) | Renames a single file. |
| Rmdir (Rd) | Deletes a directory. |
| Set | Displays and sets environment variables. |
| Systemroot | Sets the current directory to the systemroot directory of the system you are currently logged on to. |
| Type | Displays a text file. |