Hyper-V Virtual Memory Considerations for Forefront Threat Management Gateway (TMG) 2010


When Forefront Threat Management Gateway (TMG) 2010 is installed in a virtual environment, careful consideration must be made with regard to resource allocation, especially memory (RAM). Forefront TMG 2010 relies heavily on RAM for essential functions, including network connection management, content caching, and malware inspection, just to name a few. An abundance of available memory is vital for TMG’s optimal performance. Ensuring that TMG has enough memory on a physical server is as simple as making sure you’ve installed enough physical memory on the system when it is built. In a virtual environment, however, this can be more challenging. Although simply specifying the amount of memory required for the TMG firewall might be sufficient, the fundamental purpose of server virtualization is to more effectively utilize the physical resources of the server, which means sharing available memory and other system resources with other workloads located on the same host. With this in mind, I’d like to explore and discuss some of the pertinent memory configuration settings on the Microsoft Hyper-V server virtualization platform.

Memory Requirements

Defining memory requirements for a virtual Forefront TMG implementation can be challenging and depends on many different factors, including the deployment scenario. Is TMG serving only as an edge firewall? Is it configured as a caching web proxy? Are clients configured as transparent (SecureNAT) or explicit web proxy clients? Are the advanced web protection features enabled, such as URL filtering, malware inspection, or HTTPS inspection? How many concurrent users do you expect during peak times? Is TMG configured as part of an enterprise array? Is authentication required? Will the TMG firewall be providing VPN services or serve as a reverse proxy server? Given the complexity of any given TMG deployment, my recommendation is to always aim high, as having too much memory is always better than not having enough. In a virtual environment we have the ability to change memory assignment quickly and easily, which makes the process of determining the appropriate memory configuration much easier.

As a baseline, the minimum RAM requirement for Forefront TMG is 2GB, so we’ll start there. However, in my experience most TMG deployments use considerably more memory than this. Determining just how much memory TMG requires will require that you observe memory trends in your environment by monitoring memory usage using Performance Monitor. I’d suggest starting a large amount of memory and working backwards from there. For example, if you assign 16GB of RAM for your TMG firewall and observe that your implementation never uses more than 8 GB, you can go back and change the memory assignments in Hyper-V to reclaim this memory. Again, this process is trial and error, but over time it works quite well. As a general practice you should monitor the resource utilization of your TMG firewalls for trending analysis. This will allow you to recognize patterns of increased resource utilization that can be proactively addressed, rather than waiting for users to complain about poor performance and having to make changes reactively.

Hyper-V Dynamic Memory

As I mentioned earlier, configuring memory settings for a guest virtual machine can be as simple as configuring a pool of static RAM. However, this is terribly inefficient and really defeats the purpose of deploying Forefront TMG on a virtual server in the first place. Let’s be honest…if you’re going to assign resources statically, why not just deploy TMG on a physical server! To get the most benefit from our server virtualization efforts, it will be necessary to assign only the amount of memory required for the workload. Beginning with Windows Server 2008 R2 SP1, Hyper-V includes a feature called Dynamic Memory that allows for the setting of two different memory settings – startup RAM and maximum RAM. Although this worked well and greatly improved the resource utilization and dramatically increased virtual guest density on the physical host, it was still somewhat less than optimal. For example, most systems require much more memory at startup than they do when they are running. Often it is necessary to allocate a generous amount of RAM to ensure reliable startup, but running memory utilization could, under some conditions, be considerably less. In Windows Server 2012, Hyper-V dynamic memory now provides an option to configure minimum RAM, which is independent of startup RAM. Now you can define ample memory for use a system startup, yet reclaim some of that memory after the system is running, if necessary.

Figure 1

Windows Server 2012 Hyper-V Virtual Memory Recommendations

If you’re deploying Forefront TMG 2010 on a Windows Server 2012 Hyper-V server, it is recommended that you configure startup RAM equal to the setting used for maximum RAM. This will ensure that enough memory is avaialbe for the operating system and Forefront TMG to start and fully initialize. Once the system is up and running, some of this memory can be reclaimed if required. During off-peark periods when TMG firewall resource utilization is low, the Hyper-V server can allocate additional memory to other workloads as necessary. In addition, depending on which workloads your TMG firewall is co-located with on the Hyper-V host, it might be a good idea to set the memory weight to the highest setting. This setting is used to determine which guest machines will have memory deallocated during times of high memory utilization on the Hyper-V host. Choosing the highest setting will make sure that the TMG firewall is one of the last resources to have it’s memory cannibalized for use by other guests on the same host.

SQL Server Memory Utilization

When Forefront TMG 2010 is installed, two instances of SQL Server 2008 Express are also installed. If you’re familiar with SQL server at all, you’ll understand that SQL performs its own memory management. In its default configuration, by design the SQL server will attempt to reserve large amounts of RAM for its own use, even if that memory is not immediately required. In fact, if you look at the SQL server settings you’ll see that, if my math is correct, SQL is configured by default with an upper limit of nearly 2 petabytes!

Figure 2

It’s important to note that the SQL server memory management process is intelligent, and it does not indiscriminately consume all of your available memory without justification. However, in many busy environments it can and does consume quite a bit of RAM. This can be especially problematic for large scale enterprise virtual deployments using dynamic memory, especially if the dynamic memory settings are not configured properly.

If you’re concerned about SQL memory utilization, or you have evidence of SQL server consuming inordinately large amounts of memory on your TMG firewall, it is possible to limit the amount of memory that SQL server can reserve. I’ll caution you that changing this setting can have serious, adverse effects on your TMG firewall if not configured correctly. However, if you’re convinced that SQL is consuming too much memory you can follow the steps outlined here to make adjustments to the default memory allocation settings for SQL server on the Forefront TMG firewall.


With careful planning and consideration, it is possible to configure Forefront TMG 2010 to work well in a virtualized environment. By paying close attention to the memory requirements of your implementation, and leveraging the advanced features of Hyper-V dynamic memory, the TMG firewall can perform adequately and at the same time play well with other workloads deployed on the same Hyper-V host by relinquishing RAM during periods of low TMG resource utilization. For the best performance, deploy Forefront TMG on Windows Server 2012 Hyper-V to take advantage of the latest features in dynamic memory by defining minimum RAM independently of the startup RAM. When configured properly, the TMG firewall will initialize much more quickly upon startup and use host memory resources much more efficiently after it is up and running.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top