In the first scenario, Forefront Client Security will be manually installed on a Web Server that is located on the perimeter network. This client will not report to the internal FCS deployment, therefore the status of this computer will not be available on the Forefront Client Security report.

Figure 1 – Topology for Scenario 1.

This topology is using ISA Server 2006 Enterprise Edition as a firewall with the 3 Legs Template applied on it. The route relationship between the internal network and perimeter network is defined as route.

There are advantages and disadvantages in using the topology suggested on this scenario. The list below summarizes them:

• Advantages
  
  • Isolation: no need to open additional ports on the firewall in order to allow communication between the Web Server on the perimeter network to the Forefront Servers.
    
  • Independent management: with this scenario, you can customize individually what the Forefront Client Security should scan and what it should not.
    
• Disadvantages
  
  • Administrative overhead: if you have multiple servers on the perimeter network, each server will have to be individually configured to use Microsoft Update as source for definition and engine updates.
    
  • Client deployment: considering that you have multiple servers on the perimeter network, you will need to go physically one by one in order to perform the installation.
    
  • Reporting: the Forefront Client Security Reporting will not be available; therefore, it will be necessary to look individually on each Server located on the perimeter network in order to make sure that it is getting the updates and that it is detecting and addressing malware threats.
    

The first step is to install the Forefront Client Security client on the Web Server. To do that, you should follow the steps in “Deploying manually to each client computer” in the Microsoft Forefront Client Security Deployment Guide on Microsoft TechNet. On step five in the article above, you need to make sure that you will use the parameter /NOMOM. This parameter installs everything except the MOM agent.

After the installation finishes, you should see the screen below:

Figure 2 – Forefront Client Security right after finishing the installation.

Since this Web Server is not a domain-joined server, we can’t rely on the internal group policy that is being deployed to allow that to occur automatically. You need to make the changes locally on this server in order to configure the automatic update. To do that, follow the steps in the article Update and Configure Automatic Updates.

The ISA Server 2006 configuration for this scenario will be simple. It is important to emphasize that this article is assuming that ISA Server 2006 is already configured to allow the servers and workstation that are located on the internal network to access the necessary resources on the Internet.

To allow the Web Server that is located on the perimeter network to access the Microsoft Windows® Update Web site, it will be necessary to create only one access rule. The following two tasks will be done:

• Create a computer set: this computer set will be created to have all servers that are located on the perimeter network.
  
• Create an access rule: the access rule will be created where the source is the computer set that contains the servers located on the perimeter network and the destination is the Internet.
  

Follow the steps described on the article You experience problems when you access the Windows Update Version 5 or Version 6 Web site through a server that is running ISA Server on Microsoft Help and Support to configure that. However, make sure that during the access rule creation you choose the source as the computer set that was previously created and the destination is the Microsoft Update Domain Name Set.

After installing the Forefront Client Security on the Web Server and creating the access rule on ISA Server 2006, there are some steps that you can use to validate the configuration and make sure that it is working.

The first test to do is to make sure that Forefront Client Security is correctly installed. To validate that, you can review the Forefront Client Security installation log. This log is located by default in Program Files\Microsoft Forefront\Client Security\Client\Logs\clientsetup.log. In this file you should see an entry like this if the installation occurred successfully:

Figure 3 – Log file showing that the installation was completed successfully.

After validate that you need to make sure that the client is getting the definition and engine updates. First thing that you can do is to open the Forefront Client Security console and check the bottom part of the window. The client will try to get the updates right after the installation, and if it fails, the icon on the taskbar will show an orange exclamation mark. It is important to emphasize that there is a known issue described in KB938054 that needs to be installed to avoid issues on the updates for Forefront Client Security.

For more troubleshooting tips on Forefront Client Security, follow the recommendations of the article “Definitions issues” on Microsoft TechNet.

In this scenario, we need to make sure that the Web Server is able to reach the Windows Update Site and get the latest updates. For troubleshooting Automatic Updates, the recommendation is to follow the article “Issues with Client Self-Update” on Microsoft TechNet.

This topology is a variation of the previous scenario; the only difference is that we are leveraging the internal Windows Server® Update Services (WSUS) server as a mechanism to update the servers located on the perimeter network, as show the figure below:

Figure 4 - Topology for Scenario 2.

As in the previous scenario, this topology also has advantages and disadvantages. The list below summarizes them:

• Advantages
  
  • Centralized control of the updates: for an environment that needs to have managed updates controlled from a centralized server, this scenario allows that. There are situations where the IT department needs to evaluate the updates before allowing the installation, and this topology allows that.
    
  • Independent management: as in the previous scenario, this one also allows individual customization of Forefront Client Security and determines on each server what should be scanned and what should not.
    
• Disadvantages
  
  • Client deployment: considering that you have multiple servers on the perimeter network, you will need to go physically one by one in order to perform the installation.
    
  • Reporting: the Forefront Client Security Reporting will not be available; therefore, it will be necessary to look individually on each Server located on the perimeter network in order to make sure that it is getting the updates and that it’s detecting and addressing malware threats.
    

To install Forefront Client Security on the Web Server, follow the steps in “Deploying manually to each client computer” in the Microsoft Forefront Client Security Deployment Guide, on Microsoft TechNet.

On step five in the article above, you need to make sure that you will use the parameter /NOMOM. This parameter installs everything except the MOM agent.

Since this Web Server is not a domain-joined server, we can’t rely on the internal group policy that is being deployed to configure the Automatic Update client. Follow the steps in “Configuring Automatic Updates” on TechNet. Make sure that the web server can resolve the name of the WSUS server that you specify on the specify intranet microsoft update service location option. You can follow one of the options below to allow that:

• Use the internal DNS Server: you can configure the servers located on the perimeter network to use the internal DNS Server. To do that, you also need to create an access rule on ISA Server 2006 in order to allow communication between the internal DNS Server and the servers located on the perimeter network.
  
• Static Mapping: you can add one entry on the host file for the server located on the perimeter network in order to manually map the internal IP of the WSUS server to the name that you will use on that policy.
  

For this scenario, we will use the second option, which prevents to create a new rule on the ISA Server to allow the DNS traffic to pass through.

To allow the Web Server that is located on the perimeter network to access the internal WSUS server, it will only be necessary to create one access rule. The following three tasks will be done for this scenario:

• Create a computer set: this computer set will be created to have all servers that are located on the perimeter network.
  
• Create a computer: this computer will represent the internal WSUS server.
  
• Create an access rule: the access rule will be created where the source is the computer set that contains the servers located on the perimeter network and the destination is the computer object that represents the internal WSUS server.
  

From the ISA Server Management console, follow the steps below to create this access rule:

1. Expand the Arrays, right click on the Firewall Policy, point to New and choose the option Access Rule.

2. On the New Access Rule window, type the name to identify this access rule. In this case, type Web Server DMZ to WSUS Internal. After that, click in Next.

3. On the Rule Action page, choose the option Allow and click Next.

4. On the Protocols page, click on the Add button and add only the HTTP protocol. After add, click in Next.

5. On the Access Rule Sources page, click on the Add button and choose the Computer Set that has the servers that are allowed to communicate with the internal WSUS server. After adding it, click in Next.

6. On the Access Rule Destinations page, click on the Add button and choose the Computer object that represents the internal WSUS server. After adding it, click in Next.

7. On the User Set page, leave the default option (All Users) and click in Next.

8. Click in Finish on the Completing the New Access Rule Wizard page and then Apply the changes.

After installing the Forefront Client Security client on the Web Server and creating the access rule on ISA Server 2006, there are some steps that you can use to validate the configuration and make sure that it is working.

The first test to do is to make sure that the Forefront Client Security is correctly installed. To validate that, you caneview the Forefront Client Security installation log. This log is located by default in Program Files\Microsoft Forefront\Client Security\Client\Logs\clientsetup.log. On this file, you should see an entry like this if the installation occurred successfully:

Figure 5 – Log file showing that the installation was completed successfully.

After validating that, you need to make sure that the client is getting the definition and engine updates. The first thing that you can do is to open the Forefront Client Security client UI and check the bottom part of the window. The client will try to get the updates right after the installation, and if it fails, the icon on the taskbar will show an orange exclamation mark.

For more troubleshooting tips on the Forefront Client Security, follow the recommendations in the article “Definitions issues” on Microsoft TechNet.

In this scenario, we need to make sure that the Web Server is able to reach the internal WSUS server and get the latest updates. For troubleshooting Automatic Updates, the recommendation is to follow the article “Issues with Client Self-Update” on Microsoft TechNet.

On the ISA Server side, you can use the Monitoring Tab, change the source IP address to match the Web Server’s IP address, and follow the frames that are passing through. This will give you more information about what traffic is being allowed and what rule is allowing it.

For a more detailed explanation of how to use the Diagnostic Logging capability on ISA Server, check the blog post “Diagnostic Improvements in ISA Server 2004 Service Pack 3” on ISA Server Team Blog. The logging features available on ISA Server 2004 SP3 are also available on ISA Server 2006 Supportability Update.

This topology is completely different from the others described in this article because another domain will be implemented on the perimeter network. This will allow use of the full set of capabilities that Forefront Client Security has to offer.

Figure 6 – Topology for Scenario 4.

The Forefront Client Security server that is going to be used on the perimeter network is using the one-server topology. Since the amount of computers located on the perimeter network is usually small, this topology should address all the needs.

Although this scenario will allow the use of more features of the product, as the others, there are advantages and disadvantages to using it:

• Advantages
  
  • Reporting features: this scenario will allow the administrator to use the reporting capabilities offered by Forefront Client Security. This helps the administration and maintenance of the computers located on the perimeter network.
    
  • Centralize the deployment policies for computers on the perimeter network: the computers located on the perimeter network have different needs when compared to computers located on the internal network. With this topology, it will be possible to align those needs at the same time that it is possible to take advantages of the deployment policies by using Active Directory® group policy.
    
  • Centralize the updates: as you can see on the diagram, the Distribution Server located on the perimeter network is getting updates from the internal Distribution Server. In the WSUS topology, this is called Mirror Update.
    
  • Automatic installation: Forefront Client Security will be automatically installed on the computers located on the perimeter network.
    
• Disadvantages
  
  • Add a new domain to the perimeter network: in this scenario, it is necessary to build a new domain that will be isolated from the internal network. This means to create another domain infrastructure with at least one Domain Controller dedicated to the computers located on the perimeter network.
    

In this scenario, the Web Server is joined to the CONTOSODMZ domain; therefore, the Windows Update policies will be distributed by the Domain Controller that is located on the perimeter network.

For the group policy, you can follow two approaches on the deployment:

• Create an organizational unit (OU) for the servers on the perimeter network, create a group policy object (GPO) for Windows Update, and link to this OU.
  
• Edit the Default Domain Policy directly.
  

To configure the group policy for that, follow the steps in Configuring Automatic Updates on TechNet. For the option specify intranet microsoft update service location, be sure to specify the name of the FCS Server on the perimeter network.

Since this server is a replica of the WSUS server that is located on the internal network, you don’t need to approve the updates for Forefront Client Security; they are already approved.

For this scenario, the Web Server will get the Forefront Client Security client automatically from the Forefront Distribution Server (WSUS). There are some points that you need to make sure are working correctly for this distribution to function as it should:

• Make sure that the Web Server is joined to the domain, and if you choose to deploy the GPO on the OU, then move the Web Server to the OU.
  
• Run GPUPDATE /FORCE on the Web Server in order to force the server to get the GPO.
  
• Run wuauclt.exe /detectnow on the Web Server in order to force the update.
  

For ISA Server, the steps that were done in Scenario 2 will be the same ones used in this scenario.

For this scenario, we used the WSUS replica, which helps to manage the Internet Bandwidth and avoid that each WSUS server to retrieve updates from Microsoft Web site. During the first synchronization, you can observe if the traffic is correctly flowing through ISA Server 2006 by using the Monitoring option and launching the Logging view, as shown below:

Figure 7 – ISA Server 2006 Monitoring Logging.

As you can see on the screenshot above, there are three red squares on the main points of the screen.

1. The first one is the filter that was used in order to allow a visualization of the traffic originating from the perimeter network.
   
2. On the lower panel, we can see in the first square the name of the rule that is being used for this traffic
   
3. In the last red square, we have the client agent that is being used to access the internal resource.
   

It is important to mention that this is the initial WSUS synchronization. After synchronization is finished, clients will begin downloading the updates from WSUS. You will notice that the Client agent will change and appear as Microsoft BITS, as shown below:

Figure 8 – BITS job passing through ISA Server 2006.

For troubleshooting purposes, you might need to use a protocol analyzer such as Network Monitor 3 in order to see further details on the traffic. The example below was taken on the internal interface of the ISA Server while the WSUS server on the perimeter network was doing the initial synchronization:

1. Communication begins with the TCP three-way handshake:
   ISACONTN2 FCSDIST TCPTCP: Flags=.S......, SrcPort=25830, DstPort=HTTP(80), Len=0, Seq=3596964623, Ack=0, Win=65535 (scale factor not found)

FCSDIST ISACONTN2 TCPTCP: Flags=.S..A..., SrcPort=HTTP(80), DstPort=25830, Len=0, Seq=1748899480, Ack=3596964624, Win=16384 (scale factor not found)

ISACONTN2 FCSDIST TCPTCP: Flags=....A..., SrcPort=25830, DstPort=HTTP(80), Len=0, Seq=3596964624, Ack=1748899481, Win=65535 (scale factor not found)
   
   Notice that we are establishing the connection on port 80.
   
2. Afterwards, the Windows Update agent will start the communication on port 80 and begin downloading updates from WSUS:
   ISACONTN2 FCSDIST WinUpdV5WinUpdV5

ISACONTN2 FCSDIST HTTPHTTP: HTTP Payload

FCSDIST ISACONTN2 TCPTCP: Flags=....A..., SrcPort=HTTP(80), DstPort=25830, Len=0, Seq=1748899481, Ack=3596965248, Win=64911 (scale factor not found)

FCSDIST ISACONTN2 HTTPHTTP: Response, HTTP/1.1, Status Code = 200

FCSDIST ISACONTN2 HTTPHTTP: HTTP Payload

ISACONTN2 FCSDIST TCPTCP: Flags=....A..., SrcPort=25830, DstPort=HTTP(80), Len=0, Seq=3596965248, Ack=1748900342, Win=64674 (scale factor not found)
   
   Notice here that the Network Monitor 3.2 parses the Windows Update traffic as WinUpdV5. This probably will change if you are not using Network Monitor 3.2 or higher.
   

For the server located on the perimeter network, you can review the file %systemroot%\WindowsUpdate.log in order to see the detection of the Forefront Client Security client:

Figure 9 – Forefront Client Security client detection process.

If you look at Figure 9, you will see three parts that emphasize the main portions of the detection:

• Part 1 – FCS client detection.
  
• Part 2 – Initializing the download.
  
• Part 3 – Downloading the client itself.
  

After we have the client detected and installed, we have to download the definitions:

Figure 10 – Download Manager starting the job and downloading the FCS client.

The next cycle of updates will download the Forefront Client Security hotfix shown in the example below:

Figure 11 - Downloading the new definitions.

After all the updates have been downloaded and installed, the shield will became green, and the Forefront Client Security console displays the versions for the antivirus and antispyware definitions.

Figure 12 – Forefront Client Security console after the update.